You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 dictionaryshape=None# a.k.a. geometry or bounding_boxchildren= [] # points towards leafsparent=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.
Arguments against tree-like phantoms:
Larger memory overhead
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: