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:
Collision detection is simpler because bounding boxes can be compared at the branch level instead of leaf to leaf.
Complex and hierarchical structures are easier to build.
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 togetherFeature
.This is clearly the motivation for adding a
Component
class which can organize a group ofFeature
. WithoutFeature
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 aPhantom
? I propose that we get rid ofFeature
, never implementComponent
, and just makePhantom
a hierarchical structure like a data tree which so aPhantom
can be nested in aPhantom
.The proposed tree-like phantom would be have the following properties:
Arguments for tree-like phantoms:
Arguments against tree-like phantoms: