Welcome to the Soylent Green Software Division Soylent Green Software Division has no affiliation or connection whatsoever the warez site (probably defunct - thank you) going by a similar name.

Hey! While you're here, check out one of our hip T-Shirts!

Using the GPL avifile package from Eugene Smith, I was able to put together divx_encode. It's still early beta, and far from slick. It's interface is similar to mpeg_encode, where you specify everything in a config file. But the config settings are much simpler and fewer than mpeg_encode.

Unfortunatly, for Alpha and PPC users, avifile depends on using WINE,and the M$ codec, divx32.dll. I hear native DivX support is coming in the next release of libMpeg, so there's hope for the future.

To use it, you need to get and install avifile and the divx32.dll from here. It has the added advantage of suppling "aviplay" that can view DivX-; avi's).

Then unzip div_encode.zip in the avifile-x.xx directory. "cd" to divx_encode and type "make". It can be run locally (./divx_encode config), or can be installed by becoming root and doing a "make install".

Here is a test avi I made. Please view it and tell me if it decodes properly on your system.

There are rumors that DivX is a M$ proprietary product. Not true. M$ tried to make it so, by only allowing their codec to write Divx in their proprietary ".asf" format. But they didn't have that <sarcasm> brilliant </sarcasm> idea until after rev 3.2. People caught on to what they were doing and wrote software to make Divx encoded avi's using the older codec. Nice catch guys.

Top

It has been done in the past with paths, dupliverted meshes, and time offsets, but there was always one problem - As soon as you move the thing, the time offset includes the motion of the tank. You end up with tread flying around all over the screen. Each piece is a duplicate positioned where the original was n frames ago, and n frames ago it was half way cross the screen. So I finally sat down and wrote a script that could do this right. It still neds some work, if you change speeds, the tread slips. If you rotate the path, the treads get twisted . . . Stay tuned for more, but here's a preview(tread.mpg 253k) . If you care to look deeper, here's the zipped Blend file (tread.zip 46k).

Now this one is . . . Odd. This is a 4D texture. (Actually, only 3D, but the forth is Time, not Z). With this plugin, you can specify a velocity and acceleration of the rings, with (rings2b.mpg 123k) or without (rings2a.mpg 56k) noise. The zipfile (rings2.zip 6k) contains source + linux i386 .so lib. Like all our plugins, send me compiled versions for your platform, I'll toss them in the zip.

Mmmmmm. . . Fish flavored candy. . . Same deal as the pie plugin. Source + linux i386 .so lib here (15k). A little more complex than my first, this one returns intensity, color, and normal. A Windows .dll added already. Thanks IcemAn.

My first plugin. Generates a pie shaped texture on an object, zipfile (47k) contains source, and a libc6 linux-i386 .so file. If you get it to compile on your platform, I'll be happy to add those executables to the zip (for all the compiler-less people out there). Current source rev: 0.1.1. Date modified: 7-18-00. Added a Rev label, Fixed a namespace problem on Solaris. Added a Win dll to zip, but it's 0.1.0 - No big changes there.

Top

Sample Remote Render shell script for Blender. rdslave.txt (1038 bytes) This was made on a Linux Box, but should run fine on most Unixes with a bash-like shell.

It may run with a lot tweaking on windows using the dosnix package available here . But I doubt it. See the top of the TODO list.

It's not meant as a replacement for the "official" Render Daemon. It was built as an example of my idea of how the RD should be done. While it's not the official direction of the current RD (they dislike the dependency on remotely mounted file systems), I think (hope anyway) a few of the points it made should help the RD team build a better product (like allowing use of remote file systems if available).

Instructions:

• Make sure the .blend file has relative paths for textures and render destination. (start with //). This is so if the mount points on the slave machines are different, it doesn't interfere.
• Share the file space using SMB or NFS (or ANY other Remote FS).
• Make a file in the same directory as the .blend called "todo.txt". In this file type a list (one per line) of the frames to be rendered. (I know, it's awkward. I'm working on a better way.)
• Start the rdslave script with the .blend file as the argument.
• there is no step number 5
• Repeat on as many machines as you like.

• Convert to python for portability.
• Make todo.txt parser understand things like '1-100' so we don't have to list the frames on individual lines.
• Minimize the loading overhead
  • Set a definable 'Chunk' size so overhead is only seen every N frames
  • Make an 'Idle' (no pun intended) loop script, so Blender will load and spin its wheels until a frame is ready on the server. (You know - Idle... Python...)
• stay out of the way of the real render daemon team :)

I saw about 1.2 seconds per frame difference between starting on instance of blender to do 10 frames, and starting 10 consecutive instances each doing 1. On a machine with sparse memory, it can be much higher though, like 30%.

Top

Created with Ascii.