domerin0 / distributed-mandelbulb Goto Github PK

• One CameraParams per line
• Space separated value
• Tab separated objects

ex.
location (x.x y.y z.z) \t look at (x.x y.y z.z) \t up vector (x.x y.y z.z) \t fov
14.0 8.0 10.0         0 0 0         0 1 0         1.1

void getPath(char *filename, CameraPath *path, int *len){
    //read till EOF, populate path, return number of camera posistions 
}

Someone should start planning a path by hand. In the event that we don't get the automated path planning working we should have a back up plan.

Maybe 36 "coarse" points to get into the center, a small turn around animation and then use the same points on the way out.

Make quick script to interpolate 100 sub points in between the the coarse points, for the way out use the next course point for the "look at vector"

36_100 points on the way in plus some turn around frames and 36_100 points on the way out

Write out all the points to a path file formatted so the path planner can read it (7200 lines)

make it work with single precision

Ned has provided links to some of the functions to generate MandleBulbs in the assignment pdf. They need to be added to the code base along with changing corresponding function calls

Typing make video generates the final video file from the title frame and the rendered frames.

• It will be easier if you replace the vec3 class by a structure and the member functions by
  inline functions or macros. For your convenience, an implementation using macros is
  http://www.cas.mcmaster.ca/~nedialk/COURSES/4f03/private/vector3d.h
• Remove all global variables.

Today in class we discussed that drive writes take a significant amount of time. One group took 4 hours to render of which 2.5 hours of disk writes. I think we need to use one thread thread just to feed the GPU with data and another to write files to disk.

Points to consider:

• approx 12MB per .bmp frame @ 4k * 7,200 frames = 84GB of frames
• if we convert every frame to jpg in real time could we fit this in ram? (shared across all our computers) I have 8GB Dom has 16GB, not sure about Logan
• use one thread to service the GPU and add frames to a DiskWrite buffer. The second thread can empty the DiskWrite buffer.
  • I have no idea the difference in speeds of the GPU computation and the disk writes, it is possible that the buffer could fill up.
  • using multiple threads to write would only improve the performance if we are using multiple disks since a single thread should be able to saturate the write speed of a single disk.
• Solid state drives should give about a 4x write performance increase over spinning platters, unfortunately I only have about 10GB of free space on mine. If someone has an extra one to lend me it would be great.

• We will need an output directory since we are generating 7200 frames, we could possibly define the name of the directory in the params.dat file
• The frame number should correspond to the global path position. If we are using multiple gpu's to render subsections of the path, each gpu will need to know what frame number to start working at

I suggest making it work so that when make mpi is typed that it compiles with a different main.cc file which renders a subset of frames on school servers.