Octree thoughts: divide surfaces?
Author
I use an octree for object culling of a large outdoor scenery.
The problem with octrees is that I
1) either have to divide surfaces that intersect many cubelets, or
2) if I don''t divide them I must keep track of which surfaces I already have rendered since one surface is stored in many cubelets.
This problem is major for areas where small surfaces (small cubelets) lie close to large surfaces.
Both ways don''t seem to be acceptable.
1) leads to a much higher memory usage and slows down performance due to many fragmented surfaces. Fragmented surfaces are ugly to deal with and hard to light correctly.
2) forces me to keep some sorted lists around that must be searched for already rendered surfaces, will take too long.
How did you solve this?
- thomas
I''m not into this kind of problems, but as I see it you could make a wrapper of the surface and pack a bool in it, marking if the surface has been drawn or not. In each cubelet you then have a pointer to the surface/bool package and can quickly determine to draw or not. This will neither have great memory nor processor requirements.
/Gustav
/Gustav
a solution sometimes used for moving objects, called a "Loose Octree", might be appropriate. you can find info via google search. the basic idea is that the smallest-level nodes are 2x the size of your largest atomic object, and the nodes overlap s.t. every element is always in 1 node and you don''t have to split things. thus, for moving objects, you avoid the "split to multiple nodes" or "attach to multiple nodes" that a usual octree requires.
Author
Thanks for your help.
Gustav was right, I just need to kee a flag in my surfaces if they were already drawn or not. The flag and its resetting is no problem since I sort my surfaces anyway to minimize rendering state changes etc. The flag will have no performance issues and the multiple pointers of different cubelets to my surfaces are acceptable.
Thanks!
- thomas
Gustav was right, I just need to kee a flag in my surfaces if they were already drawn or not. The flag and its resetting is no problem since I sort my surfaces anyway to minimize rendering state changes etc. The flag will have no performance issues and the multiple pointers of different cubelets to my surfaces are acceptable.
Thanks!
- thomas
The problem with a flag is that, once your scene will be rendered, you''ll have to reset this flag for the next frame.
The usual solution to this problem is to keep track of a frame counter in each primitive, to store the last frame ID the primitive was rendered.
Actually, when you begin a new frame, you increase the frame ID. When you render a primitive, you check its frame ID. If it equals the current frame ID, it means the primitive was already rendered in this frame. If not, you render it and update its frame ID.
Hope that helps,
Y.
The usual solution to this problem is to keep track of a frame counter in each primitive, to store the last frame ID the primitive was rendered.
Actually, when you begin a new frame, you increase the frame ID. When you render a primitive, you check its frame ID. If it equals the current frame ID, it means the primitive was already rendered in this frame. If not, you render it and update its frame ID.
Hope that helps,
Y.
Author
The flag reset is no problem since I (and I thought you too) have the steps:
1) walk through octree and see which surfaces are to be rendered
2) collect these surfaces to be rendered in rendering pipelines (solid materials, transparent ones)
3) Sort these pipelines to minimize state changes, Shader changes, and to reuse vertex buffer data that just is to be rendered with a different translation matrix
4) render the pipelines (first solid, then transparent, finally particles if not already covered by transparent pipeline)
Step4 allows to reset the has-been-rendered-flag easily since I here have my visible surfaces together.
Thanks,
- thomas
1) walk through octree and see which surfaces are to be rendered
2) collect these surfaces to be rendered in rendering pipelines (solid materials, transparent ones)
3) Sort these pipelines to minimize state changes, Shader changes, and to reuse vertex buffer data that just is to be rendered with a different translation matrix
4) render the pipelines (first solid, then transparent, finally particles if not already covered by transparent pipeline)
Step4 allows to reset the has-been-rendered-flag easily since I here have my visible surfaces together.
Thanks,
- thomas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
