[Bf-cycles] OpenSubdiv article

Brecht Van Lommel brechtvanlommel at pandora.be
Wed Sep 25 02:01:29 CEST 2013


I don't have any new insight into this really, just what I wrote in my
SIGGRAPH report.

Matthew, for the same mesh rendered in either engine the base mesh is
equally heavy of course. But depending on the render engine you may
use a particular workflow, to either work with high detailed meshes
that you barely subdivide or not subdivide at all, or relatively low
poly subd meshes with a base mesh.

For example the Pacific Rim robots are already very high poly by
themselves and may not even have any subdivision in rendering, or very
little anyway. Or characters may be heavily subdivide already before
rendering for physics simulation of muscles, wrinkles, etc. So when
they arrive in the render engine you can't do many optimizations that
take special advantage of them being subdivision surfaces, you just
need to handle high poly meshes efficiently.

But some of the Renderman methods seem to require low poly based
meshes, for example multiresolution shading cache, or they will at
least work suboptimal with high poly meshes. Or if you have a high
poly base mesh, ptex isn't as efficient anymore and texture filtering
quality suffers because it can't scale down textures below one face.

So if we use particular algorithms that means artists would have to
model in certain ways or do retopology to get best rendering,
sculpting or painting performance.

Brecht.


On Wed, Sep 25, 2013 at 1:04 AM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> The base meshes aren't any heavier in Arnold's approach as far as I
> know, they just have more polygons at render time because they do
> all-over subdivision rather than the selective division of Pixar's
> REYES approach. One isn't any "better" than the other, it's just that
> a monte carlo path tracer won't experience much of a performance hit
> when rendering more polygons, while REYES render times are much more
> dependent on polygon count. Arnold doesn't take the approach of fancy
> ways of finding the limit surface of an object because for them it
> doesn't matter if you have 100 million or 200 million polygons. Both,
> in essence, still use the same subdivided base mesh/displacement map
> method at their core though. You don't have to model in any special
> way for either one.
>
> On Tue, Sep 24, 2013 at 4:02 PM, Marco G <digitalbath86 at hotmail.com> wrote:
>> Yes indeed would be great if sorted out sooner or later and widely adopted
>> by "everyone"...thinking about this, the last Siggraph notes by Brecht,
>> the google projects going to be finished or developed further (mostly
>> depsgraph, viewport fx, multithreaded DG), and 2.7 series coming,
>> i was wondering what are developers thoughts about which workflow might be
>> pushed more for Blender in the near future.
>> the Pixar one with lower base mesh / OpenSubD / displacement with Ptex etc
>> or the "Arnold" one, with much more heavy base meshes...
>> ...any more recent thoughts?
>>
>> Thanks, MG.
>>
>>> Date: Tue, 24 Sep 2013 15:07:07 -0400
>>> From: matt.heimlich at gmail.com
>>> To: bf-cycles at blender.org
>>> Subject: Re: [Bf-cycles] OpenSubdiv article
>>
>>>
>>> Not the first time I've heard that Solid Angle's implementation is
>>> faster on the CPU. Hopefully that gets sorted out soon, as a standard
>>> would do the industry a world of good.
>>>
>>> On Tue, Sep 24, 2013 at 1:46 PM, Marco G <digitalbath86 at hotmail.com>
>>> wrote:
>>> > Hi all,
>>> >
>>> > sharing a nice article about OpenSubdiv on fxguide for those who missed
>>> > it.
>>> >
>>> > It does also mention why SPI nor SolidAngle is not yet implementing the
>>> > library, mostly because of bad optimization of the CPU code, something
>>> > Pixar
>>> > should address in 2014.
>>> >
>>> > Cheers all, MG - link
>>> > http://www.fxguide.com/featured/pixars-opensubdiv-v2-a-detailed-look/
>>> >
>>> > _______________________________________________
>>> > 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
>>
>> _______________________________________________
>> 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


More information about the Bf-cycles mailing list