Jump to content
  • Advertisement
Sign in to follow this  
obyzouth

OpenGL Shadow Volumes and Mesh Representations

This topic is 2346 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have some questions that I can't find specific answers for. If anyone is willing to answer enough to point me in the right direction I would be incredibly thankful.

All of these questions are linked to the topic title, in case it doesn't at first appear so.
I have just begun to consider adding shadow volumes to my system, and I am attempting to make somewhat reasonable choices in data structures and/or implementation.
I am implementing the shadow volumes on the CPU rendering with openGL

1. For the most part, models in my system (moving about in the "world") have associated transformation matrices which draw them in the proper positions based on values such as position,rotations,etc. The coordinate positions of vertices stay the same in memory(usually around the origin). I am unsure of how to approach shadow volumes. Do I transform the lights position into the model space? If I did that then the volume would be generated in the model space, so I could just tranform the volume by the same matrices as the model? Is this a pretty standard way to do this?

2. Many silhouette extraction methods rely on building edge lists of all edges in the silhouette. This means building a dynamic array that you can add and delete entries from. It also requires comparing edges to prevent duplicate entries from neighboring polygons, which implies some sorting/searching O(lgN) algorithm to determine if there are duplicates.

My question is if the Half-Edge data structure is a general solution to this? This is my thinking.
-It is very easy to loop through all faces and to retrieve all the edges for a given face
-Half edge data structures can store face normals that are precalculated Up front, so doing cross products to find the normals is not necessary because the Face struct can store the normal (more space for less time)
-It would be easy to add a boolean value to the Edge struct to determine if the edge is currently in the silhouette. (as opposed to keeping a separate edge list)
-Rendering the volume would then require some mesh traversal, instead of having a nice list of edges, you would have to loop through the edge list to round them up. In either case you would still have to build the VBO's, this is just slightly longer.
This would amount to some O(c*n) algorithm(basically looping through the edge list a couple times) as opposed to many of the O(n*lgn) and (n*n) cpu implementations that exist.

3. Related to #2, what are the more popular ways to store polygonal meshes in game dev? I have been sticking to Face/Vertex and Half-Edge meshes.

Before I begin going down this path and putting lots of code into this, I just want to make sure I am not deviating too far from the industry path here.

Share this post


Link to post
Share on other sites
Advertisement

Before I begin going down this path and putting lots of code into this, I just want to make sure I am not deviating too far from the industry path here.

Well, the industry path is not using shadow volumes any more (as far as I know), the last game was Doom3 (+ games based on this engine), this was 2004. The current state of art for shadows are still shadow maps or one of its 100 variations. smile.png

Share this post


Link to post
Share on other sites
1) This sounds like a sensible approach to me.

2) There's no question mark here, I guess you're wondering about performance?
Traditional implementations are quite slow on the CPU yes, and do require tailored data structures.
A modern implementation can use the vertex-shader to brute-force this step, but it doubles your vertex/polygon counts (or a more modern version could use the geometry shader to do this without doubling of vertex counts).
As mentioned below, you can actually skip/simplify this step if your models are tessellated well enough.

3) Ideally, you don't have any CPU-side representations of your visual models at all -- they should only live on the GPU inside vertex/index buffers.
If you do have CPU-side representations, they should be customised to best match whatever their purpose is -- (so yes, a half-edge for use by shadow volume extrusion makes sense, but if not performing this task, you would not keep that data around).

Well, the industry path is not using shadow volumes any more (as far as I know), the last game was Doom3 (+ games based on this engine), this was 2004. The current state of art for shadows are still shadow maps or one of its 100 variations
It's definitely true that shadow maps are much more popular these days, but volumes are still in use. I'm shipping a current-gen console game in a few months time, which uses screen-space blurred shadow volumes, because they gave much better quality for much less cost compared to shadow-mapping the same scene (30 animated humans in the 1-100 metre range). As always, it depends on the situation and your mileage will vary wink.png
N.B. we actually skipped expensive silhouette extraction altogether, and simply move back-facing vertices along the light direction -- this doesn't give the correct shadow volumes (they're slightly smaller, and 'pop' slightly as the vertices/light rotate), but it's ridiculously cheap, and with high-poly models (such as characters) the artefacts aren't at all noticeable.

Share this post


Link to post
Share on other sites
Ashaman: I suppose this is why I had a hard time finding current implementation details. smile.png I was in fact scouring doom3 code before I posted the topic, as it was the only full implementation I could find.

Hodgman: This is the answer I expected and was hoping for. Not necessarily any standard, mostly custom solutions build around your individual needs. I won't feel guiltly about doing my own thing then, or trying something wild. biggrin.png

Thanks for the quick replies.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!