[Bf-cycles] Hair Rendering and Steps?

[Sergey Sharybin]

Hi,

I assume you're using curve/line segments for the hair. In this case you're
most likely experiencing the way how BVH currently works for hair.

We're currently using the same AABB (axis0anigled bounding box) BVH for
hair, which means if you've got long strand in the dense particle system
you're in the big trouble. This is because each strand's AABB will
intersect loads of other strands AABB making intersection check really
inefficient.

Increasing Steps in this case makes it so more memory is consumed, but
because AABB for each segment becomes smaller, there's less intersections
with other AABB which makes intersection check much faster.

Now, i'm not sure from hand if our BVH Split supports curves, but it
totally worth trying to enable it and see what happens. If it's not
implemented we should consider implementing splits for curve strands as
well (i'm not totally sure why wouldn't they be supported thought). Or
maybe we'll need to look into some improvements in BVH Split.

But the biggest thing we need t do is to use OBB (oriented bounding box)
for hair. That's a bit tricky but pretty much doable.

I'm not sure it's a regression. If previous releases renders the same scene
faster it'll be a regression and in this case i'd like to have file which
demonstrates it.

On Thu, Feb 19, 2015 at 8:48 AM, Zauber Paracelsus <zauber at gridmail.org>
wrote:

> Okay, this post is about a performance oddity that I have noticed with
> hair rendering.
>
> What I am seeing deals with the Steps property, under the Render panel
> in hair properties.  While tinkering with it I found that each 1 step
> reduction results in the render's memory usage being reduced by half,
> which makes sense given the description.  As an added bonus, it reduces
> the build time for the render.
>
> However, on the flip side I have found that lower values seem to
> increase the final render time.  Below is the rendering times, measured
> on one of the current builds off of buildbot (hash fda1198)
>
> GPU Render:
> 3 Steps: 12.20s
> 2 Steps: 12.90s
> 1 Step:  16.81s
> 0 Steps: 28.04s
>
> CPU Render:
> 3 Steps: 23.60s
> 2 Steps: 27.15s
> 1 Step:  38.96s
> 0 Steps: 80.24s
>
> Now, this isn't quite what I was expecting.  If there's less
> geometry/data to process, then in theory shouldn't the render times be
> going down?
>
> Is this expected, or have I spotted a performance flaw or regression?
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150219/3bab583c/attachment.htm