Hi,
I’ve got a custom submitter for 3dsmax that I’ve made, but since installing Corona 6, I can no longer get my UHDCaches or the new 4k Cache to work.
Looking at the info parameters, all the data seems to be correct and it is using the newest maxscript params but it doesn’t seem to ever render them out now ?
Is this just a support issue with Corona 6?
FYI, all the uhdcaches are not saved into the max file, all the data is sent with the job, this is so I can create multi uhdcaches without having to save the max files multiple times.
Any help getting this fixed would be great.
Thanks
Josh
1 Like
Hi Thinkbox people.
This corona 6 and deadline compatibility issue is stopping us from upgrading to corona 6. We would really appreciate it if someone could help us figure out what the problem is.
Thanks
Peter Guthrie
What’s the issue you’re seeing? That is - have you got any render logs showing render issues from Corona 6?
I assume you’re using some unofficial patch for Corona 6 support?
Corona_06_support.zip (8.4 KB)
Hi Justin,
The issue we have is that none of our uhdcaches are being rendered out since updating to Corona 6. There is new maxscript that handles this in Corona 6, so we have updated our script to allow for it, but deadline never seems to pick it up anymore.
All our uhdcaches are not saved into the max file, since we allow deadline make the correct changes which worked perfectly in Corona 5, but not in Corona 6. We don’t save it so we can save only 1 Max file instead of multiple !! I have attached all the job files and you can see, its holding all the correct information, but deadline doesn’t use it for some reason.
I’ve tried the Support.zip you have included, but that made no difference. Any help would be great !!!
Corona 6 Jobs.zip (10.4 KB)
Hey Josh,
Could I get the archived jobs? Those will have the submission information as well as the render logs which should show Deadline ignoring the Corona data. You can make those by right clicking on the job in the Monitor and choosing ‘Archive Job’.
Keeping in mind that Corona 6 isn’t officially supported, so this might be something we need to add to get proper support in place.
+1 for deadline being the reason we cant yet upgrade to Corona 6 in our studio.
It would be great to see official support pretty soon if possible 
Thanks
Jack
Hi Justin,
Sorry for the late reply. Here is the Archive jobs I took last week plus the 2 max files used (no textures since it was too big). Let me know if these help in anyway. If this could get supported asap that would be great !!!
Pointless Material archive.zip (1.1 MB)
Thanks
Josh
Just an update for folks. We spent some time on a call figuring this out today. It seems that our issue lives within setCurrentRendererSetting() of customize.ms which unpacks options sent along with the job within the plugin info section. Essentially it takes a dictionary and compares it against what SMTD passed along.
As an example, here are some of the Corona settings (JSON format from an archived job):
{
"corona_interactive_dissolveWithPrevious": "false",
"corona_colormap_exposureType_enums": "Use simple exposure",
"corona_colormap_exposureType_enums0": "Use simple exposure",
"corona_colormap_exposureType_enums1": "Use photographic exposure",
"corona_shading_primary_solver_enums": "Path Tracing",
"corona_shading_primary_solver_enums0": "None (biased)",
"corona_shading_primary_solver_enums1": "Path Tracing",
"corona_shading_secondary_solver_enums": "undefined",
"corona_shading_secondary_solver_enums0": "None (biased)",
"corona_shading_secondary_solver_enums1": "Path Tracing",
"corona_shading_secondary_solver_enums2": "UHD Cache",
}
For some reason, the getProperty renderers.current code that confirms the property can be set on the current renderer is failing. This leads to none of the settings coming through. In a healthy render you’d expect to see a number of properties set after these lines in the log:
2020-10-21 11:57:42: 0: INFO: >Corona Renderer detected as current renderer.
2020-10-21 11:57:42: 0: INFO: >Corona version: 6, build timestamp: Aug 31 2020 09:24:48
I’m hoping adding getCurrentException() to our debug output is going to get us something more helpful here.
1 Like
Another update: We’ve reproduced and set up a test case on our end. The original guess that it was an exception being eaten isn’t looking very likely now as we didn’t receive anything useful from getCurrentException() except on a completely different plugin that just happened to be used in a scene.