William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/20 9:06 AM, Kenneth wrote:
> > "Mr" <nomail@nomail> wrote:
> >
> ...
> >
> > 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'
> > to
> > the entries.) I have no idea what the data actually means.
> >
>
> I dug up the source code not too long ago and made these notes:
>
> ---
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
> recursion depth increased?
>
> The next three float values are the location.
>
> The text string in position 5 is the normal encoded for +-(2 byte
> value/254) it looked.
>
> Positions 6,7 and 8 are the three color channel values at the point.
>
> In field 9 we have the harmonic mean. The inverse of the mean of the
> inverses of distances to all samples used to set a point's "radiosity
> view." This read as a double (long float) but later used in calculations
> as a float.
>
> In field 10 the nearest sample distance found is recorded.
>
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.
>
> ---
> The floats are all read/scanned as doubles, but the file representation
> seems to be float. The internal usage in calculations is sometimes
> (always?) cast to float. Expect this means not too much difference
> between binary file encoding (as doubles) and current text encoding.
> However, if internally stored as all doubles and all only used as floats
> - the internal representation could probably be better?
>
> FWIW.
>
> ... Yeah, hacking the radiosity file for effects is not something I
> recall anyone doing. It could be interesting. Color shifts. By global
> locations increase or decrease intensities. Insertion of samples by
> interpolation from existing ones? Completely contrived radiosity files
> with gradients or whatever...
>
> Aside: I suspect, there are some similarities to the saved photons file,
> but I've not gotten to even a first look at it...
>
> Bill P.

Why not, ! Radiosity filters ! with that some inbuilt effect could be done like
the recent tests done for paint effect by Kenneth with his circular lights...
Back on initial topic, This is axactly the kind of data I hoped: So yes, the
radiosity algorithm is supposed to do unique samples to avoid wasting
computation, that is precisely why I mentioned to truncate the precision : so
that the samples closest would thus falsely appear as duplicates but the lines
suppressed in the initial data would rather be considered merged by that
(truncation) threshold criteria. Does that naive approach make sense to someone
more experienced than me, or am I missing something?

Post a reply to this message