When importing blend files, which contain cameras with children, those children are weirdly rotated, not like in the original file. If I have another object, with the exact same rotations as the camera, that has its own child with 0 rotation, that child stays level.
Why is it, that objects like cameras or lights, don’t get imported the same way like other types of objects (like meshes or empties)?
And why is it, that if those objects, if passed through a custom ModelPostProcessor (which gets ran after Unity has imported the model first), get handled differently there too, specifically the transforms of said objects?
You mean .blend directly or .fbx? I would strongly recommend to export to FBX, not putting your .blend files directly in the Assets tree. These get rather huge and take far longer to import than FBX. Same goes for any “source” format like PSD (prefer to use PNG, JPG).
I concur about the modeling issues. A friend of mine these days went back into Blender for some “quick changes” on animations and oh boy, the whole process is rigged with booby traps! He had “rotational issues” too, and it’s not just the difference in coordinate system.
There’s not even a good solution to many things we come to understand as normal in Unity, such as that you cannot have duplicate names in the Blender child hierarchy. So if you want some bones to be flagged as attachment slots, you got to name them “Slot_001” and rely on partial string match “Slot_” to find those.
@CodeSmile, both, actually. It does not matter whether I use the blend file directly or export to FBX first. The aforementioned problems still persist.
I would have tried glTF and USD, but neither are supported by Unity.
I don’t know why it isn’t listed in the packages registry, there are other packages (Serialization) that aren’t listed either but are not experimental or preview and work fine. Possibly Unity didn’t want to clutter the registry with highly technical, rarely used packages.
I’ve just tried that package out (after figuring out how to export cameras too), and while it fixes the problems I have with rotations and positions of children of cameras and lights, it creates a weird structure with cameras, every camera seems to get an empty parent in its place, and gets parented to that object.
Suppose a parent structure like this in the original Blender file:
└── Camera
└── Cube
That will be turned into
└── Camera
└── Camera-Camera
└── Cube
Where the child (called Camera-Camera) has the actual Camera component (though disabled by default, another issue).
I think that may relate to the odd behaviour where the root object is not supposed to contain anything but children. I vaguely recall Blender doing something like that.
Try setting up the blender file so that it matches the imported hierarchy. This should be imported as-is.
Honestly, I don’t know why a Blender object would have or add a Camera component though. Cameras shouldn’t be part of the modeling process, I assume your postprocessor is adding these? If so, change this so it adds CinemachineCamera components and use a single Camera in the scene so that you have a single place to tweak the Camera postprocessing settings, while being able to seamlessly if not automatically switch between “live” CinemachineCamera components.
I’m adding them in Blender myself. It’s actually more for testing. The exact same behaviour happens with lights, any object that is a child of a light has weird rotations and positions once imported into Blender, if imported via FBX.
The less authoring you do in Blender the better. Ideally, create lots of different geometry things in Blender, leaving them all as peers to each other, and then prefab them together in Unity. That way if one of those things has an issue, it’s much easier to adjust the one thing without throwing everything else off in Unity.
And NEVER rename things once they have been imported to Unity.
If you attempt to make a huge complex thing in Blender and expect it to survive the full tool chain conversion into Unity, unless you are meticulous in not applying scales / rotations anywhere, it’s gonna likely let you down.
Keep the back and forth as simple as possible. Here’s some more notes:
When I work in Blender3D for Unity3D use, I follow these organizational rules:
use Empty Blender Objects as folders: they come out as an extra GameObject
ALWAYS parent everything to a single Empty, even a single object
ALWAYS apply all Scales and Rotations on every Transform throughout your hierarchy.
put as few objects in a given .blend file as possible, combining them in Unity into a prefab
REMOVE unnecessary items (Light, Camera, etc.)
use good names for your Blender3D objects and NEVER RENAME them after Unity sees them
don’t even think about final Materials or Textures in Blender. Set the mesh to use N different materials, but always set up the materials within Unity and disregard what gets imported.
Costs of using Blender files directly vs exporting to FBX:
Unity imports Blender3D objects as FBX via a little Python script:
The Python script that Unity uses (substitute your Unity version number or search) to import: