This is a modification we put in our version of the SMTD, we store the Tile/Region Rendering Settings as persistent globals in the max file and recall these whenever the SMTD is opened. Having used Deadline like this for 2 years I can’t see why you would want it any other way.
Jigsaw tiles can be saved with the Max camera so that they can be restored later. Is that sufficient?
Cheers,
Ryan
We used to store (and I’m currently hacking 6_2 to do the same), the values for TilesInX, TilesInY, TilesRendering, RegionRendering.
If you’re picking up someone else’s file you don’t want to have to guess how many tiles were used last time, or to even have to check whether it was submitted as a Tiles Render or a Region Render.
We had, and no longer need, a CropsTileRendering feature which was basically the Tiles Rendering function in the SMTDFunctions but set to render a region as tiles. This was also kept so you knew exactly how a file was last submitted.
I think it’s good the Jigsaw segments are saved with the camera, although that might be annoying for referencing situations, I will have to do some more tests.
To be honest I’d prefer every setting with Deadline was persistent with the file so you’re always sending to the right group/priority/draft settings etc… but I guess that’s why I invented HydraGen 
Just need to put the rest of the Deadline Settings in!
You can save the info out to an INI file as well as saving the info into the camera. Both functions can be seen in the maxscript. Personally, I prefer the camera approach as you can share multiple camera setup’s easily between scenes and then maybe even store all the cameras as max files in a side-lined file server location or inject the info into a db, for future ref, etc.
I would have an option to automatically load tile settings per Camera and automatically save Tile Settings per camera.
I’d want to change camera view and automatically see my different render regions.
You can. Just store multiple Jigsaw region setup’s per camera. You can piggyback on the SMTD functions if you want to create lots of Jigsaw region setups per camera and calling the “Get From Camera…” functionality it could be automated by a studio’s render pass management to auto retrieve them if they so wished.
The Jigsaw UI is camera context aware, so when a certain camera is currently being used as the view, you can only restore saved Jigsaw regions for that camera. Can be automated by a studio if they wish, but I can also see it being annoying having multiple regions/tiles popping up all over the screen, when I change camera and I’m trying to submit.
Yep all makes sense and it’ll be stuff I implement into our version of SMTD, but I always like to share these ideas and try get them put in so I don’t have to re-update our SMTD every version 
And of course Auto-Region per camera will be a feature in HydraGen Also the ability to get Regions from the non-rendering camera etc…
See Attached, a fairly common setup where we’d want to have entirely different region setups per camera, currently I have to STORE each setup with each camera and then GET it from each camera every time I want to submit a render. I’m lazy, I want this automatic, or at least an option to have it like that
Thanks for the useful feedback Dave. I’ll add it to the wishlist.
Cheers,
Mike
Any update on this? Every update to Deadline I have to put the persistency back in. I cannot imagine not having it in our Deadline…
Hi Dave,
The ability to remember the MultiRegionRendering mode has been implemented in upcoming v7.0 (currently in beta) and also back-ported to upcoming v6.2.1 (currently in beta). Both latest builds are currently available in their respective beta forum build section.
Just need to add the following entry to your “SubmitMaxToDeadline_StickySettings.ini” file:
[MultiRegionRendering]
RegionRenderingMode=true
Feel free to share if there is something else you want implemented into SMTD
Hi Mike, are these Sticky settings saved per file or user settings?
All sticky settings in SMTD are per user.
Currently we do not store anything per-file except for the region definitions.
I believe RPM supports that though.
I suspect it would be possible to use a persistent global to store the SMTDSettings struct instance, but we have never done that before and I am still not convinced it is a good idea. You are welcome to play with the idea though.
We do 90% of our rendering through HydraGen now which of course keeps all the region/tiles/prepass/priority/groups/pool/limits settings for which-ever pass you want. This just eliminates any potential mistakes when somebody else has to work on an existing project, otherwise there are too many variables that could mess things up. I had to pick up a project the other day involving 4 shots, and 8 render passes for each of these and there were different group assignments for certain passes and some had different Tile Counts, and some were Region renders. If I had to ‘know’ these settings or ask him what he had set for every pass then I’d inevitably make mistakes. As it was I just updated the master scene and set all 32 render jobs with dependencies and Tile Stitching passes in a matter of minutes.
But for those occasions where we are using the standard SMTD dialog I can honestly say that I cannot imagine working without having the Tiles Settings being Persistent. Back in 5.0 I put in Persistent Globals for TilesRendering, TilesInX TilesInY, RegionRendering, and have put these in every update since. The only issue these cause is occasionally when you leave the dialog open and open a new scene, I need to put a callback in to pick up the new Persistent Globals.
The problem with using a struct instance would be when Deadline versions update, especially with values which change type (VRay are much worse at this than Thinkbox).
I think the SMTDSettings should all be persistent really, I’m going to add all of the settings to HydraGen at some point, but need to look into how RPM borrows the interface.
I’ll try testing it out and report back…
Dave