How to instance groups of objects

[nils.deitmers]

Apologies for the vague question.
This is one that has been bothering me for years, so I'd like to learn if there's a trick I missed...

I find myself working with identical groups of objects all the time, like e.g. robot arms or car engines.
The goal is usually to instanciate the objects, while being able to treat them as one logical unit, but in a non destructive fahion, maintaining all modifers and transforms.

Obviously an almost ideal workflow would be to group the objects, while also instancing the controller. If it wasn't for the one big flaw that you can't add any new objects to a group instance. 
So if you were modeling a robot arm you'd have to regroup and instance it for every screw you decide to add.

Creating a boolean object is another way to do it, but I find this too laggy and cumbersome to work with.
I'll usually create references from my objects and create a boolean from those. So I can continue working on the objects, keeping a turbosmooth modifier above the reference line to enable for preview without affecting the boolean.
This is also not really convenient, since the performance is really bad, even when moving operands with relatively simple geometry.

Is there really no way to work with a bunch of objects that update as a group in real time?

[RobH2]

What version of Max are you using? In Max 2025 you 'can' add a new object to a Group instance. Make a group and drag it over to instance it. Then click on an object outside the instance and under 'Group' click 'Attach' and the object will be added to the Group. You mentioned that being able to add an object to an Instance was ideal, and you can do it. 

[nils.deitmers]

Hi RobH2, thanks for the hint!
I was on 2024 but did the update and now I'm on 2025.

Maybe I was unclear on what I'd expect to happen:
Adding objects to existing group instances has been possible before. But the other group instances in the scene will not update. So effectively the groups are not the same anymore. Adding a new bolt to a guitar's machine head would require adding it manually to all six group instances.
This still seems to be the case in 2025, unless I misunderstood?

Also.. I did some testing with groups and it turns out they're only ideal when I intend to place them by hand.
The array modifier (set to radial) would always create individual rings of objects using their local pivot as a center instead of the group pivot.
Applying the array mofifier to a container also won't do anything at all. (The update behavior of containers is basically how I would imagine instanced groups to work.)

So the "ideal" workflow for my situation would be one where I can really instanciate and manipulate a group of objects as one logical object, while still being able to easily work with the individual objects.
(So far booleans are still the only way I know, but as I mentioned they are not really great to work with due to the laggy performance and finicky selection of objects)

I'm surprised this particular workflow is so cumbersome, as it seems very common. In technical applications we come across the need for arrays of groups all the time. 
When the array modifier came out it really made my day. In many cases I can compromise and manage with a single object for the array. But sometimes it's just desirable to have diferent chamfer or turbosmooth settings on mechanical parts, some with symmetry, some without etc..

 

[RobH2]

I see. You have such a specific workflow I'll be interested if you find something that works for you. Post back here if you do so others can take advantage of what you figure out. 

[mbreidt]

Some additional options that maybe are worth a shot:

• Object Xrefs
• Substitute modifier
• Mesher (works also with groups!)

[nils.deitmers]

Thank you for the suggestions. Did you successfully try any of them?

The mesher and substitute modifier both let you pick individual objects out of a group (even out of a closed group), but they do not seem to allow to pick multiple objects at all.
Can you explain what you mean by "Mesher (works also with groups)"?

Again: the idea is to have an arrangement of objects and repeat that in different places in the scene. To extend the examples I gave before: let's think of a dinner plate with a knife, a fork and a spoon next to it.
If I group these objects, create a mesher compund object and "pick object" the mesher will pick just one object out of a closed group and turn into that one object.
Same for the substitute modifer. Picking an object from the scene has the same effect and does not allow picking more than one object. "Select object by name" does also not work on groups. If you try to select a group it will ignore the input.

[nils.deitmers · Accepted solution]

I actually remembered a 3rd party tool that I used to work with 10 years ago.
It's called MultiMesher and it does exactly what I 've been describing, plus some boolean operations if you want.
The interface is incredibly simple and fast, in a way the boolean modifier is not.
You can just pick the objects you want to be part of the mesh and that's it. You can continue to work on the original objects, move them around in real time and tweak the relative position in the MultiMesh.  You can use the MultiMesh with the array modifier, no problem.
You will want to adjust the pivot of the new mesh, since the objects you pick initially have their world position as an offset relative to where you put the MultiMesh object.
But compared to working with the boolean tools this is a breeze of fresh air. 😉 


I honestly don't know if there's any limitations that I'm not aware of, or if this workflow of mine is really so specific, but it is beyond me why something like this seems to be considered "nioce to have". I think Autodesk should have bought it years ago.

https://www.kinematiclab.com/products/multimesher

[mbreidt · Accepted solution]

---

@nils.deitmers  schrieb:

Thank you for the suggestions. Did you successfully try any of them?

The mesher and substitute modifier both let you pick individual objects out of a group (even out of a closed group), but they do not seem to allow to pick multiple objects at all.
Can you explain what you mean by "Mesher (works also with groups)"?

---

Mesher lets you pick the "head" of a group (which contains multiple objects), see the attached .max file (R2023).

If you open it you will see four sets of cutlery. Select the pink spoon and enable/change the Twist modifier -> this will update all the green mesher objects, too.

So you can change one object within an (opened) group and all the other "instances" will follow.

The only limitation I am aware of: Any transforms will need to be done through an "Xform" modifier, as the mesher seems not to update on simple PRS changes.

Does that help?

[nils.deitmers]

Thanks for taking the time to provide this example. I appreciate it.
You're right!
It never occured to me that I have to open the group to pick the header. That's rather confusing UX, since clicking on an object in the group selects the group and not the object. So if group headers are pickable then it seems logical to pick the header of a closed group and require opening it to pick an object inside. Not the other way around.

But yes, glad I understood this now. It's always good to have a workflow that doesn't require managing 3rd party stuff.

[mbreidt]

---

@nils.deitmers  schrieb:

It never occured to me that I have to open the group to pick the header. That's rather confusing UX, since clicking on an object in the group selects the group and not the object. So if group headers are pickable then it seems logical to pick the header of a closed group and require opening it to pick an object inside. Not the other way around.

---

I agree, this is not great UX, but IMO that is true for groups in 3ds Max in general, where 3ds Max often tries to be clever about those group heads (and sometimes fails).

I would generally recommend to avoid groups in 3ds Max where possible, but in this instance they are actually useful.

IMHO the cleanest way of doing what you want are probably Object Xrefs (or Proxies) - but you would have to open a second 3ds Max session if you want to edit them (and would have to do that without context).

Containers should, in principle, also be able to do what you want - and they even allow you to "open" them, do some edits and then save again (and all other references to that container file will update) without leaving your scene.

BTW, thank you for the like/acceptance as solution!

[nilshenning.deitmers]

Yes, I agree with your comment on groups.

as for xRefs.. the editing without context is indeed a big downside. They don’t feel like a convenience tool, but more like sth you’d use for organization or if viewport performance becomes an issue I guess. So the multimesher is really like an xRef you keep in the same scene.

and I‘m certainly going to use it more now.

In my opinion it is one of 3ds max‘s strengths to allow for a nondestructive modifier based workflow.

So when I model things like a spaceship engine it seems intuitive to use lathe objects in combination with radial arrays etc and keep them uncollapsed. And when there’s more than one engines it is obviously desirable to have instances of the complete engine that can be polished and extended without breaking the instance. 

I checked out containers only briefly and they seem to offer just that. Being able to edit them in place is even more intuitive than any proxy solution,  unfortunately I couldn’t get them to work with the array modifier, which is required in my current scene.

[nils.deitmers]

Just a quick comment on performance, now that I'm testing the Mesher compound object vs the MultiMesher in the context of my actual scene:

Toggling a Turbosmooth on and off on the original mesh takes 2-3 seconds (!) to update the Mesher. Needless to say that's not an option. Also enabling a chamfer modifier on the source mesh makes the Mesher disappear entirely, not sure why. 
With the MultiMesher toggling the turbosmooth doesn't cause so much as a hickup, the chamfer works as expected and no need for extra xForm modifiers.
It also exports fine to Unity and Marmoset Toolbag, so I can recommend it.

[mbreidt]

Thanks for the update! Too bad Mesher isn't really up to the task. Sounds like some of this could worth a bug report.

Glad you found an alternative, even though it is a 3rd party plugin, so it needs to be re-released for any new version of 3ds Max.

Edit: I was curious and did some tests - it seems as if the Array modifier is slowing things down so massively with Mesher. An Array with 100 copies takes several seconds to update, but changing 100 instances works instantly.

I did not encounter any issues with chamfer modifier but that might just be lucky.

Edit2: I just realize that MultiMesher is a MAXScript plugin! Very nice, well done Clovis! That makes it quite resistant to all those version upgrades. But here I do not see a noticeable speed difference between an Array of Meshers of a group and an Array of MultiMeshers of the same objects:

• Repeatedly turning TurboSmooth on and off for a 100-Array of Meshers of a group takes 4.1 sec per run.
• Repeatedly turning TurboSmooth on and off for a 100-Array of MultiMeshers takes 4.2 sec per run.
• Both Array variants have 76k polys without TurboSmooth, and  643k polys with it (using 3 iterations)
• For comparison, doing this for 100 instances of the Mesher (no Array) takes 1.5 sec per run.
• Without the Array, one run takes 0.08 sec
• All times averaged across ten-fold MAXScript loop, with all 100 copies visible in the viewport 

[nils.deitmers]

Thanks for taking the time to do these tests. It’s always good to be more empirical to backup observations.
You're right, the array modifier does slow things down quite a bit. Creating more than the same number of instanecs by hand does not lead to a performance impact at all.

As for the speed difference I observed between Mesher and MultiMesher.. my setup was a bit different from yours:
I fed the turbosmooth into the Mesher and MultiMesher. (no arrays involved) At 1 iteration the performance difference was noticable, but not huge. At 2 and more iterations the Mesher's processing time went up to 3 seconds and beyond, while the MultiMesher was still doing it in real time. 
Also: modeling with "Edit poly" on one of the source objects has a stuttering, delayed performance if the Mesher is involved, it's real time with the MultiMesher.

The issue I mentioned with the chamfer modifer now happened with other modifiers too, toggling a turbosmooth or symmetry modifier before the Mesher can sometimes prevents it from meshing the result. Right now there's only one out of four objects in the group that doesn't break the Mesher by toggling certain modifiers.
Also just moving a single vertex in an Edit Poly can break it.
Good point. I think I'll provide this mesher and group and file a  bug report.

After working with MultMesher for some time now I noticed that it (randomly?) triangulates some quads (), resulting in undesirable results whith turbosmooth after the MultiMesher. But since it doesn't have an issue processing turbosmooth I can use it before the MultiMesher.

The things we do for science 😉
Thanks again for sharing your results!

[mbreidt]

---

@nils.deitmers  schrieb:

I fed the turbosmooth into the Mesher and MultiMesher. (no arrays involved) 

---

That is what I did, too.

The base setup was: 2 x Editable_Poly -> Group -> Mesher -> Array(100)     versus       2 x Editable_Poly -> MultiMesher -> Array(100) 

The I added a TurboSmooth modifier on top of one of the Editable_Poly with iterations = 3 and turned the modifier on/off in a MAXScript for-loop with a full screen redraw while measuring the elapsed time.

Your setup seems to have something that mine does not - would it be possible for you to post a simplified scene that shows this issue?

[nilshenning.deitmers]

The model I was using is for an unreleased game. I had to change it, so it looks different enough.
After doing that some issues were accidentally fixed, like the edit poly that broke it just by modeling, but adding another chamfer for no reason other than to show the broken mesher worked.
You should have a scene now where enabling turbosmooth takes a while to update on the Mesher while it is instant on the MultiMesher.
(For what it's worth: exporting the mesh revealed there is a rats nest somewhere that may be part of the issue.)

[mbreidt]

---

@nilshenning.deitmers  schrieb:

The model I was using is for an unreleased game. I had to change it, so it looks different enough.
After doing that some issues were accidentally fixed, like the edit poly that broke it just by modeling, but adding another chamfer for no reason other than to show the broken mesher worked.
You should have a scene now where enabling turbosmooth takes a while to update on the Mesher while it is instant on the MultiMesher.
(For what it's worth: exporting the mesh revealed there is a rats nest somewhere that may be part of the issue.)

---

Thanks for the scene file.  I can reproduce the problem with Mesher becoming very slow if TurboSmooth is on. It looks a bit like Mesher on a group is doing some extra steps that increase non-linearly with the number of verts/faces in the source mesh! It does not do this on the same object if it is outside of a group.

And I can reproduce this with a much simpler scene (three boxes in an open group, with one TurboSmooth). Which is great as I can now submit that to Autodesk in a bug report!

[mbreidt]

In fact, this performance problem becomes much worse if you add more objects to the group, even if they have almost no geometry.... 

Bug report filed.

[mbreidt]

Two more comments:

1. I do see the Mesher object disappearing, which looks like a (unrelated) viewport bug. If this happens and I hit render, the mesher is correctly rendered and also reappears in the viewport.
2. Just a thought but it would probably much faster to apply TurboSmooth on top of the Mesher, or even on top of Array. Of course this will only work if your entire group can use the same TS settings.
   
   Edit: Just tried it, and yes it is MUCH faster to do Mesher > Array > TurboSmooth than to do Mesher > TurboSmooth > Array - almost ten times slower on your test geometry!

[nils.deitmers]

Thanks a lot for your bug report and for helping with this in general!

I can confirm your "workaround". Rendering does bring back the viewport display. It's not really solving much for me, because for as long as I'm working on the meshes the erratic display is a show stopper.
Probably the Mesher was never intended to be used this way. I can see this being a minor issue if you only really use it for rendering an already finished scene.

I realized another "limitation" of the Mesher that I hadn't noticed before. It doesn't just attach meshes, but it performs a boolean operation, so I can't have overlapping geometry, especially if the turbosooth is on the Mesher, since it's probably going to create artefacts or smoothed out areas . This operation may even have sth to do with the display error, since moving one of the objects into overlapping another is a sure way to trigger it. (It can also provoke a crash, as I just found out ^^)