 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen a écrit :
> crand .001 //does anyone even use this?
Not much these days.
And looking at it, using crand AND aa seems rather futile. Crand darken
a random pixel, this causes aa to kick in and mostly kill the crand
effect: Most of the subsampling won't be affected by the crand.
A use I can find, in an animation:
Simulate the grain of the film.
Akain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers a écrit :
> 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
I had the same though. I was about to post that same comment.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen schrieb:
>> But modulating the highlight intensity (or even colour) according to the
>> highlight falloff - that's something new indeed.
>
> you think it's feasible?
Why not? Should be some work, but not much of a problem.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Zeger Knaepen schrieb:
> >> But modulating the highlight intensity (or even colour) according to the
> >> highlight falloff - that's something new indeed.
> >
> > you think it's feasible?
>
> Why not? Should be some work, but not much of a problem.
Hooray! I was thinking of how it could be used to make those fancy metallic car
paint jobs. The aoi pattern is also handy for that, but some color effects are
more around the specular highlights than anything else.
If you ever need any other suggestions on where a color_map can be added to make
things more complicated, let me know. I have quite a few in mind.
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Reactor" <rea### [at] hotmailcom> wrote:
> If you ever need any other suggestions on where a color_map can be added to make
> things more complicated, let me know. I have quite a few in mind.
>
>
> -Reactor
Yes, They are handy in any software and would be intuitive IMNO (In My Noobish
Opinion) to use the same way in pov. Set color maps free! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> 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.
I've been playing with the SSLT stuff the last 2 days and I noticed that in the
Jensen SSLT SIGGRAPH paper there's a third RGB Diffuse Reflectance parameter
(like a color_map for highlights, yes?) used to fine tune the material. So that
would just mean extending the existing diffuse component of a finish to use a
full RGB color vector instead of an assumed grayscale color vector
as it is currently, which makes a lot of sense to me (and a second vector for
the backlit stuff that Clipka did).
Well, I've been thinking about this for a while, and wondering... Xander
Enzmann's (a former POV-Ray contributor) Polyray was doing something like that
15 years ago (among other things, like using various microfacet highlight
distribution models). Take a read through the old Polyray docs at Paul Bourke's
website: http://local.wasp.uwa.edu.au/~pbourke/dataformats/polyray/
It's like listening to an old Led Zeppelin album; you sometimes forget how good
they were back in those days.
Regardless, accurate simulation of different physical materials requires
different mathematical models to handle the various cases. I know what (and
who) Phong is, but I'm not really sure what model POV-Ray's "specular"
represents (just a guess - Cook-Torrence?). So, why limit POV-Ray to "phong"
and "specular?" Why not just take into account several shading models for
various materials, just like the high-dollar Hollywood boys do? (and they're
pretty damned convincing most of the time)
That simply means making available various *combinable* shading models for
various materials. Blinn/Phong for plastics, Lambert for simple
non-reflective surfaces, Cook-Torrance for metals, Oren Nayar for rough
surfaces, and Ward-anisotropic for objects with anisotropic reflections like
brushed metal, fur, hair, etc. That's the utmost in flexibility as far as I can
see.
Just my 2 cents.
-Rob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Robert McGregor schrieb:
> I've been playing with the SSLT stuff the last 2 days and I noticed that in the
> Jensen SSLT SIGGRAPH paper there's a third RGB Diffuse Reflectance parameter
> (like a color_map for highlights, yes?) used to fine tune the material.
Which of the two papers are you referring to here? The 2001
Jensen/Marschner/Levoy/Hanrahan paper ("A Practical Model for Subsurface
Light Transport"), or the 2002(?) Jensen/Buhler follow-up ("A Rapid
Hierarchical Rendering Technique for Translucent Materials")?
The 2001 paper had no such parameter: The scattering and absorption
coefficients and the refractive index are essentially the only
parameters in the model presented there. (I'm deliberately ignoring the
phase function, as Jensen et al. themselves presumed isotropic
scattering when they went on to measure the parameters of real-world
materials.)
The 2002 paper does indeed mention a "diffuse reflection coefficient"
with reference to the 2001 paper, Rd, but in the 2001 paper that was
actually the /result/ of the SSLT computations (or, rather, with the
formula referred to in the 2002 paper, even just an approximation).
The 2002 paper does indeed take this diffuse reflection coefficient as a
parameter, but not in addition to the scattering and absorption
coefficients appearing in the BSSRDF formula, but to reparameterize the
whole smash, in order to compute the scattering and absorption
coefficients from parameters that are more intuitive (said diffuse
reflection coefficient, as well as the "mean free path" per color
component).
The diffuse reflection coefficient, in that reparameterization, would be
equivalent to the product of the pigment color and POV-Ray's the
"diffuse" parameter.
> So that
> would just mean extending the existing diffuse component of a finish to use a
> full RGB color vector instead of an assumed grayscale color vector
> as it is currently, which makes a lot of sense to me (and a second vector for
> the backlit stuff that Clipka did).
The diffuse colorization is what is currently in the pigment (which, as
you will certainly agree, is much more flexible than just a color
vector). Note that the pigment does not affect highlights or reflections
unless used with the "metallic" keyword. Even then, they can be
"decoupled" by using multi-layered textures.
> Regardless, accurate simulation of different physical materials requires
> different mathematical models to handle the various cases. I know what (and
> who) Phong is, but I'm not really sure what model POV-Ray's "specular"
> represents (just a guess - Cook-Torrence?).
No, it's actually just the Blinn-Phong model.
> So, why limit POV-Ray to "phong"
> and "specular?" Why not just take into account several shading models for
> various materials, just like the high-dollar Hollywood boys do? (and they're
> pretty damned convincing most of the time)
Maybe because someone needs to implement the whole stuff? And maybe the
people using it are not high-dollar Hollywood boys who know exactly when
to employ what model?
And last not least, maybe it's also because the syntax to this day is
not particularly inviting to add more alternative highlight models.
> That simply means making available various *combinable* shading models for
> various materials. Blinn/Phong for plastics, Lambert for simple
> non-reflective surfaces, Cook-Torrance for metals, Oren Nayar for rough
> surfaces, and Ward-anisotropic for objects with anisotropic reflections like
> brushed metal, fur, hair, etc. That's the utmost in flexibility as far as I can
> see.
I guess I do agree that it would be nice to have additional highlighting
models, and maybe even be able to combine them.
However, given that the average user will use just /one/ of these many
models, I would consider it a waste of memory (and a bit of computing
time, too) to combine all of these side by side in each and every single
texture finish.
I would therefore rather suggest to have a texture finish support
exactly /one/ highlight model (let the user pick which one), which
experienced users can then combine by using multi-layered textures.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> The 2002 paper does indeed mention a "diffuse reflection coefficient"
> with reference to the 2001 paper, Rd, but in the 2001 paper that was
> actually the /result/ of the SSLT computations (or, rather, with the
> formula referred to in the 2002 paper, even just an approximation).
>
> The diffuse reflection coefficient, in that reparameterization, would be
> equivalent to the product of the pigment color and POV-Ray's the
> "diffuse" parameter.
Okay, I misunderstood completely then (which isn't terribly unusual). Thanks for
clarifying that.
> > So, why limit POV-Ray to "phong"
> > and "specular?" Why not just take into account several shading models for
> > various materials, just like the high-dollar Hollywood boys do? (and they're
> > pretty damned convincing most of the time)
>
> Maybe because someone needs to implement the whole stuff? And maybe the
> people using it are not high-dollar Hollywood boys who know exactly when
> to employ what model?
You are *so* warm and fuzzy sometimes :)
> And last not least, maybe it's also because the syntax to this day is
> not particularly inviting to add more alternative highlight models.
>
> > That simply means making available various *combinable* shading models for
> > various materials. Blinn/Phong for plastics, Lambert for simple
> > non-reflective surfaces, Cook-Torrance for metals, Oren Nayar for rough
> > surfaces, and Ward-anisotropic for objects with anisotropic reflections like
> > brushed metal, fur, hair, etc. That's the utmost in flexibility as far as I can
> > see.
>
> I guess I do agree that it would be nice to have additional highlighting
> models, and maybe even be able to combine them.
>
> However, given that the average user will use just /one/ of these many
> models, I would consider it a waste of memory (and a bit of computing
> time, too) to combine all of these side by side in each and every single
> texture finish.
As computing power continues to increase I don't think this is really an issue.
Besides, we're *ray-tracing*, which typically uses "a bit of computing time"
anyway, so let's make the most of it.
> I would therefore rather suggest to have a texture finish support
> exactly /one/ highlight model (let the user pick which one), which
> experienced users can then combine by using multi-layered textures.
Okay, I understand that. Although I often combine phong and specular in the same
finish block to get a wide, soft, general hightlight and a sharp specular
highlight it's no big deal to layer them instead.
I just wanted to prompt some thinking about adding some additional models (maybe
for POV-Ray 4). As far as syntax, I wouldn't suggest to change it, just add a
few keywords and maybe change some things under the hood. For example:
// use default Blinn-Phong
finish {specular 0.5}
// switch to Cook-Torrance
finish {specular 0.5 metallic}
// switch to Ward-anisotropic (for say, brushed metals)
finish {specular 0.5 anisotropic{gradient radial ramp {rgb 0, rgb 1}}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Robert McGregor wrote:
> Okay, I understand that. Although I often combine phong and specular in the same
> finish block to get a wide, soft, general hightlight and a sharp specular
> highlight it's no big deal to layer them instead.
But still sounds like we have a valid use case for using two highlight
models simultaneously, namely to approximate a third unsupported one. Of
course, that would no longer be necessary if the new syntax would some
day allow to specify a custom highlight model (as a function?), after
which the old keywords could be phased out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
> 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.
arguably, adding highlights in a finish block could be seen
similarly to adding media to an interior or densities to media,
both cases where the effects are combined.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
