Spellcaster Studios

Make it happen…

OpenGL Ambient Occlusion

Finished the ambient occlusion system, in OpenGL as well…

Before:

screen414

After:

screen415

Also arrived to the conclusion that I can’t really use the ambient occlusion to make the sprite shadows (they’re too small to actually impact the occlusion properly)… So I’ll have to use either the shadow system (still under consideration) or the decal system (waiting for development)…

Also, not sure on what my next step will be… My to-do list is quite large, but a lot of the stuff is very boring, and when you’re doing a game in your spare time, motivation is everything! Smile

But since ambient occlusion was fun (even if a bit frustrating at times), I should probably tackle one of the boring tasks now… I’ll sleep on it…

Now listening to “Silent So Long” by “Emigrate”

Link of the Day: Beautiful pixel art on this Kickstarter project… And it looks like my cup of tea (although I’m not sure how well the SHMUP genre can mix with the adventure genre, it seems like two completely different, disjointed target audiences): https://www.kickstarter.com/projects/imagosfilms/starr-mazer

https://www.kickstarter.com/projects/imagosfilms/starr-mazer

Tweaking

Today I didn’t have much time to work on the game, so I basically just tweaked the ambient occlusion parameters and saw where they went…

First experiment was to see if better filtering would help the algorithm… Of course, the filtering improves the effect, but visually it doesn’t add anything, so I’ll keep the low-cost 4×4 box filter for now, instead of the 49 taps gaussian I experimented with…

Second experiment, I increased the sampling radius to ridiculous levels (1.5 meters, instead of the 0.5 I was using)…

The results were frankly better for this cartoonish, lo-fi visuals I have (before/after):

screen406

screen407

You can really tell on the shadow below the console near the player, so I’m keeping this change…

Also played around with using a “curve” to modify the AO, trying to make the darker areas to show up better (more dramatically, even if less realistic). I played around with a sigma curve, but I ended up using a square curve (x=x^2) instead, since the difference was almost negligible and the cost is way lower:

screen408

screen409

screen410

Much more dramatic shadow, which helps flesh out the scene…

Finally, I decided to use the ambient occlusion term to modulate the direct lighting… This is silly from a realism perspective, since ambient occlusion simulates how the ambient light, the lose photons in the world interact with surfaces, and direct light is all about the direct photons…

The end result ended up being much better than I expected… Not realistic, but a bit more impactful and more suitable to the game’s aesthetic:

screen411

I’ve even removed the “blob-shadow” from the sprites, and it doesn’t look bad with just the shadow from the ambient occlusion term…

In a planet, with the normal render and without the blob shadow:

screen412

Everything flat and you the player character even seems to be floating…

Now, with ambient occlusion with the current parameters:

screen413

Much better, everything seems more fleshed out… The player still doesn’t feel in the ground, I think, but still it looks much better, things just seem to have more volume…

So, even thought yesterday was disapointed with the ambient occlusion, today I’m much happier… It was a good option all in all… Now I need to implement this in OpenGL (should be just a matter of porting the shaders), and think if direct lighting shadows is a good use of my development time, or if I should just move on the other things, like decals or glows, the dozens of small bugs or the new UI work…

Now listening to “Lindsey Stirling” by “Lindsey Stirling”

A bit disappointed…

…with the results of the ambient occlusion in practice…

It works fine now, but it’s extremely difficult to notice, which makes this whole endeavor kind of pointless…

screen400

The effect is clearly there (note the corners and the far edges of the shelves), but it doesn’t help much with the whole lack of contrast I wanted to address with this…

Below you can see the same scene without and with ambient occlusion:

screen404

screen405

Almost identical…

The problem is that due to the graphic style we’ve chosen for the game, there’s not much “ambient light” going around, it’s mostly direct lighting from light sources, which is unaffected by the ambient occlusion…

I could tweak this so that I use more ambient light and less directional light (on the space ship that might work very nicely anyway, and I might do it anyway, but even so it doesn’t have as much impact as I’d like)… In the screenshots below it’s the same comparison, but without any direct light:

screen403

screen402

I can also improve the filtering (I think I’m blurring too much, using a 4×4 box filter), or some kind of sigma curve to make the darker areas darker, or even modulate the direct lighting with the ambient occlusion, but in truth, I think the main problem is that the art isn’t done to work with this… Just a theory, but I think that for ambient occlusion to work nicely, you have to have stuff with more geometric surface detail, or normal maps…

Anyway, tomorrow I’m going to do a couple of experiments with this, see if I can reach some useful conclusion, but for now I’m convinced I’m going to have to implement actual shadow-mapping (only for directional and spot lights, which makes it way easier).

Now listening to “The Revenge” by “Allen-Lande”

Link of the Day: Some amazing screenshots from PC games… Some of them are processed or tweaked renderers, but still very impressive: http://www.neogaf.com/forum/showthread.php?t=963160

Almost done!

After a long battle with almost every single line of code of the screenspace effect system, I managed to get something resembling ambient occlusion!

screen398

Now I need to add a blur filter to remove the artifacts and I can run tests on the actual scenes, see how good they look, and to see if I need to implement actual shadows of this is good enough for my purposes!

Now listening to “Ravenhead” by “Orden Ogan”

Link of the Day: I need one of these… for research purposes, of course…

So ashamed…

Finally figured out what was the problem with my reconstruction of the position from the FOV and depth…

NOTHING! ABSOLUTELY NOTHING!

The problem was way before that… For some reason (and I never noticed it for years on end), I was using the field of view parameter as the VERTICAL field of view, scaled by half (for some another really unknown reason), but everything I made with shaders that required the field of view assumed I was using the fov property as the HORIZONTAL FOV… The scaling factor I had only screwed up everything…

