… are going slowly right now.

I worked and worked on my engine, and right now- I don’t want to work on it anymore.

I pretty much lost direction with it and I don’t really know what I’m doing with it anymore, it became sort of a “thing” that I did for the sake of doing it, and when you end up correcting typos in the code comments, you know the motivation isn’t really there.
It’s in pretty OK shape right now, though. It can do some cool things, but it sucks at some other things and I will fix the suck a bit later on when I’ve regathered my motivation to work on it.

So I’m going to take a break from this engine for a little while and try to relax and do something else. I will still program stuff, just… different stuff.
I should really try to get back to working on games instead of writing this tech all the time. Not that I don’t enjoy coding the engine and solving the problems that it presents, I just can’t do it nonstop for too long apparently.

That’s that.


Engine Demo

Let’s start by making it clear that this demo isn’t finished.
It’s not finished because I’ve quite the engine re-design ahead of me and this project is sort of caught in the line of fire.
BUT. Instead of just coming on here and saying that it’s not finished for the millionth time I thought I’d at least show off a little from it.
It’s not a whole lot, and the videos are mostly still-shot.

But maybe someone could find something interesting in them. *shrug*

The following videos are shot from two different locations in the demo, both of which are not finished yet so they are very flat and boring.

This last video is a bit special, and a little bit of a failure:

It’s a bit of a failure because the framerate was so low during that video that the verlet cloth started acting weird and fell against its safety constraints which made it slouch somewhat.
And the purpose of this video was to show off the shadowing and how it interacts with the few banners that are suspended in this demo level.

Now, I’m going to elaborate a little on why it is that this demo isn’t finished yet:
That’s the biggest concern right now, and it’s intended that this demo has a couple of things that are animated. The “kobold” character I’ve shown (in the last post) is one of these “things”.
And when I noticed that it will take a little while to finish the animation support since the introduction of the binary model format unfortunately killed the animation some, I thought that OK- I’ll just post this anyway.
I’ll say again: It’s nowhere finished, so see it as a Work In Progress as I will eventually get back to this demo and spruce it up to match my new engine design.
I’ll still keep it in the shadows as to what this demo aims to do and what kind of a game it will be so at least that will still be a surprise when it’s go time for real. 🙂


I never made a post that contained screenshots of this in action, so I threw up some very quick so you can kinda see what it’s going to look like.

Note: I’m going to use some props I have lying around that I will later use in a more serious way (the oft mentioned “engine demo” I’m working on…)

So here you can see the effect of the backscatter on the thin parts of the creature, like his ears and his fingers.

What this effect now does is to apply a direct term of backscatter onto the rendered model, then apply the SSS approximation (I posted about just a few posts back) onto that, so you essentially get two effects in one.
It takes a lot of tweaking and consideration before it looks good…

Here’s another example of a tree:

Again, the light source (the sun in this case) is actually visible through the leaves if the camera were to pass by under the tree, looking up, which is a very nice effect.
You can even see it in this picture. The right side of the leaves is a lot brighter than the opposite side. This is because the light is coming down in that direction.

So that’s about it. This effect isn’t perfectly implemented yet, and some values are still in hard code and don’t allow user tweaking.


CSM Continued

OK! The cascaded shadow maps implementation is starting to show its first usable applications.

Given it still has some things that need to get adjusted to really make it complete, things like the calculations and how it’s integrated with the rest of the engine.

I have some quickly-thrown-together screenshots to share:
(I’m reworking the renderer so I’m without post processing. So no HDR bloom or AA.)

Here’s the result. It casts some nice shadows for the entire scene. As it should.

But. As you can see there are problems to this, such as this. As with the many posts I made a while back about rendering shadows outline, this is a common problem. Lack of hardware filtering ends in a brute-force approach which makes pretty jagged and noisy shadows at low resolution. It’s also possible in this screenshot to see the three cascades used for the shadows (Where the shadow suddenly drops in quality).

Here’s another problem I’m facing. Zooming out reveals the final cascade which is very low resolution compared to the two other cascades which show up close to the camera.
The Percentage Closer Filtering(PCF) doesn’t help a lot as you can see.

And this is a “for good measure” screenshot which shows the different cascades color-coded.

