Oddity… some random frames are rendered with 0 byte renderelements. The beauty passes seem fine:
The restart-renderer setting is enabled.
That’s odd… anything in the render logs for those tasks that might explain the problem? Knowing Max, I’m guessing not, but it doesn’t hurt to check.
Another thing to check is to see if specific machines rendered those frames. Maybe there are a couple of bad apples in the farm…
Yeah we are trying to troubleshoot it internally, maybe its the scene. No error messages of course…
We used to have consistently 0 byte elements, but the restart renderer option fixed that problem.
Found the reason. Its the same issue thats described here:
viewtopic.php?f=86&t=10492&hilit=FixDeviceName
Apparently, my fix was not sufficient. The mBitmap->bi.CreateFmtSpecBlock(); function also needs to be called, because sometimes a JPEG device data is generated by max for an EXR render element, and vice versa. That results in random OpenEXR Memory ERROR like crashes on the farm, and / or 0 byte files being written out.
The jpeg’s device data (pidata in the bitmap info) is 12 bytes, the exrs is 169880. Obviously, if the jpegs data is passed on as exr that will result in all sorts of funkiness.
Ill do some comparisons on monday if i dont forget, whether calling this function if that data is already properly set up reinitializes it (which would be bad, as it would destroy the settings in it). If not, could you guys include that in lighting.dlx? I believe 3dsmaxcmd.exe does this automatically. This is also the reason why deadline had a built in ‘regenerate render elements’ feature added, which i think fixes this issue in SOME CASES. Not all…
Good Effort Laszlo! 
If possible, we should definitely try and get this fixed in Lightning.dlx. If we can, the MXS hack “regenerate render elements” should actually get removed from SMTD as it’s a temporary work-around, which I too, have seen the odd occasion where (a) it doesn’t solve the issue and (b) IIRC, doesn’t handle the situation where some of your RE’s are being saved to either different path locations OR different file extensions. Either way, if we can get it fixed cleanly in Lightning then this would be the optimal solution for all.
If you could do some tests on Monday that would be most helpful 
I agree that we should address this in lightning.dlx if we can. We’ll wait for the results from your tests and we’ll go from there.
Cheers,
- Ryan
Sadly, the CreateFmtSpecBlock() function resets all the settings to whatever max thinks is default 
So if we had any custom settings there, it would get wiped…
Oh max, why you suck so much.
So basically the only solution i can think of that you guys could do is basically checking what pidata the given bitmapinfo has set up, and based on that, reinitialize if its not the one the user has set as the extension. There are calls that are supposed to do that in the maxsdk, like FixDeviceName() etc, but they fail in some cases (in most of ours…).
Ill keep looking into this a little, i would rather not have jpgs / exr internal plugin parameters hardcoded in c++ hackery code
Hey guys,
Just catching on this issue as I’m back from vacation now. Capture all RE settings prior to re-initialising everything within the Lightning plugin before proceeding to render?
Or can we check what FileExtension is being used for each RE and cross-reference it with what bitmapIO class is being used at c++ level and if they don’t match, then this particular RE will need to be re-initialised, in which case, you will need to grab all it’s current settings, so they can be re-applied once this RE has finished being re-initialised. - do all this within Lightning?
Sounds nasty. Thoughts?
M
That might be an option in some cases, but most definitely not in our case. We specify particular exr settings for different render elements (32b float for most utility passes, but 16 bit float for others, enforce compression methods etc). Since setting those values via maxscript is a minefield of epic proportions, i had to resort to writing a c++ plugin to do that, which is nasty hackery (of reverse engineering the memory mapping of exr plugin parameters, and then flipping bytes in ram). Since you cant reliably query and set those values via maxscript, this could not easily be done. Sidenote: the reason it does not properly work via maxscript is the SAME problem thats causing the 0 byte render elements. Max is just simply not initializing properly and reliably the render element output devices in time.
Yep, thats EXACTLY what i am doing right now, pre submission. The thing is, you can’t really grab all its settings, because it has none (the settings arent set if the device is not initialized). I think max just defaults to the device of the regular main output, or the defaults of the particular plugin type.
In my case, im doing the ‘housecleaning’ before enforcing our in-house parameters.
Understood. How very annoying!
Sounds like we really should contact Autodesk and get them to fix this BUG at source? I’m happy to submit a bug report, but would need a reproducible scene and set of instructions to guarantee success with ADSK! IIRC, the current EXR plugin in 3dsMax was created by Cebas off the request from Uncharted for 2012 and doesn’t look like it’s been touched by any other dev work since then and it’s subsequent implementation by ADSK.
I have reported the issue of maxscript not being able to set properties properly to autodesk about a year ago, with detailed instructions. I have also got in touch with cebas, who said something along the lines of “its autodesks’ fault”, which seems to be the case, considering it happens with jpegs too.
I have re-reported this latter un-initialized device issue 2 weeks ago again, and as far as i know its been sent to the developers.
So if we all cross our fingers it might be fixed in max 2016 
By then, my son will be going to school and my daughter will have learned to speak.
Cool!
You’re funny! / know ADSK too well!
(Do you have a tracking number / beta bug number you can send me, so I can help accelerate? ~PM me if you like )
PM’d you!