[x3d-public] X3D V4 Thoughts

[Leonard Daly]

Philipp,

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.


Leonard Daly

> 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
> https://graphics.cg.uni-saarland.de/2012/xflow-declarative-data-processing-for-the-web/
>
> [2] http://xml3d.org/xml3d/specification/5.0/#data-and-dataflow-elements
>
> [3] http://xml3d.org/xml3d/specification/5.0
>
> [4]
> https://graphics.cg.uni-saarland.de/2014/blast-a-binary-large-structured-transmission-format-for-the-web/
>
>
>
> Am 23.12.2015 um 17:16 schrieb Leonard Daly:
>> 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
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
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/20151223/f7435536/attachment.html>