[2.1] How to build a quad tree?

[mrmclovin]

So I wanna build a quad tree terrain/grid which has different LOD.

It has come to my understanding that in Ogre 2.1, using the shipped Hlms implementation, Renderables cannot be used to hold world transform. Instead this is available inside the MovableObject. My plan was to have one MovableObject and several Renderables exposing at various LODs. But in 2.1, I'm not sure how to do it anymore, but I came up with this idea:

Terminology:
quad = a quadrant in the quadtree.
MO = MovableObject

The idea is:

• - Have one MO per quad
  - Each MO has a Renderable for each LOD

With this solution, I can see that I only need 5 MO's (1 root + 4 quadrants) and I'm not sure this is even a quad tree anymore

Any ideas or suggestions on how to design it?

[dark_sylinc]

Well coincidentally, there is a Terrain tutorial sample I've been working working from which you could heavily borrow ideas. I've been working on it on and off (more off than on...), so it's been taking forever to finish.

This tutorial Terrain uses one MovableObject, and multiple Renderables (one per chunk); and a custom Hlms implementation based from HlmsPbs to let each Renderable have its own transform (and actually, I send 2 Vector3, one for position, and one for scale).

If you want, I can upload what I have (it's a work in progress) to give you some ideas, or you can wait until it's finished and pushed to the repo.

[mrmclovin]

I'd love to see your WIP if you want to share it!

So for you, it would also make sense to use renderables under one movable object? Otherwise one would have to use multiple MO attached to multiple scene nodes and hide/show them, right?

[dark_sylinc]

Exactly, with MOs you would use one SceneNode as root, and 4 children SceneNodes per quadtree-node.

The advantage is that Ogre will perform frustum culling of each MO using SIMD, cache friendly systems, and multithreaded.

However it also means it has to update the SceneNodes (unless you keep them as SCENE_STATIC) and the MOs' AABBs (unless you keep the MOs as SCENE_STATIC) and memory consumption will be higher (though may be negligible if the amount of quad tree nodes is not super high).

While a custom-tailored Hlms system for (i.e.) 20 Renderables and 1 MovableObject will not benefit from SIMD, cache friendly, multithreaded frustum culling; you usually can make a lot of assumptions Ogre can't. Also I doubt 20 Renderables will impact performance. Ogre's super optimized frustum culling is designed to work on literally hundreds of thousands of MovableObjects; and even the worst possible solution you can come up with for culling 20 Renderables can't be so slow it becomes a problem

It depends on what you need/want to do.

[dark_sylinc]

Here's the Terrain patch: http://www.mediafire.com/download/3wi3b ... Terrain.7z
Hopefully I didn't miss to include anything. Drop this in your Ogre repository, rerun CMake, there should be a Tutorial_Terrain sample to run.

Edit: Also apply this. I forgot I modified OgreMain to support Vertex-buffer-less VAOs.

Notes:

• I'm not done with the Hlms. It's based off from the PBS one; but I want to share/reuse the code as much from the original version (right now it's a modified copy-paste with no textures working).
• Only GLSL works at the moment.
• The HlmsTerra implementation assumes its materials are only applied to a Terra MovableObject. Trying to apply them to a different MovableObject will result in a crash. While Hlms implementations can be made generic and modular, in this particular case we specifically want to exploit these systems knowing each other.
• The highlight of this sample is that it doesn't use vertex nor index buffers at all. The patch of vertices is automatically generated using bit-logic magic from gl_VertexID in the vertex shader. Each Renderable is a terrain patch, and on every update() call, mRenderables is filled with the patches we need to render.

[mrmclovin]

Thank you so much. I got everything to build. I will dive into this the next coming weeks.

My project is about seamless planet rendering from space down to standing on the soil. I did a prototype in 1.9 where I used multiple renderables to represent each chunk. That's why I have that mindset

[SolarPortal]

@dark_sylinc, just a question: have you managed to work on the Terra terrain code you posted anymore as i am excited to see this

I have downloaded it to check, have the demo compiling and from the code, it seems a great way of handling a new terrain system and love the way the info is passed to shaders now for hlms.
You mentioned it works on your PC, so i wonder if its something related to my card. I have a GTX 560ti and i receive these errors from the vertex shader:

Code: Select all

0(114) : error C7011: implicit cast from "int" to "uint"
0(120) : error C7011: implicit cast from "ivec2" to "uvec2"
12:06:23: OGRE EXCEPTION(3:RenderingAPIException): Vertex Program 3758096384VertexShader_vs failed to compile. See compile log above for details. in GLSLShader::compile at E:\00_Skyline Integrations\Ogre3D SDK\Source\v2-1\RenderSystems\GL3Plus\src\GLSL\OgreGLSLShader.cpp (line 297)

vertexShader_vs.glsl for Terra

I can remove the top error by placing a uint around gl_VertexID on this line:

Code: Select all

uVertexPos.y += gl_VertexID / cellData.numVertsPerLine.x;

like you did on a previous line.

The other error is on this line:

Code: Select all

uVertexPos = ivec2( uvec2(uVertexPos) << lodLevel );

i know this is a dirty hack, but i placed a uvec2 around the ivec2 and it compiled and moved onto the Fragment program which also had errors.

pixelShader_vs.glsl for Terra
This then throws an error like:

Code: Select all

12:32:14: GLSL compile log: 3758096384PixelShader_ps
0(280) : error C7563: assignment to uniform material
12:32:14: OGRE EXCEPTION(3:RenderingAPIException): Fragment Program 3758096384PixelShader_ps failed to compile. See compile log above for details. in GLSLShader::compile at E:\00_Skyline Integrations\Ogre3D SDK\Source\v2-1\RenderSystems\GL3Plus\src\GLSL\OgreGLSLShader.cpp (line 297)

and i haven't been able to get around this error.

Any ideas or a full solution?