3ds max -> Unity: Scene rotated by 180 degree

If I look top down upon my level in 3ds max and in Unity I see that in Unity the scene is rotated by 180 degrees.

The FBX exporter has the option to specify the up-axis but this has no effect upon import. When importing this into another engine that is y-up too, the scene is not rotated.

Is this a known issue or some setting i am overlooking?

 

The reason for this is that Unity uses a left-handed coordinate system whereas 3dsmax uses a right-handed coordinate system.

http://www.evl.uic.edu/ralph/508S98/coordinates.html

 

yeah i know, look what i wrote.

thx anyways. would be cool to have an import option to fix that upon import automatically.

 

Agree!

 

Is it just me or does the "Axis conversion" setting in the max fbx exporter, not seem to make any difference to the models when they come in to Unity?

i.e. I took a teapot, converted it to editable poly, (then moved one of teh verts on the middle of one side so that its not symetrical in any axis).

Then exported it to fbx, once with the Axis conversion set to Z up and once with Y up.

Unity imported both models, but they look exactly the same, and both seem to be comming in with x rotation of 270 degrees even though the original models rotation was 0,0,0.

BTW. What did seem to help was to rotate the pivot on the model in Max x rotation = 90. This seemed to make the axis handles in unity objects e.g. a cube, agree with my imported teapot.

I wonder if doing something with the pivot in max would be one way of getting things to be the same in max and unity, i.e. it may involve both rotation and scaling of the pivot in Max, eg. the X scale may need to be set to -100% if unity's X axis is the other way around to Max's.

Unfortunatly I still don't really understand what transforms need to be performed on the axis's to convert 3dsmax - Z up, right handed to Unity's Y up, left handed.

But if there was a way to do this with the pivot in max, a Maxscript could be written to do it.

 

First I thought it would not make any difference, too. But if you modify the pivot in 3ds max, it actually can have an impact. You can find a short example on my blog posting.

EDIT: Ops, I forgot that exact the same has been written on the same day - ONE YEAR earlier!! - in another post: http://forum.unity3d.com/viewtopic.php?t=11004&start=0&postdays=0&postorder=asc

 

This 270° error conversion really sucks...
All my models are looking up and I need to rotate them x + 270° but then all the Rigidbody forces and physics are wrong off 270°

I don't know why they do not fix this bug...it is a really pain in the ass to fix for each model; and all the bones animation must be redone?

 

Vote it up!

http://feedback.unity3d.com/pages/1...ect-orientation-and-without-gameobject-hacks-

Also:

http://intra.unity3d.com/fogbugz/default.asp?222964_b26d4djv

 

i'm saving my max file in the asset folder and unity automatically reads it. ready for deployment in the scene. i wonder why there's still a need to convert it to an fbx format.

 

Why to export to FBX?

Well the reason I export to FBX is because others on my team may not have MAX possibly they use Maya and if I do an export to FBX then they can also be able to modify the project files If I sent them a project and it only had a MAX Object then they would not get to see it because they dont have max on thier computer

Not sure if this helps or not lol

Cheers!

 

Seems to me that having an option in the inspectors FBXimport UI panel that let you flip between left and right coords, perhaps with a checkbox to parse through children for simple heirarchy.

I had a similar problem, took me ages to figure out why the character controller wasn't working properly even when the character did seem to be facing the right way it would flip in the direction you moved.

There are two things I'd like to see fixed in the 3dsmax fbx export, one being the coordinates, the other being support for instances. I like building a level in 3dsmax including instances and only setting up gameplay objects in Unity.

Hopefully Autodesk will eventually add instance support, I got spoilt by the Ogre exporters these past couple of years.

 

Max already has instance support, only its called Substitute (a modifier) for some reason. I also think you can use XRefs to emulate instances, although that would be probably too awkward.

 

I know max does have instance support. It's unity that didn't seem to recognise them as instances. at least in 2.5.

I haven't tried 2.6 yet, still waiting to have some time available to try out the pro demo. Sorry I seem to have steered the subject to instances when were supposed to be talking about importing fbx with the correct transform orientation.

 

Excuse me if I'm barking up the wrong tree, but the mention of Ogre and instances made me wonder if you're the artist formerly known as Evak on the Blitz forums?

