I seem to have a strange problem, if i load a cube exported from blender as .b3d and then clone it 1000 times in a grid, i get some serious slowdown. I know it is the 3d render because when stepping through it is the render3d that takes all the time.
I am using the OGL option but strangely enough the burning renderer seems to have a couple of FPS on this!
That is only 12000 polys by my count, so what can be the problem? Is it the number of active nodes or something?
Is there a node bottleneck?
This is draw calls problem. You can look at instancing (currently irrlicht doesn't support this feature) for solve this problem.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
What I can tell you from my personal experience is that 1000 objects per scene is LOT of objects to handle. In most games, there are severa huge objects for terrain and other background stuff, dozen (at most few hundreds) of game objects (like houses, players, vehicles, ...). But if you want more than 1000 objects, it's highly probable that you'll need some special optimizations fro transformations, visibility checks, state updates...
I can render one million textured instanced cubes at 26fps, but not with vanilla Irrlicht. See my post in the thread here:
http://irrlicht.sourceforge.net/phpBB2/ ... 8&start=19
Irrlicht is great for simple stuff and prototyping but you will hit issues as soon as you start to require more advanced stuff. It currently lacks hw instancing, flexible vertex formats, multi streams, solid PVS system, multithreading, DX10, DX11, depth buffer to texture recasting, etc.
But then again, you have all the source code to Irrlicht and its easy to extend. If you want something real bad then you could always add it yourself...
http://irrlicht.sourceforge.net/phpBB2/ ... 8&start=19
Irrlicht is great for simple stuff and prototyping but you will hit issues as soon as you start to require more advanced stuff. It currently lacks hw instancing, flexible vertex formats, multi streams, solid PVS system, multithreading, DX10, DX11, depth buffer to texture recasting, etc.
But then again, you have all the source code to Irrlicht and its easy to extend. If you want something real bad then you could always add it yourself...
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
Back on this after a slight break..
I need to use the out of the box irrlicht for my project (too many reasons to explain) What i want to do is to be able to load a load of meshes and hide them, then have them copy into view when in 'scope' and delete when not.
I have heard of meshbuffers but cannot seem to find out anything about them (using them that is
.
Is this possible and where should i be looking?
I need to use the out of the box irrlicht for my project (too many reasons to explain) What i want to do is to be able to load a load of meshes and hide them, then have them copy into view when in 'scope' and delete when not.
I have heard of meshbuffers but cannot seem to find out anything about them (using them that is
. Is this possible and where should i be looking?
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
If you will stay with cubes, you will have to use a mesh which you fill with all vertices that will be ever used. Via indices you can enable or disable certain parts of that mesh. The handling of the indices is up to you. You will have to map your cubes to the indices such that you can directly access the indices.
You can use the hardware mapping to make the vertices static (and keep them on the GPU all the time) and the indices dynamic. This will give an optimal data flow between CPU and GPU.
The only question is how you can reduce/remove the indices without having the array realloc all the time.
You can use the hardware mapping to make the vertices static (and keep them on the GPU all the time) and the indices dynamic. This will give an optimal data flow between CPU and GPU.
The only question is how you can reduce/remove the indices without having the array realloc all the time.
Unfortunately it is not just cubes.
What i am trying to do is make a built in level editing system like i made with B3D several years ago. On a level load it loads all the prefabs it needs into the scene (walls,stairs,pillars,entire room prefabs etc etc) and hides them from view.
Then as the map progresses these are copied to where they are needed or when they come in to range in the scene. This is done by means of a matrix like data structure. As they go out of range they are removed from the scene, but the originals always stay hidden at 0,0,0 until needed, or until the level is changed.
The reason this is possible in b3d is because they have a copyEntity command that can do a light copy of the mesh, an instance of it that can be effected by it's own transform matrix and surfaces which allows for local scale rotation and positioning, but still shares the verticies with the original mesh.
Any changes to the mesh (or any instance) at the vertex level will change all the copies. This makes for a superb dynamic system and is lightning fast in b3d so you can have effectively 10000s of insances (in fact the system becomes only limited by the speed and size of your data structures rather than anything to do with graphics - within reason of course
).
This is what i want to do in irrlicht, but as i said as soon as i hit only a few hundred copies it starts to grind.
What i am trying to do is make a built in level editing system like i made with B3D several years ago. On a level load it loads all the prefabs it needs into the scene (walls,stairs,pillars,entire room prefabs etc etc) and hides them from view.
Then as the map progresses these are copied to where they are needed or when they come in to range in the scene. This is done by means of a matrix like data structure. As they go out of range they are removed from the scene, but the originals always stay hidden at 0,0,0 until needed, or until the level is changed.
The reason this is possible in b3d is because they have a copyEntity command that can do a light copy of the mesh, an instance of it that can be effected by it's own transform matrix and surfaces which allows for local scale rotation and positioning, but still shares the verticies with the original mesh.
Any changes to the mesh (or any instance) at the vertex level will change all the copies. This makes for a superb dynamic system and is lightning fast in b3d so you can have effectively 10000s of insances (in fact the system becomes only limited by the speed and size of your data structures rather than anything to do with graphics - within reason of course
).This is what i want to do in irrlicht, but as i said as soon as i hit only a few hundred copies it starts to grind.
Try my batching mesh, it should be easy to make it work with a recent version of Irrlicht.
You can use it as part of a larger block manager, like this:
You can use it as part of a larger block manager, like this:
Yes but you have to use the special methods provided by the batching mesh, (setTransform, store use the lists of buffers that are returned when you add a child. not sure if I added remove methods) rather than just moving nodes around. It was made before we had hardware mesh buffers and 32-bit indices, so you may want to make it default to using both of those for performance reasons.
It was really just a proof of concept, it's proved to be a good starting point for a few people's projects.. expand on it as required!
It was really just a proof of concept, it's proved to be a good starting point for a few people's projects.. expand on it as required!