Resubmission of 648

Resubmission of 648

Description

Testing the new 2.46 Blender
One of the fixed things in the new 2.46 is panoramic sss. Since BURP uses a method that slightly resembles what happens in panoramic rendering mode this may have fixed the lines and streaks seen in previous images that were rendered in parts.

Message boards : Comments and discussion : 663

Author Message
Thomas
Send message
Joined: 27 Sep 06
Posts: 15
Credit: 64,429
RAC: 0
Message 6844 - Posted: 8 Oct 2007, 18:49:42 UTC

My first 663 WU is still at 0.000 % after 15 minutes. As far as I can see, nobody finished one of those WU\'s so far, but some were aborted.
I will suspend this WU until further notice.
____________

Mike Dunn
Send message
Joined: 21 May 05
Posts: 22
Credit: 9,965
RAC: 0
Message 6847 - Posted: 8 Oct 2007, 19:50:23 UTC

Well, I just got 4 - and both running ones are @ 0% .... I\'ll give them at least an hour though ;)
____________

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 6849 - Posted: 8 Oct 2007, 19:54:41 UTC
Last modified: 8 Oct 2007, 19:55:54 UTC

663 is a rerun of 648 and uses the expensive preprocessing effect called \"subsurface scattering\" or SSS. Officially BURP doesn\'t support preprocessing at all, but since SSS was mentioned as one of the fixed things in the new version of Blender I gave it a shot to see if support for this is something that should be included in the future.
While calculating the SSS (which happens before the actual render, hence the name preprocessing effect) the progress will show 0%. On my machine it took about an hour to render for each of the test-units I ran, about half of that time was spent doing the SSS calculations.

Mike Dunn
Send message
Joined: 21 May 05
Posts: 22
Credit: 9,965
RAC: 0
Message 6850 - Posted: 8 Oct 2007, 20:13:32 UTC - in response to Message 6847.

Well, I just got 4 - and both running ones are @ 0% .... I\'ll give them at least an hour though ;)

Completed in just under 22 mins - although I do have another @ 25 mins/0% ;)
____________

AC
Project donor
Avatar
Send message
Joined: 30 Sep 07
Posts: 121
Credit: 143,874
RAC: 0
Message 6851 - Posted: 8 Oct 2007, 20:14:22 UTC - in response to Message 6849.

How does SSS handle rendering only part of a frame? Is the preprocessing time proportional to the size of the output, or is it fairly constant regardless of the number of parts per frame? If the preprocess time is constant and dominant, then of course it makes sense to minimize the number of parts per frame... just wondering what\'s expected, and eager to see how it works out.

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4483
Credit: 2,094,806
RAC: 0
Message 6852 - Posted: 8 Oct 2007, 21:18:15 UTC - in response to Message 6851.
Last modified: 8 Oct 2007, 21:25:29 UTC

How does SSS handle rendering only part of a frame?

So far it has handled this very badly.

Is the preprocessing time proportional to the size of the output, or is it fairly constant regardless of the number of parts per frame? If the preprocess time is constant and dominant, then of course it makes sense to minimize the number of parts per frame... just wondering what\'s expected, and eager to see how it works out.

As designed SSS works best when the SSS-pass can be done on entire frames at a time. Due to the amount of data generated by the SSS pass it is infeasible to do the SSS-pass beforehand and send it with the workunit for the real rendering pass. This means that to get a pixel-perfect image you would have to redo the SSS pass for the entire frame on each machine rendering a part of that frame. This, of course, cuts down the number of parts per frame where this technique will gain any beneficial speedup from being rendered on a distributed renderfarm to only 1 or 2.

What we (or Blender really) do right now is to render only part of the SSS-pass (namely the part directly overlapping the rendered image part) on each machine. This may very well give artifacts close to the part edges in the image but keeps the preprocessing time proportional to the rendertime on each node.
A solution may be to use a constant factor larger effect area than render area, this decreases performance (some of the overlapping effect areas will be computed more than once) but removes the artifacts - at least that\'s an idea.

javawocky
Send message
Joined: 21 Jun 05
Posts: 20
Credit: 32,563
RAC: 0
Message 6853 - Posted: 8 Oct 2007, 21:34:49 UTC

Thanks for reconsidering the job. It was purely a test, but should be a nice test of the SSS features.

If anyone is interested, a still frame I rendered can be viewed here, I just duplicated the cube a few times and resized them in the background.

http://www.sprocketandlube.com/shownews/item/64
____________

Profile batan
Send message
Joined: 29 Aug 07
Posts: 69
Credit: 39,901
RAC: 0
Message 6860 - Posted: 9 Oct 2007, 13:13:49 UTC - in response to Message 6852.
Last modified: 9 Oct 2007, 13:15:07 UTC

How does SSS handle rendering only part of a frame?

So far it has handled this very badly.

Apparently sessions using SSS should be rendered in one single part. Here is a completed frame of this session, and the parts do not fit together well (colour shifts in some areas between the parts).


Post to thread

Message boards : Comments and discussion : 663