POV-Ray : Newsgroups : povray.binaries.animations : radiosity in animation-- a partial solution to 'flicker' : Re: radiosity in animation-- a partial solution to 'flicker' Server Time
20 Apr 2024 12:19:48 EDT (-0400)
  Re: radiosity in animation-- a partial solution to 'flicker'  
From: Kenneth
Date: 4 Dec 2020 09:10:06
Message: <web.5fca4132a2da5c2fd98418910@news.povray.org>
"Mr" <nomail@nomail> wrote:

> ...So you're saying that this radiosity data file is human readable. If each
>  sample is clearly identifiable, and can be split on a per line basis then
> it's worth trying some kind of script (even maybe a notepad++ macro if it
> could recognize and operate on numbers?) to do the following:
> ...find any line that now has the same patch coordinates in "radtemp2"
> store its index in a list.
> ...And finally merge "rad2" at the end of rad1" to get your incremented but more
> optimized rad2

It would indeed be useful to optimize the final saved data file, if possible; my
animation test for *today*, with a moving camera, has a saved 'composite'
radiosity file with 47000+ lines of data! Here's a sample of what it looks like,
opened in POV-ray...

C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce

......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
the entries.) I have no idea what the data actually means.

Unfortunately, not a single line of that data seems to repeat; I tried hard to
find at least one repetition, with no luck. So my guess is that, as the *camera*
moves during the animation, totally-new 'coordinates' (or whatever) are
generated, with somewhat overlapping 'rad light patches'. I haven't yet tried a
test where the camera is static; maybe there *would* be duplicate entries that
could be eliminated.

BTW: From what I can tell so far, this 'additive' rad-data scheme (for the final
saved file) adds new light patches that sometimes overlap previous ones,
sometimes not. In effect, it seems to be adding to radiosity's COUNT value. So
it might be possible to 'relax' that value-- like, changing COUNT 200 to some
lower value-- to still get the original expected visual result. I haven't yet
tested the idea though.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.