A better material framework

[Jedive]

After playing a lot with the engine, and coming from Blitz3D, I have found the material framework in IrrLicht pretty limited. I know that a rewrite of the material frameowrk is planned, but I have written here a possible new set of methods to control the materials as a suggestion, in a similar way than Blitz3D, because I think that this way is very powerful. You can set the blend mode of each texture and its flags individually, cos it is much more flexible this way, and that I have added possible cube and bump mapping modes. I have ignored pixel or vertex shaders, cos I have never worked with them, and i don't know how they would be added.

The new set of functions would be:

Code: Select all

ITexture::setTextureFlag(video::E_TEXTURE_FLAG flag, bool newValue);
Set the texture to a new flag. Possible values are:
	ETF_ALPHA		Uses the alpha map in the texture.
	ETF_MASK		Does not draw invisible texels (totally transparent ones in the alpha map).
	ETF_SPHERE_MAP		Makes the texture look like if it was reflecting the environment around it.
	ETF_CUBE_MAP		This texture contains a sequence of 6 textures horizontally stripped, which is used as a cubemap.
	ETF_NORMAL_MAP		This texture contains a normal map, used to create bump mapping.
	ETF_SECOND_UV_SET	The texture will use the second UV set of coordinates in the mesh, if present.
	ETF_TEXTURE_FLAG_COUNT	This is not a flag, but a value indicating how much flags there are.

ITexture::setTextureBlend(video::E_TEXTURE_BLEND blendMode);
This sets the way that this texture is blended with the previous texture layer when applied to a material.
	ETB_NULL	The texture is not shown.
	ETB_ALPHA	If the texture has the alpha flag enabled, blend using the alpha map. If it doesn't, does not blend with textures below it.
	ETB_ADD		This texture is added to the previous layer.
	ETB_MODULATE	Standard lightmap technique: This texture is modulated with the previous one, which should be the diffuse texture.
	ETB_MODULATE_X2	Standard lightmap technique: This texture is modulated with the previous one, which should be the diffuse texture. The texture colors are effectively multiplyied by 2 for brightening, like known in DirectX as D3DTOP_MODULATE2X.
	ETB_MODULATE_X4	Standard lightmap technique: This texture is modulated with the previous one, which should be the diffuse texture. The texture colors are effectively multiplyied by 4 for brightening, like known in DirectX as D3DTOP_MODULATE4X.
	EMT_FORCE_32BIT	This value is not used. It only forces this enumeration to compile in 32 bit.

ITexture::setCubeFace(s32 face);
This functions sets the current face for rendering to texture. As the engine treats a cubemap as a single texture, you need some functions to define which is the current face you will use to render or write pixels to. The 'index' parameter is a value from 0 to 5 which indicates the face you will write to.

ISceneNode::setMaterialFlag(video::E_MATERIAL_FLAG flag, bool newValue);
Sets all material flags at once to a new value. Helpful for example, if you want to be the the whole mesh to be lighted by. Possible values are:
	EMF_WIREFRAME		Draw as wireframe or filled triangles? Default: false.
	EMF_GOURAUD_SHADING	Flat or Gouraud shading? Default: true.
	EMF_LIGHTING  		Will this material be lighted? Default: true.
	EMF_ZBUFFER		Is the ZBuffer enabled? Default: true.
	EMF_ZWRITE_ENABLE	May be written to the zbuffer or is it readonly. Default: true. This flag is ignored, if the material type is a transparent type.
	EMF_BACK_FACE_CULLING	Is backfaceculling enabled? Default: true.
	EMF_BILINEAR_FILTER	Is bilinear filtering enabled? Default: true.
	EMF_TRILINEAR_FILTER	Is trilinear filtering enabled? Default: false. If the trilinear filter flag is enabled, the bilinear filtering flag is ignored.
	EMF_FOG_ENABLE		Is fog enabled? Default: false.
	EMF_VERTEX_COLORS	Should vertex colors be used or not? Default: true.
	EMF_VERTEX_ALPHA	Should vertex alpha be used or not? Default: true.
	EMF_MATERIAL_FLAG_COUNT	This is not a flag, but a value indicating how much flags there are.

ISceneNode::setMaterialBlend(video::E_MATERIAL_BLEND blendMode);
Sets the material blend mode of all materials in this scene node to a new blend mode. This sets how the scene node is blended with the scene below it. Possible values are:
	EMB_ALPHA	The scene node is blended using the alpha value of the vertices of its mesh (if it is a mesh and the material flag EMF_VERTEX_ALPHA is enabled). If this flag is not set, the scene node will be opaque (although an alpha texture can modify this).
	EMB_ADD		The scene node is added to the scene below it.
	EMB_MODULATE	This material is modulated with the scene below.
	EMB_MODULATE_X2	This material is modulated with the scene below. The colors are effectively multiplyied by 2 for brightening.
	EMB_MODULATE_X4	This material is modulated with the scene below. The colors are effectively multiplyied by 4 for brightening.
	EMB_FORCE_32BIT	This value is not used. It only forces this enumeration to compile in 32 bit.

This way of handling materials is very different. For example, instead of EMT_LIGHTMAP, EMT_LIGHTMAP_M2 and EMT_LIGHTMAP_M4, you have the different MODULATE modes. If you want to enable vertex lighting, there are no EMT_LIGHTMAP_LIGHTING modes, you enable or disable vertex colors per material with the EMF_VERTEX_ALPHA material flag. Material types does not exist anymore, everything is configured with material flags and blend modes.

[Tels]

" I have ignored pixel or vertex shaders, cos I have never worked with them, and i don't know how they would be added. "

Have a look at http://www.ogre3d.org/ and at their changelog entry from 20.1.2004:

http://cvs.sourceforge.net/viewcvs.py/* ... l?rev=1.14

Excerpt:

# ! This is a subsection of it's own..

* Support for vertex and fragment programs (shaders), including:
o Low-level assembler programs under D3D9 (vs_1_1, vs_2_x, ps_1_x, ps_2_x) and GL (NV_texture_shader, NV_register_combiners, arbvp1, arbfp1, ATI_fragment_shader)
o High-level program support via plugins, so far we support Cg and D3D9 HLSL. Cg compiles down to D3D and GL assembler, and includes converters to non-assembler formats including NV_register_combiners and ATI_fragment_shader so you can write a single program for all targets.
o Support for automatically updated parameter bindings such as 'object space camera position', 'object space light direction' and many more
o Programs can be defined and reused many times with different parameters, all through .material scripts
* Materials now support multiple 'techniques', which can be used as automatic fallbacks for older cards which don't support the requisite features for your preferred shading approach
* Material LOD - you can tell materials to change technique over distance to save rendering power on distant objects; this is subject to the same control parameters (camera bias and entity bias) that is used for mesh LOD so you can tweak it heavily
* Scriptable multipass rendering; you can now specify multiple passes in one material if you wish, and those passes can also be iterated once per light automatically, and the engine will call the pass with each nearby light
* The .material script format has been extensively upgraded to handle all these new options; however if you have 0.12.x or previous scripts you can automatically update them using the OgreMaterialUpgrade tool

# Light management upgraded; you can now have an unlimited number of lights in the scene, and OGRE will pick and use the 'n' closest lights ('n' is configurable per pass in the material scripts) which are within their attenuation range when rendering an object. This makes light management much more practical, especially when using vertex and fragment programs. As mentioned above, passes can even be configured to iterate using the 'n' nearest lights.
# More texture formats supported: we now support 1D textures, compressed textures (DXT formats), volume textures (true 3D textures, not just 6 faces like cube maps), and loading all of the above from the .dds format, even in GL.
# XCode IDE support on Mac OSX

That sounds impressive

Just so that you get some ideas

Cheers,

Tels

[Gorgon Zola]

hi

ogre3d uses the cg-runtime from nvidia. it allows to compile cg programms at runtime and is cross everything (plattform, vender and renderer)

materials in ogre3d have now the possibility to refere to a cg programm which defines the material behaviour (lighting deformation etc.)
This really solves a bunch of problems for lighting and effects.

what about a cg material type for irrlicht?

