AWS Thinkbox Discussion Forums

3DSMax-Vray render Elements suddenly not writing to disk with Deadline

Hi all !

We’ve been using Deadline at work for a few months now and everything was working like a charm until a few days ago:

Suddenly, jobs submitted to deadline stopped writting the render elements to disk; everything looks fine in deadline, the job settings shows the proper paths, the folders are created, and i’m NOT using the vray frame buffer, but for some reason, now my render elements are not saved to disk. the beauty is fine tho.

What is even more weird is that it works with a few computers (2 of them, out of 40). I tried saving a Deadline preset from these computers and loading it on mine, but halas, it still doesn’t work.

I though that my jobs were corrupted, but when i submit them with one of the 2 valid computers it works perfectly :astonished:

Here is some more information:

  • we use network drives mapped to letters for our max files (and we do not copy them to the repository, we use the actual max files)
  • we use 3dsmax 2016 and Vray 3.4
  • we save Exrs with separate render elements in subfolders
  • we use the default deadline submitter script for our submissions

Is this something you heard about before and could it be related to some network authorisation issue or something ?

If you need more information please let me know and i’ll be happy to give it :slight_smile:

Cheers !

I haven’t heard of it yet, but it looks like we’ll be comparing the working machines to the failing machines. Can you send a job report from one that’s successfully writing the elements and one that isn’t? I’ll push that through a text difference application to see what problems might be (hoping for something easy like V-Ray versions or something).

If you can’t post them publicly, e-mail them off to us at support@thinkboxsoftware.com.

Hi Eamsler !

Thank you for your help - I will run two identical simple jobs on 2 machines (one succeeding and one failing) and report back to you with them first thing tomorrow morning - stay tuned !

hi again !

So i spent my morning working on that issue and , well , it looks like it’s not a Deadline issue - even when i render locally, i don’t have my render elements…

I’ll try and write to autodesk about it, cause it’s actually a 3dsmax problem

thanks for your help tho !

Any time Mike! Have a good day :slight_smile:

I run into this problem when the Vray VFB is enabled. Try using the standard VFB and I think the RE’s will write fine. I even wrote this into the sanity check to make sure it wouldn’t happen again.

@oatz: want to donate the sanity check code so you don’t need to maintain it? Our Mike is away on vacation for awhile, but I can run it past him when he gets back.

Enjoy. You might have different classid’s dependign on which vray version you run.

-----------------------------------------------------------------------------------------------------------------------------------------------
--THIS FILE CONTAINS YOUR USER-DEFINED CHECKS TO BE PERFORMED AND THE FUNCTIONS
--TO BE USED TO CHECK AND REPAIR THE SCENE BEFORE SUBMISSION
-----------------------------------------------------------------------------------------------------------------------------------------------
--THIS FILE WILL **NOT** BE UPDATED AUTOMATICALLY BY THINKBOX SOFTWARE INC
--AND SHOULD BE USED FOR YOUR IN-HOUSE NEEDS.
-----------------------------------------------------------------------------------------------------------------------------------------------

(
global SMTD_Private_SanityCheckFunctions
global SMTD_Private_SanityChecksToPerform
global SMTD_Private_RepairFunctions 

global SMTD_RepairFunctions
global SMTD_SanityChecksToPerform
global SMTD_SanityCheckFunctions

struct SMTD_Private_SanityCheckFunctions
(
    fn CheckVrayVFB =
    (
	if (renderers.current.classid as string == "#(1941615238, 2012806412)" or renderers.current.classid as string == "#(1941615238L, 2012806412L)") then (
		renderers.current.output_on == false
	)
	else 
	true
    )
)--end struct		


struct SMTD_Private_RepairFunctions 
(
    fn FixVrayVFB=
    (
	renderers.current.output_on = false
	SMTD_SanityCheck_errorReportRollout.log_action "Fixed" (color 0 155 0) true "Vray VFB Disabled"
    )
)--end struct 

------------------------------------------------------------------------------------------------------------------------------------------------------
--SANITY CHECK PRIVATE DEFINITIONS
------------------------------------------------------------------------------------------------------------------------------------------------------

SMTD_Private_SanityChecksToPerform = #(
 #(SMTD_Private_SanityCheckFunctions.CheckVrayVFB, #fix, "Vray VFB Enabled -- Render elements will not save.", SMTD_Private_RepairFunctions.FixVrayVFB, true)
)--end checks array

)--End File

Thanks sir! I’ll kick the link to this forum over to Mike and co.

So, the reason we don’t have a check is that we can’t say for sure ‘know’ what you want to enforce. Some people want the frame buffer enabled, some don’t. So, it’s tough as the SMTD sanity checks don’t have configuration files.

Sounds like a perfect example of the warning error type.

I’m experiencing deja vu here, as I’m pretty sure a couple of years back, this SMTD sanity check was added, we got moaned at and then it was removed and clients were advised to add it in themselves if they wanted it, due to some studios wanting it and others not. I’m pretty sure we tried tagging it as a “warn” as well, in an attempt to declassify its importance during submission, but even that was met with some moaners. :wink:

Do we just add it back in and say ‘tough beans’ to anyone else? Tough call to please everyone. Maybe a vote is needed here? Paper, scissors, stone? :laughing:

OK, I’ve been able to figure out what I believe to be a good solution which handles both workflows. I’ve re-added a sanity check into SMTD as a #warn which specifically checks for V-Ray VFB being enabled WHEN Split Channels is un-checked, as ultimately this will result in NO render elements being generated. In the case of Split Channels being checked, then that might not be what the user actually wants really, but it would result in the render elements being generated. Tagging it as a #warn, means job submission will also not be halted as well, so we have that fallback for any users who get frustrated by this additional check, in terms of backwards compatibility.

I’ve added this all to the next 8.1 beta build.

Privacy | Site terms | Cookie preferences