[Closed] Script written for Max 9 running slow/crashing in Max 2009

Not that I know off. Any chance you could post the code?

I’ve isolated the problem to this point:

fn Set_Matte o color luma =
(
– Create the matte material
local mb = standard shaderType:1 diffuseLevel:0
mb.ambient = color
mb.diffuse = color
mb.specular = color
mb.specularLevel = 0
mb.selfIllumAmount = luma
mb.selfIllumColor = color
mb.twoSided = true

                -- Assign it to the object
           [b]o.material = mb[/b]

) – End Set_Matte ()

The last line (in orange, assiging the material (mb) to the object(o)) is where it screws up.

The function simply accepts an object and a color/luma value with which it creates a material. It then assigns that newly created material to the object (o).

This is being called in a loop that iterates over every object (about 1158 in the scene file I’m testing). Like I said, I’ve run this exact script in Max 9 on the same file a million times, but it’s suddenly hanging in Max 2009.

I may have found a semi-solution.

It seems that the problem isn’t so much assigning the material to the object, but assigning a material created as a local within the function. Presumably there’s an issue with the material being created on the stack.

As a result, I made “mb” a global and only changed its parameters inside the function. So nothing new is being created at each step; a pre-existing material object is simply being modified and re-assigned.

The problem is, this means each object has the same material, so they all end up with the same properties (obviously not my intent, since the function accepts color/luma parameters).

To temporarily solve the problem, I’ll be creating pre-made versions of each unique material, all of which will be globals, and assigning them as necessary. The problem, though is that this doesn’t allow true flexibility, since I can’t create arbtirary materials for each object if necessary.

The problem in 2009 seems to have something to do with materials being created on the stack beyond a certain amount, as opposed to the global heap. Does anyone (Bobo?) have any information on how memory management has changed between 9 and 2009?

Thanks.

By “screw up” I simply mean the script begins to run slowly and eventually hangs the program.

I did a search and found another user with the same problem. Unfortunately, he posted his question about 5 months and has yet to get a response. I hope I’m not in uncharted territory here, as this script is rather vital to my work.

• The garbage collector has been automatically invoked by this script on a number of occasions while running under Max9, which never caused more than a brief pause (“mx gcs” appears in the status bar, like you said). In 2009, the behavior is totally different; it’s running extremely slow from the start, and eventually slows down so much that the program hangs. So while the garbage collector may still be involved, it’s not the traditional case of it being periodically invoked.

• Thanks for the tip on undo off, though. The script is in fact creating all these materials within an undo off () block, so I’ll experiment with that next. However, this does bring me back to my original question about how the memory manager has potentially changed between Max9 and 2009. Since again, even with the undo off () block, it runs fine in Max9 (and I would like to maintain the undo functionality).

Thanks Bobo.

How slow does your function work? On my machine for 1500 objects it takes 22 secs to create unique standard material and apply it. It sounds reasonable for me.

since max 2008 they (max developers) changed something in material’s library code. After that append, deleteItem, and findItem functions for any material library (including [color=red]scenematerials) work very slowly. Append works slowly because they check mat for uniqueness before add it to a library. Why deleteItem is slow I have no idea. [/color]

since max 2008 they don’t clean scenematerials from materials are not applied to any node.

And you can append any material to scenematerials… (!)

I don’t know is it the bug or a feature. But definitely it’s a stupid feature.

here is a simple test:

for i=scenematerials.count to 1 by -1 do deleteItem scenematerials i
for i=1 to 10 do
(
 t1 = timestamp()
 for k=1 to 100 do append scenematerials (standard())
 format "time:% mats:%
" (timestamp() - t1) scenematerials.count
)

you will see how the adding new materials slows and slows down…

can any one run this test on MAX8 or MAX9, please? I don’t have max versions lower then max 2008…

Max9:
time:188 mats:100
time:265 mats:200
time:360 mats:300
time:469 mats:400
time:609 mats:500
time:703 mats:600
time:828 mats:700
time:1031 mats:800
time:1204 mats:900
time:1437 mats:1000

Max9
time:297 mats:100
time:563 mats:300
time:922 mats:500
time:1750 mats:700
time:2562 mats:900
time:2829 mats:1000

Max9 x64
time:219 mats:100
time:484 mats:300
time:891 mats:500
time:1422 mats:700
time:1796 mats:900
time:2000 mats:1000

Max 2009 x64
time:141 mats:100
time:406 mats:300
time:812 mats:500
time:1407 mats:700
time:1797 mats:900
time:2125 mats:1000

Interesting… Dual Pentium D, 3Ghz, 4GB ram, XP64