Superfly displacement map issue and curious solution

  • Micro displacement, and a few other things that are in Firefly were considered experimental in Cycles until about 3 days ago with the release of Blender 2.78.

    Basically all of us got used to having something in Firefly that wasn't supported in Cycles Final until last Friday.
    2.78 has added other things that are not in Firefly as well.

  • @shvrdavid Ok, fair enough, but Poser does not simply have the Cycles engine - it was building upon a rendering architecture that already existed. It's not as though displacement mapping is strange voodoo feature that the world cannot fathom! :-)

    The Superfly engine already integrates with Poser's native rendering solutions, so a poor implementation of a vital feature like displacement, which has been fundamental since what, version 5, 6, seems like a crazy price to pay. Superfly truly feels like two steps forwards 1 step back.

    So is it SM's intent to try to keep up with new feature implementation in Cycles? I suppose that might be a characteristic worth suffering SOME inconvenience for (although I find the lack of previews utterly intolerable).

    What new Cycles features can we expect to see in Poser?

  • As far as displacement in Cycles/Superfly, you can not implement what isn't there. A render engine either supports it, or it doesn't.

    I do not know what the development plans are as far as adding the new features, or if they have even been added to the opensource version. Its only been a few days since it went final, and that could change if anything comes up that needs corrected.

    Sometimes it takes a while for things to get added. To make it even more confusing, there are a lot of branch builds that usually happen first.

  • @matb said in Superfly displacement map issue and curious solution:

    @shvrdavid Unfortunately it's a cycles material so it doesn't render at all in firefly. And the firefly rendering engine is still terminally, unusably slow.

    I've had slowdowns with Firefly, but it's not a permanent problem for me. When I detect that Firefly is rendering slow (I usually run it in Background mode via D3D's script) I will stop the render, save the work, exit Poser and restart it. After that, I never seem to have slowdown issues, even after working with various assets across the libraries. (One of the sources of the memory leak reportedly fixed, but I think it is still hanging around in some cases, hard to narrow down.)

    I don't know why this is. However, I routinely clean out my caches/temps using CC cleaner once a week. I've noticed some odd instances where Poser appears to react negatively after I've done that, even after a normal nightly shutdown and boot the next day. I'm wondering if its a cache issue for Firefly and something, somewhere, isn't getting the space/memory it needs or is too busy trying to reload things. After a cold start, and a shutdown/restart of the program, Poser and Firefly, in general, seems to "find their space" and behaves as they should.

    On micropolygons and CPU/GPU difference - I'm wondering if it's an issue with pixels... Micropolygons are what are used to render "displacement" in engines like Firefly. They are mathematically derived eensy-weensy polys that aren't physically present in the mesh, but are "physically present" in the rendering process of the mesh. (Poser can not "physically" sub-d any object down to "micropolygon" scales.) Because they're capable of being smaller than 1 pixel in resolution, maybe the GPU processor is designed to "throw them away" since, because of its intended purpose, all they would normally do is bog down calculations for visual real-time rendering? The CPU, not being designed as a pixel-centric visual aid, doesn't care if they're smaller than a pixel.

    TLDR - Maybe the GPU is simply normally hard-wired to scrap anything interpreted as being a rendered effect that is smaller than one pixel in resolution, even if it's supposedly only doing "maths."

  • @shvrdavid I appreciate that you cannot render what is not there, but Superfly is already a hybrid engine that renders Poser-unique elements not in the Blender version of Cycles. It does not seem unreasonable that it should also integrates Poser's displacement technology.

    To make it even more confusing, there are a lot of branch builds that usually happen first.

    What's a branch build?

  • @morkonan I find Poser 11's implementation of Firefly rendering completely unusable. It truly is shameful that Smith Micro has not resolved this issue yet. You're not the first person to suggest that this is a progressive issue that gets worse the longer the program is running. But even on a fresh load, P11's Firefly render is WAY slower than Pro 2014's.

    Your thoughts on micropolygons are most interesting. Do you mind if I ask where you learned about Poser's inability to handle micropolygons in sub d? If this is indeed the explanation, it's a vital piece of knowledge that I would have liked to receive before spending £800 on a graphics card specifically for Poser, when I was deliberating between a graphics card or processor.

    I wonder if SM can program a solution that refers back to the CPU for displacement information.

  • @matb

    Poser 11 Pro's Firefly way slower than Poser Pro 2014'?
    Sorry: no.
    Furthermore, Poser 11 most of the time handles the memory far better than Poser 2014. During a series of tests, Poser 2014 was almost constantly requiring items from the hard disk, whereas Poser 11 was smarter.

  • Poser Ambassadors

    Micropoly displacement on a subD mesh works fine in Firefly, which as I understand it is a Reyes raytracer. SubD works fine in Superfly as well but not micropoly displacement which is apparently very hard to do in pathtracing render engines (which is what Superfly/Cycles is) - if it was easy, it would have been done by now. It is a limitation that was talked about some time ago so the devs are certainly aware that it's a feature that a lot of users would like to see.

    Both engines are very different and have their own advantages and disadvantages. Poser is now well served with rendering options, the two built-in engines plus bridges to Lux via Reality and Octane Render via face_off’s plugin. Lots of options.

  • @Y-Phil said in Superfly displacement map issue and curious solution:


    Poser 11 Pro's Firefly way slower than Poser Pro 2014'?
    Sorry: no.

    Test renders today. Identical scene - no shadows

    Poser 2014 Pro
    1st render 22.09s
    2nd render 19.72s
    3rd render 22s

    Same scene in Poser 11 identical scene and settings
    1st render 49.41s
    2nd render 46.12s
    3rd render 36.69s
    4th render 104.81s (wtf?!!!)
    5th render 47.53

    Same scene Poser 2014 with shadows, sss and indirect illumination
    1st render 147s
    2nd render 149s

    Same scene Poser Pro 11 with shadows, sss and indirect illumination
    1st render 180.04s
    2nd render 214.00s

    I was already conducting these tests to try to track down if there was indeed a memory leak as others had suggested, or if Poser 11 is simply slower. I did repeated tests which should show progressive deterioration if a memory leak was the problem. There was one bizarre anomalous reading on the 4th re-render of the same scene in P11, and possibly that could be down to hard disk spooling, although it was unnecessary as the scene only contained two figures and a piece of furniture, and it's running in 16GB of RAM. There no other programs running.
    Moreover, Poser 2014's rendering times were consistent and within the margin of error for my stop watch operation, whereas Poser 11's times, whether rendering with all lighting set on, or with everything off, varied drastically from render to render.

    Clearly, Poser 11 Pro IS significantly slower Phil in spite of what you may have heard. Moreover, it is less consistent in its Firefly rendering performance.

  • @matb Do you have render in separate process checked?

  • @matb

    My way of using Poser has nothing special. Even though I'm doing some post-processing, I'm by no way a specialist.
    My pictures are rendered using one pass.
    Here are the settings I've used with a scene built with Poser Pro 2014:


    The scene is 1736w by 938h, has one infinite light and two posts.
    Here is the result:


    Both version needed a little less than 11 minutes to render this.
    I've rendered 2x with Poser Prop 2014, than twice with Poser 11 Pro, then once with Poser Pro 2014, just to be sure that there's no side effect with the hard disk
    The only noticeable difference is that Poser 2014 Pro seems to need more frequent disk accesses.

  • @ghostship said in Superfly displacement map issue and curious solution:

    @matb Do you have render in separate process checked?

    No I don't - indeed, I believe it was you in another thread who specifically advised me not to do so if I recall correctly.

  • @Y-Phil Well first off, I must congratulate you on the scene - that lighting is excellent. Is that a single point light in the lamp, a soft overhead spotlight fill and an IBL?
    As for your performance, the difference between your results and mine are hard to explain. I have been benchmarking Poser 11 since the first release, and seeing similar result differences so I don't imagine it's a patch update difference. As firefly is not using the GPU that won't be a factor either.
    How much memory are you running? Which processor/s. I notice no hard drive access with either version on my test scene.

  • @matb Ok, Now I'm starting to sound like a broken record! LOL

    Have you tried rendering larger scenes that took as long to render as Phil's. Maybe it's inaccurate to test render speeds when the render only takes a minute or two.

  • @matb

    The two spots I'm using are posed this way:


    I'm using one infinite light to fill the room.
    I never use IBL: the walls are slightly reflective, and Poser's IDL is enough to set the ambiance.

    My PC is built around a i4740K, 16Gb, and a 6Gb/s hard disk (for Poser's runtimes) connected to one of the 6GB/s connectors of the motherboard. and an ssd for the OS itself.
    It has been running for two days, and as it was the end of the work time for me, I had a virtualbox running an Ubuntu, half a dozen of programs opened at the same time. Among them: Chrome, a resources eater, with at least 10 tabs opened.

    During the render, the quantity of used RAM climbed up to ~85%.

  • @ghostship said in Superfly displacement map issue and curious solution:

    @matb Ok, Now I'm starting to sound like a broken record! LOL

    Not at all - I'm only too happy to hear your thoughts on this issue!

    Have you tried rendering larger scenes that took as long to render as Phil's. Maybe it's inaccurate to test render speeds when the render only takes a minute or two.

    I have in the past, but I'll do so this afternoon to record some accurate numbers.

  • @Y-Phil Why do you never use IBL? Also perhaps it's the multitasking that is causing the disk access?

  • @matb

    The multi-tasking? not sure: there has been less disk access using Poser 11 Pro.
    That being said, most of my scenes are either in a closed environment (room, house) or outside, but using Bagginsbill's Envsphere.
    In either cases, the IBL won't reach my character.
    You will find Bagginsbill's explanations here.

  • @Y-Phil Very useful Phil, thanks for the link.

  • @matb
    You're welcome alt text