This time out, we’re going to look at another crucial aspect of publishing that may seem obvious to some of you: the naming of the parts of your 3D model logically. Now, I’m not trying to force any of you to adopt some sort of draconian method or system to name your models, but our Member Services team has dealt with their fair share of clients who need help in trying to decipher a complex 3D model and figure out how it works simply because everything within it is named “Box209”, “Box210”, “pSphere75”, “CV_Curve26”, etc. In the worst cases, we’ve seen models where multiple parts are named identically, and this just doesn’t lead to a good user experience.
When it comes to naming your objects, you should think about a couple of things:
1. How do I best identify the various parts of my 3D model? First and foremost, unless you are building a 3D model with a single piece – say a wine glass or a vase (where the naming is pretty easy), generally speaking you will need to ensure that the various components within your model are named in a manner that someone who buys it can make sense of it. Let’s say you’re building a stereo speaker and it consists of 4 parts: the case, the grille, the woofer and the driver. Now, chances are that you’ll make your model from boxes and cylinders or splines and curves, but ultimately before you even consider posting it for sale, you’re going to want to name the parts. So instead of just Box01 or pCube1 for your speaker case, you should consider a more descriptive naming like “Case” or “SpeakerCase” or “Enclosure” – something to indicate to the person who buys it what that part of the model is. Simple enough, right? But there is more to it than just that, so read on…
2. How might my naming affect a client’s usage? In the example of my speaker above, the parts themselves are only a subset of a larger question – how might the customer who buys it use my 3D model? Consider that if you have multiple components, how do they relate to one another? If you just name your parts “case”, “grille”, “driver” and “woofer”, as you start to add them to other scenes, will that be enough? How can a user search for all of these parts in their own scenes? In the case of a speaker, chances are good that the client will likely want a pair, or perhaps several pairs of the speaker model to populate their scene with. Therefore, you also need to consider naming based on the ease of searching for all of its components and the potential that it might be duplicated. This leads to prefixing and numbering the components. Instead of “Case” you might consider “SpeakerCase01” or “Speaker01_Case”, “SpeakerGrille01”, etc.
The big thing here is to make sure that your 3D model and its components can be sequenced and easily identified when duplicated, and both the prefixing and numbering of each part will go a long way into making that a much easier process for your client. Check out this video to see what I mean.
3. Is this name going to work in another product? This tip may not be as obvious since many of you work primarily in only one 3D application and each app has its own way of doing things. If you’re working in 3ds Max, you know that you have the ability to name multiple objects the exact same thing, while products like Maya, Softimage, Cinema4D, modo and Blender don’t allow two objects to have the same name, they automatically adjust the naming specifically to avoid that. While it doesn’t take a rocket scientist to figure out naming multiple objects in your scene identically is just poor form, you might not realize that some packages also don’t allow spaces in their names, while others do. This can lead to possible issues when a client tries to convert your model from one format to another down the road. As such, it is recommended that you stick to the practice of either using no spaces in your model’s (and its components) name or using an underscore in the name. This way, the model should be convertible with a minimum of trouble, and other 3D packages won’t have to rename things on their own during file import, which can open the door to errors and unpredictable behavior. After all, your goal is to give your client the best possible experience so they come back and look for more of your content in the future.
4. What do you do with non-geometry objects that are part of your scene? Don’t forget the other things that you might want to save (or not save) with your model when you publish it. This can include lights, cameras, shapes, null objects, skeletons, Biped or CAT rigs, material libraries and more. To ensure that someone who buys your model can quickly identify everything that came with it, we recommend that you use a global prefix for these types of non-geometry items too. If you take the example of the speaker, you might include a studio lighting setup for it along with one or more cameras. Those could do with the naming prefix “Speaker01_LIGHT” or “Speaker01_CAM”, etc. or some other easily searchable and identifiable name within the overall name structure. Be sure to check for hidden objects, and delete the ones you don’t want to deliver, such as shapes or planes used as modeling aids. As scenes get more complex, if a customer imports your models and finds they have a ton of unrecognizable Dummy or curve objects it slows their workflow to a crawl while they try and decipher what’s really going on. If you help them by spending some time thinking about what you’re delivering and the naming of included objects, you ultimately help yourself.
That’s it for now. Next on our list of Publishing Best Practices: Material Handling. Until then, Happy Publishing!