here's some brainstorm thinking (i have only taken a look at the direct3d9 driver):

the material should have:
- an additional type field
EVT_STANDARD, EVT_2TCOORDS, (for backward compatibility) and EMAT_CG_SHADER for the new shader type
- and an additional structure { const char* file; CGContext context, CGProgramm program ... } holding the cg stuff

- now when rendering setVertextShader and setRenderState? must activate the cgprogramm referenced in the current material.

- the parameters for setVertexShader are hardcoded in the calling programms (drawIndexedTriangle...) this must be changed using the new parameter in the current material

- there must be a clever way to pass parameters to the cg programm.

- and while were at it: maybe we should decide on structure for an xml material serializer which stores and loades material definitions.

- maybe we need vertexbuffers too? i'm not too shure about this since the shader programms just plug in to the render pipeline and are called per vertex/pixel, independent from where they are stored. ( at least i would have made shaders act that way )


so what do You all think about it?

cheers
tom

[PadrinatoR]

I agree with Jedive about changing that framework. I need to be able to change the alpha level of an object!! xDD Blitz3D can do this using its EntityAlpha function but in Irrlicht I've tried to change the DiffuseColor and AmbientoColor but it doesn't work

[Jedive]

You do it with IMeshManipulator::setVertexColorAlpha (IMesh *mesh, s32 alpha);

[PadrinatoR]

tu turuuuuuuuu (thx xDDD)
Anyway, I agree with Jedive xDD

[japito]

I think that the better solution ever is made a specific mesh that could be exported from max etc. keeping materials and other properties as blitz, ogre and much more engines do.

It's it planed for future releases?

[PadrinatoR]

You do it with IMeshManipulator::setVertexColorAlpha (IMesh *mesh, s32 alpha);

Well... I've used that function and I still have problems. I do this:
for(int i=0;i<=m_pMesh->getFrameCount()-1;i++)
m_pSceneManager->getMeshManipulator()->setVertexColorAlpha(m_pMesh->getMesh(i),128);
It should change all vertex alpha color, but some materials stay solid
Then you can see these materials from everywhere, so it seemed a fail of the Z-Buffer, but I think that it isn't.

I've tested 3ds and x file formats... anyone knows what's happening?

[Jedive]

hmm... maybe a bug?

Anyway, coming back to the purpose of this topic... it would be cool to see an "official" announcement about the plans for the new material framework (as niko said there will be one), and if we'll be able to see it for 0.7 or 0.8

[Nessie]

My opinion so far, after looking at IrrLicht for a couple of days now, is that materials are really the biggest weakness. I've only looked at the OpenGL implementation, but I have a couple of thoughts.

1)The code currently tries to minimize GL state changes, which is a good thing. I'd suggest that this shouldn't be wired into the materials system though.

Rather, I think the current state of the renderer should be handled by the "driver"? Naturally, the materials system can then make calls through this function to request a state change...and the driver makes the state change if the renderer currently isn't already in that state.

2) Defaults. It looks like each material type sets up the defaults for that material type. I suppose this would make the engine a bit more friendly to get started with, but for anyone else, it just adds extra unnecessary complexity to the materials code...possibly makes it a touch slower, etc.

I think it would be better to have a simple tool developed that provides a simple model (or allows you to load in a custom model) and allows you to adjust some basic parameters in real-time and see the actual result. From there, the user can save out the explicit settings needed for the custom material type.

While this would take some work to set up, I think the pay-off would be decent enough. People could share material files. Having to set up your materials in code is simplified to specifying some kind of external material definition. The engine material switching code would be simplified and might also run a touch faster.

3) Insert other misc. ideas here, heh.

I have time, energy, and some knowledge about how to do some of this work so I'm willing to help out with making this happen. Naturally, a solid plan needs to be in place first. And if nothing is decided soon, I'm going to have to break down and do my own implementation...which will likely end up being pretty specific to my game...and therefore less useful to other people.

Thoughts? Design suggestions? Feature suggestions? Am I being too pushy?

Honestly though, I'll probably have to do this work anyway....it would be a shame to have it not help anyone else but myself.