Jump to content
  • Advertisement
Sign in to follow this  
DoomAngel

Intersection Between Frustom and Terrain

This topic is 3780 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

Hi all.. how can I do intersection between terrain and frustom. I want to perform it in a fast and approximate way... any help will be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
You could divide your map geometry using a quad-tree/oc-tee/AABB-tree. Then, you recursively traverse the tree. At every node you check its bounding volume against the view-frustum, three cases may occure:

Fully outside the frustum: Skip this node and all its children
Fully inside the frustum: Render this node fully, without further frustum culling
Partially inside the frustum: Traverse the children of this node further.

This method has no LOD or occlusions culling, but in my experience, can be a practical solution if your line-of-sight is not to far such as a lot of modern RTS games. For more complex methods using LOD, you should look at the articles in the gamedev archive.

Share this post


Link to post
Share on other sites
Okay..Thanks dietepiet, but there is some mis understanding...
I do that intersection in order to get the actual Terrain mesh intersected with the frustom (I won't to determine which patch are intersected with the frustom), and this is because I want to determine the shadowed area from the terrain which is intersected with the approximate shadow volume.

It's not for determinig the visible terrain patch (which ofcorse I've done it before).

Share this post


Link to post
Share on other sites
Hmm, I'm probably not fully understand you, but as far as I can see, there is no principal difference between determining which part of the terrain lies within the view-frustum or in a shadow-volume.

I use this technique in my engine to determine which parts of the terrain are rendered with which dynamic lights, so instead of culling the terrain against the view frustum, I use the bounding volumes for the lights. I imagine this is somewhat similar to culling against shadow volumes.

Share this post


Link to post
Share on other sites
Okay..
but I need that to render the shadowmap casted by objects..
and so I have to determine the mesh which is affected by the shadow..
my terrain is patch based each patch is 64m*64m size, so I have many trees and objects in side it..and all objects cast shadowmaps, so I haven't to rerender the hole patch in order to render each object's shadowmap.
so Ihave to calc the actual terrain mesh which is affected by the shadow...

Share this post


Link to post
Share on other sites
I assume you can select the patches for each tree, so if I understand you right, you want to determine the triangles within one patch, needed for each shadow-map.
Two methods pop into my mind (I have used them both, in different situations).
I describe them with vertex and index buffers, as DirectX and OpenGL both support them.

1'st method: You subdivide the triangles of each patch using quad-trees or something like that. You use a dynamic index buffer. You traverse the quad-tree for each shadow-volume/patch pair, and store the indices for all triangles inside the shadow-volume in the dynamic index buffer. Then you render this selected part of the map using the dynamicly selected indices and the static vertex data for the patch.

2'end method: You subdivide the triangles of each patch using kd-trees (or any
binary space partition tree for that matter). You rearrange your index data for each patch such that all indices belonging to triangles in a subtree of the tree are stored consecutive in your index buffer. So, indices for all triangles are rearranged as follows:

......1-12........
...../......\......
..../........\......
..1-6......7-12..
../..\......./...\..
1-3.4-6.7-9.10-12

The nice thing about this rearrangement is that, when a whole subtree is found to lie inside a shadow volume, you can render this subtree at once, with a single draw call. So, you recursively traverse the tree for each shadow volume. When a subtree is outside your volume, you prune the subtree. When it is fully inside (Or inside 'enough' according to some heuristic), you render the whole subtree as one. Otherwise (Partially inside), you traverse the tree further down.

The first method only needs one draw-call, but uses dynamic indices. The second method only uses static geometry, but probably needs more render calls. So which method has the best performance depends on your particular situation.

There are probably other an better methods around, but these methods worked fine for my engine. I hope this is of any use for your situation/

Share this post


Link to post
Share on other sites
oh...really thank you dietepiet..
I'll try the first way I think it's most suitable for me..
but I'm wondering...
shall it work even I have about 50 objects to calculate the shadowMap for them
and update the shadowed Terrain mesh too??
I just wondering, but any way..I'll try it..

and I'm asking.. can you help me how I can find a better ways to solve this situation?

thank you again dietepiet.

Share this post


Link to post
Share on other sites
If you have that many objects, each having its one shadow map rendered each frame, isn't it a better idea to use one big shadow map for the whole scene instead of one for each tree?? At least this is how its done in many games i think. Than you can just render the whole map with this one shadow map.

If you have very few tree's, calculating the shadow separately for each tree might increase performance, but if you have many tree's, parts of the map might get drawn quite a few times, so a single shadow map will probably give a much better performance.

Share this post


Link to post
Share on other sites
yes, I have many objects, but I will not calculate the shadowmap for each of them in one frame..I will use some trix like shadowmap update time, or something else..

and about that many games do the shadowm map for the hole scene..I think that many games do it for each object, cuz render the shadow map for the hole scene will reduce the shadowmap quality .. is it right??

any way..I'll think of your way and I'll try it..

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!