So even though the basics are already in and working there is a lot of work to be done. Part of this is to, again, explore different ways of filtering shadow maps to get softer visuals. I’m half leaning towards putting VSM in, but am tentative because of the light-bleeding artifacts. There’s also the possibility of LVSM which is similar to VSM but aims to reduce the mentioned artifacts.
*shrug* I don’t know yet.

Another part of what I need to improve is the actual calculation for the orthographic projection for the frustum slices. It’s right now at a “fudge” value, which isn’t accurate in any way so I will have to get the bounds of that projection to be more in tune with the bounding sphere.

Yeah, that’s about it. 🙂

Edit: Just as a pointer: I know it’s not really necessary to render different size shadow maps per cascade, but that was just a thing I decided on, don’t take it too seriously.

Edit #2: Another one. Screen space dithering helps with the jagged situation. Still noisy, though. But I often find it’s a worthy tradeoff; Noise for reduced aliasing. 🙂


OK. I don’t want to make a new post about this since it’s pretty minor and it’s connected to this post:

This is a different setup of the CSM which uses a consistent size for the shadow maps, 4 tap PCF and screen space dithering.
It looks a lot better now, albeit a bit noisy. And moving the camera around shimmers the shadows some, which I don’t really know if I’ll bother fixing right.
I think I’ll keep it as is for a while and focus on something else, like deferred shadow maps for spot lights. 🙂
(Bonus: I threw some trees in for testing how that looks.)


So. I started this implementation last night and I feel like I’m getting somewhere finally.
I have the frustum slices set up, I have the bounding spheres set up and I get some primitive shadows drawing per shadow cascade.

However. As good as that sounds there are a few major problem.
Primarily the problems stem from incorrect projection matrices.
I can get the shadows to draw correctly using a standard perspective projection, of course this is not something you’d want to do because of perspective warp. Shadows will move around according to the camera and it looks plain wrong.
I did this for testing purposes of course, I’ll just mention that it indeed does “work”.
Now, we want an orthographic projection for the shadow mapping so that the different cascades get along.
This is where the bad stuff happens. I, of course, have code for generating orthographic projections for matrices, but it seems like that code (written ages ago) has some problems getting along with the rendering of the shadow maps.
I will have to fix that before I get to make something cooler.

The good news is that my setup for the frustum slices and bounding spheres seem to be working correctly. 🙂
Back to work.

Edit: Initial work is done! I got the projections working and everything. I’ll make a real post about this soon! 🙂


Even more stuff has broken down!

Now, suddenly, the animation code that I’ve been using since forever (which is totally not part of the problem) has decided to stop working and outputs nothing but jumbled meshes and mysterious numbers.

This is a pretty big hit for me, since the engine demo was supposed to have one or two animated meshes in it. I’m not at all sure if I can make some alternate version that doesn’t use animations at all. This is not a great place to get stuck, I really want to get this demo out as fast as possible!

Usually for fixing broken animations I’ve resorted to controlling the matrices and usually the problem has been fixed just by transposing a matrix (no really, this has happened like twice.) but now, the results I’m getting are far, far worse.
I can’t even make out any parts of the mesh that’s animated correctly, it’s all a huge blob.

Anyhow. I’m left with two scenarios: I make an alternate version that requires no bone animation, or I spend some time rewriting the animation system just to make sure it’s not some corrupted data somewhere that’s messing stuff up.

Edit: OK, Now that I’ve thought a little about it. I think it may have something to do with a mismatch in vertices and vertex weights. This is basically the same problem as I had with vertex tangents a while ago, the number of components generated (be it tangents, vertex weights or bone indices) isn’t equal to the number of vertices which means it has a data shortage.
I think this may be what’s causing the problems I’m seeing but I can’t be entirely sure because it sort of seems like some of the matrices I’m printing out show unpredictable results which may be a problem also.

Edit #2: My god, this rewrite is going to take forever… And then another eternity after that one.
I’m making a conscious decision not to deal with this right now. I’m going back to program the CSM and the deferred shadowmaps. Cool? Cool.

Shadows or lack thereof

Due to some unforeseen renderer re-structuring I’m completely without shadows right now.
Yes, I knew the day would come when the special case of the shadowing system I had in place would collapse in on itself.
It did a heck of a good an adequate job while it lasted.
I will now move onto deferred shadow maps instead, which only makes sense.

I don’t know when that will be up and running, as I would definitely want to implement cascaded shadow mapping too and that might take a while.
I also know it won’t be made if I’m here writing a blog post about it so I will stop now.