Posts by Janus

1) Message boards : Problems and Help : Session 3391 (Message 15224)
Posted 4 days ago by Profile Janus
The few minutes of going back only refers to changes you've made in the scene, and not to the actual rendering of the scene?


Do they have any plans to add saving of a partial rendering?

It is becoming increasingly difficult to do this for arbitrary checkpoints and arbitrary renderers (both Windows and Linux are moving away from a process system where we can freeze and restore entire processes). The amount of data involved is fairly large too - since we aren't just talking about images but also the entire state of the renderer. We may see checkpoints for layers at some point using the "Save Buffers" feature, though - this would be useful for very complex scenes with many layers.

So to answer your question: Essentially no. No-one is currently working on pause/resume-to-disk for Blender renderers. There are other renderers out there that support it, though.
2) Message boards : General talk : Moving sourcecode to Github? (Message 15222)
Posted 5 days ago by Profile Janus
Ah right, that's a good point. I'll add a section about that

I've been using SVN for personal projects for quite a while now, so it has just become second nature to me.
3) Message boards : General talk : Moving sourcecode to Github? (Message 15220)
Posted 5 days ago by Profile Janus
For checking out the code you can use the anonymous user. Patches are reviewed before being accepted. There are 3 subforums dedicated to development for the different parts of the service.

You are free to clone the source repository on Github (or the moon) as long as you make sure that people know it isn't the official one and that the relevant open source licenses apply.

Thanks for pointing out the missing Contributors page. Will have to dig it up from an old backup since it seems to have gone completely missing at some point - probably when we migrated to the current development site.
4) Message boards : Problems and Help : Session 3391 (Message 15219)
Posted 5 days ago by Profile Janus
If 3391 was run in the full standalone Blender would it also take 9.6 hours?

Usually it would be a bit slower because standalone Blender also launches the UI. Right now it may actually be a bit faster in standalone than on the farm but that will be fixed with the next release of our client where we are once again back to being slightly faster than the standalone Blender with UI.

the system suffers a crash at say 7 hours into the task, when the system is restarted and standalone Blender resumes, are the 7 hours of processing time lost and does the frame processing restart from zero?

Correct. At least in general.
If you had made any changes to the scene without saving them before starting the render you would be able to recover those, but not the rendered data, in the autosave directory.
5) Message boards : Problems and Help : Session 3391 (Message 15214)
Posted 7 days ago by Profile Janus
A .blend-file is a scene description - it usually contains no information from the rendered output.

Think of it like an origami instruction; it contains information on how to fold a piece of paper into a beautiful bird but if something goes wrong right now we have to restart with a new piece of paper because there is no way to keep track of progress on the old one. The instructions, on the other hand, haven't changed and can be re-used.
What we want to do is to be able to put the partially built paper bird away and continue on it later - but there is no way to do that that I know of yet.
6) Message boards : Problems and Help : Session 3391 (Message 15211)
Posted 7 days ago by Profile Janus
Still not entirely sure I follow. Please correct me if I got it wrong

The autosave file is just a copy of the scene file. Like autosave in Word, Blender saves a copy every now and then - it doesn't include the rendering data (which is typically many gigabytes of data). So restoring from the autosave file is exactly the same as restoring from the scene file: it starts over from 0%.

Blender appears to written in Python and uses a lot of scripts for controlling it

Yes, a fairly large portion of the UI and some of the underlying code is written in Python, the rest is C++. Python is actually also how the current client sets up the rendering for BURP, we inject a small python script into the scene that controls how Blender renders it. The python script connects to Glue3 which in turn talks to BOINC.
Unfortunately there are limits to how much control you have from Python in Blender - and saving and restoring the entire render state is not currently an option that I know of. Especially so if it is to be done in a way that works with both Blender Internal renderer and the Cycles renderer.

That said, you're right to some extent. It is theoretically possible to get some sessions to suspend/resume with python. Unfortunately it is the same kind of sessions that could simply be split into more pieces from the beginning, so not much effort was put into pursuing that path any further.
7) Message boards : Problems and Help : The death of BURP/The Render Farm? (Message 15209)
Posted 7 days ago by Profile Janus
For starters, you could re-open the donation option.

Well the whole Paypal API part of the site is horrendously outdated, and there's only a few weeks before the purchase goes through; so let's try something different then: I've opened a Gridcoin wallet address for donations to help with the server expansion here:
S75JkohHrpFqVxvdN5VpZy1FCWMYcK3xrH (gridcoin)

If you think people are interested in supporting us like that then please go ahead and spread the word.
For the "Project donor" user tag please PM me with the transaction ID, I'll add the tag.

Better suggestions are welcome
8) Message boards : Comments and discussion : 1670 (Message 15208)
Posted 7 days ago by Profile Janus
This session got stuck in an unfortunate bug in the upload handler and was recently recovered.

Unfortunately the renderfarm doesn't handle Cinema4D files - only Blender's internal renderer and Cycles are supported at the moment.

The session has been rejected.
9) Message boards : Client : Filmic support (Message 15207)
Posted 7 days ago by Profile Janus
Very nice - it looks like it is working as intended then! Thanks for testing it out
10) Message boards : Client : Looking for bold MAC users (Message 15206)
Posted 7 days ago by Profile Janus
There's going to be another few Mac OSX CUDA units up for grabs during the weekend. Very testy. Expect explosions.
11) Message boards : Problems and Help : Session 3391 (Message 15205)
Posted 7 days ago by Profile Janus
Could you elaborate a bit? I'm not sure that feature does what you think it does.
12) Message boards : Problems and Help : The death of BURP/The Render Farm? (Message 15199)
Posted 8 days ago by Profile Janus
The BURP renderfarm has always been a bit of a word of mouth kinda thing - very little energy has been spent on advertising. Intentionally. We're a beta project still. was the opposite - and a very interesting endeavor because it highlighted some fundamental issues with the platform and how it performs under load. Some of the technical issues were tackled back then but some of the issues still lurk around today.