I've been playing with exporting a lot recently, and I've run into the same problems as everyone else, but I have noticed one huge difference in exporting. If I export with Export Selected, I generally get a lot of errors, including the 270 degree rotation and incorrect position and scale changes too. If I only use the Export option, I get a lot less of those errors. I'm not saying it's perfect, because I'm still having problems which could be my fault, 3dsMax's fault, the FBX exporter's fault *or* Unity's fault, but I have definitely concluded that Export Selected will create a lot more problems.

Of course, you do still need the Y-Up option enabled in the exporter, no matter what you do.

Just wondered if that was any help to you because I've become accustomed to always using Export Selected when exporting to game engines, and this FBX exporter we need to use with Unity seems not to like it.

 

Hey Sybixus, yes it is me. Small world! I saw another familiar face 'Dreamora' on here too. Just started looking at unity again now there's a free version. Jeremy Alessi develops almost exclusively for iphone with it now and we are contemplating porting our old Bliz3d game 'Aerial Antics' to the phone.

As far as the export goes, I have been using export selected too. I didn't imagine it would have made a difference. Thanks for pointing that behaviour out.

I use export selected because often I have layers of things like Render to texture lights and construction helpers like splines for lofting etc hidden away. A straight export seems to export everything including those hidden objects. Whilst export selected only exports whats selected and ignores whats hidden from view.

I'll have to look into this a bit more carefully now, thanks for pointing it out.

 

Thank you too much, Dominique !

 

Yes, I also noticed that export even exports objects which are hidden, and that certainly does make it tricky when you've got a complicated scene. I'm basically down to deleting everything I don't want to export, exporting what remains, and then undoing the delete before saving, which is inconvenient, but it does seem to prevent most, if not all, of the export problems. Anyway, hope it proves useful to you as well.

 

No no no.. dont delete stuff! why??
use your layers in your 3d app. or "named selection" Max got some thing like that and all other 3d apps have too me think
Structure your scene in your 3d app really saves your a lot of work.
Dont delete assets and then undo it dude I have worked with Unity and Max for two years and never used export, only export selected and I use layers in Max like in photoshop.

One FBX feature I really miss is a multiple FBX export.
One export that makes multiple FBX files, lets say all parents get to be their own FBX file with ONE EXPORT.
But but its a request that is more than a year old

 

I tried Layers already but they don't work with exporting .FBX. If I hide the 4 lights I use for light baking my scene in a layer and export. All the lights appear in Unity as nodes.

You pretty much have to delete everything you don't want exported if you don't want it to load into Unity.

 

I know export export hide objects
-but why dont you use export selected?????

 

Yep - definitley the way to go:

* generate a named selection-set of all the parts Unity needs
* Have "Export Selected" mapped to a keyboard-shortcut

So it gets simply a matter of choosing the right entry in the named-selectionset drop-down, and pressing the shortcut....

 

This would be a (rather easy i have to say) job for maxscript. If i find time and motivation, maybe i will code such a thing ...

 

That would be awesome !!

 

That was the entire point of my reply. Export seems to fix all the bugs associated with getting FBX from Max into Unity. Export Selected still has lots of bugs with scale, rotation and position.

It doesn't seem to work with skinned animations though. I've tried exporting skinned animations with Export and Export Selected and most of the time, neither one works. Occasionally, Export works, and I've submitted a bug report with a couple of working ones and a couple of broken ones to see if the UT guys can figure out the difference.

It definitely seems to be a Unity problem though because the FBX files read back into other applications just perfectly. Unity ends up making a number of major transformation errors with them, which cannot be fixed.

If you're exporting animations in the meantime, the only way I've found which works reliably is to export the mesh with all animations. Even if you want to export one mesh and ten animations to be applied to that mesh in Unity (with the @idle naming convention) you should still export the mesh with every animation and still use Export instead of Export Selected, and it seems to work.

Of course, the resulting files are much bigger than they need to be, but hopefully, Unity is only copying the animations, so it will certainly bloat your project file but (hopefully?) not your final build.

 

hmm I dont have any problems with export selected as I said I never use export. Skinned meshes rotation scale... export selected no problems.

