Hi Gurus:

   I'm back at trying to develop my "texture baking" experiments into a 
more serious and usable technique for general usage. I'm working on a 
demo scene (and the corresponding how-to) with bundled tools to automate 
the process as much as possible.

   So far, the "direct texture baking" approach is working pretty well: 
when I use the baked textures back into the textures, without lighting, 
the result is the expected one (see living_room-tb.jpg on p.b.i.).

   But the "lightmapping" approach is giving me some headaches... the 
problem is not the map generation itself, but the "loading back" step 
where I "mix" the desired final pigment and the lightmap. This is what 
CG people calls "modulating" the texture with the lightmap. Everyone 
seems to be doing it just with multiplication, but I can't get good 
results with this method... not even multpliying it twice (see 
living_room-lm1.jpg and living_room-lm2.jpg on p.b.i.).

   Can anyone think of a better (more suited) operation than simple 
multiplication?

// macro baked_texture()
//
// params:
//
// * p_lightmap: lightmap pigment
// * t_pigment: pigment to combine with the lightmap
// * t_finish: finish for the resulting texture
// * t_normal: normal for the resulting texture
//
// description:
//
// creates an uv mapped texture by multiplying the specified pigments
// and adding the specified finish and normal statements
//
// uv_mapping is added to pigment and normal individually to allow
// for texture layering over the resulting texture
//
// min() is used on the lightmap function to avoid strange artifacts
// when using interpolation (not present when using 3.6)
//
#macro baked_texture(p_lightmap,t_pigment,t_finish,t_normal)

   #local ft_pigment = function { pigment { t_pigment } };
   #local fp_lightmap = function { pigment { p_lightmap } };
   #local RED = pigment {
     function { ft_pigment(x,y,z).red * min(fp_lightmap(x,y,z).red,1) }
     color_map { [0 rgb 0][1 rgb <1,0,0>] }
   }
   #local GREEN = pigment {
     function { ft_pigment(x,y,z).green * min(fp_lightmap(x,y,z).green,1) }
     color_map { [0 rgb 0][1 rgb <0,1,0>] }
   }
   #local BLUE = pigment {
     function { ft_pigment(x,y,z).blue * min(fp_lightmap(x,y,z).blue,1) }
     color_map { [0 rgb 0][1 rgb <0,0,1>] }
   }
   #local TC = pigment {
     function { ft_pigment(x,y,z).transmit }
     color_map { [0 rgb 0][1 rgb 0 transmit 1] }
   }
   #local FC = pigment {
     function { ft_pigment(x,y,z).filter }
     color_map { [0 rgb 0][1 rgb 0 filter 1] }
   }

   texture{
     pigment{
       uv_mapping
       average
       pigment_map{
         [1 RED]
         [1 GREEN]
         [1 BLUE]
         [1 TC]
         [1 FC]
       }
     }
     finish{
       t_finish
       emission 5
     }
     normal{
       uv_mapping
       t_normal
     }
   }

#end


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Am 27.01.2011 11:22, schrieb Jaime Vives Piqueres:
> Can anyone think of a better (more suited) operation than simple
> multiplication?

No ;)

I think just *one* multiplication should do it.

Actually it looks to me like the saved lightmap file is not linear. Or 
maybe it gets gamma corrected when loading it back?
Have you used OpenEXR files for the lightmap or something else?
And that min() bothers me as it defeats the idea of HDR lighting.
What kind of artefacts do you get?

-Ive

Post a reply to this message

> Am 27.01.2011 11:22, schrieb Jaime Vives Piqueres:
>> Can anyone think of a better (more suited) operation than simple
>> multiplication?
>
> No ;)
>
> I think just *one* multiplication should do it.
>
> Actually it looks to me like the saved lightmap file is not linear. Or
> maybe it gets gamma corrected when loading it back?

   I think it is linear, as I'm using assumed_gamma 1 and the output is 
PNG, but I'm never sure about anything if gamma is involved. ;)

> Have you used OpenEXR files for the lightmap or something else?

   Unfortunately I cannot use OpenEXR, as POV-Ray doesn't supports alpha 
output on these... and I need it for the trick which "grows" the UV maps 
to avoid the visible seams (of course, HDR output will be the best 
solution).

> And that min() bothers me as it defeats the idea of HDR lighting.

  Well, as I'm not using HDR, I guess it shouldn't matter.

> What kind of artefacts do you get?

   Dot-artifacts, exactly them same ones that FlyerX was describing on 
this thread:

http://news.povray.org/povray.general/thread/%3C4ca53804$1@news.povray.org%3E/?ttop=355419&toff=50


   In the mean time, I got slighty better results using the 
