[x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: prototype polymorphism

doug sanden highaspirations at hotmail.com
Sun Feb 12 12:47:09 PST 2017


RigidBodyPhysics > encapsulating visual (shape with materials), collision (simplfied geometry) and physics (mass) nodes, for use in 3 separate lists for any given macine part, allowing complex machine to be build up from parts, each part holding all 3 types.
3 lists:
RigidBodyCollection
CollisionCollection
(regular visual scenegraph)
-Doug
..
more..
Note from former web3d user:
"""
...
It made me also 
think about the world around VRML and I must say, that the standard came 
too early and was too difficult to implement and to use at full scale. 
Too sad - I find some of its ideas brilliant (I love prototyping!).
...
 Physics: I studied the physics extension for VRML a few years ago 
(omg, its more than a decade now!). I really didn't like the proposal to 
separate geometry from physical properties of objects, which makes 
prototyping practically unusable (may be it changed over the years).
...
"""

________________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Don Brutzman <brutzman at nps.edu>
Sent: February 12, 2017 1:25 PM
To: X3D Graphics public mailing list
Cc: x3d at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: prototype polymorphism

Doug, thanks for this interesting concept on how prototypes might be made polymorphic by having multiple candidate root nodes, selectively matching intended use.  (Also thanks for permission to share without further ado.)

Since this is a pretty sophisticated topic, am hoping you might describe further what you are thinking.

There are a number of helpful concepts regarding polymorphism on the Wikipedia page:

        https://en.wikipedia.org/wiki/Polymorphism_(computer_science)

It will be great to hear more from you on this... Beyond use cases and perhaps an pseudocode example, several issues of related interest include:

a.  New capabilities. A great variety of behaviors are already possible depending on a ProtoInstance's field (parameter) values.  Aside from language and prototype-design flexibility, is there some new capability that becomes possible through polymorphism?

b. Problem being solved.  From a scene-author's perspective, is there a particular problem or shortfall with X3D capabilities that is getting fixed by this approach?

c. Expected usage.  When do you want a single protoinstance node that can be repeatedly applied as either a Group or Shape or Appearance or Material or Texture?

d. Value of hiding (i.e. not rendering) nodes.  Perhaps an interesting design feature of a prototype is the ability to "hide" non-rendered nodes in a scene graph, for example a Script can immediately follow an initial Material node within a ProtoBody. Does polymorphism break that contract?

e. Scene graph validity.  Strict (strong) typing is a major strength of X3D scene graph; prototypes are wild cards that have strong typing checks deferred until run time.  (hmmm, perhaps X3D Validator might also check a scene for consistency).  Wondering, does polymorphism break that strong-typing contract between parent and child nodes?

f. Browser implementability.  Similar question, different POV: estimating how much more work is it for a browser builder to extend their current capabilities.

g. Design patterns.  Anything else we might learn from design and usage of other languages?




On 2/12/2017 6:42 AM, Spec Feedback wrote:
> -- Submitter indicates that this comment may be public: *Yes* --
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 4.4.4.3 Proto definition semantics
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#PROTOdefinitionsemantics
>
> -----------------
> Polymorphic Protos > design:
> 4. just change of spec wording and corresponding change to code behaviour in browsers:
> Current v3.3:
> "The first node type determines how instantiations of the prototype can be used in an X3D file."
> Proposed polymorphic:
> "The root node type(s) determines how instantiations of the prototype can be
> used in an X3D file: starting with the first root node, each successive root
> node is trial fitted to the protoinstance's parent node field until an
> allowed match is found. Then the match is used in the parent field to
> represent the protoinstance type."
> -----------------
>
> Submitted on Sunday, 2017,  February 12 - 6:42am
> by dougsanden (dougsanden )
>
> See: http://www.web3d.org/node/1694/submission/1230
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org


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

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org



More information about the x3d-public mailing list