VRML - I was not impressed with X3D yet...

Author

I was not impressed with X3D yet...

Andrea

2004-03-30, 10:27 pm

Show me the compelling X3D content, since the consortium is marketing
X3D as the new vrml but is not. If I want something besides VRML I
could always use Anark, or Shockwave3D, Adobe Atmosphere or Viewpoint.
Why should I use X3D?

If a group of vendors are spending loads of money on a "VRML is dead"
campaign, the very least they could do is show me why I should switch.
Shadows and reflections on a model rotating in space is not enough.
From what I've seen, there are not enough reasons for me to dump VRML
for X3D.

If it is based on VRML,and VRML is so compatable with Java,ect..., and
people have faster computers, better graphics cards, and broadband and
high speed internet access, then wouldn't it make sense that VRML is
new and improved because of these upgrades,it makes no sense to kill
VRML. VRML is more useful now than ever.
Andrea

Joerg Scheurich aka MUFTI

2004-03-30, 10:27 pm

> Show me the compelling X3D content, since the consortium is marketing
> X3D as the new vrml but is not.

True: X3D is not the new vrml. It is the better vrml.

I do not know much about how the ISO sees it, but there is nothing (beside
loud marketing guys) that would prevent them to public the X3D draft as
"VRML2004 or VRML2005"

AFAIK the current X3D draft still support the old VRML style encoding, this
means, you can simply say "this VRML97 file is now a X3D file" and then you
have thousands of existing X3D files you can scan for "compelling X3D content".

As a example for the better vrml: the current X3D draft includes a node for
environment mapping. This is a feature, you simply can not build in VRML97.

I wish, the new X3D draft would had included more such features, e.g.
realtime shadows, sensors for devices with more degrees of freedom then 2,
modern parametric shapes like superellisoid or supershape (http://www.csv.ica.uni-stuttgart.de.../supershape.wrl).

A lot of new X3D features are build based on the work of working groups,
and this working groups (e.g. for H-ANIM) were limited to the possibilities
of VRML97.

> If I want something besides VRML I
> could always use Anark, or Shockwave3D, Adobe Atmosphere or Viewpoint.
> Why should I use X3D?

Cause X3D has the simplest converter from VRML97 8-)

> From what I've seen, there are not enough reasons for me to dump VRML
> for X3D.

You simply can not dump VRML for X3D.
Otherwise your X3D files would be very, very empty 8-)

> If it is based on VRML,and VRML is so compatable with Java,ect...

As far as i understood the current X3D draft, X3D come with a new
scripting mechanism, that unite the Script node and EAI.
Beside this, X3D browsers may support old style scripting.

so long
MUFTI
--
Muschelfluchtabfolge
(Stichwort: Shell escape)

Braden McDaniel

2004-03-30, 10:27 pm

Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<c3s3cv$6eh$1@news.uni-stuttgart.de>...
>
> True: X3D is not the new vrml. It is the better vrml.

Well ... It is different.

> I do not know much about how the ISO sees it, but there is nothing (beside
> loud marketing guys) that would prevent them to public the X3D draft as
> "VRML2004 or VRML2005"
>
> AFAIK the current X3D draft still support the old VRML style encoding, this
> means, you can simply say "this VRML97 file is now a X3D file" and then you
> have thousands of existing X3D files you can scan for "compelling X3D content".

Unfortunately, a few syntax changes/additions mean that X3D's
"VRML-style encoding" will *not* parse with a VRML97 parser.

> As a example for the better vrml: the current X3D draft includes a node for
> environment mapping. This is a feature, you simply can not build in VRML97.

That's not true. While you can't do that with scripting, there's
nothing constraining a VRML97 implementation from adding such a node
as an extension (via EXTERNPROTO).

> I wish, the new X3D draft would had included more such features, e.g.
> realtime shadows, sensors for devices with more degrees of freedom then 2,
> modern parametric shapes like superellisoid or supershape (http://www.csv.ica.uni-stuttgart.de.../supershape.wrl).
>
> A lot of new X3D features are build based on the work of working groups,
> and this working groups (e.g. for H-ANIM) were limited to the possibilities
> of VRML97.
>
>
> Cause X3D has the simplest converter from VRML97 8-)
>
>
> You simply can not dump VRML for X3D.
> Otherwise your X3D files would be very, very empty 8-)
>
>
> As far as i understood the current X3D draft, X3D come with a new
> scripting mechanism, that unite the Script node and EAI.
> Beside this, X3D browsers may support old style scripting.

Merging the EAI and the Script node API is a good idea on its face.
Unfortunately X3D's SAI also adds a bunch of baggage that's completely
inconsistent with VRML97's notion of node types as things defined at
runtime. It also abandons the opacity of node implementations by
requiring that it be made visible whether a node is implemented as a
PROTO.

For this reason it seems unlikely that OpenVRML will ever support
X3D's SAI.

Aside from the SAI, X3D really is nothing more than VRML97 cast in
XML. Which means that automatically translating from X3D back to
VRML97 is trivial where the SAI is not used. So it is easy to run such
X3D content in OpenVRML or any other VRML97 browser.

I suggest that it is a good idea for Web servers that serve X3D to
check the Accept header of requests and dynamically translate X3D to
VRML97 for clients that only support the latter.

Braden

Joerg Scheurich aka MUFTI

2004-03-30, 10:27 pm

>> AFAIK the current X3D draft still support the old VRML style encoding, this
[color=darkred]
> Unfortunately, a few syntax changes/additions mean that X3D's
> "VRML-style encoding" will *not* parse with a VRML97 parser.

I was talking about the other way: parsing a VRML97 file with a X3D parser
that support VRML style encoding.

When i take a look at the grammar of the current publiced X3D draft

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

i see no big stumblestones (ok, the header is now "#X3D 3.0 utf8"
instead of "#VRML V2.0 utf8", but this is not really a big problem to change).

Sure, there are new datatypes like "SFColorRGBA" or "SFDouble" but they can
not occure in a VRML97 file.
There are new keywords like "PROFILE", "META" or "COMPONENT" in the X3D draft,
but they are optional.
There is a valid "VRML97" way

scene ::= ...
...
statements ;
....
....
statements ::=
statement |
statement statements |
empty ;
statement ::=
nodeStatement |
protoStatement |
routeStatement ;

through the grammar.

[color=darkred]
> That's not true. While you can't do that with scripting, there's
> nothing constraining a VRML97 implementation from adding such a node
> as an extension (via EXTERNPROTO).

True. But rather useless if you need to build a working solution for all
browsers.
Cause there are so much VRML97 browsers outside, there is not even one
"browser buisness" nonscriptable extension common to all VRML97 browsers.

so long
MUFTI
--
Das Warnen: jener Windows kann eine begrenzte Zahl von Taufbecken
ueberhaeufen, und ihr Computer wird sich drastisch verlangsamen,
wenn Sie die maximale Zahl Taufbecken anschliessen.
(aus einem Softwarehandbuch, Stichwort: font)

Braden McDaniel

2004-03-30, 10:27 pm

Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<c3uh73$pvf$2@news.uni-stuttgart.de>...
>
>
> I was talking about the other way: parsing a VRML97 file with a X3D parser
> that support VRML style encoding.
>
> When i take a look at the grammar of the current publiced X3D draft
>
> http://www.web3d.org/x3d/specificat...02/grammar.html
>
> i see no big stumblestones (ok, the header is now "#X3D 3.0 utf8"
> instead of "#VRML V2.0 utf8", but this is not really a big problem to change).
>
> Sure, there are new datatypes like "SFColorRGBA" or "SFDouble" but they can
> not occure in a VRML97 file.
> There are new keywords like "PROFILE", "META" or "COMPONENT" in the X3D draft,
> but they are optional.
> There is a valid "VRML97" way
>
> scene ::= ...
> ...
> statements ;
> ...
> ...
> statements ::=
> statement |
> statement statements |
> empty ;
> statement ::=
> nodeStatement |
> protoStatement |
> routeStatement ;
>
> through the grammar.

Not quite:

x3dScene ::=
headerStatement
profileStatement
componentStatements
metaStatements
statements ;
headerStatement ::=
#X3D 3.0 utf8 string ;
profileStatement ::=
PROFILE profileNameId ;

So an X3D file requires a profileStatement, which will be absent in a
VRML97 file.

It indeed appears easy to modify such an X3D parser to accommodate
VRML97; but it's not something you'll get for free.

>
>
> True. But rather useless if you need to build a working solution for all
> browsers.

It's an unfortunate fact that very few non-trivial VRML applications
have worked equivalently on more than one browser. VRML97 is damned
complicated and conformance has not been a top priority for some
VRML97 implementers.

> Cause there are so much VRML97 browsers outside, there is not even one
> "browser buisness" nonscriptable extension common to all VRML97 browsers.

But VRML97 does allow conforming VRML97 files to use browser-specific
extensions. In theory, vendors could converge on particular extension.
Unfortunately, since there was never much of a market for VRML
browsers, there was no market to compel such convergence.

That lack of a market also means there's not much of a business case
to write code for more than one browser. The market, where it exists
at all, is small enough that developers can afford to tell their users
what browser and platform to use. Cross-browser VRML is something that
only standards fetishists like us appreciate. ;-)

Will things be different with X3D? Possibly, but I doubt it. I don't
see much of a market to compel conformance across X3D browsers.

Braden

Joerg Scheurich aka MUFTI

2004-03-31, 1:40 pm

> Not quite:

> x3dScene ::=
> headerStatement
> profileStatement
> componentStatements
> metaStatements
> statements ;
> headerStatement ::=
> #X3D 3.0 utf8 string ;
> profileStatement ::=
> PROFILE profileNameId ;

> So an X3D file requires a profileStatement, which will be absent in a
> VRML97 file.

Well, from a authors view can be seen simply as a bigger header instead of

#VRML V2.0 utf8

The interesting question is, if monster full of componentStatements is needed
for "real life" VRML97 compatibility.

It looks like, you can simply write

#X3D 3.0 utf8
PROFILE Full

instead of

#VRML V2.0 utf8

but then, it may be difficult to find a browser that is capable to run
the file 8-)

(it looks like componentStatements and metaStatements are optional)

so long
MUFTI
--
Das Video und Lebhaftigkeit-Bibleotheken jedes enthaelt AVI (Film)Akten,
ohne irgendeinen subcategory-Zusammenbruch
(aus einem Softwarehandbuch, Stichwort: animation)