 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.09.2012 08:26, schrieb Jaime Vives Piqueres:
> Thanks, Ive... I did a new one, addressing the "living blocks" problem
> (mitigated a bit by using proper mass, friction and restitution), and
> also adding the "tension moment" you suggested. The base simulation is
> different too, but this time the "radiosity flickering" seems more
> noticeable... I used +HR, but still there is some randomness from frame
> to frame. Any ideas?
+HR doesn't help for frame-to-frame problems, it just makes sure that
the /same/ scene renders identically each time.
There's really only one way around radiosity flicker, and that's
higher-quality radiosity settings. (From my experience with static
scenes, a deeper pretrace often helps a lot.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/09/12 17:11, clipka wrote:
> +HR doesn't help for frame-to-frame problems, it just makes sure
> that the /same/ scene renders identically each time.
Admittedly, I didn't finish reading the description... :(
> There's really only one way around radiosity flicker, and that's
> higher-quality radiosity settings. (From my experience with static
> scenes, a deeper pretrace often helps a lot.)
Oh, no... I was trying to avoid raising the quality, as it renders
already somewhat slow.
But I had a wild idea... I think someone suggested it sometime ago,
but I don't know if anyone ever tested it: saving/loading radiosity from
one frame to frame, by using both +RFI and +RFO for every frame. I just
did a quick test, and the flickering seems much less noticeable... but
perhaps is my imagination: will render the final animation tonight and
report back.
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 27/09/12 17:11, clipka wrote:
>> +HR doesn't help for frame-to-frame problems, it just makes sure
>> that the /same/ scene renders identically each time.
>
> Admittedly, I didn't finish reading the description... :(
>
>> There's really only one way around radiosity flicker, and that's
>> higher-quality radiosity settings. (From my experience with static
>> scenes, a deeper pretrace often helps a lot.)
>
> Oh, no... I was trying to avoid raising the quality, as it renders
> already somewhat slow.
>
> But I had a wild idea... I think someone suggested it sometime ago,
> but I don't know if anyone ever tested it: saving/loading radiosity from
> one frame to frame, by using both +RFI and +RFO for every frame. I just
> did a quick test, and the flickering seems much less noticeable... but
> perhaps is my imagination: will render the final animation tonight and
> report back.
>
> --
> Jaime
>
>
>
>
I did try that once, but must have badly chosen my animation. It caused
a crash as the radiosity data kept growing to exceede the capacity of my
computer...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/09/12 04:19, Alain wrote:
> I did try that once, but must have badly chosen my animation. It
> caused a crash as the radiosity data kept growing to exceede the
> capacity of my computer...
Hmmm... exactly what happened here, except for the crash. The rad file
was 160KB for the first frame, and now it's 85MB at frame 166 of 389, 9
hours later. It seems to be slowing down the rendering a lot, as last
time, this exact same animation did render completely under 8 hours... a
shame, because it seems to be getting ride of the flicker for non-moving
parts of the scene.
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.09.2012 08:20, schrieb Jaime Vives Piqueres:
> Hmmm... exactly what happened here, except for the crash. The rad file
> was 160KB for the first frame, and now it's 85MB at frame 166 of 389, 9
> hours later. It seems to be slowing down the rendering a lot, as last
> time, this exact same animation did render completely under 8 hours... a
> shame, because it seems to be getting ride of the flicker for non-moving
> parts of the scene.
>
What radiosity settings are you using? Not having done animations myself
I was looking for fast but non-blotchy radiosity settings for the
spectral render thing and from what I've tried something like this
pretrace_start 0.08
pretrace_end 1/min(image_height,image_width)
recursion_limit 1
nearest_count 10
always_sample off
normal off
together with scene complexity dependent count and error_bound settings
gives astonishing fast good looking results.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 28/09/12 04:19, Alain wrote:
>> I did try that once, but must have badly chosen my animation. It
>> caused a crash as the radiosity data kept growing to exceede the
>> capacity of my computer...
>
> Hmmm... exactly what happened here, except for the crash. The rad file
> was 160KB for the first frame, and now it's 85MB at frame 166 of 389, 9
> hours later. It seems to be slowing down the rendering a lot, as last
> time, this exact same animation did render completely under 8 hours... a
> shame, because it seems to be getting ride of the flicker for non-moving
> parts of the scene.
>
> --
> Jaime
>
In my case, the radiosity data managed to reatch around 3 Gb, on a 32
bits system...
Try doing a first animation phase with only, maybe, 10 to 15 frames
loading and saving radiosity data. It may be worth trying to also use
some focal blur with a large aperture and low samples count during that
step. Also, use a smaller resolution and
pretrace_end 2/image_width low_error_factor 0.2.
If the camera move, this pass may possibly omit the moving objects.
Then, do your full animation, but only load the saved radiosity data,
don't save any.
That way, you'll limit the size of the radiosity data file while
benefiting from over-sampling to remove the flicker.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignorancia org> wrote:
> But I had a wild idea... I think someone suggested it sometime ago,
> but I don't know if anyone ever tested it: saving/loading radiosity from
> one frame to frame, by using both +RFI and +RFO for every frame. I just
> did a quick test, and the flickering seems much less noticeable... but
> perhaps is my imagination: will render the final animation tonight and
> report back.
Are you sure that works properly?
While I'm not 100% sure of how the radiosity algorithm works exactly,
I have the impression that once a sample has been calculated, it's never
recalculated again. The only thing that's possibly done is calculating
more samples around it.
This works for a static scene (where only the camera may move), but it
shouldn't work very well for a changing scene (because if the scene changes,
there will be lots of wrong samples that will not get recalculated
properly).
If it works like that, I expect the radiosity to become blotchier and
blotchier as the animation goes and the scene changes more and more,
until it becomes a horrible mess of old wrong samples being interspersed
with newer more correct ones. But I might be wrong.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/09/12 22:00, Warp wrote:
> Are you sure that works properly?
>
Don't ask me how it works, but actually it mitigates much of the most
attention-grabbing artifacts, that is, the ones showing in shadows that
don't move. For the moving ones, it obviously doesn't works, but these
are less noticeable due to the movement.
The problem is, as Alain pointed out, that the rad file keeps growing
and slowing each successive frame, and eventually you can run out of
memory. I've still to try his suggestion about saving the radiosity file
with a "dummy" animation first... might work in my case.
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/09/12 18:33, Alain wrote:
> Try doing a first animation phase with only, maybe, 10 to 15 frames
> loading and saving radiosity data. It may be worth trying to also
> use some focal blur with a large aperture and low samples count
> during that step. Also, use a smaller resolution and pretrace_end
> 2/image_width low_error_factor 0.2. If the camera move, this pass
> may possibly omit the moving objects.
>
> Then, do your full animation, but only load the saved radiosity
> data, don't save any.
>
> That way, you'll limit the size of the radiosity data file while
> benefiting from over-sampling to remove the flicker.
>
Works! Not perfect, but mitigates greatly the most annoying
flicker-artifacts: the ones on parts that don't move, which are the most
noticeable (if something is moving quickly you don't get to notice the
artifacts).
What I did was to use a "dummy" version of the animation: just plain
colors and basic shapes, so that it renders very fast. I didn't skip any
frames, just used the full sequence at the same final resolution, using
both +RFI and +RFO.
As you predicted, later you just need to use +RFI with the resulting
file, and the artifacts get much less noticeable. I just tried with a
quick test, but it should work fine again tonight with the final focal
blur and area light settings.
One thing worth to note is that I still had to use +HR for this work,
otherwise the flickering appears anyhow.
Thanks for the tips, Alain... very useful as usual.
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/10/12 10:36, Jaime Vives Piqueres wrote:
> quick test, but it should work fine again tonight with the final
> focal blur and area light settings.
>
Well... yes, it works, but loading back the rad file increases
rendering times x3!!! I guess it would be better to just use higher rad
settings in first place... as clipka already told us. ;)
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
