Hi,
I have just installed Deadline 10.3.0.10 and Max2023 plus a trial of Vray6.
I have successfully submitted test renders to some farm nodes so everything does work from Max2023, however, I am seeing a submission delay under Max 2023.
I have a custom submitter which sends all selected cameras at once with a single saved max file.
This delay is an issue when needing to send many cameras at once.
If I submit from Max2021 + vray5 + Deadline 10.3.0.10, the max file saves and a SubmitInfoFile and JobInfoFile are generated per camera quite quickly (roughly a second or two apart)
On the same workstation, In Max 2023 + vray6 trial + Deadline 10.3.0.10, the max file saves and the SubmitInfoFile and JobInfoFile are generated per camera very slowly (roughly 30 to 60 seconds apart)
I have traced the delay to:
SMTDFunctions.CreateSubmitInfoFile
Specifically, this for loop: for f in ResolvedFileList do
If I remove the last line in this for loop: try(windows.processPostedMessages())catch()
then the info files generate quickly again, under Max2023.
I assume this delay is to do with how Max2023 reacts to try(windows.processPostedMessages())catch().
Since this line executes in a loop, once for every scene asset (I have 1600 assets in my scene) i guess this makes the loop run super slow.
Is there anything I can do Max side to fix this, or do I just use the edited version of SMTDFunctions.CreateSubmitInfoFile
within SubmitMaxToDeadline_Functions.ms
Thanks all
Graham
From the Max developer docs windows.processPostedMessages() is getting called to keep 3ds Max from hitting a ‘white screen’ state during long operations. With it removed, are you seeing that behaviour?
I don’t know if there’s anything on the Max side of things that could be changed to improve this - though if you run windows.processPostedMessages() in the melscript listener does it take longer to return in 2023 than it does in 2021? Might not be a good test without posted messages to process, but worth a shot.
Thanks, Justin!
I ran this:
StartTm = timeStamp()
for i = 1 to 100000 do
(
windows.processPostedMessages()
)
EndTm = timeStamp()
format "Proccess time = %\n"((EndTm - StartTm)/1000.0)
I got a fairly consistent:
0.05 seconds from Max2021
and
0.24 seconds from Max2023
So, about 4 to 5 times longer in Max2023.
I get same timings when running: try(windows.processPostedMessages())catch() in the loop.
This does’t explain how 1-2 seconds per submission can become almost 1 minute for approx 1600 assets checks, however, it points in the right direction at least.
In any case, it’s looking like an Autodesk issue to resolve.
I was thinking the loop: “for f in ResolvedFileList do”
could be more efficient by prefiltering out jpgs, pngs, vrayproxies etc… which may constitute the bulk of the assets.
Thanks
Graham
Nice work!
We run that call in a bunch of places in the submitter. It could also be that when run within an active Max instance there’s actual messages to process, where this test rig doesn’t? Just conjecture, but the run difference between Max 2021 and Max 2023 shows that there’s slowdown even in this minimum load setup.
I agree that that loop could be a bit more efficient - we likely could get away with running the processPostedMessages() based on how long since we ran it last instead of every time. I can’t say anything about if/when that sort of change would make it into the product due to Amazon policy.
Thanks for the update, Justin!
Shame about the Amazon policy 
2 Likes