[x3d-public] vrml to x3d field name changes
michalis.kambi at gmail.com
Fri Apr 27 17:34:12 PDT 2018
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:
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
- 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 :)
More information about the x3d-public