Triangle Limitations

[Elevations]

I've been looking into older 3D model formats for animated objects and realized a potential limitation they seem to share:

• .x,
• .b3d
• .milkshape

It appears these formats are often restricted by "16-bit indexing for their triangles". This imposes a maximum of "65,535 unique vertices" per model.

This vertex limitation could significantly restrict the achievable detail and overall quality, especially when aiming for complex and visually rich animated characters or objects.

While the ".obj" format offers "32-bit indexing", allowing for a much higher vertex count and thus greater detail, this format is primarily used for static geometry and doesn't inherently handle animation data in the same way.

Given this limitation, I'm wondering if there are any "possible solutions" to overcome this 16-bit barrier for animated models using these older formats?

Additionally, I'm curious if Cutelien is planning to add ".fbx or .gtlf support with animations" to irrlicht anytime soon, as that could potentially address some of these limitations. And wondering if there is other problems involved in trying to fix this?

[CuteAlien]

Note that it's not 16-bit per model - but per meshbuffer. Mostly it was possible to work around it that way in the past (splitting into more meshbuffers). Although models obviously are getting larger. Irrlicht also has that restriction internally for skinned meshes as SSkinMeshBuffer supports only 16-bit so far.

I improved 32-bit support for static models a lot for 1.9, but for animated models I've currently no plans.

And while I got .fbx loader by now partly working (got geometry and some materials, still fighting some texture troubles), it's again only coded for static models and I'm not sure I'd even use the same code for animation. Fbx format is a bit tricky as it has more transformations than Irrlicht. My current loader basically converts stuff into Irrlicht format on loading. But for animation it's maybe easier to let fbx sdk handle the animations as well and only use the result of those in the node (so the fbx sdk isn't just used for import, but also at animation time). But have to look more into that and it's a bit hard to combine with Irrlicht skinning system. Also still have to ask company I'm doing this for if I'm allowed to release the fbx loader once it's done. Anyway - not doing animation right now.

I haven't looked yet at gltf too much, but obviously would prefer that one (open format, vs proprietary fbx format). Or .glb (the binary version of it). Thought likely also should be done by using some sdk (which then can support both). And I'm not planning to work on it currently, but maybe I'll be lucky and get another freelance contract for that one (it's used a lot these days).