[Bf-cycles] Micropolygon Displacement in Cycles

Mai Lavelle mai.lavelle at gmail.com
Wed Apr 29 23:33:49 CEST 2015


Hi Ton, thank you for the reply.


Sorry for not going into detail. Getting this to work is unlikely to be
easy, theres a lot to consider...


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...


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...


Examples of memory usage for pretessellation with current BVH and mesh
storage:

 - default cube with dice rate of 0.001 takes ~7.5GB

 - for a quad that spans a 1920x1080 screen tessellated to one micropoly
per pixel the memory consumption is ~700MB


Screen adaptive tessellation btw would allow for a user configurable cache
size where memory could potentially be traded for speed and vice versa.


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.


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.


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.


Mai

On Sun, Apr 26, 2015 at 12:05 PM, Sergey Sharybin <sergey.vfx at gmail.com>
wrote:

> Hi,
>
> We actually had a brief discussion in IRC a while ago. To summarize:
>
> - There was a discussion in the list a while ago:
> http://lists.blender.org/pipermail/bf-cycles/2014-January/001744.html
> which basically concludes choosing approach for micropolygon displacement
> should be done with care
> - 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
> https://developer.blender.org/D1242
>
>
> On Sun, Apr 26, 2015 at 8:46 PM, Ton Roosendaal <ton at blender.org> wrote:
>
>> Hi Mai,
>>
>> Sorry for not getting any reaction sooner. People are busy I guess :
>> Could you be a bit more precise, and explain in more detail how you want
>> this to work?
>>
>> Or, show a paper or some images on a website.
>>
>> -Ton-
>>
>> --------------------------------------------------------
>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>
>>
>>
>> On 29 Mar, 2015, at 21:38, Mai wrote:
>>
>> > Hello,
>> >
>> > 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.
>> >
>> > Thank you,
>> > Mai Lavelle
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
> With best regards, Sergey Sharybin
>
> _______________________________________________
> 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/20150429/ccfd371a/attachment.htm 


More information about the Bf-cycles mailing list