-
Welcome to the Community Forums at HiveWire 3D! Please note that the user name you choose for our forum will be displayed to the public. Our store was closed as January 4, 2021. You can find HiveWire 3D and Lisa's Botanicals products, as well as many of our Contributing Artists, at Renderosity. This thread lists where many are now selling their products. Renderosity is generously putting products which were purchased at HiveWire 3D and are now sold at their store into customer accounts by gifting them. This is not an overnight process so please be patient, if you have already emailed them about this. If you have NOT emailed them, please see the 2nd post in this thread for instructions on what you need to do
Which Poser version is best at this point in time?
- Thread starter Rick
- Start date
I just did some tests because I've never had the problems with Cycles that people have been having with Superfly in terms of render time and quality. The only reason I used Firefly was my frequent use of and pretty sound understanding of so many of Firefly's texture nodes, and Firefly's native support. I could do well enough with Firefly that was often not worth it to export to Blender and set up new materials for everything. But Cycles was always _much_ faster than Firefly for me.
But my initial Superfly tests seemed to be like everyone else's. Slow and not as realistic.
So I decided to do some testing. I set up a really simple scene in Poser (emitting mesh, plain box for a room, Andy in the middle). I made Andy's Superfly material more accurate. I exported the scene to Blender and duplicated the materials. Then I made the rendering settings as identical as possible. The only hitch was the fact that choosing Branched Path in Blender eliminates
Just for reference, these are my processors:
CPU- Intel Core i7-4790K @ 4GHz (8 threads)
GPU - 2 x GeForce GTX 970
These are my results:
Blender 2.77 Poser Pro 11.0.0.3172
Path Tracing GPU 11:16.73 About 34:00
Path Tracing CPU 01:00:07.54 About 26:00
Branched Path Tracing GPU 13:30.50 Hours without finishing, gave up
Branched Path Tracing CPU 01:04:16.15 Much faster than above, but still on track to be hours
In no case did Branched Path Tracing perform faster. Its samples were _much_ lower than the Path Tracing samples , and the results were noticeably grainier. Not hugely so, though.
As far as I can tell, Branched Path Tracing isn't worth using in Cycles, regardless of what theory says. Maybe I'm missing something, and these results would be wildly different if caustics were involved. Which I'll test. But I'm not optimistic. I've always used Path Tracing, but Poser defaults to the much less efficient Branched Path Tracing. If everyone is using Branched Path, that could explain why so many are finding Superfly so slow.
That said, the closest I could get with Firefly only took 4:24. Unfortunately, it was _completely_ unacceptable in terms of quality, despite incredibly high settings using D3D's Render Firefly settings. This is a scene lit by a simple sphere emitter, and Firefly's IDL just isn't a good enough substitute for real emitters in a simple scene like my test scene.
Which is why I _personally_ wouldn't recommend a Poser version older than 11. Or a DS version older than 4.8, for that matter. I think that it would be good to start playing with Iray or Superfly if you can. Firefly and 3Delight are Renderman renderers. Renderman is deliberately designed for faking the funk in animation and allowing for a complex and versatile workflow, not for realism in simple stills rendered on single boxes. Even for a movie with reflections like Tron, Disney, partners of Pixar, went with Vray.
I think there's tons of time. I wouldn't push anyone to upgrade. But the day will come when vendors won't support 3Delight or Firefly. After all, last I saw a survey, the most popular genres in the content community were fantasy and sci fi. Both of which often involve glass, liquids, gems, and stuff that glows. Sticking to the older render engines means giving up caustics and emitters. Neither of which is simple to fake. There's a reason Stonemason seems to be Iray only now.
But my initial Superfly tests seemed to be like everyone else's. Slow and not as realistic.
So I decided to do some testing. I set up a really simple scene in Poser (emitting mesh, plain box for a room, Andy in the middle). I made Andy's Superfly material more accurate. I exported the scene to Blender and duplicated the materials. Then I made the rendering settings as identical as possible. The only hitch was the fact that choosing Branched Path in Blender eliminates
Just for reference, these are my processors:
CPU- Intel Core i7-4790K @ 4GHz (8 threads)
GPU - 2 x GeForce GTX 970
These are my results:
Blender 2.77 Poser Pro 11.0.0.3172
Path Tracing GPU 11:16.73 About 34:00
Path Tracing CPU 01:00:07.54 About 26:00
Branched Path Tracing GPU 13:30.50 Hours without finishing, gave up
Branched Path Tracing CPU 01:04:16.15 Much faster than above, but still on track to be hours
In no case did Branched Path Tracing perform faster. Its samples were _much_ lower than the Path Tracing samples , and the results were noticeably grainier. Not hugely so, though.
As far as I can tell, Branched Path Tracing isn't worth using in Cycles, regardless of what theory says. Maybe I'm missing something, and these results would be wildly different if caustics were involved. Which I'll test. But I'm not optimistic. I've always used Path Tracing, but Poser defaults to the much less efficient Branched Path Tracing. If everyone is using Branched Path, that could explain why so many are finding Superfly so slow.
That said, the closest I could get with Firefly only took 4:24. Unfortunately, it was _completely_ unacceptable in terms of quality, despite incredibly high settings using D3D's Render Firefly settings. This is a scene lit by a simple sphere emitter, and Firefly's IDL just isn't a good enough substitute for real emitters in a simple scene like my test scene.
Which is why I _personally_ wouldn't recommend a Poser version older than 11. Or a DS version older than 4.8, for that matter. I think that it would be good to start playing with Iray or Superfly if you can. Firefly and 3Delight are Renderman renderers. Renderman is deliberately designed for faking the funk in animation and allowing for a complex and versatile workflow, not for realism in simple stills rendered on single boxes. Even for a movie with reflections like Tron, Disney, partners of Pixar, went with Vray.
I think there's tons of time. I wouldn't push anyone to upgrade. But the day will come when vendors won't support 3Delight or Firefly. After all, last I saw a survey, the most popular genres in the content community were fantasy and sci fi. Both of which often involve glass, liquids, gems, and stuff that glows. Sticking to the older render engines means giving up caustics and emitters. Neither of which is simple to fake. There's a reason Stonemason seems to be Iray only now.
Last edited:
Glitterati3D
Dances with Bees
Yeah, I have never used Branched Path Tracing for Superfly renders. During the webinar right after release, the tech guy explained it was practically useless, so I turned it off and never turned it back on.
Most of my Superfly renders are under an hour - CPU rendering. Both of these are done in Superfly in under an hour.
Most of my Superfly renders are under an hour - CPU rendering. Both of these are done in Superfly in under an hour.
Just to clarify, Branched Path Tracing (BPT) is a multithreaded version of simple Path Tracing. When rendering with the CPU, the number of threads is tiny, usually around 4-12 threads with Hyper-Threading. BPT makes more sense in massively parallel GPU rendering with hundreds, or even thousands of streaming processors (SPs). In my PC, disabling BPT in GPU results into performance drops in the order of at least 10 times. Enabling BPT means spreading the calculations across multiple parallel threads that execute simultaneously, cutting rendering times considerably. It becomes less relevant in CPU rendering, but even then it can cut rendering times to some extend.
But to measure this kind of performance, it's not enough to enable/disable BPT, since Cycles/Superfly have several critical parameters that affect performance exponentially. For example, "Pixel Sanples" works as a multiplier to all parameters, so changing it from 3 to 4 already multiplies the value of all other parameters, which on its turn increases rendering time exponentially (not linearly). So if you can't speed your renders with BPT, it probably means your rendering params are way too high to make a difference. For once, the included built-in presets are WAAAY overblown and should take forever to render (hours).
By manually optimizing the Cycles params to more down-to-Earth levels, so far none of my renders took longer than 20 minutes. Enabling GPT in GPU mode can reduce this time down to up to 2 or 3 minutes - but then it crashes Windows altogether with a nice BSOD followed by a hard reboot and corrupts the Poser scene file (fills it with zeroes). Disabling BPT in GPU mode defeats the purpose of using the GPU in the first place, because it cannot distribute the workload into multiple threads. So GPU rendering without BPT means running a single rendering thread, disregarding how many SPs your video card may have, which is as good as having just a single one. In that case, even a Hyperthreaded dual core CPU can render faster than a Titan X, because it has 4 threads to work with.
But to measure this kind of performance, it's not enough to enable/disable BPT, since Cycles/Superfly have several critical parameters that affect performance exponentially. For example, "Pixel Sanples" works as a multiplier to all parameters, so changing it from 3 to 4 already multiplies the value of all other parameters, which on its turn increases rendering time exponentially (not linearly). So if you can't speed your renders with BPT, it probably means your rendering params are way too high to make a difference. For once, the included built-in presets are WAAAY overblown and should take forever to render (hours).
By manually optimizing the Cycles params to more down-to-Earth levels, so far none of my renders took longer than 20 minutes. Enabling GPT in GPU mode can reduce this time down to up to 2 or 3 minutes - but then it crashes Windows altogether with a nice BSOD followed by a hard reboot and corrupts the Poser scene file (fills it with zeroes). Disabling BPT in GPU mode defeats the purpose of using the GPU in the first place, because it cannot distribute the workload into multiple threads. So GPU rendering without BPT means running a single rendering thread, disregarding how many SPs your video card may have, which is as good as having just a single one. In that case, even a Hyperthreaded dual core CPU can render faster than a Titan X, because it has 4 threads to work with.
The settings don't quite work like that in Blender. When you turn on BPT, you no longer can choose your overall Pixel Samples. You can choose your AA Pixel Samples, and that acts the way you describe. But it's clearly separate and defaults to relatively low settings. But even in Poser, I'm perfectly able to read the progress bar. My BPT renders tests both in Poser and Blender used _much_lower samples. By about half. It just wasn't as fast. In my Cycles tests, BPT was at best measurably slower with lower quality results. In Poser, those same _exact_ settings as I used in Blender (so again, lower quality), were set to take hours, and possibly days.
It is not a quality issue. You know how I know? I use progressive rendering. I can read my Poser progress bar. I could see how long it took to get to 512 or so samples. Not Tracing Samples. Just samples. It took _ages_. IIRC, when I stopped Poser using BPT + CPU, after more than an hour, it had only gotten to less than 100 Path Tracing Samples and looked horribly grainy. Using Poser BPT + GPU was even slower. In Poser, it was way, way slow in every case, regardless of how unacceptably low I made my settings.
Under absolutely no circumstances, including rendering in Blender with what I'd consider inferior settings and results, did Cycles BPT render in 2 or 3 minutes. That 13:30 BPT render was significantly _lower_ quality than the 11:16 PT render, and not just by stats. It was too grainy for what I'd consider acceptable in a final render. Despite using my two pretty decent video cards, BPT performed significantly worse.
Again, I'm not addressing theory. I'm doing practical tests of Cycles. In Cycles, I'm consistently (as in including multiple renders that whose data I haven't posted because I'm not being as methodical) seeing BPT perform slower for visibly grainier results and fewer samples. Since Cycles BPT settings don't work the way you describe, and you're saying you can't test BPT with GPU in Poser but posting BPT + GPU results, I'm guessing that you're throwing in data from your experiences in another renderer. Like Octane. Which probably implements BPT much better, and is _much_ older (and therefore, more developed) than Cycles.
Also, if you note my times, using PT doesn't _at all_ defeat the purpose of using my GPU. In Blender, I observed about an order of magnitude difference (1 hour vs. 11 minutes). Also, I just did a test, and I'm finding that using only one card just about doubles my render time. So even without BPT, Cycles is using my video cards in parallel.
In short, no, I'm sorry, but you're wrong about my test results. They are legit. It is not an issue of settings that are "too high." It is an issue of Cycles BPT being consistently less efficient, at least on my box. I suspect the same is true for most people. I'm seeing lots of grainy render results that people are saying took a long time to render. The Superfly default is BPT with CPU. That combo gave me a _much_ longer render time than PT with GPU. As in rendering so very slowly that it might have taken more than a day. With settings that were _much_ lower than my PT settings. I could see how long it took to go through one pass, and each pass was at least 10x's slower.
Oh, and I don't have my computer crash consistently using Poser's BPT with GPU. Hence my numbers. I had it crash only once that way. And I haven't had a BSOD yet. It seems to just crash my driver, and black out my screen. Mostly it worked very slowly. Interestingly, I just experienced the same crash in Blender using BPT + GPU.
As far as I can tell, it's just a bad idea to use BPT in Cycles at this point. I'm not saying the theoretical principle is bad. I'm not even saying that Cycles BPT won't improve. When I started using Cycles, I had to use a Beer's law absorption equation to fake SSS, there were no volumetrics at all, and it didn't render particles. It's already come a long way in a pretty short time. I haven't seen evidence of its progress slowing down. But right now, my tests definitively show Cycles BPT working significantly slower in both Blender and Poser with lower quality settings and grainier render results. I also experience intermittent crashes using Cycles BPT + GPU, despite that being significantly faster than BPT + CPU when it works. Oh! And this was really weird, IMHO. Using BPT + GPU, in both Blender and Poser, caused my whole box to become loggy. As in finding it hard to write because of the lag. I checked, and there was no unexpected hit to my CPU or RAM (I thought maybe it triggered some kind of process as a bug). Just using PT, I didn't experience any noticeable slow-down at all.
Oh, and just to add, my video driver is up to date. I last checked it right before doing my first tests.
Last edited:
Makes me wonder why we are having opposite results with BPT in Cycles - there must be an explanation. My tests were done in Poser with Superfly - I can't really compare it with Octane because Cycles drags in slow motion in comparison, so I prefer not to compare. I don't use Blender, so I can't compare SF with the original Cycles either.
I started testing with GPU + BPT because I didn't know it would cause Windows to explode. That's written in the documentation (known issues), but I didn't read that at first. The crashes didn't happen at first, and as a matter of fact, they only started a couple of days later. Maybe it depends on what's in the scene, I don't know, and when I asked, SMS didn't seem to know either. All they know is that GPU + BPT crashes the nVidia driver in Windows. In my particular case, I am using Win10 x64, and in this OS the video driver tends to take Windows down when it crashes. Even in the rare occasion when the driver happened to recover, Windows became unstable right after, so I had to reboot anyway. Maybe this is more or less serious depending on the specifics of the system, but some other people seem to have less severe crashes with other video cards and OS combinations. I have also heard that people using 2 video cards, one for rendering, and one for the OS, don't seem to have crashes at all with GPU + BPT in SF, but I only have a single GPU here. Win10 doesn't work well with 2 for some reasons. There are some restrictions and penalties for doing so.
So my performance results are based on the couple of days when SF with GPU + BPT didn't crash Windows. I first started with the default CPU + BPT setup and did a few renders. Performance is not bad with 12 threads in lower settings, being more or less equivalent to Firefly performance. Switching to GPU + BPT suddenly started clearing noise almost instantly, so the difference was blatant. Render times dropped from 20 minutes to a little over 2 minutes - a 10X speed gain with my GTX 980 ti. In some cases noise would clear in less than a minute, depending on the scene and lighting. I was IMPRESSED.
But then at some point the video card driver started to crash, and in every time that resulted in a freeze-up, followed by a BSOD, followed by a hard reboot. I was forced to disable BPT, but I still wanted to render with GPU. The params change without BPT, so I had to read the manual to see how to proceed. The manual claims we have to increase Pixel Samples considerably to achieve the same results as BPT, so I changed it from 4 to 20 as suggested in the manual. Now I am sitting for hours waiting for the noise to clear, and GPU usage has dropped from 99% down to mere 5%, occasionally spiking to 80% and then back to 5% - things are no longer efficient. I have tried reducing Pixel Samples down to 10, but noise is still taking forever to clear, while with BPT it was a whole different story - almost instant results. For the record, Octane ALWAYS produces instant results, so I can't even start to compare - it's a whole different class. That's why I was so impressed to see that SF with GPU + BPT was producing almost instant noise clearing. That was remarkable, but short-lived.
Since GPU rendering seems useless without BPT in SF, I have switched back to CPU + BPT ever since, very unhappy, because now I am back to relatively slower rendering and I am not able to use GPU. In general, it appears to be 10X times slower, but I am not surprised since my GPU is many times more powerful than the CPU, so the results seem pretty logical on this part.
These were my actual results with Cycles in Poser. I can't explain why you are having a different experience with your OS and hardware, and you seem to know Cycles much better than me, both in Blender and Poser. There must be a logical explanation, but all I can say is that SF has lost it's initial appeal without BPT in GPU mode. SMS told me they are working with nVidia to resolve this, but we already had several new GeForce drivers and Poser service releases since then (7 months ago), and still no solution.
I started testing with GPU + BPT because I didn't know it would cause Windows to explode. That's written in the documentation (known issues), but I didn't read that at first. The crashes didn't happen at first, and as a matter of fact, they only started a couple of days later. Maybe it depends on what's in the scene, I don't know, and when I asked, SMS didn't seem to know either. All they know is that GPU + BPT crashes the nVidia driver in Windows. In my particular case, I am using Win10 x64, and in this OS the video driver tends to take Windows down when it crashes. Even in the rare occasion when the driver happened to recover, Windows became unstable right after, so I had to reboot anyway. Maybe this is more or less serious depending on the specifics of the system, but some other people seem to have less severe crashes with other video cards and OS combinations. I have also heard that people using 2 video cards, one for rendering, and one for the OS, don't seem to have crashes at all with GPU + BPT in SF, but I only have a single GPU here. Win10 doesn't work well with 2 for some reasons. There are some restrictions and penalties for doing so.
So my performance results are based on the couple of days when SF with GPU + BPT didn't crash Windows. I first started with the default CPU + BPT setup and did a few renders. Performance is not bad with 12 threads in lower settings, being more or less equivalent to Firefly performance. Switching to GPU + BPT suddenly started clearing noise almost instantly, so the difference was blatant. Render times dropped from 20 minutes to a little over 2 minutes - a 10X speed gain with my GTX 980 ti. In some cases noise would clear in less than a minute, depending on the scene and lighting. I was IMPRESSED.
But then at some point the video card driver started to crash, and in every time that resulted in a freeze-up, followed by a BSOD, followed by a hard reboot. I was forced to disable BPT, but I still wanted to render with GPU. The params change without BPT, so I had to read the manual to see how to proceed. The manual claims we have to increase Pixel Samples considerably to achieve the same results as BPT, so I changed it from 4 to 20 as suggested in the manual. Now I am sitting for hours waiting for the noise to clear, and GPU usage has dropped from 99% down to mere 5%, occasionally spiking to 80% and then back to 5% - things are no longer efficient. I have tried reducing Pixel Samples down to 10, but noise is still taking forever to clear, while with BPT it was a whole different story - almost instant results. For the record, Octane ALWAYS produces instant results, so I can't even start to compare - it's a whole different class. That's why I was so impressed to see that SF with GPU + BPT was producing almost instant noise clearing. That was remarkable, but short-lived.
Since GPU rendering seems useless without BPT in SF, I have switched back to CPU + BPT ever since, very unhappy, because now I am back to relatively slower rendering and I am not able to use GPU. In general, it appears to be 10X times slower, but I am not surprised since my GPU is many times more powerful than the CPU, so the results seem pretty logical on this part.
These were my actual results with Cycles in Poser. I can't explain why you are having a different experience with your OS and hardware, and you seem to know Cycles much better than me, both in Blender and Poser. There must be a logical explanation, but all I can say is that SF has lost it's initial appeal without BPT in GPU mode. SMS told me they are working with nVidia to resolve this, but we already had several new GeForce drivers and Poser service releases since then (7 months ago), and still no solution.