FAQ, Frequently Asked Questions
Welcome to the FAQ section of the site. We'll try to make this page a collection of the most interesting and asked about questions related to both the service and the technology running behind it.
Before or after reading the FAQ, you will probably want to read about our policies, terms of use and output licensing.
Contents
- What kind of technical limitations do I need to know about before I can put my own animation or still to render on Renderfarm.fi?
- How big are the requirements for data transfer rate in comparison to the benefits gained from using Renderfarm.fi? Is it worth it?
- How does the data transfer take place, how much transfer takes place?
- How does the server actually deal or queue jobs? Can jobs be prioritized inside the service?
- Does a professional or semi-pro Blender animator need to change their work flow in some way in order to use Renderfarm.fi?
- How big (kb-wise) is the BOINC client that is needed to participate in Renderfarm.fi?
- How much computing power and memory does it use?
- Can the amount of their usage be regulated?
- What are the minimum requirements for the computer?
- Do clients need to download and install model libraries in order to participate?
- Could the system be used to do dynamics calculation?
- How do you guarantee safety to the animator? How do you secure commercial modelling libraries and is it necessary in future projects (that might involve these)?
- Can rendering in layers be used as a safety measure (ensuring that no full frames are ever rendered by the same client)? How much security does BOINC provide naturally?
- How does the service check for errors in work units?
- I would like to use Renderfarm.fi for my rendering needs, but some of the materials that I use in my scenes is not available under open source licenses such as the Creative Commons, what should I do?
Questions related to the client and service
There are a some technical limitations to rendering animations and stills on top of Renderfarm.fi. You can read more about these on the page the limitations of publicly distributed rendering.
The more bandwidth you’ve got, the better the perfomance you get. Renderfarm.fi is currently attached to (Finnish University and Research Network) which is being run by The Finnish IT Service for Science. Funet is a high-speed data communications network serving the Finnish research community. It connects about 80 research organizations and 350 000 users. (source CSC homepage)
In the third pan-galactic BOINC workshop in Geneva in 2007, there was talk about adding support for Bittorrent for transporting massive amounts of data from projects to its participants. Such an addition would give much lower network bandwidth requirements. Some of the coding work has already been done for the BOINC/BURP client, but some changes are necessary to make this code useful to the public (C/C++ coding and restructuring). Currently there is no time schedule for this work – if you’re interested in sharing your expertise, you could contact jbk (Janus Kristensen) on the developer side of the forum.
How does the data transfer take place, how much transfer takes place?
BURP (the project Renderfarm.fi is very much based on) started out with a normal point-to-point data transfer system where all the data was transferred directly from the central server to each participant. This was quickly ruled out due to the immense amount of data that had to be delivered (and the low-speed internet connection available). Instead a mirroring software system was developed that allowed participants to install and set up a mirror and help with distribution of data. The central server would then only talk to the mirrors and these would in turn pass along the data to multiple participants each.
How much data transfer takes place depends directly on how much stuff is being rendered and how complex the textures and models used are. To optimize data bandwidth everything is automatically compressed using lossless compression - both input scene files and rendered output.
How does the server actually deal or queue jobs? Can jobs be prioritized inside the service?
Jobs can be prioritized in several different ways. Basically you can give each part of a frame a priority when you "create it" for rendering. All parts with high priority will then be rendered before parts with lower priority. A current restriction is that it is not possible to dynamically adjust priorities. This means that there are some issues in the case where multiple sessions (animations) are rendered simultaneously and one session requires a lot more CPU-power per part than the others. This issue is something that will eventually be fixed, though. For most uses the queuing and priority system in BOINC and BURP works as intended - it allows you to queue up any number of sessions and give them (or even part of them) any priority you like.
Yes, a bit:
- The fact that any publicly distributed renderfarm's performance will be determined more or less entirely by the file size rather than the render complexity of the scene means that the animator needs to be aware of which file formats (mainly for textures) create the smallest file footprint. Thinking about how large a texture you need to achieve the visual look you are aiming for is also important. Most animators are used to using insanely large textures in raw image formats (this is partly why for example Elephant's Dream fills 2 DVDs with data...)
- Fully distributed rendering means that there can be no inter-frame dependencies, ie. each frame (or part of a frame) must be fully self-contained. This means that certain effects that require information from previous frames may not work. There are workarounds for some of the effects, though.
- There is (as far as we know) not yet any way to do efficient pre- and advanced post-processing on a distributed renderfarm. This will have to be done locally afterwards. Some guides about how to do achieve some effects will be made available on Renderfarm.fi later.
- Physics needs to be pre-baked or baked centrally.
How big (kb-wise) is the BOINC client that is needed to participate in Renderfarm.fi?
Around 7.5MB in compressed form, about 20MB uncompressed (it uncompresses itself when in use). Each session also uses hard disk-space dependent on its complexity and how many textures are used. The current client does not include a screen saver. This would approximately add another 1-5MB. We are currently developing a screensaver for Renderfarm.fi participators.
How much computing power and memory does it use?
It uses only spare processing power. In other words this may be from none to all of the available CPU power depending on how much the participant utilizes his system. On single core systems it has been reported that running the client may cause a slight drop in frame rate in certain computer games. The memory footprint is entirely dependent on what is being rendered - it ranges from less than 128MB to several gigabytes. The queuing mechanism makes sure that clients with low memory get the low memory jobs and clients with a lot of memory get the jobs with higher memory requirements.
Can the amount of their usage be regulated?
Not for a single session. A client can either participate in rendering the session or not participate in that session. When multiple sessions are rendering there is a good chance that one of them will fall in the category where that particular client is able to help.
What are the minimum requirements for the computer?
- Minimum: A i686 CPU with at least 128MB ram, a hard drive with at least 500MB free space and an internet connection.
- Preferred: i686 with more than 2GHz, at least 1GB ram, 10GB free space and a fast internet connection.
- “Sweet”: i686 multicore with more than 3GHz on each core, 8GB ram, 200GB free space and insanely fast internet connection. Please join us soon.
However, keep in mind the minimum machine may depend a lot on what you intend to render.
Do clients need to download and install model libraries in order to participate?
At the moment each session input file has all models and textures needed to render that particular session. Reusable libraries (reusing both models and textures between several sessions) are on the BURP to-do list (source jbk). This requires a series of small changes in the BURP code but will dramatically improve on the network bandwidth used (as the libraries can dynamically be stored and reused on participant machines). BOINC support for this is already there.
Could the system be used to do dynamics calculation?
Dynamics calculations are inherently single-machined. Very few (non-commercial) physics solvers are able to work across a grid and none work across a publicly distributed grid (due to network bottlenecks).
A good idea would be to have a small regular old-fashioned computing cluster to take care of this kind of stuff and then use the public grid for the ray tracing and other pixel-by-pixel rendering.
Renderfarm.fi is inherently open by design. If safety to you means inhibiting people from seeing what they are rendering, it is not possible.
This topic relates to the ongoing discussion about Digital Rights Management. The conclusion (so far) has been that there is no way to allow people to open the file when they intend to help rendering but disallow them to open it when they intend to copy it. Some media industries have worked more than 20 years on this topic and they are yet to come up with something that hasn't been broken by someone else.
You can encrypt, obfuscate, sign, check, whatever, as much as you want - the fact that the client needs to get access to the real data at some point means that anyone will be able to get access to that data. You can only slow them down. This is also why publicly distributed rendering really aims at "open" projects - or at least projects that do not care about people peering into their models and textures.
Being open-minded about what you are doing tends to be a good solution in this case. Actually this can have the unforeseen side effect of getting a lot of good PR for whatever you are rendering. When you openly put forward what you are rendering you also take away people's incentive to copy the original files - since it is already out there in the open.
“Security" is a very wide term. Assuming you would mean the confidentiality of the input (scene/model/texture) files. None - and with good reason. We want to keep the system open to as many participators as possible - how many people would agree to let their computers crunch on "something" if they weren't allowed to know what that something was?
It is openness or nothing here. We feel it is possible to slow people down, but you can never stop them from looking into the data that is being rendered on their machines. Since they volunteered to help you, perhaps trust and clearly visible licenses is a better measure of protection than obfuscation.
How does the service check for errors in work units?
First of all, like with most things visual, final error checking is probably best done by sharp human eyes.
However, BOINC and BURP have excellent error checking systems in place to ensure that only correct images are accepted and awarded credit. This works by adding redundant copies of all the frames that are rendered. A rendered frame is only accepted if it matches the redundant copy. The copy is always rendered on another participant's machine. There's a lot of technical talk in this area, but the short version goes like this:
- By sacrificing render performance you can get "pixel perfect" frames. This is the ultimate in perfection but really is extremely overkill. BOINC supports this and with slight modifications BURP does too.
- In a standard rendering there will be small differences caused by rendering the frame on difference kinds of machines. A Mac renders the image slightly different than a PC, Windows machines slightly different than Linux ones etc. These differences are indistinguishable to the human eye and don't really matter. BURP uses a validation technique allowing each pixel to vary just slightly to allow for these kinds of differences. The BURP validator is configurable, for instance setting the allowed difference threshold to 0 puts you in a situation very close to case (1).
- You can render without error checking at all. This gives you completely insane and unimaginable render performance, but a large portion of the returned images may contain errors - either caused by overclocked computers, deliberate modifications or simply faulty hardware.
It seems that quite a few sources of very good materials (HDR maps, textures etc.) are distributed for free over the Internet, but not under what could be called open source licenses (that we in turn very much endorse of course).
The answer to this question is Yes. You can. However, please upload any such files through the webforms (see here for instructions on how to succesfully prepare the file and here to upload), choose copyright from the "input license" options and add the copyright information into the long description of the session. There you go.
For the future this requires us to add support for all licensing options to "input" license in the uploader. This was actually there in the first build done in January 2010, but it was "accidentally" removed because we didn't realize it would affect this scenario. It will be back in the next build (which we'll hopefully have ready at the start of August 2010).
