addModifier before system exception

[SoLiTuDe]

Hey Jason... *shakes fist* ...I tested it on my laptop for you, and I didn't have an issue in (Vista) 2010 64 bit.

Edit: I don't have 32 bit installed on this machine... :D

[Bobo]

This starts looking like a Prime Focus channel...

Anyway, it does indeed cause system exception in 32 bit Max 2010.
Does NOT do that in 64 bit though.

Also, to "repair" the modifier panel, just call
resumeEditing()
as it has been suspended in the process.

[SoLiTuDe]

^ Prime Focus For the Win!

...Jason, as a workaround you could maybe make instances of the top two modifiers in memory, remove them from the objects, add your pointcache, then reapply the top two modifiers...?

See ya tomorrow! :D

[labbejason]

...Jason, as a workaround you could maybe make instances of the top two modifiers in memory, remove them from the objects, add your pointcache, then reapply the top two modifiers...?

.... Farnsworth!! Was thinking the same thing. I'll give that a try.

Also, to "repair" the modifier panel, just call
resumeEditing()

Thank you!! I restarted Max many many times today because of that.

Keep it real, PF folks.

[Bobo]

Possible solutions:

oldState = $.modifiers[2].enabled
$.modifiers[2].enabled = off
addModifier $ (point_cache()) before:2
$.modifiers[2].enabled = oldState
select $

or

oldSel = $
clearSelection()
addModifier oldSel (point_cache()) before:2
select oldSel

or

max create mode
addModifier $ (point_cache()) before:2
max modify mode

[labbejason]

Unfortunately each of those returns a system exception. So far I only got Ian's approach working by rebuilding the stack (fun!).

Here's something interesting though. It seems like it's all in the ORDER of how the modifiers are added in. For example, if you add an edit_poly THEN the turbosmooth, there won't be any system exceptions. However if you add a turbosmooth then an edit_poly, move the edit_poly below the turbosmooth, it'll cause it to error.

[Bobo]

Unfortunately each of those returns a system exception. So far I only got Ian's approach working by rebuilding the stack (fun!).

Here's something interesting though. It seems like it's all in the ORDER of how the modifiers are added in. For example, if you add an edit_poly THEN the turbosmooth, there won't be any system exceptions. However if you add a turbosmooth then an edit_poly, move the edit_poly below the turbosmooth, it'll cause it to error.

I posted them because they worked for me, but it is possible that I created the modifiers in the wrong order as you mentioned above...
Oh well...

[labbejason]

I'm thinking that's what may have happened too. Sneaky sneaky!

[PEN]

Don't they let you Prime Focus guys talk to one another at work? You need to sneak out to the internet to do it.

[SoLiTuDe]

Well, I can talk to Bobo via jabber, but that Jason guy is nothing but trouble. They keep him locked up in the corner for a reason. :D

[PEN]

He was one of my students so I may have caused that..sorry.

[SoLiTuDe]

I suspected as much... :curious:

[labbejason]

I'm only allowed to have a 5 minutes 'stretch time' per day. Uh oh, I hear the boss coming! I better go or it'll get reduced to 2 minutes.

[labbejason]

A quick update on this. Trying to copy the modifiers and rebuild the stack causes a lot of problems when they are reapplied to the object (skin weights wiped out, vert count changes from edit poly mods).

Instead, you have to get the index of where you want to place your modifier, then with the modify panel open, use modPanel.addModToSelection.

Long day :(.

[cyfer]

2010 32bit xp32
works fine and no problems here !

[labbejason]

Did you add the turbosmooth first?

[cyfer]

the stack looks like this and this code executes with no problem

s = Sphere()
f = Edit_Poly()
t = TurboSmooth()
addmodifier s f
addmodifier s t
addModifier s (point_cache()) before:2


i had to change the $ with the variable cause i didn't select anything
but as your first post goes ... i didn't get any exceptions when i created things manually

one thing happened though , when i put e = Edit_Poly() i get

-- Cannot assign to read-only variable: e

[labbejason]

You have to do it in the right order, which is weird. I just got it to error on my home machine, try this:
- Create a sphere
- Add a turboSmooth modifier
- Add an edit poly modifier
- Move the edit poly below turboSmooth
- Execute : addModifier $ (point_cache()) before:2

This should cause a system exception. If you simply apply the edit poly first, then add a turboSmooth, it won't crash (even though both result in the same stack).

[cyfer]

I confirm !
modifierstack now shows nothing even for a newly created objects
you can get over this "if you have it" by resumeEditing()

[HornBerger]

another interesting thing to note:
if create the sphere add the turbo smooth modifer then add the editpoly on top like jason said then move the turbo smooth modifer on top which you do in 2 ways :
a) either drag the turbo smooth modifer up
b) drag the edit poly modifier down
if do it by method a) then execute the command addModifier $ (point_cache()) before:2 there is no system execption but if do by method b) then execute the command addModifier $ (point_cache()) before:2 theres system exception

Lol theres should be a book on mysteries about max ;)

[PEN]

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.

[labbejason]

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.

[Mathieson]

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.

[laszlosebo]

I'm only allowed to have a 5 minutes 'stretch time' per day. Uh oh, I hear the boss coming! I better go or it'll get reduced to 2 minutes.

no worries jason, we will just reduce your pee time by a couple mins.

[Mathieson]

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.

[Mathieson]

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..



Create a sphere
Add 4 modifiers
Drag the top modifier to the bottom of the stack until the order is the same as it originally was
Right click to bring up the quad menu, and then go to wire parameters/modified object


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.

[HornBerger]

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!

[Mathieson]

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.\n" obj.name before
format "\tCorrupted modifier info:\t\tIndex:%\t\tClass:%\t\tName:%\n" (corruptIndex+1) (classOf corruptMod) corruptMod.name
format "\tselect $%\n" 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 %\n" 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.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.