[Bf-cycles] 2.66 plans

[Brecht Van Lommel]

Hi Matt,

This is indeed a concern, I think any target audience likes minimal
memory usage. In my opinion this is something that would best be
tackled not only in the render engine but in Blender itself too.
There's things which would be nice to support in Blender:

* Blender library linking should not require other datablocks to
always be loaded into memory. So you would have a dupligroup object
with a group linked from another .blend file, and you could disable
loading that group in the viewport (or using a low resolution proxy).

* Alembic is similar, I don't know how it would be integrated exactly
in Blender, but an Alembic file is basically a 'baked dupligroup' and
you'd also want options to load that into memory on demand. The way to
create that Alembic file would be different, but from the render
engine point of view it's practically the same.

If Blender supports that kind of lazy loading of objects, then Cycles
doesn't really need to support Alembic or a scene file format to deal
with memory usage issues. It could loop over the scene and Blender
would load objects in/out of memory on demand. I imagine that's not so
simple to implement in Blender, but if you want a good workflow for
editing it would need to be implemented anyway.

Even if we only support Alembic dynamic loading instead of library
linking, the Alembic file loading can still be handled by Blender
without the render engine having to know too much about how it all
works.

Brecht.

On Thu, Nov 29, 2012 at 11:54 AM, Matt Ebb <matt at mke3.net> wrote:
> Please correct me if I'm wrong, but one problematic issue that both Blender
> Internal and Cycles have is that because the renderer is launched from
> within Blender, there needs to be two copies of the geometry in memory.
> Maybe this is less of an issue for subdivisions if blender can destroy the
> high res tessellated mesh after transferring to cycles, but it's still an
> issue. In film production this process is usually decoupled, with separate
> render farm jobs exporting scene description files such as RIBs vs
> renderer-only jobs which load those scene description files and any
> associated dynamic/procedural geometry (eg. alembic files and such), without
> the host 3d application, so there's no duplication of memory.
>
> While having an scene description file format for cycles would be cool for
> other reasons, perhaps a middle ground approach would be to have better
> support for geometry formats such as alembic in both blender and cycles, so
> that alembic geo can be represented in blender as a low res proxy and kept
> out of memory, but at render time loaded up by the renderer natively, in the
> renderer executable. Anyway, I'm not sure if this is a huge issue for cycles
> or cycles' target audience, but just putting it out there.