<div dir="ltr"><a href="https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/ui/CursorDraw.c">https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/ui/CursorDraw.c</a><br><div>draw_bbox line 726 delegates to extent6f_draw() line 638.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 24, 2023 at 1:38 PM 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">Hi Doug,<br>
<br>
Thanks for the quick response. In the browser, with slow javascript<br>
but fast hw rendering we probably have to be mindful about CPU each<br>
frame. I think in x3dom the bbox for all grouping nodes is already<br>
properly updated when necessary. I was still a bit worried about the<br>
additional work of having to apply these updates to display boxes each<br>
frame. The draw_bbox function seems to be a place holder ?<br>
<br>
Cheers. Andreas<br>
<br>
On Fri, Mar 24, 2023 at 2:14 PM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> FreeWRL - refreshes the bounding box for Group, Transform, other grouping nodes on each frame, during rendering<br>
> <a href="https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Grouping.c" rel="noreferrer" target="_blank">https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Grouping.c</a><br>
> in child_Transform(), child_Group etc 3 lines:<br>
> prep_Bbox(...)<br>
> normal_Children(...)<br>
> fin_Bbox(...)<br>
> The prep clears the bbox<br>
> Each child rendered UNIONs its bbox/extent to group bbox<br>
> the fin - depends<br>
> - if its Group, just copies the summed /unioned children bbox to Group as its bbox<br>
> - if its Transform, transforms the children bbox into Transform parent space as transform's bbox<br>
> We used to do it a different clunky way only if a node changed - a weird trickle-up algorithm that didn't work well.<br>
> 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.<br>
> <a href="https://freewrl.sourceforge.io/tests/10_Grouping/bbox/2.x3d" rel="noreferrer" target="_blank">https://freewrl.sourceforge.io/tests/10_Grouping/bbox/2.x3d</a><br>
> -Doug<br>
><br>
><br>
><br>
> On Fri, Mar 24, 2023 at 10:10 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>