Sounds like VRay RT does not even expose a Render Elements Manager?
Does it fail if you try to submit to Deadline with SMTD without doing a Sanity Check?
If yes, we have to bulletproof all code that uses the Render Elements manager interface anywhere.
I never thought a Max renderer would not expose that interface, even if it does not support Render Elements. But it is too late to point fingers, we have to fix it on our side…
The quick fix on your side would be of course
re = maxOps.GetCurRenderElementMgr()
if re != undefined and re.numrenderelements() != 0 then …
Perhaps, we should be checking that we are not in “activeShade” or “IterativeMode” in the Render Scene Dialog and if so, exit from submission immediately.
if renderers.renderDialogMode != #production do #abort
I don’t want to make any assumptions as the user might want to submit the job to Deadline in Workstation mode and run some scripts that render and capture the ActiveShade output for some reason… The error in this case is the missing RenderElements Manager, so we should deal with that issue, not whether ActiveShade is allowed or not. If someone wants to prevent ActiveShade jobs, he can write a Sanity Check specifically for that…
You can use VRayRT as a production Renderer and submit to the farm using that but I can’t imagine why you would submit to the farm in activeshade mode? I just tried it accidentally and reported it as I got a hard crash.
I can ask Vlado why VRay in Activeshade mode doesn’t report a Render Element Manager in maxscript as it does when in production mode.
FYI. I’ve finished bullet-proofing the SMTD code to handle this situation as per Bobo’s suggestion. It seems to be working fine now. Tried various job submissions and no problems, so hopefully this situation is now covered in the future and also covers any renderer in activeShade mode. Fix will ship with v7.2.