How to use S3DVertex2TCoords?

[Markuss]

Im modding Minetest and would like to use S3DVertex2TCoords because I need the extra UVs to pass some extra info to the shader. (Each node needs to have some information about its neighbors so I can tile the connected textures in the shader)

The minetest code is written to use video::S3DVertex. For example

Code: Select all

scene::IMeshBuffer *buf = mesh->getMeshBuffer(j);
video::S3DVertex *vertices = (video::S3DVertex *)buf->getVertices();
int vertex_count = buf->getVertexCount();

S3DVertex2TCoords inherits from and is an S3DVertex so in theory I should be able to find out where my vertices are being created and change them from S3DVertex to S3DVertex2TCoords.

I don't even care what the value of the extra UV is on creation since Im going to change it later, I just need to make sure the memory exists and will be passed to the shader. The vertices may actually already be S3DVertex2TCoords for all I know Im not even sure how to check since I dont know how exactly vertices are passed to shaders.

But I cant figure out where in Irrlitcht those vertices are being created. Maybe there is a way to save my mesh in Blender with an extra set of UVs and Irrlicht notices these extra uvs and uses S3DVertex2TCoords automatically?

Keep in mind the Minetest version of Irrlicht is far behind the modern version of Irrlicht.

Thank you

[CuteAlien]

In general it's the loader which creates the vertices. Not sure right now if any actually does that. Or yourself if you have your own functions to create meshes.

Make sure to use the correct vertex type in the corresponding meshbuffer class. In newer Irrlicht you can use CDynamicMeshBuffer(EVT_2TCOORDS) which supports also 32-bit buffers. In older versions those also exist, but were very buggy until pretty much exactly 1 year ago. If 16-bit buffers are big enough for you then you can use SMeshBufferLightMap.

It's also possible to convert SMeshBuffer to SMeshBufferLightMap meshes after loading with IMeshManipulator::createMeshWith2TCoords. No such solution yet for animated meshes I think.

And I think the extra values are then passed to the shader as TEXCOORD1 and TEXCOORD2.

[Markuss]

Im still pretty confused.

In Minetest the client has a getMesh function. client->getMesh(mesh);

It works by getting the file name and then iterating over an array of loaders.

These are the loaders in CSceneManager.h
#ifdef _IRR_COMPILE_WITH_X_LOADER_
MeshLoaderList.push_back(new CXMeshFileLoader(this, FileSystem));
#endif
#ifdef _IRR_COMPILE_WITH_OBJ_LOADER_
MeshLoaderList.push_back(new COBJMeshFileLoader(this, FileSystem));
#endif
#ifdef _IRR_COMPILE_WITH_B3D_LOADER_
MeshLoaderList.push_back(new CB3DMeshFileLoader(this));
#endif

Each loader tries to load the file one at a time until one is successful.
In my case since Im using a .obj file and the getMesh function appears to choose the COBJMeshFileLoader (I can confirm this in the debugger.)

For some reason I dont seem to have the COBJMeshFileLoader.h or COBJMeshFileLoader.cpp in the minetest source code
Maybe Im mistaken about minetest actually using it? or perhaps its being linked to an already compiled object?

But looking at COBJMeshFileLoader here https://github.com/zaki/irrlicht/blob/m ... leLoader.h
and assuming its similar to the one Im using its not obvious to me how to add an extra UV since the loader seems to be using S3DVertex.

Maybe I can try taking my s3dvertex pointers out of their buffer and pointing them to new S3DVertex2TCoords vertices in my mesh drawing code?

Make sure to use the correct vertex type in the corresponding meshbuffer class

Im not sure what you mean by this. Since S3DVertex2TCoords inherits from S3Dvertex then shouldn't S3DVertex2TCoords be the correct type?

[CuteAlien]

COBJMeshFileLoader seems to be in /irr/src/COBJMeshFileLoader.cpp in Minetest (at least in master branch). If you search for S3DVertex there is only once place. And what I mean with - "need corresponding meshbuffer" is that SMeshBuffer _only_ takes S3DVertex, it can't take S3DVertex2TCoords as it work with a template parameter for this. So you need a SMeshBufferLightMap instead. Check the typedef's at the end of include//CMeshBuffer.h to see what I mean. The only meshbuffer which can work with several types is the mentioned CDynamicMeshBuffer, but it comes with several other interface changes and you seem to have kicked it out anyway (and I doubt you need it).

So if you really modifed the loader (likely a bad idea!!!) - in this case would be in COBJMeshFileLoader.h in the SObjMtl struct where you would have to replace the scene::SMeshBuffer *Meshbuffer by an SMeshBufferLightMap and then replace S3DVertex in the .cpp file by an S3DVertex2TCoords.

But you probably do not have to do this in the meshloader anyway. Unless your additional data come from disk and need to write your own mesh-loader. Just use the mentioned IMeshManipulator::createMeshWith2TCoords after loading your meshes and replace your original meshbuffers with the ones created by that. You might want to check if it really was a static mesh (.obj would be always static). And then kick out your original meshbuffer.

Be aware that this isn't free - increased vertex size has it's cost. So for a start you can simply replace the meshbuffers and then run a speed-test without doing anything else just to see how big the minimal impact will be in your case. Speed impact is very application specific, for some games you can ignore it, for others this is really expensive, so you have to measure.

[Markuss]

awesome. thank you so much