[x3d-public] Representation Inspiration [was: Presentation from SVVR2017]

Michalis Kamburelis michalis.kambi at gmail.com
Fri Apr 14 11:53:44 PDT 2017


2017-04-14 17:54 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> I just had an inspiration and would like to run it by people. This may have
> been obvious to everyone else, but it's the first time I have thought of it
> this way.
>
> In X3D a Grouping node (e.g., Transform, Group, etc.) can contain other
> nodes. These usually define scene objects and collect them together in some
> sort of organized system. Looking at a Transform node that does not have any
> Transform children, that node can be thought of as a single entity with all
> of the children nodes and fields contained in that single parent.
>
> For example
>
> <Transform translation='1 2 3' rotation='1 0 0 3.14' scale='3 2 1'>
>     <Shape>
>         <Cone></Cone>
>         <Appearance>
>             <Material diffuseColor='1 .5 .2' specularColor='.8 0
> 0'></Material>
>         </Appearance>
>     </Shape>
> </Transform>
>
> Could be represented (using an arbitrary, non-XML representation) as:
>
> Transform {translation:(1 2 3); rotation:(1 0 0 3.14); scale:(3 2 1);
>             geometry:Cone; diffuseColor:(1 .5 .2); specularColor:(.8 0 0);}
>
> Thereby collapsing five elements (in XML) into one. [I am not advocating
> that this is the right approach.] Do note that this looks a lot like a CSS
> statement - it was not intentional. Note that in this representation it is
> not possible to have more than one Shape node. What is really being defined
> is a mesh (geometry + texture) at a specific translation, scale, and
> rotation. If the desired final geometry is a cube + sphere, it would take
> two statements to make that work (or make the geometry in Blender and output
> a single piece of geometry).
>

In other words, every Shape also has additional fields "translation",
"rotation", "scale"... (It was easier in my head to express it like
this, but I think that this is equivalent to your idea?).

It's a handy shortcut in this case, and probably would be easy to
implement (after all, it's the same as Transform with 1 single child
Shape). But it has a price: we create a complicated node that has
capabilities of both Shape and Transform, instead of splitting this
functionality into 2 separate nodes (as we do now). So both
specification, and the implementation, do become a little more
complicated.

But if it's important for interoperability with other important 3D
format, then I'm OK with it.

Best regards,
Michalis



More information about the x3d-public mailing list