[Bf-cycles] Micropolygon Displacement in Cycles

Tue May 5 01:59:17 CEST 2015

Hi Mai,
I have some experience with displacement mapping in a ray tracer due to my
work on Psychopath.  So perhaps I can lend some insight.

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

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

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.

None of these problems are insurmountable, I think.  But I suspect the
solutions involve large architectural shifts, and may require compromises
in other areas.

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.

--Nathan
On Apr 29, 2015 2:33 PM, "Mai Lavelle" <mai.lavelle at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20150504/abf3374a/attachment.htm 