How to make Model Batch?

[samleo]

Hi,
After long time I return from source code of hell... So, may someone give me a example of render a model using only one model or scene node? I searched on internet but I'm not having success. I need just one simple example, because I don't have any idea of how to do this in irrlicht. Someone in this forum tell to me that model batch was what I need to "draw" many times with one scene node.
Thanks

[Cube_]

irrlicht's hello world tutorial can be condensed down

but something like

Code: Select all

 
//pretty much the minimal case for rendering one mesh/scene node
IAnimatedMesh* mesh = smgr->getMesh("path/to/model.obj");
IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode(mesh);
while(device->run())
{
        driver->beginScene(true, true, video::SColor(255, 113, 113, 133));
 
        smgr->drawAll();
        device->getGUIEnvironment()->drawAll();
 
        driver->endScene();
}

As for batching them - that's not something I'm commenting on as I use other optimization methods

[CuteAlien]

There are 2 implementations on irrExt: https://sourceforge.net/p/irrext/code/H ... ene/IMesh/
CBatchingMesh and CMeshCombiner both allow to merge meshes. But if this is the correct thing to do in your situations depends on what exactly you are trying to do. This can speed up rendering, but it basically makes one big static scene. Often if you need that you can do it as well in your modeling tool.

[samleo]

Ok people, I just need make a big map of static cubes for a game. I think this is sufficient.
Thank you two again.

[CuteAlien]

If you talk about Minecraft style ... search the forum a little bit for it. There have been a few people working on that already and I think there is some lib which can help optimizing that stuff. Using batching mesh is not optimal for that kind of games as the cubes there have to change all the time (which would need to recalculate the batching/combining of the meshes constantly which would be rather slow).

[Cube_]

batching is not a good solution for cube terrain, especially not if you intend for it to be static.

You might want to look into greedy meshing.

However, if you're just using a lot of static cubes (a few thousand at most methinks) that aren't connected then it's an ok solution

[samleo]

@CuteAlien
In fact, I'm making a game like super mario bros, just for learn irrlicht. So, I have a tile map, that will static, but how did you say, batching it's not a good solution. Ok, I'll search on forum later.

@aaammmsterdddam
Hum, even if I use batching, for my mario like, maybe is not bad, I will try and search about greedy meshing.

Thank you for all.

[Cube_]

for a mario like?
Should be fine (assuming "2D" in that it'd be a fixed camera sidescroller), minecraft-likes have tens of thousands or hundreds of thousands of blocks on screen which is why batching doesn't work, for a mario like we're looking at a couple hundred rendered, maybe a thousand or two total per level.

Sounds like a solid plan.

[CuteAlien]

Is that the mario with a 3d world or a side-scroller?

[samleo]

Is that the mario with a 3d world or a side-scroller?

Sorry for the delay. So, you imagine a array 2d of tiles, then each tile is a 3d block, it's the simplest map, this is for I learn about 3d with irrlicht. I came from 2d world with SDL2 and I'm trying to learn about 3d game dev.
OFF:
Which book can I master the Irrlicht? Is there one?

[CuteAlien]

If you can see the whole world at once sometimes then a batching mesh will be better. Maybe in combination with an octree (depends on level layout etc). If you can't see the whole world (like in old mario games where always only see a small part of the world) then likely it's better to have cubes on their own because most of the world can be culled by Irricht before drawing.

I would do a quick calculation first how many cubes you might need. For example go over a mario-level and simply count the cubes in there. Then think about how much larger your levels will be at max. Then draw that many cubes and check if speed is something you have to worry about. A simple test can for example look like this: https://bitbucket.org/mzeilfelder/irr-p ... ew-default
(there I use not cubes but another small mesh, but with such tiny mesh-sizes there's not much of difference). Or https://bitbucket.org/mzeilfelder/irr-p ... ew-default where I try to optimize it a little bit.

There is one book about Irrlicht (to my knowledge the only one): https://www.amazon.com/Irrlicht-Realtim ... 520&sr=8-1
Unfortunately it doesn't cover such topics, so check Table of Contents if it sounds like a book for you.

[samleo]

@CuteAlien
I see, just for simplicity I'll use cubes for tiles because it's a few cubes.
CuteAlien, I have more one question: how should I use one scene node per cube? For example, for a map of 256x64, it's a good strategy use one scene node per cube? Sorry, I always think that I must use one scene node per cube, and in this way the program uses many memory. Is there a more optimised way? Is possible use one mesh for all tiles?


Thanks for the link of the book, I will read the table of contents.

[samleo]

@CuteAlien, ops, your example is good, I'll study it. Thank you

[CuteAlien]

I'd start with cubes. If it works - it's the simplest. If it's too slow - then you can start profiling with something concrete.