How would one fetch a mesh generated in another function?

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
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

How would one fetch a mesh generated in another function?

Post by Cube_ »

So the structure of my current engine (after splitting things up into files for readability)
basicVoxel.h/.cpp (I have both files, h contains the declaration and .cpp the definition as expected) - this generates each voxel based on what type is supplied by the world Generator and player controller function (to allow the player to edit the voxels)
voxelNode.h/.cpp (again both exist containing declaration and definition respectively) - this takes the voxels generated by the function(s) in basicVoxel and assembles them into a 256^3 chunk and takes care of optimizing the mesh for actual usage
main.cpp - the main thread resides here and is where Irrlicht renders everything, where the physics engine collides things and where the worldGenerator adds trees, water, animals etc to the world

Now I'm not sure how I should proceed with this, the basicVoxel currently ends with

Code: Select all

    SMesh * cubeMesh = new SMesh();
    cubeMesh->addMeshBuffer(buffer);
    ISceneNode * cubeSceneNode = smgr->addMeshSceneNode(cubeMesh);
    if(cubeSceneNode)
        cubeSceneNode->setMaterialFlag(EMF_LIGHTING, false);
I have no idea what would be better practice though, sending the meshbuffer directly to the chunk generator?
Sending the cubeMesh there?
sending a sceneNode there? (I really don't need a sceneNode for the cube, or rather I don't think I do as the cube itself will be added to a larger node, unless keeping the cube a separate node makes it easier to select it as an add/remove operation in which case I'm all for that)
I at least assume I should be able to send the chunk to the main thread in a similar fashion.
the chunk builder is built to take pure mesh data (with color data associated) but should be easy enough to extend into taking a full node (which, I can see benefits with since various different voxels will have different properties at a later stage, I don't remember if a node can have any arbitrary data tied to it or not but if it can then that's cool)
"this is not the bottleneck you are looking for"
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: How would one fetch a mesh generated in another function

Post by hendu »

You should not call add*SceneNode in another thread, there's a chance of corruption.
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

Re: How would one fetch a mesh generated in another function

Post by Cube_ »

I only put it there as a placeholder for later, I have to make a scenenode somewhere and that's as good a place as any to put a reminder, I am curious as to how it can cause corruption though.

Either way my question wasn't answered, what's the best way to access a mesh from a different thread than the one it was created in?
a pointer to the SMesh? a pointer to the vertex buffer?
"this is not the bottleneck you are looking for"
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: How would one fetch a mesh generated in another function

Post by hendu »

If two (or more) threads try to add a node at the same time, the children list can get corrupted. You will get anything from one node added, two nodes added, one corrupted node added, two corrupted nodes added, one added but size increased by two, two added but size increased by one, etc etc.

Send the SMesh pointer over in a thread-safe way.
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

Re: How would one fetch a mesh generated in another function

Post by Cube_ »

got it, I'll send the SMesh
As for your explanation of how nodes can be corrupted, I think I get it (there's probably some thread safe way to do it but it's unlikely to be more efficient in any way), this might not be too bad for some things (at least in the size increased by two for example (assuming size is memory and not the size of the mesh or whatnot) but it would be devastating for me, I am already using a large amount of memory (in my pure null video implementation where I just create the amount of data required, after implementing optimization techniques it still ends up at hundreds of megabytes (beats thousands of megabytes))
Even if each data node was only one byte bigger it would have dramatic effects :P
"this is not the bottleneck you are looking for"
Post Reply