<p>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.</p>
<p>--Nathan</p>
<div class="gmail_quote">On Dec 30, 2013 11:43 AM, "Brecht Van Lommel" <<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm well aware of micropolygon rendering and it is great for<br>
displacement, but it's problematic for global illumination and path<br>
tracing (note the paper only shows direct light). The industry trend<br>
seems to be to move away from it and towards path tracing, due to more<br>
interactive previews and simpler lighting workflow. As I understand it<br>
even Pixar didn't rely on it that much anymore for Monsters University<br>
in the sense that they had all geometry in memory for raytracing<br>
rather than generating it on the fly and discarding as in REYES.<br>
<br>
However, we can make our displacement workflow much better, I just<br>
don't think that REYES/micropolygons is what we should focus on.<br>
There's ideas that we can use and distinctions get fuzzy because<br>
modern production renderers aren't purely one or the other, but it's<br>
definitely been a conscious decision on my part to approach this from<br>
the path tracing side.<br>
<br>
You can read e.g. these articles to get an idea about the trends in rendering:<br>
<a href="http://www.fxguide.com/featured/the-state-of-rendering/" target="_blank">http://www.fxguide.com/featured/the-state-of-rendering/</a><br>
<a href="http://www.fxguide.com/featured/the-state-of-rendering-part-2/" target="_blank">http://www.fxguide.com/featured/the-state-of-rendering-part-2/</a><br>
<br>
On Mon, Dec 30, 2013 at 7:07 PM, <a href="mailto:x3108@chello.at">x3108@chello.at</a> <<a href="mailto:x3108@chello.at">x3108@chello.at</a>> wrote:<br>
> Hello,<br>
><br>
> maybe you know, but what if this slipped trough your fingers…<br>
><br>
> i stumbled some years ago over the renderants papers and its reyes micropolygon GPU implementation.<br>
> <a href="http://www.gaps-zju.org/project/renderants.html" target="_blank">http://www.gaps-zju.org/project/renderants.html</a><br>
><br>
> Now as i understood the papers and some code is official ?<br>
> Would be the actual cycles code be feasible for such an implementation or needs it a too complex overhaul ?<br>
><br>
> Look at the GREAT displacement images (ohhh.. :-D):<br>
> <a href="http://www.gaps-zju.org/project/renderants.html" target="_blank">http://www.gaps-zju.org/project/renderants.html</a><br>
><br>
> Imagine the displacement speed. I mean micropolygons would be definitely a way to go for the cycles roadmap ? ;-)<br>
><br>
> 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!<br>
><br>
> HAPPY NEW YEAR !!!<br>
><br>
> enilnacs<br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</blockquote></div>