So I was looking at at a scene with a FOV property set to 80º… But since I was diving that scale by 2 (yielding 40º), and then computing the horizontal FOV from it by dividing by the aspect ratio (yielding 71º), the visual result was close enough for me never to suspect a thing…

Except when I’m actually using the fov in another calculation on a shader and nothing seems right…

What helped this revelation was the fact that I decided to change the way I was seeing the error on screen… Instead of using colors, I decided to compute the world position and compare that with the depth I had on the depth buffer…

The two images below show the “normal” result (the one rendered correctly), and the one that the SSAO would compute half-way through the process:

screen396

screen397

When I saw this, I figured the problem would have to have something to do with the FOV, the images were too close to be a normal math or reasoning error…

After a lot more debugging, finally figured it out!

Now, tomorrow I’ll be able to see the SSAO in action properly!

Now listening to “Ghost Opera” by “Kamelot”

Link of the Day: I know this is a hype video, and we’re really far from this, no matter what Microsoft marketers says… But it looks soooooo cool! I can imagine my “Skylander’s-like” game here… Smile

Close, but not there…

Found some of the problems of the system yesterday, but the results are still terrible:

screen393

It was inverted on this screenshot due to lack of correction of texture coordinates to screen coordinates.

Anyway, the problem I’m having is reconstructing the camera-relative position of the pixels, based on the depth and field-of-view… Something is going wrong there, although I’m not sure what… I did a lot of math and everything should be correct:

screen395

But if I draw the error between the reconstructed position and the actual position, the error is quite noticeable:

screen394

More “red” means more error in X, more green means more error on the Y coordinate…

So, a lot of work ahead of me now…

Now listening to “Ravenhead” by “Orden Ogan”

Link of the Day: This Kickstarter project has probably one of the best trailers ever: https://www.kickstarter.com/projects/strafegame/strafe

First trial!

..and it didn’t go very well…

screen392

I can distinguish some features (if I move around), but it seems… wrong…

It’s like only the part in the middle Y of the screen is having ambient occlusion computed more or less correctly, and I’ve been looking at this shader for almost one hour and I can’t figure out exactly where things are going wrong…

My guess is that the depth is being computed wrong, but I’m not seeing how…

Well, time to look at it with a bit more attention…

Now listening to “The Grand Design” by “Edenbridge”

Link of the Day: Found this very nifty utility to create pixel art and (more importantly) to create procedural tiles… It’s actually easy to use and will definitely come in handy on my 48-hour compos! It’s “pay-what-you-want”, so check it out: http://pnjeffries.itch.io/spartan-procjam-edition

Computing a basis

For the SSAO, we have to compute a basis for the points to be able to do the random sampling…

My linear algebra was a bit rusted, but I found the Gram-Schmidt process to be useful for this. Basically it creates a geometric orthogonal from vectors, which define a local space, in my case aligned along the normal vector of the surface.

Displaying the tangent vector with the noise included, I get something like this:

screen391

It looks a bit silly, but it makes total sense when you map the colors to actual vectors, which shows the AO process is going nicely so far…

Now listening to “Paris Kills” by “The 69 Eyes”

Link of the Day: Another excelent documentary by “Ahoy”, now focusing on the history of the open world games:

View-space normals

Working on this a couple of hours at a time is not efficient, but time has been rather short lately…

Anyway, added view-space normals to the renderer, so I can do the screenspace effect:

screen390

It doesn’t seem very different, but it is… Smile

Anyway, I need the view-space normals because I’m using view space positions, and I need to change them so I can project the new position to check for the occlusion…

Next step is to get the random texture and the kernel in for randomly sample the depth map.

Now listening to “Of Rust And Bones” by “Poisonblack”

Link of the Day: Very interesting article on path-tracing and application on fractal rendering. Fractals are very interesting from a mathematic perspective and they’re beautiful to look at as well: http://blog.hvidtfeldts.net/index.php/2015/01/path-tracing-3d-fractals/

So much lost time…

So today I started implementing SSAO, and it was demoralizing… Sad smile

I was looking into my old SSAO shaders, and I decided to implement the simple version before moving towards more complex versions, and I hit the first hurdle…

When I started work on my deferred renderer (which was going to be used by the SSAO stuff), I had to compute the world position of the pixel of the rendered image, based only on the depth at that point. But at the time, I wasn’t getting the math right, and since I had a self-imposed deadline, I cheated and stored the world position into one my render targets, to be changed at a later time… Well, that later time never came, which means that the reconstruction of the position was never done… Since I don’t want to make the same mistake again, I started working on that for this shader… and again, I couldn’t get the math right!

After a long time looking at the math and the parameters, etc, I finally found out what the problem was… I was computing the position correctly, yes, but relative to the camera, not the actual world position. So, basically I was interpreting the data wrong…

After this revelation, I could change the shader to display normals if the distance in X is lower than 10, and the depth if it’s higher:

screen389

I think view-space position is good enough for AO, since it’s all relative for its sake, but then I still have the problem of the normal… The normal is a world-space normal, so maybe I have to change it so it’s a view-space normal instead to be able to use it this way, which would require me to do some math on the pixel shader to account for that… Need to check if I actually need it in view-space… I can find good reasons for both, so I really need to go into the math… Disappointed smile

Now listening to “The Metal Opera, Part I” by “Avantasia”

Link of the Day: All gamers have a backlog… Mine is mostly on Steam, and thanks to this nifty site, I can see how much time it would take me to play through all my unfinished games on Steam: About 105 days… Check yours out at http://steamleft.com/