Naming Conventions that Drive Events

Pipelines
#1

This is my first thread that I’m starting. So uhhh…hi!

What do we think about relying on naming conventions that are reqired for proper exports?

At my last studio we didnt do this, we had object props, and those were how we marked things up for export.

At my current studio we have naming conventions and the name determins how the exporter interperates the object and how it’s treated in-game. We have a tool that vetts these and other game-specific conventions for clean exports.

Cons:
[ul]

[li]Forgetfullness/typos: I don’t trust myself or the art team enough to adhere to naming conventions. I used to forget all kinds of mundane shit when i did production art, I screwed it up many MANY times all day.
[/li]
[li]Lose the opportunity to apply meta-data: I want to wrangle under-the-hood settings at the point of mark-up. If we adhere to a naming convention, how do we apply custom data mark-up? Change the naming convention slightly? How many naming conventions are we gunna force the artist to remember?
[/li]
[li]Applying bulk settings to lots of objects: Yes, you can batch-chnage names, but it’s not a select-click process…it takes longer than that and more prone to errors.
[/li]
[/ul]

Pros:
I can’t even think of one (I’m actually trying). Why would you choose to type (as an artist) instead of click?

#2

We used some prefix conventions at Whatif, just for special items that need special processing like morph targets (don’t export the targets as unique entities), custom xrefs (validate the external and link to it), etc. Everything else could be any name desired.

The less artists have to type, generally the better off you and they are.

It’s probably better to use Custom Attributes for storing your data. We used Note Tracks to store time-specific data, with scripts to simplify the process so the artists never had to actually touch the Note Track UI, they just edited meta data with a clickable UI.

#3

Here’s a post I made awhile back in another thread that summed up my thoughts on naming conventions for exports, etc. In short, I think there’s better places to store data the pipeline needs.

#4

I’m very much against artist-driven naming conventions. I don’t mind naming conventions per-se, but it should all be automated if they are used. Artists should not have to adhere to naming conventions, they shouldn’t have to keep on top of things if naming conventions change, etc. It should all be handled automatically if naming conventions are used.

I had a much longer post but a power surge sent it into the ether…

#5

well, at least we’re all in agreement.

Now I get to fight to to get to do my job.

…I guess that can be a different thread.

#6

I once had a bad experience with “data” being embedded within filenames*. It started out as a simple solution someone suggested to flag a model of a particular type, but it quickly got out of hand as more “features” were added. Gah!

*It may have been model names, but still, Gah!

#7

Programmatically parsing freeform user input always ends in disaster.

#8

We went with naming conventions for model parts and textures, and for MOST artists this wasn’t an issue. There weren’t very many, but to make things easier I write some scripts for setting up scenes:

Copying in blank textures with the correct names.
A script that scanned the models texture folder and tried to automatically fill the shader slots. It reported on missing textures.
Artist based export checkers than scanned the model and texture folder for typos.

However, for the most part on our last project every character that was exported to the game essentially went through myself or a couple of other character artists so we were performing those checks too. I quickly got to see what the common mistakes were for other artists and was able to either rework sanity checking scripts or just point out the issue to them.

Our naming convention wasn’t complicated (in my head at least) - heads were prefixed Head, torsos as uppr, legs as Lowr. We also had Hand, Feet, Hair etc. for models with those parts as separate objects. Because a model could have several heads or torsos or whatever, they became Head_000, Head_001 etc.

Textures started off simple: head_spec_000, head_normal_000 etc. For our texture variations they became head_diff_000_a, head_diff_000_b etc.

#9

On the current project we’re working on, most of the pipeline is based on this (inside and outside 3ds max). It works, but its not the best solution…it just makes it that much easier for something, somewhere, to break.

As Eric said, the less artists have to type, the better.

#10

We have all custom data set up in custom 3dsmax nodes. Everything starts with a hiearchy. At the top of the hiearchy is a “rmdRoot” object which also gives a name for the exported model. Then there’s lots of different types of objects such as “rmdCollapse”, “rmdLOD” etc with their own properties.

We’ve made our own floater dialog for multi-editing the properties of several objects at once (I know there’s lots of that type of helpers out, but they all had some unnecessary clutter that I didn’t want). The same floater can be used to edit Havok data etc…

Pure naming conventions are always forgotten and easily broken. I like the hiearchy approach, it’s pretty easy to check already at pre-export time in 3dsmax that everything is good. All content errors should be caught as early as possible… :stuck_out_tongue:

SamiV.

#11

I’m working on a little ‘system’ to do the same, but with everything.
Artists only open preexisting files and save/export them, so no mistyping errors.

the ‘system’ is a wiki and subversion mixed together with python and batch files.
The lead artist can create new objects with this tool,and they are just blank files with a naming convention applied, plus a wiki page with links to the files.
It saves time also, since artists can drag’n’drop instead of browsing subdirectories to find stuff.

#12

Stuff like this becomes a real must for outsourcing studios. It hasn’t improved their quality but it has made sure there are few or no pipeline issues with assets we receive.

#13

I’ve done something similar to this too, it was particularly appropriate for the project I was working on at the time which had different versions of the same resources in different ‘worlds’ - I even started with a default model/texture/animation for every resource and they would be replaced as needed by whichever artist was responsible for that world.

It needed to be strict though, the game editor could switch a level from one world style to another at the press of a button and it was all keyed on filenames. It was a luxury system that took me a long time to set up, but was well worth it due to my boss’ habit of shifting level orders around on a Friday evening before a build.

#14

I am currently dealing with a lot of filename driven tool issues, and can see the wisdom of custom nodes / attributes to hold data.
But how do you add custom data to things like texture PNG images?

#15

Adding metadata like that to image files is sometimes (but not always) a crapshoot. Many image formats technically support for data like that, but is not respected by every application that writes them out. Your users might use some image-editing tool that just merrily punts that data when it rewrites the image, etc. In my experience this is more of a concern with older, looser formats like TGA than it would be for something more modern like PNG, but you should definitely do your homework there.

EXIF is one type of metadata some image formats support, but PNG is not one of them. PNG does have internal support for storing metadata, but I don’t have any direct experience using it.
Here’s some more info on metadata inside image files:

At our studio we use Perforce attributes to store metadata on both images and other files in our depot. It’s very nice knowing there’s one path to reading and writing that data, it’s not format-specific, and that it works on any type of file we use. But it took some elbow grease to expose it to all our tools in an intuitive manner. Some more details on Perforce attributes: