Unit Render Python Script for Poser

Micaelus

aspiring scholar
Joined
Jul 11, 2002
Messages
329
Location
USA
This script automates the tedious process of using Poser to render all of the frames for animations in the Civ3 unit creation process and preparing them for combination using Steph's Storyboard Builder (SBB). It will automate the rendering of any number of animations, with any number of frames, even from different Poser.pz3 files, in all 8 Civ3 orientations, and place the rendered frames in the appropriate folders for each direction and animation. It accomplishes this by directly manipulating the y-Rotate values of the Rotate Ball prop and cycling through the animations, orientations, and frames. The frames for each animation will be numbered consecutively from 0000 to the last frame, allowing them to be immediately combined with SBB.

Included in the .zip are:
-3 versions of the Python script (extension .py):
---An example from my Medieval Balkan horsemen
---A template with input cues and standard values
---A blank version, with no values in the input spaces
-A readme with full instructions for using the script
-The series of empty animation folders into which the script places the rendered frames, included for convenience.

Needed but not provided: Notepad or other plain text editor.


Get the script here.


This script was inspired by the Batch Gen program.
 
Brilliant! I will give this a try with my next unit, which I am ever so slowly working on. I imagine that the render times for this unit will be rather long, so this script is most welcome and incredibly timely. Thank you.
 
I gave the script a try today, just one animation. After a couple of hours, I was able to get it to work. I don't know anything about Python, so it was an adventure. I'll share what I found out below.

I have a question though. Does the script create a movie or does it render individual frames? If I remember correctly, when rendering a movie as still images, the lights, the rendering of the shadow map, the adding of objects, etc. is done only once, before the first frame is rendered. I noticed that all of these are taking place before each frame is rendered, which makes the render time much longer. Is there any way for this to be altered?

I don't mean to be critical because I love the script! I'm so thankful I don't have to sit around and do all the rendering work myself anymore. I'd just like to see it be even better, if possible.

mac users
If you are working on a mac, you need to alter the way the directory paths are written. Use ":" instead of "\\".

My file path looked like this.
"Macintosh HD:Users:username: Documents:Civ3 Creation:Units:Unit Name:File Name.pz3"

My output directory path looked like this.
"Macintosh HD:Users:username: Documents:Civ3 Creation:Units:Unit Name:Animation Folders: run :"

Also, toward the end of the script, where the instructions for naming the file are given, you need to change a "\\" to ":". It should be pretty easy to spot.


Render Settings
No matter what I did, the saved renders always came from the render window. I normally always render to a new window. Imagine my surprise when I expected to find 150x150-sized windows, and they turned out to be 400x400. Even when set the document window size to 150x150, it didn't work. I just got .bmp images that looked like previews in Poser.

The solution was to just set the document window size to 150x150, and render to the document window. Everything seems to be fine now.


ROTATE BALL or ROTATE_BALL
Once I worked out how to get the directory path written correctly, I was able to get my file to open. Unfortunately, the error message popped up immediately afterward. I couldn't figure out what the problem was. As I looked through the script, I noticed that it was looking for a prop named "ROTATE BALL". I opened my file, and I noticed that my prop was named "ROTATE_BALL". I knew they were the same thing, but the script didn't. :) So, if something isn't working, double-check the name of your rotate prop.
 
@utahjazz7 - First off, thank you very much for taking the time to test this out and see if you could get it to work. I'm sorry it wasn't as straight forward for you as it could have been...I'll be looking into any ways I can ease the pain, since--after all--this is supposed to make things easier!

Does the script create a movie or does it render individual frames? If I remember correctly, when rendering a movie as still images, the lights, the rendering of the shadow map, the adding of objects, etc. is done only once, before the first frame is rendered. I noticed that all of these are taking place before each frame is rendered, which makes the render time much longer. Is there any way for this to be altered?

