fitting Geomipmapping into my existing tree system

Started by
1 comment, last by ic0de 9 years, 4 months ago

In my OpenGL based renderer I organize all the scenery in my world into a BVH tree which allows me to efficiently cull objects outside of the frustum. The leaves of the BVH tree are a data structure that I called a chunk, a chunk is simply a bunch of vertex data that is rendered using one draw call. The other day I added a loader for heightmaps and that was fairly straightforward, it generated a bunch of triangle tiles and offset the vertices by the heightmap value then the resulting data was stored in one chunk. Obviously drawing all the vertices in the heightmap in one go results in terrible performance. So I looked into geomipmapping which seems to fit my needs, the problem is the fact that geomipmapping requires I split up my chunks obviously but I am unsure how I should organize this from a Software architecture point of view. Should I totally separate terrain from the rest of the world and keep it in a separate tree? or should I just throw heightmap chunks into the regular BVH tree probably deriving a class heightmapChunk which adds LoD code? should I nest a quad tree inside my BVH as a node, in that case the whole quadtree is analogous to one regular chunk?

Advertisement

I always run world layer stuff (terrain, BSP, portals, whatever) as a completely separate block of rendering than the BVH for small in-world objects.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

Do you put the heightmap in the same data structure as the rest of the world scenery (buildings etc.) though?

This topic is closed to new replies.

Advertisement