[x3d-public] bboxDisplay considerations

[Holger Seelig]

Yes bboxSize and bboxCenter can be directly used as scale and translation for a transformation matrix for a bboxShape with size at 1. 

I also miss the possibility of setting the color of the box.

Holger Seelig
Leipzig, Germany
holger.seelig at yahoo.de



> Am 24.03.2023 um 19:15 schrieb Andreas Plesch <andreasplesch at gmail.com>:
> 
> Following up, I looked up the bboxDisplay implementation in x_ite, and
> it does pretty much follow what I outlined, eg. using an additional
> internal, on demand Shape. Instead of wrapping in a Transform, for
> scaling it multiplies in a local transform matrix to the model view
> matrix. it is not strictly part of the scene graph but gets added
> during render traversal but not picking traversal. The bbox shape is
> predefined as a white IndexedLineset but presumably could be
> generalized/made customizable.
> 
> I hope it is possible to avoid special treatment during traversal and
> just manage as a regular, inert scene graph participant. Let's see.
> 
> Ok, this was helpful. Andreas
> 
> On Fri, Mar 24, 2023 at 12:10 PM 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
> 
> 
> 
> -- 
> 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/5d5ea12f/attachment.html>