With the serialize() & Parse() methods inside TransformNode, I am making an assumption that this stuff can be put on a .BABYLON file. If so where?
Code so stratified in this area, I do not even know where to look anymore. The Documentation on the format, The .babylon File Format | Babylon.js Documentation, fails a TransformNode word search.
Exporting Blender Empties to TransformNodes is likely to happen, at least for my code generator. If there is NOT an import path for a .BABYLON, where it will not just be ignored, then I’ll just keep it to myself.
A quick look at doc & there is a link to the source code, so I can read that to get the answer. It has moved so many times, I will not even waste the time looking for it anymore.
Oh no. @PatrickRyan I think this could be a nice area of improvment and @RaananW, I am wondering how we could automate this part if possible ?
Automate this…
This could happen only if we move the documentation to the monorepo, and force changes to the docs, if touching specific functions 
I don’t mind looking into it, but as long as the two repos are separated, it will always be a race condition between updating docs and updating code.
ohhh I was not even thinking that far but more like the code doc we have
oh, i thought the automation was regarding updating the doc page with the right information. Code doc - of course. We can talk about it internally
Ok, you guys have turned this into something else from the original, which is fine. I’ll just change it to something else still.
I have done my changes for the code generator, which I usually do first, anyway. Found out that to do this for the .BABYLON format without losing functionality of recent changes put in by someone else, there would need to be metadata for TransformNodes loaded. metaData is defined in its super class, Node, so it seems like it would get read if in the export, though I have never tested this.
Currently though, Blender Empties are already being exported as Meshes which are missing positions, normals, & indices. (TransformNodes did not exist when the exporter was written). isVisible is set to false, so any overhead saved in the Render loop would be insignificant.
My current feeling is the gain is not worth the changes required to any post load code, so for anyone asking in the future if this will be done, the answer is probably No. Empty meshes are near as good.
I do not care right now about back compatibility in my own work. I am using this to be able to generate ever more code. I actually have a tree of BABYLON.TransformNode subclasses, thus I am using this to inject functionality, not trying to save crumbs of efficiency.
FYI, I have a PR waiting for review. No hurry, but don’t forget.