Too many vertices for 16bit index type
Too many vertices for 16bit index type
Hi
I have a scene with various 3d objects and a character, all is static, and it works. Now I have removed the static character and added an animated one.
Both the animated and the static characters look the same, I have opened them in irrEditor1.5 and loaded them both ok, though with the animated one, in the Message Log, it says it has Polycount:23734, while the static one it says it has Polycount:0.
When I try to open the animated one in the videogame, it says:
"Too many vertices for 16bit index type, render artifacts may occur."
The static model is .obj and the animated one is .x (one mesh).
And the model show up with the animations, but the mouse events don't work (its like someone is pressing the mouse buttons continuously), and sometimes the application shuts down randomly.
Does anybody know something about this? is there a way to use for instance 32bit index type then? The thing is that even before using the animated mesh, sometimes the application did strange things, and others it worked ok, even though the code was exactly the same (its like with the animated mesh loaded, it happens more often). Can some random errors happen due to too many vertices in the same scene?
thanks in advance for shedding any light to any of these questions.
DF
I have a scene with various 3d objects and a character, all is static, and it works. Now I have removed the static character and added an animated one.
Both the animated and the static characters look the same, I have opened them in irrEditor1.5 and loaded them both ok, though with the animated one, in the Message Log, it says it has Polycount:23734, while the static one it says it has Polycount:0.
When I try to open the animated one in the videogame, it says:
"Too many vertices for 16bit index type, render artifacts may occur."
The static model is .obj and the animated one is .x (one mesh).
And the model show up with the animations, but the mouse events don't work (its like someone is pressing the mouse buttons continuously), and sometimes the application shuts down randomly.
Does anybody know something about this? is there a way to use for instance 32bit index type then? The thing is that even before using the animated mesh, sometimes the application did strange things, and others it worked ok, even though the code was exactly the same (its like with the animated mesh loaded, it happens more often). Can some random errors happen due to too many vertices in the same scene?
thanks in advance for shedding any light to any of these questions.
DF
Well, hybrid did mention being able to switch to 32-bit indices, but I found nothing in the code to support this. So, yes, animated meshes are limited. But the limit is per mesh. Most figures are composed of multiple submeshes, like head, chest arms, etc. In fact, if you need to use different textures, you need to use different meshes. So, when you export the model, export the "groups" as well. I don't know if the .x format supports this, though. I guess you'll just have to try.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Well, there's no switch in the code which you can easily alter, but it's less than a few dozen code lineys to change and switch over to 32bit indices (for all skinned meshes then, though). However, this is a severe render burden, especially for mobile systems and other low-bandwidth systems. Moreover, even current gfx cards still work best with meshbuffers of a few hundred to low thousand vertices per buffer. So really, really, better optimize your gfx pipeline instead of fiddling with render pipeline changes.
I think it is a bit more. I believe you would have to change the OpenGL calls as well, and I don't know anything about DirectX (the evil empire). Anyway, not really necessary today. Though talking about a few thousand vertices and modern graphics cards is a bit like Bill Gates saying that no PC would ever need more than 640K of RAM! I'm trying to animate .obj files because I'm thinking that 100,000 vertices is the bare minimum. It's 2011 already - time to get a wriggle-on.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
No, the drivers are all capable of 32bit index handling. You just have to change the mesh preparation in the mesh loaders.
Once again, a mesh buffer with more than say 10k vertices will stall your render pipeline and lead to severe performance penalties. This holds for mesh *buffers*, a mesh can have arbitrarily many mesh buffers. and animating .obj files does not really make sense IMHO, as it's not an animated format.
Once again, a mesh buffer with more than say 10k vertices will stall your render pipeline and lead to severe performance penalties. This holds for mesh *buffers*, a mesh can have arbitrarily many mesh buffers. and animating .obj files does not really make sense IMHO, as it's not an animated format.
So glDrawElements (if that is what is used) has the correct type? OK.
I know OBJ files are not an animated mesh. But they are often animated But I am not a modeller, so I can choose my models how I like. And animating them is simply a matter of code....
I do wonder about your pipeline stalls. There seems to be a lot of interest in keeping the vertices on the GPU and skinning them there. So I don't know where the problem with vertex counts comes from. In general, of course, I know that Irrlicht would find it difficult, today.
I know OBJ files are not an animated mesh. But they are often animated But I am not a modeller, so I can choose my models how I like. And animating them is simply a matter of code....
I do wonder about your pipeline stalls. There seems to be a lot of interest in keeping the vertices on the GPU and skinning them there. So I don't know where the problem with vertex counts comes from. In general, of course, I know that Irrlicht would find it difficult, today.
Well, I loaded an OBJ mesh and animated it. Irrlicht says I have 56,857 triangles and the FPS is 10.
I switched to the Null renderer to see what the difference would be. I got 16 FPS.
I guess it doesn't mean anything, but if the the work done in Irrlicht and the work done interfacing to the card are additive, this would mean that the card is capable of 30 FPS.
I switched to the Null renderer to see what the difference would be. I got 16 FPS.
I guess it doesn't mean anything, but if the the work done in Irrlicht and the work done interfacing to the card are additive, this would mean that the card is capable of 30 FPS.
You don't have to trust my examples. I'm really not arguing *at* you. I accept the position that Irrlicht finds itself in. I know there are alternative libraries for this work. For my own peace of mind I thought I should reach some kind of conclusion. That's all.
BTW I didn't send all the vertices in one submesh, I used a number of submeshes. I wasn't testing the 16-bit index limit, I was looking at Irrlicht's inability to handle a large number of vertices distributed across a number of mesh buffers.
BTW I didn't send all the vertices in one submesh, I used a number of submeshes. I wasn't testing the 16-bit index limit, I was looking at Irrlicht's inability to handle a large number of vertices distributed across a number of mesh buffers.