Hmmm... Want to make some Irrlicht Goodies, ideas?

[Kalango]

Well, imho it looks a lot more to a shader format than with something else. Its basicly just a global way of doing things right? You could try to reach stuff like simplifying shader callbacks or something.
Just my 2 cents... i may not know what i am talkin about...

[devsh]

Essentially yes, its here to simplify shader callbacks and to save you writing a shader fallback mechanism (if you hardware doesn't support shader A, use shader B and if that isnt supported use EMT_WHATEVER)

You only unleash the power with material XML system

[bitplane]

The way I was thinking this works is, a user loads an .irr file, which contains material information. The materialType is a string, you call getMaterialRenderer(string) like you do getMesh and Irrlicht looks inside the material cache for this material, if it exists in the cache (ie "EMT_SOLID") then it uses the index as the material type. If it doesn't then it uses the shader loader to load the material type from disk, adds it to the cache, then returns its index.

Code for (de)serializing SMaterials to and from XML already exists in Irrlicht, all we'd need here is to replace the built-in material name with its name from the cache, the material deserializer would do a getMaterialRenderer. Maybe at some time in the future someone could make a shader editor and we could have saveMaterial like we have saveMesh and saveScene, and all these would magically work together

Consider these other use-cases:

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.

3) Someone hacks together a RenderMonkey shader loader, which is very ugly and doesn't belong in Irrlicht at all; it relies on their own multi-pass code and a bunch of other stuff. However, their external shader loader can make use of the shader cache and their models and special scene format all just magically work with Irrlicht's fancy new material system.

The business of an XML shader loader would be:

1) to create IMaterialRenderers when CNullDriver::getMaterialRenderer (or whatever it will be called) asks for one by name
2) to ignore shader files that the current driver can't load, fails to compile, falling back to some other (default or specified) one
3) to create generic, yet efficient callback(s) for the renderers, which pass in the parameters specified by the XML in the correctly named slots.
4) to set up the fixed-function blend modes from the base material

As for the XML format, I'm not sure about adding all the different shader types in as separate sections, I think it would be better if they were separate files. My idea about just having base and fallback material types could suffer from circular references, but IMO it would be cleaner than potentially having 8 different shader types in one file.

Also, forget what I said on IRC, I don't see a reason why we couldn't have the shader code inline, this would be a neater option (if it doesn't add extra complications)

[devsh]

The way I was thinking this works is, a user loads an .irr file, which contains material information. The materialType is a string, you call getMaterialRenderer(string) like you do getMesh and Irrlicht looks inside the material cache for this material)

Yes you could use getXMLMaterialType(params) with a null callback... and forceHighLevelShaders anyway, just remember the xml Material Loader DOESNT EXIST YET! (it would just be serialize and deserialize?)

if it exists in the cache (ie "EMT_SOLID") then it uses the index as the material type. If it doesn't then it uses the shader loader to load the material type from disk, adds it to the cache, then returns its index.

yes v0.2 does this

Code for (de)serializing SMaterials to and from XML already exists in Irrlicht, all we'd need here is to replace the built-in material name with its name from the cache, the material deserializer would do a getMaterialRenderer. Maybe at some time in the future someone could make a shader editor and we could have saveMaterial like we have saveMesh and saveScene, and all these would magically work together Smile

"all we'd need here is to replace the built-in material name with its name from the cache" - use sBuiltInMaterialTypeNames[] or the name of the shader from cache (I have to add a function for searching by the materialType index)

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.

Just another function... should be easy to make.

The business of an XML shader loader would be:

1) to create IMaterialRenderers when CNullDriver::getMaterialRenderer (or whatever it will be called) asks for one by name
2) to ignore shader files that the current driver can't load, fails to compile, falling back to some other (default or specified) one
3) to create generic, yet efficient callback(s) for the renderers, which pass in the parameters specified by the XML in the correctly named slots.
4) to set up the fixed-function blend modes from the base material

CNullDriver does that by itself in the function, I didnt want to write a loader to save time && you'd say its set out wrong anyway...
point 2, it will attempt to load again but always falls back, should I make it ignore?
as for number 3... yes it does... IDefaultShaderCallBack passes every transform you ever dreamt of, current frame buffer's size, textures and camera FarDistance.
I think it does 4

As for the XML format, I'm not sure about adding all the different shader types in as separate sections, I think it would be better if they were separate files. My idea about just having base and fallback material types could suffer from circular references, but IMO it would be cleaner than potentially having 8 different shader types in one file.

It's not 8 different shaders, but max 5 for glsl or max 3 for hlsl + specify fallback fixed function material. The circular references is why I am not doing it your way... too dangerous

Having the shader code inline would be accomplishable for v0.3 (my rc1) with the above things you specified

[devsh]

Right... Tommorow I am rolling out XML shader system rc-1 with all the corrections, next extensions to irrlicht that I shall be making in hope they go into core... in order of making

-HLSL to GLSL translator
-Hardware Billboards
-Hardware Particles
-Mesh LoD (without LoD-ifier)
-Hardware Skinning
-XML Material System (only if XML shader system makes it into core)
-Generic Post Processing
-Deferred Rendering! (4 types)
-Dual Paraboloid VSM point light shadowmapping
-Paraboloid and perspective hybrid spotlight shadows through VSM
-Mesh LoDifier
-LiPSM shadows with VSM for directional lights
-Trapezoidal shadowmaps if the quality turns out to be ok
-All above shadowmapping with PCF or other for low end HW that cant do VSM
-PSSMLiPSM with VSM (I started that but it got ff***ed with frustum clipping issues)
-GI in deferred render
-Order independent transparency!

[3DModelerMan]

That sounds awesome. I hope they all get in. Will you port them to the DirectX10/11 drivers when they're ready?

[christianclavet]

Wow! That's a lot of stuff your putting on yourself devsh! Thanks for putting so much efforts!

[devsh]

Dont worry its over a whole year at the least.... + one more, I will be doing v.Good water in deferred

ACTUALLY I'M LAYING OFF HW Particles&&Billboards
I WILL BE DEVELOPING SSE VECTORS AND MATRICES (BBOXES ETC ANYTHING OF USE) THROUGH COMPILE FLAG, ALL POST 2000 CPUS WILL BE ABLE TO USE... SPEED INCREASE IN BBOX CULLING, OCTTREES, MATRIX MUL AND ANYTHING 3D WILL BE 2X UP TO 4X EQUALLING ~5% TO YOUR FPS

[devsh]

SSE didnt bring improvements therefore I shall be resuming work on HLSL to GLSL and HW billboards

[3DModelerMan]

I just saw two awesome things you could try
http://developer.amd.com/samples/demos/ ... Demos.aspx