Request: let overridematerial override materialtype

[hendu]

It could be useful to let overridematerial also override the material type. For example would make it easier to do deferred rendering on top of irr, removing the need to traverse the scene node tree or to hack the scene manager.

[hybrid]

Yes, this should be an option. But I left it out so far as this will need more testing. Maybe try it out on your own, and tell us how good or bad it works out.

[hendu]

It "just works"

This wouldn't apply against trunk (it's for 1.7, trunk has more EMF flags), but it's only two lines:

Code: Select all

--- a/include/EMaterialFlags.h
+++ b/include/EMaterialFlags.h
@@ -75,7 +75,10 @@ namespace video
                EMF_COLOR_MASK = 0x8000,
 
                //! ColorMaterial enum for vertex color interpretation
-               EMF_COLOR_MATERIAL = 0x10000
+               EMF_COLOR_MATERIAL = 0x10000,
+
+               //! MaterialType override
+               EMF_MATERIAL_TYPE = 0x20000
        };
 
 } // end namespace video
diff --git a/include/IVideoDriver.h b/include/IVideoDriver.h
index b807a85..ad227c7 100644
--- a/include/IVideoDriver.h
+++ b/include/IVideoDriver.h
@@ -191,6 +191,7 @@ namespace video
                                                        material.TextureLayer[0].TextureWrapU = Material.TextureLayer[0].TextureWrapU;
                                                        material.TextureLayer[0].TextureWrapV = Material.TextureLayer[0].TextureWrapV;
                                                        break;
+                                               case EMF_MATERIAL_TYPE: material.MaterialType = Material.MaterialType; break;
                                                }
                                        }
                                }

Client changes were:

Code: Select all

                        driver->beginScene();
 
                        drv->setRenderTarget(mrt);
-                       node->setMaterialType((E_MATERIAL_TYPE) normshader);
+                       drv->getOverrideMaterial().EnableFlags = EMF_MATERIAL_TYPE;
+                       drv->getOverrideMaterial().EnablePasses = ESNRP_SOLID;
+                       drv->getOverrideMaterial().Material.MaterialType = (E_MATERIAL_TYPE) normshader;
                        smgr->drawAll();
+                       drv->getOverrideMaterial().EnablePasses = 0;

It would be useful to have a flag "drawpasses" to have the scene manager only draw the mentioned ones, for example camera and solid. For me the scene manager only manages the solid objects, so it's not a problem right now. Will create a separate thread for this request.

[hybrid]

We cannot apply such changes to the 1.7 branch, if you want to improve it please make the patch against trunk.

[hendu]

Certainly. I use 1.7 as it's what we're shipping (stable, if you wish), I understand it's in maintenance mode.

With only two lines added, I didn't think a patch would be needed, but will provide such in a few days against trunk.

[hendu]

Patches against trunk:

https://sourceforge.net/tracker/index.p ... tid=540678

[hybrid]

Ok, I checked the patch now. It's not possible to use it as is. We cannot change the enum, because this enum is heavily used elsewhere. Setting the material flag "materialtype" to true or false (this is the API that is currently used for this enum) wouldn't make any sense. So we have to put this flag somewhere else. Maybe another enum for all the other smaterial flags which are not simple booleans.

[Mel]

I am using a similar system, and so far, so good, i have no complains with the approach i chose to override the material type. I don't know if it is optimal or not, what i seek is that it worked, and it does.

It isn't very sophisticated, but it does the work well, And the rest of the engine works well, maybe because it doesn't have any conflict with the materials settings.

