DistRen Files · TODO · protofusion repositories

Files @ abe4f18bd898

Branch filter:

Location: DistRen/TODO

abe4f18bd898 2.1 KiB text/plain Show Annotation Show as Raw Download as Raw

LordOfWar

-added assigned_frames variable to blendjob structure

-adjusted frame_num_struct_builder by adding 1 to the total amount. (line 270)
reason: by example
sframe = 1
eframe = 2

eframe - sframe = 1.. when in reality 2 frames should be rendered... so it is now
int total = (sframe - eframe) +1;

refined frame_finder() function to use the structure for total_frames data... and optimized its frame scanning so that it scanned from (for example) 0 to 249 is 250 because the computer counts 0 as one of its numbers.

the statement in status_report_generator() function that adjust the hcfjob global variable to be able to increase the hcfjob by more than 1 per status_report_generator() function itteration by changing it to a while statement from an if statement.

moved the declaration of the num1 and num2 variables till after hcfjob was checked, because the value of num1 is based off the hcfjob value.

Added ability for status_report_generator() function to calculate the percent_done of the job and count the number of frames assigned, but not yet completed.

Distrend.c FIXIT's, mostly for matt:

1. Struct issues in frameset[frame_count]: frame_count isn't in scope, and defining obviously won't work. This is pretty crucial to the whole thing functioning. fixme!
2. In the frame_finder, ya can't declare variables in for() loops. Unless we're in C99 mode. Which we arent.
Also, sframe, eframe, x, and frame_status are undeclared in the function. Or, rather, they aren't in the scope of the function. Make 'em args?
3. status_report_generator has conflicting types.

1. Create a CLI interface for distren
X command: distren
X args: -i infile.tar.bz2 -o outfile.tar.bz2
action: submits and blocks and retreives result of rendering the contents of infile.tar.bz2. Should currently just call stub functions.

2. Design of stubs in distren library:
X Stub for submitting file to server
WIP Write configuration loader
Stub for submitting file to a server (using a stream)
Stub for waiting for server -> Maybe the client can just poll? I've got to decide this.
Stub for retrieving result (using another stream)

3. Design of stubs in distrend:
Stub for getting info from the tarball/validifying the tarball. Read distren-job.xml, a file in the tarball, to find out 1. which rendering system to use (that system, e.g. blender/povray, can read more specifics, such as name of file to pass to blender and frames. Options common between different systems will be handled in common as best as possible)
Storage of data + metadata: Stubs for unpacking tarball, assigning the submission an ID, and retrieving the file by the submission ID.
Actual rendering: Stub for calling subsystem's action that does the rendering. The subsystem should accept an XML fragment (a libxml subtree) that is specific to the subsystem. Ideally, subsystems will be both pluggable at both the dlopen() and link-time levels. dlopen may actually be easier than link-time pluggables...
Stub for submission of new jobs to be distributed (a subsystem rendering a file with multiples frames should generate a subjob for each frame)
Stub for publishing file and constructing job description so that the job can be shared