Rather NS than MS!


Steve

(as you can all see I've now got hold of the new browser version
settingw):

Spider wrote:
> 
> now this is SOOOO great...
> i have downloaded, three times.. (hmm, when NS says 502k of 270, something is
> wrong) but not installed yet.. I'll get at it :-)
> 
> Mike wrote:
> >
> > I'm having lots of fun with Nathan's new patch.  He and Ron should get a
> > kick out of this one (or anyone else who's read Jensen's papers).
> >
> > There's a few artifacts that I think may be there because the glass is a
> > mesh. I'm still unsure of the brightness on the base, but I suspect it
> > may be that odd phenomenon of light getting brighter before the
> > fade_distance is reached.  Not sure though.
> >
> > Took about 2 hours of fiddeling to come up with this, most of which was
> > learning how to use the patch - word to the wise: don't use photons on
> > infinite objects!
> >
> > Render time was 38 minutes at 640x480 and AA 0.3.
> >
> > -Mike
> >
> >   --------------------------------------------------------------------------------
> >  [Image]
> 
> --
> //Spider
> ( spi### [at] bahnhofse ) [ http://www.bahnhof.se/+AH4-spider/ ]
> #declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Steve wrote:
> 
> Rather NS than MS!
agree!!
 
> Steve
> 
> (as you can all see I've now got hold of the new browser version
> settingw):
congrats. 

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Thin will work.  I made the glass in Rhino because it makes smooth
curves and it fast to work with.  Making it thinner woulnd't be hard,
and the only reason I did the thickness is because I was going for
accuracy, which these caustics are!

Before this on I did a quick test with spatch using a thickness of one
patch and it looked great too.  That first test actually has neat
caustics because I had the light at a different distance.  I can't wait
to do an animation with a moving light, since the caustics change with
distance!

It's just too cool. :)

-Mike

Julius Klatte wrote:
> 
> I love the caustics.
> About the glass: it seems awfully thick (tough cognac glass
> I suppose?); is that necessary to achieve the clearly
> visible caustic effect, or does it work with thin refractive
> objects as well?
> 
> Julius

Post a reply to this message

Your diagram is right on.  I had a problem with coincident surfaces
(although I'm at a loss as to how I managed to model a mesh at exactly
y0), so I moved the plane down a little bit.  I'll mess with it some
more to see if I can get rid of it.  

I really like how good this patch came out.  It's not really that slow
considering that half the time is spent rendering reflection and
refraction regardless of the photons.

The only problem I've run into is trying to render caustics from a plane
with a normal on it.  One thing that might be worth adding is a bounding
option to specify an area on infinite objects (or finite objects for
that matter) to shoot photons at.  That way instead of using the
object's bounding box, use one the user specifies.

I noticed that sometimes I would render once and then go to render again
and no photon gathering was done. Then it would only do it again if I
moved a light.  Are you caching the photon maps and reusing them?

-Mike

Nathan Kopp wrote:
> 
> I'm pretty sure I know why it is overly bright, but I'm not sure right now
> exactly how to fix it.  Here's the problem:
> 
>      |______________|    glass
> ------------------------ ground
> 
> If the glass is just above the ground, photons will get deposited on
> both surfaces.  But they are gathered independly from the scene geometry,
> so you end up getting double the photons that you should get.  If you
> set the "ignore_photons" flag in the glass, it shouldn't store photons
> on the glass, so that should work as a workaround for now (speeds the
> render time, too),
> 
> Sorry I didn't include any demo scenes.  Once you get a good shooting
> density & gather density combination, you can usually just reuse that code
> to get started with a new scene.
> 
> One way to get rid of artifacts is to increase the jitter amount.  If
> that doesn't fix it, it probably is because your glass is a mesh.
> 
> Looks great, by the way!
>

Post a reply to this message

Steve schrieb in Nachricht +ADw-36E71AD9.C75418B2+AEA-ndirect.co.uk+AD4-...
+AD4-Rather NS than MS+ACE-
+AD4-
Why?

-- 
Rudy Velthuis

Post a reply to this message

Nathan Kopp wrote in message <36E7016F.72E68084@Kopp.com>...
>
>what strange effect?
>

The rim of the shadow gets darker, but beyond that there is a thin brighter
"halo". Perhaps this is caused by total internal reflection or something?
Reflective caustics were turned off in the test.

>
>If it's too sharp, try a larger gather radius.  I've done all sorts of
>tests with the brightness, so it _should_ be correct.
>


I haven't looked, but I'm pretty sure I don't have a sphere with an ior of
1.1 around the house :)
So I can't test my claim. I said it _seems_ strange, but it's impossible to
visualise refractive caustics in one's mind, so maybe it's correct.
Changing the gather radius doesn't change it, btw.

