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

Questions related to the client and service

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?

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.

(back to the top)

 

How big are the requirements for data transfer rate in comparison to the benefits gained from using Renderfarm.fi? Is it worth it?

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.

(back to the top)

 

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.

(back to the top)

 

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.

(back to the top)

 

Does a professional or semi-pro Blender animator need to change their work flow in some way in order to use Renderfarm.fi?

Yes, a bit:

  1. 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...)
  2. 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.
  3. We unfortunately cannot do pre- and advanced post-processing in an efficient manner on the service. These will have to be done locally afterwards. This functionality will be improved upon in the future however, with at least pre-processing taking place on the service.
  4. Physics needs to be pre-baked or baked centrally.

(back to the top)

 

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.

(back to the top)

 

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.

(back to the top)

 

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.

(back to the top)

 

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.

(back to the top)

 

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 our to-do list. 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.

(back to the top)

 

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.

(back to the top)

 

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)?

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.

(back to the top)

 

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?

“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.

(back to the top)

 

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:

  1. 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.
  2. 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).
  3. 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.

(back to the top)

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. Can I use Renderfarm.fi anyway?

Yes you can. As there are quite a few sources for very good materials (HDR maps, textures etc.) distributed for free over the Internet that do not fall under what can be called open source licenses, you will need to take some steps in order to use this material in any session that you want to render on Renderfarm.fi.

  1. Make sure you read and abide by any licenses for the materials that you are using. You are responsible for making sure you have the right to use the materials and that they can be distributed for the purposes of rendering.
  2. When uploading a session that has such material:
    1. Choose "copyright" for your sessions INPUT license
    2. Add any relevant copyright information to the "Long Description" field of the upload form

(back to the top)

The gallery render time shows that Renderfarm.fi was slower! Why?

Renderfarm.fi receives its rendering power by distributing complex tasks for many computers across the world. This process makes it possible to achieve very, very big improvements in render time, but it comes with a delay. As an animation is put into rendering it must be sent to all the volunteering computers, rendered on those machines, and then the results must be sent back. All of this involves using the Internet, and this is slow business. If the submitted animation has very low render times such as 20 seconds per frame, then the animation will not gain any improvement in render time - it will get slower. When the rendering eventually begins on the volunteering computer the animation may have been initiated on the Renderfarm.fi server an hour ago as the volunteering computers don't constantly ask for work, but instead do this with increasing intervals.

With this said, animations with long render times get the most out of the service. Robotcomplete by ludopencil was 114 times faster using the service than it would have been on a single threaded computer as each frame took long and there was a large quantity of frames submitted. We recommend that users submit animations with at least 50 seconds of render time per frame to be rendered. We accept all sorts of animations that fill the other requirements, but short ones won't be receiving any advantage in regards to render time.

(back to the top)


How can I contact you?

The best way to contact us is by leaving a message to the forums. You can also send a private message to Prodigal (general matters) or Gekko (technical matters and Blender questions). In case you wish to engage in some conversation, our IRC channel #renderfarm.fi is at Freenode.


(back to the top)