[Bf-cycles] Micropolygon implementation

[Nathan Vegdahl]

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.

--Nathan
On Dec 30, 2013 11:43 AM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>
wrote:

> I'm well aware of micropolygon rendering and it is great for
> displacement, but it's problematic for global illumination and path
> tracing (note the paper only shows direct light). The industry trend
> seems to be to move away from it and towards path tracing, due to more
> interactive previews and simpler lighting workflow. As I understand it
> even Pixar didn't rely on it that much anymore for Monsters University
> in the sense that they had all geometry in memory for raytracing
> rather than generating it on the fly and discarding as in REYES.
>
> However, we can make our displacement workflow much better, I just
> don't think that REYES/micropolygons is what we should focus on.
> There's ideas that we can use and distinctions get fuzzy because
> modern production renderers aren't purely one or the other, but it's
> definitely been a conscious decision on my part to approach this from
> the path tracing side.
>
> You can read e.g. these articles to get an idea about the trends in
> rendering:
> http://www.fxguide.com/featured/the-state-of-rendering/
> http://www.fxguide.com/featured/the-state-of-rendering-part-2/
>
> On Mon, Dec 30, 2013 at 7:07 PM, x3108 at chello.at <x3108 at chello.at> wrote:
> > Hello,
> >
> > maybe you know, but what if this slipped trough your fingers…
> >
> > i stumbled some years ago over the renderants papers and its reyes
> micropolygon GPU implementation.
> > http://www.gaps-zju.org/project/renderants.html
> >
> > Now as i understood the papers and some code is official ?
> > Would be the actual cycles code be feasible for such an implementation
> or needs it a too complex overhaul ?
> >
> > Look at the GREAT displacement images (ohhh.. :-D):
> > http://www.gaps-zju.org/project/renderants.html
> >
> > Imagine the displacement speed. I mean micropolygons would be definitely
> a way to go for the cycles roadmap ? ;-)
> >
> > This would make Cycles definitely THE displacement solution on GPU, and
> in terms of speed would beat Reyes stuff like PRman and 3Delight hands down!
> >
> > HAPPY NEW YEAR !!!
> >
> > enilnacs
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140103/be9181c3/attachment.htm