[osg-users] OpenSceneGraph - voxel/terrain rendering

[Pete Black]

Hi,

I have been working on a minecraft world viewer for a while, and most of my work has been done in Ogre3D, as this library is what I am most familiar with.

However, it is pretty clear that Ogre just can't go fast enough with my specific use case - it sets so much redundant state per batch that a large number of terrain tiles/chunks slow it to a crawl, and it has no straightforward way to create/update a smaller number of terrain chunks that can be run from a separate thread, which means a small number of large batches introduce long rendering stalls.

I am considering simply writing a renderer in raw openGL, but i do like the convenience of a slightly higher-level interface, especially when it comes to integrating features like adanced lighting/shadows, physics and animated characters on top of my terrain.

How suitable will OpenSceneGraph be for this kind of task? - i would have up to 5 million triangles visible at once (though a large number of these will be overdrawn) , and this dataset could be split into arbitrary-sized chunks, to optimise batch size. The triangles are textured with a single 'atlas' texture, and the vertices are specified in their final global coordinate locations, so no transforms are needed for each chunk. I pretty much have CPU to burn for state-sorting and culling.

Basically, does OSG have features for:

a) updating OpenGL buffers/arrays in a separate thread
b) optimised rendering by eliminating unnecessary state changes, compared to something like Ogre3d


Thank you!

Cheers,
Pete

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47573#47573





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Chris Hanson]

  Are you using DrawInstanced?

--

Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/

Training • Consulting • Contracting

3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL

Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android

[Jason Daly]

On 05/06/2012 02:38 AM, Pete Black wrote:
> How suitable will OpenSceneGraph be for this kind of task? - i would have up to 5 million triangles visible at once (though a large number of these will be overdrawn) , and this dataset could be split into arbitrary-sized chunks, to optimise batch size. The triangles are textured with a single 'atlas' texture, and the vertices are specified in their final global coordinate locations, so no transforms are needed for each chunk. I pretty much have CPU to burn for state-sorting and culling.

I'd say it would at least be worth a look. If you organize your scene
into an octree, you could minimize the section of the scene hierarchy
that would change from frame to frame, which would keep update and cull
traversals manageable.

> Basically, does OSG have features for:
>
> a) updating OpenGL buffers/arrays in a separate thread

Yes, although I'm not sure how well your particular use case will work
here. OSG requires you to specify which sections of the scene are
dynamic and which are static. The Update/Cull thread(s) then traverse
the dynamic objects in the scene while the Draw thread waits. Once all
the dynamic objects have been traversed, the Draw thread begins doing
its work.

In your case, you'll probably be marking almost all of the scene
dynamic, so I'm not sure how much speedup you'll get from the
multithreading.

> b) optimised rendering by eliminating unnecessary state changes, compared to something like Ogre3d

Yes. This is historically where OSG gets most of its speedup. OSG
employs state sorting and lazy state updating in the draw dispatch. I'm
guessing that with something like MineCraft, you'll have a lot of
geometry, but a relatively small number of state sets. OSG would be
perfect for this.

--"J"