OpenKeeper
OpenKeeper copied to clipboard
tonihele
Figure out decay mechanism of models
Since some of the models have some alternative textures espacially for decay (like campaign map, claimed walls etc.) we need to figure out a clean and easy way to switch between the states instead of just manually trying to find the materialname and loading the material to the model.
There are still not identified flags in the model department, maybe these are the key for this.
Seems like we are missing quite some information on exporting the meshes and materials. Since jmonkey can only store one material per geometry, we need to find a way to hold the relationship between the model and the different materials. Also every model file has an internal model name, which might be very handy to have (afaik we don't export it yet)
Currently the "relationship" is written as a custom key to the loaded model's scene graph. The RANDOM_TEXTURE (variations on rock/gold) already utilizes this.
The problem is that the models are separate from the actual data records. And we access both on separate occasions. Data records on every level load, and models only once. But I guess this is only logical. We just need the models to adapt.
The documentation for jmonkeyengine says that it is not necessary for each texture to do material. Material determines the the other quality of object than texture. E.g. rock not glow from light but metall yes.
Well then we would need to figure out all the kinds of different materials dk has and only save them once instead for every material entry. Would probably save quite a lot space and time converting them, but makes the process rather complicated and we would need to store the material-texture combination somehow.
From what I understood that @ArchDemons is trying to do a material definition that can take take these additional textures as parameters. And with a flag, change which one is active. This would make the material definition similar to what DK II data feeds us. This material definition should derive from the lightning definition perhaps.
For future's sake every alternative texture should have its normal, light etc. map for enhancements. If they can't be done as such, then the only option is to have separate materials.
DK II has more materials than the 1000 we save. The values are very different with each model. I noticed this and limited the material equals to just the texture if I remember correctly. And as said, some material values can vary with the game levels and are not saved, instead set at run time.
The reason for saving the materials is to easily let us play & experiment with the materials so that the changes are persistent. And come be achieved with artistic knowledge only :)
Also I would make "tagged" as a flag to the material. That would shader the colored layer when activated.
So, diffuse1..3 (must check the max amount) with 2 flags (textureCount, textureInUse). decay1..3 (check the max amount) with 2 flags (decayCount, decayLevel). Decay overrides the set texture as default diffuse, normal, etc. map. And the tagged flag.
The custom bits in the material should be clearly marked, should we update it to newer default JME lightning material.
Is that all?
I guess it would be worth to try out. At least it would be better than the actual behaviour.
Currently the terrain has decay implemented, not very pretty. Just mentioning in case if somebody wants to take a stab at this.