Superfly displacement map issue and curious solution



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

    @matb

    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:

    Settings

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

    Ael

    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:

    Spots

    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


  • Poser Ambassadors

    Wow - I completely forgot about the one-sided polygon IDL phenomenon in that thread. I also forgot what a jerk I was.

    Anway - I wonder if FireFly still does that weird stuff with one-sided polygons.



  • @Y-Phil have you tried TrekkieGrrrl's room prop for P11? Works great for bouncing light around.

    https://www.renderosity.com/mod/freestuff/render-room-for-poser-ect-/76449



  • @ghostship

    I didn't know about this room. It's now part of my runtimes, with other items from TrekkieGrrrl.
    Till now, I was using a few bought objects that I had bought at the time of Poser 6 & 7, with which I can build rooms.
    This one will come in handy... Thanks



  • @matb said in [Superfly displacement map issue and curious solution].. But even on a fresh load, P11's Firefly render is WAY slower than Pro 2014's.

    That is not my experience. In fact, I found a 15% speed improvement in a few test renders I did between P11 and P9. (I don't have 2014/P10/whatever) Admittedly, I wasn't specifically testing for speed across a range of render types, it was just an anecdotal observation. (I posted about it in a thread around here, somewhere.)

    I have noticed a slowdown/issue/leak/something from time to time, but it is difficult to pin down and it does not occur with every session. (I haven't had render slowdowns in a long time, but I do tend to restart the program, now and then, since I recover that processing power for when I'm working on other parts of a project. (3D creation/morphs/high-res texturing, etc.)

    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?

    I didn't say Poser couldn't handle micropolygons in Sub-D. Firefly is a Reyes renderer, specifically designed to handle micropolygons. However, Cycles could not handle micropolygons (It can now, I guess, according to some recent reports?). Sub-D and Micropolygons aren't the same thing, so when some people are saying that they are sub-d'ing the mesh in order to get the Superfly engine to deform it according to a displacement map, I'm wondering how that's being treated by the Superfly engine and am assuming that it's only applying the "displacement" to physically existing geometry and that's how it normally handles displacement (Which is a very inefficient method to use, since there's a huge waste of geometry and it may as well be modeled instead.) In the example, since I don't know anything about the Cycles engine, I'm wondering why there appears to be evidence of micropolygon dispacement, according to the poster. And/or, for that matter, why displacement would differ between processors. My suggestion is a wild-ass guess :) just based on the concept of reducing needless overhead in GPUs by preventing pixels that are not visible from being rendered. Micropolygons are smaller than a pixel, but it's their aggregate result that is eventually rendered in renderers that can use them, like Firefly.

    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.

    I have no answers, just a bunch of ignorant babble. :) There are a bunch of experienced pros out there that could probably give an accurate opinion or, at least, one that was accurate enough to base a decision on.

    What I will say is that if you plan on using the Superfly engine a lot, or exclusively, then you'd get a lot of mileage out of a new, GPU Compatible, vidcard. However, you would get much much more total mileage out of an upgraded CPU. Rendering may be slightly faster with your GPU-enabled Superfly render, but you may find a satisfactory render time with a shiny new CPU that can also be used to render, run other programs, etc.



  • @morkonan In fairness, P9's implementation of Firefly was significantly enhanced from 9 through 10 to 11 Pro so that's not really a fair comparison.

    I'm wondering how that's being treated by the Superfly engine and am assuming that it's only applying the "displacement" to physically existing geometry and that's how it normally handles displacement (Which is a very inefficient method to use, since there's a huge waste of geometry and it may as well be modeled instead

    I'm a little confused by this statement. It seems to me that one uses displacement for three reasons: so that one does not have to waste the TIME modelling detailed geometry, so that one does not have to expend the memory on high poly models, and because it may be impractical to model all of the detailed perturbations of an organic surface (a rock or a dinosaur's skin for instance). Efficiency doesn't appear to enter into that equation at all. However, I assume that you are talking about use of memory resources? If that's the case, surely subdividing small parts of a model on an ad hoc basis for Superfly displacement, though clunky, is far more efficient than creating an entire model at super high resolution, then carefully crafting all that detail?

    What I will say is that if you plan on using the Superfly engine a lot, or exclusively, then you'd get a lot of mileage out of a new, GPU Compatible, vidcard. However, you would get much much more total mileage out of an upgraded CPU.

    Well I use displacement ALL the time, and as this seems not to work at all in Superfly using GPU acceleration, in retrospect, I would have done far better with the CPU, which is what you also conclude.



  • @ghostship CONCLUSION TO RENDERING TIMES ISSUE
    I took your advice and rendered the scene below with everything turned on. Here are the results:

    0_1475754777795_zanshin.jpg

    Poser Pro 11
    1st render 18m 45s
    2nd render 16m 30s

    Poser Pro 2014
    1st render 18m 27s
    2nd render 19m 14s

    Comparing that to the earlier fast render results with all features turned off, where Poser 2014 was 200-300% faster, we can conclude that either Poser Pro 11 is less efficent at loading initial scene resources, or Poser Pro 2014 is better at rendering vanilla scenes with no shadows, SSS or IDL.

    0_1475754842943_test render no lighting.jpg
    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

    Once all of these are added, increasing render times dramatically, Poser Pro 11 was STILL slower, and where Poser Pro 2014 got FASTER with subsequent renders, Poser Pro 11 got SLOWER, possibly confirming morkonan's suggestion of a memory leak.

    Regardless, however you look at it, my assertion that Poser Pro 11 is a slower at rendering using the Firefly engine than Poser Pro 11 has been borne out by actual testing and quantifiable results. Poser 11 Pro WAS fractionally faster at a high quality render the first time through, but then performance slumped on the second rener of the same scene. Moreover, because the largest penalty is paid during the rendering that you will do the most of, (low quality preview renders), the PERCEPTION of slowness is greatly magnified.

    My test machine: Intel i5 2500k at 3.30ghz, 16GB RAM, Raptor drive for caching, Titan X graphics card



  • @matb Good test. I would also suspect a memory leak due to the increased time but also the weird randomness of your render times. I get weird random crashes with Poser 11 Pro that I never got with any previous version of Poser so I do suspect some funny business is going on.



  • Just out of curiosity I did some playing around with low quality renders to see if I got similar results. and sometime I do, sometimes I don't.

    I thought that was a bit odd, and thought about it for a while.

    There is a reason for this, and it has nothing to do with the program as far as I can tell.
    I'm not saying that in some cases it doesn't, just that the result I see have more to do with hardware than anything.

    On my Haswell I7, I have core parking off, and PL1 time to set to 1.
    The results are very similar in time, varying by a few seconds when rendering.
    Yes there is an occasional difference, but I have tons of stuff running at once.
    On average my I7 system has 7 gig cached to disk (SATA 6gig ssd)

    alt text

    alt text

    I did basically the same thing on an I3, the only thing you can change on an I3 is core parking.

    I get similar results, and times vary wildly. I can't tweak an I3, its locked down better than Fort Knox.

    There are drastic differences between the 2 systems I tested. One being that the video in the CPU is only used as passthru on the I7, and is used on the I3. Both systems use SSD's etc. The I3 is stuck at SATA 3gig

    The I3 gets very warm, and I start getting large render times on small scenes. The I7 will do it too, after repeated renders because it is overclocked.

    What does this mean to me?
    It means that heat, core parking, and the PL1 timings have more to do with it than anything for me.
    So much so, the other render engines give similar results as well.
    Mantra does it, so does Cycles in Blender, So does Superfly CPU in Poser.

    Results are going to very on different machines, that is just how it works.
    There going to vary on the same system as well, since Firefly is not a path tracer.
    Yet even the path tracers vary, suggesting that hardware has more to do with it than anything.

    Results on bottle necked machines, are going to vary even further.
    My I3 system is massively bottle necked due to having a GTX1070 in it, I ghtz mem, SSD's etc. (First design I3)
    An I5 with a titan is no different in that regard, and is massively bottle necked as well.

    So I tried it on 2 systems, one gets similar results that vary greatly, the other, not so much.
    There is very little that is quantifiable in my results, other than it varies massively with hardware.

    When I set my workstation back up, I will try it on that as well.
    The only bottle necks in that system are the processors, and, well, there Xeons. And the PCIe2 bus versus having PCIe3.

    I have no idea what SM or most of the testers use system wise, other than it probably varies greatly.

    Which also explains why the people here see differences as well.
    The difference may come down to hardware more often than not.

    There could be a problem as well, not saying there isn't.
    But until you do it on a system that removes as many hardware variables as possible, the results are nothing more than a moot point.

    When we figure out what is going on, A ticket will be made and it will be looked at.
    But we need results the show the problem repeatedly, with the same scene on all systems.
    Without having repeatable results using the same scene file, it is nothing more than a guessing game.