[Bf-cycles] Micropolygon implementation

[Nathan Vegdahl]

> It's also ridiculously slow, so in practice you get nothing at all, hence
> the full pathtracing mode coming in prman 19.

Fair enough.  In my tests with Psychopath
(https://github.com/cessen/psychopath), it performs about 3-5x slower
than Cycles for the same input scene.  Which is indeed a large and
prohibitive slowdown for many scenes, especially in a
production/animation context.

I do think, however, that saying you get "nothing at all" is a bit
hyperbolic.  A micro-geometry approach allows you to render scenes
that would otherwise not fit into ram due to geometric detail.  It
also eliminates a lot of fiddly tessellation parameters.

--Nathan


On Fri, Jan 3, 2014 at 9:26 PM, Matt Ebb <matt at mke3.net> wrote:
> On 4 January 2014 11:57, Nathan Vegdahl <cessen at cessen.com> wrote:
>>
>> Regarding Monsters 2: I'm probably being needlessly pedantic here, but
>> isn't RenderMan's raytracing still based on on-the-fly tesselation into
>> micropolygon grids (using a geometry cache iirc)?  Maybe that doesn't
>> technically count as micropolygon rendering, but I still think of it as
>> being strongly related.  It's sort of best-of-both-worlds: you get proper
>> higher-order surfaces and displacements, and you also get ray traced global
>> illumination.
>
> It's also ridiculously slow, so in practice you get nothing at all, hence
> the full pathtracing mode coming in prman 19. For many (most?) types of
> production scenes these days a modern raytracer beats the pants off
> renderman's GI, and the set of those scenes is growing, not shrinking as
> time goes by.
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>