[x3d-public] review of various X3D statement implementations for X3DOM

[Michalis Kamburelis]

2017-12-20 20:16 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
> Hi Michalis,
>
> yes, that is how DEF/USE should be implemented. The point I am trying
> to understand is if there is absolutely no distinction between the
> original DEF node and a USE node which references the DEF node, how
> can the USE node be identified, for example during picking ? The USE
> node still needs to have at least a distinct ID, right ?

When receiving an information containing a node reference (or
something inside the node, like a field), you simply cannot
distinguish between "DEF Xxx" and (any one of) it's "USE Xxx". As far
as I know, there is no way in X3D to make this distinction. Which is
why implementing it by simply using the same object reference multiple
times in the scene graph is easy.

As John wrote, to distinguish the nodes --- you simply have to use a
different node.

Various specification prose exists to account for that. E.g. the
specification of ProximitySensor has special prose to clarify "what
happens if multiple instances of ProximitySensor are present", and it
seems deliberately written to avoid the need to distinguish different
ProximitySensor instances (from the point of view of X3D author).

As far as engine internals are concerned (and here I'm talking about
my implementation, view3dscene and Castle Game Engine, not about the
specification anymore):

- There is no "unique ID" available, even internally. It would be
possible to add it, but it is not necessary -- since X3D specification
is designed to never need such ID.

- When I think about the X3D node graph, in my head, the "node path"
(how to get from the root node to the specific node occurrence) is
unique, but not the node itself. But (at least in my implementation)
we don't need to create an explicit data structure in code to hold
such "node path".

- When processing sensor events, we notify the sensor about it's
activation, along with the transformation matrix under which this
activation occurred.

    E.g. for pointing device sensors we have method "Activate(...
const ATransform, AInvertedTransform: TMatrix4; ...); " ,
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_standard_pointingdevicesensor.inc#L52
. This matrix is in turn taken from State.PointingDeviceSensors (
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_x3dgraphtraversestate.inc
) that was gathered when traversing the X3D graph, which contains
pointing device sensors + transformation matrix (
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_standard_pointingdevicesensor.inc#L19
) gathered. So, if a sensor is used multiple times, then it will be
present in various State.PointingDeviceSensors instances, with
different transformations. IOW, "current sensor transformation" is the
only information necessary to differentiate between multiple sensor
instances internally.

    Other example: for ProximitySensor we have
TProximitySensorInstance that holds a node reference + transformation,
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/castleshapes.pas#L816
. So, the internal reference to TProximitySensorInstance acts exactly
like a "unique ID" you're thinking about.

Regards,
Michalis