If you want to delete a layer from the SE, the most efficient way is to use the RMB quad in there and choose 'Delete Layers and all children'. Just pressing Delete or using Delete from the quad will unnest layers and reshuffle hierarchies, which can get messy with many layers/hierarchies.
Announcement
Collapse
No announcement yet.
3DS Max - deleting objects takes forever
Collapse
X
-
You can also try gc() in the listener window to clear the undo stack after each delete operation (CAUTION!) which could help to speed things up a little bit. A bit like the solution above which is suggesting to use a script that disables undo.
Comment
-
Okay, maybe te issue is related. Sometimes when certain windows are open, like the schematic view, some operations like delete can take ages. Maybe it is the same when the scene editor is open? Never tried it, becauce I rarely use scene editor. Might be worth a try to close it before deleting.
Comment
-
Actually I'm using the Scene editor that is located on left side on the default 3DS Max UI. So no windows were used.
Same thing happens with dope sheet. It cannot be used with scenes having thousands of object, because it will take forever to open it and also when opened and another forever to open the key edit dialog. Editing keys in the time line is the only way to go.
Comment
-
I have similar case. I'm working on a factory layout, where I need to replace one conveyor. The old conveyor had more than 3 000 objects. After hours of waiting, I let it work overnight and in the morning the conveyor was gone. Now I'm merging the new conveyor consisting of more than 5 000 objects. Max has merged it for hours. I hope it's ready during the weekend so I could start preparing the scene for rendering during next week. With my luck, the system decides to do an OS update, once the conveyor is merged, but not yet saved.
Comment
-
Use DangCollapse script. Merging 5k objects will take few minutes.
Comment
-
Maybe a little late for the party, but: since I have been using SINI tools, when using tools operating on large (5K+) number of items, me was told not to leave any window open that potenially could show all the items in the scene, whether that's Scene Explorer, Schematic View, Material Browser or Editor. They all slow down any action on lots of objects substantially. So just select the objects, make sure all these windows are closed and push delete (or attach or any other action involving lots of objects). Ever tried to type in a name in the search field of the non-modal Selection Dialog when there are 20000 objects in the scene? Then you know how antique some tools are in Max
Comment
-
Thanks,
I checked, there is no windows open during merge operation. What comes to search function, yes I know it's very slow when typing. When assigning materials to objects, I use copy-paste a lot. I might choose one bearing for instance. The I copy the name of the bearing object and paste it to search dialog. Now I have all the bearings selected and I just assign my bearing material to all of them at once.
Also it's important to have objects instanced, This helps a lot with those objects using multi/sub materials. You just define the face IDs for one object and the material fits correctly.
Comment
-
What comes to collapsing objects, I don't do that. I have noticed, after collapsing geometry some former objects are rendered black. Something is obviously happening to the model topology. When I detach the defected geometry element by element they are rendering again normally. When attached there's nothing I can do on element level to heal the geometry. Detaching is the only way.
Comment
-
What do you mean with "collapsing" ? If you mean "attaching" lots of elements|, just be carefull to use 3rd party tools. All of them (including the SINI tools) are not correctly handling multisubobject materials when attaching. The most (and IMO only) trustworthy one is the MAX-native attaching....but that is also the slowest one.
Comment
-
Thanks for the correction. Anyway I wasn't referring multi/sub material when I wrote about black geometry. Often, when attaching many objects together, I have seen, that objects do not render correctly anymore. First I thought it was a facenormal thing, but healing face normals didn't fix these problems. I have heard that Mirror is not standard CAD-command so mirrored geometry is often poorly interpreted by translators. The geometry may render fine as it is after translation, but attaching geometry might bring the problems visible. Only way to fix these for me has been detaching the defected geometry.
So in the first place to avoid any problems, it's better not to attach CAD objects together. However, it has been said that 3DS Max becomes extremely slow when the object count exceed 50 000. For Maya this is said to be 90 000 objects. So we have a problem. One way to avoid this is to use XRef scenes. Max seems to be working faster that way. However I usually get the CAD models in one several GB file.
Comment
-
Thanks,
I used this approach late 90's when computers were much slower. It has some advantages and disadvantages. The disadvantage is, that it increases the workload a lot. I find a huge timesaver if I have full scene editable at once. I can assign materials to thousands of objects with one copy-paste operation. If I broke the scene, I would need to do the same in each scene separately. When properly instanced it's easy to assign multi/sub material to a large amount on objects by editing just one object.
No one is stupid. People have reasons.
Comment
-
Originally posted by T0ofic View Post...This forum is a joke...I don't see what xrefs would help when deleting lots of objects is taking forever. You could save selected the objects you need and load them back in seperately so you wouldn't need to delete the other 40K, but therefore you don't need xrefs. It's never a good practice to have an excessive amount of objects in your scene, even if they are in the form of xrefs, proxies or whatever. It will always slow down actions in viewport or background (even when hidden) and renders to initialize and just forget about IPR.
Comment
Comment