Too many vertices : 16bit to 32bit for obj loading?

[Supra]

Hi everyone,

I am quite new to Irrlicht and have an issue while loading a .obj.

The file is quite complex because I have the "Too many vertices for 16bit index type, render artifacts may occur" error. For now, it seems to load well but as the program may complexify, I would like to get rid of this error.

I looked on other subjects, sugesting to use CDynamicMeshBuffer but here is the thing : the .obj have no group (it is only one big object) so I can not load it in several parts. Here is how I load it :

Code: Select all

_mesh = *IMeshSceneNode;
_mesh = _scene->addMeshSceneNode(_scene->getMesh(file.obj));

I also tried to modify IMeshBuffer.h and CMeshBuffer.h in order to force the use of 32bit index instead of 16bit ones, but no differences occur.

Is there any way to simply load a .obj while using 32bit index?

Thanks in advance, any help is welcome

[hendu]

The OBJ loader does not support such huge meshes. Try to convert your mesh to PLY for example, that loader does support them.

[kklouzal]

Why are we still limiting the engine to 16bits for meshes when any machine that someone's going to make an application with irrlicht for is going to be 32bit and in most cases 64bit capable?
I just don't understand it doesn't make any logical sense.

[Mel]

Because 16 bits are still quite useful, even if it doesn't look like it. With 32 bit indices you're using double the space you may need (and double the bandwidth it may use) when in many cases, the size of the indices you need is never greater than 16 bits.

It is often, space-wise, better to split the meshes into smaller 16 bit compatible chunks than having a large 32 bit mesh indices, keep also in mind you're speaking about a SINGLE meshbuffer. Think that having for instance 512000 vertices in a mesh just require 19 bits. with 32 bit indices, there are 13 bits wasted, and that also produces internal memory fragmentation.

[kklouzal]

Thank you for the explanation :)
Recently I've had MAJOR performance issues directly being impacted due to the sheer amount of draw calls being made. To make a long story short it's a bunch of nodes put together to represent a planet, an empty planet at that. So no trees, rocks, foliage, grass, etc. Having access to a 32bit mesh in this scenario could cut the draw calls down a lot which is why I made the previous post :)

[Supra]

Thanks for the quick answers.

PLY could seem to be a good idea, but I have textures to apply to the object (which are currently loaded with the associated .mtl).

I looked for the 3ds format, but can the texture be directly applied in the file or do I need some other files ?

(there are 222 211 vectrices in the file so yeah, quite big for 16bit)

[Mel]

It doesn't really matter that you have 222211 vertices, whenever they aren't in a single meshbuffer (i.e. the whole mesh has just 1 single texture) you can have very large meshes, with a very large amount of vertices.

Don't use the 3DS because, as far you're concerned with the 16 bits limitation to the meshes, precisely, the 3DS format shouldn't allow you to have meshes with more than 64K vertices in a single meshbuffer. Also, to be compliant with the 3DS format, the texture filenames must not exceed 8 point 3 characters, which is also a minor drawback of the 3DS format, and it doesn't load smoothing groups (aka, you will see the meshes flat shaded) so you better look for another format.

Or, if it is posible, create your own custom file format. It isn't very hard, covers exactly what you need, and you may build mesh combiners so your meshes can be as large as you want. You export small chunks, and save them into a large mesh that you load with 32 bits indices, and you're done

[Supra]

Thanks again for the answer.

It doesn't really matter that you have 222211 vertices, whenever they aren't in a single meshbuffer (i.e. the whole mesh has just 1 single texture) you can have very large meshes, with a very large amount of vertices.

If I understand well, you mean that appliying several textures to the objects wll divide it into several meshbuffer? It would ewplain why for now, as there are colors and no textures in the .mtl, it seems to be considered as a single meshbuffer.

Sorry for the maybe quite stupid questions, I just want to be sure I understand

[CuteAlien]

Yes, you get one meshbuffer per per texture (or actually per material).

[Mel]

Well, i said per texture because it is the most typical layout for the meshbuffer splitting, but if obj does it per material, then there you are a good way to load big meshes with 16 bit indices

[hybrid]

Another reason why we don't support 32bit indices in general: Even todays graphics cards don't like such huge meshes. I haven't checked the manuals for recent suggestions for VBOs etc, but all data processing will usually benefit from reasonably sized buffers. The parallel units can be much better fed with this moderate packets instead of pushing bloated ones. And it should thus also hold for meshes stored on the GPU mem.