clipka wrote:

> Warp <war### [at] tagpovrayorg> wrote:

>>   What happens if you *want* the texture to have an ambient value >0?

> Then you're screwed with radiosity...

include files could use a #define such as RADIOSITY_TEXTURES
to provide two versions of a texture depending on whether the
#define is set before #including. For textures which just use
a different ambient value that would be no extra effort to
write using a simple macro for ambient.

#macro AMBIENT(ambient_value)
#ifdef RADIOSITY_TEXTURES
   ambient 0
#else
   ambient ambient_value
#end
#end

#declare T_SOME_TEXTURE = texture
{
   pigment {...}
   normal  {...}
   finish  {... AMBIENT(0.15)}
}

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Kenneth wrote:

> > Sorry to be so brain-challenged, but: radiosity compatibility? I've seen that
> > term mentioned several times lately, and have no clue what it means re:
> > textures.  I must have missed something somewhere. Please explain?

>
> ambient 0 in the finish statement, otherwise it would emit light.
>
> For "radiosity-lit-only" scenes (or MCPov for that matter) it would even
> mean "specular 0" and "phong 0".
>

Got it. (Although the specular and phong stuff is new--I need to do some
experiments to see.)

Here's an 'old pitted iron texture' that I dug out of one of my scenes (I
actually started with one of the stones.inc pigments, and modified it)...

#declare old_pitted_iron_texture =
texture {
        pigment{
                granite  // AGATE works well for this too.
                color_map {

                        [0.000 rgb .8*<.4, .4, .380>]
                        [0.153 rgb .4]
                        [0.398 rgb .5*<0.7, 0.4, 0.25>]
                        [0.398 rgb .2*<0.7, 0.7, 0.7>]
                        [1.000 rgb <0.545, 0.380, 0.345>]
                          }

               }
        finish{
              ambient .2 // 0 for radiosity
              diffuse 1
              phong .6
              phong_size 24
        }
        normal {granite .7 scale 9}
    }

KW

Post a reply to this message

Attachments:
Download 'old_pitted_iron.jpg' (52 KB)

Preview of image 'old_pitted_iron.jpg'

Ive wrote:
> Warp wrote:
>> Ive wrote:
>>> ambient 0 in the finish statement, otherwise it would emit light.
>>
>>   That's what #default { finish { ambient 0 } } is for.
> 
> This does not work if the texture already has a finish with ambient > 0.
> But I'm pretty sure you know that.

  Then wouldn't the correct suggestion be "don't put an 'ambient' term
in the finish of the texture" rather than "use 'ambient 0'"?

  The former doesn't fix the ambient, so you can later change it to
whatever you want with #default. The latter fixes it and you can't
change it without modifying the texture code.

Post a reply to this message

Alain wrote:
> Warp nous illumina en ce 2009-04-01 10:41 -->
>> Ive wrote:
>>> ambient 0 in the finish statement, otherwise it would emit light.
>>
>>   That's what #default { finish { ambient 0 } } is for.
>>
>>   What happens if you *want* the texture to have an ambient value >0?
> You just add finish{ambient YourValue} and it will override that defined
> elsewhere.

  Wouldn't it simply be easier if the texture didn't define any ambient
at all? Then you can use #default to set it to whatever you want.

Post a reply to this message

clipka wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>>> ambient 0 in the finish statement, otherwise it would emit light.
>>   That's what #default { finish { ambient 0 } } is for.
> 
> Not with material to place in a lib. Those should have all parameters set, just
> to be sure.

  Just to be sure of what?

  Why shouldn't the ambient term of a texture be definable with a
#default block, even if the texture is in a library?

>>   What happens if you *want* the texture to have an ambient value >0?
> 
> Then you're screwed with radiosity...

  That didn't answer my question.

Post a reply to this message

Warp wrote:

>   Why shouldn't the ambient term of a texture be definable with a
> #default block, even if the texture is in a library?

because the designer of the texture might wish to specify
the intended ambient value for use with classical lighting.

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Warp wrote:
> > Ive wrote:
> >> ambient 0 in the finish statement, otherwise it would emit light.
> >
> >   That's what #default { finish { ambient 0 } } is for.
>
> This does not work if the texture already has a finish with ambient > 0.

That's true.

Actually there's already a very easy way to turn off ALL ambient light settings
in a scene: global_settings{ambient_light 0}

It's really a multiplier (which is why it's set up as <1,1,1> by default); a
very useful little on/off ambient-light switch for running radiosity scenes.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
> > Warp wrote:
> > > Ive wrote:
> > >> ambient 0 in the finish statement, otherwise it would emit light.
> > >
> > >   That's what #default { finish { ambient 0 } } is for.
> >
> > This does not work if the texture already has a finish with ambient > 0.
>
> That's true.
>
> Actually there's already a very easy way to turn off ALL ambient light settings
> in a scene: global_settings{ambient_light 0}
>
> It's really a multiplier (which is why it's set up as <1,1,1> by default); a
> very useful little on/off ambient-light switch for running radiosity scenes.
>
> KW

I find that even worse - in a radiosity scene, you often want some objects to
give out light via an ambient term. Specifically with lightprobes, you need the
lightprobe image to be ambient X and diffuse 0. Radiosity based lightprobe
scenes often have no actual lights - all the lighting originates from the
lightprobe. Setting the global ambient multiplier to 0 turns off the lightprobe
in those cases, and your scene ends up black...

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:

> > ...global_settings{ambient_light 0}
> >
> > It's really a multiplier (which is why it's set up as <1,1,1> by default); a
> > very useful little on/off ambient-light switch for running radiosity scenes.
> >
> > KW
>
> I find that even worse - in a radiosity scene, you often want some objects to
> give out light via an ambient term. Specifically with lightprobes, you need the
> lightprobe image to be ambient X and diffuse 0. Radiosity based lightprobe
> scenes often have no actual lights - all the lighting originates from the
> lightprobe. Setting the global ambient multiplier to 0 turns off the lightprobe
> in those cases, and your scene ends up black...

Hmm, that's bad! :-O   You're right, it certainly isn't applicable in all cases.

KW

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Warp wrote:
>
> >   Why shouldn't the ambient term of a texture be definable with a
> > #default block, even if the texture is in a library?
>
> because the designer of the texture might wish to specify
> the intended ambient value for use with classical lighting.

I agree. Most times, I create a texture with no real thought of how it might
appear using radiosity--because I don't use that feature on a regular basis.
How it looks under classical lighting is my foremost thought.  I save rad for
special occasions--and then I'll go back and re-work the texture (which will
look somewhat 'different' anyway, in radiosity lighting.)

KW

Post a reply to this message