Wishlist of future variables and path templates
With the upcoming
Project Setup system (#133001)
, Blender is getting a powerful new feature:
Templates for render output paths (#134860)
. This introduces a new
{variable_name:format}
system for file naming and paths, with support for things like
{fps:####}
and
{blend_name}
or
{resolution_y}
, and as they say:
more can be implemented in future
I propose we start gathering a wishlist of future variables the community would like to see supported, whether for filenames, folders, automation, or debugging.
Below is a list of suggestions which I thought while conversing on this other proposal , but please add your own ideas too! The goal is to shape a variable system that grows to meet real-world production needs, without overcomplicating the user experience.
NOTE:
I will try to update this post with the community's proposals, but also with the current state of implementation in Blender.
🔵 : Available in current release
🟢 : Implemented in source code
🟠 : Work In Progress
⚪ : To do
🔴 : Rejected
Counters & Randomness
-
⚪
increment
Automatically increments based on matching files or folders in the output path. Default 4-digit zero padding equivalent to{increment:####}. Could have different variants as in ShareX . Useful for iterative renders:render_{scene}_{i:####}.png. -
⚪
random
Outputs a number where each#is a digit from 0 to 9 e.g.{rand:#####}→39528,{rand:##}→07. Could support seeding or alphanumeric modes in the future
Date & Time Components
I think it's best if these have default zero-padding that make sense (most number like
y
or
h
are 2 digits except
yy
and
ms
which are 4 and 3 digits respectively), but with manual override still available (e.g.
{h:###}
).
-
⚪
y
Year (2 digits) e.g.25 -
⚪
yy
Year (4 digits) e.g.2025 -
⚪
mo
Month number (01–12) e.g.07 -
⚪
mon
Month name (system language) e.g.juillet -
⚪
mon2
Month name (forced English) e.g.July -
⚪
d
Day number (01–31) e.g.08 -
⚪
day
Day name (system language) e.g.lundi -
⚪
day2
Day name (forced English) e.g.Monday -
⚪
w
Week number of year e.g.28 -
⚪
h
Hour (12-hour format) e.g.03 -
⚪
hh
Hour (24-hour format) e.g.15 -
⚪
m
Minute e.g.42 -
⚪
s
Second e.g.07 -
⚪
ms
Millisecond e.g.382 -
⚪
pm
AM or PM marker e.g.PM
Scene Information
-
🟢
scene_name
Name of the current scene. e.g.Scene.001 -
⚪
collection_name
Active collection name (or top-level if none active). e.g.Environment -
⚪
view_layer
Active view layer name. e.g.CompositingPass -
🟢
camera_name
Active camera name. e.g.Cam_Main -
⚪
world_name
Active world name. e.g.World_HDRI -
🟢
node_name
For a path inside a node, name of the node e.g.Bake -
⚪
render_engine
Render engine ID. e.g.CYCLES,EEVEE,WORKBENCH -
🟢
fps
Frames per second of the current scene. e.g.24 -
🟢
resolution_xandresolution_yThe render output resolution X and Y e.g.1920and1080 -
⚪
frame_end
End frame of the scene's timeline. e.g.250 -
⚪
frame_range
Formatted frame range. e.g.0001-0250 -
⚪
file_format
Output format from the render settings. e.g.PNG -
⚪
color_depth
Bit depth from Output > Color settings. e.g.16 -
⚪
view_transform
Active color management view transform. e.g.AGX,Filmic,Standard -
⚪
output_node_slot
Active output node slot in the compositor. e.g.Final,client_preview,watermaked -
⚪
cycles_backend
Backend used by Cycles for rendering. e.g.CUDA,OptiX,HIP,oneAPI,None -
⚪
devices
Comma-joined list of compute devices used (CPU/GPU names) for rendering. Examples:NVIDIA RTX 4090,Intel i9-13900K,AMD Ryzen 7 7700X -
⚪
layer_passes
Comma-separated list of enabled render passes for the active view layer. e.g.diffuse,color,z
File Information
-
🟢
blend_name
Name of the current blend file without the file extension. -
🟢
blend_name_lib
Name of the blend file of the ID the path property is on, sans file extension. e.g.my project file -
🟢
blend_dir
Path up to (but not including) the currently open blend file. e.g.C:\tmp -
🟢
blend_dir_lib
Path up to (but not including) the blend file of the ID the path property is on. e.g.C:\tmp
2 Comments
This is all great for internal variables but what also needs to happen as has been suggested time and time again is that Blender supports the evaluation of system environment variables so studios can launch Blender inside a managed environment and have these accessible in all parameter/property fields. Every established studio pipeline in the world worth mentioning relies on this and it's robust and simple.
Basically this: projects.blender.org/blender/blender/pulls/140584
Such a well-written post really.