super monaco gp

(L) [2006/05/05] [greenhybrid] [super monaco gp] Wayback!

[IMG #1 ]

I implemented some monte carlo. Light sources are the inner side of the wall and that green pyramid. I traced 6000 samples for each primary intersection, but it's still very loud ( noisy I mean ).

Do you know a hat-trick to get out that noise without using photon maps, I mean, nothing against photon-maps, but I have so little time....

Goooogling for "monte carlo raytracing" always brings up very mathematical stuff. I like it, but as I said, my time is short...argh :'(

EDIT: okay, I had a short think-about-break. I'm totally tired and f***ed-up, but I'll take a hard session this night implementing a kd-tree-photon-map

EDIT2: ah sorry, forgot to say it took 130 minutes to make that snapshot

EDIT3:

another, sooner one (the left wall is the light source). 800 samples per primary intersection. 40 minutes.

[IMG #2 ]
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]

[IMG #1]:Not scraped: https://web.archive.org/web/20061004013030im_/http://root-engine.net/greenhybrid/images/glass_log_0031.jpg
[IMG #2]:Not scraped: https://web.archive.org/web/20061004013030im_/http://root-engine.net/greenhybrid/images/glass_log_0030.jpg

(L) [2006/05/07] [Lynx] [super monaco gp] Wayback!

didn't want to shock him with (multiple) importance sampling [SMILEY Smile]

I don't know how exactly the images above where rendered, but i assume you sampled from BSDF only, which is the simplest version i can think of for lambertian diffuse...

you could try sampling from light instead from BSDF (i.e. create area lights), should be much more efficient when the light emitting areas are much smaller then those not emitting light. But that already gets mathematical again when you have polygon meshes...

but multiple importance sampling would be better of course, because sampling from BSDF is bad for points far from light sources, and sampling from lights is bad for point near at light sources (but in these scenes probably a magnitude more efficient on average).

And you can go much more crazy to increase sample efficiency, fpsunflower recently implemented an algorithm that is somewhat a generalization of photon mapping and "instant global illumination" to yield unbiased results still, but i haven't looked at the newest version of sunflow yet and only skimmed through that paper he used...too busy rescuing another project...

(L) [2006/05/07] [lycium] [super monaco gp] Wayback!

i don't want to be nasty or anything, but it seems clear to me that trying to code MCPT with scant knowledge of the subject is perhaps not the best way to spend your already-limited time budget. you can't build a car engine by just welding bits of stuff you've got lying around together without knowing a little theory about efficiency, the four stroke engine, etc etc. if my previous statement seems obvious to you, please see that it's a direct analogy, and that the more you care about having little free time (i doubt anyone here is swimming in it ;), the more you stand to benefit by taking a directed approach. [it might also be a lot less frustrating, since once you've mastered the theory it's really not so difficult to code. conversely, it's a great feeling to understand such a beautiful body of knowledge, as any monte carlo freak will tell you!]

(L) [2006/05/08] [Phantom] [super monaco gp] Wayback!

If you are not doing this for a living, it might be worthwhile to experiment to find the limits of your knowledge. When I first started on ray tracing, I read a couple of papers (well actually a rather big stack of papers), then implemented a simple ray tracer, up to the point where I had a basic photon map working (without any theoretical knowledge of final gathering). Then I deleted everything, started from scratch, and documented the whole process. This became the legendary (cough) ray tracing article series. After that, I read a pile of papers again, and implemented my first interactive ray tracer. I'm now working on the third iteration, basically I deleted all code again. I'm working on a very minimalistic tracer now, but I know what every line does and it performs great. So now I have a solid basis to put back all other functionality, starting with recursive ray tracing. In the end, I want to put back photon mapping.

What I'm trying to say is that a full theoretical analysis followed by an implementation does not work for me. I can only store so much before forgetting things; I need to get my hands dirty inbetween. That this means that I need to 'refactor' is OK to me, I had fun during the process and gained a ton of knowledge. Perhaps this style fits you too.
_________________
--------------------------------------------------------------

Whatever

(L) [2006/05/08] [Lynx] [super monaco gp] Wayback!

Well, i have to admit that my renderer doesn't feature multiple importance sampling yet either, but with standard QMC path tracing and a properly designed area light you can already render stuff like this in a couple of minutes (even with totally unprofiled C++ code on a single Athlon XP 1800+ with MSVC 7.1...i suck at writing good performing code it seems, how else can it be 30-50% faster under linux on the very same machine...):

[IMG #1 ]

That's just a simple rectangular light, 5 indirect bounces and merely 64 paths per pixel (IIRC), scrambled halton sequences for sampling.

So nothing really fancy, just sampling from light for each hit point and choosing an outgoing direction by taking a cosine weighted sample of the hemisphere above the surface point (i.e. hard coded lambertian diffuse surfaces). Adjust path throughput and iterate for as many bounces as you like.

From there on you can add other BSDFs, implement MIS, create more complex mesh lights etc. if you knew before that you'll need correct PDFs for all samples etc...and because YafRay devs apparently did not know this, i'm still busy designing the framework rather than writing fancy new GI algorithms...the book "physically based rendering" helps me a lot there.

Which brings me to the same conclusions as Phantom: Play with the code until you know more, and if you notice the framework is no good anymore, consider starting from scratch. Your algorithms are not lost by doing this at all...what takes you much time is developing a structure where your algorithms work well, not necessarily implementing e.g. a path tracer inside it. I don't have any programming or even rendering related job (well i'm an IT-student, part of the knowledge comes handy but not too much really). Many papers are so interesting that i voluntarily try to understand the maths, other times i don't feel like spending my time on those and do some naive experemints, which sometimes even make me proud of myself even if it's just a minor thing [SMILEY Smile]

[IMG #1]:Not scraped: https://web.archive.org/web/20061004013030im_/http://lynx.aspect-design.de/yafray/box_path2.jpg

(L) [2006/05/08] [greenhybrid] [super monaco gp] Wayback!

yepp, I rewrote my tracer when I implemented my first kd-tree, now, with monte carlo, the code is getting pasta and I think I will rewrite again. This is the cool thing on raytracing, it just needs a couple of lines.

I made another screeny this morning before going to work (there are missing some lines because I was already to late to get to work ^^ I said there was a lot of traffic on the streets [SMILEY Wink] )

[IMG #1 ]

this is the one from this morning. 3000 paths per primary intersection.

[IMG #2 ]

and this one from this night. I resetted the random seed each time before tracing the paths.

I diddit to see if this would reduce noise, well it did not. But produced another (nice) bug, it's looking flamy heh. btw 6000 paths traced for each primary intersection.

What I haven't say yet is, that I am producing random directions to each direction in space, not only tracing the rays into the direction of the lights. This I've done due to the later implementation of full global illumation, but I learned something:

1st I should get really smooth shadows, then I should do more fascinating stuff like GI. And I'll do it more ++ like, with classes and so on.
_________________
[LINK http://greenhybrid.net/] | [LINK mailto:root@greenhybrid.net root@greenhybrid.net]

[IMG #1]:Not scraped: https://web.archive.org/web/20061004013030im_/http://www.root-engine.net/greenhybrid/images/glass_log_0032.jpg
[IMG #2]:Not scraped: https://web.archive.org/web/20061004013030im_/http://www.root-engine.net/greenhybrid/images/glass_log_0034.jpg

(L) [2006/05/08] [lycium] [super monaco gp] Wayback!

phantom, unfortunately the coherent/incoherent times are hugely incomparable: typically in a path tracer you don't spawn many rays (only for some [small area] direct lighting, and there you can really benefit, but still not in general) and only trace a single indirect ray, in a random direction. this is to avoid an exponential growth in # rays to trace ("curse of dimensionality"), which is why we're using monte carlo in the first place (eh also bc of discontinuities) instead of normal quadrature like simpson's method, which has much better than O(n^-(1/2)) convergence.

btw lynx, in that scene i don't think mis would be very beneficial since light source sampling is pretty pointless for the first few bounces of almost every ray. mlt to the rescue ;) it's actually quite difficult to beat path tracing in simple situations with big lights, not too much specular stuff going on, etc (like illumination due to hdri maps: [LINK http://liar.sourceforge.net/] - hi bramz! ;)

(L) [2006/05/08] [Lynx] [super monaco gp] Wayback!

lycium, you're probably right, biderectional methods to the rescue [SMILEY Very Happy]

I still haven't found the time to go through those MLT and "ERPT" papers/implementations...but definitely want to play with that stuff.

Otherwise MIS really seems more usefull for direct lighting especially with glossy stuff...

Anyway, am still stuck in totally different design decisions...how to do node based shading and sh** like that.

super monaco gp back