[x3d-public] Flattening Scene Graph

[Michalis Kamburelis]

2017-04-26 6:50 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> I would like to know what people think of the concept of flattening out
> portions of the scene graph. Specifically the Shape node and its contents.
> The current structure for an object is something like:
>
> <Transform translation='1 2 3' orientation='.707 .707 0 1' scale='.6 1.2
> 1.8'>
>     <Shape>
>         <Box size='3 2 1'/>
>         <Appearance>
>             <Material diffuseColor='1 .5 0'/>
>             <ImageTexture url='wrap.jpg'/>
>         </Appearance>
>     </Shape>
> </Transform>
>
>
> Of course there any many different ways to have a Shape node, but using this
> as an example...
>
> Create a new node called Mesh and put all of the children attributes and
> parent Transform (if one exists) attributes into the node  as such
>
> <Mesh
>     translation='1 2 3'
>     orientation='.707 .707 0 1'
>     scale='.6 1.2 1.8'
>     geometry='Box:size (3 2 1)'
>     diffuseColor='orange'
>     texture='url (wrap.jpg)' />
>
> This may not be the best choices for various attributes and something more
> complex would need to be done for the non-primitive geometries (e.g.,
> IndexedFaceSet, ElevationGrid).
>

It looks nice in a simple case, but the inevitable question is how you
would express the complicated cases. There are some really complex
things inside Shape and Appearance that would require inventing some
new syntax to "squeeze" them into a single attribute (if you would go
that route).

- You mention one example, non-primitive geometries. Besides simple
lists (of vertexes, indexes) they also have texture coordinates (that
may be 2D, 3D, 4D, may be generated or explicit, may be
MultiTextureCoordinate), shader attributes (that are a list of
xxxAttribute nodes). Even the vertex coordinates have options (single
or double precision, normal or Geospatial system).

- There are also complicated texture setups, using MultiTexture or
ComposedTexture3D or ComposedCubeMapTexture . Each of them consists of
a number of other texture nodes. These other texture nodes may contain
TextureProperties inside.

- The Appearance.shaders is complicated too, it may contain 5 from the
nodes inside "Programmable Shaders" component (
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shaders.html
) in various nesting configurations. Some of these nodes also allow
user-defined fields ("interface declarations", just like the Script
node).

And most of these are not features that we want to miss in X3D, I
think. E.g. I will definitely defend cube maps, 3D textures and
generated texture coordinates. They are common things in modern
graphic APIs (and implementations using shaders), they allow some
really cool things (like easy real-time mirrors,
https://castle-engine.sourceforge.io/x3d_implementation_cubemaptexturing.php#section_example
, or volumetric fog).

- Also, you would need to invent a new syntax for DEF / USE, to enable
sharing subparts of the Mesh. E.g. sometimes we want to share the
geometry, but use different appearance. Sometimes we want to share the
appearance, but not geometry.

It seems to me a really complicated task... The resulting Mesh
specification would be surely the largest node ever described in the
X3D specification:)

Unless you would introduce Mesh only a shortcut for "common usage" of
other nodes. This is an easy way, as you don't close any possibility
then.

Another alternative that I see is something that sums <Transform> +
<Shape> + <Appearance> but leaves the rest (like geometry, and all
appearance children) as children XML elements. This will still raise
the question of "how to share only a subset of Mesh", but otherwise is
good. Like this:

<Mesh translation='1 2 3' orientation='.707 .707 0 1' scale='.6 1.2 1.8'>
  <Box size="3 2 1" />
  <Material diffuseColor='orange' />
  <ImageTexture url='"wrap.jpg"' />
</Mesh>

It is a less drastic change than yours. Indeed, it does not look as
nice as yours, it's not as concise. But it retains all the power of
the existing nodes' combinations.

Regards,
Michalis