Show Us Your Dawn Renders!

[Hornet3d]

Since upgrading to Poser 11.3 I have been playing the render settings and revisited Branched Path Tracing to see if I could come up with a balance between render time and quality. This is where I am at present I don't think I can do major changes to this balance wise. The render time is 30 minutes but then I am rendering at 3508 X 2480 pixels and I am using Bagginsbill's hair shader which is very complex.

It is a render I have used before so I can judge the quality and I think this is by far the best 30 minute image I have ever rendered.

 

[Ken1171]

revisited Branched Path Tracing to see if I could come up with a balance between render time and quality.

BPT should increase render performance if there is a balance between pixel samples, the render size, and the bucket size. In general, the higher the first two, the lower the latter should be. That's to keep Superfly from running out of memory when in GPU + BPT mode. As far as I understand this, there isn't much to gain by using BPT + CPU because processors have only a few cores, so there isn't much headway to make it effective if we compare it to a high-end GPU with thousands of CUDA streaming processors. BPT comes handy with GPU mode, but that will only affect performance, not image quality.

Personally, I find it hard to balance performance when render sizes go as high as you are doing. That's because the bucket size would have to be so small that it will choke the bandwidth required by BPT to be effective. Maybe that won't be a problem if your GPU has as much as 11 or 12GB VRAM, but mine has only 6GB, so image size matters.

 

[Hornet3d]

BPT should increase render performance if there is a balance between pixel samples, the render size, and the bucket size. In general, the higher the first two, the lower the latter should be. That's to keep Superfly from running out of memory when in GPU + BPT mode. As far as I understand this, there isn't much to gain by using BPT + CPU because processors have only a few cores, so there isn't much headway to make it effective if we compare it to a high-end GPU with thousands of CUDA streaming processors. BPT comes handy with GPU mode, but that will only affect performance, not image quality.

Personally, I find it hard to balance performance when render sizes go as high as you are doing. That's because the bucket size would have to be so small that it will choke the bandwidth required by BPT to be effective. Maybe that won't be a problem if your GPU has as much as 11 or 12GB VRAM, but mine has only 6GB, so image size matters.

My card has 11GB which handled this but I have to tread with care. Strangely the GPU handles the hair shader very differently than the CPU.

 

[Hornet3d]

Ignore my last comment, as you would expect there is no difference in a GPU or CPU render. I did get a difference at one point but Poser must has thrown a wobbly as when I closed and reopened it the rendered the result was the same. The only difference was the CPU was faster but then it has a lot of cores to throw at it.

The reason for the render size is that I often have some of the renders printed but I never know at the point I create and render a scene if that particular render will be. I therefore render at the 3508 X 2480 which give me a A4 landscape render. If the render is going into a lay flat photobook than I can sometimes render to 7016 X 2480 which gives me a A4 two page landscape. In these case I usually know it is to be printed as such, as long as I do not change my mind.

The real plus for me here is that I have managed to set up BPT to give me this result in the 30 minute time frame. Before I would have BPT off and progressive refinement on with the samples set to fifty, the idea being to cancel the render when I was happy with it. Portraits would almost certainly run for the full fifty samples and take four to five hours so this is a big reduction for me.

 

[Ken1171]

Wow I so wish I had that much GPU VRAM here, so I could render larger images. With [almost] twice as much the VRAM size, you can bump up bucket size and reduce render times, but I am not sure how much because you render at such high res that it might make up for that extra video memory you have. But one thing is for sure - GPU BPT requires way less pixel samples to produce the same results as without it, so for that alone, your renders should take less time when it's enabled.

Over here I set GPU+BPT to under 7 pixel samples per render for all you have seen from me. With BPT disabled, it requires 40+ pixel samples to produce the same results, which on its own increases render times exponentially. If I switch to CPU mode, renders take many times fold, and it doesn't matter if I enable BPT or not.

Based on my personal experience with Superfly GPU rendering, if you have better times with CPU, either you have a low-end GPU (unlikely just for the amount of VRAM it has), or the params are not set to make the best out of it. For example, the default bucket size in Poser is too low to get any good performance with GPU renders. Having a GPU with 6GB VRAM, I have to bump bucket size to at least 500 to get faster renders. Using or not progressive rendering will only affect how much memory it uses, not rendering times. But when disabled, the render buffer will clear if you stop the render before it finishes. I always leave it on for that reason alone. If anything happens, I don't loose my render.

In addition, each of the Superfly parameters is quite expensive to increase, usually exponentially so. Increasing some of them by a single digit can double, or even quadruple render times, so we have to be conservative about them.

 

[Ken1171]

