POV-Ray : Newsgroups : povray.general : Actual Specular calculations? : Re: Actual Specular calculations? Server Time
4 Aug 2024 08:20:18 EDT (-0400)
  Re: Actual Specular calculations?  
From: Christopher James Huff
Date: 12 Jun 2003 11:55:20
Message: <cjameshuff-634DE0.10465412062003@netplex.aussie.org>
In article <3ee7aed3$1@news.povray.org>,
 "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

> It is similiar to what MegaPOV did, yes. What I want is to
> limit the area of effect to the places where the actual
> specular highlights appear (and I know that this depends
> on viewing angle and lighting angle, which is why I asked
> for that).

If that is the case, then it is nothing like the MegaPOV patch. 
Highlights are a surface reflection effect, and have nothing to do with 
the eye viewing them. What you describe sounds like post-process 
highlights, which sounds perfectly useless.


> So for now, I can have a simple image without specular
> highlights, and yet post-process them onto the very
> image, during the creation of the image.

But why? What else does it do?


> Its fairly interesting what could be possible, though so far
> I haven't found much which can't be done with some
> paint program (doh!) or even with POV itself... But I desperately
> wanted that bleeding/blinding effect of sparkling and bright objects,
> so I attacked the code and went on! :-)

Well, that does not depend on any highlight method, or even the 
existance of highlights. The blurring method is the most obvious way of 
doing it, and is actually a fairly accurate approximation of what really 
happens in the eye. You wanted one thing, so you attacked the code and 
did something completely different?

BTW, you're using a flat mesh to render the image? Have you tried 
writing to an ASCII image format or using boxes instead? Maybe using 
banded gradient pigments to cut down on the number of primitives 
required? You should be able to get 128 "pixels" per primitive that way, 
more if you use fancier pigment maps. (16384 for 128 gradient pigments 
nested in another gradient pigment_map)

The automatic bounding heirarchy is not specialized for this kind of 
thing, you may get a speedup by building your own heirarchy. Have a 
union of unions of unions until you get to unions of a few boxes each. 
Maybe do it with scanlines, and use the nested pigment trick to do each 
scanline as a single box.

If you don't have any programs that will read ASCII PPM, write it anyway 
and use it as an image_map on a box.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.