Margus

Post a reply to this message

Margus Ramst wrote:
> 
> Nathan Kopp wrote in message <36E7016F.72E68084@Kopp.com>...
> >
> >what strange effect?
> >
> 
> The rim of the shadow gets darker, but beyond that there is a thin brighter
> "halo". Perhaps this is caused by total internal reflection or something?
> Reflective caustics were turned off in the test.
> 

Ah, yes... that strange effect.  I should have warned you all (I'll document
it eventually).  That is caused by the way photon mapping works.  I haven't
found a good way to avoid it yet... increasing the density decreases the
dark/light ring.  That edge that you see is the border between using direct
lighting and using photon-mapped lighting.

-Nathan

Post a reply to this message

Mike wrote:
> 
> The only problem I've run into is trying to render caustics from a plane
> with a normal on it.  One thing that might be worth adding is a bounding
> option to specify an area on infinite objects (or finite objects for
> that matter) to shoot photons at.  That way instead of using the
> object's bounding box, use one the user specifies.

I agree.  I want to do this in such a way that it doesn't add too much
more to every object's struct (causing memory consumption to increase).

There is currently a workaround (but it's not very nice).  You take the
infinite object difference it and intersect it with a box that you want
to shoot photons at.  Put photon mapping on the intersection, then union
the two parts back together again.  Of course, if you do this with
complicated objects, rendering will be slower and memory usage will be
higher, so a better solution is something I'm looking into.

> I noticed that sometimes I would render once and then go to render again
> and no photon gathering was done. Then it would only do it again if I
> moved a light.  Are you caching the photon maps and reusing them?

no caching going on now (I want to do it eventually).  Maybe it's an
initialization problem (like the problem with stopping a radiosity render).
I've never experienced it, but I will be on the look out for it.

-Nathan

Post a reply to this message

> no caching going on now (I want to do it eventually).  Maybe it's an
> initialization problem (like the problem with stopping a radiosity render).
> I've never experienced it, but I will be on the look out for it.

I noticed that you don't the more I worked with it (and I peeked at the
source hee hee).  I bet it is an initialization problem, especially if
you got some of those 'floating' globals like with radiosity and Daren's
dispersion patch.  It would probably be a good idea to create a
deinitialize_photon_code struct and then add that to the section that
executes the other other ones for lighting and radiosity whenever a
render is stopped.  I could probably handle something simple like that,
so if I find something I'll let you know.

I found a more serious problem when I was rendering an animation using
photon mapping.  It seems that the memory isn't being freed between
frames, so about 1/3 through it sucked my resources dry and I had to
reboot to get it back.  I noticed that you wrote your own code for
handling the memory allocation for the photon maps, so that probably
needs some tweaking so it releases it in all cases.

I'll probably post the animation somewhere soon.  It's of a goldfish
underwater, and it came out pretty cool, albiet short. :)

-Mike

Post a reply to this message

I hadn't yet run an animation test... apparantly there's another spot where
I need to deallocate memory.  I think I know where it is, now that I think
about it.  POV's code is not too well documented, so things like this are
pretty easy to miss.  Until I get it fixed, just render a few frames at a
time.  ;-)

-Nathan

Mike wrote:
> 
> I noticed that you don't the more I worked with it (and I peeked at the
> source hee hee).  I bet it is an initialization problem, especially if
> you got some of those 'floating' globals like with radiosity and Daren's
> dispersion patch.  It would probably be a good idea to create a
> deinitialize_photon_code struct and then add that to the section that
> executes the other other ones for lighting and radiosity whenever a
> render is stopped.  I could probably handle something simple like that,
> so if I find something I'll let you know.
> 
> I found a more serious problem when I was rendering an animation using
> photon mapping.  It seems that the memory isn't being freed between
> frames, so about 1/3 through it sucked my resources dry and I had to
> reboot to get it back.  I noticed that you wrote your own code for
> handling the memory allocation for the photon maps, so that probably
> needs some tweaking so it releases it in all cases.
> 
> I'll probably post the animation somewhere soon.  It's of a goldfish
> underwater, and it came out pretty cool, albiet short. :)
> 
> -Mike

Post a reply to this message