Z and Y axis are reversed!


I where a bit shocked that with scripting  Z = Y and Y = Z, thats confusing. Z = always up and down also in blender. sounds like something got mixed up in HiFi. i hope the change that back to the normal x.y.z. not sure why its reversed. This also explains why @judas got problems with blender and the default settings. And now i see why my voxels are placed wrong, because Y and Z are reversed. thats going to be a big error for long time. WIth some googling am finding both systems, but still suggest to reverse the Z and Y so its for most users normal. Also looks like the Z axe for up / down is more common.

most users are now used to this setup,
blender is useing it SL, opensim , sketchup , looks 3dmax is useing it to.

And High fidelity is useing.

So why is High Fidelity useing a weird configuration. and i think i complained about this before. and expect when more users are going to use high fidelity that this is not the last time.


@Richardus here is the answer to a similar question from a couple of months back. https://alphas.highfidelity.io/t/inconsistency-between-myavatar-orientation-myavatar-bodyrol-yaw-pitch-and-the-way-the-avatar-is-drawn-on-screen/641/7

A Y-Up world is very common in gaming packages e.g. Maya and Unity3d. A Z-Up world generally comes from architectural based packages. Neither option is right or wrong you just need to know which one people use. We are Y-Up


You can generally change up direction when exporting with blender. @Chris is correct, most games, 3d studio, maya, etc all use Y=up, Blender, and most cad systems use Z=up, but it’s not really an issue as it can be changed on export. As far as scripting goes, I haven’t done any voxel scripting, but with models, and avatars, up is the Y axis, I imagine voxels are the same.


I believe the Z-up tradition of architecture comes from looking top-down on building-plans/site-maps, which are inherently 2d along the plane of the walking surface. It also makes sense in a flat-grid-based system such as SL/OS.

Most computer-focused-from-the-start applications use Y-up because Y is already defined in the 2D APIs as the vertical of the computer screen and the extra dimension (Z) is extended back. This makes moving between the 2D and 3D APIs easier as X and Y keep their meaning between 2D and 3D API calls.

(I, surface-dwelling being that I am, prefer to think in Z-up, but Y-up is usually better from an API sense).


@glenalec is right with “Z-up tradition of architecture comes from looking top-down on building-plans/site-map”.

I had a little trouble with this at first but when you think about it, this is correct, because.

X is always horizontal, Y is always vertical, and Z is always depth. (thats the rule of thumb in ALL cases, what changes is our perspective)

Looking down on a plan shows the traditional x-y but the depth is up and down, thats fine for overhead views,
but we are standing upright looking forward, and the normal is X along the horizontal,
and Y is the vertical again except now the vertical is up and down, as it should be in normal 3 dimensional view.
And of course Z is our depth of field.

@John_Laury I mentioned this on another thread, but when dealing with animations, if you build with Z up (standard in Blender) then you must export with Z up also or the animations will be wrong. The final corrections can be made inworld either during import or with in the script where you need to apply 270 degrees to the pitch.


That i figured out after some sleep to, just go back to the old days commodore ms-dos. so X and Y make sense and the Z is the remaining side. But blender dont have the option the change Y up :frowning: so you keep working with 2 different axis indicators. take some time, to get used on that. for now i just think about a good commodore 64 screen for the x and y, try to figure out if the not have add the option now in blender. (afraid not) It would be good if the blender people support Y-up there more people that want it. Maby reacted a bit, like eeps. but it need time to get used to this difference between both programs. It makes for me more sense that Y is up now. if you think in 2D monitor screens.


Isn’t is possible to just work in Blender’s Z up system, and when you’re ready to export, rotate the model -90 degrees on the x axis, then in the export options, choose Y=up?


nevermind sorted out a blender workflow :slight_smile:


Thats a suggestion i have read more, but blender have a betetr way. just change the setting in the fbx exporter, thanks to @judas. need to test it still myself.


I think you’ll get the same problem, you rotate the model but the joint rotations are still global, some wont translate right, you would need to change the rotations in the model. Unless there is some way of changing the global axes.

Having said that I have not yet tried to do a rigged avatar in Blender, only models and I dont know if the avatar importer behaves the same as the model importer.
Its easy enough to spin a model because the rotation options are there, but I dont know if there are any rotation options on avatar skeletons which is prob whats causing Judas’s head to explode, but Richardus mentioned something that made me think, the fst file contains rotation info, perhaps we can either import as .fst or if there is an option to modify the fst after upload, or ideally what Judas said, get devs to put in a checkbox on import to allow for all these other third parties that work with Z up.



Re Blender and all the reversal issues, do we know any popular games that use hifis orientation?
I’m wondering if someones already made a python script to flip everything?
i was looking at one for unreal engine but I have no idea which way around that does things


It seems, soifar i know Unity use the same approach as High Fidelity.
with the same problem that users have problems with it. :open_mouth: .


Unity3d is probably the largest game engine out there and it is using it. Probably a good place to start for searching.



Wellllll the newest build the FBX exporter is working correctly (for now)
blender-2.71-4776d80-win64 Fri Sep 5 09:21:29 2014

I tried it using an animated character made and rigged in blender and all the default settings.
It arrived in HIFI standing up facing forward and animated the same as in Blender
So Its again its like I have been fighting a blender fbx hifi specific quirt that time seems to have resolved

adds to post omg insert lots of swearing here but
I just imported ron standing into blender and it didnt mess up the rig
animated him a bit exported him all default settings and it (insert more swearing here ) worked
first time

damn I love the blender people

from their release notes
Support for shape keys was added, including (baked!) animation. Relative shape keys only. (0abd36f1ecbe, 59ff66fa7ac).

[edit] Importer
Support for armatures (skeletons) was added, including skinning
(using assumed modern ‘Deformers’ system, no support for assumed
deprecated ‘BindPose’ system).
Support for shapekeys was added.
Basic support for animation was added (loc/rot/scale of
objects and bones, and influence value of shapekeys). Note FBX anim
curves are always read as if linearly interpolated currently, no support
for fancy Bézier-like anim curves currently.


Good job @Judas. So much ado about nothing ! Lol.