Yay!!! Fixed at last!!!! 

The displacement node bug when using the CyclesSurface root node has finally been fixed in Poser 13.895. This render shows the bug:  

It usually doesn't show up on plane surfaces, but when the surface has a more complicated geometry (such as a vascularity map on a human figure) the displacement varies across the surface and can even be inverted.  The same setup using version 13.895 is

The test object is the default primitive sphere.  The material setup is shown here:

It has taken a year for the fix to be implemented but better late than never, I guess.

Earlier in this thread (8 October) I noted that Superfly produces weird effects with Superfly producing "negative" displacements.  The discussion here has wandered away from this but the fact remains that Superfly does not appear to handle displacement correctly (this not only affects vascularity maps but any displacement maps.  I reported this to Poser support on 2 November (local time).  Today I got this reply from Nerd3D:

"Thanks for reporting this. I can't believe this but that's been broken since we initially implemented SuperFly over 7 years ago. There's supposed to be a Displacement node between the Image map and the displacement output on the Cycles root. It was never added. It's in the code but was never included in the UI. 

"This will be fixed in the next update of Poser." 

Yay!!!!

Where did all the people go?  Maybe if this forum stayed on topic instead of drifting off into Python and Poser arcana and it might have more followers.  I'm opting out.

I have used vascularity maps with the Firefly renderer for years without any problems.  About I year ago I switched to Superfly and started seeing the same weird effects that hborre described: veins that appear to recede from rather than stand out from the surface.  I lodged a support ticket but got a reply along the lines of "well, Superfly is different so what do you expect?"   I thought it might have been fixed with Poser 13 but it's still with us.  

Here's my two cents worth for the Poser brain trust to consider:

I used the standard Poser Surface root node with an old figure and maps, NOT the Cycles node. This makes it easier to compare Superfly and Firefly images. The displacement value has been set to1.25 mm and the subdivision level for the figure is set to 1. The first image shows the figure rendered using Firefly.

The vascularity is not overly prominent: it's most obvious in the groin area and on his elbow.  The next image is the same figure rendered using Superfly with exactly the same Poser root node. I used the Optix GPU render engine, but I get the same results using my computer's CPU, so it's not an NVIDIA thing.  

Woah!  First, the displacement is unrealistically large.  It certainly isn't 1.25 mm! (Raising the subdivision level doesn't seem to change anything).  The second thing is that some veins stand out while others recede.  The scene uses 2 infinite lights. Rotating the figure does seem to change where the receding veins are located, an effect that hborre has also mentioned. 

The final render is the same as the previous one but with the displacement set to 0.125 mm.  

The veins now look much more realistic, but there are still receding veins (especially in the figure's right arm).  

All this suggests to me that there is a problem in the way Superfly handles displacement.  The "receding" effect may be a fault in the way shadows are calculated, and the magnitude of the displacement is unphysical (a displacement of 0.125 mm should be essentially invisible).  

Displacement maps are also used for non-human figures and props (walls, etc.) so this problem has wider implications.  

Also, see the topic "Cycles based SSS skin shader."  You'll find a post from me (Tues 09 May 2023) showing how you can use legacy vascular/vein maps with a Cycles node.

Will there be a L'Homme 2?

it seems to be that Infinite light glitch in Poser13, sometimes it just turns off and you get a black render ! Often by moving the infinite light. It normally works again by moving the Light just a little and it turns back on. In some cases a really annoying issue. Also like in previous Poser versions the Spots keep on vanishing and you have a hard time locating these to move by hand even if you have em set a visible. So in Poser13 quiet some things seem not working stable concerning lights and the contrast change after a render, that can be awfully annoying.

so pretty much normal getting a black render in Poser13 with infinite light after they periodically crash ! just have to be getting used to it .... 

Thanks!  I deleted the infinite light and created a new one, and now background rendering works again!  I agree, the new version of Poser is still a bit wobbly.  It has some good features, though.

I should have added that I am using Poser 13.0.296.  

Also, the problem occurs when I use either the CPU or the GPU to render the image.

@oz_tangles Use a mix closure with one side going to your PBSDF and the other going to a transparency shader. This will be driven by your transparency map. The collision lines can be mitigated by using a different SSS group number on each PBSDF node (down near the bottom of the shader)

Thanks!  Again, I should have read the Poser Manual as it has a section on "Connecting the Nodes for the Transparent Materials."

As ghostship2 points out, you may need to subdivide the figure's mesh to improve the appearance of the vascularity.

On something completely different, male genitalia are usually an add-on to most figures.  When using the PBSDF node for a gens figure I found that there was an objectionable  seam between the genital figure and the hip of the parent figure.  The textures for male gens usually include a transparency map which blends the boundary so it matches the texture of the parent.  PBDSF doesn't have a transparency input, but it does have an alpha channel input, but connecting the trans map to the alpha channel didn't work.  RTFM!!  The Poser documentation states that you must use the Cycles image map, not the Poser image map!  This node can be found at Cycles>Texture>Image Texture.  When the transmap is opened in Image Texture node and connected to the alpha input, it works perfectly.

Thank you for your excellent tutorial on using the Cycles PBSDF shader!  I have been using SnarlyGribbly's EzSkin to convert "legacy" (i.e. ancient) textures to Superfly.  The results are OK but the PBSDF shader gives much better results.  
Something you haven't mentioned is vascular maps.  EzSkin ignores vascular maps when converting shader trees to Superfly, and trying to connect a vascular map to the displacement input of the Physical Surface Node doesn't produce very realistic results.  
Vascular or vein maps have been discussed elsewhere in the Renderosity Forums, but I want to show how they can be easily added to Ghostship2's Cycles shader tree.  
1. Open the vascular map in a standard image_map node, using a gamma of 1.0.  
2. Open a Cycles Mix shader (Cycles>Color>Mix) and connect the Color output of the image_map to Color1 on the Mix shader.  Set Color2 to BLACK.  
3. Blend Type should be set to Mix.
4. Connect the Color output of the Mix shader to Displacement on the root CyclesSurface node.  
5. The strength of the vascular effect is determined by the Fac parameter in the Mix node.  Fac = 0 corresponds to the maximum vascularity and Fac = 1 to no vascularity.  I have found that a value of 0.7 or 0.8 looks pretty good, but this is a matter of taste and the subject matter (eg pumped body builders).  

I've had the same problem, but it has only appeared in the last day or so.  

Poser does not handle the error gracefully.  As Nerd points out,  you need to exit Poser and start over again. 

-oz  

I think the problem may have been with the size and/or content of the Poser file. QM can handle a simple render, but it failed for a Poser render with a 60MB pz3 file and a 105MB pmd file.  The log entries are:

...adding new Queue entry id 1
Queue Procs now available: 0
Launching FFRender for parsing...
C:\Program Files\Poser Software\Poser 12\FFRender64.exe "C:\Program Files\Poser Software\Poser 12" "C:\Users\Public\Documents\#########\2022- 3-12_17h47m11s.pz3" "C:\Users\wtang\AppData\Local\Temp\Queue Manager\12" "2000" "1600"
... FFRender launched
Parser process is ready to talk
SetRequestedFrame OK
Parser assets are ready.  Updating qTask with filenames.

Then the error message appears.

Hi Y-Phil,

Not "both computers."  Poser & Queue Manager are on the same machine.  I simply wanted to a batch rendering of several scenes overnight.  I never had problems before.  And the disk drive has around 700 GB of free space.

oz