One of the issues is that BURP has chosen security and helpfulness over performance. A real physical person is reviewing every single job before it is handed to the farm. It typically adds somewhere between 30mins and 48 hours from when you send in a session and until it actually starts rendering on the farm. For large sessions this doesn't matter but for small sessions this can be a very large percentage of the total waiting time. "Competing services" either don't review jobs at all or only retroactively review them if they are reported.
Essentially we need to pay someone to sit there ready to hit accept/reject whenever a session comes in. For they ended up having a policy of "No single-frame renders" simply because it almost always took longer to verify the session than to simply render it on your own machine.
For many years it has been technically impractical to change this but I believe there is actually a golden middle way to this somewhere where it is possible to both improve on the current system start-up time dramatically while at the same time decreasing the amount of manual labor required (and, in fact, maybe even improve the rendering performance too).
It has taken quite a while to get to the point where it is even possible to work on this issue because it requires a change to the compute cluster that BURP is hosted on. Just yesterday I began the process of purchasing the required hardware. Still have no idea how to fund this kind of thing, it is the largest investment into the infrastructure of BURP so far - suggestions are welcome.
The development goes under the codename "BARF" and you may see it pop up now and then going forward.

Second issue: Credit. This is mostly related to BOINC and not so much content creators but it takes a lot of time that could otherwise have been used to add other features. The Payday credit algorithm is really pulling some teeth. I find it annoying but also somewhat important because the default BOINC CreditNew algorithm really isn't performing well in our case. When adding GPUs to the mix it just becomes 10 times worse.

Third issue: Coders. BURP is somewhat difficult to get into coding wise. It is written in C++/C/Java/PHP/Python/Javascript/SCSS/HTML/SQL/bash/XML/... Most coders will prefer just working in a small portion of it simply because they don't want to learn all the languages. Already some effort has gone into making it more standards compliant so that it can be deployed more easily, but there is still more to do in this area. We're definitely getting there eventually - a fairly good road-map is in place for how to proceed. Help is welcome, especially in the Blender/Python area, the scene and runtime estimator is very rough.
13) Message boards : Problems and Help : Session 3391 (Message 15197)
Posted 8 days ago by Profile Janus
Don't trust the runtime estimator, it is severely broken
14) Message boards : Comments and discussion : 3390 (Message 15178)
Posted 26 days ago by Profile Janus
This session was rejected because it does not conform with the terms of service
15) Message boards : Comments and discussion : 3382 (Message 15174)
Posted 10 Jul 2017 by Profile Janus
The physics data for this session was not included in the .blend-file (and is around 4GB of data if it was). Blender stores this data in a directory on your computer which is not accessible to the renderfarm.

The session was rejected.
16) Message boards : Comments and discussion : 3380 (Message 15170)
Posted 9 Jul 2017 by Profile Janus
Features that are not officially supported yet are available on-request only.

EXR support is almost ready, mostly there are a few issues with the website preview and the upload handling.

In the early days of BURP people weren't used to renderfarms and more or less randomly selected their output formats (AVI, JPEG, ...) a lot of those formats were not supported by the server backend, so we basically hardcoded it to PNG since it is lossless and to avoid having to resubmit sessions all the time.

For full EXR support the system that performs an analysis of the .blends and the system that creates the session need to be slightly better integrated so that the output format (among other things) can be correctly determined and the entire pipeline configured accordingly.

Not quite there yet
17) Message boards : Comments and discussion : 3377 (Message 15167)
Posted 6 Jul 2017 by Profile Janus
Generated volume scattering textures, interesting concept
18) Message boards : Problems and Help : Fatal error: Too many unsubmitted sessions (Message 15165)
Posted 6 Jul 2017 by Profile Janus
You have been talking to BURP Core. It speaks in wonderfully monochromatic gibberish sentences when it wants to say anything...

BURP has had to implement a number of self-defense mechanisms over the years. One of them is that you cannot create more than 19 sessions without submitting them.

Currently the only way to reuse and manage unsubmitted sessions is through a UI in Blender which is not available for public use at the moment and through a remote API. There is no way to do it through the website.
The reason why a session can even BE in a state where it has been created but not yet submitted is that the session creation system is way more flexible than what is shown in the current "Submit session"-wizard on the website right now.

Since it is perfectly normal to have a small amount of unsubmitted sessions build up over time (your example is a good one) I've added a feature request to the todo-list to have the system automatically time out and reject those sessions after a while if they have not been touched.

As for right now: I've rejected all unsubmitted sessions manually.
19) Message boards : Problems and Help : Disappearing boids? (Message 15163)
Posted 11 Jun 2017 by Profile Janus
Are you using a library that wasn't packed into the blend-file? (oscLimbs, uprightLimb?)
20) Message boards : Number crunching : Is there any WU not for Mac OS (Linux/Windows 64) ? (Message 15162)
Posted 11 Jun 2017 by Profile Janus
Currently nothing to render.

We're keeping the old (the ones with id <3000) sessions around for figuring out what caused them to fail and eventually fix the issue and render them or abort them with an explanation.

Next 20