<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Philipp,<br>
<br>
Thanks for the response. This is going to take a little while to
absorb. I did read (1). It appears that we agree, though you have
thought a lot more about this issue than I have. I hope to get to
this later today.<br>
<br>
<br>
Leonard Daly<br>
<br>
</div>
<blockquote cite="mid:567AE15D.4070502@dfki.de" type="cite">
<pre wrap="">Hi Leonard, all,
Since I have a bit of time right now, let me briefly comment on your
suggestions from our experience in XML3D (please continue reading
regardless :-).
(1) This basic approach has been a basic design decision in XML3D and
has enabled a lot of follow-on capabilities (see below). But we have
gone much further still: Using our Xflow design [1] one can define sets
(<data> elements) that can contain an arbitrary number of generic arrays
that are simply named and typed arrays of values.
These data sets can be composed with each other according to simple but
very flexible rules [2]. As a result data can be reused very flexibly
either through nesting (as you suggest) but also using references from
other elements (e.g. data, mesh, view, etc.). Additionally, data can be
overwritten and functions can be applied to arrays via JS and other
parallel processing mechanisms (e.g. glsl, ASM.js, SIMD.js, ...).
All this data has no semantic meaning at first (similar to OpenGL
buffers but contrary to X3D). It only gets semantic meaning by being
connected to a <mesh> (or other) element. In this case all data is made
available to the rendering and shading subsystem (e.g. shade.js), which
can thus directly make use of any such data values.
(2): I find it more useful to reference a source from the target (and
not the other way around as you suggest). This way you do not have to
maintain one location with links to all objects that need this data but
simply add it to where its needed anyway. That is how we have
implemented it in XML3D/Xflow.
I think this is an important point, especially if you think about
programs that automatically generate content.
Interestingly enough, XML3D does not have a clock object but one can
simply add another data field that can be used by interpolation
operators using Xflow. You simply define a "clock" data element that
provide the time and reference it from any data element that needs the
time (for interpolation or whatever). This allows us to map the Xflow
interpolator directly to a vertex shader that gets the clock data as
input using the generic means described above. You can also add an Xflow
transformation function to adapt the timing where needed.
BTW, XML3D does not autoincrement the time but doing so is 2-liner in JS
and it automatically recomputes any changed data elements (only where
needed, of course). XML3D does not define interpolators elements in the
standard but allow anyone to write Xflow operators for this. We
pre-define some often needed ones but anyone can extend them at will.
(3) This is automatically taken care of by the above mechanisms, except
that you define thing inside-out compared to your approach.
As a comparable example:
<mesh ... >
<data compute"position=interpolate(clock, pos1, pos2)">
<data src"#mydata" /> <!-- could also put the data right here -->
<data src="#myclock"/> <!-- compose with the clock data -->
</data>
</mesh>
<data id="myclock">
<float name="clock"> 0 <float>
</data>
<data id="mydata">
<float3 name="pos1">...</float3>
<float3 name="pos2">...</float3>
</data>
BTW, we recommend to put the data in separately and asynchronously
loaded resources that are then references simply by a URL (and very
efficient transferred via BLAST [4] where needed).
If you want to look at the surprisingly, small but still very powerful
approach (<10 core elements for XML3D, already including the Xflow
mechanism), please have a look at the new XML3D 5.0 specification [3].
I think it nicely shows how a very small but orthogonal design can cover
a lot of things that current X3D needs many separate elements for and
still be extensible to thing not covered yet by X3D. And even better its
all implemented and working already, plus well tested in many projects.
I wish all of you nice holidays and a happy new year.
Best,
Philipp
[1] Klein, Felix, Sons, Kristian, Rubinstein, Dmitri, Byelozyorov,
Sergiy, John, Stefan and Slusallek, Philipp, Xflow - Declarative Data
Processing for the Web, in Proceedings of the 17th International
Conference on Web 3D Technology , page 37-45, 2012. See
<a class="moz-txt-link-freetext" href="https://graphics.cg.uni-saarland.de/2012/xflow-declarative-data-processing-for-the-web/">https://graphics.cg.uni-saarland.de/2012/xflow-declarative-data-processing-for-the-web/</a>
[2] <a class="moz-txt-link-freetext" href="http://xml3d.org/xml3d/specification/5.0/#data-and-dataflow-elements">http://xml3d.org/xml3d/specification/5.0/#data-and-dataflow-elements</a>
[3] <a class="moz-txt-link-freetext" href="http://xml3d.org/xml3d/specification/5.0">http://xml3d.org/xml3d/specification/5.0</a>
[4]
<a class="moz-txt-link-freetext" href="https://graphics.cg.uni-saarland.de/2014/blast-a-binary-large-structured-transmission-format-for-the-web/">https://graphics.cg.uni-saarland.de/2014/blast-a-binary-large-structured-transmission-format-for-the-web/</a>
Am 23.12.2015 um 17:16 schrieb Leonard Daly:
</pre>
<blockquote type="cite">
<pre wrap="">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>
would become
<IndexedFaceSet ... >
<CoordIndex>...</CoordIndex>
<Coordinate>...</Coordinate>
</IndexedFaceSet>
This allows the transfer of large data in a node rather than an
attribute. It does make it easier to deal with large quantities (> 65K
characters). There are a number of nodes, including geometry,
interpolator, Metadata, and PixelTexture that would all benefit.
2) TimeSensor should take any number of any kind of interpolators as
children. Each interpolator would automatically have the TimeSensor's
/fraction_changed/ field automatically ROUTEd to the interpolator's
/set_fraction/ input event field.
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>
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' />
To preserve the past, this would be an optional construct. This collects
the information involved in keyframe animation in one node (TimeSensor).
--
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>