A common question at TurboSquid is how to better present your models to help increase sales. One quick way to help increase your potential audience is to include wireframe renders of your models. It may come as a surprise to you, but we have many clients who won’t even consider buying a model without having a sense of what the wireframe looks like so they can determine if the model meets their project’s needs. Without at least one, these folks will just move on and not even consider your product.
As such, I have created a quick video for everyone on a simple technique to generate these wireframe renders within 3ds Max.
I’m currently working on similar videos for the other 3D apps including Maya, Softimage and Cinema4D, and will post them when done.
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!
Here’s a quick video to show you how you can quickly keep up with the TurboSquid blog while keeping busy within 3ds Max. Many of us, myself included, have a very limited amount of time to keep up on all of the news and changes in the 3D industry. For TurboSquid clients and vendors, this can be doubly true. As such, here’s an easy way to keep up with all of the happenings at TurboSquid without ever leaving 3ds Max:
Welcome to the first installment of our guide to help you become more successful as a vendor on TurboSquid. Over 9+ years, we’ve gotten a LOT of feedback from our clients, and we feel it’s important that we share this information with you so that you work smarter before publishing and can be more successful after you have content for sale through our library. So, let’s dive into our first topic:
REAL-WORLD SCALE
With more 3d animations relying on dynamics in one form or another; for example rigid body dynamics to destroy buildings or entire civilizations, soft-bodies for cloth, hair and other “squishy” bits, fluid dynamics for water, smoke and fire and much more, and global illumination rendering becoming more prevalent, it is becoming more critical that vendors consider the scale of the content they post for sale. In many cases, it is no longer simply enough to make the model “look right”, because it might be imported into a scene that needs real-world scale in order to function properly, whether as part of a specific render or as part of simulation system. This can be especially frustrating for a client who purchases your content (especially architects and designers, who use our library more often these days), so do your best to consider the following things while modeling:
1. For real-world content (i.e. cell phones, flower pots, speakers, tables, etc.) do a little research to make sure its scale is correct. Measure it! Check your units setup and use the built-in measuring tools to ensure you’ve got it set up right. The old adage “measure twice, cut once” can be updated for TurboSquid vendors to read “measure twice, publish once”. There is little use for a 10-foot tall cell phone, even if it is amazingly detailed and richly textured. Likewise a 150 foot long table will have a cloth sim behave very strangely unless the client who buys it wants it for a giant’s home. Check this video out to see what I mean:
Here are some other tips regarding real-world scale that we often see overlooked in many tutorials:
2. If you’re using image planes as guides to construct your content, make sure they are not only set up on the origin (which is just good modeling practice – but that’s a publishing topic for another day), but that they are to the right scale too. It makes little sense to do all of your modeling only to discover that your brand new car model with all its detailed bits and pieces is 30-meters long (unless you’re designing a SUPER stretch limo!). That will take a bit more of your time to scale down properly after the fact and opens up the potential for mistakes.
3. In concert with the previous tip, if you’re providing a model (as opposed to a scene or collection of objects), you should try and ensure that it is centered at the origin of the construction planes so on import, or merge a user doesn’t have to hunt for it.
That’s it for now. Next time, we’ll cover another crucial aspect of publishing – Model Naming. Until then, Happy Publishing!
