Using IAttributes on SMaterial and removing E_MATERIAL_TYPE

[pippy3]

If each material was a collection of OpenGL shaders, DirectX shaders and face rendering options it would make it easier to "envision" how internally irrlicht deals with materials.

Advantages:
- easier to define fall back behavior
- swapping cool effects and shaders easier
- future irrlicht mesh formats can easily describe custom materials (eg, shimmer effect on wings of irrlicht fairy)
- gives ground for an ogre3d like cross api shader compiler


The reason why I thought this was EMT_PARALLAX_MAP_TRANSPARENT_ADD_COLOR stands out of the materials used by irrlicht. Having some shader level materials while millions of effects don't feels like it breaks the purity of the engine. Of course they'd still be these materials internally, they'd just be defined differently. (Perhaps not their own class, but a new SMaterial that gets created when the material gets made, internally filling in the IAttributes)

Idea I'm throwing around, I can already think of many draw backs; such as if per material pixel-shaders would be wise.

[bitplane]

I also like this idea, material parameters should certainly be part of the SMaterial struct even if the shaders themselves aren't (we need to be careful about compiling too many). The only problem I see is the potential performance of IAttributes and copying SMaterials around. However, since Hybrid made everything const-correct and added the texture layers, minimal SMaterial copying happens in the engine.

Do you have a design idea? How would serialization work? Lightfeather did something similar when they forked, maybe we can draw some ideas from their design.

[3DModelerMan]

Another material improvement we could use is semantic keywords (if that's even possible). Like instead of having to create animation callbacks for everything in DirectX we just bind it like we can with "TEXCOORD" and "COLOR" already does. Except it would be "AMBIENT" or "SPECULAR" or even "MATERIAL_TYPE_PARAM_1". And I really like pippy3's idea. It sounds like a really good solution.

[pippy3]

After a little research I think both Source and Unreal have their own format for defining material properties and shader variables. In Unreal if the user specifies a bump map or similar the engine will use internal higher shaders to render it. In Source the user can write their own pseudo-programming-language to specify material properties. This is similar to what I was suggesting.

Ogre's material class looks like dog food. It's so horrid I don't even want to know how it works, what if the user sets two incompatible shader values? not the right approach. I'd imagine the material would switch between internal shaders according to what function call happened last.

Lightfeathers is very clean. Very professional looking API, it works by having the user create a render state that will get registered by the engine, then specified internally. No idea if it's serializable though. I really like that approach.



How I'd takle the problem is having a IMaterialCollection. Some shader states (EG, EMT_SOLID will always be there and can't be removed. While others optionally can) The driver would have a function to register a SMaterial. This Material will extend IAttributeExchangingObject that takes in OpenGL and DX Vertex and pixel shaders, a map of custom variables and the fall back order. Instead of specifying a MaterialType upon creating a material, the user would specify a string or ID that would be looked up in IMaterialCollection.

Ha, while writing this I found that crystal space actually implements it this way. Not sure if we can trust those guys though

Draw methods and shaders aren't my forte, so I'm making many assumptions. Iterating through a material collection during draw time may have a massive impact on the performance, though I'd assume that there'd be optimizations to this.

[hybrid]

Well, i tmight be not that clear. But actually it's already in Irrlicht to some extent. You use the EMT_ enumerator and material ids to reference the actual material implementation. Those can be registered with the engine. You can use a specific fallback scheme in your registration process for different shader support.
There are for sure several thing missing in the material system. But I'm not sure if a completely different approach would be necessary.

[pippy3]

My suggestion was just a stab in the dark, I don't know the best way to tackle the problem.

I don't feel the modifications would completely change the way irrlicht handles materials, it would change the way it initiates them.

One possibility is simply integrating it tightly into irrcg (I think it's been added to the engine, right?).

By having irrlicht manage the lights, paramaters and other variables into post processing shaders it would streamline the process of creating modern, robust and most importantly good looking materials. I'd love to see a Hello World for irrlicht that loaded a single file - that shot down all other graphics engines. Shaders smoothing the skin, shimmer & refraction on the wings and rough realistic clothes. With pc0der et al working on reworking the mesh system it would be the perfect time to integrate the two together in preparation for the 1.8 release of the engine.

[pippy3]

I've played around with nvidia's cg and I'm very impressed. It's exactly what I wanted over a year ago when I was getting into irrlicht.

Though I'm getting sidetracked. I'll retract my statement about "integrating [irrlicht] tightly into irrcg" as I now realize it has a completely different licence, requires it to be separate lib and wrappers do the work anyway.


Instead consider:

Code: Select all

SMaterial
 SMaterial* fallback;
 stringc name;
 SMaterialShader shader;

SMaterialShader will just be a class that contains a shader string and some other data. If the string is set, depending on the driver, or a custom override it will switch to the GLSL or HLSL or custom shader. The other data would contain how many textures, reflection, etc.

Imagine how handy that would be, a custom reflection shader with fall back material of EMT_TRANSPARENT_REFLECTION_2_LAYER?