<div dir="ltr">Just built a few minutes ago and tried out the file again. The sync is more or less unnoticeable. Not sure where/when the issue was, but it doesn't seem to be happening anymore.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Jul 14, 2013 at 3:48 PM, Matthew Heimlich <span dir="ltr"><<a href="mailto:matt.heimlich@gmail.com" target="_blank">matt.heimlich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Let me see if I can find the test file I was using. The tests were a little over a month or so ago I would estimate, and were using a self-built version on Windows 7 64-bit, not MinGW.<br></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Jul 14, 2013 at 8:58 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tested this a bit on OS X but didn't see anything like a 10 minute<br>
export, instead something like 20s with about half in Blender doing<br>
the subsurf modifier, half doing BVH build stuff, and just a small<br>
percentage other overhead. I committed a small tweak to reduce the<br>
other overhead but it's doesn't make any significant difference since<br>
it's just a few percentages here.<br>
<br>
It would be interesting to see a .blend file and to know which<br>
platform you are seeing this behavior on.<br>
<br>
On Sat, Jul 13, 2013 at 2:47 AM, Brecht Van Lommel<br>
<div><div><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>> wrote:<br>
> A scene with 3 million polygons should never take 10 minutes, that<br>
> sounds like a bug. Some sort of cache would be useful but at the<br>
> moment is somewhat difficult to implement, we don't have a way to<br>
> track what changes between renders. But the first thing to do is<br>
> really to optimize export if there are cases where it takes this long,<br>
> that's not normal.<br>
><br>
> On Sat, Jul 13, 2013 at 1:35 AM, Matthew Heimlich<br>
> <<a href="mailto:matt.heimlich@gmail.com" target="_blank">matt.heimlich@gmail.com</a>> wrote:<br>
>> I've waited up to 10 minutes for synchronization for a single model before,<br>
>> going from SubD level 1 in the viewport to SubD level 4 for rendering (3<br>
>> million polys or so). Not sure where the optimizations are in the other<br>
>> packages, but rendering begins pretty much immediately for them. Not a<br>
>> negative criticism of Cycles by any means, I'm just wondering where in the<br>
>> pre-render process optimizations could be made to increase interactivity.<br>
>><br>
>> Another question I've had is if there are any plans to do some kind of cache<br>
>> to memory so that a scene doesn't need to be re-synced and rebuilt for each<br>
>> frame when f12 rendering if nothing has changed. In a turntable I did of a<br>
>> character not long ago, sync and BVH building accounted for nearly 50% of<br>
>> the total render time despite the camera being the only thing animated in<br>
>> the scene.<br>
>><br>
>><br>
>> On Fri, Jul 12, 2013 at 7:13 PM, Brecht Van Lommel<br>
>> <<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>> wrote:<br>
>>><br>
>>> Most of the time is usually evaluating modifiers, particularly for<br>
>>> subdivision surfaces or particles. Once Blender has evaluated those<br>
>>> things the copying itself isn't that slow from what I've analyzed, and<br>
>>> I'm sure other render engines have similar steps, just under a<br>
>>> different name?<br>
>>><br>
>>> What we could optimize here is doing multithreaded sync(this relies on<br>
>>> the multithreaded depsgraph project), or doing our own subdivision in<br>
>>> Cycles. If it's particularly slow without modifiers that would be<br>
>>> interesting to investigate and see how it could be made faster.<br>
>>><br>
>>> It doesn't have anything to do with how deeply Cycles is integrated<br>
>>> really, just stuff that could be worked on.<br>
>>><br>
>>> On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich<br>
>>> <<a href="mailto:matt.heimlich@gmail.com" target="_blank">matt.heimlich@gmail.com</a>> wrote:<br>
>>> > Hey all,<br>
>>> ><br>
>>> > I was thinking about the long sync step when rendering with Cycles and<br>
>>> > had a<br>
>>> > couple of questions. As far as I can tell, external renderers in other<br>
>>> > 3D<br>
>>> > packages done require this step. Is this because the other<br>
>>> > renderers/packages directly use the geometry data already in memory<br>
>>> > directly<br>
>>> > from the 3D package? If so, this makes me wonder if this step is a due<br>
>>> > to a<br>
>>> > limitation of Cycles not being as deeply integrated with Blender as it<br>
>>> > could<br>
>>> > be (if I recall it was originally intended to operate as a standalone<br>
>>> > that<br>
>>> > could work with other packages as well) or if there is a limitation with<br>
>>> > Blender itself in terms of the data it makes available to external<br>
>>> > programs.<br>
>>> ><br>
>>> > As I understand it, the process now is:<br>
>>> ><br>
>>> > Start rendering process -><br>
>>> > Copy geometry data from Blender to a Cycles buffer -><br>
>>> > Build BVH based on this data -><br>
>>> > Begin intersection tests<br>
>>> ><br>
>>> > With the geometry copy being a very time consuming step, especially for<br>
>>> > complex scenes. Please correct me if I'm wrong anywhere. Just trying to<br>
>>> > continue wrapping my head around the inner workings of Cycles as a<br>
>>> > whole.<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Bf-cycles mailing list<br>
>>> > <a href="mailto:Bf-cycles@blender.org" target="_blank">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>
>>> ><br>
>>> _______________________________________________<br>
>>> Bf-cycles mailing list<br>
>>> <a href="mailto:Bf-cycles@blender.org" target="_blank">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>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Bf-cycles mailing list<br>
>> <a href="mailto:Bf-cycles@blender.org" target="_blank">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>
>><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>