Multiple IMeshSceneNodes vs *??

[hitachihex]

Been at this for a few days now, and it's kind of getting on my nerves

So I figured my last resort before I use a method I don't want to use was to ask here.

To the point, I'm (with a friend) making a minecraft clone (I've been doing the client, he's doing the server ) and I decided to use Irrlicht as the graphics engine.

My problem is only one problem - creating the terrain.
It seemed simple enough, sure, cubes. Lots of cubes.

Then came the realization that lots of cubes = lots of simultaneous rendering.

I have tried to use bitplanes MeshBatcher to remedify the problem - only rendering one mesh scene node - as opposed to multiple.

It seems both of these (regardless) achieve the same effect

My current method would be iterating through dimensions, and creating new mesh scene nodes with SceneManager->addMeshSceneNode(...)

psuedoish:

Code: Select all

for(int i = 0; i < dims.X;  i++)
{
     for(int j = 0; j < dims.Y; j++)  
    {
         for(int k = 0; k < dims.Z; k++)
         {
                 sceneNodePtr = smgr->addMeshSceneNode( meshOfSimpleCubeInObjFormat );
                 // set position, etc
         }
    }
}

Along the general lines of this is what's being done, and it's not working very well (performance hit out the ***)

I was suggested a custom scene node - but I saw no benefit in this if the scene node still had this many meshes to render.

(And if it weren't to use this many meshes, would the suggestion have been to use a huge array of vertices , and calculations ? ... )

My only other option (while awaiting advice from these forums) is to only render when required - setting my cameras far value does not achieve wanted results because of the sheer amount of cubes on most maps.

If the question was unclear ( vague, perhaps ) my question is:

Is there any way possible to maintain a solid framerate without having to render only when required - regarding as many as 1024*1024*1024 cubes.

[hybrid]

Since this would mean about 8 billion vertices - no, that's not possible. However, if you only want to draw a fraction of them actually, you should use the batch version. Put all geometry into one or just a few mesh buffers and render them. If you still need more performance, try to arrange the geometry into zones and either hope for a good frustum culling or use an octree/quadtree based render optimization.
BTW: Are you trying for voxel rendering? You need some clever algorithms to get this to work. Instancing would probably be required, which is not available in plain Irrlicht.

[hitachihex]

Since this would mean about 8 billion vertices - no, that's not possible. However, if you only want to draw a fraction of them actually, you should use the batch version. Put all geometry into one or just a few mesh buffers and render them. If you still need more performance, try to arrange the geometry into zones and either hope for a good frustum culling or use an octree/quadtree based render optimization.
BTW: Are you trying for voxel rendering? You need some clever algorithms to get this to work. Instancing would probably be required, which is not available in plain Irrlicht.

I see, so if I wanted to effectively mimic Minecrafts terrain system - I would need to do voxel rendering?

I wasn't aware of how it rendered it's terrain specifically - I just knew they were cubes. (Somehow)

Would voxel rendering enable me to render the terrain instantaneously without a major performance hit - or would it be combined with culling?

And if the answer to the above question is yes - do you have any good links on this subject?

[Nox]

Hmm would be an octree perfect for this situation? And what about instancing?