[x3d-public] vrml to x3d field name changes

[Michalis Kamburelis]

2018-04-27 5:00 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>> 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 ?
>

Thanks for this comment Andreas, it got me thinking and I looked at
what I'm doing more carefully.

Looking closer at my own implementation (in Castle Game Engine), I see
that I wrote some incorrect things about how we deal with LOD node
differences between VRML 2 and X3D. Sorry about that -- I completely
forgot that 10 years ago I made this commit:
https://github.com/castle-engine/castle-engine/commit/1f00560fa0c490e556dfeb65d94ea155ef35a4f8
.

So, to clarify what I'm doing in Castle Game Engine about LOD:

- We have a class TAbstractLODNode that is basically a LOD node as
defined in X3D. With "children" MFNode field, and "level_changed"
event that outputs SFInt32.

- For X3D files, we use TLODNode that is just a descendant of
TAbstractLODNode that doesn't add there anything important. So,
everything in X3D works, because for X3D files we don't define any
aliases.

- For VRML 2 files, we use TLODNode_2, that is a descendant of
TAbstractLODNode that adds aliases:

    - "children" can be called "level" (along with their events, so
"children_changed" can be called "level_changed")

    - As an extension, the ancestor field "level_changed" can be
called "levelIndex_changed" (which is not in any specification, this
is only CGE extension).

- In effect, the VRML 2 LOD node (TLODNode_2) actually has a name
clash: "level_changed" is there both an event SFInt32, and an event
generating MFNode. It's embarrassing, but I think my approach works
for VRML 2 only by accident: the "level_changed" MFNode output is just
"seen" first by the parser, before the "level_changed" SFInt32 output.

    Since it's just this one, single case, I'll probably leave it be as it is :)

Regards,
Michalis