[Bf-cycles] Cycles geometry synchronization

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Jul 13 02:47:40 CEST 2013

A scene with 3 million polygons should never take 10 minutes, that
sounds like a bug. Some sort of cache would be useful but at the
moment is somewhat difficult to implement, we don't have a way to
track what changes between renders. But the first thing to do is
really to optimize export if there are cases where it takes this long,
that's not normal.

On Sat, Jul 13, 2013 at 1:35 AM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> 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.
> 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.
> On Fri, Jul 12, 2013 at 7:13 PM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
>> Most of the time is usually evaluating modifiers, particularly for
>> subdivision surfaces or particles. Once Blender has evaluated those
>> things the copying itself isn't that slow from what I've analyzed, and
>> I'm sure other render engines have similar steps, just under a
>> different name?
>> What we could optimize here is doing multithreaded sync(this relies on
>> the multithreaded depsgraph project), or doing our own subdivision in
>> Cycles. If it's particularly slow without modifiers that would be
>> interesting to investigate and see how it could be made faster.
>> It doesn't have anything to do with how deeply Cycles is integrated
>> really, just stuff that could be worked on.
>> On Sat, Jul 13, 2013 at 12:50 AM, Matthew Heimlich
>> <matt.heimlich at gmail.com> wrote:
>> > Hey all,
>> >
>> > I was thinking about the long sync step when rendering with Cycles and
>> > had a
>> > couple of questions. As far as I can tell, external renderers in other
>> > 3D
>> > packages done require this step. Is this because the other
>> > renderers/packages directly use the geometry data already in memory
>> > directly
>> > from the 3D package? If so, this makes me wonder if this step is a due
>> > to a
>> > limitation of Cycles not being as deeply integrated with Blender as it
>> > could
>> > be (if I recall it was originally intended to operate as a standalone
>> > that
>> > could work with other packages as well) or if there is a limitation with
>> > Blender itself in terms of the data it makes available to external
>> > programs.
>> >
>> > As I understand it, the process now is:
>> >
>> > Start rendering process ->
>> > Copy geometry data from Blender to a Cycles buffer ->
>> > Build BVH based on this data ->
>> > Begin intersection tests
>> >
>> > With the geometry copy being a very time consuming step, especially for
>> > complex scenes. Please correct me if I'm wrong anywhere. Just trying to
>> > continue wrapping my head around the inner workings of Cycles as a
>> > whole.
>> >
>> > _______________________________________________
>> > Bf-cycles mailing list
>> > Bf-cycles at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>> >
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list