#### Archived

This topic is now archived and is closed to further replies.

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

## Recommended Posts

1. When using a quadtree in a terrain engine, do you build the quadtree from the pixels in the heightmap or do you get their world positions and build the quadtree from them. 2. If you build it from the heightmap how do you implement frustum culling, do you have to find the camera position in the heightmap? I''m not a being lazy about this, I''ve read loads of the theory but I can''t seem to find much code so I can see how the theory is put into pratice?

##### Share on other sites
focus on 3d terrain programming

I beleive that''s the name of the book. It shows how to do a quadtree terrain and comes with example code. I think the explanation is pretty good and the pictures help. I think the book is pretty cheap, too. Something like \$20.

##### Share on other sites
you could do it either way.

building the data from the hightmap pixels would be quadtree as opposed to octree which would require 3d coords. for frustum culling, you would probably find culling the final 3d terrain coords eaiser as well as faster. just off the top of my head... using a 2d culling method seems kinda sticky when you want to look off center... not to complex.. but not exactly efficient no matter how you implement it.

Frustum culling doesn''t depend on your rendering algorithm (as long as frustum culling isn''t your only means of eleminating unseen geometry - which in the case of octrees it is (more or less =P ) ).Generally you take the result of your main rendering algorithm and do a frustum test against the resultant polygons. Furthurmore you generally do both simultaneiously. Octrees are built around the idea that you need to know what the camera can see to know what boxes are within view.
So you would take your camera attached to your screen'', extract the frustum planes, and hand them to your octree for rendering.

ne way.. hope this helps..
Andy

##### Share on other sites
quote:
Original post by skillfreak
Generally you take the result of your main rendering algorithm and do a frustum test against the resultant polygons.

maybe i just got that wrong, but are you suggesting to test polygons for visibility?

about the tree: it completely shouldnt matter what you use to build your tree, the only interesting part is what you store in your nodes and leaves. but i think thats the part you want to know ,-)

without saying its the best approach:
store all vertices in one big vertex buffer (or array if you dont like the extension). in your quadtree for every node store its aabb in world coords (for culling etc.), in the leaves also store a pointer to the index array for that part and the offset into the vertex buffer/array (or if you have the memory, store that for every node thats not exceeding the index limit, maybe with lower lod, but that depends on what you want to do with your terrain).

if you dont mind using vertex programs you might get away with just storing the height and calculate everything else on the fly, but i wouldnt do that except you have seriously large terrains and not enough memory for it. or short: as long as memory allows store your stuff the way you need it and can use it without a lot of extra work.

1. 1
2. 2
3. 3
Rutin
23
4. 4
5. 5
khawk
14

• 9
• 11
• 11
• 23
• 12
• ### Forum Statistics

• Total Topics
633654
• Total Posts
3013168
×