The Octane “Texture Displacement” is using a voxel grid, and appears to be an old algorithm. I tried looking for some description of it, but the only thing I could find was a paragraph in their Cinema 4D documentation.
They had it for years, and it is not what is described in the paper you linked.
Ah, right he did mention voxels. Forgot about that.
Err…
Hey guys I found this paper!
Any news when we are gonna be able to bake displacement from selected to active using Cycles?
This is another issue with Cycles that should have been solved a long time ago.
Brecht just committed patch for UDIM baking:
https://developer.blender.org/rB6787cc13d4efef19eb708e1912356f8c1d4d2e01
Sadly some vague mentions of the terms voxels and voxelgrid is all we got. It was the first displacement implementation in Octane before they got vertex displacement. Since it’s older I thought maybe this is a known algorithm and one of the devs knows what it’s doing.
That looks cool too!
If it’s 20-50x worse performance as I understand what Brecht says, is it even worth it? I get the feeling that running out of VRAM and using the system RAM might still literally be as fast, or faster? I’d really like to see someone do actual tests on out-of-core rendering performance, the wiki’s “still faster than CPU” is pretty broad…
Here’s quick comparison between Octane’s Texture Displacement and Cycles’ Adaptive Tesselation. I rendered each test with displacement turned on and off and calculated the memory difference (measured with GPU-Z). The displacement map is 2048x2048 and all meshes are direct copys and not instanced. The sampling and lightbounces are matched.
OCTANE:
Rendertime: 52s
Displacement Memory consumption: 53 MB
Octanes Texture Displacement seems to only consume memory for loading the texture map. If you put the displacement shader on other meshes it doesn’t allocate more. Even if you use it for the whole scene on arbitrary and non-instanced geometry. Need to test this more.
CYCLES:
Rendertime: 46s
Displacement Memory consumption: 7368 MB
For Cycles displacement I used a dicing rate of 1px and Offscreen Scale: 50. Since adaptive tesselation is screen spaced, the displacement would flicker if you moved the camera or the meshes. But there’s always the option of adding a static dicing camera to lock the micropolygons in place. It’s definetly a good implementation (and way better than Octane’s second method Vertex Displacement), but for complex scenes the GPU memory would kinda very heavily explode. That’s the reason why I thought something along the lines of Octane’s Texture Displacement would be a good fit for Cycles.
That’s a bummer. There’s always one catch on most of this papers. But the quality is amazing.
Interesting. Much more detail in the Octane version.
And the amount of displacement seen in many spots is different, it appears clear to me that the color values are being read differently in the Octane version. Which colorspace type did you use, because Cycles does not exactly require you to set the data as non-color for displacement to work?
Good catch, I had the Cycles texture still on sRGB! 
No wonder why I could not match it exactly. Also Octane seems to interpret Midpoint and Displacement Height a little bit different. But I was able to match it pretty closely.
CYCLES:
Rendertime: 47s
Displacement Memory consumption: 6830 MB
But my main point is the memory consumption on GPU. Cycles displacement quality would be even better than Octane if I set the dicing rate to 0.5. But RAM consumption would be excessive 
.
Somehow I like the light transport of Cycles a little bit better, but this could be differences in the Sun & Sky model and tonemapping.
One of which is using microdisplacement on “source objects” (source assets typically placed near origo) is completely useless right now. If the source asset is placed far away from the camera being rendered out, it seems like it’s the evaluated tesselation on the origo object that is being rendered near the camera.
the one thing which we would really need is an option to reduce the texture resolution per object and not only globally (an object simplefy tab).
after this is already possible to do in the render setting, I guess it‘s a pretty low hanging fruit to add this feature also per object or per material.
this would really help to optimize the vram usage.
the current is global option of this feature is pretty useless, after it reduces also the resolution of forground objects which you want to keep sharp or the HDRI.
That’s why the feature is still experimental, and many issues remain to be fixed and improved:
And keep in mind this old problem (not sure if this has already been fixed in recent versions)
Yes, it doesn’t work with instances. I can understand that though, instances are instances, they have to share their data and I assume that includes the diced mesh
That’s great news. I know cycles can render geometry motion blur based on velocity attributes from alembic. But i couldn’t make it work, not with alembic nor with geometry nodes. Is there some specific workflow?
I haven’t found the time to experiment with it, so I wouldn’t know the right workflow, sorry.
Does other renderers suffer the same problem? What would be a workaround to make the asset work as an actual asset? This kinda messes with how I was planning to go about doing large scenes of office venues.
Yes, you can’t adaptive subdivide instances, it doesn’t make sense. The whole idea of instancing is that you have one mesh instantiated with multiple different transforms. In Redshift for example, it simply turns off subd entirely if you try and enable adaptive on an object with multiple instances. Some renderers might have a somewhat smarter fallback where they automatically switch to non-adaptive subd. This can result in a very different mesh than what the user is expecting though.
