Superfly displacement map issue and curious solution

I pointed out that Poser Pro 11's displacement mapping was not working, but the story gets weirder. Look at the following Superfly comparison engine. You'll see that the PROCESSOR render handles displacement just fine, but the GPU version does not. I thought that there was supposed to be no functional difference between the end results of CPU and GPU rendering within Poser, but here's a clear example where that is not the case.

In fact, I wonder if it does not depend on the video driver.
I mean: on the left: the CPU version, on the right: the GPU version
I have used a sand texture from TerraDome2 on the default ground prop, removed the bump parameter, and pushed the displacement up to 1.0
We can see that the GPU version is somewhat more flat. I've read the the displacement depends on the geometry of the object (SubD level?)

Just thinking more about what you said here. So even model-level smoothing doesn't work in Superfly? So all those models that were built with the expectation that they would be smoothed now look bad under Superfly?

@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).

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.

@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.

@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.

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.

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.

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.