Assimp will lose a huge amount of material information by forcing all materials into a restricted material model (with $clr.diffuse, $clr.ambient, $mat.shininess etc.). For example an FBX exported with Vray materials attached (a very common situation) will store all the Vray material information. But during conversion it will be lost and the materials will be empty.
Rather than (or as well as) expanding the material model to support a specific, but still very restricted PBR implementation. It would be a more general solution to read ALL the material parameters and present them to the user to implement as they wish. Just store the floats, textures, and vectors as name-value pairs that can be queried. regardless whether they make sense in the Assimp material system.
I've started the process in this branch. This stores all the FBX parameters as well as those the material model understand. Unfortunately I've let it code rot a little behind ToT, and it only supports FBX.
https://github.com/griffin2000/assimp/tree/FBXParameters
I think it's a good idea
This would be very useful indeed.
Hi @kimkulling
This feature would be really helpful to us for dealing with models exported to FBX with non-standard materials.
We're considering bringing @griffin2000 's changes to the current master. That would basically consist in using his/her SetShadingPropertiesRaw() method that reads unparsed parameters and stores them with a $raw prefix instead of discarding them altogether.
Would this be reasonable? If we go this way, would you consider reviewing it for merging?
If not possible, we would maintain a custom fork but that's obviously not convenient.
Thanks,
ping @kimkulling
What's your opinion on this matter? Thanks
Most helpful comment
Hi @kimkulling
This feature would be really helpful to us for dealing with models exported to FBX with non-standard materials.
We're considering bringing @griffin2000 's changes to the current master. That would basically consist in using his/her
SetShadingPropertiesRaw()method that reads unparsed parameters and stores them with a$rawprefix instead of discarding them altogether.Would this be reasonable? If we go this way, would you consider reviewing it for merging?
If not possible, we would maintain a custom fork but that's obviously not convenient.
Thanks,