[x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: prototype polymorphism
doug sanden
highaspirations at hotmail.com
Mon Feb 13 08:17:23 PST 2017
Proto Polymorphism >
Design4: the proto instance's rootnode list is scanned until a match to the parent field's required nodetype(s) is found.
There are other designs that have a different flavor, and would have different answers below. So even if you don't like Design4 answers, I recommend you don't 'throw the baby out with the bathwater' just yet - keep proto polymorphism alive as a possibility with some other design.
> 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?
No.
...
I think there is a way to do the RBP 3-list use-case by passing the lists as SFNodes down through prototype interface fields -so an encapsulated part would self-register in collision and physics lists- and that's probably how you would do it for hierarchical machine parts.
...
On Flexibility:
I program in C. Somehow I get the same things done as others working in C++ and Java, although I have to work harder. So if 'flexibility' was discounted for computer languages, perhaps we'd all still be using assembler.
A better filter: does it make something easier, can you build up bigger, more complex scenes easier, with objects staying closer to semantic/meaning. Flexibility, readability, ease of doing big things.
...
And the idea of proto polymorphism seems like a cheap way to boost x3d, and leverage x3d's current relative strength in prototyping.
> 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?
RBP 3-list use case.
>
> 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?
RBP 3-list use case.
>
> 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?
Yes, but only if you use the protoinstance somewhere that the first node doesn't match the parent's field.
In that case:
current behaviour: browser says bad node, or treats as null / nullptr / no-node-in-field and doesn't use.
design4 proposed behaviour: browser finds the script, if parent field can allow a child node, and uses it.
So you would put your more specialized nodes ahead of your generic child nodes.
body[
def mat0 material
shape {... material use mat0 }
]
design4 weakness: if all of the types to be polymorphized are child nodes, and all target parent fields accept children, then there's no way to arrange the rootnodes to polymorphize: they'll all get the first node.
>
> 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?
Depends how you do it. Freewrl delay-loads extern protodeclares. So when parsing, and it hits an externProtoInstance, it puts a stub - no body. The body is inserted/instanced later when the extern proto declare shows up. If some rendering loops pass before the body is populated, the parent gets a NULL as if there was no concrete node type in the field.
So with the current x3d, its already up to the browser code to verify at runtime, and that would continue.
> f. Browser implementability. Similar question, different POV:
> estimating how much more work is it for a browser builder to extend
> their current capabilities.
Good question. already browsers:
- detect if SFNode field is populated by a node, and if the node is a protoinstance
- if protoinstance, get the first node
- check the first node is a compatible type (perhaps return something like null or nullpointer if not the right type)
So with design4 they would need to keep going in a loop, if its not the right type, until rootnode list is exhausted, then return nullptr if no suitable type found.
>
> g. Design patterns. Anything else we might learn from design and usage
> of other languages?
>
In C++, visual basic I've used polymorphism to process lists: I have a list of generic objects and I want to process them different ways. In a loop, I would ask each object for a certain interface, or if its of a certain type, and if it so -if its of a type or has the interface I want- then process it through that interface/type.
That implies there's some way to
a) ask for a certain interface/type
b) take no for an answer
________________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of doug sanden <highaspirations at hotmail.com>
Sent: February 12, 2017 1:47 PM
To: x3d-public at web3d.org
Subject: Re: [x3d-public] [x3d] Spec Comment by dougsanden on 19775-1: prototype polymorphism
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
_______________________________________________
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