PDA

View Full Version : MAXScript Speed


Khrob
01-02-2008, 01:51 AM
G'day all,

I'm doing some visualisation for an oil company, and I'm running into some interesting speed issues with my .ms files. While I can't post my actual code, here's something akin to what I'm trying to do:

fn createcones =
(
for i = 1 to 1000 do
(
c = cone()

c.pos = [0,0,i-500]
)
)

fn changecones =
(
start = timestamp()

undo off
(
for c in $cone* do
(
c.material = standard diffuse:(color 64.0 64.0 64.0 ) selfIllumAmount:2.0 opacity:2.0
)

gc()
)

end = timestamp()

format "changecones() took % seconds\n" ((end-start)/1000.0)
)

Nice and simple - with the actual project I'm using something in the order of 180,000 objects, so speed is of the essense.

My problem is with repeated execution of the above code - works entirely adequately the first time around, then slows down with every subsequent call.

Here's some typical results:

changecones()
changecones() took 2.078 seconds
OK
changecones()
changecones() took 3.469 seconds
OK
changecones()
changecones() took 5.656 seconds
OK
changecones()
changecones() took 10.125 seconds
OK
changecones()
changecones() took 17.984 seconds
OK

A six minute turnaround for 180,000 objects isn't great, but I can live with it - nearly an hour to do the same tweaking of the data just because I've run it 5 times? Not so good!

If anyone can point out a better way or if I'm making some boneheadedly obvious mistake, I'd greatly appreciate it!


Happy New Year All!!

U.S.S. Speed
01-02-2008, 04:24 AM
I'm not a pro at MaxScript, so take my advice with some salt...

But I already hit a problem with large number of polys on screen that are being modified... Or simply a large ammount of object.

The problem I had was the viewport refresh... Every action the script take that affect the scene call for a refresh... unless you disable it.

use :
disableSceneRedraw()
at the start of your script and
enableSceneRedraw()
at the end to disable and enable the viewport refresh.

The bad side to that is, if your script crash, the viewport stay disabled. You can turn it back on in many way. Personnaly I do a Hold and a Fetch.

focomoso
01-02-2008, 05:24 AM
Print out sceneMaterials.count. Looks like you're creating 1000 new materials every time you run the script and they're probably still in the scene. You're better off assigning a mat on object creation and then manipulating that mat when needed.

edit: just confirmed this. Every time I ran the script in 2008, sceneMaterials.count uped by 1000.

Khrob
01-02-2008, 07:42 AM
brilliant! many thanks!

Bobo
01-02-2008, 08:07 AM
Print out sceneMaterials.count. Looks like you're creating 1000 new materials every time you run the script and they're probably still in the scene. You're better off assigning a mat on object creation and then manipulating that mat when needed.

edit: just confirmed this. Every time I ran the script in 2008, sceneMaterials.count uped by 1000.

There is a thread somewhere around (http://forums.cgsociety.org/showthread.php?f=98&t=561413) about how to solve this - Max does not update its internal material database unless you perform a file i/o of the Max file. We found out that the simplest way to force an update of the sceneMaterials.count is to perform a "dummy" save selected, something like

saveNodes #() (GetDir #scene + "\\_Temp.max")
deleteFile (GetDir #scene + "\\_Temp.max")

This saves an empty file to disk and deletes it afterwards, but this forces Max to update as if a real save was performed. Calling holdMaxFile() will have the same effect, but would take much longer...

Khrob
01-02-2008, 11:44 PM
U.S.S. Speed, focomoso & Bobo - Thanks so much guys - I've shaved a heap of time off the update function, but it's still growing - I think I've got a problem with my object creation.

I made this little function:

fn conetest iterations num_cones =
(

disableSceneRedraw() -- thanks U.S.S. Speed!

for i = 1 to iterations do
(
start = timestamp()

for j = 1 to num_cones do
(
c = cone()
c.pos = [0,0,j]
)

end = timestamp()

format "iteration % took % seconds\n" i ((end-start)/1000.0)
)

EnableSceneRedraw()

)

and some results:



conetest 5 400
iteration 1 took 2.078 seconds
iteration 2 took 2.594 seconds
iteration 3 took 3.156 seconds
iteration 4 took 3.718 seconds
iteration 5 took 4.375 seconds
OK

is 'c' not being cleaned up or something?

thanks again for all your help - it's been invaluable so far!

Khrob
01-02-2008, 11:54 PM
slight change - I removed the local variable c in the inner loop - I do my post creation manipulation based on the object's name, so it's not necessary. Now it looks like this:


for j = 1 to num_cones do
(
cone pos:[0,0,j] boxmode:true
)

which doesn't seem to improve performance much (if at all)

cheers

Gravey
01-03-2008, 12:19 AM
try adding undo off before you start your i loop to disable the undo buffer for your cone creation and possibly speed things up even more

U.S.S. Speed
01-03-2008, 12:19 AM
- Forget what I said - ;)

But Gravey may have something.

Kramsurfer
01-03-2008, 12:27 AM
if it's just for viewport update, perhaps view and adjust object color instead of the materials. Then if you need to, before rendering apply materials.

I have times : Windows xp sp2. max9. 3.0ghz Dual Pen.

13.8 seconds for the supplied script.
0.64 for just changing the .wirecolor Parameter...

This is with the screen enabled.

If you need to store other data quickly on the objects, I would consider AppData calls, they're very fast...

0.68 changed .wirecolor and two setAppData calls.
0.86 changed .wirecolor, .visibility and two setAppData calls.

-----------------
for c in $cone* do
(
c.wirecolor = ( color 20 20 20 )
c.visibility = 0.5
setappdata c 3445 "Data1"
setappdata c 3446 "Data2"
)
------------------

It's definitely a material thing.. looping test.

changecones() took 0.719 seconds
changecones() took 0.703 seconds
changecones() took 0.703 seconds
changecones() took 0.719 seconds
changecones() took 0.703 seconds
changecones() took 0.703 seconds
changecones() took 0.75 seconds
changecones() took 0.734 seconds
changecones() took 0.751 seconds
changecones() took 0.735 seconds
changecones() took 0.719 seconds


Hope this helps..

Khrob
01-03-2008, 12:46 AM
Man I love this community! Thanks so much for the help everyone, and Kramsurfer - thanks for going to the trouble of actually running and improving things yourself!

truly we work in an industry populated with awesome people :)

focomoso
01-03-2008, 08:21 PM
There is a thread somewhere around (http://forums.cgsociety.org/showthread.php?f=98&t=561413) about how to solve this - Max does not update its internal material database unless you perform a file i/o of the Max file. We found out that the simplest way to force an update of the sceneMaterials.count is to perform a "dummy" save selected, something like

saveNodes #() (GetDir #scene + "\\_Temp.max")
deleteFile (GetDir #scene + "\\_Temp.max")

This saves an empty file to disk and deletes it afterwards, but this forces Max to update as if a real save was performed. Calling holdMaxFile() will have the same effect, but would take much longer...
Nice......

RustyKnight
01-03-2008, 10:05 PM
- Forget what I said - ;)

But Gravey may have something.Actually, I think what you said is relevent, it's just another piece of the puzzel and everything helps...

I find disabling the viewports and undo buffer very useful.

I've also found increase the avaliable memory to maxscript can help and cearfully placed gc calls can also help...

U.S.S. Speed
01-03-2008, 10:23 PM
Actually, I think what you said is relevent, it's just another piece of the puzzel and everything helps...

I find disabling the viewports and undo buffer very useful.

I've also found increase the avaliable memory to maxscript can help and cearfully placed gc calls can also help...

No... I actually edited that post. I was repeating something that was no longer relevant. But since you can't delete a post... :D

Kramsurfer
01-07-2008, 10:08 PM
As far as speed, the SaveNodes has a major delay when saving from large scene's in Max 9. I've confirmed this from other users, but I don't know if it's been logged as a bug or not...

We've a system than manages the camera per shot in different max files and the save select from large scenes is very slow...

CGTalk Moderation
01-07-2008, 10:08 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.