Hi folks
I did some research and testing today to see how far Cycles offers now displacement similar to REYES but it seems you still need to heavily subdivide the mesh before rendering.
I have a basic plastic chair and subdividing it kills Blender.
Any advice
Cycles can do adaptive subdivision if you enable it. Only under the Experimental feature set though. You’d have to read up on it to learn more as it’s something I’ve never looked into. The relevant settings are somewhat scattered around
Yeah the mesh still has to be subdivided manually or via subdivision modifier.
That unfortunately does not work well compared to REYES (Renderman) which does the tessellation (polygon smaller than a screen pixel).
You can do that too, setting dicing size to value smaller than one pixel.
It seems that render time works much better than viewport where Blender locks up for me each time.
And micropoly rendering is improved in 2.8 due to things like proper UV subdivision (no more distortions), and off-camera scaling (large memory savings). Displacement is also a vector now so you can displace in more directions than just on the normal.
The major thing still missing is a displacement cache (which would allow limitless subdivision without using tons of RAM).
That works because REYES is a rasterizer. Raytracers have to either pre-subdivide the mesh, or loosely bound the triangles and subdivide during intersection (this has a rather horrific performance cost, you don’t want to do this if you can avoid it). Mantra (houdini) does have a little trick where it pre-subdivides one mesh at a time during render startup to find the proper displaced bounds, then uses that to subdivide on intersections. Helps the performance to not be quite as bad, but you do still need to load the full mesh once to get the bounds.
RIS has amazing subdivision performance too though.
I get some odd render results with Vector displacement
and this is my node setup
The vector displacement is interesting because it shows no seam tearing apart along the cube’s vertical edges.
That’s very interesting and strange. I think that’s worth reporting as a bug.
That is because Vector displacement maps typically do not look like normal maps at all.
This is what a displacement map of a human ear looks like (from the Arnold docs.).
Now you could work over the normal map with nodes to create something that would work with multi-directional displacement, but your mileage may vary.
Ah so the vector displacement node does not work with a normal map?
You could theoretically process the normal map through a node setup so that it can produce a result that is better than using a bumpmap alone.
In apps. like Mudbox, Zbrush, and Arnold though, you’re only guaranteed a good and expected result if you use a specialized map as I posted above (which Blender can’t bake to right now).
the reason why I look into displacement right now is to explore surface structures for furniture design which will be rotor molded so undercuts are not really possible resulting into simple height displacement being the most logical choice anyway.
with that said I am happy to see how well actually the displacement works now. pretty amazing.
However working on a cube I hit 5 GB of ram even before getting the resolution as close as the reference rendering.
Normal maps store a surface angle, vector displacement maps store a surface transformation. It’s easy to think of v.disp as being the displacement equivalent of a normal map, but that isn’t the case at all.
I blame oversimplified explanations of bump/normal mapping as displacement of a fake surface. That’s not how they work. Normal maps describe surface angle, bump maps approximate surface angle from differences in a height map.
Disable autosmoothing
Hi Ninja
Yeah the terms can be very confusing. Sadly blenders doc also does not explain differences between different image types and how they would work with the nodes.
