primorge posted at 5:22 PM Thu, 6 October 2022 - #4445996

hborre posted at 4:54 PM Thu, 6 October 2022 - #4445993

If you are using the PhysicalSurface node, you have access to displacement.  But you need a significant resolution for it to work correctly.  Don't even bother with Cycles ATM, it's trickier to get the right values for displacement.

@ADP, I peeked into that MC6 file and I see no reference to the PrincipledBsdf node anywhere in the coding.  It looks like it's missing nodes.

I played around with the physical surface with displacement in the past, the values were tricky there also. It did seem to work but not quite like it does in Firefly. Seemed to require more subdivision than expected IIRC... I'll play around with it some more, does seem a shame to hinge certain details on displacement and have that not work in both renderers optimally. Subdivision morphs out of Zbrush can be unpredictable, can cause you to waste some work.

Thanks for commenting hborre. Also saw your comments on it in the other forum, I'll fuss around with it a bit more seriously when the time comes.

You cannot implement the way displacement is implemented in Firefly (micro-polygons) in Cycles. The Blender programmers have done something along these lines, but in a very different way. A displacement map brings different results in the two render engines. This simply cannot be avoided (and never will). It doesn't really matter, because Firefly will certainly die away more or less quickly. Or completely slip into a niche.

Nevertheless, the way displacement is implemented in new Cycles versions is the better one. Since the geometry is divided where it is necessary. Namely in the close range. Everything further away remains untouched (a kind of subdivision on demand).

In Poser's Superfly a relatively old Cycles implementation works. We Poser users have to live with that :)
Rule of thumb: Where Highres morphs work, a displacement map works the same way (like a morph, displacement shifts the geometry towards normal).

---