<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 8:48 AM, Zauber Paracelsus <span dir="ltr"><<a href="mailto:zauber@gridmail.org" target="_blank">zauber@gridmail.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Okay, this post is about a performance oddity that I have noticed with<br>
hair rendering.<br>
<br>
What I am seeing deals with the Steps property, under the Render panel<br>
in hair properties. While tinkering with it I found that each 1 step<br>
reduction results in the render's memory usage being reduced by half,<br>
which makes sense given the description. As an added bonus, it reduces<br>
the build time for the render.<br>
<br>
However, on the flip side I have found that lower values seem to<br>
increase the final render time. Below is the rendering times, measured<br>
on one of the current builds off of buildbot (hash fda1198)<br>
<br>
GPU Render:<br>
3 Steps: 12.20s<br>
2 Steps: 12.90s<br>
1 Step: 16.81s<br>
0 Steps: 28.04s<br>
<br>
CPU Render:<br>
3 Steps: 23.60s<br>
2 Steps: 27.15s<br>
1 Step: 38.96s<br>
0 Steps: 80.24s<br>
<br>
Now, this isn't quite what I was expecting. If there's less<br>
geometry/data to process, then in theory shouldn't the render times be<br>
going down?<br>
<br>
Is this expected, or have I spotted a performance flaw or regression?<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div>