[casey]

I would like to be able to export an MXS file from MAX to a particular filename, not just the one that's manually enter in the Maxwell renderer properties page. Is this possible? It doesn't seem to be. This is a pretty important feature to have for automating batch renders and so forth.

- Casey

[j_man]

Hi Casey,

I don't get it, when you export a Maxwell file using the renderer properties you are exporting to a particular filename. Can you elaborate what you're trying to do a little more please?

Are you trying to batch render? if so, are you using the max batch renderer or the MX command line options?

J.

[casey]

I don't get it, when you export a Maxwell file using the renderer properties you are exporting to a particular filename. Can you elaborate what you're trying to do a little more please?

I wrote an automated system here that takes jobs and distributes them to the render farm, previously it was used with Brazil only but I've expanded it to use Maxwell as well.

When the MAX user presses a button, the MXS file is written to a directory where the distributor picks it up and distributes it to a free machine. If there's no free machines, then the files just pile up and the distributor will send them out when machines become free. The way this was working before is that the MAXScript portion of the code inside MAX just picks a random filename in that directory, verifies that a file of that name does not exist, and writes it out. Done deal. The user does not even have to be aware that this is happening.

Now, with Maxwell, first of all the user has to know about this system and go into their render settings and set the MXS target location to be the distributor directory. Then they have to turn off the automated Maxwell Studio launching. Then when the file gets exported, because the user might launch to renders in rapid succession, the distributor has to poll at a very high frequency to see if new files are appearing and rename them quickly to avoid having previous jobs overwritten (and this process isn't foolproof). Etc., etc.

So what should be a simple one-line command in MAXScript, like

Code: Select all

MaxwellExport ("c:\temp\job" + RandomNumber + ".mxs");

is actually this big tenuous mess on both sides.

Furthermore, sometimes you want to launch multiple renders from the same file. For example, suppose it's a 10-frame animation, and I want to launch all 10 frames rendering at once. Now the MAXScript has to loop through with a sleep timer to give the distributor time to sneak in and rename the previous export... it's just disgusting.

Personally, everything else about Maxwell is awesome for this job. The fact that it doesn't require MAX to be installed on the farm machines is so awesome, I can't even tell you. The fact that it periodically writes out a bitmap with its render progress is even more awesome, it's like awesome^256. I actually added this cool window to the distributor system that shows the current image from all the farm machines as thumbnails and you can view their progress, etc. It's totally awesome! I'd previously wanted a feature like this in Brazil for this very reason.

The lack of MAXScript-accessibility to Maxwell is really the only bad thing about it in the pipeline right now (well, that and the two known bugs of memory leaking forcing you to restart MAX periodically and the lost material names).

As an aside, I really like the MXM material, and the way you use an external editor to edit the materials, but you still link them to your scene with MAX so that you don't have to use Maxwell Studio (which isn't an acceptable pipeline IMHO because you can't then re-edit the scene in MAX without losing all your work in Studio). It would be super-awesome if everything in Maxwell worked this way - so, there was a little app that was the Maxwell Environment Editor, which is just the environment editor from Studio but it saves out a MRE or something and then the 3D Studio plugin doesn't have any of this stuff, just a little file path for pointing to the MRE. Then make sure all the filenames are settable from MAXScript, and it'd be perfect, and highly automatable.

- Casey

[j_man]

What can I say Casey, yes it's a hassle that Maxwell isn't exposed to MXS (erm Maxscript) but I'm hardly surprised. You'll just have to wait or get the SDK out and write you own extension.

BTW you don't have to poll the directory to see when new files appear, why don't you use a #postrender callback (or something) to call your function to assign jobs.
Another great advantage of maxwell with your render wrangler is that the command line rendering lets you change all sorts of settings after the creation of the MXS file, like the target image file, or the sample level etc.

J.

[casey]

You'll just have to wait or get the SDK out and write you own extension.

I would love to get my hands on the SDK, but I thought that there wasn't one available for 1.0 yet?

BTW you don't have to poll the directory to see when new files appear, why don't you use a #postrender callback (or something) to call your function to assign jobs.

Well, that doesn't quite do the trick either, because I still have to rely on the user to properly set up the path of the export, because the #postrender callback has no way of knowing what file was actually written since it can't access that field. But, it's a good suggestion!

Another great advantage of maxwell with your render wrangler is that the command line rendering lets you change all sorts of settings after the creation of the MXS file, like the target image file, or the sample level etc.

I agree, and I already make use of those features... it's great!

- Casey

[j_man]

You'll just have to wait or get the SDK out and write you own extension.

I would love to get my hands on the SDK, but I thought that there wasn't one available for 1.0 yet?

Heck I haven't even looked!

J.