What is your standard naming convention for render output?

[Rex]

Hi everyone!

We would love to see examples of your standard naming convention used for final image delivery. What are the variables that you include? i.e. date, scene name, model name, material name, camera name, version...

For example: "181016-scene_name-camera_name-v1.png"

Thanks for sharing!

[Esben Oxholm]

Mostly it's just something like 'projectname_iterationnumber'. E.g. 'Chair_03'.

For projects with multiple materials and camera angles it's something like 'projectname_cameraangle_materialsetup_iterationnumber'. E.g. 'Chair_threequarter_shinyblack_02'.

Cheers,

[martinwahlberg]

I often include resolution, something like this, Productname-color-backside-300ppi.png

[RRIS]

date_project code_concept name_camera name

Usually something like this.. it's easy to overdo it, but as long as you can find what you're looking for with a file search it's all good.

[mattjgerard]

ours are totally product based, and use the model strings that engineering has come up with to describe each part, then the CAD file ID number, and an alpha to indicate the view that will be connected in our PIM catalog.

eg-  tl50-gyr-blk-audible-qd-169559-a

tl50- Tower Light 50MM diameter
GYR- Green Yellow Red light segments from the bottom up
blk- Black housing
audible- sound module on top
qd- Quick Disconnect connection
169559- CAD file ID number also linked for pdf dwg drawings
-a  is the primary image for that product, can have others with -b, -c, -d for alternate views of back, bottom, closeup of features, etc.

now my personal works are much more unstructured and usually are some iteration of chair-fixedleg-003-redo-dammit-final-again.psd

Cinema 4d introduced the token system for render filenames a while back and i was just starting to get into using it, where you could dynamically give your renders names based on templated token strings that used variables such as camera names, pass name, object ID, take #, and lots of others. I don't think Keyshot needs to get that complicated, but being able to pull data from the current scene to name your renders would be sorta neat.

[Will Gibbons]

Date_Project Name_Version Number (if saving multiple iterations on same day)

Ex: YYYY_MM_DD_Product_One_V2

This makes it easy to search by and sort by date across all OS platforms.

[mattjgerard]

So the more I think about why this question is being asked, the more I think of this "How would I want KS to automatically name my renders" which probably has more practical use.

Here's how i see it maybe working =

1) Be able to populate a naming string with various variables that can be pulled from the project
2) variables could be model set, studio, environment name, image style preset applied, camera name, material set, currently selected multi-material, date, time, resolution (could be stored in the image style preset), pass name, render layer name,  or file name plus iteration based on a preset number or project revision number.
3) Interface would be a list of clickable icons with text denoting each of these "tokens" that can be dragged into a field that would represent the filename.
4) Can drag these "token" icons to reorder them in the field, maybe even show a dynamic example underneath to show what the filename would be with the options selected.
5) save this naming convention as a preset that would include (or not include) file path

This would be pretty powerful and while does not directly impact the quality of renders coming from KS, it would most certainly earn praise as one of those "ease of use" things that makes certain softwares a pleasure to use.

[Rex]

So the more I think about why this question is being asked, the more I think of this "How would I want KS to automatically name my renders" which probably has more practical use.

Here's how i see it maybe working =

1) Be able to populate a naming string with various variables that can be pulled from the project
2) variables could be model set, studio, environment name, image style preset applied, camera name, material set, currently selected multi-material, date, time, resolution (could be stored in the image style preset), pass name, render layer name,  or file name plus iteration based on a preset number or project revision number.
3) Interface would be a list of clickable icons with text denoting each of these "tokens" that can be dragged into a field that would represent the filename.
4) Can drag these "token" icons to reorder them in the field, maybe even show a dynamic example underneath to show what the filename would be with the options selected.
5) save this naming convention as a preset that would include (or not include) file path

This would be pretty powerful and while does not directly impact the quality of renders coming from KS, it would most certainly earn praise as one of those "ease of use" things that makes certain softwares a pleasure to use.

I like the way you're thinking

And what about the separator character? Are other characters used besides dashes, underscores, and periods?

Attached is the dialog Lightroom uses.

[theAVator]

For me it's pretty varied based on the project I'm working on.
But just in general:  VehicleName_Variant(if applicable)_System(Component)_View_Overlay/Underlay(if applicable)_Numbering(if applicable)
Which might look like:  HEMTTA4_M978Fueler_Engine_Left_1

As far as separators, I tend to only use underscore or hyphen. I'm old school and tend to stay away from using periods. Where I can, I try to avoid spaces as well.

As an aside, I think another feature along similar lines would be adding a metadata tagging system into this so that if you are outputting a large number of files, you can have it automatically metatag the files upon rendering them. I would think the logic and programming would be very similar to the functionality you're showing here with the filenaming system. You could set up the naming, and the tagging and then outputting files becomes an easier and more complete process. It also speeds up the process by not needing to go in after the fact and batch tagging the files on the back end (if it's part of your process).

[Eric Summers]

My naming convention is a combination of part of the scene name and the studio name. I use an 'X' in the scene name as a wildcard for various aspects but I don't want that in the image file name. So I name my studios 761, 763, and 769 for the model number and add camera info if applicable (this example I only have studios set up for XRs). When I have all the views I'm going to render, I'll take out '-76X' from the Name field and queue up all of my renders. KeyShot will processes the studios as XRO-761, XRO-763 and XRO-769 since KS puts a dash between the Name and the studio when rendered.

I'd love it if I could tell KS to name the files to just the studio name. That way I could put all of the info in the studio name instead of this half and half method. It's easy to forget to take the info out of the name field and end up having to manually re-name a group of images afterwards. There are also times a date stamp would be handy to have in the file name.

[mattjgerard]

I totally agree on the studio name. I've made this my habit of the studio name being what I want the final output name to be and end up copying and pasting stuff back and forth so I can track back from the image to the project to the studio that it came from.

Cinema does this with its system- $camera$res$frame$pass$prj where the $ sign denotes a "token" which is picked from a list. Uses a hyphen in between, which is what we use. Since we use AEM as our image library, no spaces slashes or periods in filenames.

I would disallow any non-standard characters, winders has always taken issue with / characters and such, so no need to allow those.

[mattjgerard]

I like the way you're thinking

And what about the separator character? Are other characters used besides dashes, underscores, and periods?

Attached is the dialog Lightroom uses.

The lightroom dialog looks great, its simple and easy to understand. The fact that it gives an example of what the end result would look like is another one of those really nice touches that makes the feature an easy to use one.

And I like that you all are asking the users what they think. Not many software developers do anymore, so much appreciated. And what I think you will find is that you don't have to reinvent the wheel with simple user experience stuff like this. We know you all will keep it simple for us in the end