[x3d-public] Flattening Scene Graph

[Leonard Daly]

Michalis,

Thanks for the confirmation. I am not a complete advocate of scene graph 
flattening, but I did want to have a discussion on it so it's strengths 
and limitations are understood.

Something that has been missing from X3D development in a while is an 
actual determination of which environment and industries/applications is 
X3D targeting. For a long time the answer was all environments and all 
applications except games.
Your work has shown that games should not be excluded. To my knowledge 
the Consortium has not clarified or revised the statement on the target 
platforms/environments or industries/applications of X3D. This has led 
to some people trying to figure out how to define the next generation of 
X3D (common called X3DV4) for every possible platform and environment 
and for all applications. This is the smooth peanut butter approach -- 
spread it smooth (and thin) to make sure everything is covered. That 
doesn't work when you are trying to build market share.

My efforts have been getting X3D to work in the browser environment. I 
am looking at what is necessary to make adoption easier for people 
already working in similar existing (e.g., Unity and Unreal) and 
developing (A-Frame) environments. In all of those environments people 
regularly import models from a large variety of sources, including glTF, 
FBX, and OBJ. The environment provides the glue that holds everything 
together and handles the interaction between the various elements of the 
scene and surrounding environment (in my case, the web page).

Formats like glTF (and its predecessors SRC and PopGeometry from 
Fraunhofer) were designed to ease the importation of large models into 
the GPU by doing the preprocessing once. glTF is planned to be included 
in V4 much like JPEG is used as an image format.


Leonard Daly



> 2017-04-26 16:37 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
>> Michalis,
>>
>> You did hit on the difficultly of expressing geometry or complex texture in
>> a single node. This is certainly the case when you are using a model in X3D
>> (as opposed to glTF or other model format). What if there was a requirement
>> that Mesh only supported simple models and textures and anything complex
>> needed to be referenced by URL (to a non-X3D file). The external file could
>> also include internal animation of the model (e.g., pistons, wheel, walk,
>> run, jump, etc.)
> It would mean that for my (Castle Game Engine) purposes the X3D
> standard would no longer stand on it's own. If I would need to combine
> X3D with some other 3D format, like glTF, to get the features I need,
> then... in practice I would just focus on glTF.
>
> To give a little background: I'm making a game engine, integrated with
> any 3D authoring tool (like Blender) by supporting many asset formats
> (like X3D), running on any platform (desktop, mobile, web), and also
> using X3D as a complete scene graph.
>
> Right now, I *can* combine X3D with other formats (e.g. using Inline),
> but it's my choice if (and how) I do it. For example, my Collada, MD3,
> Spine, OBJ, STL... importers right now just convert everything to X3D
> nodes. Right now, I can do it, because X3D is a powerful scene graph
> describing everything I need. This would change. The format you
> propose would no longer be a useful (complete) scene graph for me, it
> would only be a start.
>
> Also the exporters would need to adapt. Blender's exporter to the
> format you propose would likely need to use glTF exporter internally
> too.
>
> Since glTF can express animations, shaders, texture coordinates... in
> many cases, I would actually not need X3D. The primary focus of the
> engine would be the glTF format. X3D would still add interactivity to
> glTF models, and allow to group and reuse them... but I don't really
> need X3D for this. E.g. for scripting, we have a nice object-oriented
> API in our modern Object Pascal to do all kinds of interactive things
> with assets. This can be invoked from X3D Script, but it can also work
> from the outside of the X3D Script, loading and unloading and
> organizing whatever assets it needs.
>
> In other words, it would (from my usecase) make the (new) X3D much
> less useful. The glTF becomes the powerful format then, and X3D is
> then only an optional wrapper around glTF.
>
> Let me be very clear: Your design is elegant, and I can see where
> you're going. Your design is coherent. I asked "How do you deal with
> complicated geometry?", and your answer "You delegate it to an
> external file" is an absolutely reasonable answer. But for me, it is
> also something different than X3D, it does not fill my need (unlike
> the current X3D). The new format would be something to manipulate the
> 3D assets expressed in other files. I need a format to actually define
> these assets.
>
>> You also brought up accessing various subparts of mesh that are current
>> existing nodes (e.g., reusing Appearance, Geometry, Coordinate, etc.). The
>> current standard when modeling (*) is to create a complete model for each
>> non-repeated instance. The parts that may be reused (texture, animation)
>> could be represented as the equivalent of CSS classes and reused between
>> instances of Mesh. For example
>>
>> .texture-color {diffuse:orange; specular:blue; }
>> .texture-ball {appearance: hard-surface.shader; }
>> .texture-plush {appearance: fuzzy-surface.shader; }
> Aha, sharing like CSS. I can see that it's elegant, if the emphasis is
> on having similar concepts as HTML.
>
> Best regards,
> Michalis
>

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170427/0f690621/attachment.html>