Shader Basics

[Max Power]

Hmm I wasn't able to run your program what are you compiling under?

Visual Studio 10. Maybe I didn't choose the right settings, but the source is in the archive, too.

I know now that the problem occurs with multiple meshBuffers of the same node, not with different nodes.
Apart from that it's like I suspected: the order of the meshBuffers determines which ones are visible behind the others.

Well why didn't you say so

There is no intra-mesh transparency sorting. It is only between meshes.

But if you do the same thing with transparent standard materials, there is no problem :/

[Max Power]

To use dynamic lighting you have to create the shader to work off a light, most likely a single point light. Then you create the light in Irrlicht and pass that light as the light to use in your shader callback.

So that means I have to get all dynamic lights from the driver inside the shader-callback, pass that array of point-lights as "uniform" to the vertex-shader, and then apply each light to each vertex using the dot-product of vertex-normal and light-direction?

[Max Power]

So, can anyone tell me what I need to do to get my transparent custom-shader materials behave like standard transparent materials. It's kind of a big deal. It's not just the mesh-buffers inside a mesh that get messed up, I also sometimes can't see other transparent scene-nodes behind these materials, like standard billboard-sprites. I don't understand what the problem is...


I've redone the test scenario and recompiled for "release" this time (don't really know anything about compiler settings...): http://s000.tinyupload.com/index.php?fi ... 2470312866

I also added some sprites to the scene. Before, I only had the custom shader mesh-buffers and at least then, it looked like there weren't any problems as long as you used seperate nodes for them. But now you can see what a mess the whole thing is. There's still a visual difference between one mesh vs several meshes, but it's messed up either way.

[hendu]

Your code doesn't compile, and your frag shader doesn't compile...

Your nodes are acting all funky because you place them at the same spot. If all six cubes are at (0, 0, 0), how is the engine supposed to sort them?

That's very easy to fix - instead of physically moving vertices (orig + center), you put the node's position at that center after addMeshSceneNode. This has more advantages too, because you reuse the mesh instead of having six copies: your meshes take six times less space in VRAM, and may even render faster if already cached.

[Max Power]

Everything compiles just fine on my mashine. There's just a problem with the D3D-shader, because it seems to refuse working with the variable names I gave it and spams the console with warnings, even though it's operating (at least here, it is). I wrote it last night and wasn't able to fix it yet. However, the GLSL shader shouln't cause any trouble. And the important part is: there is no such funky behavior with any transparent standard materials, regardless where I place the nodes. Why would it matter anyway? What's important is where the vertices end up, not where the nodes are located. If I compile the same scenario with standard tranparent materials, there is no problem. I would very much like to know why and if I can do something about it. When listing custom shaders as an engine-feature, transparency must have been in mind, no?

The point is: I use giant meshes to dynamically alter a voxel/volume-based world where individual faces appear and disappear all the time, adding/removing their vertices to/from their buffer. I made performance tests up front and keeping the number of mesh buffers as low as possible has proven to be the best approach. So even if the node-positions really did make a difference, I have good reason to do what I'm doing.

[Max Power]

I don't know why I still bother, if nothing runs or compiles outside of my machine, but I don't feel like giving up just yet, so I re-worked the example again: http://s000.tinyupload.com/index.php?fi ... 8883415249

You can now choose between standard and custom material for the comparison. It looks like disappearing nodes, when using one node & mesh per mesh-buffer, occur with standard materials as well. So maybe you're right and this really has to do with the node-placement (which would be a flaw with the engine imo).

BUT: using a single mesh (like I pretty much have to) with standard materials is no problem at all. The only thing slightly unusual I could observe here is that sprites behind one or several transparent materials are sometimes a little bit less bright than normal.
With my custom materials these sprites and other transparent materials just comletely disappear sometimes. There has to be a reason for this.

[hendu]

That the standard material works is a coincidence in the sort order. Use nodes properly, and your previous upload starts working with your shader (after numerous fixes to make it compile - don't use nvidia and VS, they let you get away with far too much).

If you check the irr source, the node position is used in transparency sorting. I wouldn't call that a flaw. While center-of-bounding-box could also be used, it would result in different behavior, not necessarily better.

[Max Power]

A coincidence?

From my point of view I am using the nodes as properly as I possibly can. The meshes are not meant to be instanced. There is one mesh per voxel-object. The mesh can extend over tens of thousands of individual voxels, containing several times this amount of faces. I have to dynamically decide wether to draw (add to buffer) or leave out faces that are hidden by neighbor-voxels etc.

I can't use 10000 individual nodes for that, unless I want to make a slide-show. Have you worked with particle-systems? They work very similarly, although they only have a single material. If you created one node per particle...

I need one buffer per material (several, if the number of vertices gets too high). Even if I used an individual mesh & node for each, where would I place them, if not at the voxel-object's origin? All the face/vertex data added has to be relative to something.

I am not going to believe that the fact that everything works flawlessly with standard materials, no matter how many, is pure coincidence.

[hendu]

I understand you need to batch. But your draw order has to be correct for transparent results to look like they should, so you should only include at most one overlapping transparent material per node.

The disappearing node appears to be a legit bug in transparent Z-writing, checking.

[hendu]

Yes, it was a bug. Z-writing was erroneously enabled for transparent shader materials. I can't believe I've never hit that before.

[Max Power]

Always glad to be of help

Does it concern only the disappearing nodes or the mesh-buffers as well? Because I'm currently preparing videos to finally clarify what I'm talking about.



edit: anyway, the upload has finished: http://s000.tinyupload.com/index.php?fi ... 3626562985

Don't bother figuring out what those things are supposed to be. It's just placeholders, 5x5x5 cubic voxels with randomly picked placeholder-textures. There should be about 10 different textures/materials. Each has one mesh buffer containing all the belonging vertices, all the mesh-buffers belong to one node/mesh. In one video, every materialType is set to my custom shader material, based on standard vertex-alpha-transparency. In the other, all the materialTypes are standard vertex-alpha-transparent. You can see that each and every polygon is always visible as it should be, using the standard material type. When using the custom one, many polygons are missing. I don't know if this is covered by the bug or not, but I don't see how this could be coincidence.

[hendu]

Yes, looks like it's covered.

[Max Power]

Ok, glad to hear that. Thanks for the help. Guess I just have to wait for next release then and let you guys fix it.

[hendu]

Irr releases come slightly less often than Jesus's comings, so I recommend patching your version.