Is it me alone?
When i upload a babylon file (with multiple objects) in the sanbox and
then directly export it as glb.
The transform position values are chanced. what was
(transform position) Z -44.776 in the babylon file is now
(transform position) Z 44.776 in the glb file.
Can you do a test yourself with a babylon file with mutiple objects?
Thanks Fit
I know coordinates must be transformed when loading a gltf/glb because itâs a right handed system but I donât know if the exporter should âun-correctâ thisâŚ
Today I did a test with a few cubes in blender and imported and exported it out in sandbox as GLB that was fine no errors there.
Then I uploaded my babylon file again (note this was made by 3d max designer) and the same problem. Load babylon in sandbox and directly out to glb, resulting in a switch of the negative number into a positive number on the transform z location.
But since a blender file with a few cubes in sandbox Babylon to GLB exporter went fine. I donât know what the problem is at this point.
The file has 60+ internal objects it canât be corrected when al the Z location positive numbers (only) are now turned into negative to positive numbers. Even if you export it out again with Blender to babylon with or without the Blender âpreserve z-upâ option. You end up with all the Z location positive numbers turning into Z location negative numbers.or you end up with the Z location correct but X and Y location are now transformed in the opposite.
So it really needs to be âAs isâ when its coming out of sandbox as glb.
updated my earlier comment.
adding @Drigax who is our masterchief for glb generation
That sounds like expected behavior. Babylon.js by default is a left handed coordinate system, and Blender/glTF use right handed coordnate systems to define their space. When we export from babylon.js -> glTF we invert the Z axis and apply rotation to make sure that the objects are spatially equivalent. You should find that the world position of your scene exported via glb and the original scene are equivalent, even if the local positions are inverted.
You can test this by setting scene.useRightHandedCoordinates = true to use a right handed coordinate system instead, and the mesh local positions should match what you see in the glTF
Otherwise please feel free to make a playground demonstrating any disparity.
@Drigez - âYou should find that the world position of your scene exported via glb and the original scene are equivalent, even if the local positions are inverted.â
They are equivalent. But somebody dropped me a .babylon file and need it afterwards back with the same XYZ location coordinates.
At least when your GLB is one on one with a .babylon file that is possible.
P.s. I cant make a PG that file is private.
@Fit
As @Drigax explained,
Itâs two different formats, two different coordinate systems,
in GLTF & GLB right-handed system, z is inverted compared to .Babylon left-handed system
Edit
I believe the babylon file format is as old as babylonjs itself (at least very close to) and of course it uses a left-handed coordinate system like babylonJs does,
GLTF/GLB came years later and sadly decided on a right-handed coordinate system, thus is difference 
@aWeirdo
Yes I get that but Blender and Babylon are here to stay and my example is not isolated to me alone.
I guess it would be great if the sandbox had an extra GLB exporter option to choose L or R handed.
Can we explore this a bit, why do the local positions need to be the same? Can you expand on your use case a bit more so we can better understand your needs?
I have a .babylon file and have to make some chances and also add some objects.
To start I need Sandbox ro do a GLB conversion to load into Blender.
So at this point the transformation numbers of the Z-location are swapped from its original negative to positive. I could work with that in certain situations but the file has to many linked material and textures etc .
So here starts my problem
(Note, the original file is send without any attached material/txter files.)
As far as I know the GLB conversion skips the naming (so sandbox renders out a GLB with its own naming like âmat 1 ,2 ,3 etc.â instead of the internal naming, there is more that donât match or is skipped (have to look that up).
In short my GLB file is useless to work on if you need to send it back as an exported .GLB or .babylon file because they cant only read parts since all the original naming is gone.
Work-around
So my option would be to use the data what is chanced after Iâam finished working on it and then pass those modified data bits into the original file.
For that you need a GLB from sandbox that is one on one in its data.
Even if you use Blenders BJS exporter âpreserve z-upâ option that will chance
all XYZ locations not the Z only. (Iâam not guessing but literally tried all off that and more)
Iâam also wondering, (even if the original scene would be equivalent when the local
positions are inverted) if that has an effect on the UVs coordinates when you combine multiple objects from different L and R hand systems into a blender file. For example when you add an objects in a blender file coming from an external L or R hand system and then chance its XYZ location would the UV coordinates still follow the same XYZ coordinates of the object?
On a more general note
Exchanging files between multiple persons where everyone is on a different L/R handed system with a GLB converter in the middle which only renders out L hand data to choose from, can make the whole workflow over-complex and even obsolete when your in need of exact data. Although for more appropriate situations the L hand automation is also brilliant.
If you send a personal PM address I can send you the file Iam working on.
Fit
Ok, so we want to convert a .babylon file to glb, load into blender, modify the file, and reload into your scene?
That might not be a maintainable workflow without some flexibility on the part of the artist since youâre putting yourself at the mercy of two engines, two file formats, three importers and two exporters. If youâre loading a .babylon file into a babylon scene for usage, thatâs fine, that should work as you expect but as soon as you want to bring that file into a DCC tool for further edits, its not necessarily a realistic expectation that everything in your new format, or even the same scene round tripped through glTF via babylon or blender to be identical to the input format.
Your only real guarantee here is that everything should look identical, but the data may not necessarily be preserved once your application consumes it, ESPECIALLY when you take in data of a given format and convert it to another format. You are now bound to the rules of your new format. As I would expect a blender file I give to someone else to use in blender to be preserved, I canât expect a glTF that I create from a blender scene to be a 100% one-to-one representation of the original scene, it should just be expected to perform identically when loaded into another engine that supports the format.
Your expectations might need to be adjusted from âeverything is identicalâ to âeverything should load and look identicalâ. I would expect that my scene as it appears in Babylon and exported to .glb should look identical in Blender, or re-imported into Babylon from the .glb. Material namings may change, and object hierarchy may change, but the scene should still be functionally equivalent outside of coordinate system shenanigans.
To answer your other question regarding UV coordinate systems, I believe that glTF uses a top down texture coordinate system, while babylon uses a bottom-up, so UVs may not be 1-1 preserved as well.
Are you scripting anything in blender that is dependent on your object locations? Why does the local space transform changes break your workflow even though the world space is correct?
Also, is this a one time conversion you need to make or are you hoping to use a whole library of babylon objects that need to be roundtripped through babylon and blender?
Hello Drigax ,
That is not what I expect at all,
As I wrote earlier posts it would be very helpful if the sandbox converter had an GLB âoptionâ to keep the z-up location âas isâ.
For this file I am not using Babylon JS,
I relceve a file convert it in SB as GLB work on it in Blender and send it back to the owner. Not to unusual.
For the reason why. I wrote that in the earlier post.
But in short the SandBox is in the middle of it all and its very hard to reverse âonlyâ the z-location data if a file has 50 object, materials links etc.
no not at all, It was a desperate request from a client.
Is this really an isolated and unique situation?
Iâm just struggling to understand the necessity is all Again if you can provide a sample, that would definitely end this debate 100%.
Also I believe you can work around this by loading your .babylon file into a scene/playground with scene.useRightHandedSystem = true to avoid our coordinate space transformation.
@Drigax Ok let me send you the file first, to avoid further 
which pm address.
feel free to send me a private message with the file attached
GLB uses Y-up as babylon does, difference is the direction of Z axis (commonly used as the depth axis) when compared to the X axis (commonly used as sideways axis),
GLB uses an inverted Z axis direction compared to babylon 
And when importing to blender, they again should be converting the data to fit their coordinate systemâŚ
So if the Z-axis is not inverted by the exporter,
the entire exported scene will be wrong / visually flipped along z axis when comparing it to the original,
E.g. A face mesh looking towards the camera in the .babylon file will look away from the camera in the non-inverted glbâŚ
This is why weâre having a hard time understanding 
Yes I did get that already before i stated this topic but i stumbled on a problem
i wiil post that after the weekend but very good described anyway.