[x3d-public] bboxDisplay considerations

[Andreas Plesch]

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