PDA

View Full Version : Script written for Max 9 running slow/crashing in Max 2009


amv256
09-19-2009, 02:02 AM
I've recently upgraded from Max 9 to Max 2009, and a script I wrote for version 9 is no longer functioning.

The script loops through each object in the scene and applies a new material to it. As it does this, it updates the status bar so I can watch the progress.

In max 9, this runs relatively quickly. Running it on the exact same file/object set in 2009, it's running extremely slowly and eventually causing the program to hang before even reaching the halfway point.

Are there any common pitfalls when migrating scripts from v9 to 2009 that I'm missing?

Thanks!

MarcoBrunetta
09-19-2009, 02:13 AM
Not that I know off. Any chance you could post the code?

amv256
09-19-2009, 02:59 AM
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
o.material = mb
) -- 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.

amv256
09-19-2009, 03:16 AM
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.

magicm
09-19-2009, 03:46 AM
The last line (in orange, assiging the material (mb) to the object(o)) is where it screws up.
Is there an error printed in the listener? If so, please post the error as well.

Martijn

amv256
09-19-2009, 04:10 AM
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.

Bobo
09-19-2009, 04:33 AM
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.

*Have you looked at the Task Manager while it is running? Does memory go up? What does the CPU % show? Does it look like Windows is paging? Is this in 32 or 64 bit?

*Have you looked for signs that automatic garbage collection is kicking in (the status report area of Max would flash a message if it does). Have you tried calling garbage collection at intervals between the calls?

*Have you tried running the code inside a 'with undo off ()' context to prevent Max from creating an undo record for thousands of materials being changed (when you assign a new material, the old one remains in memory for the undo stack to be able to restore it, with undo off will disable that)

amv256
09-19-2009, 04:43 AM
- 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.

denisT
09-19-2009, 06:33 PM
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.

denisT
09-19-2009, 10:54 PM
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 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.



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:%\n" (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...

DreaTawn
09-20-2009, 09:17 AM
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

denisT
09-20-2009, 07:40 PM
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 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.


...



i double checked these three fuctions ... append and deleteitem are slow, finditem works fast.

probably #mtlRefAdded and #mtlRefDeleted callbacks slow everything down. But they were added in 3ds max 6 ...

Kramsurfer
09-21-2009, 05:13 PM
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

CGTalk Moderation
09-21-2009, 05:13 PM
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.