irrlicht XML shader system [Release Candidate 1]

[devsh]

Yes... I can announce the completion of this feature

UPDATE RC-1

For the new features find my Bump-post, I also added time shader constant passed down automatically.

Link : http://pastebin.ca/2015990


OKAY GOT THE DIFF to WORK
http://pastebin.ca/2011488

UPDATE v 0.2
I addressed the following issues, the function is now called getXMLMaterialType and doesn't require you to set baseMaterial (reads from xml if specified) also can pass the camera far value to the shader.

Link : http://pastebin.ca/2012004

1) Rather than them being considered a special sort of "shader material", I think we should assume that all materials exist in the filesystem as files. We'd need a material cache in the video driver base class and some fake file names to go with it. I'm thinking we may want to export materials, maybe not but it's at least worth thinking about.

2) Rather than have a shaderCodeFallback, we should use something like materialFallback and give a file name to fall back to. For example the default could be SOLID which represents the built-in EMT_SOLID renderer.

[devsh]

so now I will wait untill the devs put it into the engine... and if you guys want... I will make a materialFromXML loader and add caching for the shaders loaded from XMLs

[hybrid]

I don't get it. Where's the advantage over pure shader files? You still need the shader callbacks, manual code insertions here and there. Shouldn't this all be automatically?
Anyway, I'll move this to Code Snippets where it is better kept.

[devsh]

what did you expect?

I mean that shader is unique, requires non std variables like camera position turned into light and a color to be passed down. If it used the standard gl_LightSource then you could get away without a callback.

If you havent noticed, all the code for handling fallback shaders/ high level shader creation failure is GONE... so assembly shaders will get loaded if high level shader fails.

The default callback however, handles passing down any transformation you dream of, world, view, proj, viewproj, worldviewproj.. the transpose of them, the inverse and the transpose inverse

It also passes the textures automatically and can give you the FB size, just these can enable you to do most post processing (let me think, SSAO, DoF, Blur, MotionBlur, edgeAA, Bloom not HDR though due to custom params like exposure) WITHOUT writing your own callback... although if you wish I have 6 slots left for user's custom CONSTANTS passed as uniforms (not linked to things in the game)

Btw this is a patch for the engine, not a code snippet... i'd like it integrated if possible (after ammendments to the design).

[hybrid]

If it would be an addition (i.e. without changing existing stuff) it might have chances. But first of all the advantages or disadvantages have to be discussed. And it's not a problem to have diff's in the code snippets forum.

[devsh]

As you can see from the diff it's only an addition.

[devsh]

sorry forgot to post the link to second diff

[ACE247]

I'm not sure why but whenever I want to apply your diff files using Tortoise SVN it just gives me the error "An unknown line type was found in line xxx and it just closes.
I hardly ever use/used Tortoise svn, so maybe someone can help me here?

[bitplane]

Okay, now I've taken the time to read your code, I think it's a good start. It is missing a time parameter though, which is essential for any sort of animating shaders.

Secondly, like I said in the other thread I think it would be better if it worked like all of Irrlicht's other loaders.

1) An IMaterialRendererCache which ties renderers to names.
2) An IMaterialRendererLoader which the shader loader is a subclass of.
3) Automatic loading for XML shaders and other types from within files.
4) The base and fallback materials described by (file) name in the XML, so you can chain them together.

The disadvantage:
1) Engine bloat.
2) Still need to make your own material renderers for trickier materials

Advantages? We can port materials from the forums into the new format and load them in the examples in one line, shaders become demystified and newbies churn out some great-looking apps.

In the future we could have a CRenderMonkeyShaderLoader or CFixedFunctionMaterialLoader to compliment this, allowing Irrlicht to automatically create desired materials whatever they are. External projects and plugins could have their materials work with loadScene/saveScene and add their own shaders and fixed function materials to the renderer cache.

It doesn't solve the multi-pass issues, but it's a good start

[devsh]

1) No.. You dont have a special ITexture cache for textures, so you shouldnt have for shaders

2) I will try but I dont promise anything

3) That will come when I write XML material loader, and that only happens if this makes it into irrlicht

4) If you studied v0.2 you should see that this is implemented, you can either specify base material in the loading function (like in the example when you use the same shader but with different base (also two cache entries are made)) or you specify it in the XML. fallback material is specified in the XML
Chaining is not necessary as.. you need to use a fallback material because your hardware doesnt support shaders, so why reference to ANOTHER shader?

[devsh]

All is done.. rc-1 is complete. New Features:

-

1) Extend: I write a ".fooMesh loader", which comes with a paging terrain with ten splat layers and shaders for each driver type hard-coded into the loader. When you create the loader it adds its shaders to the driver's material renderer cache, any time anyone needs "FooMeshShader" (even if they're not a .fooMesh) it works without issue, even though FooMeshShader isn't an XML file.

-

2) Override: I hate Irrlicht's built-in materials, so I make my own. I hack the material renderer cache and replace the default renderers with my own fancy shaders, some are loaded from XML files, some aren't. I then load some files, my shader gets used whenever getMaterial asks for EMT_SOLID.

[devsh]

bump.. can we test it and decide on putting it in the engine?

[hybrid]

Yeah, I guess everyone can test it, no? Let's wait for bitplane to decide. He seems to understand what is going on and what could be useful in this situation.
Oh, and don't bump for no reason. Threads with too many bumps can vanish without further notice!