"sooperFoX" <bon### [at] gmailcom> wrote:
> "Edouard" <pov### [at] edouardinfo> wrote:
> >   - LightMapGen 16 sample median-cut lightdome, plus one hand-placed Sun light
> > (no radiosity).
>
> This is the second time you've mentioned this. I had a look at the utility and
> it sounds useful. Do you have a technique for loading the output it produces
> into POV-Ray? I can imagine it getting quite tedious to hand-convert even
> "just" 16 lights every time to try a new probe...
>
> I understand that the first 3 values are in radians; the first being elevation
> and the second azimuth, the third is the angular area the sample occupies. The
> remaining 3 values make up the RGB value of the sample.
>
> But is there a way to read/parse the probemap.lm file directly into POV or do I
> have to convert them into lights by hand?

I wish POV had a more general file reading API, then we could read the files
directly...

What I did was write a macro that reads a comma-separated version of the .lm
file, as it was a easy search and replace operation to convert it into a file
POV could read.

I'll see if I can get in into a postable shape!

> I like your probe, too, by the way. And as others have said, nice work on
> texturing the model!

Thank-you!

Post a reply to this message

"sooperFoX" <bon### [at] gmailcom> wrote:
> But is there a way to read/parse the probemap.lm file directly into POV or do I
> have to convert them into lights by hand?

Very rough version:

#declare dome_size = 10000;

#macro LoadLightMapGenFile( filename, manual_rotation,lightscale )
 #fopen file filename read

 #local number_of_samples = 0;
 #read (file, number_of_samples)

 #local phi = 0.0;
 #local theta = 0.0;
 #local solid_angle = 0.0;
 #local r = 0.0;
 #local g = 0.0;
 #local b = 0.0;

 #local i = 0;
 #while( i < number_of_samples )
  #read (file, phi, theta, solid_angle, r, g, b )

        light_source {
            <0,0,10000>
            rgb< r, g, b > * 2 * lightscale
            area_light < sqrt(solid_angle * dome_size) * rtod, 0, 0 > < 0,
sqrt(solid_angle * dome_size) * rtod, 0 >, 2, 2
            circular orient jitter
            rotate x * (-90 + (phi * rtod))
            rotate y * theta * rtod
            rotate y* manual_rotation
        }

  #local i = i + 1;
 #end

 #fclose file
#end


And the modified lightgenmap file (using a quick search and replace):

16,
1.67289808803656, 0.68722339297277, 1.6527013386, 0.0552636348, 0.0607447550,
0.0508851111,
1.54723438189297, 1.66111711558560, 0.7794830194, 0.0711220279, 0.0557181686,
0.0360830873,
1.61792021659874, 2.17162592179394, 0.5545587558, 0.0781337619, 0.0515972860,
0.0299037341,
1.41764368493239, 2.17947990342792, 0.0867880323, 0.0761284605, 0.0559703335,
0.0377449766,
0.91891585117501, 0.61261056745001, 0.8644722987, 0.0400214680, 0.0603732206,
0.0936556607,
0.94247779607694, 1.50403748290611, 0.4497592365, 0.0661152080, 0.0552642494,
0.0537655167,
1.20558618081508, 2.10486707790516, 0.1601643115, 0.0730255991, 0.0542870797,
0.0431215167,
0.75005524604456, 2.10879406872215, 0.3450847009, 0.0759069920, 0.0534908585,
0.0404571854,
1.69253304212150, 3.01592894744620, 1.5993434847, 0.0655947104, 0.0591190495,
0.0349534899,
1.29983396042278, 2.95702408519139, 0.3214766435, 0.0631420985, 0.0567937195,
0.0538687669,
0.81681408993335, 2.68998870963626, 0.2905465791, 0.0762574896, 0.0534339696,
0.0398534238,
0.81288709911636, 3.29867228626928, 0.5453702181, 0.0694099888, 0.0545476936,
0.0498176217,
1.64540915231765, 4.60243323750905, 1.7470526871, 0.0568613783, 0.0604094379,
0.0494299829,
1.61792021659874, 5.72947960198439, 1.3599216939, 0.0526376031, 0.0615689270,
0.0575421639,
0.91891585117501, 4.45713457728052, 0.9250347179, 0.0431348681, 0.0603335723,
0.0894638970,
0.95033177771091, 5.67057473972958, 0.8845644490, 0.0372447670, 0.0613860562,
0.1000061333,


Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> Same old Jotero Ajax bust as always!
>
>   - 200mm lens at f/4 shot from about 1.7 meters away.
>   - HDR lightprobe I took a couple of evenings ago in nearby field.
>   - LightMapGen 16 sample median-cut lightdome, plus one hand-placed Sun light
> (no radiosity).
>   - Simple texture_map with three entries (shiny, dull and corroded).
>   - DF3 based proximity pattern (along with slope and bozo) to choose the
> texture via a pigment_map.
>   - focal blur only used 7 samples. I could have bumped that to 37, but I wanted
> to see the results today, not tomorrow :-)
>
> I guess the interesting technique (to me at least) was writing a seperate pov
> script to analysed the mesh and create the image slices that got combined into
> the DF3 file. This one used a 60x90x60 DF3 file created with 25 samples per
> voxel. You pay for a one-off creation time, but then get to use the DF3 file
> from then on (and it loads more or less instantly). It possibly might render
> quicker than an averaged fastprox pattern, but I'm not really sure.
>
> The background is just a bit of the sky from the lightprobe - with a bit of
> focal blur it came out looking nice even though the lightprobe resolution is
> pretty low.
>
> I'm pretty happy with how it turned out, but any feedback anyone has would be of
> course welcomed.
>
> Cheers,
> Edouard.

