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

>         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

> 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