Question the second, where can I find any documentation on using AutoLISP commands with AccuRender?

[Jim]

I've written a few scripts in AutoLISP for animating scenes, essentially making small incremental changes and then rendering after each change. I'd love to do this with AccuRender combined with nxtfarm to churn out some animations.

[Roy Hirshkowitz]

It hasn't been documented-- but I do have a few and may be able to add some.  Let me know what you need.

[Jim]

Just in the short time I've played around with the nXt trial version I can tell this will be well worth it and produce some amazing animations.

 

Here's a snippet of the code I use in AutoLISP in a loop:

 

 

(command "-VIEW" "r" "camera1")

(setq fileName(strcat "C:\\animation\\camera1-" (itoa angle) ".jpg"))

(command "-render" "p" "r" "1280" "720" "yes" fileName)

(command here to move the piece in the scene)

 

 

So basically, commands to set the resolution and filename would be a great start. Also setting the number of passes would be useful. If there's a way to have nXt automatically save the image with the given filename after hitting the set number of passes, I think I would be set.

[akinlolu olugboji]

I pray this wonderful project could also be shared with the open community as a whole.

[Jim]

Agreed. I was pretty disappointed when I found the thread from 2011 asking for more AutoLISP interaction only to find that it seemed nothing had been done since then. The more AutoLISP functionality that can be added, the greater the opportunity for nXt render and renderfarm to produce some really amazing stuff with little effort.

EDIT: not that it doesn't already produce really amazing stuff :)

[Roy Hirshkowitz]

Without the render farm, this should be pretty easy. Some of this probably exists. OTOH-- doing object animation with the farm as it's currently configured will produce an enormous amount of data. We'll need to extract a new model file everytime something changes in the scene. The additional storage and network loads imposed by this could easily, depending on model size, negate any benefits derived from using multiple machines. Would you want to proceed without the farm, at least initially?
In any case, it may be a little while-- I'm traveling right now and I've got at least one other item on my plate to finish up first.

[Jim]

Well here's how I'm looking at it. The script I wrote in AutoLISP does fine at producing images with the native renderer, it just takes too long. at 1280x720 each frame takes up to ten minutes on my computer, and I would like to move up to 1920x1080 eventually. I came across AccuRender by searching "AutoCAD render farm" in google. So, the farm is basically the main reason I'm here; the giant leap in image quality is just a delightful bonus.

 

One nice thing I think I figured out about the farm is that I seem to be able to make it work with computers not on the same network. I don't have a licensed copy of nXt yet so I can't send anything to the farm for test rendering, but I can get plenty of other computers to appear in the farm monitor by pointing them to a folder inside of a Dropbox. Right now I'm at work, and my computer at home is showing up on the render farm monitor. I think this could potentially be a solution to rendering through Amazon EC2. Just set up a render farm on each with a Dropbox and suddenly you've got a massive, scalable farm.

 

Anyway, the one problem I foresee (and maybe there's a solution) is the way that the farm reconstructs images, as described below in the wiki:

 

After the job is complete, output can be found in the job's Output folder. To reconstruct the output into a single image use the following steps:

1. Open the nXt Image Editor.
2. Load the first image of the sequence, 000000.nXtImage
3. From the menu, select Image→Arithmetic→Add for the standard engine –OR– Image→Arithmetic→Combine Path Tracings… for the Path Tracing engine.
4. Select all of the other images in the sequence (do not select 000000.nXtImage again or it will be counted twice)

Having to go through that process for every single render could also negate any time saved by automating with AutoLISP. The real benefit of this code:

(setq fileName(strcat "C:\\animation\\camera1-" (itoa angle) ".jpg"))

(command "-render" "p" "r" "1280" "720" "yes" fileName)

Is the way I can set the renderer to automatically name and save each render without any additional work, so once the script is (eventually) completed I have every single image in order ready to be loaded into movie maker to produce the final animation. I'm guessing that some kind of system that would automatically combine the finished .nXtImage files from the farm and output a .jpg or .png is probably not a high priority at the moment.

One more thing to note is that the scenes I'm talking about aren't as insanely complex as the ones in the gallery on the site here. This is an example of a test video I made at 720p using my script with the native AutoCAD renderer. Using AccuRender on this scene, it seems to stop changing the image at all after about 10 passes, and anything beyond 20 seems to be complete overkill.

[Jim]

Actually I just had an idea. What about a render farm mode that sends each computer only one individual render at a time, then saves the completed image automatically? For large scale animation projects, it would make more sense to me anyway to have 30 computers each working on one image at a time, rather than each computer working on 1/30th of the same image and then have to manually compile it later. I don't know how feasible it might be though.

[Jim]

Some other things that might be nice to control via AutoLISP:

-Light Preset

-Date and time of day for Exterior lights

-Use Plants

-Use Materials

-Use Colors

-Total Passes

[Roy Hirshkowitz]

nXt's built in animation on the farm already outputs sequenced .png files for direct use by a movie compiler.  Each computer is given a few frames to render to amortize the cost of reading the model-- otherwise the process is similar to what you're describing.

I'm inclined to say no to the render farm request at the moment-- it's a lot of work and the performance will very likely be disappointing.  OTOH I'm willing to implement a few autolisp commands that aren't there and/or tell you about the ones that already exist.  You'll still be able to run your script-- it will only render locally though.  Again, let me know if it's something you still want to pursue.

[Jim]

That's a good start and I'm willing to take it. The main problem I have with -RENDER in AutoCAD is there is no way to suppress the render window, which keeps all of the previous renders in memory as it writes the new ones. There is no way to clear the old ones after they've been saved, and often I'll run out of memory before completing. If nXt starts from a clean slate every time, it would be a huge advantage.

[Jim]

I did notice that the nXt animation produces png files in sequence according to the wiki. The difference it seems that the nXt animation is simply moving the camera, whereas I keep a stationary camera and move objects in the scene.

[Roy Hirshkowitz]

The following already exist in the current build and should work fine for your purposes (let me know):

(nxtrender nPasses)

Renders modally for the set number of passes.  nPasses should be > 0.

Example:

(nxtrender 100)

(nxtsave sFilename [bAlpha])

Writes a .png file from the current buffer.  Include the extension in the name.  Set bAlpha to 1 to mask out the background with an alpha channel, or leave it out to retain the background normally.

Examples:

(nxtwrite "c:/my folder/frame_0001.png")

(nxtwrite "c:/my folder/my image.png" 1)