Unexpected rotation applied to OBJ models (need option to preserve original orientation without georeferencing)

[loicroybon]

Problem encountered

I am using Obj2Tiles in a mesh conversion pipeline (OBJ → 3D Tiles).
My source OBJ is correct (verified in multiple viewers).
However, after conversion with Obj2Tiles, the generated 3D Tiles are misoriented: the mesh is rotated by about 30–45 degrees.

The OBJ input is correct, but Obj2Tiles applies an implicit transformation that disorients the model.

---

Analysis

• The options --lat, --lon, and --alt are not used in my case (no georeferencing needed).
• The issue occurs even without any geographic transformation.
• The OBJ is correctly oriented in Z-up.
• The generated tileset.json contains a 4×4 transform matrix that seems to introduce the unwanted rotation.

Typical example:

"transform": [
  -0.15971367836948433, 0.9871633810781724, 0.0, 0.0,
  -0.7036627692186165, -0.11384596649119745, 0.7013542636423288, 0.0,
   0.6923512462307532, 0.11201586928643742, 0.7128128764765174, 0.0,
   4423440.518572955, 715670.7489476459, 4523682.777249486, 1.0
]

This matrix introduces a systematic angular offset on all my models, which is not expected.

---

Business objective

My need is straightforward:

• Be able to produce valid and correctly oriented 3D Tiles directly from a correct OBJ.
• Input can be either in local coordinates (near zero) or associated with a CRS (with large coordinate values).
• Georeferencing (--lat / --lon) should always be optional.

This would avoid extra steps of “repairing” or patching in the pipeline (post-processing, forced alignment with 3d-tiles-tools, etc.).

---

Proposed improvement

• Add an explicit option to disable any automatic rotation and strictly preserve the orientation of the source OBJ.
• Clarify in the documentation the default logic applied to the vertical axis and the generated transform matrices.

---

Thanks

Thanks a lot for this great tool!
A clarification (or fix) on this orientation issue would really help those like me who want to integrate Obj2Tiles in a 100% automated pipeline and generate directly usable 3D Tiles datasets, with or without georeferencing, and without post-corrections.

[loicroybon]

Maybe linked to this file ? /Stages/TilingStage.cs

    // Where is it?
    private static readonly GpsCoords DefaultGpsCoords = new()
    {
        Altitude = 0,
        Latitude = 45.46424200394995,
        Longitude = 9.190277486808588
    };

[dknezevic]

Maybe linked to this file ? /Stages/TilingStage.cs

    // Where is it?
    private static readonly GpsCoords DefaultGpsCoords = new()
    {
        Altitude = 0,
        Latitude = 45.46424200394995,
        Longitude = 9.190277486808588
    };

If lat/lon/alt is not defined this is the default location your model will be translated to. It points to the Piazza del Duomo in Milan, Italy. This should not affect the rotation of your model.

What happens here is that the location of you model defined by let/lon/alt (or the default one of these are not defined) is converted to ECEF coordinates, so that the tiles could be merged together in the tileset.json. This usually does introduce rotation in the transform file because, in the ECEF, the center of the earth is the pivot. On the other hand, you model should not look rotated if you have positioned it correctly (im talking about the coordinates in the mesh).

Heres my suggestion, im not sure it will work, its just a guess:

What you can try and both set local coordinates of your mesh and lat/lon/alt to 0.0 and try again.
Here is a little hint about how the location of the model could impact the rotation

[loicroybon]

Thanks for the clarification. I understand the current behavior with ECEF and the default pivot.

From a geospatial / production perspective, it would be really useful to simplify usage by supporting two explicit workflows:

1. Local models (non-georeferenced)

• Coordinates are close to zero, no CRS, no implicit translation to Milan.
• The OBJ orientation and coordinate system are preserved “as is”, without any transform injected into tileset.json.
• This mode is critical for many pipelines where models are not intended to be placed on the globe.

2. Georeferenced models

• Input mesh has coordinates in a known CRS (large coordinates, e.g. projected meters).
• User specifies an EPSG code (e.g. --crs EPSG:2154).
• Obj2Tiles internally transforms to WGS84/ECEF using PROJ or similar, so the model is positioned consistently on the globe.
• No need to manually type lat/lon/alt, the origin comes from the mesh itself + CRS.

This dual approach would avoid the current confusion (implicit Milan offset, unexpected rotation in ECEF) and make Obj2Tiles easier to integrate in automated pipelines where georeferencing is optional.

Would you be open to discussing a feature like --mode local|georef or --crs EPSG:xxxx to make this explicit?

[dknezevic]

@loicroybon personally, if i end up implementing some of the features you menitioned in my line of work, i would be happy to share it with the community and create a pull request. At the moment, i don't have a similar requirement and the current version suits me fine for my needs.

[itfsw]

Obj2Tiles has support --y-up-to-z-up;
so edit ODM opendm/ogctiles.py

 CmdStr = 'Obj2Tiles "{input}" "{output}" --divisions {divisions} --lat {lat} --lon {lon} --alt {alt}'.format(
            **kwargs)
 # add y to z
 CmdStr += ' --y-up-to-z-up'

[HeDo88TH]

We just added the --local switch to support local coordinates in #92
Does it fit your workflow @loicroybon ?