Deferred shadowmaps

Yes. They are finally happening after all this time.

So now I’ve got fully deferred lighting, but I have CSM for directional lights and now, with the twiddling of some shader math, shadowmaps for spotlights!

There we are!
The same ol’ shadows, except now they aren’t rendered using forward rendering and therefore run about a million times faster (n-… not actually the real number).

Anyway. As you can also see the Gobos are back in action. These are actually very easy to implement once shadowing is working and vice versa.

I’ll go back to work now.

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. 🙂

Some updates


I’ve been fixing up the particle system some, to allow the features I never had the energy to do a while ago when I posted that video with the gargoyle face and stuff.
There’s still a lot missing that are necessary for a full featured particle system, but the basic stuff is working fine.
Except I’m going to have to redesign the system itself a little.
Right now it’s divided into particle effects and emitters.
The idea is you attach particle effects onto emitters and create effects in that manner.
But the way it’s designed it doesn’t actually allow more than one particle effect per emitter, or even multiple emitters sharing a particle effect. A little design flaw there. oops.

I experimented a little with color grading as a post processing effect.
So far I think it’s a cool thing, even though I’m not a huge fan of it in general. It’s a fickle matter, it takes a lot of consideration and fine tuning to get right.
There’s also the issue of banding artifacts, which I understand is commonplace with color grading. I’ll have to experiment a little with different stuff to alleviate it to some degree. The banding really looks terrible in some cases, definitely not something you’d expect to see in modern engines.
In case someone wants to get a reference as to why I get this banding artifact: It’s because the loaded texture that contains the color information is just 8 bits per channel, meaning we don’t have a lot of resolution to stretch that to the rendered bit depth which is far higher.

It’s come to the point where I’m going to start implementing the ‘final’ step of my custom 3d file format.
The binary step. (oooh, aaah) But really, it’s too slow to parse text and the format is robust enough not to crash every second time I use it so. It’s that time.
The format is not that amazing really. It just supports the bare minimum of what I need, so there’s no awesome animation support like curves, morph targets and stuff like that in it ( …yet).
I’m not really planning to use this format forever. It was sort of my own idea that I would eventually switch to something else, to Collada perhaps. (*whisper* if the damned exporter support was better.)
I would use FBX, but I’m rather put off by the options of parsing. Either parse the text based file or use Autodesk’s FBX parsing library. I’m not even sure the schematic is public so you could parse the binary yourself.
Anyway It’s too heavy for my (rather) lightweight framework, but I might take a closer look at one point.

Uuh… I think that’s about it. I’m doing a ton of other stuff too, but nothing significant to write about.

Things and stuff

I’ve been spending some time rethinking and re-implementing a part of my material system to basically be more versatile than what it was.
Since my renderer still utilizes sort of a hybrid rendering using a deferred approach to handle the largest bulk of the lighting and standard forward rendering for the rest, what I can and can’t do is pretty apparent.
But. With my latest additions the renderer is way more full featured and can be used to make a plethora of effects.
I still don’t handle transparency that well. Sorting transparent geometry is always difficult to get good. So I probably won’t bother trying to make more of it than I have to. Basic back to front sorting will have to do.

Here’s a boring ol’ wall tile with a texture applied.
Now how this is being rendered is of course mostly up to the material attached to that object.
We can change the material to do something else:

Here I turned the material into a mirror-shine super glossy material.

I also added a “custom” routine for effects and stuff that fall out of the reach of my generalized pipeline so we can render those with custom shaders and blending operations and stuff.
Main problem with that is of course that they can usually not take part of the scene’s lighting.
To remedy that, there’s a “super crisis-system”(this is not its actual name) that allows arbitrary shaders to access the scene’s lighting manually so we can at least get some of the lighting on it. Right now I’m planning on allowing access to 4 of the biggest nearby lights. I’m filtering out small and faint lights as these don’t affect the geometry as much (Duh).

I finished putting in support for the last channel of the dedicated “mask” texture that is available through the material’s texture slots.
The “mask” texture is a special texture that stores 3 textures in one. One texture per channel.
It stores Specular Gloss, Fresnel and Reflection.
I find it a tiny bit unintuitive to cram textures into channels of other textures, but artists don’t generally seem to mind; there are plenty other engines that do something similar.

Aaah. What else?

Haha. 😀 Just for fun I tried putting in a monster from Doom 3 to see how the texture maps translated into my engine’s material system.

Hmm. I guess that’s about it for right now. I should really document what I actually do better. I feel like I forget more than half the things.

HDR stuff… Again

This is why I think HDR is so neat.

Check this out. It’s the same scenario as the last post (I know the images are small, but they are large enough to get the message across…).

The spotlight here is at intensity “1” meaning it’s only capable of being as bright as the screen pixel, so my HDR bloom doesn’t even bother blowing it out in any way.

But if we change the light’s intensity to say, 4?

We get this…
Everything is super glowy! 🙂
Also please note, I’m not changing the entire scene’s brightness or the exposure of the camera, just the light’s intensity.

Here’s a shot from the back so you can see that nice bleed you get from the light area to the dark area. 😉

