The documentation for aiProcess_RemoveRedundantMaterials seems to suggest that if you pass through additional 'user' material properties they won't be considered as part of the processing for reduntant material merging and presumably aiProcess_OptimizeMeshes as well. Is this the case? Why would custom material properties not be part of the identification of duplicate materials?
In my situation, I'm extending the q3bsp importer so that collision information is retained by the process so I can communicate what the collision properties are of the meshes, whether certain models are gameplay/trigger related, etc Other than getting the collision properties out, I also had to change the q3bsp importer so that it didn't destroy the structure of the map file. For example, there are typically many 'submeshes' as part of the bsp file that represents smaller sub objects. A movable platform, or some static object that may be hidden/shown as part of gameplay events. Maintaining these logical groupings are necessary. The preferred solution to this is the same as the materials, I could just put a custom tag on the material "SUBOBJECT"=x. Doing it in this way(provided the post processors consider the meta data as part of identifying mergable materials) would be the easiest way to retain information in a way that doesn't close off the use of certain post processing options.
Even though I may not need to use the post processing optimziations steps in my particular case, this method of getting returning this information needs to be general purpose if it is to be contributed back to other users as I would like to do.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.