[Bf-cycles] Micropolygon Displacement in Cycles

Stefan Werner swerner at smithmicro.com
Mon Jul 20 12:10:59 CEST 2015

On 6/26/15, 3:58 AM, "bf-cycles-bounces at blender.org on behalf of Nathan Vegdahl" <bf-cycles-bounces at blender.org on behalf of cessen at cessen.com> wrote:

>I guess that's my main concern as far as caching goes: Cycles is
>designed for both CPU and GPU, and IMO it makes sense to implement
>things in a way that will eventually allow for a good GPU
>implementation as well.  It would be a shame if displacements were
>permanently a CPU-only feature.  Then again, maybe geometry caching
>wouldn't be as unfriendly to GPU's as I'm imagining--I'm far from
>expert in that space.  It just seems like it would invite cache
>thrashing, though, among other things.

While it is desirable to share as much code between GPU and CPU as possible, I wouldn’t make that a top priority. There may be cases where two separate implementations, optimized for each architecture, are better than a weak“runs everywhere” compromise.

Displacements may just be such a case. If you look at what the CPU and GPU vendors demonstrate, Intel’s Embree implements on-demand adaptive tessellation and a cache, the OptiX SDK instead uses direct intersection method (I believe similar to http://www.cs.utah.edu/~bes/papers/height/tech.html ). I think both code examples are worth a read.

If displacements become a CPU-only feature, that would not be a first anyway. OSL support at this point is also a CPU exclusive feature.

>> 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?
>I think there are a few things that can be done here:
>1. Given a primitive like a triangle, you know what its subdivided
>topology is going to be if you subdivide it uniformly, so you don't
>need to store additional connectivity information, you can just store
>the vertices in a known order.  That's certainly not a huge space
>saver, but it helps some.

There’s more than that that can be saved. Per-vertex attributes, such as UVs, vertex colors, etc can be calculated on the fly instead of stored in memory, normals may be a bit more costly due to a sqrt. Likewise, per triangle attributes such as visibility flags, shader ID do also not be duplicated.

>2. Adaptive tessellation based on what the camera projection is going
>to be.  This is pretty straight-forward, and in many cases with models
>that are already highly tessellated you might not even end up having
>to do any additional tessellation.

That would not only be useful for displacements, but could also help rendering pixel-precise subdivision surfaces.

>3. Adaptive tessellation based on displacement shape: e.g.
>tessellating more finely in areas where the displacement has high
>curvature.  This one is not so trivial, but I think it can likely be
>done well for many common displacement patterns.

Again, this would apply for subdivision surfaces. OpenSubdiv is implementing that, if I remember correctly.


More information about the Bf-cycles mailing list