VRML - Errors Translating ROUTE definition from VRML to X3D

Author

Errors Translating ROUTE definition from VRML to X3D

Palu

2005-10-05, 6:29 pm

Did you notice that if you have a ROUTE definition inside a script or inside
curly brackets {} the parser doesn't recognize it? I was given
"parser.exception error: undefined field ROUTE"
I tried vrmlmerge and Vrml97ToX3dNist. Is there another vrml -> x3d
translator without this problem?
Someone have fixed this problem?
Thanks
Alberto
paluz@tin.it

Joerg Scheurich aka MUFTI

2005-10-06, 6:39 pm

> Did you notice that if you have a ROUTE definition inside a script or inside
> curly brackets {} the parser doesn't recognize it?

Can you give a example for "inside a script" ? I can not imagine, how to
put a ROUTE definition inside a scriptnode legally...

so long
MUFTI
--
Eine benoetigte Ressource ist nicht
OK
Fehlermeldung von Netscape

Palu

2005-10-06, 6:39 pm

Sure:

DEF sc Script {
eventIn SFBool isover
eventOut MFString quantity_changed
field MFString quant IS quantity
url "java script:
function isover (b,ts) {
if (b == false) quantity_changed = '';
else quantity_changed = quant;
}

"
}
]
translation IS transhud
scale 0.188021 0.188021 0.188021
ROUTE ts.isOver TO sc.isover
ROUTE sc.quantity_changed TO q.string
}
}
This is only an example...
This is another one without a script, only with ROUTE inside a node:

DEF hudbuttonsSW Switch {
whichChoice 0
choice DEF hudbuttons Transform {
ROUTE handler.node_changed TO hudbuttons.addChildren
}

Using a VRML plugin like cortona there is no problem, converting it with a
"converter" gives lots of problem!
bye
Alberto

Joerg Scheurich aka MUFTI

2005-10-13, 6:25 pm

> This is another one without a script, only with ROUTE inside a node:

> DEF hudbuttonsSW Switch {
> whichChoice 0
> choice DEF hudbuttons Transform {
> ROUTE handler.node_changed TO hudbuttons.addChildren
> }

You are right:

In this cases, the routestatement is part of a nodeStatement in the same
way as a field.

The VRML97 grammar

http://www.web3d.org/x3d/specificat...t1/grammar.html

reads

statement ::=
nodeStatement |
protoStatement |
routeStatement ;

while the here important part of the nodeStatement is defined as

node ::=
nodeTypeId { nodeBody } |

nodeBody ::=
nodeBodyElement |

nodeBodyElement ::=
fieldId fieldValue |
....
routeStatement |

So a routeStatement may be part of a node like a field.

> Using a VRML plugin like cortona there is no problem, converting it with a
> "converter" gives lots of problem!

It looks like, there is a grammar error in the "converters" you are talking
about. Maybe it is possible to inform the programmers about this error.

so long
MUFTI
--
Es gab einen Fehler an der Stelle 661.
Fehler ist: und bedeutet .
Wir schlagen vor: vorsichtig zu sein.

simon

2005-10-13, 10:21 pm

i was putting routes in the place of parameters a lot, so found this
bug a year of so ago, and i reported it to the person at NIST
responsible for this program.

but i also looked at the source, and its structured as a, rather
bloated, element and parameter parser, so routes in the place of
parameters are a real problem, requiring a pretty big rewrite, if i'm
not mistaken.

the only other converters i've found, all copy this program!!

there was another bug, it couldn't take proto's that didn't have any
parameters. however this was an easy fix which i submitted.

but, are you sure you need to convert, vrml and x3d are sort of
transparent, the only functional difference is that you are restricted
to vrml nodes in a vrml file, but you can use protos written in x3d
from vrml and visa-versa, or just use the x3dv file type.

There's an example on my web site of using the X3D keySensor node from
vrml, by using a x3d prototype.

http://vrml.portland.co.uk/oddities/keySensor.wrl

(only works in an x3d browser, tested in flux.)

2005-10-16, 6:23 pm

> node ::=
> nodeTypeId { nodeBody } |
>
> nodeBody ::=
> nodeBodyElement |
>
> nodeBodyElement ::=
> fieldId fieldValue |
> ...
> routeStatement |
>
> So a routeStatement may be part of a node like a field.
>
>
>
>
> It looks like, there is a grammar error in the "converters" you are talking
> about. Maybe it is possible to inform the programmers about this error.

Hi,
You are right, ROUTEs as well as PROTOs and EXTERNPROTOs can be inside
a node. I already fixed that in vrmlmerge and I'll release this new version soon.
But the problem with conversion to X3D is that while the vrml spec. allows
these statements inside a node, the x3d spec. doesn't. In x3d some nodes
(for example Transform) may have ROUTEs inside, but most other nodes can't.
And most of them (all?) can't have PROTOs inside.
I don't know why this is so inconsistent.
So the current solution used in vrmlmerge is: don't care about the
specification... As I see some browsers have a similar approach (BS Contact)
and they can run such x3d file (despite it's not valid against the DTD)

Regards
md
http://vrml.deem7.com

Joerg Scheurich aka MUFTI

2005-10-20, 6:44 pm

>> So a routeStatement may be part of a node like a field.

> But the problem with conversion to X3D is that while the vrml spec. allows
> these statements inside a node, the x3d spec. doesn't.
....
> So the current solution used in vrmlmerge is: don't care about the
> specification...

> As I see some browsers have a similar approach (BS Contact)
> and they can run such x3d file (despite it's not valid against the DTD)

There is a simple rule about good data processing:

Be gracious when you are reading and be strict when you are writing.

BS Contact is gracious when accepting non X3D code, which is not a real
problem cause AFAIK the X3D document do not forbid accepting non X3D code.

When vrmlmerge write non X3D code, this can cause more problems, cause
possibly some vrmlmerge users do/can not use BS Contact.

What is the problem to pull a ROUTE or PROTO statement out of a node ?

so long
MUFTI
--
Wenn Sie Zugang zur Welt Breite Spinnwebe haben, koennen Sie die
spaetesten Spitzen und Tricks blaettern.
(aus einem Software-Handbuch, Stichwort: World Wide Web)

fabricator

2005-10-23, 6:20 pm

> What is the problem to pull a ROUTE or PROTO statement out of a node ?
>
>so long
> MUFTI

I guess it boils down to context, is the ROUTE inside a PROTO or is it
part of the main world ? As that determines the end location of the
ROUTE.

Joerg Scheurich aka MUFTI

2005-10-24, 6:35 pm

>> What is the problem to pull a ROUTE or PROTO statement out of a node ?

> I guess it boils down to context, is the ROUTE inside a PROTO or is it
> part of the main world ? As that determines the end location of the
> ROUTE.

We where talking about a ROUTE statement inside a node statement, not inside
a PROTO statement. If the node is inside a PROTO statement, i do currently
not see the problem from moving

PROTO []
{
node {
ROUTE
}
}

to

PROTO []
{
node {
}
ROUTE
}

so long
MUFTI
--
Es gab einen Fehler an der Stelle 661.
Fehler ist: und bedeutet .
Wir schlagen vor: vorsichtig zu sein.