You're right--this renders individual frames since that was the only way I could see to code it. I'm still looking into how to code the rendering of a movie not as an .avi or .swf but as individual frame .bmps, however PoserPython is somewhat limiting and the documentation provided is slim to none, so I'm not particularly optimistic about the chances of improving this. This does significantly slow the render process with complex units and when hiding underlying body parts is not an option, so I will keep looking.

mac users
If you are working on a mac, you need to alter the way the directory paths are written. Use ":" instead of "\\".

I should have checked to see if there was any difference for Macs...sorry about that, I didn't even consider it. I could make the adjustments and upload another version...that might be the best way of handling that oversight.

Render Settings
No matter what I did, the saved renders always came from the render window. I normally always render to a new window. Imagine my surprise when I expected to find 150x150-sized windows, and they turned out to be 400x400. Even when set the document window size to 150x150, it didn't work. I just got .bmp images that looked like previews in Poser.

With Poser 7, I set it to render to an exact resolution of 150x150 (Render > Render Dimensions > Render to Exact Resolution)... There is no 'Render to a New Window' setting. With Poser 5, I wonder if it would be best to have this set with the appropriate dimensions. Or, if that's what you did, did it not work?

If it's not a version difference, I'm wondering if the issue here is that, just as the script is based on a prop named "ROTATE BALL" not "ROTATE_BALL" or anything else, it looks for a camera named "Main Camera", not "Main_Camera" or the like. If it can't set that as the camera, it defaults to the preview window, I would assume, but that's only my conjecture.

If neither of those fixes it, I could look into adding code for setting the render dimensions, etc, rather than leaving that up to the saved Poser file.
 
Question: What if you use some other rotation method than the (IMHO) inefficient and unnessesary rotate ball? I just parent the main figure (and any props not assigned to the main figure) to the ground plane object, and rotate that.
 
Question: What if you use some other rotation method than the (IMHO) inefficient and unnessesary rotate ball? I just parent the main figure (and any props not assigned to the main figure) to the ground plane object, and rotate that.

Then you will have to amend one line of code.

Find the following line:
scene.Actor("ROTATE BALL").Parameter("yRotate").SetValue(RotateBallValue[ThisDirection])

It is located under the heading "Poser will render, outputting all frames in all orientations"


Replace it with:
scene.Actor("GROUND").ParameterByCode(poser.kParmCodeYROT).SetValue(RotateBallValue[ThisDirection])


That's all there is to it...so long as everything is parented to the Ground plane (rather than the Rotate Ball) it should work in the exact same fashion. (This is not just theoretical...I've just tried it.) Similarly, this process can be used for whatever figure or prop ('actor') is rotated on its y-axis to achieve the various orientations. So long as the name of the figure or prop, as it appears in Poser, is typed accurately within the parentheses for scene.Actor("<HERE>").Param--- the script will rotate it accordingly and the output will be correct.
 
Following up on:
I have a question though. Does the script create a movie or does it render individual frames? If I remember correctly, when rendering a movie as still images, the lights, the rendering of the shadow map, the adding of objects, etc. is done only once, before the first frame is rendered. I noticed that all of these are taking place before each frame is rendered, which makes the render time much longer. Is there any way for this to be altered?
You're right--this renders individual frames since that was the only way I could see to code it. I'm still looking into how to code the rendering of a movie not as an .avi or .swf but as individual frame .bmps, however PoserPython is somewhat limiting and the documentation provided is slim to none, so I'm not particularly optimistic about the chances of improving this. This does significantly slow the render process with complex units and when hiding underlying body parts is not an option, so I will keep looking.

I have to report that, after checking a couple Poser Python forums and completing a number of futile tests, there is no way to get around the fact that texture and shadow maps will be re-drawn and re-rendered with every frame by this method, slowing the process as compared to rendering a movie of .bmp frames. There is no way to duplicate this process using Python (only Flash .swf movies can be rendered as such) and textures are loaded and shadow maps rendered with every call of the render function.
 
Thanks for the tip, but OUCH! If that's the case, I think I'll stick with rendering using the BMP sequence... Poser is slow enough on my computer as it is without running something that makes it even slower.
 
