[Bf-cycles] Cycles geometry synchronization

[Matthew Heimlich]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130712/96997f80/attachment.htm