I am trying to export custom attributes textures using the babylon.js exporter for 3DS max, but
I bumped into an issue when trying to export the textureMap from custom attributes, the path of the textures gets exported successfully within the gltf in the extras node, but the texture itself is not exported to the textures export location (nor anywhere else).
The exporter simply ignores it.
According to the documentation:
" Texture : The texture is fully exported, including its bitmap. However, the Babylon loader doesn’t interprete the data as a BABYLON.Texture. They are instead row data that can be read or parsed after import."
Here is my simplified material setup, the base color map gets exported, but not the lightmap:
In theory, Texture bitmap are only exported if type of “texturemap”.
Could you share the definition of your webMaterialAttr, and export log ??
Regards
The final goal is to have my three.js gltf importer read the custom attributes and assign them where they belong.
As far as I know, the custom attribute type that I created is of textureMap type, here is the meaningful part in my maxscript so you can see the type (I am aware this is not a forum to help with maxscripts, this is just to give context :
Just mimic your case and reproduce. Have to check why it’s did not export the bitmap itself.
Update : had a look into the code and NO lines are taking care of exporting the extra texture bitmap. @bghgary because it is not implemented, but documented, and because I do not know the history behind. Do we update the code or the documentation ??
If this is a burden don’t worry about me! I have not seen much interest in this feature in the forums anyways
If you can give me some quick guidance in terms of what part of the exporter’s code I need to edit to implement this feature, I can try, and if it works I can send it over so you can publish it.
Hey guy’s,
This is not big at all, but we might decide on some way how to deal with GLB, which is suppose to encompass all the files. I do not know if it’s reasonable, nor standard, to add some additional file into the GLB (which is basically a zip archive).
Otherwise we might setup a call to explain how to deal with the exporter code and focus on the part of interest. But honestly, It might take me more time than doing it by myself. But happy to share some knowledge if @j.franc want to ramp-up.
Okay, I do not wish to waste your time, so if you update the code I will look at the code updates once they go live so that I can learn how you did it, and hopefully, with time I’d love to contribute to this exporter since I use it all the time!
Thanks a lot!
I was referring to this, but I’m not sure this is what we should do. I just re-read the post and I didn’t understand what we were tying to do before. If we want to export something that can be read by a glTF loader, it must be some kind of extension or at least documented in some way. The first step is to create a glTF extension that adds the new textures and how they should be interpreted. Without this, the exported data will be useless since no loader will be able to read it.
Right, this is why i asked. I beleive the use case here is to support a inhouse non norminative extension to allow ThreeJs to load specific data.
I do not know how they achieve that and it sound a very bad pratice.
What I suggest is to export the texture data to gltf, but not glb. As the underlying code let think, the extra attribute capability of the exporter was at the begining dedicated to Babylon format, not GLTF.
It would make sense for it to be exported only in GLTF and not in GLB, it could be a good idea to include a warning in the log in case a user tries to export a custom attribute texture to a GLB.
If there is a custom glTF extension and it uses the typical buffer way to reference external data, then exporting to a GLB will not be an issue. It will just be included in the main BIN chunk of the GLB.