Now this would not be possible using LDR formats for the rendering. LDR AFAIK always clamps the pixel’s value to 1 (255) if it’s greater, it can never exceed it.
HDR allows pixels brighter than 1 (It’s floating point after all, not unsigned byte). But because we lack the means to fully represent it (our computer monitors are LDR, mind you), people allow the brightest pixels to bleed over to the neighboring pixels instead, showing that they are brighter than the rest, or put in another term: light bloom.
If I were to have the same threshold for the bloom as I have now (at > 1) and render using a LDR format, I’d never get any bloom at all. The pixels after all can’t, logically, exceed that value.

Things to keep me busy

So. Since I hit that little snag I posted about yesterday and I wasn’t able to post the updates like I imagined I just now thought that I’d put some stuff up here as an equalizer for the boring bugs I have to deal with.

Starting off with a model I made yesterday as a “warmup” for getting back into modeling a little more.
I’m determined to give a “modern” modeling workflow a shot, so I sculpted a model, remade its topology, baked normalmaps and ambient occlusion from it then finally made the textures using the information I had at that point.

So. It’s a stone column of sorts. I wanted to do a piece like this specifically because it’s sort of a “modules within modules” thing, and that appeals to me.
The column is composed of the individual bricks I sculpted, and the low-poly cage is built from that super high-polygon model.
It turned out surprisingly well, and the normalmap/ambient occlusion bake went effortlessly too. I usually have a lot of artifacts, but not this time.
Oh, I know the texture has seams. 😉 Laziness kicking in.

Here it is rendered real time also, just for kicks. Though it’s pretty hard to tell it apart from the background. Constant ambient, I curse you. Also, lack of scene “fog” that helps perspective.

So, there are some other things I wanted to explain/show, one which is actually in that engine render above.
The model is lit by two lights in that screenshot. One pointlight and one spotlight. The spotlight casts shadows onto the model that are made by a obstructing model which we’ll get to soon.
However, what’s changed from the last post I made showing spotlight shadows is that the shadows are now soft shadows.
Yes, that’s right. They are totally better looking now than before.
Right now the softness is brought on by a 4 tap PCF(percentage closer filtering) and a sort of screen space dithering routine. 4 tap PCF is usually a very low sample for soft shadows, but with the help of the screen space dithering the visual artifacts are not that noticeable.

The model that’s obstructing the light there is this one:

A window thing. That floats in mid-air.
There’s something else up with this window. It’s light-bloomed to the high heavens! That’s the HDR Bloom thing I’m working on for the post processing pipeline.
It’s not working that great right now, but gives a pretty good effect for making things glow.
The blurring I used for this effect is pretty costly. So there’s another reason not to use it yet.

Alright. There’s one last thing I mentioned in the last posts but didn’t show.
How I “improved” the water and what it looks like.

Here’s an “overview” shot of the water and where it intersects with the geometry.

Here’s a screenshot looking into the water near the column.

And here’s finally the change I made. At this low horizon angle the column is still visible where it intersects the water surface. This didn’t happen in the older water and I think it’s more “accurate” like this.

… And it’s OK. I know the refraction artifacts are pretty damn prominent. But I don’t really want to get into ameliorating it yet…

There- now that’s officially off my chest, I’ll get to go back to staring at pixels again. Bye. 🙂

Edit: One more for good measure:

The light, as reflected by the water surface. It of course changes shape depending on the viewer angle, it’s like any other specular highlight in the engine. 🙂

Another showcase and some other stuff…

(Also there’s that dagger again from the last video.)
So. After that bit of video I’m going to hammer my fingers against this keyboard for a little while, like so:

Just for a brief moment I’m going to tell you what you just saw in that video.
The most apparent thing, I guess, is the water. Both the water plane and the flowing water out of the gargoyle’s face.
The flow is just particles, as simple as that. Tiny billboards with textures, nothing fancy.

The water plane, however, is a little bit more complicated.
The main feature I decided to implement was the refraction, the rippling of whatever is seen through the surface.
So, because of this I left out reflections completely, and I decided to go with simple cubemap reflection for now.
I also have a simple Fresnel term for the water, meaning the refractions/reflections are only visible depending on the viewer angle. Although this doesn’t show too much in this video.

There are plenty of things left to be done. Like specular highlights from nearby lights on the water surface, or depth “fog” etc.
And after this little stunt my poor renderer is left bleeding. I picked it apart a lot and now it’s just kinda there, like some kind of mysterious monolith, staring back at me.

No, but on a serious note- the things in this video are seriously hacked together in a matter of hours, so there’s a good deal of negligence going on. That particle system, for example, is- I don’t dare to speak the words- hard coded.
And it’s just tacked on top of everything else like a gross ol’ band-aid.
Bottom line: It’s, technically, ugly as hell.
There are even some negligence visible in the video… Hint: Did you see that water-stream jump a little at times? That’s a frame-rate dependent bug. It did that when I was recording, but it doesn’t do that generally when I run it on my computer.

So why did I produce this monstrosity?
Hey, gotta start somewhere. Now that I know what I want, I can work on a better way of implementing it. 🙂

Bye now. 😀