Page MenuHome

Cycles: Implement an area preserving parameterization sampling for area lamps
ClosedPublic

Authored by Sergey Sharybin (sergey) on Oct 10 2014, 3:28 PM.

Details

Summary

Replace old code for area lamps which was more like incorrect with more correct
one using the following paper as a reference:

Carlos Urena et al.
An Area-Preserving Parametrization for Spherical Rectangles.
https://www.solidangle.com/research/egsr2013_spherical_rectangle.pdf

Implementation is straight from the paper, currently the rectangle contants are
calculated for each of the samples. Ideally we need to pre-calculate them.

The old PDF is still used, which makes difference real subtle. This is to be
corrected before final commit.

Diff Detail

Repository
rB Blender

Event Timeline

Sergey Sharybin (sergey) retitled this revision from to Cycles: Implement an area preserving parameterization sampling for area lamps.
Sergey Sharybin (sergey) updated this object.

Mainly sharing because i remember @Thomas Dinges (dingto) was trying to make this working. Not sure where exactly he struggled.

Now we only need to implement proper PDF calculation using section 5.2 from the paper.

Implement proper pdf

This revision was automatically updated to reflect the committed changes.

Committed by accident from one WIP branch to another.

The patch works great, here an example with an area light inside a volume.

Old:

New:

Finally i had something working :)

Did you run some benchmarks already, seems it's like 20% slower? Things were a bit crazy here, didn't check how much slower we
re now (was developing on a laptop which isn't good for such kind of tests).

I tested color_ramp.blend but replaced the 9 Mesh Lights with Area lamps.

Before: 40s
New: 49s

The issue in this scene is, that the image was not better. In general the improved sampling only helps in cases where the lamp is near a surface/volume.
So when you lit the scene from far away, you will get slower renders but no visual improvement.

How much can we pre calculate?
Edit: Seems we could precalc the first few variables (corner up to z)

Reference space we can calculate quite easy in device_update() (in worst case we'll bump memory usage a bit tho). It _seems_ we can pre-calculate rectangle coords and solid angle when connecting light for branched path tracer.

Right, can take a a look this weekend if you like.

Minor optimization: we already know the rectangle normal

Just a small code cleanup

Tried to precalculate some constants. Unfortunately this is not faster, it's about the same.

Yes, that's because those few cross-products are nothing comparing to the complexity of sqrt and sine happening later.

Some ideas:

  • Get rid of conditioning, let it be numerical errors in some real corner cases. Removing branching would make code friendlier to the cache. From quick tests it only gave unmeasurable speedup tho.
  • Use SIMD. Seems we can use a bit in here.
  • Test with scenes from ToS or secret agent. I bet slowdown in those cases wouldn't be that drammatic, because area lamp sampling is just a fraction of all the complexity in there. If there'll be no so much slowdown in here i think we can just commit it.

Btw, does it work on GPU, had some issues building cubin on laptop so far due to RAM.

Tested with sm_21 on Geforce 540, works fine (both compilation + render).

As for the speed you are probably right, in a typical scene the area light is just a fraction of the render time.

This revision is now accepted and ready to land.Oct 12 2014, 2:05 PM
Sergey Sharybin (sergey) edited edge metadata.

Some final touches to the patch

  • Minor optimization, some pdf terms were dicarding each other
  • use proper PDF for MIS
This revision was automatically updated to reflect the committed changes.