Again another texure alpha problem

[Klunk]

the classic one is as it happens the chain link fence, the obvious solution is to use Alpharef but that can moire like a bitch so you try a semi transparent material, looks good doesn't moire nice; but for efficiency you 'd like nice long strips but now you have sorting issue with other transparent objects (and it's self) because the strip is being sorted based on the strip position not the face position. So before long the strip is broken up into quad sized meshes with all the overheads that entails. Or the other pain is the 2 quad crossing tree dilemma ! even with face sorting which is the closest face ?

[hendu]

However, I'm surprised that a special development is needed because we see quite often in games semi-transparent objects such as cars or even wire fencing.

Having two windows, their render order doesn't matter. Likewise, a fence is much easier than your object, it usually doesn't wrap on itself.

[Kiristu]

Having two windows, their render order doesn't matter.

I mean, for example, like in this thread:
http://forums.bistudio.com/showthread.p ... ck-in-game
(not Irrlicht related)

The back window pillars are visible through the front window, even if it seems (?) to be one unique object.
This is something very common in games.

Likewise, a fence is much easier than your object, it usually doesn't wrap on itself.

Indeed, I had not thought it could be such an issue.
At least now I know I have to consider this while designing my objects.

Edit: Also, I can't find an easy way to override the render method of IAnimatedMeshSceneNode. Creating a custom scene node only for render is quite a huge work, and there is no way, as far as I can understand, to extend CAnimatedMeshSceneNode to make it work.
Am I missing something obvious ?

[hendu]

The back window pillars are visible through the front window, even if it seems (?) to be one unique object.
This is something very common in games.

The pillars are solid, and the glasses are a separate meshbuffer. The solids get drawn before transparents, write Z, all works out.

Re your override issue: if you don't want to make a custom scene node, you can always take control of the drawing.

node->grab
node->setParent(NULL)

..in render loop, after scene->drawAll..
node->render()

[Kiristu]

OK, I will try that trick to render my nodes separately, or find another way to design them maybe.

When you say "separate meshbuffer", do you mean "separate node" ?

I might have to export (from Blender b3d exporter) my current unique node into several sub-nodes, more work at design time, less changes in the code ...
Is there a direct way to automatically split one node in several nodes according to the meshbuffers ?

[hendu]

For the car windows and windshield, I do mean meshbuffers. Windows are usually transparent enough that having them render in a wrong order is not visible.
Of course with enough tinting/reflections you would need to separate them to nodes.

Is there a direct way to automatically split one node in several nodes according to the meshbuffers ?

That's a loop and a couple lines of code

[Kiristu]

For the car windows and windshield, I do mean meshbuffers. Windows are usually transparent enough that having them render in a wrong order is not visible.
Of course with enough tinting/reflections you would need to separate them to nodes.

Ok, my display errors are also related to the backfaces. I understand it a bit more now.

That's a loop and a couple lines of code

Well, I looked into node and mesh construction, but I'm not sure, is it possible to build a node from a meshbuffer ? Or to convert a meshbuffer to a mesh ? I missed it in the documentation.

[hendu]

Please see example 3. You create a SMesh, add the buffer to it, then you can pass that SMesh to addMeshSceneNode.

[Kiristu]

Unfortunately, this seems to be more complicated for an animated mesh. The SMesh is designed to work with static meshes.

I tried to use SAnimatedMesh instead, but it does not have any "addMeshBuffer()" member.

So I tried:

Code: Select all

 
IMeshBuffer* buf = mesh->getMeshBuffer(i);
 
SMesh* smesh = new SMesh();
                
smesh->addMeshBuffer(buf);
 
SAnimatedMesh* samesh = new SAnimatedMesh(smesh);
 
node = smgr->addAnimatedMeshSceneNode( samesh );
 

But, as expected, the IAnimatedMesh skeleton is not included in the node (as I did nothing to extract it from "mesh" and to add it to "samesh").

According to the debugger info, I should have a "CSkinnedMesh" object as mesh of the node (member Mesh of CAnimatedMeshSceneNode), but this is internal to Irrlicht.

Any clue of how I could extract some MeshBuffers + skeleton from an IAnimatedMesh ? Do I need to implement a clone of CSkinnedMesh or implement ISkinneddMesh ?

Thanks

[Kiristu]

I found this thread:
http://irrlicht.sourceforge.net/forum/v ... 1&start=15

giving some code to copy an ISkinnedMesh

Code: Select all

irr::scene::ISkinnedMesh* createSkinnedMeshCopy(irr::scene::ISkinnedMesh* mesh, irr::scene::ISceneManager * sceneManager)

That works quite well for the whole mesh, but as soon as I filter the duplicated SSkinMeshBuffer* to keep only the one I want to extract, it is not animated anymore.
However, the joints are copied, and animation stuff seems to be called correctly (I checked that the frames are incremented).

So, I might be close to the result I want, but something is still missing.

Edit: After investigation, I think the joints are not correctly linked with the vertices/mesh if some meshes are not copied during the process ...

[Kiristu]

OK, I finally made it.

Based on the copy method, I filter the mesh buffer I want (based on material) and copy only this one.
The trick is to go through every weight of every joint and update the buffer_id in there (setting it to 0 for the new mesh).

Thanks again for the help