MartinusMagneson's picture

Magneson (@MartinusMagneson)

Groups

    MartinusMagneson's picture
    Magneson commented on Bodysoulspirit's Feature Request, “Fire / Time at chosen FPS

    What would be an example of a situation where this would be a better solution than the proposed Target Framerate?

    Not sure if better, but maybe a couple different ways of looking at it. I would assume jersmi 's method would result in lower system overhead in total, considering fewer (duplicate) frames. As someone that deals with broadcast equipment a lot (looking at you Blackmagic), along with Powerpoint that does exactly this, I can hardly say I'm a fan of the approach.

    With a "get system refresh rate" you can easily divide it with any integer to get a subdivision of the framerate. That way you can not only trigger at half framerate, but also get every fifth frame for instance - for less important/time sensitive tasks.

    MartinusMagneson's picture
    Magneson commented on Bodysoulspirit's Feature Request, “Fire / Time at chosen FPS

    While the time output ports don't output the exact same time for Display Refresh vs Divide set to 1/60 (which I hope is not a big deal)

    This is just the info overlay rounding up

    Can you explain how that would make it easier ? If using Fire Periodically 1/60 will always output the same no matter the display no ?

    Fire periodically will fire at a set rate, but if it will sync up to your display output rate is something different. This is probably why your older iMac stutters as well. If system framerate is set to 75Hz, and you fire at 60Hz, these only match up every fifth frame. Then it can be a bit hit and miss when you get sync. This is probably why jersmi wants system setting control, and is why I think a get "system refresh rate" would be neat :).

    MartinusMagneson's picture
    Magneson commented on Marc's Discussion, “Refactor a composition

    I'm definitely in the MOIST camp apparently 😅. I'm struggling to understand the point of the composition. If the point is to count down from 3 to 0, then sum the countdown, I'd just do as in the attached composition (but would probably not comment it that much if it wasn't for the task). It does pretty much the same thing, and is by the looks of it a tad bit faster at it. I got <.03333 seconds for the attached comp repeatedly at ideal conditions VS <.050000... seconds in the original. These are based on frame times though, and can be impacted quite a bit by other open windows and overlays so a couple grains of salt is needed for that timer. I did get outliers at .16 and .18 respectively sometimes for both of them.

    I use node naming a lot when building my own stuff rather than comments. Trying to make it easily readable/understandable from the nodes and structure itself is less time consuming than excessive commenting. When noodling intensifies, focus on commenting quickly looses its importance. I look at it as a tradeoff between getting things done and getting things done correctly. That can depend on who is paying the bill. If it's a one-off exported app, it doesn't matter much. If it's a repeated task, a commented subcomp is usually better (to then drop into small exports). If I'm the only one that looks under the hood, and I can understand what's going on from node names and colors, I wouldn't care much about comments. If it's for others to see, use and modify - comments are very necessary.

    MartinusMagneson's picture
    Magneson commented on Bodysoulspirit's Feature Request, “Fire / Time at chosen FPS

    I think these are two (or three perhaps) issues that should not be confused. Time is always time from composition start, not linked to framerate in itself (and framerate/frame-number should never be used to drive animations).

    First is the "Fire Periodically" approach. Use a "Divide" node to set the timing - don't enter decimals manually ;). "1" at input A, then your desired framerate as the divisor. In such a workflow, a "Get System Refresh" node or a "Display refresh time" output from a "System Info" node would be beneficial to make "Fire Periodically" nodes more easy to use (Jean Marie). Then it's just a matter of multiplying the output of this node by an integer to get a subdivision that should match up with the system refresh/draw.

    Second is excessive event firing in generators/time input compositions. You don't want to link this up to framerate either, but rather limit the incoming triggers to a more suitable rate for the HW you got. To do this; attach an event cable from the "Time" input port to the "Increment" port of a "Count within range" node. Set it to a minimum of 1 and a maximum of 2. Drag the output of this to the "Which" port of a "Select Event out (2)" node, and attach the "Time" input port to the event input of the selector. Now you can use the trigger outputs to drive the composition at half the input rate (you can also play around with increasing the max value to get an in-between rate, but then you will skip frames here and there).

    Also when going fullscreen on a retina mac with a shadertoy-shader you are rendering at 4K or whatever the retina displays are. That can be pretty heavy, especially for some of the more experimental stuff done there. Try dividing the Width and Height inputs by 2 if you get these from the input ports/screen info node!


    Edit: Framerate is linked to time, but only in the sense that you get the time elapsed from composition start based on which frame you are at

    MartinusMagneson's picture
    Magneson commented on Magneson's Discussion, “Color picker depth

    Thank you Jean Marie! Turns out I was stupid and had set my debug port to output a scaled integer that confused me a bit :)

    Pages