Shader Basics

[Max Power]

I dealt with custom vertex- and pixel-shaders for the first time yesterday and I would like some help understanding the communication between Irrlicht and the shader.

- First of all: Is every material shaded as a whole (involving all layers at once)? If so, how do i get access to the other texture layers inside the pixel-shader? I tried passing a second sampler-ID (1) for the second layer, but then the shader refuses to work.

- How do I use additional vertex-data inside the shaders (like the texCoords2 of S3DVertex2TCoords)?


edit: nevermind, it's working now. I still don't understand the logic behind the setting of shader constants - sometimes it's working, sometimes it isn't - but I will figure it out eventually. You probably have to use a variable inside the shader (not just declare it) in order to be able to set it.

[Max Power]

One more simple question: how do I rewrite the GLSL vertex shader from the shader tutorial to use normal global dynamic lighting like any other material?

[The_Glitch]

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.

[Max Power]

And there is something else now: The solid material I made works well (except for the lighting, I haven't done this yet), but the transparent one - no matter what kind of transparency I use as base material - doesn't behave like it should. For instance, unlike with the standard materials, there is no adding of layers of transparent materials (or very rarely). If I place one custom shader window behind the other, it's completely invisible.

My guess is that the driver needs to know the correct SMaterial::isTransparent() value, but the implementation is very strict. It only returns true for any of the transparent standard material types. And the function isn't virtual, so I guess material-inheritance is not an option? Looks like I will have to continue with material renderers next...

[hendu]

See COpenGLSLMaterialRenderer.cpp.

Code: Select all

 
bool COpenGLSLMaterialRenderer::isTransparent() const
{
        return BaseMaterial ? BaseMaterial->isTransparent() : false;
}
 

[Max Power]

Hmm, ok. Thanks for the hint. Must be something else then. Sometimes I can see one transparent material through the other and sometimes I can't. Haven't made sense of it yet. I also noticed that my transparent custom shaders sometimes become intransparent for a second or two, but I think that only happens when I added child-nodes to the according scene-node. Will need to do more testing.

[Max Power]

Sorry for spamming the place with questions lately, but I am currently experimenting a lot with the engine's features and getting a bit excited about how easily you can create all kinds of effects

I'd really like to do some post-processing. I thought about passing a screen-sized alpha-channel texture into to the pixel shader to create a glow-value from the fragment's material, and then use this to postprocess the final render-texture. Would also be great to blur vision when injured or to put noise, color-distortion and stuff on top of render-target-textures for in-game monitors and such.

A few tips how I can do this would be much appreciated. How can I apply a shader to a render-texture?

For the main render (0), it would be great if the image processing also worked with stereoscopic 3D.

[hendu]

I think you're hitting the ebo bug if you're using a recent irrlicht - having a transparent material is not enough there, but your mesh's material must also have its BlendMode set to EBO_ADD.

To do post-processing, you use a screenquad. With it you pass a texture (rtt) through a shader into another rtt. You can find several screenquads in the code snippets forum, including mine.

[Max Power]

Changing BlendOperation to EBO_ADD doesn't seem to do anything.

I think it has to do with some internal order though. If I create 3 materials with my custom transparent type and use 3 different textures, I can always see the material through itself. Other than that, there is some kind of A > B > C relation. B and C can be seen through A, but A can't be seen through B or C. So of any combination of 2 materials/textures only one can be seen behind the other.

This doesn't happen with any of the standard materials.

[hendu]

You'll need to post a runnable test case.

[Max Power]

Do you need complete compilable program code?...

Or is the shader enough?

[hendu]

We can't do anything with just a shader. Complete code, data, everything.

[Max Power]

I made the test scenario and put everything into one archive: http://s000.tinyupload.com/index.php?fi ... 1690015142

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.

In case you are wondering: the "crack"-texture is using the normal texCoords in the example, because I used the sandard vertices instead of 2TCoords. That's why it's always strongest on one side and weakest on the other.

[The_Glitch]

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

[hendu]

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.