:?
(Max 2009)

 

As we all agreed it is left-handed versus right-handed axis system problem. Could someone explain me what exactly you would like to have axis-conversion wise?
A) Expose "up axis" option in unity
B) Have a checkbox for "rotate my model around Y axis by 180 degrees"
C) Have a checkbox which forces to export axes exactly as they are (X in Max/Maya = X in Unity, Y in Max/Maya = Y in Unity, Z in Max/Maya = Z in Unity)
D) Have advanced settings which allows you to setup any axis conversion. Fox example:
X to -Z
Z to Y
Y to -X
E) You suggestions...

 

I don't think it's necessary to do anything really complex. All I really want is a couple of bugs fixed and maybe one new feature. Granted, fixing the bugs may not be trivial. But I don't see any reason why the existing Unity GUI or workflow needs to be modified at all.

Basically, Unity should work as expected - whatever that means

Oh, and I'm using blender, not Max. I'm not sure if Max's fbx files have similar problems. The OP seems to indicate that it does. If not, then blender is probably the problem. If that's the case, then I'd like for Unity to either automatically compensate for blender's problem or to provide some kind of option to that effect. It would be fine to have an import option to "fix broken blender fbx importer," or even a more advanced axis mapping or rotate/scale/translate matrix setting. But, really, it's better if fewer things need to be tweaked and tuned to get it to work right.

I'm not including any illustrations, samples, or screenshots with this, but once you have blender installed (and someone who can accomplish rudimentary tasks), observing these issues yourself is trivial. Just create a new scene, create a box, assign colored materials to each face (so you can tell which face is which), save the .blend file (or export to fbx) into a Unity project's Assets folder, and then drop the object into a new scene inside Unity.

First, these are my problems and related observations.

Errors in Unity after import, whether Unity imports a .blend file directly or an .fbx exported from blender:

• * Normals look correct in blender, but in Unity are nonsense. I always have to use "Calculate Normals" option to get anything useful at all. Even a box primitive that's been "set solid" in blender will have unusable normals after import.
  
  * The "right" view in Unity (camera points -X) corresponds to "left" view in blender (camera points +X).

Observations in Unity after import:

• * The imported scene root object has no rotation.
  
  * Each imported scene object that's a child of the root object has a 270 rotation on the X axis (i.e. in Unity's inspector pane).

And here are my suggestions.

Suggested changes:

• * Normals should be correct.
  
  * No imported object, root or otherwise, should have any rotate/scale/transform that doesn't exist in the imported scene. When objects have "magic import rotations" like this, scripting becomes more complicated. It's not a huge problem, but it's still counterproductive and counterintuitive. In other words, if any transformations need to happen during import, then they should be applied to the actual objects during conversion.
  
  * Viewing an imported scene from the top/left/front views in Unity should look identical to the top/left/front views in blender. Probably just a handedness problem.

Suggested additions:

• * Importers for each file type should have settings that will apply to any asset that it imports in the future. For example, I want to be able to tell the .blend importer to always use a scale of 123.45 instead of 1.0, or always "Generate Normals" without having to manually modify each file after it's been imported. I mean this for all importers, not just 3d files: textures, sounds, etc.

 

To summarize: Just go through the process of importing an FBX. You should notice the same problems we do. I don't need any extra options or features, I just need the problems to get fixed somehow. If, for whatever reason, it takes extra options or features to get those problems fixed, then that's ok by me as long as it simplifies my workflow instead of complicating it.

 

Paulius,

I think exposing the conversion method like you suggested in D) would be very flexible. In addition to that add let us specify the default values for new FBX importer components inside the editor settings. There you can also provide a drop-down or so, where you can select a preset like "3ds max", "Maya" etc. which would set the required values as default.

This way this can be a one-time setup per project or even seat installation.

Please also have a look at characters. It seems that the root GO can easily have a different orientation than the skeleton (i.e. biped)

 

Btw. I'd like to add that rotating a Biped in 3dsmax via "Move All Mode" around the X axis is not possible (only around the up-vector). Therefore the workaround suggested by holmeren is not universally applicable.

(edit: added one more sentence)