BSAC does not generate frames or animations; it just manages and collects frames.
BSAC does not handle partial frame renders.
There are 2 main components to BSAC, the server and the client. In typical operation, the "owner" of the animation will run the client as the director of the animation and make requests to each server asking it to build frames.
Both client and server run on Windows and Linux (other Unix ports to
be available later)
|+- BuckoSoft Animation Controller
| +- World
| +- Users
+- Tech Overview
| +- Authentication
| +- Files
| +- BuckoRoot
| +- Client
| +- Server
| +- Status Checking
| +- Determine Frame To Render
Each file that is read during a POV-Ray render must be authenticated between the client and server as being the same.
This is accomplished with a date stamp and a checksum. Note that Windows95 uses 2-second resolution on date stamps and BSAC must accommodate that.
Each client/server transaction must authenticate itself to avoid stray frames from undesirable sources entering the stream.
Connections are accepted only between a previously established client.
Each client/server will use 1 TCP port.
Communications port between client/server.
HTTP port used to monitor status of a client or a server and possibly allow configuration.
There are default values for each TCP port, but they must be configurable
to allow for firewalls. The defaults are
Note that if you have any imagemap files, then you will have to include them. Be careful about specing graphics/imagemap files, you don't want to transfer any test renders you've generated! So including *.tga is a bad idea :)
The .bsac file also supports a conditional, it is possible to specify files to be included only in certain frames. Your file may look like this:
if %f > 100
Server System File
Per Project Root
The client and server each maintain a Project Root. All files to be rendered must be beneath the project root. NOTE that this includes POV-Ray system include files as well. It is imperative that the client/server be operating from the same set of files.
Subdirectories are supported.
There are 2 styles of frame generation available.
Striped – When a server finishes a frame, the next available frame is given to it to build. Less efficient than the block method, but better for quickly gathering frames for making test animations.
Block – A server is given a range of frames to complete. The server will send each frame to the client on completion
Servers in Project
Defines how the client views each server
Client tells Meta that he is online. Meta will then query the client about his projects.
[ I want a StatCheck done please. ]
||How you doing?||
|I have these projects that i care about|
||Tell me about project p.||->|
|Project p has x frames of which y need rendering. There are n files and m megabytes of source. Project wants v0 or v1 versions of POV-Ray. Project was created on d date and the last render started on d1. Project p is [in]active.|
||Tell me about the frames in project p [as of date]||->|
|Here is a list of frames with their renderstatus, inc. start time, end time, server, status.|
||Server s is expecting a render request from Client c for project p of n frames starting at frame f.|
||?-||I have finished project p frame f with status pass/fail.|
Client will then send another RenderReq before asking for the frame output file. This allows rendering to recommence before performing the FetchFrame
||Please give me this frame's output.||->|
|Here is the file.|
||Delete this frame's output.||->|
||Delete all of this project's files.||->|