<div dir="ltr"><div>I&#39;ve waited up to 10 minutes for synchronization for a single model before, going from SubD level 1 in the viewport to SubD level 4 for rendering (3 million polys or so). Not sure where the optimizations are in the other packages, but rendering begins pretty much immediately for them. Not a negative criticism of Cycles by any means, I&#39;m just wondering where in the pre-render process optimizations could be made to increase interactivity.<br>
<br></div>Another question I&#39;ve had is if there are any plans to do some kind of cache to memory so that a scene doesn&#39;t need to be re-synced and rebuilt for each frame when f12 rendering if nothing has changed. In a turntable I did of a character not long ago, sync and BVH building accounted for nearly 50% of the total render time despite the camera being the only thing animated in the scene.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 7:13 PM, Brecht Van Lommel <span dir="ltr">&lt;<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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&#39;t that slow from what I&#39;ve analyzed, and<br>
I&#39;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&#39;s particularly slow without modifiers that would be<br>
interesting to investigate and see how it could be made faster.<br>
<br>
It doesn&#39;t have anything to do with how deeply Cycles is integrated<br>
really, just stuff that could be worked on.<br>
<div><div class="h5"><br>
On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich<br>
&lt;<a href="mailto:matt.heimlich@gmail.com">matt.heimlich@gmail.com</a>&gt; wrote:<br>
&gt; Hey all,<br>
&gt;<br>
&gt; I was thinking about the long sync step when rendering with Cycles and had a<br>
&gt; couple of questions. As far as I can tell, external renderers in other 3D<br>
&gt; packages done require this step. Is this because the other<br>
&gt; renderers/packages directly use the geometry data already in memory directly<br>
&gt; from the 3D package? If so, this makes me wonder if this step is a due to a<br>
&gt; limitation of Cycles not being as deeply integrated with Blender as it could<br>
&gt; be (if I recall it was originally intended to operate as a standalone that<br>
&gt; could work with other packages as well) or if there is a limitation with<br>
&gt; Blender itself in terms of the data it makes available to external programs.<br>
&gt;<br>
&gt; As I understand it, the process now is:<br>
&gt;<br>
&gt; Start rendering process -&gt;<br>
&gt; Copy geometry data from Blender to a Cycles buffer -&gt;<br>
&gt; Build BVH based on this data -&gt;<br>
&gt; Begin intersection tests<br>
&gt;<br>
&gt; With the geometry copy being a very time consuming step, especially for<br>
&gt; complex scenes. Please correct me if I&#39;m wrong anywhere. Just trying to<br>
&gt; continue wrapping my head around the inner workings of Cycles as a whole.<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Bf-cycles mailing list<br>
&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt; <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;<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></div>