Not sure if it’s due to the latest build or not, but it could be, when I import assets built in Max some of the objects are offset from the Max version. This is happening with static as well as animated objects, so now my animations are not working correctly but I haven’t figured out how to correct the animated objects. The static objects I can move but the rotations are way offset from what they should be.
The hooks hanging down in the attached image and should rotate out from their pivot point at the top of the object but are rotating out from the parent object but not out of their own pivot point.
If I try to create a new parent either in Max or Unity it is still is offset. What is going on?
Is no one else seeing this?
Trying to rebuild some animations and they are going screwy, rotating in opposite directions, etc.
Did something change in how animations are read like has the pivot point of animations now changed from what it was to something new?
Or now do all my Max animations have to be each separate pieces (doors with parent, ramp with parent, etc.) not the whole model imported?
Still no response on why objects are being imported offset?
It isn’t only on animated objects, but straight out of Max.
I’ll keep bumping this thread until either I find the reason and it’s me,
or the problem is acknowledged in their experience by someone else.
I’ve passed this on to our resident Max expert but coincidentally, he is also the guy who is snowed under with manual activation requests resulting from the overloaded servers on Monday. I’ll ping him again shortly.
Although very highly unlikely, could be a similar issue I am having with floating point precision, so the scale in Max converted to Unity with a misplaced decimal point, hogwash I know, not likely the problem, I mean the joint itself is intact, it is a separate object in Max and so in Unity it is also, just look at the coordinates in max and calculate the difference in the coordinate position in Unity and see if there is a common theme.
Thanks Andeeee, I am content to know it is being looked at (or will be).
This is something that popped up in a recent version of the betas because I just started seeing it.
The models haven’t changed and were fine previously. No idea what the logic is for what is going to be offset,
some things (like an animated door and steps) that one would think might be offset are fine but other things like an animated axle on the same model is out of whack.
Zumwalt, not sure I really understand what you would like me to examine, the objects are correctly related (in position) to their parent in Max.
In Max, what is the base X/Y/Z of the objects, then in Unity, what is the transform.position.x/y/z, from looking at this image, the axles, wheels and box are all separate objects, so when they are imported into Unity, the x/y/z are offset, if rounding is going on for the float for the x/y/z then this would displace the objects per unique object, please list the x/y/z per object in Max then the same objects that are offset in Unity with the position x/y/z, I think there is some rounding going on.
Ok, take the front axle:
the X in Max is zero,
in Unity it is zero but should be (if I move it into position) somewhere around the range of -1.6,
otherwise it is not offset. However, when highlighted the X axis arrow (red) is pointing up
while the Z axis (blue) is pointing in the X (in Max) direction.
I have been playing around with this some, I created a scene, in this scene I have a maya scene and a max scene along with unity primitives. In Max 2010 and in Maya 2010 I duplicated what I did in Unity with primitives. Basically in Unity I created a plane that is 100x100 units with a 10x10x10 cube at 0,5,0 location, I repeated that in Maya and Max, both having a plane primitive at 100x100 units split into 10x10sectors with a cube primitive at 10,10,10 in size positioned at 0,5,0, now given the scales for import here are my findings:
Max flips the Y and Z on import, Maya does not (which is not an issue, I think it is supposed to do this)
Max cube center on parent plane values are: 0, 0, 4.529478e-09
Max scale factor: 0.1
Max scale on cube: 1, 0.9999998, 0.9999998
Maya cube centered on parent plane values are: 0, 0.5, 0
Maya scale factor: 0.1
Maya scale on cube: 1, 1, 1
Now based on those results, I would think that Max SHOULD have been centered at 0, 0, 5, but it is half a meter off and the scale factors are not all 1 (but arguably close) so as I thought, rounding issues. I already have closed tickets in the system about object placement or movement in the scene based on math issues, but that is a different issue and it was pretty much closed by them as a non issue since floating point precision is not an exact science and prone to errors.
This test is easy to reproduce since you know how to use Max, create a new project in Unity, empty, no additional packages, create a new scene in Max, place a primitive plane and cube, make the plane 100,100 with a 10,10 subdivision, make the cube 10,10,10 with a position centered on the plane / sitting on the plane as a child to the plane, apply some color material either in Max or in Unity to the cube and plane, save the max scene to your assets folder. After Unity imports it, drag the newly created prefab to your empty scene, place it at 0,0,0 in the scene, make sure your scale is changed from 0.01 on import to 0.1 and then simply click on the cube on the object in the scene and look at the stats.
Ok, will have to have a look, problem is this only started happening recently, this same model has been int he scene,animated ,
textured and fully operational for months. I had to re-import the model since some things were screwed up between 2.6.1 and the version 3 betas.
I suspect that during the scaling during the import, they use the same math module against the model and subsequent child objects of that model that they use in the transform’s math on an object, I also suspect and have for some time that the math they are using is flawed and has some issues at times with floating point math precisions along with some anomalous jumps, I gave up after the last bout with Q/A on the math problems and just gave in to the simple answer that it was due to natural computational errors from floating point math imprecision. The same math is used in both the scaling and in the translation between positions so when you multiply two vectors or add two floating point values, they are never quiet “normal” per say, unfortunately this simply means after an import, you will have to walk your model child objects and re-adjust them until they are back in place, but this, as you have found out, only really works for static objects, not for animated objects. The only place I have personally noticed this math issue has been in movement and I had to have code to compensate for this anomaly, however you are at the mercy of the import feature using the same suspected math module.
The fact that I was able to reproduce it with MAX 2010 and Unity 3 is sort of scary, I only had a cube, a plane and was a simple parented relationship, I do not have a full level to import like you do, not yet anyway. I can’t imagine how you are going to fix the animated objects.
Well, I have created it all in Max, yes, but once I animate something I move it to a separate Max file
and import it separately than the level geometry, so that if or when I have to edit the animated model
I don’t have to re-import the entire scene. I also keep scripts on empty game objects in Unity so I don’t have to redo them each time.
However, this offsetting isn’t only on animated objects or child objects but can be entirely separate objects in a scene.
Another thing, why did this not occur with Unity 2.6.1 on the same models that now are showing this problem?
As for why it didn’t happen in 2.6.1 and why it is happening in 3.0.0f5 release? Not a clue, here was my test files for both Maya and Max when checking out this issue, I do not see how this type of displacement would be overlooked, but as stressed as they were to rush to production, anything is possible.
397180–13632–$test.zip (23.8 KB)
Yeah, there are definitely decimal point inaccuracies, but Max isn’t considered a very accurate (high precision) software.
So, instead of a simple 5 for the center of the 10 unit Max box in your test scene, Unity reads: 4.529478e-10, though the pivot point in Max is actually at 0,0,0 so it’s way off pretty much any way you look at it.
Could be Max or Unity or both or the importer, but still I cannot see the actual logic of the objects I am seeing offset but maybe it’s not really all that logical.
I’m just thinking it would be something of the same character in each model that is imported (all certain types of objects or relationships),
but it seems only some objects are offset, though the offset seems kind of uniform in distance, though not always in relation to the size of the actual model. For instance, I wanted to create two holes in a wall of the full scene geometry so before applying the the Boolean operation I imported the scene to Unity to see how the Boolean object placement matched another objects in the scene that were going to go through the holes. The boxes that were going to create the holes in the wall were both offset at the same amount, only enough to be not in the wall but beside it. This really didn’t hurt for the purpose I needed but wasn’t offset by a huge amount in relation to the overall size of the model (large scene area). Once I finished the aligning and ran the Boolean operation the holes were imported correctly and not offset.