There are several drawbacks I see in POV-Ray's highlights syntax:

- Phong and Specular are basically redundant; you only need one of the 
two in any material.

- Although they basically do the same, the parameterization of Phong and 
Specular is different.

- Neither Phong nor Specular highlights are implemented in an "energy 
conserving" fashion; that is, changing the parameter not only changes 
the size of the highlight, but also changes the total amount of light 
reflected in this manner, making it difficult to find realistic 
settings, let alone keeping them in "sync" with reflection.

(This difficulty to find realistic settings also appears to be the 
reason why highlights are not taken into account for radiosity sample 
rays; theoretically they should be, while a comment claims that this 
"causes problems with colors being far too bright" - which is actually 
an indication that energy conservation is violated somewhere.)


I therefore propose to phase out the existing syntax in favor of a 
different one - including different interpretation of the parameters - , 
along the lines of:

   highlights {
     specular       // or "phong", choosing the model
     0.3            // brightness of the highlight
     roughness 0.01 // value controlling the "spread" of the highlight
   }

where...

- a brightness parameter of 1.0 would /not/ be interpreted as "/peak/ 
highlight brightness = incoming light brightness", but rather "/total/ 
highlight output = incoming light input" (that is, changing the "spread" 
of the highlight would cause the peak brightness to diminish 
accordingly), so it can more easily be matched to diffuse and reflection 
parameters [*]

- roughness would be interpreted as currently in specular highlights; 
for phong highlights, a correction factor would be applied to make the 
highlight size roughly equivalent regardless of choice of highlight model.

[* this would allow for the rules of thumb "diffuse + highlights < 1.0" 
and "highlights = reflection" to get somewhat realistic results]


The new syntax, as proposed above, would allow for the old one to be 
retained for a while (old syntax would continue to use the old 
parameterization schemes of course, i.e. the main parameter indicating 
peak brightness) and just cause a deprecation warning. (To begin with, 
phong and specular could still live side-by-side when using the old 
syntax, in case anyone happens to use them simultaneously.)


Comments?

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4a9651d4$1@news.povray.org...
>   highlights {
>     specular       // or "phong", choosing the model
>     0.3            // brightness of the highlight
>     roughness 0.01 // value controlling the "spread" of the highlight
>   }

and what if, for whatever reason, you want the effect of both models 
combined?
(layered textures are not an option unless you change the code so that 
patterned textures finally can be layered too, but even then you're making 
it unnecessarily complicated)

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen schrieb:
> and what if, for whatever reason, you want the effect of both models 
> combined?

Name one.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4a968920@news.povray.org...
> Zeger Knaepen schrieb:
>> and what if, for whatever reason, you want the effect of both models 
>> combined?
>
> Name one.

You're missing the point.  It's not because you or I can't think of a 
reason, no one can. Your idea takes functionality away, just because you 
believe there's no reason for that functionality to exist. (Or better: your 
idea makes it a lot harder to do the same thing).

But, if you really want an example: try this:
--- START CODE ---
camera {
 angle 160
 location 0
 look_at z
 translate x
}
light_source {
 <-1,0,0>
 rgb 1
}
torus {
 1,.5
 texture {
  pigment_pattern {bumps scale .2}
  texture_map {
   [0
    pigment {blue 1}
    finish {
     ambient 0 diffuse 0
     reflection 1
     phong .5 phong_size 15
     specular 1 roughness .001
     metallic .5
    }
   ]
   [1
    pigment {red 1}
    finish {
     ambient 0 diffuse 0 brilliance 10
     reflection 1
     phong .5 phong_size 15
     specular 1 roughness .001
     metallic .5
    }
   ]
  }
 }
}
--- END CODE ---

Possibly this could also be done with averaged textures, but the code would 
be a lot more complicated.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> There are several drawbacks I see in POV-Ray's highlights syntax:

....

> Comments?



Can we tack a color_map somewhere in there?  It would let you determine the
color of the highlight and the way it falls off.  Yes, I know hat would make
already complicated things more complicated.  No, that doesn't have to be taken
seriously.

-Reactor

Post a reply to this message

Zeger Knaepen schrieb:
> "clipka" <ano### [at] anonymousorg> wrote in message 
> news:4a968920@news.povray.org...
>> Zeger Knaepen schrieb:
>>> and what if, for whatever reason, you want the effect of both models 
>>> combined?
>> Name one.
> 
> You're missing the point.  It's not because you or I can't think of a 
> reason, no one can. Your idea takes functionality away, just because you 
> believe there's no reason for that functionality to exist. (Or better: your 
> idea makes it a lot harder to do the same thing).

No, I think it's you who is missing the point:

* As long as there's no reason to use both at the same time, the 
functionality /is/ redundant.

I notice that you do give a scene that uses both at the same time - but 
you fail to name a reason why it does so.

* In case there are /exceptional/ reasons to use both at the same time, 
if there's a reasonably simple way around it the functionality can still 
be considered redundant.

