<div dir="ltr"><div dir="auto">Yes, I was thinking about node reference + trafo before:<br><br><a href="https://github.com/x3dom/x3dom/issues/220#issuecomment-333314778" target="_blank">https://github.com/x3dom/<wbr>x3dom/issues/220#issuecomment-<wbr>333314778</a><br><br>x3dom has 'drawables' which is a list of trafo+shape combos.</div><div dir="auto"><br></div><div>Well, thanks for pointers and the discussion,</div><div><br></div><div>Andreas</div><div><br></div><div dir="auto">On Wed, Dec 20, 2017 at 3:32 PM, Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>> 2017-12-20 20:16 GMT+01:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>:<br>>> Hi Michalis,<br>>><br>>> yes, that is how DEF/USE should be implemented. The point I am trying<br>>> to understand is if there is absolutely no distinction between the<br>>> original DEF node and a USE node which references the DEF node, how<br>>> can the USE node be identified, for example during picking ? The USE<br>>> node still needs to have at least a distinct ID, right ?<br>><br>> When receiving an information containing a node reference (or<br>> something inside the node, like a field), you simply cannot<br>> distinguish between "DEF Xxx" and (any one of) it's "USE Xxx". As far<br>> as I know, there is no way in X3D to make this distinction. Which is<br>> why implementing it by simply using the same object reference multiple<br>> times in the scene graph is easy.<br>><br>> As John wrote, to distinguish the nodes --- you simply have to use a<br>> different node.<br>><br>> Various specification prose exists to account for that. E.g. the<br>> specification of ProximitySensor has special prose to clarify "what<br>> happens if multiple instances of ProximitySensor are present", and it<br>> seems deliberately written to avoid the need to distinguish different<br>> ProximitySensor instances (from the point of view of X3D author).<br>><br>> As far as engine internals are concerned (and here I'm talking about<br>> my implementation, view3dscene and Castle Game Engine, not about the<br>> specification anymore):<br>><br>> - There is no "unique ID" available, even internally. It would be<br>> possible to add it, but it is not necessary -- since X3D specification<br>> is designed to never need such ID.<br>><br>> - When I think about the X3D node graph, in my head, the "node path"<br>> (how to get from the root node to the specific node occurrence) is<br>> unique, but not the node itself. But (at least in my implementation)<br>> we don't need to create an explicit data structure in code to hold<br>> such "node path".<br>><br>> - When processing sensor events, we notify the sensor about it's<br>> activation, along with the transformation matrix under which this<br>> activation occurred.<br>><br>>     E.g. for pointing device sensors we have method "Activate(...<br>> const ATransform, AInvertedTransform: TMatrix4; ...); " ,<br>> <a href="https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_standard_pointingdevicesensor.inc#L52" target="_blank">https://github.com/castle-<wbr>engine/castle-engine/blob/<wbr>master/src/x3d/x3dnodes_<wbr>standard_pointingdevicesensor.<wbr>inc#L52</a><br>> . This matrix is in turn taken from State.PointingDeviceSensors (<br>> <a href="https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_x3dgraphtraversestate.inc" target="_blank">https://github.com/castle-<wbr>engine/castle-engine/blob/<wbr>master/src/x3d/x3dnodes_<wbr>x3dgraphtraversestate.inc</a><br>> ) that was gathered when traversing the X3D graph, which contains<br>> pointing device sensors + transformation matrix (<br>> <a href="https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dnodes_standard_pointingdevicesensor.inc#L19" target="_blank">https://github.com/castle-<wbr>engine/castle-engine/blob/<wbr>master/src/x3d/x3dnodes_<wbr>standard_pointingdevicesensor.<wbr>inc#L19</a><br>> ) gathered. So, if a sensor is used multiple times, then it will be<br>> present in various State.PointingDeviceSensors instances, with<br>> different transformations. IOW, "current sensor transformation" is the<br>> only information necessary to differentiate between multiple sensor<br>> instances internally.<br>><br>>     Other example: for ProximitySensor we have<br>> TProximitySensorInstance that holds a node reference + transformation,<br>> <a href="https://github.com/castle-engine/castle-engine/blob/master/src/x3d/castleshapes.pas#L816" target="_blank">https://github.com/castle-<wbr>engine/castle-engine/blob/<wbr>master/src/x3d/castleshapes.<wbr>pas#L816</a><br>> . So, the internal reference to TProximitySensorInstance acts exactly<br>> like a "unique ID" you're thinking about.<br>><br>> Regards,<br>> Michalis<br><br><br><br>-- <br>Andreas Plesch<br>Waltham, MA 02453</div>
</div>