[x3d-public] bboxDisplay considerations

[GPU Group]

FreeWRL - refreshes the bounding box for Group, Transform, other grouping
nodes on each frame, during rendering
https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/scenegraph/Component_Grouping.c
in child_Transform(), child_Group etc 3 lines:
prep_Bbox(...)
normal_Children(...)
fin_Bbox(...)
The prep clears the bbox
Each child rendered UNIONs its bbox/extent to group bbox
the fin - depends
- if its Group, just copies the summed /unioned children bbox to Group as
its bbox
- if its Transform, transforms the children bbox into Transform parent
space as transform's bbox
We used to do it a different clunky way only if a node changed - a weird
trickle-up algorithm that didn't work well.
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.
https://freewrl.sourceforge.io/tests/10_Grouping/bbox/2.x3d
-Doug



On Fri, Mar 24, 2023 at 10:10 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Please forgive me if I use this message to plan strategies for a
> possible implementation of bboxDisplay for x3dom. There will be a few
> questions at the end.
>
> To start, it is already quite straightforward to generate visual
> feedback for selection purposes in x3dom. Here are a few examples:
>
>
> https://andreasplesch.github.io/Library/Examples/html5/highlight/turnyellow.html
>
> https://andreasplesch.github.io/Library/Examples/html5/highlight/withBBox.html
>
> https://andreasplesch.github.io/Library/Examples/html5/highlight/outline.html
>
> Thinking about generalizing to any X3DBoundedObject leads to the
> following observations.
>
> In x3dom, only Shapes are collected for rendering during scene
> traversal. Displaying a bbox for groups etc. breaks this basic
> pattern.
>
> Although a custom shader would be most performant, this means it is
> not really advantageous to expand the shader to include an option for
> bbox rendering because it is restricted to shapes. Also a bbox needs
> to be displayed even if the shape is not visible which complicates
> logic.
>
> In turn, this means it appears to be necessary to add an internal bbox
> Shape for each X3DBoundedObject to the scene graph which is managed by
> the engine. Since the bbox size needs to be updated at each traversal
> this will add some overhead. I guess if the updates are only performed
> when the bbox is visible this may be ok but the check is still
> necessary. Also the bbox shapes need to be created for a lot of
> objects, perhaps on demand only which could be an optimization. It
> will be necessary to be careful in cleaning up when a X3DBoundedObject
> is deleted from the scene graph.
>
> Finally, I am considering adding an SFNode field to X3DBoundedObject
> "bboxTemplate" which would be a Shape node or a Grouping node and
> would let the scene designer customize the kind of bounding box used
> for the display. By default it would be a green cage or such. It is
> expected to be of unit size, and scaled internally (by a Transform
> wrapper) to the actual bbox size. ( Hm, this would probably mean
> allowing subShapes to Shape nodes as children. It may be possible to
> deal with bboxes for Shapes as siblings, or in general as siblings,
> eg. child of parent ).
>
> By default the size of the displayed bbox would be a tight fit but it
> would look probably better to make it a little larger. So another
> custom field could be SFFloat "bboxMargin", zero by default.
>
> What strategies do FreeWRL, x_ite or castle use to implement
> bboxDisplay while keeping overhead at a minimum ? Check at each
> traversal and insert a scaled bbox ? As an option in the shader ?
>
> Depending on the strategy, would it make sense to support a custom
> bounding box ?
>
> A somewhat unrelated question is if a displayed bounding box is
> eligible to be sensed by Sensors such as a TouchSensor ? Presumably,
> it should be completely inert and be ignored but I am not sure if this
> is how the spec. intends to be read. I think in x3dom it should be
> possible to make sensing eligibility configurable.
>
> Thanks for any feedback,
>
> Andreas
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230324/08e63b1f/attachment.html>