What is the correct (best?) way for reading time?

StephenTStephenT Fabric for MotionBuilder Posts: 77

After working with Fabric for a long time, I am still unsure how a graph should access 'time'.

On the one hand, we have the EvalContext, which has a time parameter. When I found this, I assumed that it is the way to access host time. Nice and easy.

However, most of the sample graphs rely on the input "timeline" parameter, which is a regular port that most (but, er... not all) DCC's automatically hook up to be driven by their own timelines.

I appreciate that time is a parameter, just like any other. Except it's not, because you don't want the user seeing it/messing with it in the UI. Internally, any preset should accept time as an argument rather than accessing a global. However, shouldn't a root-level graph just use the EvalContext?

What is the recommended method of accessing a host apps time? It should be consistent across all DCC's if Fabric is truly write-once, run-anywhere.

And would it be possible to get rid of the other (non-recommended) method to make things just a bit cleaner/clearer?

Tagged:

Best Answer

Answers

  • StephenTStephenT Fabric for MotionBuilder Posts: 77

    Hi Helge,

    This does make sense - especially no the reusability front - but the way the things are implemented today it's not clear at all. DCC's are implemented one way, and Standalone another, and our 4th dimension feels like a distinctly 3rd class citizen.

    I have a few requests that make time a proper built-in dimension that you don't have wire up manually...

    Could we remove time from the EvalContext? If it is there 90% of the time, that still means your graphs won't work 10% of the time, which is worse than 0%. It should either work, or not be there.

    Also, could we move the implementation of the DFGController::setTime functions out of DFGController to somewhere in the core code? The problem with having these functions in the DFGController is that code is UI layer code, and the DCC graphs don't have reliable access to it (what happens if you have no UI?).

    https://github.com/fabric-engine/FabricUI/blob/721a1f18ceb9ca3962ee788eed7939e4e526d2a5/DFG/DFGController.cpp#L2383

    Ideally, these functions should exist on DFGBinding. Internally, the DFGBinding should be the one responsible for figuring out which ports are time ports (if they exist). The DCC implementations (and Canvas) can all call setTime on the binding. This is also consistent with DFGBinding being the logical gateway for parameters entering the graph.

    This would unify the treatment of time across all applications, ensure availability of the time/frame/FPS/etc to graphs but without requiring the DCC's to come up with their own (hopefully) identical implementations.

  • HelgeHelge Moderator, Fabric Employee Posts: 314 Fabric Employee

    Hey @StephenT,

    I'll file a follow up ticket for this cleanup work.

    Best,

    Helge

    Research Engineer @ Fabric Software

  • StephenTStephenT Fabric for MotionBuilder Posts: 77

    thanks much Helge :-)

  • StephenTStephenT Fabric for MotionBuilder Posts: 77

    (ideally, the KL DFGBinding class would also include functions for setting time - so my graphs embedded in KL, embedded in DFG could also work out-of-the box :p although if I'm asking too much forget this, these embedded graphs require a fairly strict format already. But it would be nice!)

  • malbrechtmalbrecht Fabric for Houdini Posts: 752 ✭✭✭

    Just to throw in some support for the idea: I am all for having a reliable(!!) timing function available "anywhere" in Fabric, independent from DCC and/or standalone. Best would be both a setter/getter and a "pull request" so that a reevaluation based on a timed trigger can be initiated (IRQ/RTI line of thinking).
    Yes, using the timeline "kind of" gives me that, but not accurately enough if I am dealing with subframes, which I will be in any kind of simulation and/or RT data processing.

    Marc


    Marc Albrecht - marc-albrecht.de - does things.

  • StephenTStephenT Fabric for MotionBuilder Posts: 77

    Marc - this actually brings in another controversial question - do we use scalar time or frames?

    I'm busy converting all my code from scalar seconds to frame-based. I just don't like the uncertainty that a floating precision brings - representing 1/30 precisely is not possible. Which isn't a huge problem, but there is enough uncertainty to make time comparisons unhappy.

    Sub-frame evaluation is super-important though - but there is no need for the frame to be an int. I'd suggest time as a float-based frame number. Precisely represents frame time, even down to extremely small sub-intervals.

    With Fabric's move into RT games, I'm not sure if this segues with their long-term goals though.

  • malbrechtmalbrecht Fabric for Houdini Posts: 752 ✭✭✭

    Sub-frame evaluation is super-important though - but there is no need for the frame to be an int. I'd suggest time as a float-based frame number. Precisely represents frame time, even down to extremely small sub-intervals.

    Just bouncing back your own argument: If the frame number gets piped in from an external source (DCC), it might get calculated somewhere, and "wrong" so (read: "Floating" just beside the correct value, if the pun is excusable). Which would definitely speak for frame numbers to be int.

    Personally I'd always go for an SMPTE like encoding of timings, read: Being able to address subframes as INTs, too. So a correct frame address could be 40:30:24 on a 25fps timeline, meaning frame number 24 after 40 minutes, 30 seconds of time passed. Subframes would then be accessible depending on a set subframe resolution (e.g. 1000) as 40:30:24.754 (subframe 754 based on the same frame as before).
    But I have to underline that this is a very personal preference and might not make it into any hall of fame of being widely acceptable.

    The problem that I see, however, with subframes being only addressed through float values on the timeline is exactly this: If there is no definition for the subframe resolution, the graph might be clueless as to what is to be read in the firs place (I am still having in mind that a second can be framed into 24, 25, 29.97 and whats not).
    Sure, you can just SET it to be decimal - and I'd be happy to live with that. But without any definition given, I am not a fan of a float for the frame pointer at all :)

    With Fabric's move into RT games, I'm not sure if this segues with their long-term goals though.

    Games ... pffft! :wink:

    Marc


    Marc Albrecht - marc-albrecht.de - does things.

  • scaronscaron Fabric for Houdini Posts: 171
    edited August 3

    how we express time is tricky endeavor, especially for a tool like Fabric which is about integration and playing nicely with others.


    https://github.com/PixarAnimationStudios/OpenTimelineIO

Sign In or Register to comment.