Hi there,

I'm really sorry for not posting.
I, pretty much, wasn't doing anything ray tracing related :(.


For starters, I would like to give you a little update:
I'm writting my master's thesis this year and it's about raytracing.

However I'm working commercially, for quite some time now, in the Java EE / Spring field, and shamefully enough, I feel like going that direction.


I'm no longer the guy that had entire weeks to "waste" just to render that caustic reflections, in the cornell box, a little bit faster.

So that being said, writting my master's could be my last ray tracing encounter.
I know how it sounds, but to me, this thing is like, too much absorbing for a hobby, you know?

And how are you guys with your ray tracing projects? How is life?

Sincerely

Progressive photon mapping with metropolis sampling

Hi again,

To answer my last entry, I've added metropolis sampler to my photon tracing routine.

Well it was a natural thing to do.

I am aware of that paper by Toshiya et al. - Robust Adaptive Photon Tracing using Photon Path Visibility.

But since I am quite familiar with Kelemen's mlt, and I didn't want to switch to that sppm approach (I keep it as a traditional photon mapper with shrinking radius), I implemented it quite differently. Path quality is equal to how many photons do contribute to photon map (and photon map's bouding box is based on the visible hitpoints). So it just favors longer paths. Perhaps I could extend it to how much flux the path carries.

Also like in standard Kelemen's mlt, there are 2 mutation strategies, small and large mutation, which the former needs some further testing like mutation approach and size.

So enough talking, pics:

Path tracing:

Photon mapping - random sampling:

and finally, Photon mapping - metropolis sampling:

All images were computed in 2 minutes, also the metropolis code is still fresh and messy.

photon mapping vs path tracing outdoor test

So yea photon mapping doesn't handle biger scenes very well.

Glass is farily good (good caustics makes up for crap direct ilumination, I trace 5m photons every pass here, perhaps if I lowered that number I would get better direct lighting and antialiasing, but worse indirect lighting).

Photon mapping:

Path tracing:

Lambert material, photon mapping (without direct lighting computed separately):

Photon mapping with direct lighting:

Path tracing:

As expected path tracing performs better, maybe some fine tunning (photons per pass and initial radius) would help, but I don't expect miracles.

Download Red Dot demo

Hi there,

I would like to provide runnable version of the current incarnation of my raytracer.

I know it's nothing special, but maybe someone would like to run it, just for fun, I know I would.

https://sites.google.com/site/ciebiada/reddot_demo.zip

Unpack the zip archive and there you have it - double click on reddot.jar or type:

java -jar reddot.jar -Xms1g -Xmx1g

(if you care about the performance it is acutally a lot, lot better if you specify those options from command line, because if not, jvm will get too little memory for photons, and GC will trigger like crazy)

It reads obj files (with its material representation) straight from blender exporter.

But since camera is fixed I didn't provide a gui for importing your own scenes yet.

Image is updated every each 5 seconds.

Moreover, rendering fashion depends on 3 parameters:

• initial radius = (world_max - world_min).length / 50
• photons_per_pass = 100000
• alpha = 0.5

Initial radius just like in regular photon mapping is a tradeoff between smoothness and details. If the initial radius was smaller, the caustic would be sharper from the start, but image would be noiser overall.

Instead of basing it on the world bounding box, I perhaps should base it on bounding box of the photon map. But in this case it's exactly the same.

Photons per pass means how many photons it shoots between ray tracing passes. It doesn't store photons for the first hit, because direct ligting is computed like in regular path tracer.

This is also kind of a tradeoff. In scenes where there is no direct ligting (emitter is not directly visible by the diffuse surfaces) all direct lighting computations (visibility checks mostly) are a waste of time. But in the other case, when surfaces are lit directly, those direct lighting computations helps quite a lot.

And an alpha parameter controls how fast the initial radius shrinks.

Here I attach my 45m render (mobile i7):

Photon mapping continued.

Quick 5 min render.

It clearly reveals an issue with smooth normals.

Photon mapping ownz!

Hi there, it's been a while.

I've implemented progressive photon mapping, first exactly as it is in original paper (constructing hitmap once and shooting photons in the main loop), it was all nice and fast but quite troublesome, especially if it comes to antialiasing and glossy materials.
Then i've implemented the more basic approach to PPM as in this paper.

But I have some isues as for now:

• I am not sure about the adjoint bsdf for shading normals. What's obvious is smooth normals didnt work out of the box for the lambertian. What I did is using original normal, and scaling contribution by |in*nor_s| / |in*nor_g|, kinda works but I am not sure. What with other materials? For specular and dielectric it seems to work with just smoothed normal in place of the geometric one.
• Since I'm still using Java I have problems with Garbage Collector, I build uniform grid for 100000 - 200000 photons every pass on all 8 threads separately and that really kills the GC, even if I try to reuse the grid. Any suggestions?
• Shading on hard corners, for example 90 degree corners between the walls. Right now I use simple hack to check for the angle between the photon and surface normal, but that makes them black, the blackness does shrink over time but doesn't seem to ever disappear. So I wonder if it wouldn't be a better choice to leave it alone converging to the right sollution in +inf time and 1/inf radius (?)

Other than that it's blazing fast. This image took around one hour to render:

But was already pretty good after minutes.

Couldn't resist the GPU hype,

so I wrote an open cl path tracer in C. It's very similar to Dade's SmallptGPU but it uses float4 though.
I don't have proper GPU to test it on, but I got tempted by sse operations that vector operations supposedly utilize.

A performance note:

While I get 2 fps on this scene with my core 2 duo (no ht), my friend with his radeon 4870 gets almost 60 fps.
I'm not yet sure if thats good enough.



(I misleadingly called frames samples, while they are samples per pixel, yea)

Water caustics

One of the hardcore scenes to test. Forgive me the noise but my bvh is so slow :(.

Cheers.

A little update

Hi there,

What's new:

• Added Beer's law to the glass material - you can tell how absorption varies with the distance traveled (for ex. monkey's ear is barely colored versus it's middle).
• Pixel filtering - added variety of filters. The black border around the light source is due the negative values of mitchell filter.
• Reimplemented simple bvh and .obj parser.

Btw. could somebody tell me:

when I specify my light intensity with pure rgb triplet as its emittance, for ex. (15, 15, 15) - what units are those? And how could I convert between other, perhaps more physically convenient, units? so I could compare my results with other renderers.

Cheers.

Sup?

Friend of mine has i7:


rendering time: 20 minutes, no direct lightning, just naive path tracing with metropolis sampling.

Cornell box

I just like them.

I'm back

Yet again starting from scratch. Playing with metropolis.



Naive path tracing on the left, same thing but with metropolis on the right.

Metropolis Light Transport and stuff.

Hi!

Long time no see. Like always I was rewriting it from scratch a couple of times. But nevertheless it's still java and now it uses metropolis sampling to help that poor path tracing converge.

Btw. I did MLT on yesterday evening after 2 beers (it had to be Ballmer peak).

Altough the implementation is still very fresh it easily outperforms standard path tracing, what is to be seen especially when difficult caustics are involved.

I've implemented spectral rendering too, it was very easy actually, cause all computations on wavelengths are linear just like rgb. But then I realised that even if it does feel more physically correct to do so, whats the point? 3d applications are operating in rgb color space, and because I cant represent a rgb color as spectrum interchangeably I have to approximate it, so as long as I'm not running a physical simulation or something I don't see the benefits (please correct me if I'm wrong), thus I abandoned that.

I was also working on dispersion (rgb rendering), but that feature needs a little more work (I've included an old pure path tracing rendering with dispersion visible)

Edit:

Explicit direct lightning

gives a lot,

unmatched quality:

A fireflies happen to appear from time to time (there is one on the ceiling for example) and, what's funny, it's a random thing while my PRNG has constant seed values.

I'm almost sure its because all threads share one random number generator and what seem to happen they are at times calling random procedure ALMOST in the same time, reassigning the values unpredictably.

Edit:

Blah

Seems my sRGB conversion was causing that fireflies from previous images.

Btw. I was wondering why the farthest I've ever get in ray tracing (excluding fixed path MLT in C++) was when I was using OCaml. Say what You want, but that functional language thing fitted ray tracing very well. Also, but that's maybe caused by my nature - now when I have dozens of ways to implement something I start to wonder what way to choose, what would lead to better design. Too many options confuse me, and slow me down big time.

I've set emitter colour to rgb approximation of 2600K, it makes some nice, realistic atmosphere.

It's still naive path tracing, though.

Multithreading and some GUI

Hi there,

I've added some multithreading and was playing with gui in swing.

As far as everything was a very pleasant experience, I'm concerned that
I got only ~190% load on my two cores, what means that the speedup is not exactly 2x.

So I've tested sunflowand noticed
that it also doesn't get anywhere near 200% - 180%-190% most likely. So I don't know...

Java path tracing

Hello I'm back.

My current weapon of choice is Java though.

The renderer supports:

• median split BVH,
• thin lens and pinhole camera models,
• sphere and Triangle primitives,
• naive path tracing with lambertian surfaces only,
• rendering in a progressive manner.

Performance is not that bad. I designed it to take full advantage of the new feature of java called Escape Analysis, so I'm not reusing objects (what leads to ugly code btw.) but creating them like crazy.

What sucks though is that there is no 1.6.0_14 java for Mac OS X yet, but I've tested in on windows and it works very well.

Some first, naive path tracing, renderings: