So I'm creating a game, and I've encountered a bit of a limit with the drawing by Irrlicht considerably slowing down at a point.
The game is essentially just a world with a whole lot of boxes in it, similar to minecraft if you've played that game.
At around about ~10,000 boxes, it starts getting really slow. Intuitively I would expect to be able to do better- assuming 12 polygons per cube, thats a total count of only 120,000 polygons, which is quite low compared to what a modern computer should be able to handle (Judging against modern games). Therefore I'm guessing I must be doing something wrong or there are some optimizations I should be able to do.
The one obvious thing I found was camera->setFarValue() which limits the things shown to those in the immediate vicinity of the camera, but I think as a rough guide I'd expect an engine to be able to handle 120,000 polygons on screen, so the far value should be the last thing I change when I can't do anything else.
I thought maybe the textures are a problem (like if you have a reasonably detailed texture for each side of each box, compared to a "standard" polygon in a game having not much detail), so I disabled them and it doesn't run much faster.
I am using EDT_DIRECT3D9 as the driver, doesn't help changing drivers (although openGL is quite a bit slower). Is there anyway to check that it is using hardware rendering and not just doing it in software on the CPU? Do I need to enable this somehow?
I have profiled my code, so I'm sure it's the Irrlicht draw that is slow. The compuer has a Quad core CPU, nVidia 9800GT graphics card. Any help or pointers would be appreciated.
Basic Optimizations?
Re: Basic Optimizations?
The only thing I know is mesh batching, and maybe also instancing, tough I don't know if thats going to work in your situation.
Theres a minecraft clone in the forums you should go and find it I'm pretty sure its opensource, so you could look how he did it.
Theres a minecraft clone in the forums you should go and find it I'm pretty sure its opensource, so you could look how he did it.
Working on game: Marrbles (Currently stopped).
Yep you need to batch thinks.
It is significantly faster if you draw 120,000 polygons at once than drawing 12 polygons 10,000 times.
Iirc there is a BatchSceneNode in the forum that you could take a look at.
It is significantly faster if you draw 120,000 polygons at once than drawing 12 polygons 10,000 times.
Iirc there is a BatchSceneNode in the forum that you could take a look at.
Software documentation is like sex. If it's good you want more. If it's bad it's better than nothing.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Yeah, the problem is that by using a high number of scene nodes, you urge Irrlicht to prepare each single cube separately. This is a high overhead on the CPU, which reduces geometry transfer to the GPU and rendering to very few items per second.
Batching means that you put many cubes into one scene node, which are then rendered at the same time. You don't even have to reduce the number of vertices or indices you render, it's just by the larger geometry sets that rendering can cope with far more objects then.
Batching means that you put many cubes into one scene node, which are then rendered at the same time. You don't even have to reduce the number of vertices or indices you render, it's just by the larger geometry sets that rendering can cope with far more objects then.