CBCT simulation output exception

Started by zhenguo, Dec 01, 2025, 01:18 PM

Previous topic - Next topic

zhenguo

*
Newbie
Posts: 2
Logged
Hello, I am a beginner with GGEMS. When using example 7_Mesh.py, I modified the original STL phantom code as follows:
Original code for STEP 5: Phantoms and systems
# Loading phantom in GGEMS
mesh_phantom = GGEMSMeshedPhantom('phantom_mesh')
mesh_phantom.set_phantom('data/Stanford_Bunny.stl')
mesh_phantom.set_rotation(90.0, 90.0, 0.0, 'deg')
mesh_phantom.set_position(0.0, 0.0, 0.0, 'mm')
mesh_phantom.set_mesh_octree_depth(4)
mesh_phantom.set_visible(True)
mesh_phantom.set_material('Water')
mesh_phantom.set_material_color('Water', color_name='white') # Uncomment for automatic color

Modified code:
# Loading phantom in GGEMS
mesh_phantom = GGEMSMeshedPhantom('Centrifuge_tube')
mesh_phantom.set_phantom('data/Centrifuge_tube.STL')
mesh_phantom.set_rotation(0.0, 0.0, 0.0, 'deg')
mesh_phantom.set_position(-11.25, -50.0, -11.25, 'mm')
mesh_phantom.set_mesh_octree_depth(4)
mesh_phantom.set_visible(True)
mesh_phantom.set_material('Bakelite')
mesh_phantom.set_material_color('Bakelite', color_name='white') # Uncomment for automatic color

mesh_phantom1 = GGEMSMeshedPhantom('Cylindrical_soil')
mesh_phantom1.set_phantom('data/Cylindrical_soil.STL')
mesh_phantom1.set_rotation(0.0, 0.0, 0.0, 'deg')
mesh_phantom1.set_position(-6, -10.0, -6, 'mm')
mesh_phantom1.set_mesh_octree_depth(4)
mesh_phantom1.set_visible(True)
mesh_phantom1.set_material('Lead')
mesh_phantom1.set_material_color('Lead', color_name='blue') # Uncomment for automatic color

The STL file of the centrifuge tube phantom is a cylindrical ring with a height of 100 mm, an outer radius of 11.25 mm, and an inner radius of 10.5 mm; the cylindrical soil phantom is a cylinder with a radius of 6 mm and a height of 20 mm. The geometric centers of both phantoms are at the coordinate origin, and there is no overlap between them at all—the cylindrical ring encloses the cylinder.
After running the code, I found that the generated projection.raw image only shows the projection of the centrifuge tube sample, with no information about the cylindrical soil reflected. However, if I change mesh_phantom1.set_position(-6, -10.0, -6, 'mm') to mesh_phantom1.set_position(-100, -10.0, -6, 'mm') (at which point the cylindrical ring and the cylinder no longer have an enclosing or overlapping relationship), the information of the soil cylinder will appear in the projection.raw file generated after running the code.
What causes this issue and how can it be resolved? I would be extremely grateful for your answer. Best regards!

didier.benoit

Administrator
*****
Newbie
Posts: 18
Logged
What you are observing is expected behaviour in GGEMS v1.3. The geometry engine in this version does not support hierarchical or nested mesh volumes (no mother/daughter relationship, no enclosure detection, and no overlap resolution). All meshed objects are treated as independent top-level volumes. During transport, GGEMS v1.3 evaluates navigators in a flat list, and the first navigator that intercepts the ray "wins". If a mesh volume is fully enclosed inside another mesh volume, the outer volume will always intercept the particle before the inner one. As a result, the enclosed mesh is never queried, and it effectively disappears from the simulation.
This explains why:
- When the cylindrical soil is fully inside the centrifuge tube, it does not appear in the projection.
- When you move it slightly so that it protrudes outside the tube, it becomes visible again (because it can now be the first object intersected by the ray).
This limitation is inherent to the v1.3 geometry system and cannot be resolved by STL positioning alone.
The upcoming GGEMS v2 introduces a unified geometry framework with proper hierarchy and overlap handling, in which nested or enclosed meshes will be correctly represented.

zhenguo

*
Newbie
Posts: 2
Logged
Dear Administrator,
Thank you very much for your detailed explanation! Your reply clearly pinpoints the core of the issue — the geometry engine of GGEMS v1.3 does not support hierarchical parsing of nested meshes. The outer centrifuge tube intercepts the rays first, causing the inner soil cylinder to fail detection. This has fully clarified the experimental phenomena I observed earlier and saved me from making futile attempts at STL positioning adjustments.
Learning that the upcoming GGEMS v2 will introduce a unified geometric framework with support for hierarchical structures and overlap handling, I am truly looking forward to it! Accurate representation of nested meshes is crucial for my experiments involving the co-simulation of centrifuge tubes and their internal samples. I believe the new version will perfectly resolve the current limitations and make the simulation results more consistent with real-world scenarios.
May I take the liberty to ask if there is a tentative release timeline for GGEMS v2? For instance, will a beta or official version be launched in the near future?
Thank you again for your prompt response and professional insights. I sincerely anticipate the release of GGEMS v2 and will keep a close eye on all updates of the software.