[x3d-public] review of various X3D statement implementations forX3DOM

John Carlson yottzumm at gmail.com
Wed Dec 20 11:21:39 PST 2017


Andreas, I think if you want to distinguish USE nodes with picking, you would use a separate node.

John

Sent from Mail for Windows 10

From: Andreas Plesch
Sent: Wednesday, December 20, 2017 2:18 PM
To: Michalis Kamburelis
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] review of various X3D statement implementations forX3DOM

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 ?

A conceptual scene graph structure may look like this:

group1
  node 1: DEF "original"
group2
  node 2: USE "original"

There are still two nodes. node 2 is not a copy of node 1 but is still
a separate node which happens to reference node 1.

Or

group1
 node 1: DEF "orginal"
group2
 node 1 (inserted a second time during scene graph construction)

Closer to spec. but makes it hard (impossible?) to distinguish the two
node 1 instances from each other.

So I was thinking something like an additional ID may have to exist:

1. group1
2.  node 1: DEF "orginal"
3. group2
4.  node 1 (inserted during scene graph construction)

?

-Andreas




On Wed, Dec 20, 2017 at 11:03 AM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
> 2017-12-20 15:51 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
>> (DEF/USE in x3dom: There are a several x3dom issues about picking a
>> USE Shape. Since x3dom literally places the referenced DEF Shape in
>> the scene graph, the picking actually reports the node of the
>> referenced DEF Shape when the USE Shape is picked. This is because
>> x3dom actually does not keep a distinct representation of the USE node
>> at all. Except for the fact that the DEF node now has two parents.
>> This may be too literal an interpretation of the DEF/USE concept, and
>> I wonder if in the spec. there is a section which explains how the
>> node which has a USE reference is still a distinct node. I suspect
>> that keeping such a distinct node around is how most x3d browsers work
>> ?
>
> This DEF / USE (in x3dom) treatment is required by the X3D
> specification, and it (should) be the same in all VRML / X3D browsers.
> I know it is the same in view3dscene and Castle Game Engine. When we
> encounter a "USE Xxx" then internally we *do not* make a copy of the
> "Xxx" node, instead we make an additional link to the "Xxx" node that
> in effect has 2 parents. This implementation is most natural and
> practically required by the X3D specification:
>
> http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/concepts.html#DEFL_USESemantics
>
> """
> The USE statement does not create a copy of the node. Instead, the
> same node is inserted into the scene graph a second time, resulting in
> the node having multiple parents (see 4.3.5 Transformation hierarchy,
> for restrictions on self-referential nodes).
> """
>
> And that's a very good concept, in my opinion: it allows to use DEF /
> USE mechanism for various optimizations. Since you have only one copy
> of the node, you should also be able to have only one copy of various
> internal things (like OpenGL VBO data) associated e.g. with Shape that
> is USEd multiple times. This is really powerful, you can construct a
> large scene by USEing the same shapes multiple times, and it will
> still render fast and not eat too much memory:)
>
> In contrast, expanding the PROTOtypes makes a copy on the contents.
>
> Regards,
> Michalis



-- 
Andreas Plesch
Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171220/c32bfcdc/attachment-0001.html>


More information about the x3d-public mailing list