The blender exporter is doing a bunch of coordinate space conversions to change the up axis...
So normals and vertices have their axis swapped around....
Additionally, there are attempts to adjust transforms to compensate for this shift, but they don't seem to be consistent.
When exporting the following scene, and importing the result into the three.viewer:
I get this:
There are a number of transformations and coordinate swaps that occur in the exporter, i think in attempts to address peoples preference for default "up" vector. These transformations are spread throughout the exporter, and don't seem completely consistent to me.
I have disabled them in a local branch of the exporter, and I get a solid 1 to 1 correspondence between blender and the three viewer.
You can get my modified exporter here if you want to check it out:
https://github.com/manthrax/three.js/tree/blender-exporter-remove-coordinate-mangling
Here is the screenshot from above, after exporting with the mangling disabled:
(This also has my fixes for multiple materials per mesh.)
Here's a list of issues that I think might stem back to this problem:
I'm not familiar with the blender exporter but we discussed a similar problem right here #11540.
So basically an exporter that produces output in the three.js
format (JSON Object Scene format) needs to ensure that the geometry is expressed in the correct coordinate system.
I'm a little bit confused now why your geometry is imported and rendered correctly even if you removed all coordinate system transformations in the exporter. The default up axis in Blender is Z
. In three.js
it's the Y
axis. So how does this work?
BTW: I agree with you that the blender exporter should change the coordinate system consistently. If this is not the case, we need a fix.
The exporter used to have controls that affected how the axes would be transformed/swapped, but that UI seems to have been changed/been removed in previous revs.
And good catch on my screenshot... I did rotate the scene root in the viewer, to look at it upright. I was focusing more on the relative positions of the objects, but I understand your point.
I'm suspecting that there is more nuance here than I thought... I saw you pinged @WestLangley in that other thread. Perhaps he can provide some insight. :)
I do think there is a case to be made for exposing the transform UI again, or maybe there is some hidden way to enable it?
I'm not sure we need an UI element for choosing e.g. the UP
axis. From my point of view the exporter should always produce the three.js
standard coordinate system.
Just tested some simple _static_ scenes and your exporter seems to work perfectly! Woops was confused for a bit. The axis are still different between blender and threejs.
Maybe the transform UI can be hidden with a tab? Then you can import any object in blender and fix it with the transform options if the axis are different?
@izar89 I think that would be a good solution. Also, fixing the existing functionality seems important.
Here's a copy of the .blend that shows the problem, and the resulting export...
I'm not sure we need an UI element for choosing e.g. the
UP
axis. From my point of view the exporter should always produce thethree.js
standard coordinate system.
Agreed.
Here is a simpler illustration of the buggy behavior: @Mugen87 @mrdoob
And the blend file:
Here's an example where the arrows are parented tip to tail, and each is rotated 25 degrees inward:
in blender:
and in the three viewer:
Here is the blend, and exported json:
馃
Just chiming in; https://github.com/mrdoob/three.js/issues/11803#issuecomment-316826354 I mean... that looks totally broken to me.
Yeah me too.. It definitely needs some love.
I also would not be sad if there was a checkbox to allow passthrough exporting without touching vertices/transforms, for when you really just want the actual data as it is in blender.. but that is another topic.
Yeah me too.. It definitely needs some love.
Any takers? 馃槆
I'm looking at it....
I think there is some confusion in the exporter, or maybe some legacy code that is transforming vertices and normals, in addition to the code transforming matrices for Y up...
There is special case logic for different export scenarios.
By disabling the vertex/normal remapping, but leaving the matrix remapping as is, it seems to produce the correct output:
I'm going to stare at it a bit more, but this might be an easy fix.
@Mugen87
After reading the code further, simply disabling the coordinate axis flipping will touch many other parts of the exporter, so I'll need to do a bunch more reading/testing to figure out exactly what is going on...
Particularly for skinned meshes and possibly morph targets.
The JSON Blender exporter has been removed with R93
(#14117).
Also see: https://threejs.org/docs/#manual/introduction/Loading-3D-models
Most helpful comment
I'm looking at it....
I think there is some confusion in the exporter, or maybe some legacy code that is transforming vertices and normals, in addition to the code transforming matrices for Y up...
There is special case logic for different export scenarios.
By disabling the vertex/normal remapping, but leaving the matrix remapping as is, it seems to produce the correct output:
I'm going to stare at it a bit more, but this might be an easy fix.
@Mugen87