A pleasure for my eyes.
As usual!

--
Carlo

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Edouard" <pov### [at] edouardinfo> wrote:
>
> Geez!
>
> What's that DF3 proximity pattern thing? I guess I'd like to learn about it:
> What exactly does it do? And how do you do it?

The object is just being coloured by a DF3 file, but the DF3 file was itself
created from the object by sample points in space around each voxel. The
density of the voxel is determined by how many samples are inside the object vs
how many samples are outside.

> (BTW, the corroded texture seems a bit too strong to me; or is that green color
> reflections?)

I've done some google image searches, and bronze patina's can be as strong as
this one, but often a bit paler in colour. There's an enormous variation from
what I can tell. It's being lit by a setting sun on the horizon, which might
contribute to the patina's intensity a little.

I'll try tweaking it when I do some more bronzes.

Cheers,
Edouard,

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
>             area_light < sqrt(solid_angle * dome_size) * rtod, 0, 0 > < 0,
> sqrt(solid_angle * dome_size) * rtod, 0 >, 2, 2

Opps - add this global

#declare rtod = (180 / pi);

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> The object is just being coloured by a DF3 file, but the DF3 file was itself
> created from the object by sample points in space around each voxel. The
> density of the voxel is determined by how many samples are inside the object vs
> how many samples are outside.

So basically it's a kind of antialiased voxel representation of the object?

Then I think it's not the ideal way to do it.

If I understand it correctly, the desired effect is that the DF3 helps you
texture an object differently in areas that "stick out" as opposed to
"recessing" regions. For this purpose, the DF3 should be "blurred" in a way.

If I get you right, your approach leveas all blurring to the "voxel
oversampling" and POV's DF3 interpolation. However, this is strongly dependent
on the DF3 resolution.


To improve the approach, the sample points could be jittered even beyond the
boundaries of their "nominal voxel" using a gaussian distribution, which can be
scaled according to the desired "blurriness" of the DF3 for more control, so one
can improve quality of the DF3 (by increasing resolution) without "sharpening"
it.


> > (BTW, the corroded texture seems a bit too strong to me; or is that green color
> > reflections?)
>
> I've done some google image searches, and bronze patina's can be as strong as
> this one, but often a bit paler in colour. There's an enormous variation from
> what I can tell. It's being lit by a setting sun on the horizon, which might
> contribute to the patina's intensity a little.

Taken by itself, it doesn't seem wrong to me; it's the contrast to the
uncorroded bronze that makes it look strange in my eyes. I can't imagine you'll
ever have that strong corrosion in some parts while others are perfectly shiny.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Edouard" <pov### [at] edouardinfo> wrote:
> > The object is just being coloured by a DF3 file, but the DF3 file was itself
> > created from the object by sample points in space around each voxel. The
> > density of the voxel is determined by how many samples are inside the object vs
> > how many samples are outside.
>
> So basically it's a kind of antialiased voxel representation of the object?
>
> Then I think it's not the ideal way to do it.
>
> If I understand it correctly, the desired effect is that the DF3 helps you
> texture an object differently in areas that "stick out" as opposed to
> "recessing" regions. For this purpose, the DF3 should be "blurred" in a way.
>
> If I get you right, your approach leveas all blurring to the "voxel
> oversampling" and POV's DF3 interpolation. However, this is strongly dependent
> on the DF3 resolution.
>
> To improve the approach, the sample points could be jittered even beyond the
> boundaries of their "nominal voxel" using a gaussian distribution, which can be
> scaled according to the desired "blurriness" of the DF3 for more control, so one
> can improve quality of the DF3 (by increasing resolution) without "sharpening"
> it.

I didn't explain it very well - sorry. Each voxel's value is determined by 25
samples taken (in this specific case) randomly within a sphere of 2.5 voxels in
radius. The voxel size and the sample radius are independent of each other.

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> I didn't explain it very well - sorry. Each voxel's value is determined by 25
> samples taken (in this specific case) randomly within a sphere of 2.5 voxels in
> radius. The voxel size and the sample radius are independent of each other.

I see - so you already did the improvement I suggested ;)

(A gaussian distribution would probably give a better quality, but a uniform
spherical distribution should do a good job as well. Oh, it *does*, as can be
seen from your shot ;))

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> "Edouard" <pov### [at] edouardinfo> wrote:
> >             area_light < sqrt(solid_angle * dome_size) * rtod, 0, 0 > < 0,
> > sqrt(solid_angle * dome_size) * rtod, 0 >, 2, 2
>
> Opps - add this global
>
> #declare rtod = (180 / pi);

I did pick up on that, thanks - but it seems the news posting page "swallowed"
my response.

Is there any benefit to declaring that, over using the built-in degrees(rad)
float function?

Also I noticed that you included rotate and scale parameters, as well as a light
intensity multiplier - all things that I was considering when I initially saw
the words "light dome" - so thanks!

Post a reply to this message

"sooperFoX" <bon### [at] gmailcom> wrote:
> > Opps - add this global
> >
> > #declare rtod = (180 / pi);
>
> Is there any benefit to declaring that, over using the built-in degrees(rad)
> float function?

None at all - it was a quick hack, so was a bit of a mess... I'll try to find
the time to make some sort of proper lightprobe/lightdome/backplate loading
macros.

> Also I noticed that you included rotate and scale parameters, as well as a light
> intensity multiplier - all things that I was considering when I initially saw
> the words "light dome" - so thanks!

You're welcome, and thank-you in turn.

Cheers,
Edouard.

Post a reply to this message