Xflow: time data source

[wherget]

Another feature request, this time for xflow. An operator yielding time would be very neat, so I could do

<data compute="transform = xflow.createTransform(translation, rotation)">
    <data compute="animationKey = xflow.time() % 10.0" />
    <float4 key="0.0" name="rotation">0.0 0.0 0.0 1.0</float4>
    <data compute="translation = xflow.lerpSeq(translation, animationKey)">
        <float3 key="0.0" name="translation">0.0 0.0 0.0</float3>
        <float3 key="5.0" name="translation">0.0 100.0 0.0</float3>
        <float3 key="10.0" name="translation">0.0 0.0 0.0</float3>
    </data>
</data>

where the resulting transform would repeatedly move 100 units along the y-axis up and down in 10 seconds time. This is similar in usage to Quartz Composer's Patch Time. Note that I have blindly assumed the existence of a modulo (%) operator and possibly abused the syntax due to lack of documentation ;) PS: I have a ton more of these, maybe it wold be easier to document how to write new operators?

[dmrub]

You can look in xml3d-examples repository for examples of custom xflow operators. Search with git grep 'Xflow.registerOperator'. Xflow documentation, including operator list, is here: https://github.com/xml3d/xml3d.js/wiki/Xflow.

[lachsen]

Hi.

A custom operator won't cut it in this case.

This would be an Xflow operator that would automatically change output by itself, which goes against the current design concept, that Xflows doesn't act on itself (e.g. output only changes if input is modified).

For such things, please add a minimal amount of JavaScript to do the Job. For most serious applications, this is usually the more feasible approach, as it allows the full flexibility of computing the time value (also for stopping the time, applying slowdowns, play the time in reverse).

If you still want the have a more convenient way to have automatic time values, I recommend the following: Add a marked <float> element, that is marked in a way for an external library to be detected to drive the animation. Example inside XML3D:

<float name="animationKey" data-time-loop="time % 10.0" ></float>

External Library

function updateTimeEntries(){
  var time = new Date().getTime();
  $("float[data-time-loop]").each(function(index, element){
     var timeExpression = element.getAtrribute("data-time-loop");
     var value = eval(timeExpression);
     $(element).text(value);
  });
};
window.setInterval(updateTimeEntries, 10);

This is kinda hacked, not tested, but about the amount of work that is needed. I don't think we need any (rather complicated) Xflow extension for this.

Use the Web, Luke.

[wherget]

What's the rationale behind the design paradigm that Xflow shouldn't act on its own then? Every data flow graph programming language I've encountered (XPresso, Pure Data [and conversely Max/MSP], VVVV) has had some notion of time-based operations. What would be the downside of evaluating time-originating expressions every frame (i.e. with requestAnimationFrame())? Because I don't see it.

Maybe I'll just try my hand at writing my own operator. Thanks for the documentation heads-up, dmrub

[lachsen]

The rational behind this design is to match the rest of Web technologies. HTML with the exception of few components (e.g. embedded media) is mostly static. Whenever we want to have dynamic content, we need to add some JavaScript with DOM modifications.

We also want to avoid the situation we have in VRML and X3D. Both include a very powerful and flexible dataflow mechanism that includes nodes for timers, input sources and all that. In practice, however, this system still was too restricting for most use case, so people always relied on scripting nodes in the end. On top of that, this dataflow system was designed in a way that is rather difficult to optimize, precisely because it includes so many self-running components as well as cyclic connections.

Xflow on the other hand has just one goal: It tries to model expensive computation tasks that are too expensive to handle with pure JavaScript and/or might be tightly connected with rendering (embedded into shading / post processing). In that sense, the focus of Xflow is simply different from other data flow graph programming languages. That's because we have JavaScript and we want to extend it, not replace it. Does any of the data flow systems you describe support a script language integration for dynamic changes at runtime?

A custom Xflow operator for this use case won't work. since this would be the first operator, that continously provides new output without any input modification. You would need to extend the Xflow system itself for this.

[csvurt]

I'm going to go ahead and close this 2 years later. The 5.0 release will include a section in the spec on how to write custom operators and the same functionality can be achieved by controlling the animation keys through Javascript at the page level.