I notice that the scene you give can be fairly easy done using layered 
textures (see below).

I also note that your scene appears not to be relying particularly on 
the ability to use both phong and specular simultaneously, but on the 
general ability to overlay multiple highlights of different spread; if 
you would want to carry this further to mix 3 instead of 2 such 
highlights, then you'd be screwed anyway.

* For scenes that do use both features in the same texture - for 
whatever reason - there would be a transitory time (well, transitory 
versions actually) that would still support the old syntax, including 
the ability to use both types of highlights at the same time.

* Removing redundant functionality has been done before in POV-Ray (e.g. 
Halo, which was superseded by media even though that probably made it 
more complicated to achieve the simpler use cases covered by halo).


> But, if you really want an example: try this:
> ...
> 
> Possibly this could also be done with averaged textures, but the code would 
> be a lot more complicated.

Try layered textures - doesn't appear a /lot/ more complicated to me; I 
think it's actually a quite straightforward recipe (which also happens 
to work for cases where you'd want to combine 3 or more differntly-sized 
highlights):

-----------
camera {
  angle 160
  location 0
  look_at z
  translate x
}
light_source {
  <-1,0,0>
  rgb 1
}

#declare Tx1 = texture {
   pigment {blue 1}
   finish {
    ambient 0 diffuse 0
    phong .5 phong_size 15
    metallic .5
   }
}
texture {
   pigment {blue 1 transmit 1}
   finish {
    ambient 0 diffuse 0
    reflection 1
    specular 1 roughness .001
    metallic .5
   }
}

#declare Tx2 = texture {
   pigment {red 1}
   finish {
    ambient 0 diffuse 0 brilliance 10
    phong .5 phong_size 15
    metallic .5
   }
}
texture {
   pigment {red 1 transmit 1}
   finish {
    ambient 0 diffuse 0 brilliance 10
    reflection 1
    specular 1 roughness .001
    metallic .5
   }
}

torus {
  1,.5
  texture {
   pigment_pattern {bumps scale .2}
   texture_map {
    [0 Tx1]
    [1 Tx2]
   }
  }
}
------------

Post a reply to this message

>> You're missing the point.  It's not because you or I can't think of a 
>> reason, no one can. Your idea takes functionality away, just because you 
>> believe there's no reason for that functionality to exist. (Or better: 
>> your idea makes it a lot harder to do the same thing).
>
> No, I think it's you who is missing the point:
>
> * As long as there's no reason to use both at the same time, the 
> functionality /is/ redundant.

the functionality is there, I see no reason whatsoever to remove it.

> I notice that you do give a scene that uses both at the same time - but 
> you fail to name a reason why it does so.

try to remove one or the other, the result is completely different. The 
reason to use both phong and specular in my scene is so I can have soft and 
hard specular hilights in the same material without needlessly complicated 
code

> * In case there are /exceptional/ reasons to use both at the same time, if 
> there's a reasonably simple way around it the functionality can still be 
> considered redundant.

I would agree if you were argueing against *adding* functionality, but we're 
talking about taking functionality *away*. And in that case I believe that 
if even one person can think of a reason, even if only he/she understands 
that reason, to use a particular function, and if changing the program to 
remove that functionality doesn't give us anything else, anything better, in 
return, then we're dealing with an "it ain't broke so don't fix it" 
situation.

> I notice that the scene you give can be fairly easy done using layered 
> textures (see below).
> I also note that your scene appears not to be relying particularly on the 
> ability to use both phong and specular simultaneously, but on the general 
> ability to overlay multiple highlights of different spread; if you would 
> want to carry this further to mix 3 instead of 2 such highlights, then 
> you'd be screwed anyway.

true, but like I said in my post: it's not because you or I can't think of a 
reason, that no one else can.  I made that scene just quickly as a 
demonstration that combining hilights could be usefull, I know perfectly 
well the same effect can be be done in another way, but that was not the 
point.  I didn't want to spend time trying to find a situation where it 
couldn't reasonably be done in any other way.

> * For scenes that do use both features in the same texture - for whatever 
> reason - there would be a transitory time (well, transitory versions 
> actually) that would still support the old syntax, including the ability 
> to use both types of highlights at the same time.
>
> * Removing redundant functionality has been done before in POV-Ray (e.g. 
> Halo, which was superseded by media even though that probably made it more 
> complicated to achieve the simpler use cases covered by halo).

yes, but AFAIK every effect halo could produce, can also be done with media. 
The opposite is not true.  So it's not a matter of taking functionality away 
without adding anything better.  Your proposal is.

