AdvancedPhotonSource / xdesign

Tools for designing x-ray phantoms and experiments.
https://xdesign.readthedocs.io
Other
24 stars 16 forks source link

Hierarchical Phantoms #43

Closed carterbox closed 7 years ago

carterbox commented 7 years ago

Introduction

Recently, I was trying to make a Douglas-fir Phantom which is made of a collection of 20 cells. In attempting to complete this task, I immediately got stuck because a cell is made of two parts: the cell wall material and an empty lumen in the center. In 2D, it's a square doughnut. Because our geometry only has convex polygons, my two options were: make a mesh or overlay a circle on a square. The later seems like it should have been simpler, but as yet there is no way to group together Feature.

This is clearly the motivation for adding a Component class which can organize a group of Feature. Without Feature grouping, I will have to specify each individual cell and make sure the lumens stay aligned with the cell wall; with grouping, I can make one cell and lumen pair, then copy as many times as I need.

That got me thinking about whether 3 separate classes are actually needed. Is a Feature really that different from a Phantom? I propose that we get rid of Feature, never implement Component, and just make Phantom a hierarchical structure like a data tree which so a Phantom can be nested in a Phantom.

The proposed tree-like phantom would be have the following properties:

properties = dict() # mass attenuation etc are stored in a dictionary
shape  = None # a.k.a. geometry or bounding_box
children = [] # points towards leafs
parent = None # points towards root

Arguments for tree-like phantoms:

  1. Collision detection is simpler because bounding boxes can be compared at the branch level instead of leaf to leaf.
  2. Complex and hierarchical structures are easier to build.

Arguments against tree-like phantoms:

  1. Larger memory overhead