Hi guys, so I’ve got a few posts I’m going to make for Modo. I’ll break them up since one is more of a feature request rather than an issue.
So this first issue regards the rendering of the modo render outputs. When 801 was released I ran a test scene where I output every render out that existed in modo. I noticed that there are about 3 outputs that did not look like they did in my local render I did. So I saved out that local render and compared all the images to my Deadline render. The Diffuse Roughness, Diffuse Energy Conservation, and the Specular Coefficient. are the problem outputs. I’m unaware if this is a Modo or a Deadline issue. But When I render locally and I save out a layered EXR, all of the layers are correct. This could be an issue with Modo_cl, but I’m unsure how to test this outside of Deadline. I figure I’d start with you guys first since you’re much more responsive than the Modo guys.
I’ve attached the images to this thread along with my modo scene file.
Windows 7
Deadline Version: 6.2.0.32 R (eb5668cff)
Modo Version: 801 - Service Pack 1 - 71114
Deadline_Modo_RenderOutput_Debug.rar (69 KB)
Could you post a render log from the Deadline job? We can check to see if there are any warnings or anything else that might indicate there is an issue. Also, when you are testing, are you rendering with Deadline on the same machine that you’re doing the local rendering on?
How are you submitting the job? From looking at the modo plugin code, the only time we touch the output settings is if a tile job is being submitted, or if the job is being submitted from the Monitor with the Override Output option enabled.
So if you are submitting from the modo integrated submitter, and you’re using tile rendering, try disabling tile rendering to see if it makes a difference. If you are submitting from the Monitor, and you’re overriding the output path, try disabling that to see if it makes a difference.
If you still see these problems when tile rendering is disabled, or when submitting from the Monitor without overriding the output, it might be a modo thing.
Cheers,
Ryan
Could you post a render log from the Deadline job?
Log attached.
Also, when you are testing, are you rendering with Deadline on the same machine that you’re doing the local rendering on?
When I render locally, I’m rendering through my own instance of Modo. Then when the render is complete I’ll save out the images through Modo. When I run it through Deadline I’m sending it to our farm, which at the time of render my machine was not part of.
How are you submitting the job?
I’m using my own modified version of the integrated submitter.
So if you are submitting from the modo integrated submitter, and you’re using tile rendering
I’m not using tiled rendering.
After reading through your response I get the feeling that our terminology is being crossed. When I say Render Output, I’m speaking of Modo’s internal system that puts out a different render for the output type (i.e. Diffuse Direct, Diffuse Indirect…). At this point I’m not using the optional Output folder (although I’ll have another post regarding this).
I’m still unsure if this is a Deadline issue. But I believe that you guys are sending commands to the modo_cl exe and I’m wondering if something is getting crossed up there. I say this because two of the render outputs look the same (Diffuse Energy Conservation and Diffuse Roughness).
James
Deadline_Modo_RenderoutputLog.txt (2.81 MB)
Thanks for the log! It confirms that Deadline isn’t passing anything output-related to modo. The key line is this one:
2014-06-17 16:14:30: 0: STDOUT: Received command: EXECUTE: !render.animation {*}
The {*} part tells modo to render using it’s existing output settings, and nowhere else in the log does it show us sending a command to touch the output.
So since the output isn’t being touched, my guess would be that it’s a modo issue…
Cheers,
Ryan
OK, I’ll submit a bug report to Luxology and see where things go.
James
Just to update. Totally was an internal issue with my code. I duplicated some variables that caused information from two sources to go to the same variable. Pesky little bug.