multiplication and then applying to the result the formula for the Gimp 
"overlay" mode. Also, I'm not sure if baking lightmaps with white 
pigments on the objects was the best choice... perhaps a medium grey 
would get better results? (trying it now...)

   Regards,

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Am 27.01.2011 15:52, schrieb Jaime Vives Piqueres:

>> Actually it looks to me like the saved lightmap file is not linear. Or
>> maybe it gets gamma corrected when loading it back?
>
> I think it is linear, as I'm using assumed_gamma 1 and the output is
> PNG, but I'm never sure about anything if gamma is involved. ;)
>


>> Have you used OpenEXR files for the lightmap or something else?
>
> Unfortunately I cannot use OpenEXR, as POV-Ray doesn't supports alpha
> output on these... and I need it for the trick which "grows" the UV maps
> to avoid the visible seams (of course, HDR output will be the best
> solution).
>
Have you actually tried OpenEXR? This file format *does* support alpha
and IIRC there was once a bug (with alpha getting inverted or some such) 
but it should work fine now - haven't tried it myself since quite some time.


>> And that min() bothers me as it defeats the idea of HDR lighting.
>
> Well, as I'm not using HDR, I guess it shouldn't matter.

Sure, but this is quite a limitation when used for exactly this purpose.


>> What kind of artefacts do you get?
>
> Dot-artifacts, exactly them same ones that FlyerX was describing on this
> thread:
>
>
http://news.povray.org/povray.general/thread/%3C4ca53804$1@news.povray.org%3E/?ttop=355419&toff=50
>

I see. Looks like a POV-Bug. Have you considered filing a bug report 
before it is too late ;) - which reminds me that I wanted also report 
one more definite bug but for the moment I cannot remember what it was.


> In the mean time, I got slighty better results using the multiplication
> and then applying to the result the formula for the Gimp "overlay" mode.
> Also, I'm not sure if baking lightmaps with white pigments on the
> objects was the best choice... perhaps a medium grey would get better
> results? (trying it now...)

Hmm, should help as radiosity (unless you use insane settings) tends to 
flatten the lighting and this effect does become much more prominent 
when using plain white as pigment.
And I think I'm beginning to see the cause of the problem: there is too 
much light distributed as all objects whithin the scene are equally 
bright. So - purely judged from your posted example images - I would try 
to apply a power function on the lightmap (kind of inverse gamma) 
*before* doing the multiplication, like:
function { ft_pigment(x,y,z).red * pow(fp_lightmap(x,y,z).red, 
MyLightmapExponent) }


-Ive

Post a reply to this message

On 1/27/2011 6:52 AM, Jaime Vives Piqueres wrote:

>> What kind of artefacts do you get?
>
> Dot-artifacts, exactly them same ones that FlyerX was describing on this
> thread:
>
>
http://news.povray.org/povray.general/thread/%3C4ca53804$1@news.povray.org%3E/?ttop=355419&toff=50

This might be related to a bug I've been meaning to report. Image_maps, 
when interpolated (2,3 or 4) and made into functions, tend to produce 
horrible dot artifacts. I haven't tested it with the last two beta 
versions, but it would seem that the artifacts are still present :(

Sam

Post a reply to this message

> Have you actually tried OpenEXR? This file format *does* support alpha

   (In moments like this one, I realize how appropriate was the choice 
of the name for my site domain... :)

   No, actually I didn't try OpenEXR... I tried Radiance (.hdr), which 
doesn't support alpha, and I assumed this was the only HDR output in 
POV-Ray 3.7! I should read the new docs ASAP...

   BTW, I just tried OpenEXR output and it worked perfectly for light 
mapping, as soon as I found out that I had to adjust the the 0-1 range 
to 0-255 (thanks, Sam: I realized it when reading your latest post!).

   #local RED = pigment {
     function { ft_pigment(x,y,z).red * fp_lightmap(x,y,z).red/255 }
     color_map { [0 rgb 0][1 rgb <255,0,0>] }
   }


>>
http://news.povray.org/povray.general/thread/%3C4ca53804$1@news.povray.org%3E/?ttop=355419&toff=50
>
> I see. Looks like a POV-Bug. Have you considered filing a bug report
> before it is too late ;)

   Did I ever mention that I'm waaaay too lazy? ...well, OK, only for 
this time I will try overcome my aversion for bug reporting.

> which reminds me that I wanted also report
> one more definite bug but for the moment I cannot remember what it was.

   :)


   Thanks for your excellent advice, as usual...

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

On 1/27/2011 11:43 AM, Jaime Vives Piqueres wrote:
> BTW, I just tried OpenEXR output and it worked perfectly for light
> mapping, as soon as I found out that I had to adjust the the 0-1 range
> to 0-255 (thanks, Sam: I realized it when reading your latest post!).

/Your/ post reminded me to make light of this issue :) As it turns out 
(thanks to Ive's input), a higher value than 255 might be needed for 
some images.

Sam

Post a reply to this message