2.5D Displacement

Is it real to make displacement in Cycles like in octane or corona render for less memory usage?
There are a lot of cases I can do in Octane with displacement, and can’t do the same with Cycles, because - out of memory. But I like Cycles, i want to do all in it.

Is 2.5d displacement for cycles in development? In plans? Is it real for cycles?


i have the same question, it seems octane can render displacement without modify the real geometry, but Cycles need very density subdivision to have acceptable result.
what’s the technical difference?


https://youtu.be/DTqcPEhSHB8 - looks here is a same way, as in octane. Can it be done in Blender?


Very impressive. :open_mouth: Surely there are drawbacks (or are there?) in any case the presentation doesn’t touch on it. The paper can be read here.

Not only the final quality but memory footprint too.

So, it seems from skimming through the paper that

  1. Displaced meshes are not watertight, although this is not considered unsolvable. From what I seem to understand, discontinuities only appear at UV seams and whenever the displacement map is rather coarse, so it’s invisible most of the time.
  2. edit : apparently I was wrong on that second point, see Brecht’s reply below
    The technique is incompatible with GPU acceleration, because it doesn’t tesselate and build a BVH beforehand, which is what GPUs expect to be fed. Instead it creates a “displaced-BVH” on-the-fly for each ray. This sounds like kind of a dealbreaker…

A future extension would be to extend modern hardware to directly support displacement mapping

doesn’t seem absurd to me but then again what do I know

1 Like

Seems like some researchers at Adobe found a way to make displacement more efficient. Wonder how complicated it would be to implement…

Edit: apologies, didn’t notice this was linked before.


Moderation note: merged @Claus his thread into the already existing topic on this subject.

1 Like

Wow …
that is awesome!

Pushing poly count for good details is not that much of an issue for a still image project. But it scales animation render time.

It is nice to see that Appleseed’s lead developer is part of the researcher team.

We clearly need a tessellation-free displacement. My computer isn’t fine with a 10M polygones ground :’).
Hopefully we could get it soon !

I think the main downside of this method is the performance, which from the papers seems to be about 20-50x slower than pre-tessellated meshes after preprocessing is done. Still would be great to have as an option.


Which metric are we talking about?

So it would be compatible with GPU acceleration after all ? have I read this wrong ? or would it be considered as a CPU-only method ? I’m thinking if it’s limited to CPU and it’s 50 times slower, well, wow, that seems like a pretty steep price to pay for lower memory footprint

For the metric, check Mr/s in Table 3.

The numbers in the paper are from an implementation that runs on the GPU. It’s just that even with that, it’s still relatively slow and would benefit from fixed function hardware support.