Irradiance Caching

Ideas, enhancements, feature requests and development related discussion.

Re: Irradiance Caching

Postby sascha » Fri Jul 31, 2009 10:57 am

For REYES it's easy to subdivide and dice until each micropolygon is smaller than a pixel (and thus the surface looks extremely smooth). The renderer knows how large each primtive will be on the screen, and based on that knowledge it can decide either to subdivide it, or to dice it (and set the dicing-rate such that each micropolygon will be sub-pixel sized, but not much smaller). There are some issues with ditching adjacent primitives that have been diced at different levels without creating holes in the surface, but all in all the algorithm is quite straightforward.

Raytracing is different. You have ray/bounding-box collisions, and after that have to decide the subdivision level. This is relatively easy for primary rays: if a standard perspective projection is used the renderer has the same information as a REYES renderer and can set the subdivision level based on the estimated screen size . For secondary rays (shadows, reflections) things are more complicated, the renderer needs to know the width of the ray (see beam- or cone-tracing). I think the most feasible approach here is using ray-differentials. You need this information anyway (and especially for primary rays) to do shader-antialiasing (or even mip-mapping). So I think ray-differentials are a must, both for a stand-alone raytracer and for the raytracing part in a hybrid REYES/raytracing solution.

A REYES renderer could handle a Wal-Mart, with shelves, the 10,000 or so different items of merchandise in quantities of 1-100 each, without any trouble at all. POV-Ray would be thrashing my hard drive somewhere about 10% of the way through parsing, unless I replaced each object with sprite versions.

D'accord. All I was trying to say is that it's futile to discuss such issues on the povray newsgroups ;-)
Seriously, to handle massive amounts of geometry, both approaches (scanline and raytracing) fall back to cheating, be it different models for each level-of-detail, instantiation, displacement mapping, baking, layered rendering, etc.
Both REYES renderers and raytracers have been used in the production of feature films, and I'm quite sure that it's possible to teach something like mental-ray to render your wal-mart scene within a reasonable time. POV-Ray is fun, educational, useful for scientific visualizations, and I really, really like it a lot, but it's NOT a production renderer. It lacks a lot of features that are mandatory even for the most basic animations, but unfortunately the POV-team is quite ignorant about that (and some of the users on news.povray.org too), so I have shifted my focus away from POV-Ray and towards Renderman.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Irradiance Caching

Postby pndragon » Fri Jul 31, 2009 11:13 am

which version of JPatch are you using? Could you point me to a link?
http://www.jpatch.com/temp/jpatch20060523.zip
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Re: Irradiance Caching

Postby dcuny » Sat Aug 01, 2009 5:38 am

Thanks!
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby John VanSickle » Tue Aug 04, 2009 1:32 pm

sascha wrote:POV-Ray is fun, educational, useful for scientific visualizations, and I really, really like it a lot, but it's NOT a production renderer. It lacks a lot of features that are mandatory even for the most basic animations...

I think you are using the term mandatory a bit too loosely here. I've done dozens of animations with POV-Ray, and I'm interested in knowing how I overcame the lack of these mandatory features. :-)
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: Irradiance Caching

Postby dcuny » Tue Aug 04, 2009 4:30 pm

That reminds me of a thread I ran across last night discussing the Reyes algorithm, complaining that it lacked features required of a production-quality renderer, like raytraced shadows and reflections. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby sascha » Wed Aug 05, 2009 8:41 pm

I've done dozens of animations with POV-Ray, and I'm interested in knowing how I overcame the lack of these mandatory features.

That's indeed quite an interesting questions, and thinking about it, I've made several animations with POV-Ray too (and two for the IRTC.) ;-)
But on second thought: I've used MegaPov for one of them, because I had the choice between using some incredibly complex lighting-setup for rim- and back-lights (that would have slowed down rendering and caused some unwanted shadows, because POV-Ray thinks that when you turn off shadows it has to turn off specular hightlights too, I mean, what else would you excpect?) or using Mega-POV and faking the rim light with its angle-of-incidence feature.
For the other animation I needed a 3D procedural texture that moved with the object, again something POV-Ray can't handle (the missing feature is called "reference geometry" and RenderMan is flexible enough to let you do that and much more). So I grabbed David's Inyo sourcecode and added the feature in about two hours, and I still don't know why nobody can add this to POV-Ray.

