"Time," shader node
For procedural shaders, or any type of animated texture, I would love to see a simple Time / Frame input node for cycles. All it would do is output the current frame number.
It's kind of a pain to animate a value manually because "speed," and "duration," aren't linked, meaning if change one you have to tweak the other.
16 Comments
Just add a Value node (Input > Value) and type "#frame" into the field. That will output the current frame number.
* @michael * Honestly, I didn't know this was a thing! I knew you could type math expressions like "50 / 12" into an input, but I didn't know you could do dynamic things like that. Do you know where I can find more of these "expression," commands like #frame?
* @Zach Hixson * Using "#" in this way is just a quick way to add a driver actually. So drivers is what you'd want to read up on. This is a good video to get started. It's good fun actually.
* @Zach Hixson * There's a variable for driver namespace - bpy.app.driver_namespace - type this into the console and you get a looooong list of stuff the drivers are aware of. You can add any Python function to the list (just like a Python dictionary).
I use the time node in UE a lot. Not everybody knows the solution with drivers and it isn't the first thing i would think about. I think that having a time node would be great. In combination with divide and modulo it is super powerful to quickly create animations.
What would it be ? A node which outputs the frame number as a value ?
I may be wrong here but I doubt it would be usefull as is. I can't think of anything you could do with integer values goind up crazy like the frame number as input in a shader.
When I animate something through time in a shader, I don't use the frame value directly. If I want my shader to have some property at fframe 4012, I don't input the value "4012" somewhere in my shader, I either add keyframes to some shader properties "at frame 4012", or I use drivers.
* @-L0Lock- * Maybe think of it as a ready-made time driver. I think it'd be very handy for anything that needs to evolve through time, like procedural fires or water.
* @ferran m.clar * If that's the case, why not (as * @michael * pointed out, just actually use a driver?
* @ferran m.clar * Animation nodes as a time node, and as such it would clash if we made another time node just for the shader screen. Eventually these things will likely be unified in everything nodes so probably better off as is.
* @Jason van Gumster * To me it is a UX/quality of life thing. Will provide a ready-made setup for a node that everyone would need to assemble in roughly the same way. Same reasoning behind getting some material pressets bundled in. And as * @daniellepalme * points out, Animation Nodes implements it, probably for a good reason.
* @daniellapalme * well, Animation Nodes wouldn't need to implement one if Blender had one itself, addon-agnostic. You are probably right though, and wel'll be getting one with Everything nodes.
* @ferran m.clar * There actually used to be a Time node (in the Compositor, at least). It was replaced with a preference to using drivers... mostly for workflow reasons (driven, time-based values could all be in the same place).
The Scene Time Node from geometry nodes could be added just for consistency to material nodes. docs.blender.org/manual/en/latest/modeling/geometry_nodes/input/scene/scene_time.html
Currently to get time you have to divide frame number with Attribute:view_layer:render.fps which is complicated. Some texture animations are just easier to do with time node than keyframes.
An extension to this idea: particle/Dupli age could be handled in a node.
* @Josephbburg * That's what you can already find in the Particle Info node.
Seriously? Then it'll probably be pretty easy to add your feature. Cool! This would also be a great way to handle image sequences, which should then be given a "frame offset" input