Limitations of Publicly Distributed Rendering
This page aims to describe the inherent technical and other limitations of publicly distributed rendering as it is represented by BURP and Renderfarm.fi. For answers to the most commonly asked technology related questions, read the Renderfarm.fi FAQ (Frequently Asked Questions). After consulting the FAQ, feel free to ask questions on the Forum.
Some terms used in this document
- Frame: Single image in a sequence of images making up a movie.
- Part: a part of a frame, multiple parts make up an entire frame. Parts are typically small rectangular pieces of frames
Contents
- Known bugs in the client side code
- Frame inter-dependencies
- Part inter-dependencies
- Data and performance
- Closed versus open
- Public interest
Known bugs in the client side code
- Using the sequencer in Blender may cause it to reset any BURP-related settings (like split), causing the session to fail or become very expensive in regard to performance
- Adjusting the computer clock backwards will crash running workunits
- The "maximal no-progress-threshold" is too low in some situations
- Progress can sometimes go from 0 to 98% more than once (including negative progress just when switching) due to layers
- Fluid simulations made in Blender as external files are not supported because BURP doesn't support inclusion of external files yet
- Using movies as textures isn't supported in the Blender patchset code
- Using subsurface scattering in a session where each frame is split into multiple parts causes rendering artifacts
- Using composite nodes that rely on neighboring pixels causes artifacts if the frame is split to multiple parts.
It is not feasible to render animations where one frame in the animation depends on some computation done in another frame. This is due to the fact that each frame may be rendered in parallel, so the information may simply not be available - or it may be available on a machine that is not accessible from the machine rendering the frame.
One example of "backwards frame dependency" is physics simulations; for instance simulating the ripples in a shaking glass filled with water. For each frame the state of the water depends on where the water was calculated to be in the previous frame. This limitation is true even for centralized renderfarms, which is why most effects like these can be "baked" – which means that the dependency is resolved by doing some calculations prior to the actual rendering of the frames. These calculations could, in our example above, result in a set of geometric positional data describing the state of the water for each frame. This way the frame now only depends on this geometric data and not the computation of other frames.
Similarly to frames multiple parts may be rendered in parallel and thus cannot depend on each other. Some pre- and post-processing effects can introduce this kind of dependency. An example of a preprocessing effect is Subsurface Scattering (used for rendering things where the light can scatter beneath the surface - skin, milk, cheese etc). This effect achieves its results by using information from nearby pixels. This information, however, is not available on machine A because machine B may not yet have finished producing it and A and B cannot communicate directly anyways. So far there is no solution to do the preprocessing effects (possibly in the future maybe they could be baked like physics), but the post-processing effects can be done in a separate pass where the information from the entire frame is available.
When rendering on a publicly distributed network it is important to keep in mind that the data will have to travel over the (slow) Internet. In other words it is a bad idea to attempt to render a 500MB animation where each frame only takes 10 seconds to render. The reason why this is a bad idea is because the system will be spending more time transferring data over the Internet than it would have taken a single computer to render the frame locally. Said in a different way: Keep the CPU-to-data ratio high. The more processing which can be done per megabyte of data (for instance complex raytracing and reflections) the better the system will perform compared to a centralized renderfarm.
If an existing system could produce results within a time frame measured in weeks then a distributed system can produce the same results in just hours or days. But if an existing system could produce a certain result in just seconds the distributed system will likely still take hours to produce that same result due to the overhead of distributing data to the involved machines.
A publicly distributed renderfarm is an open environment. Technical limitations imply that model and texture data will be exposed. Participants will be able to inspect the data files on their computers to see what it is they are rendering. If it is paramount to keep the model and/or texture data confidential then publicly distributed rendering is not the model to use; it doesn't provide any technical means of confidentiality.
Another limitation lies at the client side: only freely distributable render engines can be used to render the scene data. Obviously participants are not interested in investing hundreds of euro in buying commercial render engines in order to participate in the project. Furthermore, it is necessary to instrument the render engine with code to measure and report progress to the distributed renderfarm. The render engine license must be "sufficiently open" to allow this kind of instrumentation.
In order to maintain participation levels the animations rendered should in some way arouse public interest. Depending on who are participating the definition of "interesting" may vary. Renderfarm.fi endorses using it for visually pleasing material, however, we also fully appreciate the old saying "beauty is in the eye of the beholder". This means that we will try to stay as objective as possible when accepting or rejecting works proposed to be rendered on the service by its users.