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

Jellby schrieb:
> Why not allow multiple highlights{} blocks in finish{}?

I think that would be somewhat overkill for the standard use case, 
making the code unnecessarily complex, as the same effect can already be 
achieved by adding another texture layer.

In addition, it would raise the question whether three highlight blocks 
would be ok as well, and stuff like that.

Post a reply to this message

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

Might become worth it - it has already ceased to be a strictly 
single-value statement.

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

Hm... that's actually a neat idea! So far I had understood the idea to 
be about getting a different brightness or roughness for different 
points on the object - which I wouldn't have considered too 
entertaining, given that this can be achieved with texture maps already.

But modulating the highlight intensity (or even colour) according to the 
highlight falloff - that's something new indeed.

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

Yup.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4a980586$1@news.povray.org...
> Hm... that's actually a neat idea! So far I had understood the idea to be 
> about getting a different brightness or roughness for different points on 
> the object - which I wouldn't have considered too entertaining, given that 
> this can be achieved with texture maps already.
>
> But modulating the highlight intensity (or even colour) according to the 
> highlight falloff - that's something new indeed.

you think it's feasible?

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 wrote:
> (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.)

Why not extend "conserve_energy" to affect highlights?

...Chambers

Post a reply to this message