TurboTips: Scene Optimizations & Best Practices, Part 1

by Calvin Bryson

Keeping your scene clean and organized is important while making any 3D model. A well constructed scene will make modelling and editing your own model easier, and it may encourage customers to buy your product. The examples below are from 3ds Max, but these concepts can apply to any 3D package.

 

1. Organize Objects

If a 3D scene is difficult to navigate and/or modify, then editing a model within that scene can become extremely frustrating for the person attempting to use the model. (And this frustration is usually enough to make someone look elsewhere for a model that is easier to edit and use.) Industry professionals want a model that is ready for production and is quickly editable to fit their needs. No matter how great the model looks, poor scene organization can make it unusable to them.

Bad Organization_1

The treadmill model (pictured above) is a good example of an object that shouldn’t be combined or merged into one single object. Merging the model creates lots of subobject elements that are very difficult to sort through and edit. Not only would it be difficult for you to go back and adjust the model later, it would also be difficult for the customer who purchased the model.

Bad Organization_3

Bad Organization_4

 

If an artist wants to edit any part of this model, they would need to go into element mode to sort through the different pieces looking for all the parts that make up what they want to edit. Then, they will have to hide the unselected elements within the object to get a full view of the pieces they want, or detach the elements into a new object. This makes it very inconvenient and time consuming for the end user to make changes. Combining your model into a single object makes more work for everyone.

 

1.1. Naming

Good Organization_2

Name all objects and textures in the scene. The names must be descriptive enough so that anyone could look at the layer editor and quickly select the desired object. Never leave anything as the default name such as Cylinder03, Object05, Map #6(VrayMtl).

Naming

You can see in zoomed image above that every object has been renamed descriptively after separating the model out from one single object. If you select any of the names like “Console_Screws”, the descriptive name gives you a good indication of where to look on the model for this object. The first word indicates what larger part of the model to look; “Console” . The second word lets you know specifically which part of the model will be selected; “Screws”. You will also notice that naming this way makes selection very easy from the layer editor since all parts of the model will sort alphabetically.

 

1.2. Intelligent Combining & Merging

Good Organization_3

Merging multiple objects into one larger object should only be done when it logically makes sense. For example, the screws on the back of the console are combined into one object named Console_Screws instead of having 13 individual screw objects.

Calvin Bryson is the Senior Technical Artist at TurboSquid, and a 3ds Max expert.  If there are any topics you’d like to see in a future edition of  TurboTips, let us know in the comments below, or Tweet your question to @TurboSquid with hashtag #TurboTips.

 Next week in TurboTips: Using Layers, Part 2 of 5 in our series on Optimizing Scenes & Best Practices

4 Responses to “TurboTips: Scene Optimizations & Best Practices, Part 1”

  1. Lars Egerrup says:

    Well, there is a time for everything. I agree so far that it’s good when models are shipped from TurboSquid as shown above. However putting this model in a larger ArchViz scene, will result in a confusing amount of objects, even when put in groups. I usually have different versions of the same model for different uses – the ‘exploded’ version (hopefully shipped from the supplier), maybe even with the modifier stack intact. Then I have a fully collapsed version, as one object, for my ArchViz scenes – I might have the collapsed version in in various detail versions as well – far – medium – up-close. And them I have a version in proxy version.

    Another argument for having collapsed objects in ArchViz scenes is, that Max is good at handling objects with many sub elements/ sub vertices – but not specially good at handling zillions of light objects.

    Naming
    I use almost the same naming format, I would however prefer if the general model name would always be incorporated in the naming structure, – as it is very likely that you will meet other “foot”, “grip”, “console” ect. In your scenes.

    I also end my object names with .001, because then you are sure the name format will be kept as you instance the model – if you don’t, then you will get the following result: Gymband_console_main; Gymband_console_main01; Gymband_console_main02 ….

    The final thing – which might be out of the scope of this article – I try to give every sub component it’s own MatID. Even if multiple objects share the same material. It’s cumbersome indeed – but can turn out to be valuable in the end – especially when you work with the collapsed versions . It is so much easier to change material and make material variations through a multisub material with a well planed structure.

    Well, that’s of course my personal view on these things

    All the best
    Lars,
    senior visualizer
    LKE Design

  2. Calvin Bryson says:

    Lars, you do make a valid point from the consumer point of view in an ArchViz field. However, this is one part of many sections aimed more towards helping artists organize individual model scenes. This way artists who supply the market can offer a more versatile product to the consumer.

    I agree that in an environment scene you may not want all your props made up of dozens or more parts. Likewise, using your example of an exploded view, if a consumer were to buy the model as a single object then an exploded view would be very time consuming to create. It is much easier to attach all objects into a single model than it is to detach elements into new objects.

    There are methods to navigating an object heavy scene if the scene is organized using all the tools available to you in max such as layers and grouping. These are covered in the subsequent parts of this article yet to be posted. Using those tools possible encounters of duplicate names is potentially a non-issue.

    Workflows vary wildly per individual, company, and even industry. For those who are lacking a particular workflow we want information to be available. It is always best to make informed decisions over arbitrary ones.

    We appreciate you taking time to comment on the blog post and share your personal views.

    Calvin
    Senior Technical Arist | Turbosquid

  3. Lars Egerrup says:

    Well there is a time for everything!

    I agree a long way with your way of formatting the model. Your approach is for obvious reasons seen with the TurboSquid glasses on. I have however some remarks to your strategy.

    First of all I miss a prefix on the parts telling which main object it belongs to. Looking at an isolated model your way is good, however most of the models sold on TurboSquid are used in (much) larger scenes, and when you insert a model, like the Threadmill, the chance that you will meet other Foot_Pad, Grip_Screws, Base_SidePanel, Console_Main, in the scene are quite large. At the same time they would be spread/mixed around in the object list – making it much harder to find.
    By putting a ‘ThreadMill_’ in front would keep the parts assembled together and you would never be in doubt which model they belonged to. 

    Next I would ALWAYS put a number formatted like this ‘.001′ in the end of each part. Max adds automatically numbers to instances in the format 01, 02, 03  …  in case no other format is made. This result in the following structure in the naming list if you do not preformat the numbering …..

    Threadmill_Foot_Pad
    Threadmill_Foot_Pad01
    Threadmill_Foot_Pad02
    Threadmill_Grip_Screws
    Threadmill_Grip_Screws01
    Threadmill_Grip_Screws02

    Giving a messy look in the namelist. I personally prefer if it look like this:

    Threadmill_Foot_Pad.001
    Threadmill_Foot_Pad.002
    Threadmill_Foot_Pad.003
    Threadmill_Grip_Screws.001
    Threadmill_Grip_Screws.002
    Threadmill_Grip_Screws.003

    I case of several variants of the same thing, it can be

    Threadmill_Grip_Screws01.001
    Threadmill_Grip_Screws02.001

    Or ..

    Threadmill_Grip_Screws_L.001
    Threadmill_Grip_Screws_R.001

    A whole other aspect in this discussion is that one thing is to publish a model on TurboSquid, another is to work with them in a large ArchViz scene.

    I would almost ever collaps the model to one object when used in an ArchViz scene. A chair is a chair – and unless you want to be able to i.e. adjust it’s height or something similar. In that case I would collaps the sub parts in chunks that move together – maybe link them and then group the whole lot.

    3DS Max is good at handling larger objects with many sub objects, and not so good at handling zillions of small objects.

    In my model library i have several variants of the same model. The original one from the supplier – hopefully organized as mentioned above. For insertion in my scenes I have a collapsed version, and a proxy version – and if the model is heavy to very detailed. I have  versions in various levels of detailing.

    Lastly, which might be out of the scope of this article,  I give all my sub part a unique MatID – of course not internal instances, they will obviously share the same MatID. Yes, it is a comber some  approach, but it make the model much easier to administer – and it will act the same wether it is in bits and pieces or fully collapsed. Furthermore it is very handy once you want to make material variants of the model. It is so much easier to change a material in a multisub object .

  4. Spedition says:

    If you use naming like here:

    http://blog.turbosquid.com/wp-content/uploads/2013/12/Naming.jpg

    objects will be scattered on the object list after merge to scene. Objects of the one model should have the same name prefix, and be named alphabetical like from example above:

    Threadmill_Foot_Pad
    Threadmill_Foot_Pad01
    Threadmill_Foot_Pad02
    Threadmill_Grip_Screws
    Threadmill_Grip_Screws01
    Threadmill_Grip_Screws02

    etc.

Terms of Use Privacy Policy Site Map © 2013 TurboSquid