I am doing a port of Assimp to Java here
I am dealing now with materials.. Assimp have a quite complicate structure imho (and they themselves also say it: it's an ugly macro for historical reasons, don't ask)
These are the relevant C classes:
In the docs, you can have a overview about the possible different properties..
Properties range, for example, from different AiColor3D Colors to several int ShadingModels or several AiString Texture types.. and so on
So basically with the AiMaterialProperty name we refer to a very different range of material properties..
And like this wasn't enough, each property may be an array of values, controlled by the const unsigned int pNumValues argument.
I alread wrote something, but it is crap and I really don't like it. I just wrote it down what was my really first idea, that is essentially having a MaterialProperty that holds all the different types (String, int, float, etc) and only the relevant one will actually store the value of the given property..
Now I would like to improve it and I was thinking to have a base class AiMaterialProperty and then extend it based on the property type (AiString, AiColor3D, int, boolean, float, AiVector3D) such as AiMaterialPropertyString, etc..
Then I was planning to have a enum variable holding the materialKey, (everything that starts basically with AI_MATKEY in the material.h..
The problem is that some properties, like SHADING_MODEL, are enums on their turn... And since in Java enums cannot extend other enums I was kind of stuck..
So, I'd like to probe if anyone out there has a better idea regarding which structure would fit it at best for Java
