[x3d-public] X3D V4 Thoughts

[Joe D Williams]

So now we are asking the big three questions:

1. Multiple inheritance of abstract and concrete nodes?

The X3D object hierarchy showing derivation and inheritance of 
abstract and concrete nodes is currently being refined with the idea 
of making the inheritance consistent and to offer more guidance to 
implementors. This examination is mainly taking place using a weekly 
phone conference

 2. Why do we need wrapper ags or containerField

Well, I think the schema has enough info to allow an authortime or 
runtime system to figure out if a field (a node) is legal in the 
context it is placed. If that were true, then we would not need 
wrapper tags or containerField. However, it apparently is not done 
that way and we have to allow for predefining the correct containing 
node in a prototype, and I guess there must be some runtime issues so 
we need to have the user code predefine its role in the structure.

3. Why big data in elements rather than attributes

Well, if large data is real problem, then it is relatively easy to 
redo the schema to put whatever attribute data into an element. I 
think I remember that a reason was that in the old days there was no 
data validation available for element content, only attribute content.

more below ...

----- Original Message ----- 
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Wednesday, December 23, 2015 8:16 AM
Subject: [x3d-public] X3D V4 Thoughts


>I have been doing a lot of thinking about V4 and wish to document 
>these
> ideas and open them up for discussion. These are not presented in 
> any
> particular order.
>
>
> 1) All nodes that have (potentially) large attribute values
> (IndexedFaceSet's coordIndex)
> should (optionally) allow those fields to be expressed a children of 
> the
> node. For example
>
>    <IndexedFaceSet ... coordIndex='...'>
>         <Coordinate>...</Coordinate>
>    </IndexedFaceSet>
>

corrected:

<IndexedFaceSet ... coordIndex='...' texCoordIndex='...'>
       <Coordinate point='...' />
</IndexedFaceSet>


>
>
> would become
>
>    <IndexedFaceSet ... >
>         <CoordIndex>...</CoordIndex>
>         <Coordinate>...</Coordinate>
>    </IndexedFaceSet>

Not quite there, but I won't try to guess.
And, with no wrapper tags either.
Would be nice to keep the point keyword.
Should size matter?
Please also consider some other examples.

>
>
>
> This allows the transfer of large data in a node rather than an
> attribute.

True, but whether large or small should not matter how it is contained 
for transport.

> It does make it easier to deal with large quantities (> 65K 
> characters).

Please quantify easier. Same number of characters, I think, except for 
a few <>

> There are a number of nodes, including geometry,
> interpolator, Metadata, and PixelTexture that would all benefit.

Please show some more examples. How would the interpolator be written?

>
>
>
> 2) TimeSensor should take any number of any kind of interpolators as
> children.

Take my word for it, you probably do not want all interpolators run 
from the same TimeSensor.
I think you really want to group the TimeSensors and Group the related 
Interpolators.
And, what do you lose by this automation?
The human readable and easiy synthesized event graph.
Trying to automagically group functions by location in a structure 
(lake a TimeSensor with children) may save a few keystrokes for the 
TimeSensoror gozouta to Interpolator gozinta is moslty lost in extra 
indentions.

Now there is only one rule that is important, that the def must appear 
beore the route.


> Each interpolator would automatically have the TimeSensor's
> /fraction_changed/ field automatically ROUTEd to the interpolator's
> /set_fraction/ input event field.


"automatically" is fine, but, to me, much better when clearly explicit 
and easily readable in the user code.
Sure you can alway invent a way to use various assets 'automagically' 
but what happens after?
The neat thing about the way we do it ow is that there is nothing 
automatic, each Route completly describes what is needed.

This is like the tose where I share my coords and indices and all in 
some common area then somehow apply them to some other means to 
actually apply them. Sames some strokes but have a more complex 
interface.

>
>
> 3) Standard Practice: Put ROUTE statements as children of the
> interpolator node that provides the source data. Combining (2) and 
> (3)
> gives:
>
>    <TimeSensor ...>
>         <PositionInterpolator DEF='Mover' ...>
>             <ROUTE toNode='MoverTarget' toField='translation' />
>         </PositionInterpolator>
>    </TimeSensor>

Please use set_translation.
What ar you losing when you try to convert from existing forms? Looks 
compicated, if possible without handwork.

Me no like this style. Much better to have groups of TimeSensors, 
Intrpolators, and ROUTEs.
Please look at some examples of complex animations, like

http://www.hypermultimedia.com/x3d/hanim/JoeSkin4EXSPYRWRJK.x3dv


>
>
>
> This would replace:
>
>    <TimeSensor DEF='Timer' ...></TimeSensor>
>    <PositionInterpolator DEF='Mover' ...></PositionInterpolator>
>    <ROUTE fromNode='Timer' fromField='fraction_changed' 
> toNode='Mover'
>    toField='set_fraction' />
>    <ROUTE fromNode='Mover' fromField='value_changed'
>    toNode='MoverTarget' toField='translation' />
>

No, it would most likely replace One timesensor with 20 interpolaters 
and 49 routes. .
Since all interpolators may notbe run frm the smae timesensor,


>
>
> To preserve the past, this would be an optional construct.

Please compose example of schema.


> This collects
> the information involved in keyframe animation in one node 
> (TimeSensor).

No, to me it locks information into an arbitrary semi-automated 
structure with much added work for author and player.
This looks simple for simple stuff, then dies when it gets real.  How 
about when you add an interpolator and ROUTE at runtime? (hint, much 
more complcated for the player.)


>From previous mail:

>> For those few cases when a 'containerField' is required, is it
> > reasonable to define wrapper tags.

Yes, if found, that has been done.

>  while making the structure of the X3D field easier to understand.

First, for this topic there is one major question that has at least 
two answers:
What is the actual function of the wrapper tag or the containerField?

>
>
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> X3D Co-Chair on Sabbatical
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>

Thanks and Best,
Joe



--------------------------------------------------------------------------------


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