Too many vertices for 16bit index type

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
DF
Posts: 4
Joined: Fri Apr 01, 2011 1:02 pm

Too many vertices for 16bit index type

Post by DF »

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
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

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.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Actually, the correct term would be meshbuffer. Each mesh consists of buffers, and each buffer can have up to 65535 different vertices. Since animated meshes need separate buffers for animation anyway, the buffers should usually be pretty small. But this depends on your exporter also.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

Well, I know, but I thought the poster might be confused if I spoke about meshes and mesh buffers. We can also add in the container: animated mesh. Altogether too many meshes.

Anyway, it was you who sent me on the wild-goose chase to find the fictitious 32-bit indices! :)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

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.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

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.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

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.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

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.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

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.
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

I've written an application to display a mesh using only OpenGL calls (glDrawElements). The mesh has 238965 vertices and 425850 faces (I "tripled" the quads). Just spinning the model (moving the camera) I get 30 FPS!

So I don't think there are any pipeline stalls.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Well, all three major gfx hw manufacturers have these recommendations in their most recent GPU programming guides. Why should I trust your example more than their rules?
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Post by mongoose7 »

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.
Post Reply