I’m trying to use the tilemap to paint game objects in my 3D scene.
I got my Grid Swizzle set on XZY, and the Tilemap Orientation on XZ.
The problem is, when I paint the tile on the tilemap, the GameObject is rotated wrong. The tilemap instantiates the GameObject like the left example on the picture, but I need it to be instantiated like the right example (basically -90º on the X axis)
Is there any way to solve this easily, without having to setup weird rotations on the prefab?
Edit the geometry in Blender.
It’s annoying but it has to do with Blender having different axis chirality than Unity and how Unity solves it.
I don’t see any chirality issues with simple model shown, just the X rotation, which you can add a rotation while instantiating. While Blender does have a right-hand universe and Unity has a left-hand universe, the axis used for the notion of “upward” is also different, which is where the rotation comes in. The importer on Unity’s side handles the chirality flip.
Correct.
However the default (-90,0,0) rotation is applied as a bandage to address right-hand-rule FBX objects imported into left-hand-rule Unity.
That’s the chirality I speak of. Here’s my cribsheet:
Blender3D objects used as trees / detail in Unity3D terrain (See the second half of this response)
https://discussions.unity.com/t/841411/2
Quote:
“Try making your tree in Blender so that “up” is actually +Y on Blender’s coordinates (green line positive).”
Again, the rotation is about the +Z choice for “up” in Blender vs +Y choice for “up” in Unity. That’s not chirality. The rotation would still need to be done even if Blender was left-handed.
Coordinates are scaled (-1,1,1) to solve chirality shift. That’s done in the import stages on Unity’s side.
The 3D object was made in Unity, with Pro Builder.
Also, it’s the whole prefab that is instantiated in a wrong rotation. It isn’t only a mesh, it has a worldspace canvas inside it and other stuff.
Are you sure?! I don’t think so because I can make a piece of geometry that says KURT and it comes out that way.
If the coordinates were negated in only one axis it would come out as TRUK, wouldn’t it??
My understanding is that import swaps Y and Z and rotates by (-90,0,0) but perhaps I have been laboring under a misconception all this time. I dunno, it works for me.
I just notice that the way OP’s image looks is EXACTLY how my my default-imported vertical-in-Blender trees look when put on Terrain.
If a single axis is negated, and you stay in one chirality (your respective handedness), things look flipped. If you negate X and you move from a right-handed world (FBX) to a left-handed world (Unity) simultaneously, then things look the way you expect them to be. Which is the point.
Time to get to the bottom of this!
tl;dr: ** @halley1 you are correct:** a negation and axis swap (via rotating (-90,0,0)) is happening.
Also, a (-90,0,0) rotation is both an axis swap AND a negation, hence canceling the actual negation.
My test:
In Blender I made a 4-point pyramid with these magnitude-unique verts.
These are the X,Y,Z values from Blender’s inspector:
0, 1, 0,
1, -1, 0,
0, 0, 1.5,```
I exported it as .blend, .FBX and .OBJ.
As one might expect, .blend and .FBX behaved the same. Ignoring order of verts, paying attention to only X,Y,Z positions:
Oddly, the .OBJ file took a different but analogous numeric path.
First, in the OBJ file the vertices were:
```v 0.000000 0.000000 -1.000000
v -0.900000 0.000000 0.500000
v 1.000000 0.000000 1.000000
v 0.000000 1.500000 0.000000```
so the transmog happened at Export time. This is the OBJ file in Unity:
And finally, the dumper script itself if anyone wants to play around:
using UnityEngine;
using System.Collections.Generic;
// @kurtdekker - put this where there are MeshFilters, it will
// report what unique vertices are the meshes.
public class ShowUniqueVerts : MonoBehaviour
{
void Start ()
{
var mfs = GetComponentsInChildren();
// report on all the mf-ers
foreach ( var mf in mfs)
{
var mesh = mf.mesh;
HashSet<Vector3> uniques = new HashSet<Vector3>();
// inject
for (int i = 0; i < mesh.vertices.Length; i++)
{
Vector3 v = mesh.vertices[i];
uniques.Add(v);
}
Debug.Log("Mesh:" + mesh.name + " on " + mf.name + " has " +
mesh.vertices.Length + " verts and " +
uniques.Count + " unique verts.");
// report
foreach ( var v in uniques)
{
Debug.Log(v);
}
}
}
}
No amount of rotation alone can settle the chirality flip. Think about it, how much rotation around an X axis does it take to turn X=-0.9 into X=0.9?