glTFast
glTFast copied to clipboard
atteneder
Material/Texture Extraction and Matching/Replacement
Is your feature request related to a problem? Please describe.
When exporting materials & textures to a larger project, you might find yourself re-using textures/materials for several objects. Often when importing textures from a different software, such as Blender that uses a completely different render engine, you might need to tweak your materials manually afterwards. Therefore its crucial that the import tool doesnt create duplicates of the materials to allow for this fine tweaking.
When it comes to textures, the obvious is that a single set of textures can be a couple of MB - once you get up into the hundreds of textures it will start to impact your project size by meaningful amounts even for desktop titles where file size isnt super crucial.
Describe the solution you'd like
The exact details of how the reuseability is implemented isnt crucial.
But ideally you would be able to choose individual directories for where to store on a Unity project basis (so you dont have to fill in this info every time you import):
- materials
- textures
- "scenes" or models.
- (animations?)
And when importing it should give you the option to first look for existing materials/textures in the project that matches that of what is in the glTF, either by name or by value (by value, I mean that it checks if the textures/materials are identical despite being potentially named differently).
A nice to have here would be if one could choose to match by both texture/mat name & value. Another common issue when working with Blender is that material duplicates can happen in the blend file from time to time that usually adds a ".001" or ".002" (etc) suffix to the material name. So an option to ignore such a suffix would also be neat.
If a matching texture is found, any materials referencing this texture will be mapped to this pre existing texture in the Unity project, otherwise it will import/create the/a texture based on what is included in the glTF.
Likewise, if a matching material is found, any objects referencing this material will be mapped to this pre existing material in the Unity project, otherwise it will import/create the/a material based on what is included in the glTF.
Describe alternatives you've considered
If anyone have any ideas on how to improve this ticket, feel free to drop a comment💝
Additional context & requirements to satisfy my needs
Its important that the importer remains somewhat fast even for large projects when doing the material matching. The current Unity project that I work on has maybe thousands of assets in it (far too many to even estimate the size of, its a team project that has been in development for 2 years now).
Also
I believe Unreal Engines datasmith could be a nice tool to try out just to see how they handle everything, they use the same concept as Im describing here
Thanks for reading 😁
@ItsCubeTime Thanks for the feedback.
Would the solution the FBX importer offers (extract materials and on-demand re-mapping) suffice for your needs?
@ItsCubeTime Thanks for the feedback.
Would the solution the FBX importer offers (extract materials and on-demand re-mapping) suffice for your needs?
Mostly yes, what I have struggled with most in my current workflow is when the materials get some suffix from Blender, like .001, .002 (etc).
Another thing is that the default importer places a folder of materials right next to the fbx. Personally I dislike this for our "reuseability workflow" and would prefer the materials to go into some specified directory that you choose yourself (that in my case would be dedicated to materials alone, I would want my textures in another, separate, directory). Even more ideal would be if you had the option to choose the folder that the materials/textures gets placed in, but that it can also create a subdir within that folder that has a name of which matched the file name of the gltf.
In the event that the importer finds several materials by the same name in the project, it would also be nice if it could give you a warning (I have already been confused by this myself several times when it choose another material in our project by the same name, that I did not know about) - and ideally a way of prioritizing/choosing what material you want to use out of the available ones (either through that the user gets to prioritize a directory to recursively search for matching materials, or that you get to cherry pick the material you like out of a list of available ones).
@ItsCubeTime I see.
Imho Blender's numbering is not adequate to replace regular versioning (GIT like). Even if it was, that should be a thing the AssetDatabase should take care of, not the importer of a specific format (glTF). You could actually implement that by hooking into AssetDatabase callbacks if you wanted to.
I think you already can export FBX materials into a custom directory (although materials plus textures; not separated).
Your proposed conflict solution is very interactive, which comes with the downside of blocking the UI, potentially a LOT. I kind of prefer the FBX way of picking the best choice automatically and allowing you to change it afterwards
@ItsCubeTime I see.
Imho Blender's numbering is not adequate to replace regular versioning (GIT like). Even if it was, that should be a thing the AssetDatabase should take care of, not the importer of a specific format (glTF). You could actually implement that by hooking into AssetDatabase callbacks if you wanted to.
I think you already can export FBX materials into a custom directory (although materials plus textures; not separated).
Your proposed conflict solution is very interactive, which comes with the downside of blocking the UI, potentially a LOT. I kind of prefer the FBX way of picking the best choice automatically and allowing you to change it afterwards
~~Might be a bit of extra work from your standpoint, but what comes to my mind is just putting tickboxes or enum dropdown menus on everything non-essential, having most semi-advanced features disabled by default.~~
~~As an artist it can be nice not having to dig into customizing the import process through code - but I can def also see its value for someone who considers himself to have the time to do it (unfortunately the project manager has made it clear to me that he doesnt want me to dig into that during paid work hours, so I have been unable to do such things myself).~~
~~I only speak from what I could have good use for right now. But I do think there has to be a decent lot of other people that could benefit from the features Im suggesting (Datasmith is very popular among the Unreal Engine users, mostly what Im mentioning with organization/reuseability capabilities are some of its core features pretty much).~~
Shorter version: My personal opinion is that features never hurt, just keep them optional so they never get in the way! (So I think its better to worry about how much time you can/want to put into making the tools rather than making too many)
Would the solution the FBX importer offers (extract materials and on-demand re-mapping) suffice for your needs?
@atteneder this would be perfect and I have this exact use case in my projects. Just so I know we're 100% on the same page, are you talking about this section here in the FBX importer?
@drjaydenm Yes. I'd also include the Extract Textures/Materials buttons from above.
Just starting to try out GLTF fast and this + #391 have immediately popped up as features we will need. Our use case is mostly interchange (Blender -> Unity) but we will be looking to share the GLB's at runtime too.
I'm not yet on top of the implications of that for materials but am thinking the other application that needs to share the GLB's could implement its own material as we will be using the same materials on all GLB's