I'm not saying your idea isn't good, I'm saying you have to give us more, 
not less, functionality.  I too believe it's redundant to have two 
hilight-types (and to be completely honest, I've never really understood the 
benefits of phong, I've always found specular to look far better) but 
they're there, people might want to combine them, so why not just let them.

I think your idea is more something for POV-Ray 4, although I hope we get a 
full shader language there :) with full layering possibilities (why, btw, 
isn't layering of patterned textures allowed in POV3.6?) including 
texture-'blend modes' (like the ones image editing programs have, I'd love 
to be able to make textures that shift the hue of underlying colors, or 
textures that additively blends with the background).
hmm, this is getting OT :)

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen schrieb:
> I would agree if you were argueing against *adding* functionality, but we're 
> talking about taking functionality *away*. And in that case I believe that 
> if even one person can think of a reason, even if only he/she understands 
> that reason, to use a particular function, and if changing the program to 
> remove that functionality doesn't give us anything else, anything better, in 
> return, then we're dealing with an "it ain't broke so don't fix it" 
> situation.

Among the things it would give us, there are:

- reduced memory footprint for texture objects
- reduced code complexity
- more consistent SDL syntax

The latter one being my main motivation for suggesting it.

My primary proposal is to re-parameterize the highlights. Collapsing the 
two features into a single one is more of a spin-off, but in case we'd 
do the syntax change anyway, I think it prudent to make the new syntax 
better than the old one in this respect, too: I'm quite sure using 
/both/ highlight modes is /not/ a standard use case.

> true, but like I said in my post: it's not because you or I can't think of a 
> reason, that no one else can.

That's why I'm putting it up for discussion (and arguing against any 
reasons I consider not really "hard").

> yes, but AFAIK every effect halo could produce, can also be done with media. 
> The opposite is not true.  So it's not a matter of taking functionality away 
> without adding anything better.  Your proposal is.

I would expect halo to have been living alongside media for a while, as 
with many other changes that affect compatibility. So in a sense, 
ultimately removing halo from POV-Ray would have been taking 
functionality away without adding anything better, too.

Similar things have also happened with assumed_gamma, which is being 
restricted in the 3.7 to be set to either 1.0 or 2.2, but no interim 
values, and be phased out altogether, making that feature unavailable 
for artistic purposes.

Likewise, collapsing both highlight models into one would remove a 
redundant feature apparently of use only for artistic purposes; and 
other than assumed_gamma, in this case there even appears to be an easy 
ways to go around it.

> I think your idea is more something for POV-Ray 4,

I've come to the conclusion that the parameterization of highlights 
sucks - among others, it's in the way of getting stuff like radiosity 
and subsurface scattering right. So I would preferably want it changed 
way before 4.x comes out.

And if the syntax would be changed anyway, I'd suggest going the whole 
way and collapsing the two features into one.

> (why, btw, isn't layering of patterned textures allowed in POV3.6?)

Because with the POV-Ray 3.x architecture, it would appear to open up 
some cans of worms regarding getting the behavior consistent, I think. 
Never did an in-depth analysis of that issue yet though. But I agree it 
does suck at times.

Post a reply to this message

Among other things, Zeger Knaepen saw fit to write:

> and what if, for whatever reason, you want the effect of both models
> combined?

Why not allow multiple highlights{} blocks in finish{}?

You could have: 

finish {
  highlights {
    specular
    0.3
    roughness 0.01
  }
  highlights {
    phong
    0.2
    roughness 0.1
  }
}

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

"Jellby" <me### [at] privacynet> wrote in message 
news:l42### [at] badulaqueunexes...
> Among other things, Zeger Knaepen saw fit to write:
>
>> and what if, for whatever reason, you want the effect of both models
>> combined?
>
> Why not allow multiple highlights{} blocks in finish{}?
>
> You could have:
>
> finish {
>  highlights {
>    specular
>    0.3
>    roughness 0.01
>  }
>  highlights {
>    phong
>    0.2
>    roughness 0.1
>  }
> }

I was thinking about that too, but it's inconsistent with current behaviour: 
normally, specifying a value overwrites the previous value, which is a good 
thing and imho must be kept.

I'm not sure about the highlights-block.. If that gets through, I believe 
there should also be a diffuse-block.

And to be honest, I actually like Reactor's idea of allowing a color_map.

Something like this:

finish {
    highlights {
        specular        //model of highlight, specular or phong
        1               //main brightness of highlight
        roughness .01   //spread of the highlight, lower values give 
narrower spread
        color_map {
            [0 rgb 0]   //from where the highlight would have no effect, up 
to where
            [.8 red .8] //it has 80% effect, only use the red-component of 
the light_source
            [1 rgb 1]   //from there, gradually use the full color of the 
light_source
        }
        metallic .1     //shift the highlight-hue slightly toward the 
surface-hue
    }
    diffuse {
        lambert         //model of diffuse reflection
        1               //main brightness of diffuse reflection
        brilliance 2    //falloff-power of diffuse reflection
        crand .001      //does anyone even use this?
        color_map {
            [0 rgb 1]   //some fancy special effect lighting: everything 
that should
            [1 rgb 0]   //be shaded is lit, and vice versa
        }
    }
}

color_maps would allow for a whole range of special effects, including 
simulating the effects of combined highlights.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message