But of course you're right, POV-Ray is cool, and it's easy (and funny) to learn and use. It's still a pity that some features that would be mandatory^H^H^H^H^H^H^H^H^H incredibly useful for animation (and easy to implement) are missing. If something would speed up rendering times the usual povray-newsgroups consensus is "uhh, no way, but this wouldn't be physically accurate" (as if Phong lighting was physically accurate). I wonder why they didn't remove the fake caustics once photon mapping was added. Reference geometry? It took us 10 years to finally add the u/v mapping patch to the official version, so why bother...

RenderMan has a much steeper learning curve, and manually tweaking RIB files (as you would with POV-Ray scene files) isn't quite as fun, but I think eventually focusing on RenderMan will pay off. I really like your IRTC animations, but I think that some of them reached the limits of what's possible with POV-Ray and rendering them in 1920x1080 instead of 320x240 would be a problem - not only because of the speed, but e.g. because of aliasing problems and noise, and the only way to get rid of these in POV-Ray is to increase the rendering time.

Still, I love POV-Ray and I understand why people are using it, and I'm quite sure that I'll do some more animations with POV-Ray too. Animation is just not POV's primary focus (alas).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Irradiance Caching

Postby dcuny » Fri Aug 07, 2009 7:06 am

My "coding vacation" is on hold because of various things at work. :?

That's probably just as well, because I'm not quite ready to start coding yet. If I can figure out the math on the SDS stuff, I'll probably end up working on that instead of the irradiance caching.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby dcuny » Wed Aug 12, 2009 6:59 pm

Allow me a moment for a Doh!

My plan a couple of weeks ago was to start out simple, with a basic "spheres and plane" sort of ray tracer, and add irradiance caching to that. It took very little time to cobble together something that rendered spheres. So far, so good. Then I added a basic plane - again, trivial.

Then I tried adding shadows, which is a trivial extension to the code. And it didn't work. :|

Now, in retrospect, all bugs look really, really obvious. The real trick is to ask the right question. And I've been trying for the last week to figure out why this code didn't work, when it would render spheres, but the shadow rendering code completely failed.

Finally, a simple test occurred to me: place a sphere around a light. That way, every single object should be in shadow. I stepped through the code, and everything looked like it worked... except the distance the intersection routine was returning was a negative number. That just didn't make sense.

So I jumped on Google and found a Wiki with the sphere intersection code on it. This line caught my attention:
Code: Select all
Vec oc = sphere.c - ray.p;

Compared to my code:
Code: Select all
      // save some effort recalculating
      double d_min_o_x = ray.direction.x - this.origin.x;
      double d_min_o_y = ray.direction.y - this.origin.y;
      double d_min_o_z = ray.direction.z - this.origin.z;

What the heck does ray.p stand for? So read the text, which said:
First, we find a vector from the ray origin to the center of the sphere,

Doh! :roll:

Since the ray/sphere intersection code had been working from the eye point, I'd assumed that the routine had been working, and hadn't bothered to look at it more closely. Sometimes, coding can make me feel downright stupid.

As I said, debugging is all about asking the right question. To quote Conan Doyle's famous character:
Sherlock Holmes wrote:How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?

OK, enough of that. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby sascha » Wed Aug 12, 2009 7:41 pm

:lol:

Ok, here's the most stupid bug ever, which puzzled me for quite a while:
I can't remember exactly, but it was something like that:
I wrote a test class to try out a few things:
Code: Select all
public class SubdivisionTest {
    public static void main(String[] args) {
        new SubdivisionTest();
    }

    SubdivisionTest() {
        do_something();
    }
}
It worked, but I wanted to optimize the do_something() method while still keeping the original implementation. I saved it under Test1, renamed the class and constructor and started modifying the do_something() method:
Code: Select all
public class SubdivisionTest1 {
    public static void main(String[] args) {
        new SubdivisionTest();
    }

    SubdivisionTest1() {
        do_something_else();
    }
}

Great, it worked and I've got the same results for Test1 and Test. Cool, so I copied the body of the do_something_else() method into some real JPatch code, but it didn't seem to work. Test1 worked perfectly, but the same code in JPatch did not.
I added some debugging println()'s in the JPatch code and the output indeed indicated that something was wrong. So I added the same debugging code to Test1's so_something_else() and guess what - it didn't print anything at all! What was going on?
Can you spot the problem?

Here's the solution (magic ink, mark to read it): The main() method of Test1 still calls the Test() constructor, not the Test1() constructor as it should. Copy and past, you know... What's a little frustrating is that I run into the same kind of problem over and over again.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron