Decal-based shadows work better than I expected, it looses that effect of being just a quad below the characters, etc:
In this case it’s quite hard to make out, except when stuff is moving… Here’s an old screenshot for comparison:
If you zoom on the shadow you can see the difference…
It’s much more noticeable on the acid cloud enemy… It used to look like this:
You can’t really tell where the cloud starts… The character is being hit by the cloud where I’m standing, but it seems to be far away from it, because of perspective and particle density…
Now, with the new decal-based shadow, it becomes much easier to spot:
It adds volume to it as well, which is nice…
Now to do the same to the lightning cloud (and better lightning)…
Now listening to “Shatter Me” by “Lindsey Stirling”
Link of the Day: Found this page full of nice papers… There’s some very neat stuff there, especially regarding realtime shadows: http://chriswyman.org/papers.html
Now I got plasma burns (on some weapons, not all).
It still has some error, there are gaps in the stream for some reason, probably something wrong with the collision detection, but I’ll look into it when I work on the raycasting optimization…
Now it’s time to look at the possibility of using the decals to do the blob shadows!
Now listening to “Best Of” by “Leonard Cohen”
After a nasty fight (brain was slow today!), got the bullet holes up and running in the game!
Also added a small camera shake with the shots, to lend some force to the weapon… Next, plasma burns!
Now listening to “Torn” by “Evergrey”
Finished the refactoring (or most of it, probably still missing some stuff, but I’ll correct it as I do another playthrough of the game), and now decals work much better!
There’s still some stuff that’s rendered wrong (for example, coplanar alpha objects with decals, like an explosion on the ceiling of the pirate lair), but it will probably just be a matter of tweaking values…
Next step (much more fun) is to use the decals in game stuff, like shot marks, etc…
Now listening to “Crimson Glory” by “Crimson Glory”
Link of the Day: Fascinating (and a bit scary) read regarding emotion analysis: http://www.newyorker.com/magazine/2015/01/19/know-feel
Tomorrow I’ll probably be done with the refactoring of the new rendering pipeline…
With this one I’m getting way more control over the whole rendering system, which will help me get the decals working properly…
Then I can move to more interesting (and visual) stuff!
Now listening to “The Classical Conspiracy” by “Epica”
Stage 1 of the refactoring is done… It just replicates what was already working:
The only difference is internally… I create a scene graph and render that, instead of iterating all the objects… And even that is not completely done, since the elements of the scene graph are most of the time just a pointer to the object that gets drawn, now I’m going to work on the specific instances…
By providing more information on the scene graph, I can then do smarter stuff, like sorting back to front, do some culling, and even prioritize some objects over others in an easy fashion…
Now listening to “A Matter of Life and Death” by “Iron Maiden”
Link of the Day: Nothing very wow to post today, but I saw this Jimmy Fallon clip and it made me giggle… I was a big fan of “Saved By The Bell” back in the early 90’s, so this hits my nostalgia just right:
Yep, that’s what I’m doing… It will be a bit painful and I’ll get a lot of bugs in the process, but I think it’s the best thing at this moment…
Currently, the rendering is working in a per-pass/per-object basis…
So, first we get the solid pass, iterate objects, render all of them (and they will check if they should be render in the current pass), then go to the alpha pass, etc, etc…
What I want to do is a “object pre-pass”… So I gather all the objects/meshes/render elements in a single array, with some metadata on their usage, conditions and rules (I don’t want lighting on this object, I don’t want to do decals on this one, etc), and then on the render pass I’ll iterate this array and should be drawn or not, rendering as intended…
The idea on this is to save some CPU power (not much, I expect), but mainly so I can organize the render data according to my criteria, for example, to sort alpha objects back to front, and solid objects front to back, to exclude dynamic objects from decal rendering, draw these special effect objects after the decals are done, exclude objects from the depth/normal stage, etc…
It’s going to be a lot of work, but in the long run it will be fairly positive!
Now listening to “Sunset of the Golden Age” by Alestorm
Unfortunately, my initial idea that screen-space decals was some sort of magic bullet was completely wrong…
They work great a lot of the time, easy to implement, fast… but (there’s always a but) they have some small details which break it down…
The issue I talked about yesterday was mostly solved with the stencil buffer:
So that’s good, I can mask where the decals is drawn and where it isn’t… But unfortunately, it doesn’t solve the issue with the explosions, since there we want to draw the decal, but “behind” the explosion, but due to the way alpha blending works, it doesn’t work:
If you’d see the stencil buffer, you’d notice that on the edge of the explosion (where there isn’t almost any color, but it’s necessary for its smoothness) is flagged as not allowing the decal, but we’d like a decal there, and then the explosion… I can maybe solve this by playing around with the passes (move the explosion to the effect pass, and only draw decals on the alpha pass), but it’s getting to be a sloppier and sloppier implementation…
Another issue is the edge of the geometry… For example, on the window of the Skydancer, this works fine if the explosion isn’t on top of the glass:
But as soon as it overlaps, the UVs get stretched:
This one I was actually expecting and I can probably solve it with some threshold on the angle between the decal normal and the world normal.
One more issue, mostly relating to the “scorch marks” decal: what happens on the edges of objects:
It seems the scorch is something planar… I can fix partly finish this by extending the decal box on the Y-axis, but it would just extend the black on top the the wall, which would look very weird…
One possible solution for this one is to create some sort of “radial decal”, which instead of being a box, ends up being a sphere and with some different mapping (might be hard for the artist to build the texture for this).
Finally, another expression of the alpha issue and the fact that alpha-objects aren’t affected by decals (by not letting decals be drawn):
The glow of the beam is a billboard drawn on the ground, which will fill the stencil buffer with a mark saying “don’t draw here”, which stops the decal from being drawn, which spoils the decal effect…
Again, this one might be sorted by doing a separate decal pass…
Finally, one of the problems that isn’t a real problem now is the fact that this requires a lot of rendering in separate passes, etc… This could be minimized by doing a “gather” phase before rendering… Basically, just iterate all objects and fetch all the meshes and materials in the scene, with some more properties describing what kind of usage they have… With that I can then just iterate it and draw/not draw according to the specific circumstance…
So, basically decals have extended my to-do list instead of reducing it… For a lot of stuff (like bullet holes on walls), the current solution would work fine, but my main interest at this point was to use the decals for the scorch marks (with the above results), entity shadows (think that one would work in most cases, except inside the facilities) and the shadows for the poison cloud and storm cloud (might work).
So I think the next stop will be creating the gather phase (which I also hope will help clean up the code and optimize a lot, even if there isn’t a big need for it), which is extremely boring! 
Now listening to “Savage Poetry” by “Edguy”
Link of the Day: Found this white paper on how to make a system for AABB trees for collision detection while saving loads of RAM, you might find it interesting… I know I did: http://www.codercorner.com/ZeroByteBVH.pdf
Well… Just finished implementing decals… It went better than expected, since I’ve never tried implementing screen-space decals before…
The main difficulty of screen-space decals is the occlusion. Most of the code is related to this, and mine is working great:
One problem I’m already seeing is the fact that the way the decal maps removes a bit of the volume of the scene in the affected area… Not sure if the problem is the texture (need to run tests), or if the UV mapping is not correct (but it seems to be, at least on this kind of “orthographic” decal, if it was a perspective decal, the contour of the underlying terrain might be more noticeable). This can also be minimized by using some sort of smoothing of the blend based on the angle of the underlying normal and the decal normal.
I have more serious issues, though, namely the alpha objects:
They get rendered “behind” the decal… The reason for this is very simple: the decal is completely drawn based on the existing depth, and the alpha objects usually don’t draw to depth, which means that from the decal rendering point of view, they simply aren’t there… This is a tricky one to solve…
The other one has another reason for it, but it’s also as tricky to solve:
Here, the sprite is drawn on the depth map, but the decal is still rendered “on top” of it… Here the issue is the fact that the decal act as sort of “projector” that affects EVERYTHING in the scene, including the player… Of course, this isn’t the goal (most of the time…)
Not sure exactly how I can solve this issue… One solution is to render to a stencil map what can or not be affected by the decals… Basically, I’d set on the stencil buffer to 1 in all the static geometry (which I want affected by the decals), and to 0 all the dynamic stuff (or more precisely, just don’t draw to the stencil buffer).
This is not a very elegant solution in my opinion because it requires me to render to another buffer, but in all honesty, I don’t see any way around it: the decals need to be aware where they can be drawn in screen-space. From a perfomance point of view this can be made quite fast with a Z-equal test, no color or z-writes, and choosing the objects I’m interested in “decaling”.
The good news is that they are rather fast (at least on my PC) and on static geometry they work as a charm!
Now listening to “Songs from a Room” by “Leonard Cohen”
Link of the Day: I’m not a big fan of online competitive games, so I’m not seeing myself playing this one, but it looks extremely cool: http://www.polygon.com/2015/1/27/7917991/dreadnought-video-gameplay-preview
One of the effects I would like to use extensively in the game is “decals”…
A decal is just a kind of painting you put on top of the geometry.
Decals used to be done by intersecting the world geometry with the decal shape and drawing those polygons, but since I now have the normal/depth of each point on screen available, I can probably get away with using screen-space decals… I got the idea first from this presentation: Screen Space Decals in Warhammer 40K: Space Marine.
As the rest of my rendering engine, I’m betting a lot of batching, which introduces some complications: since I can’t pass the decal property as a constant to the shader, I need to find another way to pass it in. For now, I’m using the texture coordinates of the box itself, which is a bit wasteful. I could use an array and just pass an index, but that would be more complex and would have other limitations, like the number of decals on a single batch.
So, to be able to add this kind of “custom data” to each vertex, I had to code in a new vertex declaration system, but that was quite fast (I had to do most of the groundwork before for the OpenGL port anyway).
So, the current state of this is:
“What am I looking at?!”, I hear you say…
Basically, you’re looking at the rendered decal volume, in which every point is colored with the normal extracted from the Normal+Depth buffer…
Tomorrow I’ll work on actually generating UVs from that and discard the points that don’t belong inside the decal box… Just look at the tree below:
Most of the code on the decal shader is to prevent that from happening… 
Now listening to “The Burning Halo” by “Draconian”
