[x3d-public] vrml to x3d field name changes
andreasplesch at gmail.com
Thu Apr 26 20:00:27 PDT 2018
On Thu, Apr 26, 2018, 8:54 PM Michalis Kamburelis <michalis.kambi at gmail.com>
> 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
> > 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
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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the x3d-public