submitting RTT render with 3dsmax, output path undefined.

hi folks,

we’re evaluating Deadline for our medium sized farm where we mostly bake out a lot of textures. we’ve been using backburner up till now, and everything that i’ve seen in Deadline has been great so far! i’m really impressed.

the wall i’m hitting at the moment, however, has to do with submitting Render To Texture jobs. i’m getting a MaxScript exception that complains that the output path isn’t set (the path is definitely present in the UI). the error looks like this:

RenderPluginException -- Error in RenderTasks: RenderTask: Unexpected exception (Exception caught in 3ds max: -- Runtime error: ERROR - Render To Texture Output Path is undefined.

deadline’s output path query (\submission\3dsmax\Main\TextureBake.ms) is:

local RTT_SceneData_AppData_Index = 0x41dd73d5 outputPath = getAppData rootNode (RTT_SceneData_AppData_Index+4)

so i did a bit of digging yesterday, and learned that in order for the submission script to be able to properly query the RTT dialog’s output path, you can do one of two things:

1.) TextureBake.ms can be modified to query RTT_data.FileOutput_FilePath instead, but not until the RTT dialog is opened (it doesn’t get populated until then).

2.) TextureBake.ms can be run as-is, but not unless you cause WriteSceneData() (\MacroScripts\Macro_BakeTextures.mcr) to get called, which in turn causes RTT_SceneData_AppData_Index to be populated. One of the things that does this (there are a few manual UI twiddles that call WriteSceneData()) is manually updating the output path in the RTT dialog box. Merely opening the RTT dialog box isn’t sufficient, and the output path returns as undefined.

so in terms of automation, this isn’t ideal. my question is, what’s a safe way to populate the RTT_data structure without requiring user interaction, or to trigger WriteSceneData() (also without user interaction)?

I’m new to maxscript and newish to max, so i’m unfamiliar with common workarounds – in which case, i apologize if the answer is obvious :slight_smile:

any help and/or pointers greatly appreciated.

-tony.

Hi Tony,
Just a quick note to say, that we are looking into this issue for you and you’re not being ignored! We are digging!
Will be in touch as soon as we have something.
Cheers,
Mike

Hi Tony,

I looked (again) at the Macro_BakeTextures.mcr code and while it was not designed to be easily accessed from the outside, it can be hacked :slight_smile:

Here is a piece of code that forces the WriteSceneData() to be executed:

RTT_SceneData_AppData_Index = 0x41dd73d5 --get the appData address
outputPath = getAppData rootNode (RTT_SceneData_AppData_Index+4) --get the path - it would be undefined

macros.run "Render" "BakeDialog" --open the RTT dialog
gensettings = gTextureBakeDialog.rollouts.rollouts[1] --get the first sub-rollout
--Call the changed handler of the "Rendered Frame Window" checkbox
--without changing its current state
gensettings.cDisplayFB.changed gensettings.cDisplayFB.state 
destroyDialog gTextureBakeDialog --close the dialog

outputPath = getAppData rootNode (RTT_SceneData_AppData_Index+4) --get the path again - it should be correct!

OUTPUT:

1105032149
undefined
undefined
Rollout:commonBakeProps
undefined
OK
"C:\Users\Borislav\Documents\3dsMax\sceneassets\images"

I have to ask though why the scenes you are submitting do not contain the AppData already?
The AppData is stored in the root node of the scene graph, and the artist that set up the scene for baking would have triggered the update. If the scene was saved and then loaded and submitted, the AppData would persist. What step are you skipping to end up with MAX files that don’t contain the output path, but contain other Texture Baking settings?

That being said, our implementation of Texture Baking submission is scheduled for a big rewrite in Deadline 7. We don’t like the original Autodesk script, and our submission code leaves a lot to be desired, too. We hope your feedback will help us improve the tool in case you decide to use Deadline in your pipeline…

Thanks, Bobo (and Mike)!

I do indeed appreciate the feedback.

I’m not familiar with the particulars of how the max file in question gets assembled, but it probably has something to do with this max file being assembled automatically from a large series of other files. it’s never opened by a human in the first place :slight_smile:

also, i was just informed that hacking the Macro_BakeTextures.mcr is something that has, shall we say, a certain level of familiarity in the office. i think we’ll be okay from here out. thank you!