Not sure I'm using it correctly yet but  appreciating the adaptive option in the render engine. Normally set low clamp levels to avoid long render times but now use much higher levels - first time I've got the HDRI reflected in the eyes. Thanks devs :)

If these are PBR materials another approach is to ignore the PoserSurface settings and build direct from the file names, I'm only familar with the metal-roughness approach but there tends to be a convention where the files are name  <texture>_diffuse.jpg, <texture>_normal.jpg , <texture>_roughness.jpg  etc. Provided the python script can determine what material zone  the "<texture>" bit applies to it can build the physical node directly - you're already grabbing the diffuse name from the mtl file so maybe that is a starting point. If you can provided an example of the texture file naming scheme and how the PoserSurface node looks after the import I'll check to see how it compares with the script I use.

Mybe tajking the discussiion outsude of thread, just get tired of Superfly being presented as a mistake, its just a tool and what we make of it is down to expectatiion.

Not my decision but are not both good?

FIrefly vs Supefly = why are we arguing

I would just like a objective discustion on if Superfy was good or bad. My own option is it works ok but I#m not a pro.

Its not a criticism, just saying that peope that decide to work with poser are not backward or behind the times, just part of their work flow.

Not aboout the renders, its more a general complaint about the assertion Superfly was a mistake, I've used many render engines and they all have problems :) I'm jusr saying we need to work with the constraints . Not sure if that makes sense.

If superfly is bad why are bad why are they include in site promos? I know this post will be ignore because it doesn't conform to the idea that Pose is bad

Superfly renders - these are not as good as a pro artist but what is missing?

I believe IOR in PBR is only indirectly changable via the setting the value of the specular channel (F0 calc) and it does not support refraction.

Could caustics be an issue here, I know there is a button to tick but does it do anything.

Edit: Cross post with parkdalegardener

Looking at the monster image - Interesting thought if P11 devs had gone down the Renderman route instead of Cycles, maybe we could claim fair use for education purposes.

From a workflow view point the standardised node layout of the physical root node does allow a certain amount of integration/automation. For example the ability to integrate with Substance painter allows for rapid prototyping and exporting of textures - instance a base texture across muiltiple mat zones, apply light baking and weathering on top of that instance and then bake. Using instancing its possible to create a number of texture sets that look quite different but are just a few clicks different, The flaw in this argument is the lack of automation between substance painter and Poser, there was a Cycles proposal back in 2015 on how to integrate PBR with a principle node and the mat file associated with its OBJ file but that doesn't appear to have been picked up. I suggested a simpliar approach with Poser 12 enhancements, don't think that was picked up either. Not trying to sell Substance Painter but for anyone who likes texturing but not the material room it is an option to consider and it doesn't need to be photo realistic there was a tutorial on this site for using SP with toon like textures (light baking).

The following are generated using SP and the physical root node as examples

@Boni - Apologies for the misplaced comment, i was following this thread in one tab and going through the gallery in another, must have switched tabs somehow.

Very enjoyable, excellent tour of your work.