Feature request: Add bounding box to geometries (C++)

[rtownson]

This is a good first issue for someone looking to do some C++ coding and contribute to EGSnrc. If you decide to give it a go, comment below so we know you are working on it, and feel free to ask for help.

The idea is to add bounding boxes to the egs++ geometries, to facilitate checks on whether two geometries might intersect, among other things. The egs++ geometries are found in HEN_HOUSE/egs++/geometries.

Here is my idea how it might be implemented:

For each geometry, add a new array boundingBox that will contain the min/max along each dimension. When the geometry is initialized, calculate the bounding box (might be tricky for some geometries). If it is a composite geometry (like a CD), use the bounding boxes of the components to estimate it. Add a new getBoundingBox() function for each geometry.

[ftessier]

Good idea! I suggest that the bounding box numerically lies outside the geometry, i.e., at least a floating point epsilon away from the geometry per se (ideally defied through a boundingBoxEpsilon parameter. For example, for a simple egs_box the bounding box would be bigger than the actual box by at least an epsilon on each side.

Bounding boxes would bevery useful for partitioning the geometry in kd-trees or other space segmentation schemes to speed up ray tracing. I reckon this is required for efficient transport in complex triangular meshes, in particular.

Thinking out loud:

• Constrain bounding box to be aligned with x, y, z, axes. For example, rotated geometries should reset their bounding boxes to encompass the geometry in an aligned bounding box.

• Handle the "infinite" geometries (e.g., planes) by flagging the infinite dimensions (using inf?).

• In composite geometries, define init methods that properly combine the individual bounding boxes.

• Find reasonable and safe defaults for "hard" geometries, cd in particular!

• Allow the user to select bounding box howfar() calculations, per geometry in the input file, which can speedup transport significantly if the geometry per se is very complex: first calculate howfar() on the bounding box, then on the actual geometry only if there is a hit on the box For example, it is not widely recognized that in EGSnrc a conestack in a big box (think ion chamber in phantom) causes particle to stop at all conestack planes extended throughout the phantom!! Inscribing the conestack in a tigh envelope typically speeds up the calculation!