PathSolver Fails to Find LOS Path in a Deterministic, Programmatically-Assembled Scene

[natanzi]

❗ PathSolver Fails in Minimal LOS Scenario Using XML + Python Hybrid Scene

Hello Sionna Team,

I'm encountering a persistent issue where PathSolver.cir() fails to detect any paths, even in a minimal and deterministic Line-of-Sight (LOS) setup.

---

🎯 Objective

I'm working on creating a digital twin of an indoor factory (20×20×5 m). The scene combines:

• Static geometry (walls) loaded from an XML file.
• Dynamic elements (TX, RX, obstacles) added programmatically in Python.

---

🐛 Problem

Even after:

• Removing all obstacles,
• Placing the transmitter and receiver with a clear LOS,

…the call to PathSolver(scene).cir() returns an empty list/tuple, indicating no paths are found.

---

🧪 Minimal Reproducible Example

This example uses two files: scene.xml and main.py.

---

scene.xml

<scene version="3.0.0">
    <integrator type="path"/>
    <bsdf type="itu-radio-material" id="concrete_material">
        <string name="type" value="concrete"/>
    </bsdf>
    <shape type="cube" id="walls">
        <transform name="to_world">
            <scale x="20" y="20" z="5"/>
            <translate x="10" y="10" z="2.5"/>
        </transform>
        <boolean name="flip_normals" value="true"/>
        <ref id="concrete_material"/>
    </shape>
</scene>

---

main.py

import mitsuba as mi
import sionna.rt as rt
import os

os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
mi.set_variant("llvm_ad_mono_polarized")

# Load static walls
scene = rt.load_scene("scene.xml", merge_shapes=False)

# TX and RX setup
scene.tx_array = rt.PlanarArray(num_rows=4, num_cols=4, vertical_spacing=0.5, pattern="tr38901", polarization="V")
scene.rx_array = rt.PlanarArray(num_rows=1, num_cols=1, pattern="iso", polarization="V")

scene.add(rt.Transmitter("bs", position=[10, 10, 4.8], orientation=(0, -90, 0)))
scene.add(rt.Receiver("agv_0", position=[10, 10, 0.5]))

# Path computation
print("Attempting to compute paths in a simple LOS scenario...")
solver = rt.PathSolver()
solver.max_depth = 5
paths = solver(scene)

# CIR extraction
cir_h, cir_tau = paths.cir()

# Check result
if isinstance(cir_h, (list, tuple)):
    print("\n--- FAILURE ---")
    print("No paths were found.")
    print("Opening scene preview for inspection...")
    scene.preview()
else:
    print("\n--- SUCCESS ---")
    print(f"Successfully found {cir_h.shape[-1]} paths.")

---

❌ Observed Behavior

Attempting to compute paths in a simple LOS scenario...
--- FAILURE ---
No paths were found.

scene.preview() confirms that the transmitter and receiver are properly positioned and unobstructed.

---

✅ Expected Behavior

In this setup, PathSolver.cir() should return at least one valid path due to clear LOS conditions.

---

🛠️ System Info

• Sionna version: v1.0.2
• Mitsuba version: 3.5.0
• Environment: Docker (nvcr.io/nvidia/tensorflow:25.02-tf2-py3)
• GPU: NVIDIA H100

---

❓ Question

Is there a known issue or hidden requirement when mixing:

• XML-loaded static geometry
• Python-added dynamic objects (TX/RX)

…that might cause PathSolver to fail path discovery?

This appears to be a critical blocker for hybrid scene construction in digital twin setups. Any insights or guidance would be greatly appreciated.

Thank you for your time and support.

Best regards,
Milad

[faycalaa]

Hi @natanzi ,

Your code has several issues that explain what you are observing.

Here is a fixed version:

import mitsuba as mi
import sionna.rt as rt
import os

# mi.set_variant("llvm_ad_mono_polarized") --> Not needed as Sionna RT sets the variant

# Load static walls
scene = rt.load_scene("scene_946.xml", merge_shapes=False)

# TX and RX setup
scene.tx_array = rt.PlanarArray(num_rows=4, num_cols=4, vertical_spacing=0.5, pattern="tr38901", polarization="V")
scene.rx_array = rt.PlanarArray(num_rows=1, num_cols=1, pattern="iso", polarization="V")

scene.add(rt.Transmitter("bs", position=[10, 10, 4.8], orientation=(0, -90, 0)))
scene.add(rt.Receiver("agv_0", position=[10, 10, 0.5]))

# Path computation
print("Attempting to compute paths in a simple LOS scenario...")
solver = rt.PathSolver()

# solver.max_depth = 5 --> Wrong use of the API.
# max_depth is a parameter of the PathSolver call method
paths = solver(scene, max_depth=5)

# CIR extraction
cir_h, cir_tau = paths.cir()

# if isinstance(cir_h, (list, tuple)): --> Wrong use of the API
# cir_h returns by default a 2-tuple containing the real and imaginary parts
# of the channel coefficients
h_real, h_imag = cir_h
if h_real.shape[-2] == 0: # The second to last dimension is the number of paths
    print("\n--- FAILURE ---")
    print("No paths were found.")
    print("Opening scene preview for inspection...")
    scene.preview()
else:
    print("\n--- SUCCESS ---")
    print(f"Successfully found {h_real.shape[-2]} paths.") # Fixed: cir_h.shape[-1] --> h_real.shape[-2]

Output:

Attempting to compute paths in a simple LOS scenario...

--- SUCCESS ---
Successfully found 167 paths.

Please check out the API documentation and tutorials.

[natanzi]

Hi @faycalaa,

Thanks for your previous guidance. I'm facing a new issue as we're encountering a persistent problem with PathSolver that we haven't been able to resolve.
This is the scene I want to build: Two robot and 5 metal obstecle.

This is my unit_cube.obj:

# OBJ file for a unit cube.
# Vertices are defined first, with x, y, and z coordinates.
# A unit cube centered at the origin, with side length 1.
v -0.5 -0.5 -0.5
v -0.5 -0.5 0.5
v -0.5 0.5 -0.5
v -0.5 0.5 0.5
v 0.5 -0.5 -0.5
v 0.5 -0.5 0.5
v 0.5 0.5 -0.5
v 0.5 0.5 0.5

# Faces are defined by the indices of the vertices that make them up.
# For a cube, there are 6 faces.
f 1 3 4 2
f 5 6 8 7
f 1 5 7 3
f 2 4 8 6
f 1 2 6 5
f 3 7 8 4

---

🧩 Problem Description

The PathSolver() consistently fails to return any paths — not even a Line-of-Sight (LoS) path — in a simple, programmatically generated scene. This occurs even when there are no obstructions between the transmitter and receiver.

I have carefully followed the Sionna RT API documentation and reviewed previous GitHub issues to avoid common pitfalls. Specifically, our implementation already includes:

• ✅ Programmatic Scene: The scene is built entirely in code to avoid any XML parsing issues.
• ✅ Mesh Cloning: All geometry objects derived from the same mesh are created using .clone().
• ✅ Correct Scene Additions: Geometry is added via scene.edit(add=[...]); TX/RX arrays via scene.add(...).
• ✅ Explicit Frequency: scene.frequency is set to 28 GHz.
• ✅ Scene Updates: scene.scene_geometry_updated() is called after any position/orientation change.
• ✅ Mitsuba Variant Handling: import sionna.rt is used to automatically configure Mitsuba.

Despite these measures, the solver finds no paths and Drjit error, and we are currently blocked in our development.

---

❓ Questions

1. Is there a hidden configuration or low-level step that we might be missing?
2. Could this issue be specific to programmatic-only scene construction?

---

📎 Reproducible Code

Below is the code that reliably reproduces the issue.

# -*- coding: utf-8 -*-
import os
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'

