Large Project Workflow

[glorybound]

Like the title says, I am looking for a way to optimize a large scene that I am working on. Currently, I don't even have materials and I am getting a lot of spinning cursors. Should I XREF as much as I can? I have several buildings that are copied, so I am assuming XRef's will help. Anything else to do? I don't want to jump through hoops if it's not going to speed up viewport performance.

[glorybound]

Some more views. This is the one that had no plans; everything was from napkin sketches and a lot of iterations.



There are three sizes of residential apartments, a clubhouse, and three commercial buildings. I am hoping that we won't have many materials. Hopefully, there won't be more than 1/2 dozen, since it's all in one complex and are supposed to work together.

[super gnu]

isolate each unique building, collapse geometry by material, so you have a single object for each material type. then replace any copies of the building with instances of your optimised building.

looking at the complexity of the scene, that should be enough to get you good performance.

should the scene get really heavy (likely in the end i guess), export each building type as a proxy and instance that around the scene.

xrefs are good for keeping scenes organised, but dont do half as much for viewport speed as collapsing into fewer objects, and use of proxies.

also, i dont know if this is fixed in newer versions of max, but in 2014 there is an xref bug where the "invisible in viewport" and "display as box" settings for xrefs are ignored when you reopen a saved scene. this can lead to some painful viewport playback, when you open a really heavy scene.

if you want to do large areas of grass and planting with forestpack, expect to use a lot of ram!

i dont know how close you will get to each building, but id definitely consider avoiding displacement for bricks etc apart from in very closeup shots.

[super gnu]

ok ive just seen the closer shots. you could also check the models for any particularly high poly elements (the sunscreens?) and proxy/instance those. this is more flexible than proxying the whole building of course.

[glorybound]

perfect, thanks!

isolate each unique building, collapse geometry by material, so you have a single object for each material type. then replace any copies of the building with instances of your optimised building.

looking at the complexity of the scene, that should be enough to get you good performance.

should the scene get really heavy (likely in the end i guess), export each building type as a proxy and instance that around the scene.

xrefs are good for keeping scenes organised, but dont do half as much for viewport speed as collapsing into fewer objects, and use of proxies.

also, i dont know if this is fixed in newer versions of max, but in 2014 there is an xref bug where the "invisible in viewport" and "display as box" settings for xrefs are ignored when you reopen a saved scene. this can lead to some painful viewport playback, when you open a really heavy scene.

if you want to do large areas of grass and planting with forestpack, expect to use a lot of ram!

i dont know how close you will get to each building, but id definitely consider avoiding displacement for bricks etc apart from in very closeup shots.

[glorybound]

So, I have to proxy one, delete the others and instance them?

ok ive just seen the closer shots. you could also check the models for any particularly high poly elements (the sunscreens?) and proxy/instance those. this is more flexible than proxying the whole building of course.

[Oleg_Budeanu]

isolate each unique building, collapse geometry by material, so you have a single object for each material type. then replace any copies of the building with instances of your optimised building.

looking at the complexity of the scene, that should be enough to get you good performance.

should the scene get really heavy (likely in the end i guess), export each building type as a proxy and instance that around the scene.

xrefs are good for keeping scenes organised, but dont do half as much for viewport speed as collapsing into fewer objects, and use of proxies.

also, i dont know if this is fixed in newer versions of max, but in 2014 there is an xref bug where the "invisible in viewport" and "display as box" settings for xrefs are ignored when you reopen a saved scene. this can lead to some painful viewport playback, when you open a really heavy scene.

if you want to do large areas of grass and planting with forestpack, expect to use a lot of ram!

i dont know how close you will get to each building, but id definitely consider avoiding displacement for bricks etc apart from in very closeup shots.

Well he said it all !
3DsMax hates a lot of objects - join your buildings in one edit poly with multimaterial , and proxy high polys. That's all. Personally i hate XRef system , so i prefer to use layers. If you work in a group than there is sense to use Xrefs on early stages of design/prototyping.
And yeah , instance geometry can save some memory and speed as well. If you have repeating objects with a lot of polys - proxy-instance them.

[piotrus3333]

I recently had a fairly big one - about 4-5 times bigger residential developement. closeups, aerials - around 14 cams.
I tried containers with xref mats. took a while to get all that working nicely but next time I will do the same.
Im on 2015 so cant xref mats to the main scene, needed separate one for materials, overwriting that required manual deleting of file - but everything else was pretty smooth. and containers are easy to edit along the way, teamwork or not.

[re:FORM]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
he... used...containers! ....kill him!

Can you tell us more about your workflow with containers? I don't know a single person/company that has dared use them in production after getting burnt in the early days of their usage.
Have the problems that ruled them out in previous versions been resolved?

[piotrus3333]

hehe, I heard about all the problems but wanted to try anyway. I did have some issues (like containers silently overwriting scene materials when opened) but all of them were resolved. max 2015.

files setup: one main scene, folder with separate buildings scenes and folder with all the containers (.maxc files). building scenes have containers inside them - trick is to saving this file twice - with container opened (the building is saved with this file) and than with container closed (building is saved in .maxc file). that was just a precaution in case of corrupted file - .maxc is always overwritten. nothing bad happened though. containers were used in 'edit in place' mode - can be edited by only one person at the time, you can even see a tag next to container who is editing right now or that you need to update the container if it had some changes applied.

xref materials - you can only apply those if object is already part of the container. adding such object is no go. you change xref mat for something else, add object to container and than reapply xref mat. for that you need separate scene - like a mat library - boxes with materials an uvw. to edit this scene you merge the boxes to the main scene, edit and than 'save selected' to the material scene. next trick - after you click the material scene file to save - you need to manually delete this file. and than continue with save. 2016 have xref mats that can lead to your current scene so I presume its easier now. to edit materials I used main scene - just replace xref mat on object in container for mat from merged boxes, edit and resave file with materials.

containers are easy to load/unload if viewport is too slow. there are also proxies for containers with low poly versions of buildings, sometimes useful.

teamwork is easy. you always have info whats going on with every container (tag next to container or container explorer)

containers in 'edit in place' mode leave little files next to .maxc files to mark is as locked. sometimes you must delete them manually when max crashes.

instancing is no problem - two containers can lead to one .maxc, can be mirrored etc.

remember that asset collecting scripts will move your .maxc file as well.

[flino2004]

I would use Xrefs for sure....optimized buildings, Xrefs per zones for landscaping, entourage and sitework.

[YoyoBoy]

Don't just use x-ref objects, use x-ref scenes. And in the x-ref dialog you can link x-ref scenes to dummy objects so that you can place them wherever you want. And you can even import multiple copies of the same scene and place them around. This way you don't have thousands of objects clogging up your Selection Floater (though the objects will show up in other listings).

[glorybound]

I guess I should spend some spare time and learn more about what you guys have mentioned (haven't had a minute all year). This is the project that had no drawings, I did everything from napkin sketches, and he just dropped the landscape plan on me this week. I mean crazy! I am almost half way and I am talking thousands and thousands of plants and trees. All the plants and trees are proxies; it's the buildings that are slowing things down. With the vegetation, I turned off visible to GI and lowered the GI subdivs. Also, I turned reflections off on all vegetation. This 4k proof took about 2 minutes.

[rusteberg]

With the vegetation, I turned off visible to GI and lowered the GI subdivs. Also, I turned reflections off on all vegetation. This 4k proof took about 2 minutes.]

I wouldn't do that.... the buildings are slowing down the gui or the frame render times? if it's your gui that's lagging due to the buildings, then start with your balconies and repetitive point groups - put those on layers and hide while working on the scene (I'm guessing your balcony railings are groups of extruded splines that are instanced over and over again - seems rather simple but....) When you force a 4k render down to that frame time then you're undoubtedly going to pay for it in quality.

Here's a mixed use commercial/residential I did earlier this year - No proxies, no xrefs, no containers and it's all geo that pulled close to 64 gigs of ram at render time (without the cars it pulled around 24). There was an animation that went along with it. A large development company commissioned the work, a large architectural firm whose name starts with a G did the commercial buildings, a landscape architect did the master site, and three separate residential developers did the homes and not a single party knew what the other was doing at just about every step of the process - One dude with a pen and a bar napkin sounds like a pretty good deal - It can be done

[glorybound]

Sweet! I'll have to dig into why the building are slowing things down. I would have expected the landscape would have been the problem. It's the view port that is slow with the buildings, even when they are hidden.