Poser 11 Pro - SuperFly Separate Process render issue

  • Hi all,

    Poser Pro Mac OSX 10.13.6 High Sierra.

    Recently got back into 3d and ran some quick test renders to try to optimise my workflow.
    I noticed a big difference in render output with SuperFly between using the Separate Process option in prefs or not.

    Only noticed it on eyes and mouth so far so suspect transparency. Any ideas? Which do we think is correct looking?
    Is this an old bug that was fixed but only fixed for one of the two options (separate process on or off).


    Thanks in advance for any input...

  • I noticed this as well. I wanted to dispatch renders upstairs to my big-boss machine but couldn't. And I had gotten so used to rendering in LuxRender, where it was independent and I could just engage machines as needed. Also, superfly would trigger the "not optimized" warning on mojave macs. In fact, it triggered it on first render even local render. Same binary. Which is why I didn't understand the difference.

  • I think what is needed here is a little more info. What is your mat setup for the eye surface? I'm assuming this is V4? What are your render settings? what lighting are you using?

    I just did a test and could not get the separate process render to look any different. Using IDL only. The problem is I'm on a PC and am running an old version of PP11.

    ***=NSFW content***

    click to show

  • Same issue here with latest Poser 11.1, OS X 10.13.6. Happens with both CPU and GPU renders.

  • Yes it's V4, with mainly the Elite Amy texture and EZSkin3 script run on it. I'll have to check the eyes though as I might have changed them. Will check.

    As for lighting at one point, I was trying out EZDome but I deleted the dome and left the lights - so 3 lights, colour, IBL & Sun.

    Will do a few more tests and report back.

    Thanks for the input chaps :)

  • @ader42 IBL lights don't work in Superfly.

  • IBL lights do work but different. With SF they are like emissive background shader lights but do emit diffuse light only. Therefore they are only useful for some special cases.

  • Poser Ambassadors

    IBL is a "cheating" light just like AO is a "cheating" option.

    Both should have been dropped off a cliff when Poser8 came with IDL. => The "real thing".

    Now mix SuperFly ( a real PBR render engine) with a cheating option, and you get banana's that smell like oranges mixed with some concrete and flower power. => In other words, => The result is "unpredictable".

    Next Poser versions should concentrate on PBR render engines and drop all cheats completely. That way end users stay safe and can not get in trouble.

    Best regards; Tony

  • Yes maybe they better had dropped the IBL light in SF (the name is misleading anyway as it does something different). Those who need a light that behaves that way can creat it with an emissive and light-path node anyway.

  • Okay more info.

    With base V4, my poser default lights (8 area/spotlights) the Separate Process option makes no difference to the render in either FireFly of SuperFly.

    If I run EZSkin3 on the eyes only then with SuperFly I get this:


    So the issue is nothing to do with lighting. I would wager there's not any problem with EZSkin3 either, or the materials at all.
    After all, just checking "Separate Process" should not affect the render, should it?

    So to me, it looks like Mac users should avoid the Separate Process option. It would be interesting to find out if Windows users have the same issue.

  • @ader42 try my eye shaders with the separate process.
    0_1560703896649_Eye example 1.jpg

  • I didn’t use the "Separate Process" rendering in the past and out of curiosity i tried it with some older Poser versions, and Always got the same render issue. I used EZSkin3 eyes with custom cornea and eye surface shaders. Tested on OS X 10.13.6.

  • @ghostship I have those shaders and I love using them on V4. Is is possible for you to create one for LaFemme specifically? It's kind of a bear to go through her entire materials and try to match up your shaders to make her work. I've done it, but it's very time consuming for me, and I am sure there are others who are not familiar with the advanced tab in the materials room who could use it too.
    Thanks for the wonderful Superfly shaders you are creating and distributing.

  • @ghostship Wow, didn't know about these :) very cool, trying them is next on my to-do list ;) Your portrait lights look super useful too :D

  • @rokketman let me take a look.

  • @rokketman If I know Ghostship, he'll come up with something, because I've been able to use them with Dawn thanks to his help.

  • @ader42 They are super useful :D

  • @ader42 It seems the render issue is related to the Poser SSS node in combination with having close contact to a mesh. If i recall correctly there was such problem with SSS in the first version of Poser 11 in general.

  • @nagra_00_ Why would the external render trigger it? I mean, they use the same render engine either way, no? Or does Poser export (load content into) the render engine differently, depending on how the render engine is started. I always thought the render should always be external. With the render window just being an update of the external render process state. Starting another render would just add another to the queue. Then you could use any number of render nodes and it wouldn't matter to Poser. I long for LuxRender's cool trick of being able to change the lights while the render is happening. OMG, that's nice.

  • @thoennes I'm not aware of what material evaluation differences there might be between internal and external renderers, but the process of saving and loading a scene file is not guaranteed to produce the same results, due to Poser's penchant for rearranging the order of evaluation of deformers (all clustered before the morphs) and hidden joint parameters at leisure. Until they fix that, there's no assurance that an external render will be identical to an internal one. Ever! Since the scene file must be saved out before it can be read by the external renderer, whether local or remote.