[x3d-public] vrml to x3d field name changes

[Andreas Plesch]

On Thu, Apr 26, 2018, 8:54 PM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> 2018-04-27 0:21 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> >>
> >> - LOD.level as an alternative name (in VRML 2) for X3D LOD.children
> >>
> >> - LOD.levelIndex_changed as an alternative name (in VRML 2) for X3D
> >> LOD.level_changed
> >
> > Makes sense to introduce this non-standard vrml field. Maybe this name
> > should have been the official x3d field name in the first place.
> >
>
> Note that in Castle Game Engine, we do *not* add alternative names
> (from VRML 2) to X3D.
>

Yes, there would be no need for that. I just had hinted that it may have
been a little cleaner to not reuse the field name 'level' for X3D when it
was spec'ed and instead use a new name such as 'levelIndex' for a newly
introduced field. Perhaps something to keep in mind for future X3D
revisions when new fields are considered.


> The "alternative name" (like "LOD.levelIndex_changed" or
> "Collision.collide") is versioned, i.e. it only exists if the file
> header declared exactly VRML == 2.
>
> On the other hard, the "standard" name (like "LOD.level_changed" or
> "Collision.enabled"), which equals the "name in the latest standard
> version", is available in all versions. (VRML and X3D).
>

But LOD.level_changed should mean different types of events in VRML and
X3D, no ? MFNode in VRML and SFInt in X3D ?


> So in X3D you have to use "LOD.level_changed" / "Collision.enabled".
> In VRML 2 you can use "LOD.levelIndex_changed", "LOD.level_changed",
> "Collision.collide", "Collision.enabled". I hope this can ease a
> transition VRML 2.0 -> X3D, so you can "upgrade" your VRML 2 content
> to X3D in small steps.
>
> >> - Polyline2D.point as an alternative name (in VRML 2) for X3D
> lineSegments
> >
> > Hm, I could not find Polyline2D in VRML.
> >
>
> It's not in the original VRML 97 specification, but it was added in
> "VRML 97 Amendment 1 specification", see
> http://www.web3d.org/documents/specifications/14772-1/V2.1/index.html
> .
>

Ah, I see. I suspect Amendment 1 will not become a priority for x_ite .
Nurbs for X3D would be first as there are currently only stubs.


> It's part of the NURBS concept (that, BTW, changed so significantly
> between "VRML 97 Amendment 1 specification" -> X3D that you cannot
> handle it all using a simple aliasing anyway, I mention the
> differences on https://castle-engine.io/x3d_implementation_nurbs.php
> ).
>

Yeah, another reason to not focus on Amendment 1 ? Is there vrml 2.1
content around which authors did not convert to X3D ?

-Andreas

>
> Regards,
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180427/b0a28a2a/attachment.html>