VRML - prototype: browser differences ( with examples.)

Author

prototype: browser differences ( with examples.)

simon

2004-09-28, 7:27 am

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>

Joerg Scheurich aka MUFTI

2004-09-28, 7:27 am

> Explanation of problem:
> ~~~~~~~~~~~~~~~~~~~
> Although the nodes ( except script ) inside a prototype shouldn't be
> active past the first one,

This is wrong. The VRML97 standard (still the current standard till
next month) says:

http://www.web3d.org/x3d/specificat...ncepts.html#4.8

| 4.8.3 PROTO definition semantics
....
| 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.
....
| 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.

There is nothing about "not active", it is about "not part of the
transformation hierarchy".

http://www.web3d.org/x3d/specificat...epts.html#4.4.4

| 4.4.4 Transformation hierarchy
|
| The transformation hierarchy includes all of the root nodes and root node descendants
| that are considered
| to have one or more particular locations in the virtual world.
....
| The following node types are in the scene graph but not affected by the
| transformation hierarchy:
| ColorInterpolator, GeoPositionInterpolator, GeoMetadata,
| CoordinateInterpolator, NavigationInfo,
| NormalInterpolator, NURBSPositionInterpolator, OrientationInterpolator,
| PositionInterpolator, Script,
| ScalarInterpolator, TimeSensor, and WorldInfo.

> 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.

Wrong (at least for VRML97 (ISO14772:2002))

TimeSensor and Script are not affected by the transform hierarchy, therefore
blaxxun, cortona and octagon are correct, while flux is wrong.

> test 2. reorder elements to
> proto [ timeSensor , shape , script , routes ]
> result: blaxxun works.

What means "working" ? Do you see the shape ?

Everyone else doesn't shows anything, which is
> correct because the shape shouldn't be available.

> test 3
....
> result: all browsers work!

> test 4
....
> result: blaxxun and cortona work, flux and octagon give parser error,
> the error is correct,

