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

[Nathan Vegdahl]

Regarding hair pruning:
I wonder if some kind of russian-roulette in the BVH traversal could
work...?  And maybe scaling the alpha based on the number of
near-nodes skipped.  Not sure if that would be too noticeable an
approximation, or how it would affect noise, but just an idea.

--Nathan


On Fri, Jan 4, 2013 at 12:17 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> 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