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

[Andreas Plesch]

Yes, I was thinking about node reference + trafo before:

https://github.com/x3dom/x3dom/issues/220#issuecomment-333314778

x3dom has 'drawables' which is a list of trafo+shape combos.

Well, thanks for pointers and the discussion,

Andreas

On Wed, Dec 20, 2017 at 3:32 PM, Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:
> 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



-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171220/e656b749/attachment.html>