I think when it comes to volume rendering, it can only be done usefully if you provide several different integrators. Having a slow, unbiased and straight forward volume path tracer is fine, MLT and bidirectional optimizations too. But artists would also need simpler more efficient ways to render common effects, like a standard volume ray caster, similar to the one in BI (+ radiance caching, adaptive ray sampling, optimizations for homogeneous media,... ). Imho for cycles someone should focus on providing a good base and infrastructure to integrate several rendering techniques.<br>
<br><div class="gmail_quote">On 29 November 2012 11:54, Matt Ebb <span dir="ltr"><<a href="mailto:matt@mke3.net" target="_blank">matt@mke3.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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>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><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>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br>