Hi,
Can the new Draft Tile Submission UI be more intelligent, like the old TileAssembler UI submission. Maybe even better?
ie: instead of asking for a Draft ‘configuration file’, it would be mush more useful if the UI has the same functionality as the TileAssembler UI - ie: checkboxes for all the options available, a file/directory browser, allowing for the selection of already rendered “region” rendered files, automatically calculate how many tiles/regions there are, based on RegEx’ing the multiple files on disk. Also, being able to “recursively” scan a directory on disk INSTEAD of selecting the files individually OR by directory, would be excellent and was missing from the old TileAssembler UI code. Automatic Job Naming convention, based on the name of the region files to be assembled. Job name gets updated either when you select a new set of input files OR cycles through the job names as it submits the various input files recursively into the farm.
Perhaps, once it’s scanned a directory for possible files to assemble, provide this back as a list for selection before submitting to the farm for processing, would be nice 
Finally, would be handy, to have a monitor RC job script, to submit a Draft Tile Submission job, pulling in all the render output information from the currently selected (could be multiple job selection) jobs. IIRC, there use to be an old TileAssembler job script that did this…? (maybe I wrote this in-house…? can’t remember!)
Thanks,
Mike
Hey Mike,
I’m not sure how this would work, since the configuration file is a necessary component to allow Draft to do the tile assembly. This configuration file needs to be generated by the script that is submitting the tile job, and it replaces the tile_nXm_xXy naming convention from the old system to allow for greater flexibility (ie: different sized tiles, incomplete tile sets, etc). With the new system, the file name for each tile doesn’t give any information to indicate where that tile belongs in the final image, so building that configuration file based on a list of selected image files really isn’t feasible.
Cheers,
Ah, I see that now…hmmm…this concerns me.
I can see situations (indeed I’ve been in them) where ad-hoc is required, post 3D render job submission, where the original submitted job is long gone…
So, I had in my mind that the naming convention would be enhanced and not replaced when it came to Draft Tile Assembler introduction:
old way:
tile_nXm_xXy
new way (in my head):
tile_tX_tY_region_x_wXh
where _tile_tX_tY is particular X and Y tile position, which in turn is part of “region” X and the overall image resolution, w(width) X h(height).
Here’s an example from the current v6.1 beta 3 “draft_tile_config.txt” schema for 1 particular render pass coming out of 3dsMax:
current way:
ImageFileName=C:\mike-test-render0050.png
TileCount=112
ImageWidth=640
ImageHeight=480
Tile0FileName=C:\mike-test-render_region_1_0050.png
Tile0X=0
Tile0Y=420
would become:
ImageFileName=C:\mike-test-render0050.png (RegEx auto-calculated by removing “tile_0_420_region_1_640x480”)
TileCount=112 (calculated by adding the number of images in the particular directory path via a RegEx)
Tile0FileName=C:\mike-test-render_tile_0_420_region_1_640x480_0050.png
…
Finally, for monitor submission, the “draft_tile_config.txt” files would be created on the fly during monitor submission and submitted as std aux files as per the current setup. The RC monitor script would just pipe currently selected job render output info into the monitor submission script.
What if instead of submitting the config file with the job, it was created in same directory that the tiles would be saved to, and the job would just reference it? That way, you will still have the config file after the job is long gone. The config file really simplifies things, and ideally we’d like to stick with this approach rather than get into more and more complicated file naming patterns.
I totally agree. KISS. But what if the config txt file is deleted or the user changes the tile/region configuration and then overwrites some or all of the tiles/regions in that directory.
Both cases, the config file submitted with the output footage doesn’t cover it off. However, you can submit the config file into the repository (current setup) AND if the Draft config file was named UNIQUELY, then any footage overwrite, would mean, the subsequently submitted Draft config file wouldn’t be overwritten, as its called something like: “DraftConfigFileO_jobID.txt”. Compromise?