Irrlicht Engine

Compiled Irrlicht 1.8 and got my first few shaders up and running. Amazing!! thank you for incorporating it into the engine ^_^

After searching through IGPUProgrammingServices class trying to find out if I could use techniques with multiple passes there doesn't seem to be support beyond the simple vertex and pixel shader call backs of previous Irrlicht builds.

I really want to be able to control the render state in my pass tag. This is crucial to the design of some shaders (e.g. turning off depth testing for a skydome/skybox shader). I really don't want to hard code the render states.

Is there going to be support for multiple techniques and passes from a single shader file? It would be ideal to support the technique and pass models for HLSL and CG. Though in saying that I don't fully comprehend the scope of implementing it.

It wouldn't be too hard... Meshbuffers have a single material attached, what if instead of a material, there was a way to have multiple shaders attached to a material, meaning this that the meshbuffer needs multiple passes to render correctly? or an array of materials. Though this would mean changing large parts of the engine, even that it would break backwards compatibility, so, most probably, a multipass setup would be for the version 2 of Irrlicht.

Still, it wouldn't be too hard to create a scene node that performed the multipasses on its own. just keep in mind the rules for the rendering of transparent objects, and you would be done.

Eh, if it would break things for GLSL and HLSL users only to benefit Cg users, I have to ask what's the point?

Things like a techniques, passes etc. cause a problems with performance. eg problems with material sorting, states cache etc. so we will not implement these features in the engine.

BTW. GLSL doesn't support it Anyway these features are usefull only for small tech demos, for standard game dev performance hit is too big (AAA games doesn't use it).

Ogre3D Supports techniques and passes. e.g. http://www.ogre3d.org/tikiwiki/tiki-ind ... e=Cookbook (turns the depth test on and off)

@Hendu I didn't necessarily think it would break things for GLSL users. I was thinking more along the lines of adding support for HLSL and CG techniques to control render states. If it were done right it would be a couple of new functions in IGPUProgrammingServices which would load effects (techniques) instead of routing to the vertexshader and pixel shader callback. I don't think support for the existing callbacks would need to be broken.

enum E_GPU_SHADING_LANGUAGE
{
...
EGSL_CG,
EGSL_HLSL,
};

s32 addEffectFromFile(const io::path& effectFilename, IShaderConstantSetCallBack* callback = 0, s32 userData = 0, E_GPU_SHADING_LANGUAGE shadingLang); // Loads a shader effect with technique and pass style

@Nandro While I concede multiple passes would slow a real time program, I don't fully understand why it would be the case under a single pass. Consider this example:

In OpenGL:
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
// render
glDisable(GL_BLEND);

in CG:
technique Tech1
{
pass Pass1
{
AlphaBlendEnable = TRUE;
DestBlend = InvSrcAlpha;
SrcBlend = SrcAlpha;
VertexShader = compile vs_2_0 VertexShaderFunction();
PixelShader = compile ps_2_0 PixelShaderFunction();
}
}

All the pass is doing is changing a couple of variables tied to a render state. A cache of states being pushed and popped every time a shader was used may slow things down. But If I am hard coding those state changes inside irrlicht, doesn't it end up approximating the same thing? (It would probably be faster if the stack only recorded changes in the state rather than every single state variable)

@ Nadro "AAA games doesn't use it".If AAA titles don't use techniques how do they control their render states? Using passes to control render states is a core part of XNA, don't know if there are performance issues there.

XNA is dead & deprecated

And worst of it, Microsoft killed it with DX10...

Ogre support passes and techniques in your own material file format, so they can have better control over them.

What is a problem with: As I remember when I used Cg some time ago, You can't read render states from file to application memory in simple way and as I said GLSL even doesn't support FX structure. You need these variables for optimized OpenGL calls (look at how is working COpenGLCallBridge).

what if instead of a material, there was a way to have multiple shaders attached to a material,

That would be great! We could use ready made shaders and mix them together to get the desired material.

Ex: Have a "diffuse" shader then decide to add specific maps those to the model, perhaps also having easier way of doing deferred rendering:
- Normal
- Specular
- Displacement
- Reflection
etc.

If I'm not mistaken, this can be achieved in a single shader, but need to write a bigger shader with some "boolean" to activate/deactivate features.

On another subject, has anyone ever written a diffuse/normal/specular GLSL shader that could support 8 lights? Or is there somewhere I could find some example to building something like this? I've almost not find any resources on teaching how to use shaders with Irrlicht...

It isn't very hard to write one, but it is a performance OVERKILL IMO ^^U at least not the shader you would want to fill much of the screen, for not to speak about overdrawing on hidden surfaces. Not obstant, that is the solution applied for the drivers that need forcefully the programable pipeline.

If you need to chain shaders, use one of the screen quads. But be aware that it's very inefficient, you're much better off writing one shader that does everything.

Hi, Thanks for the replies!

use one of the screen quads.

Are theses are used for POST PROCESS FX only? How could I use that for applying another shader on a material? Is the material appear as a mask and we could use them with the screen quad?

I think, I will try to make shaders with the required stuff, but I'm curious about the method you talk by using screen quads... Thanks for "educate" me on this subject!

Yes, if you need to chain materials in a non-deferred setup you need multipass rendering, which is really costly.

In a deferred setup you can often use screen quads, because then many effects become post-processing essentially.