<div dir="ltr">FreeWRL - refreshes the bounding box for Group, Transform, other grouping nodes on each frame, during rendering <div><a href="https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Grouping.c">https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Grouping.c</a><br><div>in child_Transform(), child_Group etc 3 lines:</div></div><div>prep_Bbox(...)</div><div>normal_Children(...)</div><div>fin_Bbox(...)</div><div>The prep clears the bbox</div><div>Each child rendered UNIONs its bbox/extent to group bbox</div><div>the fin - depends</div><div>- if its Group, just copies the summed /unioned children bbox to Group as its bbox</div><div>- if its Transform, transforms the children bbox into Transform parent space as transform's bbox</div><div>We used to do it a different clunky way only if a node changed - a weird trickle-up algorithm that didn't work well. </div><div>But darn view3dscene was making us look bad, so we updated to do the full deal - and rely on multi-core Ghz CPU to keep up with the specs.</div><div><a href="https://freewrl.sourceforge.io/tests/10_Grouping/bbox/2.x3d">https://freewrl.sourceforge.io/tests/10_Grouping/bbox/2.x3d</a><br></div><div>-Doug</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 24, 2023 at 10:10 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Please forgive me if I use this message to plan strategies for a<br>
possible implementation of bboxDisplay for x3dom. There will be a few<br>
questions at the end.<br>
<br>
To start, it is already quite straightforward to generate visual<br>
feedback for selection purposes in x3dom. Here are a few examples:<br>
<br>
<a href="https://andreasplesch.github.io/Library/Examples/html5/highlight/turnyellow.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Examples/html5/highlight/turnyellow.html</a><br>
<a href="https://andreasplesch.github.io/Library/Examples/html5/highlight/withBBox.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Examples/html5/highlight/withBBox.html</a><br>
<a href="https://andreasplesch.github.io/Library/Examples/html5/highlight/outline.html" rel="noreferrer" target="_blank">https://andreasplesch.github.io/Library/Examples/html5/highlight/outline.html</a><br>
<br>
Thinking about generalizing to any X3DBoundedObject leads to the<br>
following observations.<br>
<br>
In x3dom, only Shapes are collected for rendering during scene<br>
traversal. Displaying a bbox for groups etc. breaks this basic<br>
pattern.<br>
<br>
Although a custom shader would be most performant, this means it is<br>
not really advantageous to expand the shader to include an option for<br>
bbox rendering because it is restricted to shapes. Also a bbox needs<br>
to be displayed even if the shape is not visible which complicates<br>
logic.<br>
<br>
In turn, this means it appears to be necessary to add an internal bbox<br>
Shape for each X3DBoundedObject to the scene graph which is managed by<br>
the engine. Since the bbox size needs to be updated at each traversal<br>
this will add some overhead. I guess if the updates are only performed<br>
when the bbox is visible this may be ok but the check is still<br>
necessary. Also the bbox shapes need to be created for a lot of<br>
objects, perhaps on demand only which could be an optimization. It<br>
will be necessary to be careful in cleaning up when a X3DBoundedObject<br>
is deleted from the scene graph.<br>
<br>
Finally, I am considering adding an SFNode field to X3DBoundedObject<br>
"bboxTemplate" which would be a Shape node or a Grouping node and<br>
would let the scene designer customize the kind of bounding box used<br>
for the display. By default it would be a green cage or such. It is<br>
expected to be of unit size, and scaled internally (by a Transform<br>
wrapper) to the actual bbox size. ( Hm, this would probably mean<br>
allowing subShapes to Shape nodes as children. It may be possible to<br>
deal with bboxes for Shapes as siblings, or in general as siblings,<br>
eg. child of parent ).<br>
<br>
By default the size of the displayed bbox would be a tight fit but it<br>
would look probably better to make it a little larger. So another<br>
custom field could be SFFloat "bboxMargin", zero by default.<br>
<br>
What strategies do FreeWRL, x_ite or castle use to implement<br>
bboxDisplay while keeping overhead at a minimum ? Check at each<br>
traversal and insert a scaled bbox ? As an option in the shader ?<br>
<br>
Depending on the strategy, would it make sense to support a custom<br>
bounding box ?<br>
<br>
A somewhat unrelated question is if a displayed bounding box is<br>
eligible to be sensed by Sensors such as a TouchSensor ? Presumably,<br>
it should be completely inert and be ignored but I am not sure if this<br>
is how the spec. intends to be read. I think in x3dom it should be<br>
possible to make sensing eligibility configurable.<br>
<br>
Thanks for any feedback,<br>
<br>
Andreas<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>