 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greetings Photon Phonatics !
As I have been using the new Photon patched version of Pov-Ray I
have been keeping a small list of things that seem odd, I want further
clarification on, or possible problems with the patch itself that he
should know about. As I complete a new each new set of notes I will
post them here so that the information is not spread across several
different groups. Feel free to respond to my questions if you want to
or if you have your own observations about the patch this would be a
good thread to attach them to. That way Nathan doesn't have to go
chasing around the different subject groups to find it all and it will
be here and ready for him when he gets back from his conference trip.
Ron,
If there is a subject group more suitable for this let me know and
I will clear out of here and move to the appropriate forum.
Regards,
--
Ken Tyler
My current list of observations and questions regarding the Photon Patch
1.) What effects do transmit vs. filter have on behaviour ?
Which have you been using to specify a glass material during
your development work?
2.) What direct effect does max trace level have on the photon
collection process ?
2a.) Add to this what effect does the ior value have on the collection
process.
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.
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.
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.
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.
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.
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.
That is all for now.
Thank you for your continued support.
Ken Tyler.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Ken.
I think I can answer this one for you.
>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.
Photons are shot at an object's bounding box. POV is at a loss when
trying to automatically bound an intersection of planes (or any other
infinites) only. When you intersect a box with a plane, POV knows for
sure that the resulting object will be bounded by the aforementioned
box. The solution is to manually bound your CSG of planes. It will
speed up the render, too.
---------
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 25 Mar 1999 01:20:24 -0800, Ken <tyl### [at] pacbell net> wrote:
> Ron,
> If there is a subject group more suitable for this let me know and
> I will clear out of here and move to the appropriate forum.
It's not my newsgroup, so do what you will. In any case, this seems
like as good a place as any for it, since it's the closest thing we
have to an "unofficial patch" group. Besides, I think photon mapping
is cool (even if I haven't done anything with it yet.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike <Ama### [at] aolcom> wrote:
: 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.
He also mentioned that he will add an adc_bailout value for the photons.
That surely will be handy since I'm constantly running out of memory.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken heeft geschreven in bericht <36F9FFD8.D4819465@pacbell.net>...
>Greetings Photon Phonatics !>
> .............
>
>4.) How do you force it to stop sending out so many photons ? ...........
Use autostop 0 in the global_settings
Don't start with a very small radius and density setting. Use only one or
two steps.
>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
>.....
No, I think the settings are ok. Keep an eye on the priority queue remove
value, keep it close to zero.
> .......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.
It seems to depend on the type of object (ior?) and the light position. A
light shining through a (converging) lens on a plane will gather lots of
photons. An object that diverges the light will gather less.
>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. .......
Didn't try prisms yet, but for lenses and mirrors the patch behaves
accurate. You can build complete optical systems, use photons_pass_through
on every optical element except for the last. Only have the last element
generate the caustics. Every element should have the appropriate glass
texture and ior. Use a high setting for the max_trace_level (this also helps
against the black shadows in the glass with liquid scenes).
For prisms the problem will be the total internal reflections, as pointed
out by Mike.
>
> That is all for now.
>
> Thank you for your continued support.
>
> Ken Tyler.
When I set up a one light, one object scene, in global_settings I set the
photons radius to an angle of say 0.05 to start with. Then in the object I
set the density
to 0.1, followed by a test render. If queue remove value is high I make the
density value bigger. If the remove value is not shown I reduce the density
value. Make the remove value close to zero.
To change the quality (sharpness) of the caustics, devide (or multiply) the
radius and
density values by two. Then tweak again. The parse time and memory use will
go up, the rendertime will stay the same (almost)
Continue these steps until you are satisfied, run out of memory or until
UVPOV gives up (caustics are gone).
If you change the lightposition or the camera position much, you can start
tweaking again. Also when you change the properties of the
defracting/reflecting object (thickness of glass, ior).
Put "I think, ..." before and after everything I stated here.
ingo
--
Met dank aan de muze met het glazen oog.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have a couple of questions too:
1. The photons are not supporting spotlights right now (spotlights are
handled just like point lights). I suppose you will add that feature in
the near future.
2. The photons do not interact with atmospheric (scattering) media. I
suppose you will add that feature too (or is it possible at all?).
3. Are you going to add support for area lights and how?
4. What's the meaning of life?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1. The photons are not supporting spotlights right now (spotlights are
> handled just like point lights). I suppose you will add that feature in
> the near future.
I think he mentioned a few days ago that he plans on adding that
eventually.
> 2. The photons do not interact with atmospheric (scattering) media. I
> suppose you will add that feature too (or is it possible at all?).
There's already some code to do this, but it's commented out in the
source. I haven't worked up the nerve to try it out yet (maybe today).
It's not only possible to get it to interact with media - there is a way
to store photon IN media. As has been mentioned before it apparently
very slow to do this though.
> 3. Are you going to add support for area lights and how?
I think I saw some code for diffuse interreflection that isn't used yet.
It's probably incomplete at this point.
> 4. What's the meaning of life?
To render and render often.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> 1. The photons are not supporting spotlights right now (spotlights are
> handled just like point lights). I suppose you will add that feature in
> the near future.
hmm, light_source in a differenced cone, outside totally diffuse and black,
inside totally relflective. that should do for now. noo?
> 2. The photons do not interact with atmospheric (scattering) media. I
> suppose you will add that feature too (or is it possible at all?).
I'm suuure he will(if we bugger him enough)
> 3. Are you going to add support for area lights and how?
Hmm, as a grid of point_lights is my guess...
> 4. What's the meaning of life?
42.
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
par### [at] my-dejanewscom (Ron Parker) wrote:
>since it's the closest thing we have to an "unofficial patch" group.
not any more (remember to get new groups)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
