[x3d-public] candidate feature: display bounding box

[Andreas Plesch]

Another aspect of showBBox is whether the displayed bbox should
replace or augment the normal rendering. Probably augmenting is what
most would assume but I think it would need to be spelled out.

Another aspect is how to deal with non-visual content of a
X3DBoundedObject, say an empty Group with explicit bounding box, or a
Viewpoint or ProximitySensor inside a Transform with explicit bounding
box. Probably just display bbox if explicit, and ignore if no bounding
box can be computed. Does that need to be specified ?

X3D defines the bounding box aligned with local coordinate system:
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/group.html#BoundingBoxes
If the appearance of a display bounding box is left unspecified, then
it would make sense to also allow display as world axis aligned
bounding boxes.

Finally, I think any more sophisticated bounding box rendering would
need to be left to an author, using switch nodes, or the visible
field, or prototypes. For example, an author could just place a shape
representing a bounding box (eg. a transparent box, or glowing cage
with the right dimensions) as a sibling to the bounded object and
control its display. If there are many objects, these are typically
generated, and the generation then can also generate the bounding box
shapes.


On Fri, Jan 24, 2020 at 7:33 AM Don Brutzman <brutzman at nps.edu> wrote:
>
> Glad that this issue is worth considering, thanks for implementer perspective.  More follows below from Thursday's teleconference adding perspectives for authors and users.
>
> On 1/21/2020 8:32 AM, Andreas Plesch wrote:
> > On Tue, Jan 21, 2020 at 11:06 AM Don Brutzman <brutzman at nps.edu> wrote:
> >>
> >> Thanks for considering impact.  Since bounding boxes are easily/commonly computed, am thinking that implementation isn't difficult.  It seems to apply to two classes of nodes, either shapes or else nodes that group shapes together (e.g. X3DGroupingNode, NurbsSet etc.)
> >
> > The issue with implementation is not that it is difficult to compute.
> > Indeed, the bbox will be computed anyways. But rendering is another
> > matter. It would add a whole new class of renderable objects which
> > will require deeper changes in most implementations. But certainly
> > doable. The performance impact may need to be considered to, if it is
> > a inputoutput field. How would one avoid impacting performance when no
> > bbox are shown, the default case ?
> >
> >> Note that this only impacts the specific X3DBoundedObject that it applies too, authors and tools would be able to selectively apply it within the scene graph tree of interest for the degree of detail needed.
> >>
> >> Supporting debugging during authoring is good, have added it to the multiple other benefits.  Potentially may have extra benefit when testing across multiple display types or interaction devices.
> >>
> >> Am thinking that this feature can be a potential benefit to interactive usability and user experience as much as anything else, not just a low-level graphics embellishment.
> >
> > It could be useful for highlighting, or selecting. But it would be
> > pretty rudimentary since some browsers may use thin black lines, some
> > browsers may use fat green lines or tubes and other browsers may use a
> > semitransparent box. A good UI will be probably require more
> > predictability. But for a quick solution it would be quite useful.
> > [...]
> /Adding visible field to X3DBoundedObject has exposed possibly adding displayBBox/
>
> * Relevance to DPS is that both features are common to many CAD-related interactions and also appear relevant to scanning creation of meshes.
>
> * Also interesting that both hiding and highlighting are complementary functions (from a user perspective) and indeed “easily doable” (check) in X3DBoundedObject.
>
> * Visible is similar but not the same as Switch (which requires Scripting or Sequencers at a higher profile) because it is boolean and easily aligned with HTML-style animation.  Switch is heavyweight and not readily modeled in actual models.
>
> * Concerns about cost and details of rendering… Worth checking; already implemented in InstantReality and view3dscene so not a showstopper.
>
> * What would bounding box line color and line properties be?
> -- Always default grey, unspecified
> -- Browser preference
> -- Figure out how LineProperty node might be added, otherwise use default values (e.g. grey)?
> -- Is highlighting sufficient?  Browser gets choice beyond default grey bbox.
>
> * Motivation for displaying bounding box is usability: selection, navigation, displaying state.  Interestingly both visible and displayBBox * facilitate common tasks for all three of these.
>
> * Addition of CSS classes to X3D scene graph might permit patterns that mimic HTML pages.  Such DOM-based page implementation as possible already.
>
> * Goal is to avoid making things more complex, keeping it simple as possible.
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman



-- 
Andreas Plesch
Waltham, MA 02453