[Bf-cycles] 2.66 plans

[Aurel W.]

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.

On 29 November 2012 11:54, Matt Ebb <matt at mke3.net> wrote:

> On Thu, Nov 29, 2012 at 7:11 PM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>
>> Right. I think auto dicing to get a certain face size rather than
>> subdivision level still has some use for displacement, but it can be
>> done in a modifier too.
>>
>
> 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.
>
> cheers
>
> _______________________________________________
> 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/20121129/b369d2de/attachment.htm