EDIT 2Okie dokie, The model is now working correctly inside the program and a good camera angle.{"name":"609995","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f0a2facd89010537ab74a4ec6d14d7c.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f0a2facd89010537ab74a4ec6d14d7c"}

EDIT 3To keep things focused on just-get-things-working, I grabbed the glm:: header files that are used in the tutorial to build the ortho transform for the light projection. Thanks to Elias' cool new feature, I was able to peruse the code much more easily and skim-check if there were any conflicts between the glm matrix and Allegro's ALLEGRO_TRANSFORM. So far no red flags.

EDIT 4Alrightie, the difficulty curve has shot up. There are conflicts between my OpenGL/GLSL/version_numbers/Allegro/the_tutorial/my_knowledge_of_anything. For one reason or another, I am unable to create a framebuffer with this simple code (the glCheckFramebufferStatus line keeps sending me to "glCheckFrambufferStatus == FALSE") :

To keep moving what I might have to do is just create a shader on an ALLEGRO_BITMAP that draws the depth in RGB. more investigation to continue...

EDIT 5Also, to anybody who's interested, the tutorial's shaders have #version 330 core at the top, and upon compiling the shader I get the message "ERROR: version 330 is unavailable"

EDIT 6Wooohf! I finally made some headway. This whole time I was having difficulty drawing to an ALLEGRO_BITMAP; It was coming out blank. It turns out it was because the object(s) I was trying to draw (the scene model from earlier) was not being drawn in both views, despite me having created the infrastructure. The static world model was considered a "special case" in the engine and not included in the list of entities to render in all views. Good news is, now I have 2 projections with different rendering methods working simultaniously.

Camera View:{"name":"609996","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/8\/a8c99f72a570e25a16f175efc680c5df.png","w":1920,"h":1200,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/8\/a8c99f72a570e25a16f175efc680c5df"}Light Projection View:{"name":"609997","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/ad607aced189ead5c93e1a1f58029b56.png","w":1920,"h":1200,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/ad607aced189ead5c93e1a1f58029b56"}Depth is right around the corner.

When attempting to render to my depth-view, the depth test is somehow exactly flipped.{"name":"609998","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/f\/8f41682a891e29552ab1a2b433c82782.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/f\/8f41682a891e29552ab1a2b433c82782"}

