Bad performance - setHardwareMappingHint(EHM_STATIC)?

[Dragfang]

Hi, so I'm working on a mine-craft clone and I got the basics working pretty good, but when I start getting a lot of cubes my FPS drops a lot. I've searched a lot about it on these forums and I found setHardwareMappingHint(EHM_STATIC). I've tried to implement it but my FPS is still low with many cubes.

Code: Select all

IMeshSceneNode* node;
IAnimatedMesh* mesh;
ITriangleSelector* selector;

this->mesh = smgr->getMesh("media/cube_Grey.obj");

this->mesh->getMesh(0)->setHardwareMappingHint(EHM_STATIC);

	this->node = smgr->addOctreeSceneNode(this->mesh->getMesh(0));
	
	if (this->node)
	{
		this->node->setPosition(vector3df(50,500,50));
		this->selector = smgr->createOctreeTriangleSelector(this->mesh->getMesh(0), this->node, 128);
		this->node->setTriangleSelector(this->selector);
	}
	if(metaSelector)
		metaSelector->addTriangleSelector(this->selector);

Is this correctly done? If it is, what else can help reduce this FPS drop? I've implemented a function that creates 12.500 cubes randomly, and with that amount of cubes I get 6 fps.
If you want I can upload my program and you can try it for yourself.

[Radikalizm]

are these all separate cube scene nodes? if so, it's the huge amount of draw calls which is causing problems

[macron12388]

I've heard that you should not make each cube a scene node. You need to 'chunk' them altogether so there are less draw calls. There was already another thread like this, I think in project announcements?

EDIT: AH! I was ninjad!

[Radikalizm]

yeah, you'll need a batched mesh to work around this problem, but this will create some new problems since you're creating a minecraft clone

you'll need to make some distinction between cubes which are static and cubes which can be edited by the player at any given time and switch these in and out of your batch of cubes (that's how i would implement it anyway, never attempted it so i could be missing something here)

i think a lot of people see minecraft as a relatively simple game because of the simple graphics, but the underlying scene management is pretty complex

[Dragfang]

Thanks for the answers. Hmm, as it is right now I'm checking collision against other cubes and placement of new cubes depending on the position of the cube that I find collision against, would this still be possible to treat each seperate cube as a seperate position if I chunk them together?
As it is right now I draw a terrain from a heightmap that is flat and then the player can build from that, so I dont need any cubes that are not build/removable, atleast not now.
I might be able to chunk them together and calculate the position of new cubes depending on the position where I find collision against other cubes rather than finding the position based on the cube I collide against. I will give it a try thx.
Also, how do I go about "chunking" them together? If you could show me some code / link me to a guide or something that shows it it would be great!

[bitplane]

Look at CBatchingMesh in the code snippets forum, this will batch your meshes and also allow you to set transformations for each one. It might need a little work to make it compatible with the latest version of Irrlicht, for example it will need to set the hardware mapping settings, but it's a good start.

[Bate]

MeshCombiner

It takes care of pretty much everything.

[PolyVox]

It's a bit of a shameless plug, but a number of people are using my library to create Minecraft-style games. It basically handles the volume storage and mesh generation for a Minecraft-style cubic world. To my knowledge it has only been used with Ogre and raw OpenGL/Direct3D, but it's API independant so it would be interesting to see it work with Irrlicht as well