[x3d-public] vrml to x3d field name changes
andreasplesch at gmail.com
Thu Apr 26 15:21:31 PDT 2018
Thanks. Ok, let's see:
On Thu, Apr 26, 2018 at 4:07 PM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
> 2018-04-26 16:48 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>> So my question is if there may be other nodes with fields which were
>> affected by renaming from vrml to x3d in such a way ?
> We have a mechanism "AddAlternativeName" for such cases in Castle Game
> Engine (when a field/event name changed, but the type and usage are
> 100% the same).
> Grepping the code, it was used for these fields/events:
> - Collision.collide as an alternative name (in VRML 2) for X3D
> Collision.enabled. In VRML 2.0, Collision node didn't descent from
> X3DSensorName and had special field "collide". In X3D, "enabled" is
> used for the exact same purpose.
That's ok since x3d does not also have a
> - 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
Makes sense to introduce this non-standard vrml field. Maybe this name
should have been the official x3d field name in the first place.
> - HAnimHumanoid.humanoidBody as an alternative name (in HAnim 1.1) for
> HAnim 2 skeleton
x_ite does not implement HAnim sofar. I suppose it would only target
HAnim 2 or later.
> - Switch.choice as an alternative name (in VRML 2) for X3D Switch.children
That's ok since x3d does not also have a Switch.(set_)choice(_changed) field.
> - Polyline2D.point as an alternative name (in VRML 2) for X3D lineSegments
Hm, I could not find Polyline2D in VRML.
A global search for the .addAlias method in x_ite does not yield any
additional such node fields.
So I think it would be ok to just special case aliasing LOD.level to
LOD.children to only occur if the execution context is vrml in x_ite
although Holger may disagree.
Waltham, MA 02453
More information about the x3d-public