I'm even at the point now where I'm getting glitch art: {"name":"609999","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/c\/ac088e791935043a4c1d615704677eed.png","w":1044,"h":706,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/c\/ac088e791935043a4c1d615704677eed"}

It looks like the shadows won't arrive for another day. Perhaps my weary body will be better equipped after a nights rest.

In discouragement at being unfamiliar with rendering to a strict depth buffer, I decided to just create a simple shader that would draw depth to an ALLEGRO_BITMAP. What I did was pass into the shader the real-world-position of the camera, and calculate distance() to the real-world-position of the vertex. It worked... ish:{"name":"610003","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c5a4fe173e1b736e52c3676515892b8.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5c5a4fe173e1b736e52c3676515892b8"}Darker colors represent being closer to the camera, while lighter colors are further.

But why is the floor white? My theory is that since I was calculating the distance to each vertex, glsl was calculating that the four corners of the bottom plane were at a far distance from the camera, and then interpolating those values to fill in the rest of the geometry.

At that point I realized that the camera's position is already (0,0,0) in the shader after the al_porjview_matrix is multiplied to the object in the shader, and I could avoid having to calculate a million distance() formulas, which are really slow. And the depth value that I need is already in the 4th component of the shader's gl_Position.

I coded it in, and it worked!{"name":"610004","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/0\/2001f9c79772db6044463ddb07d8f73e.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/0\/2001f9c79772db6044463ddb07d8f73e"}This is the actual depth data that I need (but to make it more visible, I had to multiply it by 0.05 because my view frustum is verrrrry deep. When I make it a frustum for the light projection, it probably won't need to be nearly as deep)

Ok, it looks like I have run into a problem. When drawing to an ALLEGRO_BITMAPthat is not the backbuffer (or a subbitmap of the backbuffer), the depth sorting gets all messed up. This is what the scene looks like when drawn per the usual way:

Depth Shader On A Target Bitamp (that is NOT a Backbuffer): - EEKS!{"name":"610015","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fb200f6810fbbe86d5dd3af9b9dc2457.png","w":1920,"h":1200,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fb200f6810fbbe86d5dd3af9b9dc2457"}

I'm not sure what's causing this problem. Any ideas? I'll try it without using a shader.

EDIT 1Oh well interesting, it also has the same problem when not using the shader.

Normal Drawing on a Target Bitmap (that is NOT a Backbuffer): - Also EEKS!{"name":"610016","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/2\/3265897c395bce43dd6e5a87da48da33.png","w":1920,"h":1200,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/2\/3265897c395bce43dd6e5a87da48da33"}

I thought there was something wrong with my depth algorithm, so I looked into it and it turns out the geometry was messed up. The cone was hovering above the plane by about 0.2:{"name":"610021","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/6\/96cb22eaf7ad1c7e8e38bcd800cd3e14.gif","w":396,"h":211,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/6\/96cb22eaf7ad1c7e8e38bcd800cd3e14"}

So I fixed that:{"name":"610022","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/c\/acce09e40629957190cb98e10404bfb6.png","w":727,"h":473,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/c\/acce09e40629957190cb98e10404bfb6"}

---

Ok. I'm excited to finally have a (sort of) depth map! Next up we should see some semblance of shadows.

Everything's all out of wack, but it's all in there. All that's left is to work out the math just inside the shader. I added a bunch of little floating objects to make the depth more palatable. Note that this is not actual shadows mapped, rather it's the depth image just plastered onto the models as if it were a regular plain old texture map.The floating things are just reflective AllegroFlare logos.

It's cool 'cause if you look at the floor you can see that the rotating logos have "shadows" that are also rotating as well.

That's where it all started.

After that, I needed to make sure the 0.05 that I multiplied to the depth wouldn't be a problem.

{"name":"610025","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/5\/5581400a6160bb752680d37874f00768.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/5\/5581400a6160bb752680d37874f00768"}^This is me checking that the light depth and camera depth data are not being confused with each other. In this image, the darker pixels represent smaller distance to the light source. So this shows that the light source is on the other side of the camera and that data is separate from the active viewing angle. It also shows that the value ranges for the light depth and camera depth are (essentially) the same.

Good. Everything is in order.

Now it's time to calculate an actual shadow map onto the scene.

And finally, without further ado, here is the first image showing an actual shadow projection:

If you look carefully, you can see that the texture is looping for some reason. So somewhere the UV mapping coordinates are scaled incorrectly. So I scale them by some multiple:{"name":"610027","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f830b1d3919a5aa5396799de48bd3f77.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/8\/f830b1d3919a5aa5396799de48bd3f77"}^ Oops! wrong direction. I multiplied when I should have divided.

{"name":"610028","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/7\/47b33701eed38d4c6ef16abc33ef3f18.png","w":1072,"h":734,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/7\/47b33701eed38d4c6ef16abc33ef3f18"}Cool, but the alignment is off, too. So I put in 2 dials to let me offset the texture:

At this point I create a bunch of cool abstract art. But it's still a little tough to se what's going on so I put in some crappy texturing to get a better sense of space and depth:

It's so close. It looks like the depth calculation is correct - shadows are deforming onto the geometry correctly. It's cool how it working and not working at the same time. It's just that there is something amis with the actual projection itself.

I wanted to add that when trying to correctly align the light texture into the scene, one method I tried was to place the camera and the light at the exact same position. In theory, this would allow me to tinker with the UV position and scale, and see when the shadow projection and scene were in sync:

^ This is the light and the camera placed and viewing the scene from the exact same position, both are rotating around the scene together in sync. Looks cool Unfortunately, it didn't prove to be as useful as I had thought so I went back to separate locations.

Also, I found out that you cannot make your own variables in GLSL with a gl_* prefix. I tried naming a variable gl_Position_from_light and got this wonderful work of bow tie art:

and an error message that read ERROR: 0:13: Identifier name 'gl_Position_from_light' cannot start with 'gl_'

Anyway, that's all in the past.

---

This is where we are now. As you can see by the end of the video, we're so close!

Ahgh! So close you can almost taste it!

If you look closely at how the shadows are distorting, you can see that all the shadows seem to be bending inward towards the back, rather than outward. I think the reason is because I am using a perspective projection for the light, when I should be using an orthographic projection. It's as if the shadows at the center are OK, but further on the edge of the camera, they seem to bend in and shrink towards the back, like what would happen in a perspective projection.

I always assumed it was the compiler that generated the printf warnings. In that case it's just a matter of looking at the arguments of a printf() call--since the compiler already knows how to read the grammar--and parsing the format string. I would assume it's similar to how JS treats eval() differently depending on whether it's actually called as "eval" versus through an alias.

I dunno, if you're simulating nearby a point light, then a projective transformation makes sense. If you're simulating a far away light, then orthographic would be fine.

A perspective transform should work. In the tutorial, it uses a ortho transform, but there is another later section that says if you want to use a perspective transform then (...) and I didn't read that part. So, I dove into trying to fix it by switching back to ortho and it worked.

Sort of.

Part 1: Getting to the Orthographic Projection

It took awhile to get the ortho transform in place, since you can't just simply swap out al_perspective_transform with al_orthographic_transform. Here's what it looked like when I just swapped them out:

I ended up using the exact same ortho projection for the light and the scene, but from different viewing angles. That way I wouldn't have to worry about possible inconsistencies when merging the two projections for a shadow.

Ok, here's the interesting part. Notice that in the upper right corner (that's the light's view depth map) that the entire scene is black? This happened when I switched to ortho mode.

Something new is up with the depth z-values, so I tried a bunch of different things to see what I could get out of the pixel data. I tried curving the brightness of the colors in a bunch of different ways...

Well that's kinda strange. Previously, I was only using the color.a component, since the z-value for the pixel is stored in there (e.g. rgba(color.a, color.a, color.a, 1.0) ). Why now, would the green value just produce a simple gradient? So I investigated further and drew the image with proper colors rgba(color.r, color.g, color.b, 1.0):

Strange again, I'm not sure what's going on in this picture... but... if you look reeeeeealy closely, you can see some very faint shapes in the RGBA render. Very very faint, and they appear to be in the blue part of the image.

It turns out, when using an orthographic projection, depth values are stored in the 3rd color component - blue. Instead of RGBA (or XYZD), it's RGB (XYD). It makes sense; there's no need to transform a z value once it's in orthographic projection. The only coordinates you would need are x, y, and depth. So here's the light projection drawn using only the 3rd color component rgba(color.b, color.b, color.b, 1.0).

When everything is lined up there's really bad "shadow acne" but who cares!! It works!!!

Part 2: Getting Rid of the Noise

The hard part is over, from this point on it's a battle of filtering out shadow noise, and I ended up using a solution of my own (not mentioned in the tutorial).

Quote:

Will you be able to do this [en.wikipedia.org] in real time?

Funny you mentioned that actually. As I was trying to figure out shadows, it was a bit difficult to see what was going on with the checker texture (because of that exact "checker shadow illusion") so I swapped out with a grass texture.

By filtering out for the "shadow acne" noise, at best I was able to get it to look like this:

If you look closely, the worst-case-scenario-stripes-pattern is isolated to geometry that is facing away from the light, so to catch this case I ended up using a combination of plain-old-school shading combined with the casted shadows.

Here's the scene rendered with plain-old-school shading. This uses the light's point as the source and does not have a falloff for distance. Essentially, a plane is brighter when it's facing the light, and darker as it turns away: