[Bf-cycles] Cycles geometry synchronization

[Brecht Van Lommel]

I tested this a bit on OS X but didn't see anything like a 10 minute
export, instead something like 20s with about half in Blender doing
the subsurf modifier, half doing BVH build stuff, and just a small
percentage other overhead. I committed a small tweak to reduce the
other overhead but it's doesn't make any significant difference since
it's just a few percentages here.

It would be interesting to see a .blend file and to know which
platform you are seeing this behavior on.

On Sat, Jul 13, 2013 at 2:47 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> 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
>>