[x3d-public] bboxDisplay considerations

Wed Mar 29 06:10:14 PDT 2023

( Sorry for late response about CGE/view3dscene state: )

We do not yet implement  X3DBoundedObject.bboxDisplay *yet*.

Developers can of course implement bbox display manually for any 3D
object they want. (To query bounding box of an arbitrary X3D group,
one can start at TShapeTreeGroup that corresponds to X3D group, and
you can calculate bbox looking at children.)

We have in CGE ready components in `CastleDebugTransform` unit to
visualize CGE transformations and scenes. These are also used to
highlight picking in CGE editor. But they do not support bbox on any
X3DBoundedObject inside X3D -- no big reason, we just didn't really
need it *so far* :)

As for future implementation of X3DBoundedObject.bboxDisplay, I
haven't really decided, we have 2 possibilities that I think match
designs mentioned in this thread by others:

1. Create (on demand) internal X3D nodes to display box at each X3DBoundedObject

2. Or do direct rendering of bbox that "goes around" normal X3D
rendering. We have a class TCastleRenderUnlitMesh (
https://castle-engine.io/wp/2023/02/19/shadow-volumes-and-shadow-maps-work-on-mobile-opengl-es-and-we-have-a-new-tcastlerenderunlitmesh-utility-class/
) to do simple rendering "explicitly", i.e. without the need to manage
X3D nodes.

I think in this case AD 2 is more appealing to me, but they really
both make sense.

Thank you for this thread, it's informative to know approaches taken
by all X3D browsers for this.

Regards,
Michalis

wt., 28 mar 2023 o 19:30 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> Thanks. I know, all the cubes look impressive but probably would not
> be considered particularly high performance these days. The bbox
> implementation itself is not really optimized, other than the bbox
> size of invisible grouping nodes only being updated when the bbox
> display is on. Standalone x3d browsers will be much higher
> performance, eg. could deal with much larger scenes.
> Picking in x3dom is done by rendering the scene only in a few pixels
> (or actualy just one pixel) around the mouse pointer with shaders
> which return an object id and distance as color. This can deal with
> complex scenes and avoids CPU ray intersection calculations but limits
> precision somewhat in expansive scenes.
>
> Do we need to discuss how a browser should deal with display=true
> bboxes inside invisible grouping nodes ? The situation may be left
> unspecified as it probably occurs rarely.
>
> Andreas
>
> On Tue, Mar 28, 2023 at 12:39 PM Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu> wrote:
> >
> > Wow.  Tweet with screenshots:
> >
> >
> >
> > Interesting, cool, high-performance implementation of new #X3D 4.0 feature bboxDisplay field for any Shape geometry in #X3DOM player. Who said boxes have to be lines? https://raw.githack.com/andreasplesch/x3dom/9059fe8fa238aa19a90917429925b7b300b8b760/test/regression-suite/test/cases/routes/routes.html
> > https://twitter.com/Web3DConsortium/status/1640753409241550848
> >
> >
> >
> > v/r Don
> >
> >
> >
> > -----Original Message-----
> > From: Andreas Plesch <andreasplesch at gmail.com>
> > Sent: Monday, March 27, 2023 7:14 PM
> > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> > Cc: Holger Seelig <holger.seelig at yahoo.de>; Doug Sanden <gpugroup at gmail.com>; X3D <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] bboxDisplay considerations
> >
> >
> >
> > I am testing bboxDisplay with
> >
> > https://raw.githack.com/andreasplesch/x3dom/9059fe8fa238aa19a90917429925b7b300b8b760/test/regression-suite/test/cases/routes/routes.html
> >
> > and it looks complete enough to be useful. The X3D textured boxes have bboxes on the surrounding transform. The WebGL textured boxes have bboxes on the Shape which can be toggled with a TouchSensor. The grouping bboxes have the same alignment as they do in x_ite which also works fine with the scene.
> >
> > I think there will be a bboxMargin field as well. It will add a margin, scaled to the box diameter and constant in each dimension.
> >
> > Visually, a transparent box might be appealing and more robust to be able to be detected against backgrounds or textures. A lineset cage seems to be more standard but webgl cannot render thicker lines reliably.
> >
> >
> >
> > An interesting but unavoidable drawback is that DEF/USE instances cannot be highlighted individually. It is all or none. Nested instancing leads to many bboxes in the example. Single instance bboxes seem desirable but possibly not compatible with author control.
> >
> >
> >
> > -Andreas
> >
> >
> >
> > On Sun, Mar 26, 2023 at 10:03 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > >
> >
> > > Working on a first version of bboxDisplay, I came across a few more decisions.
> >
> > >
> >
> > > The spec. language says that "The bounding box is displayed regardless
> >
> > > of whether contained content is visible.".  This is useful for
> >
> > > debugging purposes. x3dom may not correctly update bboxes when
> >
> > > non-visible content changes.
> >
> > >
> >
> > > There is also the reverse situation when the bounding box is contained
> >
> > > within a grouping node which is not visible. Because further traversal
> >
> > > into a non-visible grouping node is not normally needed, x3dom would
> >
> > > not display bboxes contained in non-visible nodes for performance
> >
> > > reasons.
> >
> > >
> >
> > > Another perhaps somewhat surprising point is that bboxes are aligned
> >
> > > with the local, surrounding coordinate system of grouping nodes. This
> >
> > > means that displaying the bbox of a Transform does not adjust to any
> >
> > > changes to that transform, only to changes to the surrounding
> >
> > > transform. This is the sensible solution but may be surprising to
> >
> > > authors at first. Authors can always use the bbox of an additional
> >
> > > Group inside such a transform.
> >
> > >
> >
> > > Any feedback welcome, Andreas
> >
> > >
> >
> > > On Fri, Mar 24, 2023 at 11:26 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > > >
> >
> > > > These are good points. However, the author, not necessarily the
> >
> > > > browser, would typically know best how to use color for any intended
> >
> > > > purpose. After all, the author needs to decide when to display or
> >
> > > > hide the bbox. Of course, any browser can have user preferences
> >
> > > > which may override author choices.
> >
> > > >
> >
> > > > I believe browser debug and ui features would be independent of the
> >
> > > > bboxDisplay field. It is a field exposed for authoring purposes.
> >
> > > >
> >
> > > > I can also see the value in the argument that because it is a simple
> >
> > > > feature, its control should be simple. Richer bboxes would need to
> >
> > > > be custom made, perhaps with prototypes. On the other hand, from an
> >
> > > > implementation perspective, simple may mean "just another shape" to
> >
> > > > render which then could be easily exposed to the author.
> >
> > > >
> >
> > > > Well, enough looking. Perhaps time to proceed,
> >
> > > >
> >
> > > > Andreas
> >
> > > >
> >
> > > > On Fri, Mar 24, 2023 at 5:35 PM Brutzman, Donald (Don) (CIV)
> >
> > > > <brutzman at nps.edu> wrote:
> >
> > > > >
> >
> > > > > 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
> >
> > > > >
> >
> > > > > Browsers might have their own algorithms or user preferences,
> >
> > > > > There is no “correct” color since farther objects and Background
> >
> > > > > color might be the same or similar, Browsers might decide to do
> >
> > > > > color “negation” or some other technique for contrast, 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
> >
> > > > >
> >
> > > > >
> >
> > > > > 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