[x3d-public] bboxDisplay considerations

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Fri Mar 24 14:35:05 PDT 2023

Thanks for close looks at this, it holds a lot of potential value.  Hopefully more-effective bounding boxes will improve authoring, debugging, and user interaction.


We intentionally did not specify an X3D4 bboxColor field since

a.	Browsers might have their own algorithms or user preferences,
b.	There is no “correct” color since farther objects and Background color might be the same or similar,
c.	Browsers might decide to do color “negation” or some other technique for contrast,
d.	Browsers might also use it for indication of picking, selection, collision.


Authoritative references:


*	X3D4 Architecture, Grouping component, 10.3.1 X3DBoundedObject
*	https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.review/Part01/components/grouping.html#X3DBoundedObject


*	X3D4 Architecture, Grouping component, 10.2.2 Bounding boxes
*	https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.review/Part01/components/grouping.html#BoundingBoxes


v/r Don


From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Holger Seelig
Sent: Friday, March 24, 2023 1:48 PM
To: Andreas Plesch <andreasplesch at gmail.com>
Cc: X3D <x3d-public at web3d.org>
Subject: Re: [x3d-public] bboxDisplay considerations


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 <mailto:holger.seelig at yahoo.de> 



Am 24.03.2023 um 19:15 schrieb Andreas Plesch <andreasplesch at gmail.com <mailto: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 <mailto: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:


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

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

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 Plesch
Waltham, MA 02453

Andreas Plesch
Waltham, MA 02453

x3d-public mailing list
x3d-public at web3d.org <mailto:x3d-public at web3d.org> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230324/54d58158/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5464 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230324/54d58158/attachment-0001.p7s>

More information about the x3d-public mailing list