Filename collisions are the thing that bites batch renderers, and from the feature list you are already close to guarding against them. If two jobs differ only on an axis that is not part of the filename template, both write to the same path and the second silently replaces the first, so a six job batch quietly produces four files and nobody notices until review.
The cheap guard is to generate every name up front, check the set for duplicates, and refuse to start while showing the colliding pair, rather than discovering it halfway through a long render.
The other thing worth having is resume. If a batch dies at job five of twelve, a small manifest of completed jobs written beside the output lets the next run skip what already rendered instead of starting the whole combination again.
Thanks for pointing these out! Your comment helped me realize that the description could explain this more clearly.
RenderRoster keeps an automatic job ID based on all four axes in each filename, even when camera or world names are omitted. Versioned filenames also preserve earlier renders.
Continue and Retry skip completed jobs within the same Blender session. Recovery after a Blender crash or restart isn’t currently available through the UI, so that part of your suggestion goes beyond the current functionality.
I’ve updated the description to clarify both points. Thanks for the useful feedback!
← Return to add-on
Comments
Log in with itch.io to leave a comment.
Filename collisions are the thing that bites batch renderers, and from the feature list you are already close to guarding against them. If two jobs differ only on an axis that is not part of the filename template, both write to the same path and the second silently replaces the first, so a six job batch quietly produces four files and nobody notices until review.
The cheap guard is to generate every name up front, check the set for duplicates, and refuse to start while showing the colliding pair, rather than discovering it halfway through a long render.
The other thing worth having is resume. If a batch dies at job five of twelve, a small manifest of completed jobs written beside the output lets the next run skip what already rendered instead of starting the whole combination again.
Thanks for pointing these out! Your comment helped me realize that the description could explain this more clearly.
RenderRoster keeps an automatic job ID based on all four axes in each filename, even when camera or world names are omitted. Versioned filenames also preserve earlier renders.
Continue and Retry skip completed jobs within the same Blender session. Recovery after a Blender crash or restart isn’t currently available through the UI, so that part of your suggestion goes beyond the current functionality.
I’ve updated the description to clarify both points. Thanks for the useful feedback!