Material/Light bug in .NET wrapper? Niko help please

Irrlicht.Net is no longer developed or supported, Irrlicht.Net Cross Platform is a much more complete wrapper. Please ask your C# related questions on their forums first.
Locked
crodude

Material/Light bug in .NET wrapper? Niko help please

Post by crodude »

When coding a bit I've discovered that when I create a new material like this(C#):
// Create and set material
this.m_MaterialSolid = new Material();
this.m_MaterialSolid.AmbientColor = new Irrlicht.Video.Color(255, 80, 80, 80);
this.m_MaterialSolid.DiffuseColor = new Irrlicht.Video.Color(255, 128, 128, 128);
this.m_MaterialSolid.Texture1 = this.m_ColorImage.Texture;
this.m_MaterialSolid.EmissiveColor.Set(0,0,0,0);
this.m_MaterialSolid.Type = Irrlicht.Video.MaterialType.SOLID;

this.m_MaterialSolid.GouraudShading = true;
this.m_MaterialSolid.Shininess = 50;

and after that I put this material on the ISceneNode object like this:
this.m_ModelNode.SetMaterial(0, this.m_MaterialSolid);

and after tweaking some material parameters on a first created material(this.m_MaterialSolid), material changes doesn't reflect on a ISceneNode onto which this material has been referenced.
Material changes happens only if I acces the material through node (like this):
this.m_ModelNode.SetMaterialFlag(Irrlicht.Video.MaterialFlag.ANISOTROPIC_FILTER, filtering);

After a few minutes of investigating, I've realized that these(that should be the same material reference) are two instances of a Material class.

I took some time to look into the wrapper source code and found that in NativeConverter class, getNETMaterial function actually creates a new managed object of Material type of a passed native irr::video::SMaterial. Also, managed material class has been implemented as __value not _gc.

Same thing is done getNativeMaterial where a new irr::video::SMaterial is created and populated with parameters from a passed managed Material object.

All this is the same for a Light class.

Is this how it should be? It's really strange to do something like that since it would be more natural (and easier to use) for these classes to be of a reference type.

Here is a suggestion how would I like implement Material and Light class in the wrapper:
- Do it like a ITextrure, ISceneNode (__gc class)
- CONSTRUCTOR 1: Create and instance of irr::video::SMaterial in a constructor of managed Material and set it to private NativeMaterial* member which will hold the pointer to a native material structure.
- This way all managed material properties should be acceses like:
NativeMaterial->AnisotropicFilter etc. (same thing like in other GC classes)
- CONSTRUCTOR 2: Material(irr::video::Material* realMaterial). This is a standard constructor as in ITexture and similar __gc classes.
- Create property get_NativeMaterial to which gets the pointer to a native material for other Irrlicht classes to be able to use it. This way getNativeMaterial in a NativeConverter class could be removed.
- In a NativeConverter class in a getNETMaterial function, there should be instantiated a new managed Material object with CONSTRUCTOR 2 by passing a pointer to a native material structure.
- And ofcourse, update all calls to these functions in a NativeConverter class with a new implementation not to break the wrapper.

Well these are my thoughts. Doing something like this in a wrapper wouldn't break and code guys on this forums do since all changes would be done inside it without external changes. Coding would be more NET way and more pleasant doing this kind of implemetation for this two classes.
NOTE: I'm not a regular C++ coder so implementation like this could be wrong. Niko please respond with advice of some kind.
I could try to do this changes and compile a dll for a testing purposes, but I would like to hear from You first if this could be possible and wise.

Thanks! See ya!
:lol:
Locked