Are you using the VRay Frame Buffer output? or the Normal Max output?
Typical log attached. I believe it is the V-Ray FB Dave, not my job but i think all the team use the V-R FB where possible.
Hd-xren-mies_00010_20120904165144.logReport (23.7 KB)
You can’t use the Vray Raw image file output with tile rendering if that’s what you’re trying to do?
I was looking into making it work with the VRAY VFB, but we’ve moved against using that output anyway, there’s a feature in 5.2 which allows it to be written though. I may or may not get back to that, but for the moment if you want to use Tile Rendering you need to turn off the Vray VFB.
Suspected as much. Bit of shame - means we’ll have to go back to EXR output rather than correct gamma correction in the FB.
Cheers guys.
It’s still on my list of things to-do but it’s lower down.
We are still encountering this problem.
Have ruled out any VFB / Split Render Files as the obvious cause.
Log file attached. Seems strange - output file name gets set correctly, then overridden as the final output. Happens on all tiles.
Hd-xren-mies_00001_20121107162506.logReport (47.8 KB)
0: Plugin rendering frame(s): 1
0: INFO: Render Tasks called
0: INFO: Region rendering enabled: left = 200, top = 0, right = 400, bottom = 152, padding = 0, type = CROP
0: INFO: Overriding render output: Q:\PA001 211 East 13th Street, NYC\renders\lobby\dline test 03\lobby_v03_tile_2x1_4x4_.tga
0: INFO: Lightning: Render frame 20
0: INFO: Lightning: Rendering frame Q:\PA001 211 East 13th Street, NYC\renders\lobby\dline test 03\lobby_v030020.tga
0: INFO: Lightning: Rendering 0 render elements
0: INFO: Lightning: Setting up render parametersThat’s strange…
Right-click on the job in the Monitor, select Explore Repository Directory, and then zip up the 2 .job files and post them. We’ll take a look to see if we can figure out what the problem is.
Thanks!
- Ryan
And you say you’re not using the Vray Frame Buffer or the Vray Output override?
No. Have run tests turning off, 1 by 1, VFB, Vray Output Override, Vray render elements. The logs and the report posted were all with none of these turned on.
M
Thanks for the files! Unfortunately, I’m having no luck reproducing this. I set up a VRay tile rendering job of my own with the same resolution and the same number tiles, and it worked as expected. So then I replaced my job’s files with the ones you sent, tweaked the output path to one that existed here (while maintaining the file name), and requeued the job. Again, it worked as expected.
So I’m kind of at a loss here…
Have you made any changes to your 3dsmax.py plugin file, which can be found in \your\repository\plugins\3dsmax?
Maybe you could run the 5.2 repository installer again over your current repository. This would “repair” your 3dsmax plugin if there is something wrong with it.
Hey All,
This is driving me nuts. There seems to be no obvious rhyme or reason as to why some users / jobs respond in this way, and others do not. We have reinstalled VRay / Deadline / Max on the workstations of those affected, but their jobs still fail for the same reason.
Attached are two .job files for two different users who sent jobs in the same way, to the same repository, running the same version, using the same 3dsmax.py. One failed (all tiles overwrote final output / no tiles_ extension), and the other worked perfectly.
999_050_999_012c7bf1_successful.zip (5.45 KB)
001_050_999_42cab066_failed.zip (4.97 KB)
Both were setup using fresh scene files.
The only obvious difference I can spot is in the files left in the repository job folders -
Any clues?
This is such a weird problem…
Do you know if any of the problematic scenes have some sort of callback script in them that could affect the output file name?
No, not that I am aware of. Can you give an example? We run a fairly standard setup here without much customisation or plugin-heavy workflow.
We thought we had tracked it down to being something to do with a scene at one time having something in the vray split frames output, but this proved a dead end.
The only other lead is that when someone whose scenes run fine through deadline opens the files of someone whose doesn’t they get a max warning stating “The MassFX authored in this file was created with a newer version of the plugins. Forward compatibility is not supported, so things might not behave properly”.
Other than that, everything seems exactly the same.
Ultimately, the render output gets changed in the last few lines of code by ‘Lightning’. What is this?
I don’t have an example, but I do know it’s possible to create maxscripts and assign them to callbacks for the scene file (ie: post scene load, pre render, etc). It sounds like this isn’t the case though.
It sounds like you have some version mismatching of the MassFX plugin between workstations and render nodes. What happens if you open the same scene on a render node? Do you get the same MassFX warning? It definitely sounds like a possible lead.
Lightning is the plugin that Max loads and that Deadline communicates with. It’s how Deadline controls the Max render. Based on the log, the override is being set correctly, but then something “resets” the output path:
From looking at our code, I can’t see where this reset would take place. So for now, maybe focus on resolving the MassFX plugin version issue and see if that makes a difference.
Cheers,
- Ryan
Ok, we’ll fix this, its does seem like a version mismatch from Max. Poss related to PU6.
I’m certain its not the cause though, as we’ve been experiencing this for a while (pre-PU4). Even if a user who can send to deadline perfectly successfully opens the file of someone who has previous sent that file and had it fail, it renders absolutely fine despite the error.
M
Does it make a difference if your Render Scene Dialog is open/closed? The way the render scene dialog works it can do funny things as changes are always made in a temporary state and only applied to the scene when it closes or has an update function called. I put something in our code to make sure any changes were definitely applied before doing any Deadline stuff.
interesting. let me test.
remarkably, I think we have just stumbled across the answer.
if the output path has a comma ‘,’ in it, it fails, otherwise, it works perfectly. 