VRML - prototype: browser differences ( with examples.)

Author

prototype: browser differences ( with examples.)

simon

2004-09-28, 7:21 pm

dear all,

I've had some headaches with the root nodes in prototypes, so in a
effort to save others some time, here is what i hope is a simple
explanation of the issues that caused my problems, in the form of
examples, and what happens, or doesn't, in current browsers. ( latest
Windows versions of blaxxun, cortona, octagon, flux.)

Explanation of problem:
~~~~~~~~~~~~~~~~~~~
Although the nodes ( except script ) inside a prototype shouldn't be
active past the first one, they are allowed, and so their existance
doesn't report as an error, this, when conbined with browsers that
incorrectly support the excess nodes, can mean you have prototypes
working in several browsers when they shouldn't, and can't be relied
on to work in other or even later versions of the same browser.

I nievely thought you could just take a piece of VRML and wrap it in a
proto and it whould work, which in does in many common browsers, but
often it actually shouldn't, and this causes pitfalls. ( BTW it would
probably of been better if you could do this type of wrapping, its
less surprising.) check the extract from the specification at the
bottom of the page.

here are 6 tests to highlight what i'm talking about;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
based on the same animated box idea;

test 1.
proto [ shape , timeSensor , script , routes ] # hopefully self
explanitary pseudo code. ( see below for VRML example version.)
result: in blaxxun, cortona and octagon this works, in Flux you see
shape but it doesn't animate.
Flux is the only one that is correct, because in this position the
timesensor should not be available.

test 2. reorder elements to
proto [ timeSensor , shape , script , routes ]
result: blaxxun works. Everyone else doesn't shows anything, which is
correct because the shape shouldn't be available.

test 3. move the timesensor to inside a shape transform
proto [ transform [ shape , timesensor ] , script , routes ]
result: all browsers work! ( and this is correct to the
specification.)

test 4. move the routes to inside the shape transform
proto [ transform [ shape , timesensor, routes ] , script ]
result: blaxxun and cortona work, flux and octagon give parser error,
the error is correct, because only Nodes are allowed in a children
field because its a MFNode.

test 5. move the script to inside the shape transform, and routes
inside the script.
proto [ transform [ shape , timesensor, script (routes) ] ]
result: blaxxun cortona and octagon work, flux gives a parser error
for the routes, i think flux is wrong here because routes are allowed
anywhere a field is, and this is where the script node's fields are,
the only difference is that unlike other nodes the script node can
have multiple fields of the same type ( events ).

test 6. move the script and put the routes inside the timesensor.
proto [ transform [ shape , script , timesensor(routes) ] ]
result: all browsers work! ( again correct to the specification.)

conclusion
~~~~~~~~~

flux is tightest to the spec. and blaxxun the loosest.

you seem to always need more depth than you think. ( well i do
anyway.)

info
~~~~

<quote ISO-IEC-19775-FDIS-X3dAbstractSpecification >
4.4.4.3 PROTO definition semantics
A prototype definition consists of one or more nodes, nested PROTO
statements, and ROUTE statements. The first node type determines how
instantiations of the prototype can be used in an X3D file. An
instantiation is created by filling in the parameters of the prototype
declaration and inserting copies of the first node (and its scene
graph) wherever the prototype instantiation occurs. For example, if
the first node in the prototype definition is a Material node,
instantiations of the prototype can be used wherever a Material node
can be used. Any other nodes and accompanying scene graphs are not
part of the transformation hierarchy, but may be referenced by ROUTE
statements or Script nodes in the prototype definition.
</quote>

<vrml from test 3, the one that's the best. its a pulsing cube, by
the way>
#VRML V2.0 utf8
PROTO any []{
DEF ts5 Transform {
children [
Shape {
geometry Box {}
appearance Appearance {material Material {diffuseColor 0.8 0.8 0.8}
}}
DEF ts3 TimeSensor { cycleInterval 1 loop TRUE }
]
}
DEF ts4 Script {
eventIn SFFloat fin
eventOut SFVec3f fout
url ["java script:
function fin(v){
fout=new SFVec3f(v,v,v);
}
"]
}
ROUTE ts3.fraction_changed TO ts4.fin
ROUTE ts4.fout TO ts5.scale
}
any {}
</vrml>

simon

2004-09-28, 11:16 pm

>
> Viewpoint and Background are bindable children nodes, see
>
> http://www.web3d.org/x3d/specificat...pts.html#4.6.10
>
> | The first node within a prototype instance is a valid candidate
> | for the first encountered <bindable node>.
>
> so long
> MUFTI

I could have some more tests for this, but i'm not really looking at
the first node, AFAIK the first node in a proto is simply treated
like any node outside a proto, if a browser got this wrong it would
show up very quickly. I'm really only interested in the other nodes,
and i don't think you can assume anything about a node being in the
"transformation hierachy" from its bindability.

I still think neither of these are intended to be active in the later
nodes of a proto, when you think about it, there's no need for them to
be, all you get is side-effects, which are generally though to be lead
to confusion, and bugs.

I also think, that the browsers lack of conformance can be traced to
the specs lask of clarity, the concept could do with a rethink; how
about two types of proto,

1/ a single node proto, where the root is a SFNode, so you could use
a proto anywhere, as long as the type of SFNode matched with where it
was used.

2/ a multi-node proto, with a MFNode at its root, here all the nodes
would be active, so you could just wrap any snip of VRML code in a
proto ( could be called a VRML node, like the SVG node in SVG. )

simon.

simon

2004-09-29, 7:56 pm

Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<cje6tt$u1g$1@infosun2.rus.uni-stuttgart.de>...
>
> You can wrap any snip of VRML code in a proto by using Group as
> the first node...
>
> so long
> MUFTI

yes of course, but the real problem's that it's not obvious why you
have to do that, the idea of having TWO proto types is all about
making things less surprising.

the multinode type has all the nodes active, like as you say,
containing all the nodes in a group. The single node type is used to
allow the types to match with an other node.

But do you see what i mean, the confusion here, as is often the case,
comes from having a concept that is better conceptualised as two
related but different concepts. Splitting the terminology emphasises
the difference and produces clearer thinking, obviously there's an
advantage in having the minimum terminology, but i thing maybe here
the benefits exceed the cost, if you see what i mean.

simon.

Joerg Scheurich aka MUFTI

2004-10-02, 12:23 pm

> stuck your results on that page, also thought of a couple more
> browsers, if you know of any of these that have the same engine, i
> could probable cut a few off.

AFAIK Cosmo and Piviron use the same engine.

BTW: X3DBrowserGLUT (cybergarage cx3dcc 1.01) for IRIX show nothing for all
tests. It looks like, it do not support PROTOs 8-(

so long
MUFTI
--
Auserlesener Halt, da Video oder Lebhaftigkeit-Klammer zu halten
(aus einem Softwarehandbuch, Stichworte: animation und clip)