Can Jigsaw assemble the regions it renders at the correct image size of the render? At the moment it is cropping the image to the edges of the regions that have been rendered, so when it comes to overlay in Photoshop, everything needs moving into position. (ie the render is 5kx2k, and the assembled region image is 1kx2k)
I could have sworn it used to render the full image size and have the regions in the correct position, so maybe I have the wrong option selected? It is set on assemble over empty background (output over previous image wont work for us as things usually change)
The way Jigsaw renders its tiles for the Draft Tile Assembler is to crop the tiles to the size of the region, plus eventual padding. Then, in the Draft Tile Assembler control file, it specifies the upper left corner location of the tile relative to the full image. To do this, the SMTDFunctions.CreateJobInfoFile() function writes out the key pair
RegionType=CROP
The other options for the region type are RegionType=NOCROP and RegionType=BLOWUP.
The “3ds Max Region Rendering” rollout offers a drop-down list with those options (Region, Crop, Blowup).
In your case, you are asking for the Region (NOCROP) option, but it is not exposed in the Jigsaw controls - Jigsaw always defaults to CROP.
If you are not using the Draft Tile Assembler to assemble your images, but you are doing the assembly manually in Photoshop, then you would have to modify the JOB file after it has been written to replace the line
RegionType=CROP
with
RegionType=NOCROP
Then all tiles should end up at fill output image resolution, and you could paste them on top of each other in Photoshop without knowing the exact placement of the upper left corner of each one of them.
That being said, it would be possible to add this as a feature to the SMTD Jigsaw code. We could have an option that switches Jigsaw between CROP and NOCROP, and then the Draft Tile Assembler control file needs to have the matching line TilesCropped=True (which is the current hard-coded value), or TilesCropped=False when NOCROP was specified for the renderer. As result, the tiles would be saved as full res. images, and the DTA would still read only the pixels from the specified region of the uncropped file, and paste at the correct location of the background image. But then you could open in Photoshop and do what you want with those full res. images…
Btw, you could modify your SubmitMaxToDeadline_Functions.ms file for now to always submit Jigsaw with RegionType=NOCROP, and set the TilesCropped=False in the Draft Tile Assembler’s control files if you want to test it out. I can tell you which lines to modify if you want to try that…
Thanks for that info. As a workaround I set Jigsaw to render a small tile in the top left and bottom right to give it the correct dimensions on output.
If you can show me how to force the NOCROP on Jigsaw that would be great, as every region we send would always need to be the full image size to comp.
Also, what would be the best way to retain changes made to the repo scripts when updates happen (apart from keeping a big list of what needs changing manually?)
In SubmitMaxToDeadline_Functions.ms, locate the code block that looks like
)
else
(
format "RegionPadding=%\n" SMTDSettings.TilesPadding to:JobInfoFile
if SMTDSettings.TileBlowupMode and tilesRendering then --SMTDSettings.TilesRendering
format "RegionType=BLOWUP\n" to:JobInfoFile
else
format "RegionType=CROP\n" to:JobInfoFile
)
and change the last format from CROP to NOCROP:
format "RegionType=NOCROP\n" to:JobInfoFile
Then locate the code block inside the fn SubmitDraftTileAssemblerJob that looks like:
format "TileCount=%\n" tileCount to:draftConfigFile
format "TilesCropped=True\n" to:draftConfigFile
format "DistanceAsPixels=True\n" to:draftConfigFile
and change the TilesCropped line to False:
format "TilesCropped=False\n" to:draftConfigFile
Note that I haven’t actually tested these changes, but looking at the code, they should make Jigsaw render non-cropped regions, and the assembler will expect them to be non-cropped. Make sure you have a backup copy of the MS file in case it does not work. I will be on a business trip the rest of this week and might not be able to keep an eye on the forum…
Currently your only hope is that we will include the changes you need as features of the next SMTD update. If you report that the above changes worked correctly, I will add a checkbox option to the Region rollouts to control the CROP/NOCROP behavior of Jigaw and Tile regions in the next version of Deadline. Otherwise you would have to make the changes each time a new update is installed…
Error: Renderer returned non-zero error code, 1. Check the log for more information.
at Deadline.Plugins.PluginWrapper.RenderTasks(String taskId, Int32 startFrame, Int32 endFrame, String& outMessage, AbortLevel& abortLevel)
=======================================================
Type
at Deadline.Plugins.SandboxedPlugin.a(DeadlineMessage A_0)
at Deadline.Plugins.SandboxedPlugin.RenderTask(String taskId, Int32 startFrame, Int32 endFrame)
at Deadline.Slaves.SlaveRenderThread.a(TaskLogWriter A_0)
Turns out we also need to supply the Tile Width and Tile Height when the sources are not cropped (duh!), so the Draft Tile Assembler can crop them internally.
If you are going to composite them yourself in Photoshop or another application and you don’t intend to use Draft Tile Assembler at all, then the changes you made would be ok - the tile images should be now full resolution, uncropped. Just disable or ignore the DTA job.
If you want to use the Draft Tile Assembler, we need to add a few more lines to the function that creates the DTA control file to supply the width and height. Unfortunately, it is not exactly trivial. Let me know if you want me to look into it.
Then I must be missing the point - if DTA is recompiling the image, what do you care how the tiles were saved if the final image is made whole anyway? Or are you using the tile images for something else in addition?
I will look into this, but once again it turns out it is not trivial since I don’t collect the region size info during submission and will have to heavily modify some already scary code.
