[Bf-cycles] Micropolygon implementation

[Brecht Van Lommel]

My understanding is that they had to fit all geometry in memory
(except for hair which was handled differently). I think that's
because the ray differential / multiresolution geometry cache doesn't
work so well when you add more raytracing effects and the rays lose
coherence. I could be wrong though, but that's what I remember from
siggraph.

On Sat, Jan 4, 2014 at 1:57 AM, 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.
>
> --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
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>