Add Obj2Tiles --y-up-to-z-up support to ODX and NodeODX

[itfsw]

Regarding the OBJ-to-3DTiles issue mentioned in issue #79, I also encountered this problem when generating 3DTiles models from DJI-captured data. I know that the Obj2Tiles tool already provides a solution, and I have tried to fix it myself. However, since I am not a Python developer, I am unable to provide a better implementation. Could you please help fix it? Thank you.

[pierotofy]

Can you provide the dataset that causes this problem, as well as the Cesium code you're using to load up the model (or the viewer you're using)?

[pierotofy]

No response, closing.

[kassol]

I reproduced this issue with a 38-image DJI dataset and prepared the requested
dataset and Cesium loading example as a complete reproduction package:

Download the Google Drive reproduction package

The archive contains the 38 original JPEGs, four complete final 3D Tiles
outputs, exact Docker options and full logs, image and result hashes, a minimal
CesiumJS comparison viewer, and the ODX port used to test the candidate fix.

Short result

Using ODM 3.5.3 as the upright baseline, the measured root-orientation sequence
is:

ODM 3.5.3                 0 degrees   upright
ODM 3.5.5                90 degrees   rotated
ODX 3.8.0 latest         90 degrees   rotated
ODX 3.8.0 + PR #2016      0 degrees   upright

The four full outputs have the same ECEF root translation. The unpatched and
patched ODX outputs also use the exact same textured OBJ, so the result is not
caused by a different reconstruction or geolocation.

Dataset and common processing options

• 38 original DJI M3TD JPEGs
• 4032 x 3024 pixels
• all 38 images contain GPS metadata
• total input size: 291,307,520 bytes
• common options: --auto-boundary --dsm --3d-tiles --no-gpu
• no 2D --tiles option in the four compared runs

The input image hashes are in evidence/input-images.sha256 in the archive.

Full-data comparison

Output	Tested converter/image	Root rotation vs ODM 3.5.3	Result
ODM 3.5.3	Obj2Tiles v1.0.12	0.000 degrees	upright baseline
ODM 3.5.5	Obj2Tiles v1.0.13, default behavior	90.000 degrees	affected
ODX 3.8.0 latest	Obj2Tiles v1.5.0, default behavior	90.000 degrees	affected
ODX 3.8.0 with PR #2016 behavior	Obj2Tiles v1.5.0 plus --y-up-to-z-up	0.000 degrees	restored

The tested latest ODX image was:

• image: webodm/odx:latest
• reported version: ODX 3.8.0
• manifest digest: sha256:fc5f65be6cefa95b125d54d7a5ce51229095d9eb0e3031ec2436d12e05f66a07
• source commit in the image: 17695b95b5e02ce705f70ca3e8372d38cd364e41
• Obj2Tiles version: 1.5.0+042c7a0429f6b38b3cb3bfc176b1764435675e23

Its logged Obj2Tiles command does not contain --y-up-to-z-up, so the converter
uses its false default.

Where the behavior changed

The release boundary is ODM 3.5.5, not ODM 3.5.3:

1. ODM 3.5.3 and 3.5.4 both pin Obj2Tiles v1.0.12. In that version,
   ToEcefTransform() always multiplies the Y-up-to-Z-up rotation matrix.
2. Obj2Tiles PR #63 made this conversion optional. Commit
   529ce7e1a0a8cf57711e755f7efd3f1dca8ad71b then changed the default to
   false, and Obj2Tiles v1.0.13 includes that default.
3. ODM commit 5aca98ba1e0da9008f571fc0ae1f5d8395c43165 upgraded Obj2Tiles from
   v1.0.12 to v1.0.13. ODM's opendm/ogctiles.py call did not add the new
   argument.
4. ODM 3.5.5 is the first released ODM tag containing this dependency upgrade.
   Therefore the same ODM call changed from "rotation always applied" to
   "rotation omitted/default false" without a corresponding caller change.
5. Current ODX 3.8.0 uses Obj2Tiles v1.5.0, where the option still defaults to
   false, and ODX still does not pass or expose it.
6. NodeODX uses ODX for this processing path and has no separate OBJ-to-3D-Tiles
   compensation, so it inherits the same behavior.

This explains both the source history and the observed 0/90/90 result on the
same dataset. I would describe this as an ODM/ODX integration regression
triggered by the intentional Obj2Tiles default change, rather than a claim that
Obj2Tiles itself is universally wrong: the correct option depends on the source
OBJ up-axis.

Candidate fix verification

I ported the functional changes from OpenDroneMap/ODM PR #2016, exact commit
78b587f29ff3fb22e722eea8001aafcb9ac13946, to the tested ODX source. The port
adds an ODX option and passes Obj2Tiles --y-up-to-z-up only when requested.

For a controlled comparison, I cloned the completed unpatched ODX project and
reran only odm_postprocess with:

--3d-tiles-y-up-to-z-up

Both ODX conversions used the same textured OBJ:

SHA-256 616e7b91641e415ed4e574ec1635fd16bee82dc08d7724c3b3da05a1aa683738

The only relevant converter-command change was the added
--y-up-to-z-up argument. The generated root orientation returned exactly to
the ODM 3.5.3 baseline while the ECEF translation remained unchanged. This
confirms that the PR #2016 approach fixes this dataset.

I do not think the conversion should be forced globally. Exposing an explicit,
default-off ODX task option, as PR #2016 does, preserves Obj2Tiles behavior for
other OBJ axis conventions while allowing affected ODM/NodeODX tasks to opt in.

How to inspect the supplied outputs

After extracting the archive:

chmod +x serve.sh
./serve.sh

Open http://localhost:8000 and switch among the four full models. The page
uses the same CesiumJS loading path for every result and refocuses the selected
tileset. fixture.html provides the same 0/90/90/0 test with a small
synthetic marker.

Exact full-run commands are in evidence/run-commands.md; image digests and
environment details are in evidence/environment.json; raw logs and measured
transforms are also included.

Apple Silicon reproduction note

The historical official ODM 3.5.3/3.5.5 ARM64 images contain 32-bit ARMHF
Obj2Tiles executables and fail with a missing /lib/ld-linux-armhf.so.3. To
keep these runs native ARM64, I rebuilt only Obj2Tiles from the exact tags that
ODM pins (v1.0.12 and v1.0.13) and replaced the incompatible executable. This
is only a platform compatibility workaround; no orientation logic was changed.

As a cross-check, an untouched official ODM 3.5.5 AMD64 full run under
emulation produced a byte-identical tileset.json to the native ARM64 v1.0.13
post-processing result.

The archive includes the original inputs, final models, exact parameters, raw
logs, viewer, hashes, and tested patch needed to repeat or inspect the
comparison.

[pierotofy]

Thanks. This is now fixed with f204f19