The good news first:
The file name prefixing/labeling now works as it should. I set the prefix to be ‘left’, etc. in the ini file and that also works.
Thank you very much!
The bad news:
The Draft jobs are still failing and i think i know why. It is looking for files named e.g.
Notice the ‘…’ before VRay’s render element description. I think we’ve seen this issue before but i don’t really remember where it was coming from and how it was fixed. I’m entering the file name in VFB’s ‘Save…’ dialog as
kit_001_010_rndr_setup_v003b_hh.exr
So i guess it’s most likely happening through SMTD?
a quick question aside from the bugs: when not using the Autodesk StereoCameraRig is there any chance to name the cameras in a way that Deadline will treat them like the StereoCameraRig so we don’t have to send several separate scenes to the farm? Reason is that our artists stepped away from the rig for now as it was causing some more (Deadline-unrelated) trouble.
There is a chance, but I don’t want to make assumptions, as there are so many users of Deadline. Imagine someone named his cameras in a similar way, but does NOT want them to be handled automatically… Or company rules require completely different naming than what you (and eventually Deadline) expects?
Would it be reasonable to require the “Stereo” Cameras to be parented to a common Helper that is named in a special way?
Right now Deadline checks for the Autodesk StereoCamera head to determine which cameras belong together in the rig.
Also, the Autodesk StereoCameraRig appears to have a fixed creation order for the Left, Right and Center cameras, so right now Deadline does not depend on the actual naming of the cameras. You could call them John, Paul and George, and it would still work. Ensuring a fixed order of the children within a custom Helper parent would be tricky though, so we would have to parse the camera names, and that would be quite arbitrary.
Can you provide more information about how you set up and name your “stereo” cameras?
How about adding an option “OFF” to the Stereo Camera Jobs drop-down menu in SMTD for those cases?
Understood. This seems to call for a ‘small’ MAXScript that will build up a stereo camera rig with certain parameters that can be configured by the user or a global pipeline setup - and ideally Deadline/SMTD would read that config.
This is definitely a possible solution. Or maybe also a simple MAXScript that let’s the user pick the left/right/center cameras from the scene?
If that MAXScript i suggested above is involved that should make it less arbitrary, right?
Not really, honestly. Luckily, this is the first S3D project in years
But while we’re at it i thought we should try and get a proper workflow together that includes Deadline. So we’re actually quite flexible here as there are no rules set in stone in our facility ATM - apart from that ‘left’/‘right’ naming instead of ‘LE’/‘RE’.
I tested this here with QuickDraft and it worked.
However, given my history from the last week, I don’t want to assume it is right until you test and confirm it.
Plus, there might be other places it is broken that I could have missed…
I just did a test with the same scene i was using for the tests before. This went fine, the files don’t have any ‘…’ in the name anymore. All the dependent Draft jobs including shotgun_filmstrip and shotgun_h264 worked finished without any errors.
But i have only tested rendering through VFB, not anything else.
If the current viewport is set to a native 3ds Max Stereo Camera rig, it will work like before.
If the current viewport is set to a Camera that is not part of a native Stereo Rig, the following rules apply:
[list]
[*] If the camera contains the sub-string “left”, “right” or “center”/“centre” in its name, it will be checked for a Custom Stereo Rig
If the above potential stereo camera is parented to any object that contains the substring “stereo” in its name, that parent will be checked for other cameras matching the “left”, “right” or “center”/“centre” naming convention.
If a “left” and a “right” camera is found within the “stereo” parent, they will be used as left and right eye.
If there is no pair of “left”+“right” cameras, the current camera will be used as non-stereo camera
If there is a “center” or “centre” camera in addition to the left and right, it will also be considered part of the rig
If the current viewport camera is parented to another camera and is named “left”, “right” or “center”/“centre”, or is the parent of such cameras, these cameras will be collected and used.
In this case, the parent camera does NOT have to contain the substring “stereo” in its name. If it is called “left”, “right” or “center”/“centre”, it will be considered a part of the renderable cameras, otherwise it will be used as the parent but won’t be rendered.
If two or more cameras of the same “eye” are found, the first one found will be used.
The order of detection depends on the order of parenting (first camera parented is the first to be found), and on the active camera in the viewport.
[/*:m][/list:u]
Here are some examples of possible Custom Rigs:
Point Helper called “PT_stereo_001” with “LeftCamera001” and “RightCamera042” parented (linked) to it. Either one of the cameras is set to the current viewport. RESULT: The two cameras will be used as Left and Right eye. The “LeftCamera001” will always be the left eye, regardless of the order in which the parenting was performed.
Dummy called “DM_StereoRig_012” with “StereoCamera_LeftEye_01”, “StereoCamera_RightEye_01” and “StereoCamera_CenterEye_01” parented to it. One of these three cameras is set in the current view. RESULT: The three cameras will be used as the Left, Right and Center cameras.
Mesh called “GEO_SomethingSomethingDarkSide_012” with “SomeCamera_Left_01” and “SomeCamera_Right_01” parented to it. One of the two cameras is set in the current view. RESULT: The current camera will be rendered alone, ignoring the second one, because the mesh name does not contain “stereo” in it!
“NewCamera_Left”, “NewCamera_Right” and “NewCamera_Centre” are all grouped together using the Group feature of 3ds Max, and the Group is called “MyNewStereoRig”. One of the three cameras is set as the active viewport’s camera. RESULT: All three cameras will be considered a stereo rig, because they are technically parented to a Group Head containing “stereo” in its name. Note the center camera is spelled “centre” and it is still supported for all UK users to enjoy.
“LeftEyeStereoCamera01” and “RightCameraJustInCase02” are both parented to a camera called “SomeCamera_123”. Either one of these three cameras is set in the active viewport. RESULT: Only the Left and Right children cameras will be sent to render because “SomeCamera_123” does not contain the string “center” in its name. However, it can be used as the parent to animate the other two cameras, and even render locally as the center eye. Rename it to “SomeCamera_Center_123” and it will be considered a valid Deadline center camera. Note that the names of the two eyes are different, but contain the necessary “left” and “right” tokens.
“LeftEyeStereoTest012” and “CenterCameraTest034” are both parented to an Omni light called “TheThirdEye_InStereo”. One of the two cameras is set as the active viewport’s camera. RESULT: Only the active camera will be submitted as a single rendering because for Stereo Camera rendering we expect both Left and Right eye to exist, but this rig has only Left and Center. Adding a third camera or renaming the Center camera to “RightCameraTest034” will make it work again.
“LeftEyeStereo012”, “LeftEyeAgain034”, and “RightEyeStereo056” are all parented to a camera called “RightEyeAndParent001”. “LeftEyeStereo012” is set in the active viewport. RESULT: Only “LeftEyeStereo012” and “RightEyeStereo056” will be submitted, the “LeftEyeAgain034” and “RightEyeAndParent001” will be ignored because we support only one pair of left and right cameras, and the first ones found will be used.
I tested this somewhat and it appears to be working correctly.
I also fixed some nasty problems with QuickDraft which required the Integration tab to be activated for the feature to work after a new start of SMTD, and some settings were not being sent with the job if their controls were never touched by the user (e.g. Format, Frame Rate etc.)
I just tried it with a recent scene that was set up with custom left/right cameras and it seems to work. We’ll continue using it today and see if it works reliably - but it’s looking good so far! I attached the scene of this test for you as reference to see if there are some things in the way it’s set up that you maybe want to consider.
Would it actually be possible to disable the ‘Stereo Camera Jobs’ menu as kind of an indicator that SMTD didn’t find any compatible setup?
Another question: right now, there is a shotgun version being created for each camera/view. Would it maybe be possible to have an option to submit all views/cameras as one single version? In most cases we don’t really need a version per view but rather have both/all cameras in one shotgun version. The “Path to Frames” in shotgun is then something like
filename_%V.%04d.exr
where the ‘%V’ is a variable that’s being interpreted by Nuke as the name of the view.
As you also mentioned some bugfixes with QuickDraft/Integration i remember seeing another bug in the Integration tab which still seems to be there.
The info in the ‘Extra Info’ section is not updated until disabling and re-enabling the ‘Create New Version’ checkbox.
When opening SMTD, i go to the Integration tab, activate the ‘Create New Version’ and then enter the new version name, description, etc. But the ‘Extra Info’ doesn’t change - only when i disable/enable the checkbox it’s being updated. Same goes basically for the ‘Draft Template Output Options’ values. Only when pressing ‘Use Shotgun Data’ they’re being updated.
No, the majority of the SMTD UI does not reflect the scene content dynamically. The menu tells SMTD “if you find a stereo camera in the active viewport, here is what to do with it”. I have some other ideas how to let you monitor what would happen if a submission would be performed, but it looks like a bigger project that will have to wait for v8.0…
It won’t be trivial. Each stereo camera is submitted quite independently, as if you pressed the SUBMIT button multiple times. The individual jobs don’t have knowledge of each-other, except for the batch name. It would require some rethinking to make the Shotgun integration know what to do. I have some ideas, but I don’t think they will make it into 7.2.
Will look into this, thanks! The Integration tab was not my code originally, so I will have to be careful not to break anything.
I know you were joking, but there is a huge difference between modifying my own code (even if it were 10+ years old, as is the case with some parts of SMTD), and somebody else’s code I have never seen (which is the case with the Draft & Shotgun integration functions).
Yesterday, I moved a large portion of the Quick Draft code from the UI into the Functions part because it was simply in the wrong place. However, I was probably the only person in the world to know that. It was a truly stressful exercise to move it over and make it work better than before without breaking it…
In contrast, adding the custom stereo camera support was a breeze, as I was tweaking a function I wrote myself about a month ago
I know - especially as someone who’s just a part-time programmer and is causing this pain to myself every once in a while - and sometimes to others. But i’m working on it
Speaking of Draft: do you think there’s a chance to add an option to limit the QuickDraft jobs to the beauty pass (in the case of VRay the ‘RGB_color’ pass) of a render job? All those outputs don’t really hurt but sometimes you just don’t need/want them.
And we just stumbled upon another Draft issue related to EXR output from Max/VRay. Don’t know if this is related to the code that you’re working on but if you want to have a look, the thread is here: https://forums.thinkboxsoftware.com/viewtopic.php?f=205&t=13720
It is not trivial, and is not controlled by SMTD. Basically we enable Quick Draft by writing some flags into the Job file, and then the Draft Event takes over, fishes out all paths from the file and builds jobs on the fly when the main job finishes. This will require some serious changes on the side of the Draft Event which is out of my control. But I will ask the developers to consider it…
Just add one more flag then!
Joking aside: completely understood. Like i wrote before, it’s not something really important, rather some nice-to-have feature.
Another question/idea:
how about adding some control next to the ‘Stereo Camera Jobs’ where the user can control the priorities of the different cameras as an offset value in relation to the first camera? I’m thinking of a scenario where you have a few scenes to render in stereo and they will take quite a while. Basic comping and editing could be started as soon as one view is rendered for all scenes. Of course, this can be done manually in the Monitor but i think it’s nice to have this in SMTD - just like with the ‘PREVIEW FRAMES’ jobs where you can set the ‘Priority +’. In the case of stereo, i think it’d be better to decrease the priorities of the other cameras in relation to the left one, though. I think it’s become kind of a de-facto standard to use the left view as the hero view and use that in case of mono versions. And i think SMTD already submits the left one first, right?
Awesome idea, I will add that.
However, it won’t make it into the next beta build (expected before the end of the week), so I will just upload the new SMTD scripts here when I have them.
Quick question: there’s been loads of ‘inofficial’ fixes and updates of SMTD and some other scripts due to some other bugs during the current 7.2.0.14. So i was regularly backing up, overwriting scripts in the repo. I guess a better way to test those fixes would be to put them into the ‘custom’ folder as those are being used when they have the same name as the shipped ones, right?
Wrong, the MAXScripts always read from the \Submission\3dsmax\Main
The Custom scripts is for Deadline’s own scripts. SMTD is part of 3ds Max, shipping with Deadline, but not running IN Deadline.
Keep on doing what you were doing before - baking up the old files (in a zip or subfolder), and overwriting with the latest ones.
Instead of offering a number, it asks you for the order you want them processed in, and sets the Priority internally to 1 less than the main eye.
E.g. if Left > Right > Center was requested, and Priority was 50, it will submit Left with 50, Right with 49 and Center with 48.
If you want to tweak the actual offset value, I might expose it as a setting you can control company-wide via the Defaults.
I’d rather not add it to the UI. So you could set it to 10 and it would submit with 50,40,30…
I see…
Actually, it’s just a bit misleading in the docs then:
In addition, any scripts or plugins in the ‘custom’ folder will override any scripts or plugins that are shipped with Deadline if they share the same name.
I just briefly tried your new version and it seems it’s all working.
Sounds good to me. Probably not really necessary to have the prio offset exposed to the user. I was just thinking of the same behaviour as the ‘Preview Frames’ job.
When sending Left > Right it’s going to use prio 50 and 48 (but not 50 and 49). Not at all a problem for me, just thought i let you know.
Yes, that’d be good. Should have at least some location to tweak it if needed.