Code: Select all

 
void SOverrideMaterial::apply(SMaterial& material)
                {
                        if (Enabled)
                        {
                                material.MaterialType = Material.MaterialType;// <------------------------   Hack Here!!!
                                for (u32 i=0; i<32; ++i)
                                {
                                        const u32 num=(1<<i);
                                        if (EnableFlags & num)
                                        {
                                                switch (num)
                                                {
                                                case EMF_WIREFRAME: material.Wireframe = Material.Wireframe; break;
                                                case EMF_POINTCLOUD: material.PointCloud = Material.PointCloud; break;
                                                case EMF_GOURAUD_SHADING: material.GouraudShading = Material.GouraudShading; break;
                                                case EMF_LIGHTING: material.Lighting = Material.Lighting; break;
                                                case EMF_ZBUFFER: material.ZBuffer = Material.ZBuffer; break;
                                                case EMF_ZWRITE_ENABLE: material.ZWriteEnable = Material.ZWriteEnable; break;
                                                case EMF_BACK_FACE_CULLING: material.BackfaceCulling = Material.BackfaceCulling; break;
                                                case EMF_FRONT_FACE_CULLING: material.FrontfaceCulling = Material.FrontfaceCulling; break;
                                                case EMF_BILINEAR_FILTER: material.TextureLayer[0].BilinearFilter = Material.TextureLayer[0].BilinearFilter; break;
                                                case EMF_TRILINEAR_FILTER: material.TextureLayer[0].TrilinearFilter = Material.TextureLayer[0].TrilinearFilter; break;
                                                case EMF_ANISOTROPIC_FILTER: material.TextureLayer[0].AnisotropicFilter = Material.TextureLayer[0].AnisotropicFilter; break;
                                                case EMF_FOG_ENABLE: material.FogEnable = Material.FogEnable; break;
                                                case EMF_NORMALIZE_NORMALS: material.NormalizeNormals = Material.NormalizeNormals; break;
                                                case EMF_TEXTURE_WRAP:
                                                        material.TextureLayer[0].TextureWrapU = Material.TextureLayer[0].TextureWrapU;
                                                        material.TextureLayer[0].TextureWrapV = Material.TextureLayer[0].TextureWrapV;
                                                        break;
                                                case EMF_ANTI_ALIASING: material.AntiAliasing = Material.AntiAliasing; break;
                                                case EMF_COLOR_MASK: material.ColorMask = Material.ColorMask; break;
                                                case EMF_COLOR_MATERIAL: material.ColorMaterial = Material.ColorMaterial; break;
                                                case EMF_USE_MIP_MAPS: material.UseMipMaps = Material.UseMipMaps; break;
                                                case EMF_BLEND_OPERATION: material.BlendOperation = Material.BlendOperation; break;
                                                case EMF_POLYGON_OFFSET:
                                                        material.PolygonOffsetDirection = Material.PolygonOffsetDirection;
                                                        material.PolygonOffsetFactor = Material.PolygonOffsetFactor; break;
                                                }
                                        }
                                }
                        }
                }
 

Then i simply pick the override material, and change the material type at will. And it works. Maybe because i don't use it anywhere outside the shadowmap generation and i don't use any other settings, but definately, a robust material type override should be a must in the engine, besides the other material override settings.

[hendu]

Ok, I checked the patch now. It's not possible to use it as is. We cannot change the enum, because this enum is heavily used elsewhere. Setting the material flag "materialtype" to true or false (this is the API that is currently used for this enum) wouldn't make any sense. So we have to put this flag somewhere else. Maybe another enum for all the other smaterial flags which are not simple booleans.

The enum is already used for non-booleans, such as EMF_ZBUFFER. Do you mean to move all these to the new one?

[hybrid]

Yes, we have some values which have implicit enable/disable states. ZBUFFER was initially also just an enable/disable flag, which was latter improved to all supported values. For Material type (as well as for the color values, textures, etc.) are simply not possible to give a proper meaning for true/false. So we have to do some other enum for all those flags where we cannot define this enable/disable behavior.
@Mel: This is definitely not possible, it would prohibit many uses of the override material, where just a simple value such as zbuffer shall be changes, but the overall appearance nad material renderer shall be kept.

[REDDemon]

Maybe thinking some possible use of 1 unique material can help to decide the design about it.

I tried to do some nice PP effect wich required a depth texture for work. I figured that redrawing the scene using a white material with no light and black fog(linear fog) rendered a nice grey scale picture that can be used as depth texture. (using the NVIDIA eye radial extension can make it also more realistic!)

For doing that or you use a override material (with some hack) or you add a conditional branch to each custom scene node to switch between standard or depth material (will allow also for a greyscale alpha ref material usefull for vegetation).

Doing depth textures like that in fixed pipeline based hardware is lot faster than using a "depth shader". (40% less time for drawing the depth texture in my tests). Doing that for hardware with unified pipelines have no improvement (that's why I prefer fixed hardware. There are still few things at wich they are faster.. unless you buy the latests really expensive videocards).

[hendu]

Hm, do you really get good-looking results that way? Certainly not correct, but that's not what matters

[Mel]

Are you asking me? Well, this screen is done with that approach.


(the sorcerer model is not mine, the rest is...)

the plane and the sorcerers use shadow mapping, the stage doesn't. I override the shader on the shadow map pass, and simply use the drawall method, but i do it twice, first for the static meshes and after for the animated ones (there aren't animated meshes there, though), after this is done, i disable all the overrides, and render as usual. For my needs, it is enough, and the best of it, it works and i haven't found any trouble using it, but i can't warrant that it will work with other overrides well.

[hendu]

@Mel

I meant REDDemon and his fake-depth texture. But nice to have got another pic out of you

[REDDemon]

the good results depend on the precision required. a 16 bit channel was enough for me I tried SSAO for small scenes and DOF (also 8 bit channel can work) with terrain scene node.
SSAO worked only with NVIDIA eye radial extension (and pretty more fast thanks to the hardware already doing part of the space transformation required). DOF worked also without eyeradial on ATI drivers.

@Mel Amazing screen shot!