I have to report that, after checking a couple Poser Python forums and completing a number of futile tests, there is no way to get around the fact that texture and shadow maps will be re-drawn and re-rendered with every frame by this method, slowing the process as compared to rendering a movie of .bmp frames. There is no way to duplicate this process using Python (only Flash .swf movies can be rendered as such) and textures are loaded and shadow maps rendered with every call of the render function.

Oh well. Thank you very much for looking into it for us; I appreciate the effort.

I don't think that it will normally be such a big problem, but the Polish Archer unit that I was rendering had a lot of objects and some of the props had more polygons than were necessary--I'm still getting used to Blender. :) And, I was working on my laptop, which renders fairly slowly anyway. When I get home at the end of July and work on my desktop computer again, it should be less of a problem.
 
With Poser 7, I set it to render to an exact resolution of 150x150 (Render > Render Dimensions > Render to Exact Resolution)... There is no 'Render to a New Window' setting. With Poser 5, I wonder if it would be best to have this set with the appropriate dimensions. Or, if that's what you did, did it not work?

At first, my document window was set to 400x400. The render settings were set up to render to a new window at 150x150. When the script ran, the frames were all rendered to a new window which appeared to be 150x150. But, when I looked at the rendered images, they were all 400x400.

Then I set the document window size to 150x150, and I left everything else the same. The frames were rendered in new windows at 150x150. But, the rendered images were not saved. The saved images appeared as if I had taken screen captures of the document window in its preview state and saved these images.

But, when I turned off rendering to a new window, and rendered within the document window, everything was fine. It's probably even better to do it this way. When the images were rendered to new windows, they were not automatically closed after being saved. Instead the stacked on top of each other. With rendering in the document window, there's no problem with 100's of windows popping up.

If it's not a version difference, I'm wondering if the issue here is that, just as the script is based on a prop named "ROTATE BALL" not "ROTATE_BALL" or anything else, it looks for a camera named "Main Camera", not "Main_Camera" or the like. If it can't set that as the camera, it defaults to the preview window, I would assume, but that's only my conjecture.

If neither of those fixes it, I could look into adding code for setting the render dimensions, etc, rather than leaving that up to the saved Poser file.

I checked, and the Main Camera is named just as it is in Poser7: "Main Camera". So, that is not the issue. But, again, as long as I set the render settings to render to the document window, and have the document window with the proper dimensions, everything works perfectly well.
 
Today I have tried the Micaelus` Python script for the first time.

Micaelus, thank you very much for such a helpful utility. With it I can make units with less efforts and with more patience. :)

Utahjazz7, thank you very much for explaining how to resolve some of the same problems you`ve met before.

All is working well ! :)
 
Okay, I tried Micaelus' poser script, and while it does cut down on overall rendering time somewhat (not having to manually rotate and re-start the "render movie" bit really helps here), here's a few things I found that need to be addressed in case there's anyone else who's as eccentric as I am when it comes to unit making:

First of all, I use the Ground plane object in lieu of the rotate ball, because (a) the Ground plane has to be visible anyways in order for you to get the correct shadows, and (b) Rotate Ball: ~58000 polygons; Ground Plane: 1 Polygon, therefore my method should significantly reduce render times and file sizes.

THIS is the line that should be used for the ground plane:

scene.Actor("GROUND").Parameter("Turn").SetValue(RotateBallVal ue[ThisDirection])

Additionally, I have all my units set up so that the "0" orientation is the SW direction, whereas the script is set-up for 0 = S

I had to go through and change all the number settings on the line with the degrees listed. In addition, Micaelus had the 180 degrees setting as "180", and I've found that in Poser 5, at least, setting the rotation to 180 can cause weird errors with figures that have been conformed to the main figure, therefore I set it to -180, which, for some odd reason, fixes that.

Other than these three little annoyances, the script works great. ;)
 
I'm so in love with this script I've got to bump the thread. I missed this when it came out but thanks to Plotinus mentioning it, I definitely adopted it.

Thanks Micaelus!

Maybe this thread should be stickied ?
 
Top Bottom