Scene time input node #93098

New Issue

Hans Goudey · 2021-11-15T18:44:11+01:00

Hans Goudey commented

2021-11-15 18:44:11 +01:00

Currently, to access the scene's time in geometry nodes, one has to use a #frame driver.
People have gotten used to doing this, but there is no particular reason it has to be complicated.

Instead, we should add a "Time" node that gives the current scene time, in frames and seconds.

Details

The node should have two single value outputs:

Frame The current scene frame
Seconds The current scene time in seconds (the name is the unit since there is no other way to make that clearly visible.

Implementation

Implementation wise the node itself should be fairly trivial. The more complex part is probably making the object reevaluate when the scene time changes.

To get the current time from the depsgraph use DEG_get_ctime(...).
To get the current depsgraph use GeoNodeExecParams::depsgraph().
In updateDepsgraph in MOD_nodes.cc, the node group has to be scanned for a Scene Time node, and if available a relation has to be added to the depsgraph. Maybe a new function next to DEG_add_node_tree_relation has to be added for that (e.g. DEG_add_scene_time_relation).

Further Questions

Node name: "Time" is a bit vague when there could possibly be other sources of time in the future-- simulation time, object time. So Scene Time might be a better more explicit name.

Currently, to access the scene's time in geometry nodes, one has to use a `#frame` driver. People have gotten used to doing this, but there is no particular reason it has to be complicated. Instead, we should add a "Time" node that gives the current scene time, in frames and seconds. ### Details The node should have two single value outputs: - **Frame** The current scene frame - **Seconds** The current scene time in seconds (the name is the unit since there is no other way to make that clearly visible. ### Implementation Implementation wise the node itself should be fairly trivial. The more complex part is probably making the object reevaluate when the scene time changes. * To get the current time from the depsgraph use `DEG_get_ctime(...)`. * To get the current depsgraph use `GeoNodeExecParams::depsgraph()`. * In `updateDepsgraph` in `MOD_nodes.cc`, the node group has to be scanned for a Scene Time node, and if available a relation has to be added to the depsgraph. Maybe a new function next to `DEG_add_node_tree_relation` has to be added for that (e.g. `DEG_add_scene_time_relation`). ### Further Questions Node name: "Time" is a bit vague when there could possibly be other sources of time in the future-- simulation time, object time. So `Scene Time` might be a better more explicit name.

Hans Goudey commented

2021-11-15 18:44:11 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2021-11-15 18:44:11 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey changed title from ~~Time input node~~ to Scene time input node

2021-11-15 18:44:28 +01:00

Aaron Carlisle commented

2021-11-15 19:35:45 +01:00

Added subscriber: @Blendify

Aaron Carlisle commented

2021-11-15 19:35:45 +01:00

Sounds good 👍🏻 a reminder to me or someone else to rename the compositor time node to "time curve node".

https://docs.blender.org/manual/en/latest/compositing/types/input/time.html

Sounds good 👍🏻 a reminder to me or someone else to rename the compositor time node to "time curve node". https://docs.blender.org/manual/en/latest/compositing/types/input/time.html

Paul Larson commented

2021-11-15 21:58:24 +01:00

Added subscriber: @GeorgiaPacific

Aaron Carlisle commented

2021-11-15 22:48:02 +01:00

Can we add the scene framerate also? This way we can easily calculate time in seconds (or any other unit) rather than in frames.

Hans Goudey commented

2021-11-15 22:51:36 +01:00

In #93098#1254043, @Blendify wrote:
This way we can easily calculate time in seconds (or any other unit) rather than in frames.

Isn't that what the seconds output is for though? Anyway, I don't really think framerate should be exposed that way, since it can be problematic if changing the framerate for rendering can change arbitrary things in some node tree.

> In #93098#1254043, @Blendify wrote: > This way we can easily calculate time in seconds (or any other unit) rather than in frames. Isn't that what the seconds output is for though? Anyway, I don't really think framerate should be exposed that way, since it can be problematic if changing the framerate for rendering can change arbitrary things in some node tree.

Aaron Carlisle commented

2021-11-15 22:55:34 +01:00

My bad I didn't see the seconds output, I thought there was only frames.