[FAQ] Top reasons for rejected sessions


Advanced search

Message boards : Server backend and mirrors : [FAQ] Top reasons for rejected sessions

Author Message
Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4461
Credit: 2,094,806
RAC: 0
Message 5758 - Posted: 4 May 2007, 9:45:55 UTC
Last modified: 15 Sep 2007, 22:06:55 UTC

When running through the submitted sessions I see many different people making the same mistakes and assumptions about what can be rendered on BURP and what cannot. To avoid too much confusion I\'ll try to compile a \"Top reasons for rejected sessions\"-thread here to help shed some light on what is going on.

The reasons are sorted in order of most the often occouring issue first:

1) (About 40%) The uploaded session did not have the right settings for BURP
Many people did not follow the How to prepare your file in Blender-guide present on the upload page. This results in the following common misconfigurations:


  • The output format was selected to be a video format instead of an image file format *
  • Threads were set to more than 1 *
  • Physics/Textures/Models were unbaked


Issues marked with * are now expected to be automatically corrected for uploaded sessions.

Additionally sessions that have render options set to create only a single part will be rejected since it is more effective to simply render these locally. For instance Rendering a single frame that cannot be split is faster on your own machine rather than sending it to BURP where it will then be sent to a single machine and rendered.

2) (About 40%) The expected rendertime was too low compared to the filesize
On BURP the filesize determines how fast any render can be rendered. This is counterintuitive since most people expect the complexity of the scene to be the determining factor - which it isn\'t. The fact that a complex scene usually causes an increase in filesize only helps confuse these things.
The problem, however, is that if you upload a 20MB session input file which would have taken 30 secs to render on your own machine you are bound to become disappointed with the BURP performance. Such a session could readily take a day to render on BURP - at the same time wasting quite a lot of project resources.
Before every session you upload you should ask yourself the question: \"Could I render this faster on my own machine in the many hours it potentially can take before it even gets started on BURP?\" If the answer to that question is \"Hm, probably\" then don\'t upload the session.
Also stronly consider using compressed image formats instead of raw data - this dramatically decreases the filesize and increases your chances of getting the session accepted.
Here\'s a small example list of sessions that got accepted but probably shouldn\'t have since they used more time on the distributed system than they would have on a single computer:


And counterexamples of sessions that gained quite a speed increase by being rendered on BURP:


Another effect is that rendering a single frame or rendering an entire animation typically takes almost the same amount of time - an effect which was nicely captured by Ramathorn in these two sessions: still image (about 4 hours), animation (about 8 hours for 100 frames).

3) (About 15%) Unsupported renderer selected
BURP does not support Yafray at the moment, however quite a few sessions are configured for it anyways. To avoid queueing up a lot of such sessions until Yafray is supported they are rejected.

4) (About 10%) Potentially commercial use or copyright infringing
Some sessions are submitted which are clearly ment to be used commercially - for instance logo animations or graphics for commercial websites. Since it is still being discussed whether (or how) commercial renders and BURP fit together it is not allowed to use BURP for any work that is either directly or indirectly going to be used commercially (ie. for profit - even if this is to make money for a non-profit organization).
In this category is also a small set of sessions where it is unclear whether the results are going to be used commercially. Googling for any names present in the session datafiles to validate the \"non-commerciallity\" of the session stakeholders takes way too much time, so the default action from now on will be to reject this kind of questionable sessions unless there are strong indications of \"non-commerciallity\" in the session description.
Similarly sessions with content where the uploader is not the author but no link and license is stated in the description are considered questionable and are rejected.

But wait! That\'s more than 100%!
Yes, some sessions fall under more than one of the above categories.

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4461
Credit: 2,094,806
RAC: 0
Message 5759 - Posted: 4 May 2007, 9:46:15 UTC
Last modified: 4 May 2007, 10:28:27 UTC

Please do not post in this thread unless you have an addition to the FAQ - if you have a problem with a submitted session please instead search the forum or create a new thread about it.


Post to thread

Message boards : Server backend and mirrors : [FAQ] Top reasons for rejected sessions