[Bf-cycles] Cycles geometry synchronization

[Matthew Heimlich]

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/20130714/4ed3ae48/attachment.htm