-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
axis swapping and .scene #240
Comments
But in a way we are applying this "mega rotation" when exporting the scene by doing the position swapping. |
Hello @paroj, I'll attempt a second try at explaining my position: BlenderOGREAs you can see every rotation and position is respected and in OGRE it looks the same way it looks in Blender. So we have a sort of WYSIWYG (What You Get Is What You See) situation. I think this has always worked becuase if I'm not mistaken this was developed by the Tundra guys and they used the exported scenes. The only thing that is different are lights. The transform that is being performed to the Quaterion does not seem to really be a rotation, but an axis swapping which seemingly is not the same. For example an axis swapping leaves an identity Quaternion identical because x, y and z are 0, but a rotation would change the Quaternion. So, I'm still arguing in favor of leaving the axis swapping of scenes, but adding something to rotate the lights so that they look correct in OGRE (in fact I already did this). |
yes, your proposed solution works in some cases, like the scene above. However, please go back to my initial example of a light and a mesh attached to the same node or this one:
we must apply the rotation to the top-level node so the translation is correct thus we should aim at a solution that works always |
You say that the problem is when someone is putting meshes or other things as children of lights? I don't know why you would put a mesh as a child of a light, it would be better to separate the light. But perhaps it cannot be done in Blender... |
please export this with axis swapping: |
If I export without axis swapping option: 'xyz' (that is, Blender coordinates) And then rotate everything in ogre-meshviewer:
So, it looks properly. BUT, this means that people would have to export everything withoug axis swapping (even meshes), so they are basically exporting meshes with Blenders coordinate system. To me this is too revolutionary 😂 |
OK, I have been trying more exports with this .blend file. You did some wizardy which I don't understand 😂 That Suzanne and Plane have something odd. |
yes, this is what I was arguing for in the issue description |
Then, what do you think of documenting all of this and letting the user choose their misery. If they want the solution of exporting everyting with axis 'xyz' and then rotating in OGRE or exporting everything with 'xz-y' and having to take care of the lights. For example I would choose the 2nd option because I'm used to By the way, here is where it all comes from if you're interested: |
personally, I would hide the axis swapping, if a scene is exported. But as you seem to like that behaviour documenting it is the next best thing we can do. |
when exporting .mesh files, axis swapping optionally bakes-in a rotation, like 90° around x resulting in xz-y.
When exporting .scene, we also have to rotate the nodes for consistency. This poses the following problem:
lets say a car with some headlights.
To apply the xz-y transform, to the light, we must rotate the node as described above. However, currently we also bake the rotation to the mesh, so the transform will be applied twice and the result is wrong.
The easiest solutions (considering multiple cars) is to add an intermediate node as:
this way all entities will be only rotated once.
However, given that the current Ogre API for loading .scene looks like:
https://ogrecave.github.io/ogre/api/14/class_ogre_1_1_scene_node.html#aee2ef1147dd19f9195babeb676da377c
it is trivial to do the swapping in user code as:
therefore, I would just disable swapping when exporting .scene
The text was updated successfully, but these errors were encountered: