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?
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.
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.
ghostship last edited by
@Y-Phil have you tried TrekkieGrrrl's room prop for P11? Works great for bouncing light around.
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
morkonan last edited by
@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.
matb last edited by matb
@ghostship CONCLUSION TO RENDERING TIMES ISSUE
I took your advice and rendered the scene below with everything turned on. Here are the results:
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.
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
ghostship last edited by
@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)
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.
James_in_3D last edited by
I appreciate your input on this, @shvrdavid ... I can get varying results at different times on the same scene, too. But my system is a Mac and doesn't have the option of using its GPU, so I'm not sure my experience matters. I do wonder what the test systems used by SM are. I know the beta testers have widely diverse systems, which is good.
I did all my tests with Firefly and CPU options in the others, the GPUs were just sitting there waiting to update the screens.
maestro last edited by maestro
This post is deleted!