[x3d-public] candidate feature: display bounding box

[Don Brutzman]

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