Did you find a statement in the ISO 14772 text, that forces browsers to
show a error on a file with invalid grammar ?
I did not find one.
Please note, that major authoring tools for VRML97 produce such a error 8-(Please note, that major authoring tools for VRML97 produce such a error 8-(Please note, that major authoring tools for VRML97 produce such a error 8-(

I suspect it is allowed for a computer programm, to render non-VRML files
(e.g. files without the #VRML V2.0 utf8 header)...

Of course programs should at least show a warning, when they render non
VRML files...

> test 5.
....
> proto [ transform [ shape , timesensor, script (routes) ] ]

Did you intented to say:

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. True for the "script { routes }" version.

> test 6.
....
> result: all browsers work! ( again correct to the specification.)

> conclusion
> ~~~~~~~~~

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

Other conclusion:

For your tests, flux is the loosest to the VRML97 spec

> <quote ISO-IEC-19775-FDIS-X3dAbstractSpecification >
> 4.4.4.3 PROTO definition semantics

This is not VRML97, it is a (possibly outdated ?) X3D draft. X3D still do
not exist (yet).

> 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.

This quote also talk about the transformation hierarchy....

> #VRML V2.0 utf8
> PROTO any []{

Your example has a VRML97 header, not a X3D header...

Unfortunatly, you did not tested Cosmoplayer, Xj3D, cybergarage, OpenVRML
and FreeWRL.
Could you please public your tests on a website, so we can continue ?

so long
MUFTI
--
Wenn ich verdopple, klicken Sie im browser, Bilder werden in gesaust.
(aus einem Softwarehandbuch)

simon

2004-09-28, 7:27 am

Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<cj0vpt$8ua$1@infosun2.rus.uni-stuttgart.de>...
>
> This is wrong. The VRML97 standard (still the current standard till
> next month) says:
>
> http://www.web3d.org/x3d/specificat...ncepts.html#4.8
>
> | 4.8.3 PROTO definition semantics
> ...
> | 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.
> ...
> | 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.
>
> There is nothing about "not active", it is about "not part of the
> transformation hierarchy".
>

i was using "not active" specifically because it isn't defined.

> http://www.web3d.org/x3d/specificat...epts.html#4.4.4
>
> | 4.4.4 Transformation hierarchy
> |
> | The transformation hierarchy includes all of the root nodes and root node descendants
> | that are considered
> | to have one or more particular locations in the virtual world.
> ...
> | The following node types are in the scene graph but not affected by the
> | transformation hierarchy:
> | ColorInterpolator, GeoPositionInterpolator, GeoMetadata,
> | CoordinateInterpolator, NavigationInfo,
> | NormalInterpolator, NURBSPositionInterpolator, OrientationInterpolator,
> | PositionInterpolator, Script,
> | ScalarInterpolator, TimeSensor, and WorldInfo.
>
>
> Wrong (at least for VRML97 (ISO14772:2002))

i suppose this spec (the one i'm using) is out-of-date as well.

Version 2.0, ISO/IEC 14772

The first node found in the prototype definition is used to define the
node type of this prototype. This first node type determines how
instantiations of the prototype can be used in a VRML file. An
instantiation is created by filling in the parameters of the prototype
declaration and inserting 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, then
instantiations of the prototype can be used wherever a Material can be
used. Any other nodes and accompanying scene graphs are not rendered,
but may be referenced via routes or scripts (and thus cannot be
ignored). The following example defines a RampMaterial prototype which
animates a Material's diffuseColor continuously and that must be used
wherever a Material can be used in the file (i.e. within an Appearance
node):

nothing here defining "transformation hierarchy".

> TimeSensor and Script are not affected by the transform hierarchy, therefore
> blaxxun, cortona and octagon are correct, while flux is wrong.
>
>
> What means "working" ? Do you see the shape ?

Yes, blaxxun is the only one to produce output and is wrong.

>
> Everyone else doesn't shows anything, which is
>
> ...
>
>
> ...
>
> Did you find a statement in the ISO 14772 text, that forces browsers to
> show a error on a file with invalid grammar ?
> I did not find one.
> Please note, that major authoring tools for VRML97 produce such a error 8-(Please note, that major authoring tools for VRML97 produce such a error 8-(Please note, that major authoring tools for VRML97 produce such a error 8-(
>
> I suspect it is allowed for a computer programm, to render non-VRML files
> (e.g. files without the #VRML V2.0 utf8 header)...
>
> Of course programs should at least show a warning, when they render non
> VRML files...
>

isn't this a little philosophical, a standard only applying when the
standard is adeared too, don't you actually rely on the fact that you
are trying to render VRML to indicate that the strandard should apply?
and this is at a level outside the standard.

Are you familier with the problem as to weather, or not, a book in a
library, that contains an index to that library, should be included as
an entry in itself?

> ...
>
> Did you intented to say:
>
> proto [ transform [ shape , timesensor, script { routes } ] ]
>

sure, if you like, but its my pseudo code!

> ???
>
>
> ...
>
>
>
> Other conclusion:
>
> For your tests, flux is the loosest to the VRML97 spec
>

i think Blaxxun's problem with test 2. is the biggest issue, it seems
like blaxxun just allows anything, which, as i said, might be a good
approach, if it wasn't the clearest violation of the spec.

I was wrong about Example 1. so Flux is the worst here, but it still
displays the shape.

>
> This quote also talk about the transformation hierarchy....
>
>
> Your example has a VRML97 header, not a X3D header...
>
> Unfortunatly, you did not tested Cosmoplayer, Xj3D, cybergarage, OpenVRML
> and FreeWRL.
> Could you please public your tests on a website, so we can continue ?
>
> so long
> MUFTI

behaps you could test these, i 'only' have four browsers installed!

i've put a table of the results at:
vrml.portland.co.uk/conformance/prototype/index.html

with links to the tests, including two new ones.

i've now read all the specs i can find, i'm now i'm not sure about
background and viewpoint nodes, and it looks like the browser
developers aren't either!

simon.

Joerg Scheurich aka MUFTI

2004-09-28, 7:27 am

> i suppose this spec (the one i'm using) is out-of-date as well.

> Version 2.0, ISO/IEC 14772

....

> nothing here defining "transformation hierarchy".

What is the source of this words ?

> behaps you could test these, i 'only' have four browsers installed!

> i've put a table of the results at:
> vrml.portland.co.uk/conformance/prototype/index.html

> with links to the tests, including two new ones.

FreeWRL 1.07

FreeWRL : s1.wrl: shows a scaling box
FreeWRL : s2.wrl: shows a scaling box
FreeWRL : s3.wrl: shows a scaling box
FreeWRL : s4.wrl: PARSE ERROR
FreeWRL : s5.wrl: PARSE ERROR
FreeWRL : s6.wrl: shows a scaling box
Warnings:
Node DEF3 is not defined at /usr/lib/.../Scene.pm line595
Node DEF1 is not defined at /usr/lib/.../Scene.pm line595
FreeWRL : s7.wrl: shows a scaling box and a somewhat gray/black background
filling the lower part of the world
FreeWRL : s8.wrl: shows two scaling boxes, Name of viewpoint: 1

Xj3d (AFAIK, M9 release)

xj3d: s1.wrl: shows a scaling box
xj3d: s2.wrl: shows nothing
xj3d: s3.wrl: shows a scaling box
xj3d: s4.wrl Error message
starts with:
failed to load
xj3d: s5.wrl shows a scaling box
xj3d: s6.wrl shows a scaling box
xj3d: s7.wrl shows a box, then freeze
java dump starting with:
javax.media.j3d.RestrictedAccessException: Node: local to
vworld transform is undefined for a node that is not part
of a live scene graph
xj3d: s8.wrl shows nothing
java dump starting with:
javax.media.j3d.RestrictedAccessException: Node: local to
vworld transform is undefined for a node that is not part
of a live scene graph

> i've now read all the specs i can find, i'm now i'm not sure about
> background and viewpoint nodes,

It makes no sense to rotate/move a Background, but it is not the in the list
of the Transformation hierarchy.
But you can rotate/move a Viewpoint.

so long
MUFTI
--
Warning: This paper on SETI@home is written for scientists and engineers.
In order to confuse and obfuscate the public, we utilize substantial
technical jargon.
(Vorwort eines technischen Dokuments)

simon

2004-09-28, 7:27 am

Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<cj98gq$5ji$1@infosun2.rus.uni-stuttgart.de>...
>
>
> ...
>
>
> What is the source of this words ?
>

the definition of proto from vrml spec. 1996.
destinction between "scene tree" and "transformation hierarchy" came
later, i guess as a clarification.

>
>
>
>
>
> FreeWRL 1.07
>
> FreeWRL : s1.wrl: shows a scaling box
> FreeWRL : s2.wrl: shows a scaling box
> FreeWRL : s3.wrl: shows a scaling box
> FreeWRL : s4.wrl: PARSE ERROR
> FreeWRL : s5.wrl: PARSE ERROR
> FreeWRL : s6.wrl: shows a scaling box
> Warnings:
> Node DEF3 is not defined at /usr/lib/.../Scene.pm line595
> Node DEF1 is not defined at /usr/lib/.../Scene.pm line595
> FreeWRL : s7.wrl: shows a scaling box and a somewhat gray/black background
> filling the lower part of the world
> FreeWRL : s8.wrl: shows two scaling boxes, Name of viewpoint: 1
>

OK, so 2's wrong, 5 should parse OK, 6 warnings aren't required, and
background & viewpoint are both "active".

> Xj3d (AFAIK, M9 release)
>
> xj3d: s1.wrl: shows a scaling box
> xj3d: s2.wrl: shows nothing
> xj3d: s3.wrl: shows a scaling box
> xj3d: s4.wrl Error message
> starts with:
> failed to load
> xj3d: s5.wrl shows a scaling box
> xj3d: s6.wrl shows a scaling box
> xj3d: s7.wrl shows a box, then freeze
> java dump starting with:
> javax.media.j3d.RestrictedAccessException: Node: local to
> vworld transform is undefined for a node that is not part
> of a live scene graph
> xj3d: s8.wrl shows nothing
> java dump starting with:
> javax.media.j3d.RestrictedAccessException: Node: local to
> vworld transform is undefined for a node that is not part
> of a live scene graph
>

interesting, all OK, but seems not to like either background or
viewpoint in a proto root. ( shouldn't give an error anyhow. )

>
> It makes no sense to rotate/move a Background, but it is not the in the list
> of the Transformation hierarchy.
> But you can rotate/move a Viewpoint.
>

this list of nodes you posted from the spec, are those NOT in the
transformation hierarchy and so ARE "active" in a proto root. This
would imply background and viewpoint are both not "active".

But from the latest spec for X3D, ( i think all the specs are trying
to define the same thing.)

3.1.71
transformation hierarchy
subset of the scene graph consisting of nodes that have well-defined
coordinate systems

i'd have to say viewpoint should definitly be out, and you could even
argue that background has a coordinate system.

simon.

Note:

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.

Joerg Scheurich aka MUFTI

2004-09-28, 7:27 am

Joerg Scheurich aka MUFTI

2004-09-28, 7:27 am

>> vrml.portland.co.uk/conformance/prototype/index.html

Cosmo Player 2.1.5 (SGI IRIX) same results as Cosmo Player 2.1.1 (M$Windows)

> Cosmo : s1.wrl: shows a scaling box
> Cosmo : s2.wrl: shows nothing
> Cosmo : s3.wrl: shows a scaling box
> Cosmo : s4.wrl: # Error parsing 'ROUTE' at line 24: node name expected
> Cosmo : s5.wrl: complete crash of program
> Cosmo : s6.wrl: shows a scaling box
> Cosmo : s7.wrl: shows a scaling box
> Cosmo : s8.wrl: shows two scaling boxes, use sole default Viewpoint "[entry]"

> It makes no sense to rotate/move a Background, but it is not the in the list
> of the Transformation hierarchy.
> But you can rotate/move a Viewpoint.

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
--
Auserlesener Halt, da Video oder Lebhaftigkeit-Klammer zu halten
(aus einem Softwarehandbuch, Stichworte: animation und clip)

Joerg Scheurich aka MUFTI

2004-09-28, 7:27 am

> 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)