[🐛 bug report] Inconsistent behavior of `mi.Transform4f`

[shinyoung-yi]

System configuration

System information:

OS: Windows-10 (I am actually using Windows 11) CPU: Intel64 Family 6 Model 151 Stepping 2, GenuineIntel GPU: NVIDIA GeForce RTX 4090 Python: 3.11.10 | packaged by Anaconda, Inc. | (main, Oct 3 2024, 07:22:26) [MSC v.1929 64 bit (AMD64)] NVidia driver: 546.33 LLVM: 16.0.0

Dr.Jit: 0.4.6 Mitsuba: 3.5.2 Is custom build? False Compiled with: MSVC 19.39.33523.0 Variants: scalar_rgb scalar_spectral cuda_ad_rgb llvm_ad_rgb

Description

import numpy as np
import mitsuba as mi
mi.set_variant('cuda_ad_rgb', 'llvm_ad_rgb')
print(f"{mi.__version__ = }")
print(f"{mi.variant() = }\n")

scene = mi.load_dict(mi.cornell_box())
cam2world = scene.sensors()[0].world_transform()
print(cam2world @ mi.Transform4f.rotate([1,0,0], 90))
print(cam2world.rotate([1,0,0], 90))

Result:

mi.__version__ = '3.5.2'
mi.variant() = 'cuda_ad_rgb'

[[[-1, 0, 0, 0],
  [0, -4.37114e-08, -1, 0],
  [0, -1, 4.37114e-08, 3.9],
  [0, 0, 0, 1]]]
[[[1, 0, 0, 0],
  [0, -4.37114e-08, -1, 0],
  [0, 1, -4.37114e-08, 0],
  [0, 0, 0, 1]]]

The two transforms in the above script produce different values. The first one should be correct. It is inconsistent with the usage introduced in the documentation: https://mitsuba.readthedocs.io/en/stable/src/how_to_guides/transformation_toolbox.html , which states that mi.Transform4f.scale(2.0).translate([1, 0, 0]) and mi.Transform4f.scale(2.0) @ mi.Transform4f.translate([1, 0, 0]) are identical.

Is it related to Issue #366 ? and has this issue not been solved yet?

Thanks,

[njroussel]

Hi @shinyoung-yi

Yes this is a duplicate of #366.

Unfortunately, .rotate() is ambiguous:

• it's a static method that initalizes a rotation matrix
• it's an instance method that chains a rotation operation onto an existing transform

With Pybind11 this was possible but could in certain cases lead to confusing scenarios like the one you've reported here. On master we're using nanobind and that dual definition isn't possible anymore - which also means that this strange behavior is gone.

[shinyoung-yi]

Thank you for the response. I now have a much better understanding of why this issue occurred.

When I checked the latest version (Mitsuba 3.6.0) of the transformation toolbox documentation, it initially seemed that the ambiguous method usage remained the same as in version 3.5.2. However, I now notice that parentheses () have been added, as in mi.Transform4f().translate(...).