[Bf-cycles] Cycles geometry synchronization

[Matthew Heimlich]

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.


On Sun, Jul 14, 2013 at 3:48 PM, Matthew Heimlich
<matt.heimlich at gmail.com>wrote:

> 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.
>
>
> On Sun, Jul 14, 2013 at 8:58 AM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>
>> 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
>> >>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130715/93cd835e/attachment.htm