Warp wrote:
>   Naturally if two photons reflect from the surface and end up hitting the
> same image pixel, their brightness gets added, not averaged. There's no
> such a thing as "averaging photons" in nature.

Technically, there is, except you average them in a complex space (as in 
real+imaginary) instead of linearly.  ;-)   If you *really* wanna get 
physically correct.

> However, in specular reflection the reflected ray retains at least
> part of its own color and is not completely filtered by the surface's
> color. This is something which happens in nature.

Isn't that one of the things that makes a surface look metalic? That the 
reflected rays retain their own color because the photons are bouncing 
off the free valence electrons roaming around on the surface of the 
material, rather than hitting a bound electron in a particular "shell"?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Isn't that one of the things that makes a surface look metalic? That the 
> reflected rays retain their own color because the photons are bouncing 
> off the free valence electrons roaming around on the surface of the 
> material, rather than hitting a bound electron in a particular "shell"?

  Most materials reflect light at least partially specularly. That's why
you can see highlights of the light's own color on most surfaces, or at
least something closer to the light's color than to the surface's color.
The phong highlighting used in rendering is a cheap way of simulating this,
and it usually makes surfaces look like plastic, as most plastics have an
accentuated (blurred) specular reflection property.

  IIRC metals behave a bit differently and can affect specular reflection
in other ways, but I don't remember details.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I'm not trolling here. I have access to the pov3.7 source and I'm helping
> the pov-team develop it (eg. the new string comparison operators were added
> by me). I would be interested in testing this kind of rendering to see if
> it's feasible. Although unlikely, it's theoretically *possible* that I could
> try adding some support for this to pov3.7, if I could just figure out the
> algorithm how it's supposed to be done.

  Well, I suppose I will not be testing this on pov3.7 and any chance of
having anything like this is out.

-- 
                                                          - Warp

Post a reply to this message

> Warp <war### [at] tagpovrayorg> wrote:
>>   I'm not trolling here. I have access to the pov3.7 source and I'm helping
>> the pov-team develop it (eg. the new string comparison operators were added
>> by me). I would be interested in testing this kind of rendering to see if
>> it's feasible. Although unlikely, it's theoretically *possible* that I could
>> try adding some support for this to pov3.7, if I could just figure out the
>> algorithm how it's supposed to be done.
> 
>   Well, I suppose I will not be testing this on pov3.7 and any chance of
> having anything like this is out.
> 

I'd like to help but I have entire books on the subject here, and 
retyping them is beyond my patience ;)

This one already popped up in the discussion: http://www.pbrt.org/
I also have the first edition of this one: 
http://www.advancedglobalillumination.com/

I don't think it would be feasible to pack this kind of algorithms in 
POV-Ray easily. It's not just a matter of shooting more rays, they use 
different definitions for materials that wouldn't be compatible with the 
POV-Ray way.

On the other hand, I never looked at the source code of POV-Ray, so 
maybe judge for yourself.

-- 
Vincent

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Well, I suppose I will not be testing this on pov3.7 and any chance of
> having anything like this is out.
>
> --
>                                                           - Warp

I can't see how that's a bad thing, there must be plenty left to do on 3.7
anyway without adding more features.

Tom

Post a reply to this message

> I don't think it would be feasible to pack this kind of algorithms in 
> POV-Ray easily. It's not just a matter of shooting more rays, they use 
> different definitions for materials that wouldn't be compatible with the 
> POV-Ray way.

Existing definition of pigments should work for any algorithm. Normal 
perturbations would work with some; not all actually use the normal 
vector. The whole finish and interior blocks may need to be different 
for each rendering algorithm. Objects would have no problem either, 
except for those that have built-in normal perturbation 
(smooth_triangle, bicubic patch, and smooth heightfield; any other?).

> On the other hand, I never looked at the source code of POV-Ray, so 
> maybe judge for yourself.
> 
It will be rewritten for 4.0 anyway, so we might as well...

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> I can't see how that's a bad thing, there must be plenty left to do on 3.7
> anyway without adding more features.

  Could people please make up their minds already? People want new features
and people don't want new features at the same time.

  It's not like me testing some new features would slow down the pov-team
in any way.

-- 
                                                          - Warp

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> I'd like to help but I have entire books on the subject here, and 
> retyping them is beyond my patience ;)

  I simply wanted to try the notion of raytracing in the way that no more
than one ray is ever traced from a given point (iow. a ray is never split
into two or more rays), and that the end result is produced by sending many
rays from the same pixel and averaging the results (which is basically what
antialiasing does).
  In theory if the scene has many objects which would split rays, as well
as other features which would require multiple rays (such as area lights),
doing it this way would reduce the overall number of traced rays per pixel
while still getting an acceptable result, thus speeding up the rendering.
(This is, AFAIK, how Pixar raytraces their images.)

  However, I don't want to read lengthy books filled with material and
lighting theory just to try this. If someone could write me a simple
algorithm then I could try it.

-- 
                                                          - Warp

Post a reply to this message

>   However, I don't want to read lengthy books filled with material and
> lighting theory just to try this. If someone could write me a simple
> algorithm then I could try it.
> 

Well Scott did, and it's not all that difficult to perfect it to obtain 
the result you seek, i.e. to have different colors for diffusion and 
reflection.

color = 0
for ray=1 to 1000
r = random number between 0 and 1
a = specular_amount
b = specular_amount+diffuse_amount
c = specular_amount+diffuse_amount+refraction_amount

if 0 < r < a
  color += reflection_color * fire_reflection_ray

if a < r < b
  color += diffuse_color * fire_diffuse_ray_in_random_direction

if b < r < c
  color += refraction_color * fire_refraction_ray

if c<r<1.0 //absorption
  color += 0

//Of course you could have emitting surfaces as well
if emission
  color += emitted_color

next

pixel_color = color / 1000

The algorithm should check that c<1, obviously, otherwise the surface 
transmits more light than it receives.

The real problem with that approach, that you should have pointed out, 
is that the lights are missed most of the time if you don't fire rays to 
them specifically. If all your lights are point lights, they will always 
be missed.

With very simple BRDF such as these (specular + diffuse), you would only 
have to fire shadow rays in the diffuse case above. And possibly sample 
all visible emitting surfaces. I don't remember the details...

The other problem is deciding when you stop firing rays. If many 
surfaces have no absorption, it's possible to end up with very long 
paths... I think one of the books uses a form of Russian roulette to 
stop ray spawning and still keep an unbiased picture.

-- 
Vincent

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> > I can't see how that's a bad thing, there must be plenty left to do on 3.7
> > anyway without adding more features.
>
>   Could people please make up their minds already? People want new features
> and people don't want new features at the same time.
>
>   It's not like me testing some new features would slow down the pov-team
> in any way.
>
> --
>                                                           - Warp

I don't understand. Looking back through the thread, the only person discussing
this for 3.7 appears to be you; as far as I can see the rest of the discussion
was in the context of POV 4. Certainly I think it's pointless to add this to
POV 3.7, it would need a huge amount of work to get the sampling right.

I've no idea what will and what will not slow the POV team down. How could I?

Tom

Post a reply to this message