import sionna.rt as rt
import drjit as dr
dr.set_flag(dr.JitFlag.Debug, True)
import numpy as np

# Set seeds for reproducibility
np.random.seed(42)

# Create a minimal scene
scene = rt.Scene()
scene.frequency = 28e9  # 28 GHz
scene.tx_array = rt.PlanarArray(num_rows=1, num_cols=1, pattern="iso", polarization="V")
scene.rx_array = rt.PlanarArray(num_rows=1, num_cols=1, pattern="iso", polarization="V")

# Add transmitter
bs = rt.Transmitter(name="bs", position=[10, 10, 4.8])
scene.add(bs)

# Add receiver
rx = rt.Receiver(name="agv_0", position=[2, 3, 0.5])
scene.add(rx)

# Update scene geometry
scene.scene_geometry_updated()
print("Scene initialized with 1 TX at [10, 10, 4.8] and 1 RX at [2, 3, 0.5]. No obstacles.")

# Test PathSolver with default settings
print("\nTesting PathSolver with default settings...")
solver = rt.PathSolver()
try:
    paths = solver(scene)
    h_real, h_imag = paths.cir()
    if isinstance(h_real, list):
        print("LOS paths: 0 (empty list returned)")
    else:
        print(f"LOS paths: {h_real.shape[-2]}")
except Exception as e:
    print(f"Error with default settings: {e}")

# Test PathSolver with documented parameters
print("\nTesting PathSolver with documented parameters...")
try:
    paths = solver(scene, max_depth=0, max_num_paths_per_src=1000000, samples_per_src=1000000, seed=42)
    h_real, h_imag = paths.cir()
    if isinstance(h_real, list):
        print("LOS paths: 0 (empty list returned)")
    else:
        print(f"LOS paths: {h_real.shape[-2]}")
except Exception as e:
    print(f"Error with documented parameters: {e}")

---

🪵 Execution Output & Error Log

Scene initialized with 1 TX at [10, 10, 4.8] and 1 RX at [2, 3, 0.5]. No obstacles.

Testing PathSolver with default settings...
LOS paths: 0 (empty list returned)

Testing PathSolver with documented parameters...
LOS paths: 0 (empty list returned)

---

🖥️ System Information

• Sionna Version: 1.1.0 (pip install sionna[rt])
• Mitsuba Version: 3.6.2
• Environment: Docker container nvcr.io/nvidia/tensorflow:25.02-tf2-py3
• GPU: NVIDIA H100-NVIDIA Driver Version: 575.51.03
• CUDA Version: 12.x
• TensorFlow: 2.19.0
• DrJit: 1.0.3
• Optix: 8.1.0

Thank you for your time and assistance.
Best regards,
Milad

[merlinND]

Hello @natanzi,

I think that once again the issue is a misunderstanding of the API and return values. @faycalaa has already pointed it out in his answer above.
Why would h_real being a list indicate that there are no paths?

    if isinstance(h_real, list):
        print("LOS paths: 0 (empty list returned)")
    else:
        print(f"LOS paths: {h_real.shape[-2]}")

If you print paths.valid, h_real, h_imag, you would see that there is indeed a path found.

Please check again whether the results are as expected by actually inspecting those variables.

[jhoydis]

Hi @natanzi,

You cannot expect us to go through large code examples and find bugs in your code which are most likely due to hallucinating LLMs (as for example seen by the wrong use of the Sionna API above).

For future issues, please provide a minimal (!) reproducer code snippet that identifies clearly a bug or unexpected behavior. Also refrain from using LLMs for the issue generation as they are generally far too verbose.

Hope for your understanding.

[natanzi]

Hi @jhoydis,

Just to clarify: I didn’t expect anyone to "go through large code examples and find bugs" in my code. I included the full snippet because the issue seemed complex and context-dependent, and I wanted to avoid omitting details that might later be considered critical.

I do take your point about minimal reproducible snippets noted and already adjusted.

Technical feedback is always appreciated. But so is tone.

Best regards,
Milad