<div dir="ltr"><div>I'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'm just wondering where in the pre-render process optimizations could be made to increase interactivity.<br>
<br></div>Another question I've had is if there are any plans to do some kind of cache to memory so that a scene doesn'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"><<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">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>
<div><div class="h5"><br>
On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich<br>
<<a href="mailto:matt.heimlich@gmail.com">matt.heimlich@gmail.com</a>> wrote:<br>
> Hey all,<br>
><br>
> I was thinking about the long sync step when rendering with Cycles and had a<br>
> couple of questions. As far as I can tell, external renderers in other 3D<br>
> packages done require this step. Is this because the other<br>
> renderers/packages directly use the geometry data already in memory directly<br>
> from the 3D package? If so, this makes me wonder if this step is a due to a<br>
> limitation of Cycles not being as deeply integrated with Blender as it could<br>
> be (if I recall it was originally intended to operate as a standalone 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 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 whole.<br>
><br>
</div></div>> _______________________________________________<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>
><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>