Real time shadow casting in a 2D isometric game

Question

I'm writing a small 2d isometric engine in C++ and I'm trying to implement real time shadow casting. I followed a simple approach described on this page and here is the result (light is located at the same position than the yellow cube):

The result is very nice but there are missing shadows on walls and on the top of cubes. Here is an example of how it should look like (I've draw expected shadows in green):

All the cubes drawn are simply made of 3 2D quads located at a X-Y position and with a Z depth (z = x + y). I use OpenGL with an orthographic matrix (glOrtho). Shadows are drawn using the stencil buffer.

I'm looking for resources or solutions that would help me complete this shadow casting implementation.

Thanks a lot!

Answer 1

For roof and walls, you may try to determine intersections between your wall segments and generated shadows regions. You need two pass rendering of your shadows. First one will do what you are doing today (in memory storage). Second pass will calculate intersections of roof and wall. Last stage is real rendering. DeadMG is wrong, you can do that.

Note: for roof you have to intersect shadow area and roof area.

Answer 2

Fundamentally, what you're looking for can't be done. You want to take a bunch of 2D objects and have them cast shadows as if they were 3D objects. If you want to have full 3D shadows, you need to have 3D objects.

Answer 3

Solution described is not full 3d as he doesn't need full 3d solution. It will look like but it is not. Creation of shadow casting must be considered as intersection between volume. What he needs is less complicated. Remember (if you have kown) dooms and dooms like rendering engine. All processing were done on two dimensions.

Answer 4

Given that you want this game to be small, what about just saying that the current shadow implementation is good enough?

I admit that I have not seen this in action, that is, I have not seen how disturbing or non-disturbing the shadow imperfections will be when this games is running live with dynamic objects and dynamic light sources but judging from your images, I'm very tempted to say "it's good enough, now focus on getting the game completed". If the current implementation happen to be small and execute fast and fixing what you perceive to be problems will turn the code big and slow, I think you are better of not worrying about those shadows.

I know, I know, suggesting "don't try to solve the problem" as a solution to a problem might be a bad practice. Still, I honestly want to say that it really is good as it is if you want a small footprint for your code.