Beamtree using ROAM's patches?
I''m still only getting the hang of 3D (I''ve only first looked at 3D less that 2 weeks ago).
I as with most of us want an expansive world with CLOD and as I''m quite new to 3d I''m sorting through piles of documents. I was wondering if anyone who has created an engine would like to comment on the following occlusion culling technique.
In the examples of ROAM I''ve seen so far it used patches as the heighest level polygon container. What In was thinking was to use the bounding box of these patches in a beamtree occlusion method. I don''t know if this kind of thing is generally done but combining the tesselation and occlusion algorithms seem like a good way of efficiently using the structures at hand and not tesselating parts of the landscape that are occluded.
Now for some strange questions. What is\are:
c-buffer
z-buffer
s-buffer
...and why is clipping important if you''ve already culled?
Thanks
gimp
PS : Let me know if there is anything else I should read before continuing down this path
Let''s assume you are on the ground and there is a sharp mountain ridge in front of you. Behind that mountain ridge is another.
If the further mountain ridge is obscured by the front ridge, we don''t want to tesselate it. Your idea sounds great.
But make sure you use the original height field data to test if the further mountain ridge is obscured. Because the current ROAM tesselation for the frame in question might not be the same as the height field data.
However, if ROAM is implemented properly, the front mountain ridge should be tesselated to almost full resolution because the error metric encourages tesselation at ridges viewed head on.
If the further mountain ridge is obscured by the front ridge, we don''t want to tesselate it. Your idea sounds great.
But make sure you use the original height field data to test if the further mountain ridge is obscured. Because the current ROAM tesselation for the frame in question might not be the same as the height field data.
However, if ROAM is implemented properly, the front mountain ridge should be tesselated to almost full resolution because the error metric encourages tesselation at ridges viewed head on.
this summer I''ve been working under Mark Duchaineau at LLNL on a visibility algorithm for multires geometry (ROAM in particular, and for arbitrary ROAM geometry, not just terrain). the more you understand the problem, the more complicated it gets. we have, however, come up with a nice solution. I can''t tell you about it yet, but we''ll probably write a paper this year. it''ll also then be implimented in an open source complete ROAM package (including a lot of new stuff which has been researched by others but not yet published, to really kick ROAM into high gear), which I may release this fall or in 2001. sorry that i cant yet tell you how it works, but it''ll be out sometime. it''s not a problem that i''d recommend you attack if you aren''t extremely familiar with ROAM (that is to say, far beyond the original paper) and advanced visibility algorithms.
if you''re only doing terrain, then something simple like quadtree-based visibility to let you not allocate tri''s to invisible areas may work well enough for you. good luck,
Lucas Ackerman
ackerman@wpi.edu
ackerman7@llnl.gov
if you''re only doing terrain, then something simple like quadtree-based visibility to let you not allocate tri''s to invisible areas may work well enough for you. good luck,
Lucas Ackerman
ackerman@wpi.edu
ackerman7@llnl.gov
guess this forum doesn''t refresh messages (or update # of replies) unless you''re registered, so I figured I might as well. cheers.
-Lucas
-Lucas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement