I’m guessing that the epoly mod is storing the number of verts in the turboSmooth and when dragged below is not updating something. Maybe it still is holding information about those extra verts.
I think that’s a good assumption, Paul. I sent a bug report with reproducible steps to Autodesk, so hopefully that’ll be patched up.
Just saw this thread now. I was running into this bug all the time back on Pinky. It drove me nuts! Luckily haven’t seen it much since then. I feel your pain Jay. Try to hold back the tears.
I wish I had known about the resumeEditing() earlier. That will come in handy in the future. Thanks for the tip Bobo!
Just a thought on this whole “order of the modifiers” business. I don’t really know whats going on behind the scenes with Max’s modifier stack, but often times when wiring into morpher modifiers I notice that there can be several teirs of “Modified Object” that I have to go through. I have always assumed this is just because at one point or another I’ve copied modifiers from into the middle of the stack of the node with the morpher on it and it causes it to do something funky in the background. I wonder if something like this multiple “Modified Object” deal is causing the problems? I just tested the wire parameters dialog after the steps you’ve provided Jay, and what I am describing seems to be happening with your example.
Just thought I’d add that it seems this is re-creatable using any combination of modifiers. There is no significance to Turbosmooth, Edit_Poly and Point_Cache. I have been able to do it with Bend, Twist, Mirror, Flex, and NormalModifier. Seems like its a problem with moving modifiers down the stack in general and has no relevance to the modifiers themselves.
Something else that is interesting, as soon as I add a 3rd modifier to the mix the problem no longer exists when moving the top modifier down one spot. It does happen again though when moving it down 2 spots so that it goes from the top of the stack to the bottom of the stack. To get the issue to re-create you have to add the modifier through script to the spot just above the baseobject, so if there are 3 modifiers you have to specify before:3. This tests true with 4 modifiers, and it doesn’t have to be the top modifier moving to the bottom of the stack, it just has to be any modifier that wasn’t previously at the bottom of the stack. So, if you have 4 modifiers you can move the 3rd modifier into the spot just above the baseobject and it will again re-create.
Also, in all of these situations where the error is getting occuring, the same thing happens again with the wire_parameters that I explained in my previous post. You can right-click, go into the wire parameters macro and in the “Modified Object” sub-menu there will be a few of the modifiers, then another “Modified Object” sub-menu. My guess is that maybe they’re watching for when a new modifier is added at the spot just above the baseobject, and when that event triggers they create a new modifier stack for the node. Try this…
[ol]
[li]Create a sphere
[/li][li]Add 4 modifiers
[/li][li]Drag the top modifier to the bottom of the stack until the order is the same as it originally was
[/li][li]Right click to bring up the quad menu, and then go to wire parameters/modified object
[/li][/ol]
After these steps there should be a new “Modified Object” level for every modifier in the stack. You can now re-create the issue when trying to add a modifier through script before any index other than 1. When adding before:1 I guess it is still adding to the top most modifier stack, which it doesn’t have a problem with.
When dragging a modifier to the bottom of the stack, it doesn’t check that there are already modifiers applied or something. Just as long as a modifier is being added just above base-object, it creates a new stack. Then having these nested stacks is somehow causing the issue. Just a guess because I still don’t really know whats going on behind the scenes, but seems pretty solid.
how about creating the object adding the modifiers to this object then creating a copy of this object deleting all the mods from the copy, then copying the modifiers from the original object to the copy which will happen in reverse (because stack is a LIFO structure) and then applying the point_cache before:2 … doesn’t give any system exception [lol maybe the code will make clear what i am trying to say] :
myobject = sphere radius:10 segs:32 wirecolor:black name:"sph"
objname = myobject.name
addmodifier myobject (turbosmooth())
addmodifier myobject (edit_poly())
mycopy = copy myobject
for i = 1 to mycopy.modifiers.count do (deletemodifier mycopy 1) -- you could make the copy before adding the mods to original object as well but ...
for mods in myobject.modifiers do (addmodifier mycopy mods)
addmodifier mycopy (point_cache()) before:2
delete myobject
select mycopy
mycopy.name = objname
then again i do not know in which context 1 would need this … so i am not sure this will help anyways … cheers!
I’ve run into this a few more times since, so have put a bit more time into playing around with this. Here is a function for adding a modifier to a node’s stack, safely. It will attempt to add to the “before” index you specify, but if it will throw an exception it will instead add the modifier to the lowest index possible and format data to the listener notifying you there was a problem.
-- Adds modifier as low in the stack as possible, without throwing exception.
mapped fn addModifierSafely obj theMod before:0 collapseStack:false =
(
isCorrupt = false
before = obj.modifiers.count
if (before > 1) then -- Stack only corrupts with 2 or more modifiers.
(
corruptIndex = findItem (getSubAnimNames obj[#modified_object]) #modified_object
if (corruptIndex != 0) then
(
isCorrupt = true -- Flags stack as corrupt.
before = corruptIndex - 1
corruptMod = obj.modifiers[corruptIndex]
format "Corrupt stack on %. Modifier added at index %. Please address the stack manually.
" obj.name before
format " Corrupted modifier info: Index:% Class:% Name:%
" (corruptIndex+1) (classOf corruptMod) corruptMod.name
format " select $%
" obj.name
)
)
addModifier obj theMod before:before
if collapseStack and not(isCorrupt) then
(
maxOps.CollapseNodeTo obj (before+1) true
)
)
Some more strange things I have found when playing around with this:
Similar to how when you have a corrupt stack you will see a number of levels of modified_object in your wire parameters menu, evaluating “getSubAnimNames $[#modified_object]” will return another #modified_object inside. You can then grab the 2nd level modified_object by evaluating “$[#modified_object][#modified_object]”. The more corruptions you have, the more nested #modified_objects you will find.
Evaluating $.modified_object on a non-corrupted node will throw an error. However, if the node’s stack is corrupted it will not throw an error and instead will return the 2nd level modified_object (you can see the modifiers by evaluating “show $.modified_object”). This makes for a good way to quickly check if you will run into any system exceptions when attempting to use addModifier on the collection of nodes. “for x in selection where (isProperty x #modified_object) do (format “Modifier stack corrupted on %
” x.name)”.
As with any other subanim, you can check the parent of the #modified_object. Evaluating “$[#modified_object].parent” will return the host node, since this is the 1st level modified_object. Performing the same on the 2nd level modified_object, “$[#modified_object][#modified_object].parent”, will return “ReferenceTarget: DerivedObject”. Checking this object’s scene address using exprForMAXObject returns the same path as for the host node. Checking the classOf for this object returns DummyClass, and checking superClassOf returns Unknown.
Thats where I hit the wall. It would be easy enough at this point if you could feed $[#modified_object][#modified_object] to the addModifier method so it adds to the 2nd level, but it will error on anything other than a node. I can’t figure out anything better than the function above, which is just making the issue a little easier to deal with. If you have 200 nodes with corrupted stacks, it is still going to be a major pain to deal with, unfortunately. Hopefully it will help to make some people’s lives a little easier though.