<div dir="ltr"><span><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">Hi Ton, thank you for the reply.</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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&#39;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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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&#39;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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"> - 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.9400005340576px"> - 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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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.9400005340576px"><br></span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:17.9400005340576px">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">&lt;<a href="mailto:sergey.vfx@gmail.com" target="_blank">sergey.vfx@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;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&#39;s a patch from Main in the tracker which optimizes memory storage for subdivided meshes which i&#39;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">&lt;<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;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>
&gt; Hello,<br>
&gt;<br>
&gt; I had a nice conversation earlier in irc with Marco G, who suggested I ask here. I&#39;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&#39;ve been poking around a bit at the code but don&#39;t want to get too involved without asking about it first.<br>
&gt;<br>
&gt; Thank you,<br>
&gt; Mai Lavelle<br>
</div></div>&gt; _______________________________________________<br>
&gt; Bf-cycles mailing list<br>
&gt; <a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
&gt; <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>