Replies: 1 comment
|
Hello @natanzi, The first issue is that the plugin name is However, after fixing the name, you would run into another issue. In fact, the holder material is added automatically by the Instead, you should include an actual radio material in your scene, for example: <scene version="3.0.0">
<integrator type="path"/>
<bsdf type="itu-radio-material" id="placeholder">
<string name="type" value="concrete"/>
</bsdf>
<shape type="cube" id="my_object">
<ref id="placeholder"/>
</shape>
</scene>Note that this is unrelated to Docker. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I am having a fundamental issue setting up a static scene in Sionna RT within a Docker environment. My goal is to load a static scene (walls, obstacles) from a Mitsuba XML file and then programmatically add Transmitters and Receivers.
Environment:
The Problem:
According to the documentation and API design, the correct workflow seems to be defining geometry in an XML file with a placeholder, and then linking a Python-defined RadioMaterial to it.
However, when I try to load a minimal scene with this placeholder, it fails.
My scene.xml file:
XML
My Python code:
The Final Error:
This code fails with the following error:
This error indicates that the Sionna holder_material plugin is not registered with the Mitsuba XML parser at the time of loading. All my previous attempts at purely programmatic scene creation (without XML) also failed due to persistent and unresolvable TypeError issues with mi.Transform4f.
My Question:
Is this a known issue with this version setup, or am I missing a crucial step for registering Sionna's custom plugins with the Mitsuba parser before loading an XML file? What is the definitive, robust method for creating a scene with custom static geometry in this environment?
Thank you for any help.
Milad
All reactions