[x3d-public] bboxDisplay considerations

[GPU Group]

https://sourceforge.net/p/freewrl/git/ci/develop/tree/freex3d/src/lib/ui/CursorDraw.c
draw_bbox line 726 delegates to extent6f_draw() line 638.


On Fri, Mar 24, 2023 at 1:38 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Hi Doug,
>
> Thanks for the quick response. In the browser, with slow javascript
> but fast hw rendering we probably have to be mindful about CPU each
> frame. I think in x3dom the bbox for all grouping nodes is already
> properly updated when necessary. I was still a bit worried about the
> additional work of having to apply these updates to display boxes each
> frame. The draw_bbox function seems to be a place holder ?
>
> Cheers. Andreas
>
> On Fri, Mar 24, 2023 at 2:14 PM GPU Group <gpugroup at gmail.com> wrote:
> >
> > 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230324/7362ef25/attachment.html>