Material Definitions Per Entity

Hi all,

I am pondering the idea of creating an XML format that loads materials into the spatial of an entity. This could be useful for having 2 identical entities, 1 spatial definition, 2 different textures.



This .mat file could also load lighting, material states, vertex/fragment programs…etc into the Entity so as to give that spatial a different look. But not different vertices, texture coordinates or normals. That could be handled by a different model, e.g. the .jme format.



This could also be used to set actions and behaviours to different parts of this entity. E.g. To make a light flicker (inspired by the UT3 demo). And when a physics API is introduces, it could be added to that as well.



What do you think?



DP

"DarkProphet" wrote:
Hi all,
I am pondering the idea of creating an XML format that loads materials into the spatial of an entity. This could be useful for having 2 identical entities, 1 spatial definition, 2 different textures.

You can do that now. First make an xml file that contains the vertexes. Now make a new xml file for each of the textures. In each of theas files have a root node that contents the texturestate and JMEFile node loading the mesh. If I am not clear tell me I will try to clarify myself.

I would support having contraers for states that would do what you want with lights.

i know we can do it that way. But That means we have to load them using 2 seperate IO operations. My idea was to load only once, and use different textures. No vertex definitions, no normal definitions, no texture coordinate definition, no animation definitions. Just pure textures, behaviours, and actions:



<material name="bus" />
  <model src="com/data/models/bus.jme" />
  <texture src="com/data/models/bus_1.tga />
  <texture type="sphereENV" src="com/data/env/sky.tga />

  <lights>
  <pointLight name="pl">
  <ambient>1.0 1.0 1.0 0.5</ambient>
  </lights>

  <behaviours>
    <behaviour name="flickering light" executeEvery="0.2">
      public void doUpdate(float time) {
        FlickeringLight fe = new FlickeringLight(pl);
        parentEntity.setBehaviour(fe);
      }
    </behaviour>
  </behaviours>

  <behaviourDefinitions>
     <definition name="FlickeringEntity>
        private Light light;
        public FlickeringEntity(Light l){
          light = l;
        }

        public void doBehaviour(float time, Entity parent) {
          FlickerLight();
        }
       
     </definition>
  </behaviourDefinitions>
</material>



This is like that, not like the .jme specs.

If you can still see similarities, please let me know.

DP

OGRE dose what you are describing. Other people suggested the same thing previously on the form and they decided to use the method we have now. I personally do not care which method jme uses but I think that it is not worth the time to implement the new mode. Cep21 is currently working on multitextures, which would be one more thing that will be implemented. I also think that it would be bad policy to have code in a xml file, instead I think that you should put all the flickering code inside a controller and put a reference to the controller inside the xml file.