[Bf-cycles] Future of the non-progressive renderer and Cycles strand rendering

[Nathan Vegdahl]

> But then you still have the
> issue of what to do for BVH building. Using this method, your radius
> can arbitrarily large, so what would be a good bounding box? I don't
> know how e.g. Arnold deals with this, for rasterization it's not that
> much of an issue but for raytracing we need good bounds.

To deal with expanded bounds, you can just add/subtract the expansion
radius to the max/min of each bounding box as you visit it.  It
shouldn't require a rebuild of the BVH.

It's a bit of a chicken-and-egg problem in this case, though, because
you need a good estimate of the ray footprint to know how much to
expand each bounding box, but you need to intersect the ray with the
bounding boxes to estimate the footprint.

But just expanding the bounds of a BVH is pretty straightforward.

Incidentally, if you can estimate an expansion radius for the root
node, then the rest should be pretty straight forward, as you can use
the estimate from parent nodes to expand the child nodes as you go
along.  Something like:

recurse_bvh(ray, node, expand_radius):
    if intersect(ray, node.bbox + expand_radius):
        new_radius = node.max_footprint_inside_bounds(ray)
        recurse_bvh(ray, node.child_1, new_radius)
        recurse_bvh(ray, node.child_2, new_radius)

Not sure how best to estimate the expansion radius for the root node, though.

Another thing to note is that even with the tightest possible bounds,
the BVH quality will degrade substantially as the hairs get thicker
and thicker, due to increased overlap in the leaf bounds.  In the
worst-case, all of the hairs substantially overlap with each other,
and you end up testing each ray against almost every hair.  I imagine
that would degrade performance pretty enormously (though it would be
good to test, regardless).  I feel like some kind of hair pruning
would need to happen as well to maintain performance for distant hair,
or hair reflected in a convex surface.

--Nathan


On Fri, Jan 4, 2013 at 8:17 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> Hi,
>
> I don't think there's any paper about the minimum pixel size method
> for ray tracing. I remember reading about it somewhere for
> rasterization but I'm not sure where. It's like stochastic
> simplification but without actually removing any curves:
> http://graphics.pixar.com/library/StochasticSimplification/
> http://graphics.pixar.com/library/500MillionHairs/
>
> The idea is quite simple. Basically you need to estimate some minimum
> radius for the hair in world space, based on the area covered by a
> pixel. When you scale up the radius you make the material more
> transparent at the same time to compensate.
>
> If you already had ShaderData set up I think you could compute it
> something like this using ray differentials:
>
> minimum_radius = minium_pixel_radius*len(sd->dP.dx + sd->dP.dy)
>
> Of course this will not have actually been set up yet, and you could
> compute something like it on the fly. But then you still have the
> issue of what to do for BVH building. Using this method, your radius
> can arbitrarily large, so what would be a good bounding box? I don't
> know how e.g. Arnold deals with this, for rasterization it's not that
> much of an issue but for raytracing we need good bounds.
>
> Perhaps the simple solution is to compute this all based on the
> distance to the camera and render resolution before rendering starts.
> The disadvantage is that it may not be quite accurate for reflections
> or refractions, but it does give a consistent geometry regardless of
> where the rays come from, and you can use tight bounds in the BVH
> tree. Another disadvantage is that it makes the BVH depend on the
> camera position and render resolution, so e.g. moving in the viewport
> needs a BVH rebuild.
>
> So I'm not sure yet how exactly it should be implemented, but I guess
> you understand the idea.
>
> Brecht.
>
> On Fri, Jan 4, 2013 at 3:35 PM, Stuart Broadfoot <gbroadfoot at hotmail.com> wrote:
>> Hi Matthew,
>>     As Brecht says, there’s a lot to do for the basics to be fully
>> functional. Once that is done it would be good to implement everything you
>> mentioned. I can not find many details on implementing a minimum pixel size
>> for path tracing though. All I could find is this very short paper/abstract
>> http://research.lighttransport.com/distance-aware-ray-tracing-for-curves/asset/abstract.pdf.
>> Brecht, do you have any thoughts on this or know of any other good papers?
>> As for further features, Dual scattering mentioned in the paper
>> http://www.cemyuksel.com/research/dualscattering/dualscattering.pdf would be
>> brilliant but this is a large feature to add.
>>
>> Stuart
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles