[x3d-public] motivations and potential renaming of OM4X3D as X3D Unified Object Model (X3DUOM)

[Michalis Kamburelis]

2017-08-20 1:14 GMT+02:00 Don Brutzman <brutzman at nps.edu>:
> Similar design patterns for autocreation of node signatures are also
> interesting to observe. Going even further, conceivably a simple stylesheet
> might parse the XML object model X3DObjectModel-3.3.xml
>         http://www.web3d.org/specifications/X3DObjectModel-3.3.xml

I have on my TODO list to read these XML files with the nodes
specifications. Not read them with a stylesheet, but read them with a
Pascal code (the engine is dealing with XML formats a lot anyway,
already :).

I once started it, but eventually decided that reading simple text
files like https://github.com/castle-engine/castle-engine/tree/master/src/x3d/nodes_specification/components
is easier, and it was trivial to create such files by copy-pasting
from the X3D specification.

But, eventually, in the future I would prefer to just read the XML
file you linked. The text files in
https://github.com/castle-engine/castle-engine/tree/master/src/x3d/nodes_specification/components
can be just removed them, no need for an intermediate text format --
once I implement reading X3DObjectModel-3.3.xml, I can just use it
directly to generate the Pascal code I need :)

> Looks like you have gone in the other direction too, for strong typing of
> simple non-node typed values.  For example, an excerpt
>
> ===============================================================================
>
> https://castle-engine.sourceforge.io/manual_scene.php#section_transform
>
>         Material := TMaterialNode.Create;
>         { Yellow (we could have also used YellowRGB constant from
> CastleColors unit) }
>         Material.DiffuseColor := Vector3Single(1, 1, 0);
>         Material.Transparency := 0.75;
>
>         Appearance := TAppearanceNode.Create;
>         Appearance.Material := Material;
>
>         Box1 := TBoxNode.Create('box_1_geometry');
>         Box1.Size := Vector3Single(0.5, WallHeight, RoadBox.Sizes[2]);
> ===============================================================================
>
> shows typed arrays.  The SAI language bindings go even further beyond direct
> assignment of fields by providing typed get/set accessor methods.

It is already a full-featured SAI :)

The assignments you see here, like "Material.DiffuseColor := xxx", are
not simple assignments to the field values. They call getter/setter
methods underneath.

- If the field is exposed ("inputOutput" in X3D terms) and the event
processing is already initialized, then doing "Material.DiffuseColor
:= xxx" actually sends a new color to the input event of the exposed
"Material.diffuseColor" X3D field.

- Otherwise, the field is set, and the scene is at least notified
about this change (to cause a refresh of the screen, and stuff like
RenderedTexture or GeneratedCubeMapTexture).

So, it looks like a trivial assignment in Pascal, but it actually uses
a 100% proper way to send the new value in the X3D scene graph :)
Underneath it is a powerful mechanism, updating everything as
necessary, propagating the change as necessary too (e.g. if you would
ROUTE your Material.diffuseColor_changed to something else, it will be
correctly propagated by this assignment).

It is done using Object Pascal "properties", see
http://castle-engine.io/modern_pascal_introduction.html#_properties .
The C# language has a very similar feature.

We also have a lower-level API to operate on node's fields, by
accessing every field using the Fd prefix. E.g.

Material.DiffuseColor := xxx

is actually a shortcut for

Material.FdDiffuseColor.Send(xxx)

which is a shortcut for

Material.FdDiffuseColor.EventIn.Send(xxx)

or

Material.FdDiffuseColor.Value := xxx;
Material.FdDiffuseColor.Changed;

(depending on whether the field is exposed and event processing is initialized).

You can do many fancy things by accessing properties of the
Material.FdDiffuseColor :) E.g. you have there a full information
about field's name, the default and the current value.

>
> Of course your API is closely aligned with your rendering by your game
> engine. So it isn't clear if separating out a pure SAI-based library for use
> by other ObjectPascal programs really makes sense.  But it is a possibility,
> if even-more-general ObjectPascal usage became desirable.

Actually, I deliberately keep the "rendering" part of my engine
separate. The engine's X3D nodes classes, and a powerful
TCastleSceneCore, are "clean" -- no dependencies on the rendering
stuff (like OpenGL, OpenGL ES), you can use them to write X3D
transformation / conversion tools nicely :) Like the "tovrmlx3d"
command-line program distributed with view3dscene, to convert between
classic/xml encoding, or convert VRML 2.0 to X3D.

>
> Am also happy to see that you have Distributed Interactive Simulation (DIS)
> bindings specified.  We will probably revisit/re-open the Open-DIS work this
> fall, it would be great to test interoperability if you like.

I only parse the DIS nodes for now, nothing more. In general, we can
parse 100% of the X3D 3.3 specification -- it does not mean that we
actually implement 100% of the nodes (making them visible, or behave
as necessary). Even if we implement a lot :)

Regards,
Michalis