<div dir="ltr"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Hi Nathan,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Thank you for your reply.</span></p><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 7:59 PM, Nathan Vegdahl <span dir="ltr"><<a href="mailto:cessen@cessen.com" target="_blank">cessen@cessen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p>Hi Mai,<br>
I have some experience with displacement mapping in a ray tracer due to my work on Psychopath. So perhaps I can lend some insight.</p></blockquote><div><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Psychopath is pretty interesting, love reading blogs like yours. Your insight is much appreciated :D</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>There are a few problems with the geometry cache approach. The first is that it works very poorly with multi-threading. With multi-threading you either have to have a lock of some kind protecting the cache from data races, or you have to have a separate cache per thread. Neither of these options scale well to very many cores (and certainly not the GPU!).</p></blockquote><div><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">There are variations on an LRU cache that work better with multi-threading which I'd like to try. Also, I think most users of cycles will probably have a high enough memory-to-thread ratio to make per-thread cache feasible. Better scalability and GPU will probably need some architectural changes, but most systems using CPU should be fine without them.</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>The second problem is that it has a very steep performance cliff when the cache starts thrashing, which isn't as unlikely as you might think. Dicing rates based on ray differentials helps with that (as per the Pixar paper), but it's not a silver bullet, especially since even diffuse ray differentials often need to be narrow to capture certain shadowing effects properly (this was something I didn't expect when implementing adaptive dicing in Psychopath).</p></blockquote><div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">This was disappointing to me. After reading your email and having a closer look at the math I did some experiments with mipmapping to see the impact differentials would have. If the differentials are too wide there is a blurring effect on indirect light (PDF of BSDF doesn't match PDF of sampled region, thus over/under valuing leading to blur). I don't think however that this blurring will be objectionable in all cases, and see no reason why some sort of quality setting can’t be added for this. There are also other things to try. I’d like to investigate having a maximum trace depth for displaced geometry which would help with cache thrashing.</span></p></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>The third is that large dynamic displacements wreak havoc with BVH quality, to the point that rendering slows to a crawl. The problem is that if you don't have the already-displaced geometry up front when building the BVH, then you have to add padding to the geometry bounding boxes to account for the displacement. That's fine if the displacement is small compared to the base geometry, but if it's large compared to the base geometry then it makes all of the triangles' bounds significantly overlap with each other.</p></blockquote><div><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Large displacements are indeed a problem. Even REYES renderers suffer from this. I think this can only be addressed by informing artists of the problem with careful documentation.</span> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>None of these problems are insurmountable, I think. But I suspect the solutions involve large architectural shifts, and may require compromises in other areas.</p>
<p>In the end, I think pre-tessellation probably makes the most sense for Cycles. It can be done adaptively, with tunable parameters. It has drawbacks, sure. But it's a proven technique in other production renderers, and I think it fits best with Cycles' design.</p><span><font color="#888888">
<p>--Nathan</p></font></span></blockquote><div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I still feel like it would be worthwhile to at least investigate the screen adaptive approach further. It has been used successfully in production environments and the differentials it uses are also useful for texture caching. It definitely has problems, but I think if it can be gotten to work it has some nice benefits.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">As for pre-tessellation, my biggest concern is memory usage. I don’t see an easy way to keep it down while also having pixel sized detail—although I may be overestimating the problem. Maybe there is some compression technique that could be used? The best I can think of is to reduce the dice rate by the distance from camera, but there are situations where this wont work so well. Pre-tessellation is far simpler to implement and I already have some of it done, so I will finish it up first and see how it does. You mention tunable parameters... could you be more specific? Maybe you have thought of something I haven't?</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Best regards,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Mai</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><br></span></p> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<div class="gmail_quote">On Apr 29, 2015 2:33 PM, "Mai Lavelle" <<a href="mailto:mai.lavelle@gmail.com" target="_blank">mai.lavelle@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Hi Ton, thank you for the reply.</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Sorry for not going into detail. Getting this to work is unlikely to be easy, theres a lot to consider...</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">The ideal would be to have screen adaptive tessellation, where artists set a size in pixels for micropolygons. The renderer would then use ray differentials to calculate needed tessellation rate to match that size as best as possible with respect to visual impact on screen/reflections/refractions/etc. Some sort of cache would be used to store tessellated geometry. Would likely start off limited to CPU, do to trickiness of needing a dynamic cache. There are other techniques for screen adaptive tessellation but I don't think that they would perform as well. Screen adaptive tessellation would probably be the most desired by artists for its ease of use and the high level of detail it can provide, but its also the most difficult to implement. Details of this method can get quite involved...</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">A much simpler approach is to pretessellate all geometry and send the entire tessellated mesh to the kernel. Major problem with this is it requires an enormous amount of memory to achieve detail. Bump mapping in addition to displacement helps a bit, but artifacts appear in the silhouette and tangent vectors which causes weirdness in specular highlights. Possible way to mitigate memory issues with pretessellation is to use frustum adaptive tessellation, but this probably isn't that useful do to shadows and reflections of objects outside of the frustum having under-tessellated silhouettes. It could be problematic for animation as well do to possibility of popping as objects cross the frustum boundary. Instances also pose a challenge here. In any case it might be a good idea to have a memory limit for pretess since its difficult to predict, but this could lead to other usability problems... </span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Examples of memory usage for pretessellation with current BVH and mesh storage:</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"> - default cube with dice rate of 0.001 takes ~7.5GB</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"> - for a quad that spans a 1920x1080 screen tessellated to one micropoly per pixel the memory consumption is ~700MB</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Screen adaptive tessellation btw would allow for a user configurable cache size where memory could potentially be traded for speed and vice versa.</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">I mention pretessellation mostly for its simplicity. Even tho it has big issues with memory it might still be useful for lower detail? Would be nice to hear thoughts on which approach would be better. Thoughts about having both methods available for use, or if there are other usable techniques would also be great. </span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Regardless of method chosen for tessellation there are some things that need work in general for displacement to be useful; the Diagsplit implementation needs some improvement, and texture coordinates pose a problem. Artists will likely need both texture coords generated form the base mesh and the displaced mesh for some shading techniques. One idea is to add a “Displaced” check box to the texture coord node, but I’m not sure if other nodes would need similar consideration or if theres a better way to approach the problem.</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">If needed I could write a more detailed proposal. I would very much like to help make this happen, and look forward to your response.</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.94px">Mai</span></p></span><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 12:05 PM, Sergey Sharybin <span dir="ltr"><<a href="mailto:sergey.vfx@gmail.com" target="_blank">sergey.vfx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>We actually had a brief discussion in IRC a while ago. To summarize:</div><div><br></div><div>- There was a discussion in the list a while ago: <a href="http://lists.blender.org/pipermail/bf-cycles/2014-January/001744.html" target="_blank">http://lists.blender.org/pipermail/bf-cycles/2014-January/001744.html</a> which basically concludes choosing approach for micropolygon displacement should be done with care</div><div>- There's a patch from Main in the tracker which optimizes memory storage for subdivided meshes which i'll try to review in next few days <a href="https://developer.blender.org/D1242" target="_blank">https://developer.blender.org/D1242</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 8:46 PM, Ton Roosendaal <span dir="ltr"><<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mai,<br>
<br>
Sorry for not getting any reaction sooner. People are busy I guess :<br>
Could you be a bit more precise, and explain in more detail how you want this to work?<br>
<br>
Or, show a paper or some images on a website.<br>
<br>
-Ton-<br>
<br>
--------------------------------------------------------<br>
Ton Roosendaal - <a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a> - <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
Chairman Blender Foundation - Producer Blender Institute<br>
Entrepotdok 57A - 1018AD Amsterdam - The Netherlands<br>
<div><div><br>
<br>
<br>
On 29 Mar, 2015, at 21:38, Mai wrote:<br>
<br>
> Hello,<br>
><br>
> I had a nice conversation earlier in irc with Marco G, who suggested I ask here. I'm very interested in helping out with getting micropolygon displacement working in Cycles. What are the current plans for this and what could I do to help? I've been poking around a bit at the code but don't want to get too involved without asking about it first.<br>
><br>
> Thank you,<br>
> Mai Lavelle<br>
</div></div>> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org" target="_blank">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>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">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><span><font color="#888888"><br>
</font></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</font></span></div>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">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></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">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></blockquote></div>
</div></div><br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div></div>