Forum: Poser 12


Subject: Subdivision in Superfly

ChromeStar opened this issue on Nov 24, 2021 ยท 6 posts


ChromeStar posted Wed, 24 November 2021 at 3:11 PM

I think this image speaks for itself regarding microdisplacement and different shader roots. Using a different root doesn't change the issue, to get fine scale displacement you need a lot of polys. Which means either a detailed object or a lot of subdivision. (In this case I used the Ball primitive which is pretty low detail, simply for the sake of a clear example.)

Here are the shaders, which I kept as simple as possible (with a single infinite light so that it would be the same on each object). PoserSurface:


PhysicalSurface:

Cycles:


Note I've plugged the displacement info (a Marble node in this case, but could be anything) into a cycles Math node. Varying Value2 will increase or decrease the amount of displacement, so that's an easy way to make it adjustable. The amount isn't exactly the same as the PoserSurface and PhysicalSurface in this case but I think I have it pretty close.


hborre posted Wed, 24 November 2021 at 3:33 PM

What is your unit of scale?  Poser units?  Feet?  Inches?  Millimeters?  This is important information if someone wants to duplicate your results.


ChromeStar posted Wed, 24 November 2021 at 3:40 PM

I have Feet selected.

I changed the units to Centimeters and re-rendered; the image is the same but Poser has changed the Displacement value for PhysicalSurface and PoserSurface to 1.82. Interestingly, the multiplier for Cycles has not changed (because there's nothing displacement-specific about the math node), but the amount of displacement in the image hasn't changed. That says that displacement on the Cycles node is scale invariant, unlike on the other nodes.


hborre posted Wed, 24 November 2021 at 6:02 PM

Yes, that is correct, 0.06 feet is 1.82 centimeters.  That Is to be expected.


primorge posted Wed, 24 November 2021 at 10:18 PM

Of note; black is 0 displacement in Poser. Unless there's a difference between the renderers for this now, if you're using middle grey maps that depend on 127 127 127 rgb (or 128 if you like) as zero height they need to be run through math subtract 1/0.5... various artifacts are an issue otherwise. Old BB advice that seemed to need constant mentioning.



ChromeStar posted Wed, 24 November 2021 at 11:46 PM

And subtracting that way does work with the Cycles displacement node. I think generally you would want to subtract first, then multiply. My examples were intended as the simplest possible, not the best. :)