I don’t think so. I think the obj file is correct. It’s your glb/gltf that once imported in blender using the right-handed system of blender, displays mirrored. I never tried the export, so I don’t know whether this is a bug or just unhandled behavior on export. On import, BJS creates a parent and fixes the transform through a minus scaling on the Z-axis and Math.PI on the Y- axis to face the camera/scene. On export, probably it doesn’t, I didn’t check on it. But apparently, from your screenshot, it doesn’t.
The workaround would be to apply the conversion manually before export I believe. May be this export thingy can be improved somehow. May be you’ll have to wait a little because 1)it’s sunday 2) there’s a code freeze until the launch of v7.
Meanwhile, enjoy your weekend
AFAIK, there is no forward convention specified in OBJ, so there isn’t a right way to export an OBJ, but we should try to be consistent with the ecosystem if possible. Does the OBJ import into Babylon sandbox in the same orientation?
I did a few more test with this playground: https://playground.babylonjs.com/#JTLL3M#11 , adding the axis as tube to see a bit better what it happening, the shorter tube is the X axis, the bigger one is the Z axis in babylonjs coordinates system
OBJ file: The X axis is the same as in babylon.js, and the Z and Y axis has been swapped , the object is the same, but the camera is from the other side
I am not sure what to think of all this to be honest:
I am wondering why when you export in GLB with babylonjs and then open it again in the sandbox the camera is reversed ?
Might have a bug with the OBJ import that mirror the model ?
regarding consistency between OBJ and GLB exports (what I am looking for), I could either rotate the scene 180 before exporting in GLB or in OBJ and I think I would reach what I want… maybe we could add an option in the exporter to follow some convention or not ?
Thanks a lot for the help and the work on babylon.js
Right-handed vs left-handed coordinates system. In Babylon.js terms, the scene defaults to left-handed. You can change it to right-handed by doing this scene.useRightHandedSystem = true. Both glTF and OBJ are right-handed. It appears the obj exporter in Babylon.js converts to right-handed by only inverting Z position, which I don’t think is going to work for all cases, but I think it is okay for your case.
Babylon.js is Y-up. glTF is Y-up. OBJ, AFAICT, does not specify which way is up. Blender, IIRC, is Z-up. This might have some implications on what’s going on with the axes.
Forward convention (i.e., which way is front). glTF is the only one that specifies, but Babylon.js also implicitly defines this in order for the exporters to know what to do.
This is a combination of the handedness and forward convention.
Possibly, but we should rule out some of the problems. Maybe try doing everything with Babylon.js in right-handed system to see if we can at least rule that one out?
If I set my scene to useRightHandedSystem = true the exports are consistent. Importing in blender both GLB scene and OBJ scene result to the same scene.
I used this code to convert all my meshes after setting: useRightHandedSystem = true :
And I get the same scene with the rightHanded coordinate system.
I do think there is a bug with the import OBJ function in the playground, because when importing back the scene (exported with useRightHanded) in the playground , I get the object mirrored on the X axis
I hope this is not going to mess with my current settings, is it? I’m not using the exporter but I do import lots of OBJ and I wouldn’t like my scene breaking just before the imminent launch (because it says ‘breaking change’)
This will probably break your scene, as the objects will be mirrored (maybe not if you use scene.useRightHandedSystem = true). You should stick to one version before the PR is merged for your release, and update your code afterwards.
I don’t use right-handed. OBJ is my standard and else everything from my demos are pure BJS (left-handed)
I can’t say I like this answer but thanks a lot for the warning .
I will retrieve the latest version library and link my scenes to this until I find the time to conform them to new.
Good thing is that with the launch of v7 I was going to do this anyway.
Bad thing is that, meanwhile, I will not be developing sync with latest
So where do we stand with this? I mean, I know it’s not my role and I have also been warned (by @Evgeni_Popov) that there’s a risk of breaking everything related to .obj import. But that’s just me. If this is really going to happen, shouldn’t you Guys make an announcement to warn the community? Just thinking (sorry to interfere)
I did a temporary fix on my project where I wrapped the models under a transform node and to fix the camera rotation (when it’s animated) I had to create a temporary animation group and multiplied the rotation with 180 on both z and y.
Well, that’s basically what I imagined when I told the poster
but that’s just a fix on export. The way I understand it is that everything is wrong from this handling. Eventually, only a breaking change will let us return to ‘normal condition’. At least, that’s my understanding of this.
No, unfortunately not. I am refactoring the serializer to make this work properly. This won’t make the 7.0 release.
I think if people are concerned by this change, we should add a flag to revert to the old behavior but keep the default the hopefully correct behavior. We are guessing not a lot of people are using obj files since this has been wrong since it was written.
Yes, a breaking change is required to get the default to the correct behavior.
We can announce something if we suspect many people will be affected. @Deltakosh@sebavan Any thoughts?