<div class="gmail_extra">On Thu, Nov 29, 2012 at 7:11 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2t7">Right. I think auto dicing to get a certain face size rather than<br>
subdivision level still has some use for displacement, but it can be<br>
done in a modifier too.</div></blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">cheers</div>