I figure this is very likely built into Netrender, but has anybody done their own render job automation with the "Non-Netrender" version of A:M? I've been wondering if I could use something like a command line script to que up multiple rendering sessions.

At this point I'm mainly curious whether it's possible. I've purchased a second copy of A:M specifically so I can have one machine (legitimately) rendering while I'm happily animating or modeling on another. I'm about to start building a new PC with a quad-core processor to do the heavy lifting part.

I figure, if I have a number of shots worked out, it might make sense to que them up for rendering if there is a command line interface that I could script. That way I could keep the machine busy rendering non-stop overnight, for example, without me having to hover over it waiting to start up the next rendering job.

Anybody know if this is possible in A:M?

Thanks!
Bill Gaylord

It may be possible soon but as of right now unless someone knows some tricks they aren't sharing its not.

The closest I've seen to netrenderless batch rendering has been with Glenn Anthofer's RenderDone program.
He found he could hook into A:M's processes such as final render notification, crashing during render and closing of A:M to run programs and scripts. A:M could even be shut down via RenderDone after rendering was completed.

Unfortunately there didn't seem to be anyway to launch A:M with a render in a que.
This would be a requirement for batch rendering.

There may be a workaround that approximates scripted rendering but I'm sure the solution is going to require Hash Inc's adjustment of A:M in the renderer. Thats quite a tall order and unless already in the pipeline I'm not sure how we'd see it before v15.

Hash Inc is *always* full of surprises though.

If you can find a way to launch A:M's renderer automatically I think you could do semi-scripted rendering even now.

As far as I know only Netrender has those capabilities.
This from the knowledge of a non-programmer.

I'll add this to the mix as well. Yet another hack which would only stab at the issue.

If you can show how to call a Chor from another Chor you have semi-batch rendering capability already.
Once the renderer was launched it would recursively run through the scenes of several Choreographies as if they were one.

Perhaps it might be better to approach this from a different angle?
As batch rendering really isn't the goal... rather than seeking batch rendering what is it that you'd hope to accomplish if you had such a tool?

Perhaps you've answered already:


I'll look into this from my naive perspective.

I was thinking along the lines of some kind of "key stroke" recording application like "Quick keys" that could run after each rendering was complete.

For instance once a render is done, the windows are closed and another chor is loaded and the render to file is clicked... etc.

If the program had an editable line for which chor to open and the saved file name at that point you could "copy/paste" and just change the reference. This wouldn't require any changes to AM at all and could possibly be cross platform (Applescript for Mac and... whatever they use for windows?)

Even if you just loaded and rendered each chor and stopped it before it got too far while recording the keystrokes, then ran all of those "scripts" it would save effort.

Is AM Applescriptable? I don't think I ever checked.

-vern

Therein lies the problem as far as I can tell.
Who knows how to remotely cue up a Choreography?
Who can automate the clicking of the render to file icon?
I sure can't.

I half suspect A:M can take such arguments upon loading... render through if you will... but maybe not.
Hash Inc ain't tellin' all their trade secrets.

'Render to File' can be assigned a shortcut key.
If you can find a program that will hit that key for you automagically... kerboom... You are rendering.
Well... not quite but at least one click closer to it.

'File: Import Choreography' can be assigned a shortcut key too.
Getting a program to import a Chor wouldn't be enough though as it would have to know what Chor to open and click the dialogue button too. I believe the last Chor opened will be the default entry in the dialogue box.

But again, perhaps more importantly, what are the underlying needs that scripted rendering addresses?

I can think of one off hand that might not be obvious.
Having the renderer spit out an image in a low resolution (thumbnail) first and then automatically go on to render a high res version.
The benefit here would be that we get to see our render quickly while the rendering goes on to do the dirty work behind the scenes.

Extending that further...
Lets say I want to sample a high res image to make sure something is going to render properly... a particularly important shot with hair.
If we could just see the most important part of the image we are interested in we could make a decision to continue or terminate the session based on that. If the test meets our approval it gets pushed on to the background renderer.

I would imagine the most apparent use of scripted rendering would be to have a list of choreographies that the renderer would grab and chew on until consumed. This type of rendering would be ideal for greenlighted projects in the cue. In my estimation its not the best solution for determining what we want to render. For that we need evalators and evaluation tools. Are the colors correct? Is this shot too dark? Too light? Too Blurry? How can we communicate our needs to the renderer? How can it respond with a proper solution.

When looking for solutions I like to shoot for the moon.
We may not ever get there but we can usually count on a clearer view.

Scripted rendering could get really complex.
It would need to be pretty complex to satisfy everyone's needs.



Now back to your reality based query Bill. (Sorry for all the Off Topic)

You really should look into RenderDone. I assume it can still be used in v14.
Contact Glen Anthofer and see if he's updated it anymore for himself.

At the very least you'd be able to Render your animations out and shut down A:M immediately thereafter.
If you can then load A:M with another Project automatically you'd just have to Whack the Render to File button.

I'm sure Glen would gladly share his knowledge and code, especially if someone were interested in extending it.

Update: I did find a way to launch A:M and open a specific Choreography.
But as of right now it only opens one.

Edit: Silly me. If we want more than one Chor we just need to load a Project.
That part works beautifully.

So... minor success.

Also, we can shortcut key [File:Close] and [File:Exit] to close the active file and shut down A:M respectively.

Its looking more and more like RenderDone (and therefore Actionscript) could automate this.

Thanks, Rodney! This is looking very interesting. Basically I'd just like to schedule rendering jobs so I can keep the "rendering beastie" busy while I, for instance, get some sleep, or work on other things in parallel on another machine.

Too simple a need. Too basic. You've gotta dream bigger!

For the simple side of things I think we could pick everyone's brains and get to an optimized workflow.
You've got a second A:M and computure for rendering so you are pretty much there already.

RenderDone... RenderDone... RenderDone should be in your future. (Assuming it still works in v14 which I think it does)
If nothing else you could program it to tell you what you've done.
It could launch programs like XNView to post process images, rename files... things you want it to do.
Create a batch file that pushes the date and time into a textfile once a render is completed.

Just having that second computer rendering is going to be a big help.
But I do see Netrender in your future as it can be run on one computer.

Glen's site has version 1.0, but nothing after that. You can find it here.

-Vance

Thanks for the link Vance. I really should have tracked it down but have been getting lazy.
Thankfully guys like you have my back.

Glen did such a great job with that little utility. RenderDone wasn't revolutionary but it answered a lot of little needs... simply.
Sadly, when released it didn't find much interest to keep it in development.