I’m submitting and rendering on the very same machine.
Only the Repository is instelled on a dedicated Linux server, but this is a virtual windows server 2012 machine where I’m performing all the tests.
I’m submitting and rendering on the very same machine.
Only the Repository is instelled on a dedicated Linux server, but this is a virtual windows server 2012 machine where I’m performing all the tests.
Yes, it actually does save the file as “0010” to the 3ds Max root!
What the hell?!
Can you try changing the output path to something simple, like c:\output_.jpg or something (since you’re rendering on the same machine)? This is just to rule out that it’s not something to do with the current path…
Can you try changing the output path to something simple, like c:\output_.jpg or something (since you’re rendering on the same machine)? This is just to rule out that it’s not something to do with the current path…
Hmm… strangely it still saved the file as “0010” to the 3ds Max root.
I’m pretty stumped here.
Did you ever have success rendering with 3ds max 2013 and Deadline 6 before this started happening?
I’m pretty stumped here.
Did you ever have success rendering with 3ds max 2013 and Deadline 6 before this started happening?
Actually, yes, before installing the latest beta, we hadn’t experienced such issues.
I’ll try re-installing Deadline, completely, if it makes any difference, but I’m really surprised the SMTD script worked fine, but submitting via the monitor doesn’t.
Sounds good!
but I’m really surprised the SMTD script worked fine, but submitting via the monitor doesn’t.
When submitting with SMTD, we include the output path in the plugin info file, so that you can modify it from the Monitor after submission. Because of this, the output path gets set to this value by the Lightning code. When we don’t include the output path, which is the case for Monitor submissions, the output path is left “as is” by the Lightning code (which you think wouldn’t be an issue at all).
That’s the key difference, and it must be related to that somehow. If the reinstall doesn’t work, we’ll keep digging.
Cheers,
What is the exact parameter name for the output path?
Because when we used the OutputDir0="" in our own generated job_info files the results were the same, i.e. not saving. Maybe we can at least try to add this parameter that works, so it doesn’t block our further development.
This setting goes in the plugin info file (the second file submitted with the job). For example:
RenderOutput=\\RENDER\publicsmb\jobs\test_.jpg
Cheers,
Thank you, we’ll try that.
But in the end it’s not a bulletproof solution sine we have to supply the filetype as well, which is a bit problematic, since we cannot know in advance what filetype is being used beforehand.
By the way, this is very interesting in Deadline 5.2
0: INFO: Disabling Multipass: 1
0: INFO: Loading 3dsmax scene file
0: INFO: [filename] 0000000048A442B0
[format] 000007FED48CCE68
[size] 640x480
[aspect] 1
Why are the filename and format this screwed up?!
This is also Max 2013, but Deadline 5.2.0.49424
Could this be somehow connected?
I think it’s just a display issue. I’m pretty sure you would see the same thing when submitting from SMTD, but please correct me if I’m wrong!
I think it’s just a display issue. I’m pretty sure you would see the same thing when submitting from SMTD, but please correct me if I’m wrong!
Yes, most likely. It just surprised me a bit.
Though I don’t have any issues with Max 2013 on Deadline 5.2 (except for the lighting_startup.ms is being used by another process error discussed earlier )
I confirmed it’s just a display issue, and it turns out the information it’s trying to display is completely irrelevant because it’s pulling from data that hasn’t been set yet (hence the weird values). In beta 15, it will just say that the scene file has been loaded successfully. We’ll also be tweaking the 3dsmax plugin to press the Cancel button on that Image I/O error instead of Retry, since repeatedly pressing Retry can cause the render to get stuck forever if the image never saves.
I also tested your scene file again, this time without touching the output path in case that was somehow “fixing” things on my end. The image failed to save as expected, since that path doesn’t exist here, but the output path wasn’t “blank” like it is on your end. I simply got errors saying it couldn’t write to \render\publicsmb\BunnyTest\Ball_tst_0015.jpg.
Though I don’t have any issues with Max 2013 on Deadline 5.2
That’s interesting. When you test with 5.2, is it on the same machine you’re testing 6.0 on?
That’s interesting. When you test with 5.2, is it on the same machine you’re testing 6.0 on?
No, it’s not, it’s on a virtual machine we’re using for beta testing. The 5.2 runs on my company server in actual production.
Though I have to say it seems that reinstalling deadline completely seems to have fixed the issue. I’ll test some more this evening, to definitely confirm this.
Though I have to say it seems that reinstalling deadline completely seems to have fixed the issue. I’ll test some more this evening, to definitely confirm this.
Hopefully that fixes the issue! Maybe it was a corrupted lightning plugin or something…
Hopefully that fixes the issue! Maybe it was a corrupted lightning plugin or something…
It most likely was our problem that we overlooked some change somewhere. Unfortunately I’m not the only developer on this project so I can’t really say for sure.
But I still have to thank you, again, for your top notch support! I can’t imagine dealing with this with Autodesk or Adobe.