Ahhh, I wasn't sure if you had checked that out. OK, and yes I'm familiar with wxPython, but I haven't tried programming with Python yet, so not sure how I'd do this.

Problem solved. I have examined Karina's code, and noticed she didn't use any of the WX managers the Poser documentation claim to be required. Ironically, this also means I would never solve this problem by following the official documentation. These extra WX managers were claimed to be required to integrate Python scripts with the Poser WX interface, but what they actually did was to slow the heck of them down, and cause Poser to crash when we close them.

I have deleted all of these managers, and my startup code is now comprised of a single line - the class name itself. The app performance has visibly increased, and the close button simply closes the app, no more crashing Poser. The only thing I lost was the ability to dock the panel into the Poser interface. I don't like that anyway, so I am Ok without it. I actually hate when I try to reposition the app, and Poser keeps trying to dock it, messing up my interface. And I like this side-effect that my app now runs faster in Poser.

 

[Miss B]

Problem solved. I have examined Karina's code, and noticed she didn't use any of the WX managers the Poser documentation claim to be required.

Psssssssssst . . . Karina's a he, not a she.

The only thing I lost was the ability to dock the panel into the Poser interface. I don't like that anyway, so I am Ok without it. I actually hate when I try to reposition the app, and Poser keeps trying to dock it, messing up my interface.

OK, so Posesr thinks it's dockable, but it's not. Usually you can choose whether a Poser window is dockable, docked, or floating. I'm not sure where in the code for this you could set that up, but it might be doable. I know Joe/Netherworks has that on his Script Servant goodie. It loads floating, but I just grab it and doc it where I want it.

 

[Ken1171]

Psssssssssst . . . Karina's a he, not a she.

Oops, my mistake! ^^

OK, so Posesr thinks it's dockable, but it's not. Usually you can choose whether a Poser window is dockable, docked, or floating. I'm not sure where in the code for this you could set that up, but it might be doable. I know Joe/Netherworks has that on his Script Servant goodie. It loads floating, but I just grab it and doc it where I want it.

No, it's not that. These WX managers I have removed from the code were responsible to allowing the frame to be dockable. Now the app is no longer dockable, which is actually what I wanted.

 

[Janet]

I hope you will make this a product we can all play with.

 

[Ken1171]

I hope you will make this a product we can all play with.

As a matter of fact, I have just started it's own thread.

 

[Miss B]

Oops, my mistake! ^^

No problem. I thought the same thing when I first "met" him on the old SM Poser forum. It got so I stopped going by avatars when trying to determine if someone was male or female.

 

[Ken1171]

Tried 5 different plants with the "Scatter Tool" to make this scene, and that's Dawn at the center. ^^

 

[Ken1171]

It's bunny time! And horsey doesn't want them to hide the carrots. The scatter tool was useful to place some grass around. ^^

 

[KageRyu]

Every time I see that rabid Lagomorph I wish I had hime in my runtime - he reminds me of Max, and I was a big fan of Max...not so much Sam though.

 

[Ken1171]

Every time I see that rabid Lagomorph I wish I had hime in my runtime - he reminds me of Max, and I was a big fan of Max...not so much Sam though.

Thanks! I have modeled Max many years ago. I think he was 2nd or 3rd Poser figure made as an exercise for modeling, UV mapping, and rigging. Wasn't my best work, but he's still fun to use.

 

[Ken1171]

Scene created with Dawn Type-12 + Scatter Tool plugin in Poser. Made some crates with the Poser box primitive, and added some grass. Rendered with Superfly.

 

[FantasyArt3D]

Willow

I like this girl

 

[Ken1171]

Willow
I like this girl

Lovely render! I like ALL of the 3DU's toon characters, and Willow is no exception. You can combine her morph with other characters to "toon-them-up". ^____^

 

[Ken1171]

A little "Dirty Pair" TV show (1985) fanart, featuring by interpretation of Kei, the short-tempered, impulsive redhead tomboy. Made with "Body Type-12" and my original outfit. Rendered in Poser with Superfly.

 

[Ken1171]

Kei wouldn't be called the "Dirty Pair" without her opposite counterpart, Yuri. Now the fanart set is complete. While Kei was the explosive tomboy, Yuri was the girly, smarter one. While Kei preferred the large bazookas, Yuri would pick energy whips, lightsabers, and throwing cards over fire weapons. Kei loved muscle men, while Yuri would only flirt with cultured, educated men. Complete opposites. Not to mention their bear-sized cat-like creature pet, Mughi, who could pilot spaceships.

One of the fun parts of watching this 1980's TV series was the constant bickering between these two, and of course, how they often managed to accidentally cause large scale destruction, and occasionally explode a whole planet.