Ken wrote:
 
> 1.)  What effects do transmit vs. filter have on behaviour ?
>     Which have you been using to specify a glass material during
>     your development work?

Same as with no photon mapping.  Fade_distance and fade_power work too,
which I recommend for glass.  I also tend to use a transmit of .95 or so
for glass.  I only bother with filter if the glass has color.
 
> 2.)  What direct effect does max trace level have on the photon
>     collection process ?

Again, same as with no photon mapping.  Photons use the max_trace_level
specified in global settings.  Nathan mentioned that he might make a
seperate one for photons, but right now it's the same for forward and
backward tracing.  Once the max_trace_level is reached, no further
tracing for that ray is done.
 
> 2a.)  Add to this what effect does the ior value have on the collection
>      process.

It changes the direction of a photon.
 
> 3.)   Occasionally the program begins rendering a black scene. There
>     is nothing that can be done internally to reset to a correct render
>     behaviour forcing a program closure and restart. It then will
>     render correctly. It is a hit and miss bug but has happened maybe
>     5 times now.

I think this may be related to something I mentioned to Nathan a little
while ago.  There's some global variables that probably need to be reset
before each render.  I'm sure this will be addressed as the code is
refined.

> 4.)  How do you force it to stop sending out so many photons ?
>    There are times that no matter what parameters you choose it will not
>    stop counting. I have seen the gather vs. shot count running 1:1 and
>    after 5 minute with no end in site the render was manually stopped.
>    It seems to be finding photons that just are not there. And yes
>    I know that the parameters were in the ball park because there were
>    cut and pasted out of a working scene with similar objects and lighting
>    /finish attributes.

I think it's only controllable with the various tuning values, like the
stop angle, density, or gather.  To tell it to only shoot like 1000
photons would be like telling POV-Ray to render only 50 pixels - it
wouldn't know which 50 to render.

> 5.)  If I collect more photons than I shoot does this indicate that I do
>    not have my gathering radius and/or the number of steps set correctly
>    or is this an ideal situation. It seems to me that in most cases you
>    would seek to have shot more photons that the number gathered.

dunno.
 
> 6.)  If I shoot white light through a 60 degree equilateral triangle
>    should I be getting prismatic dispersion on the output ? I know
>    Darrens patch addresses this internally but was wondering about the
>    effects of external out put with no method of assigning an internal
>    dispersion characteristic.
> 
>    There is a practical reason for asking this aside from the ideal
>    material. I have a large very detailed high triangle count mesh
>    of a human skull. When I tried to use it as a glass object the many
>    convolutions of the shape of the mesh gave me prismatic despersion
>    seen on surrounding objects. Even with a max trace level of 40 I
>    was still having problems with getting light to pass through all
>    of the surfaces and gave up in favor of a different project. I was
>    just wondering if this was expected behavior or did I just catch
>    the oddball.

Hmm, you mean to ask if photons are effected by dispersion?  So far I
don't think this is turned on.

> 7.) On the same topic as above should light bend in accordance with
>    the natural laws of physics or is the photon model used in the
>    patch more of a visual gimmick than a relativistic lighting model.
>    I have observed unnatural behaviour in three different prisms
>    constructed using differing methods. Each was tried with a wide
>    range of both photon related parameters and options as well as
>    changes in refraction, reflection, and  the filter/transmit values.
>    None of the computer based models matched a physical prism I have
>    been using as a reference for comparison.

I think that what is covered is accurate, but the one characteristic of
a prism that is modelled currently is total internal reflection. 
Dispersion and other subtle effects of angle dependant reflection and
tranmission are not.  If the wyzpov patch is merged with the backtracing
portion of the code than some of this might work, although there's
probably better models that could be used that no one has written yet.

In other words, if at a certain angle a ray is reflected 90%, then the
transmission should be 10%.  Obviosly if something like this were
included as an option, it should be turned on with a seperate keyword so
as not to remove any artistic liscences one way want to take.  The way
photon mapping works now creates very accurate looking caustics, even
though there are many things that aren't taken into account.  The reason
being that the sampling is smooth, so the lack of detail actually
creates the illusion that several other things are present.  You may
notice that the more refined the photon gathering, there seems to be a
point where it starts to look less accurate because it's too perfect.

> 8.) Are there any object types that are excluded from working with
>    the photon patch, photon specific, properties ?
>    Of the different object types the patch seems to provide the least
>    functionality with are triangles and meshes, it works properly with
>    procedural primitives, and seems to really choke on CSG constructs
>    like a shape made out of intersecting planes. The last is one that
>    gave me the runaway photon counter mentioned above. A box trimmed
>    with an intersecting plane works well but if you use all planes to
>    form a refracting object it goes nuts and no parameter will change
>    the way it reacts. This is of course a one object, one time, situation
>    that I have not confirmed with other constructions or construction
>    CSG types.

Just keep in mind that photons are shot at an object's bounding box.  A
plane is actually is bounded, but the size is around the limits of what
POV-Ray can handle.  As far as CSG goes, you may recall the hard time
spider had rendering the glass tree.  The bounding box surrounds the
whole tree, so there's a very small volume inside a larger one,
therefore the chance of getting a hit isn't very good.  The closer the
bounds match the object, the better hit/miss ratio you're going to get. 

What I've said might not be totally correct, but given the gist of most
of the questions, I think there's one thing that should be noted - the
photons pretty much use the same model as a normal ray.  Nathan copied
the code from compute_lighted_texture with some modification.  The
photon mapping code seems to be mostly involved with how many photons to
shoot, the starting direction, and how to store them in the kd tree. 
How they behave behond that is just like regular POV -> Rays. ;)

-Mike

Post a reply to this message