Active Textures in material

[Nadro]

Hi, in current Irrlicht material renderer we had functions list like this:

Code: Select all

...
Driver->disableTextures(1);
Driver->setActiveTexture(0, material.getTexture(0));
Driver->setBasicRenderStates(material, lastMaterial, resetAllRenderstates);
...

it's OpenGL Solid material renderer. We should change it to:

Code: Select all

..
for(int i = 0; i < MATERIAL_MAX_TEXTURES; i++)
Driver->setActiveTexture(i, material.getTexture(i));

Driver->setBasicRenderStates(material, lastMaterial, resetAllRenderstates);
...

Previous method may cause problem in shaders, because only first texture is active. This problem is eg. visible when we use Cg runtimes and we leave texture manage control for application. Other solution is create special materials with this structure only for shaders eg. EMT_SOLID_S etc, if we need leave current form of material renderers

[devsh]

get this sorted quick... thanks for spotting vital bug NAdro!

[BlindSide]

get this sorted quick... thanks for spotting vital bug NAdro!

I'm not even sure why you're so interested in this. This has nothing to do with your problem because in COpenGLShaderMaterialRenderer it does:

Code: Select all

	for (u32 i=0; i<MATERIAL_MAX_TEXTURES; ++i)
		Driver->setActiveTexture(i, material.getTexture(i));

It seems to be only relevant for implementing custom shader solutions?

We're not going to change EMT_SOLID because this is changing something widely used for a very specific edge case.

I like the idea of creating special base material only for shaders but this requires some consideration and we may as well revamp the entire material system while we're at it, so it'll take a while.

Can you describe "This problem is eg. visible when we use Cg runtimes and we leave texture manage control for application." a little more? Can't you just set the active textures in your CG implementation using DX/OGL calls? I was actually going to make setActiveTexture exposed in the IVideoDriver interface, would this help you?

[Nadro]

Hi,
Yes, for builtin Shader all works good. In Poland was 4 A.M. and I was tried, so I forgot check shader renderer Sorry it's my fault I will have to reproduce or use exposed activeTexture in IrrCg and all will be ok

BTW. I think also than expose OpenGL ExtensionHandler eg. similar for D3D Device, so in SExposedVideoData will be ok, but setActiveTexture also will be useful because it usage some private variables for optimization, so reproducted function may be not that fast as original.

[BlindSide]

If you look at the SVN you can see that all drivers derive the same setActiveTexture() from CNullDriver, so until I add it myself you can just copy the virtual function into IVideoDriver and it should work right away.

[Nadro]

If you look at the SVN you can see that all drivers derive the same setActiveTexture() from CNullDriver, so until I add it myself you can just copy the virtual function into IVideoDriver and it should work right away.

Yes, thats right I've done it in my Irrlicht copy and all work very good, when it will be "official" avaiable in Irrlicht SVN, I can will add method with setActiveTexture() to public IrrCg repository. Thanks for help

[hybrid]

Yes, this texture activation thing was implemented to overcome several problems with render state setup. Somewhere around Irrlicht 1.1 we had major problems under OpenGL where the render states were pretty messed up. We need to clean up this texture and render state handling and unify across the drivers. Then we'll see which methods will be made public, and which are only helper functions. Since revoking a method later on makes stuff pretty complicated we will first clean up, and not first give access to all methods.