I debated whether to post this here. But I saw the thread by Ironsoul on lighting and decided, eh, why not? This is a repost for everyone who posted at the SM Poser Forum, but rather than taking a chance that it might not be moved or saved, I post this here in Poser's new OFFICIAL Forum.

4 Ways to Speed up Your Cycles Render!

Well that's interesting - I finally understand why people kept telling me to increase bucket size and it made things awful for me. I'm on an AMD card, so I have to use CPU rendering and it seems to be the opposite. When the render I have cooking right now (with Progressive Refinement on) finishes, I'll try a bucket size of 16 and see what it does for me.

Is this applicable for Poser Pro 11? Cheers

arrow1 posted at 7:03PM Sun, 14 July 2019 - #4357004

Is this applicable for Poser Pro 11? Cheers

Pretty much. Superfly is based on Cycles and if you open up the Render page under Superfly, you'll find that you can adjust the four topics addressed although GPU and CPU are determined by your computer.

Also in that thread was the following advice. I had seen a Blender Guru Video on 18 ways to speed up Cycles.

18 ways to Speed up Cycles

I did watch it though, and once again remember that these apply mainly to Cycles, but Superfly can probably benefit as well. You'll notice that I only specifically posted 12 suggestions. That was because a few of them were Cycles specific, like using the new Denoiser filter, using Portals, or using the latest version of Blender.

reduce light Bounces

Use GPU

Change the Tile Size (Smaller for CPU) (Larger for GPU)

Reduce Samples

Use newest version

Use a different OS

Clamp it. The higher the better. Indirect only.

Turn off Caustics

Remove Alpha transparency.

Reduce the strand count (Hair & particles)

Remove Volumetrics

Cut Subsurface Scattering (If you don't need it)

Understandably, though, the moment you actually want to realistically render fluids or refractive surfaces/volumes, higher Light Bounces, Caustics and Volumetrics become mandatory. If they're not in your scene at all, then sure, get rid of them.

Caustics, volumetrics and all of that are why some people, like seachnasaigh built a render farm. And he renders using the render queue. Rendering in background is another viable option if your machine has the RAM to do it because it allows you to work on a scene while rendering.

rokket posted at 7:50PM Mon, 15 July 2019 - #4357097

Caustics, volumetrics and all of that are why some people, like seachnasaigh built a render farm. And he renders using the render queue. Rendering in background is another viable option if your machine has the RAM to do it because it allows you to work on a scene while rendering.

All these suggestons do is speed up your render times. If Caustics, volumetrics, etc. are important to you, then have at it.

EClark1894 posted at 5:26PM Mon, 15 July 2019 - #4357104

rokket posted at 7:50PM Mon, 15 July 2019 - #4357097

Caustics, volumetrics and all of that are why some people, like seachnasaigh built a render farm. And he renders using the render queue. Rendering in background is another viable option if your machine has the RAM to do it because it allows you to work on a scene while rendering.

All these suggestons do is speed up your render times. If Caustics, volumetrics, etc. are important to you, then have at it.

To be honest, I was just offering one solution, i.e., the render to background or the render queue. I rarely ever render caustics or volumetrics because I mostly render to test a material I am creating for a model. I don't do many finished scenes that are heavily populated with figures, props, lights... It was just a suggestion, and one that I know a lot of people won't even consider because networking a bunch of CPU's for a render farm is out of budget.

I'm also in the particularly difficult situation of having discovered a Poser bug that precludes background or queued renders since they both require a scene file to be saved, which breaks the necessary channel evaluation order that tightly conformed clothing requires to match the base figure and avoid pokethrough. Whenever the external renderers load that saved scene, the conformers' inherited deformer channels get re-ordered and no longer match the base figure's deformer channels, so pokethrough occurs, except when the scene is foreground rendered. Utterly frustrating.

Speeding up render times is actually quite easy if you remember that everything you add has to be calculated.

I see some adding nodes and nodes and nodes, but remember. . . . . Everything you add has to be calculated.

Same goes for polycount, number of material zones, number and size of textures, number and type of lights.

And if you use the "modern" PBR workflow with older content, please remove all old "cheating nodes" when it is render time.

Many have proved that all content renders pretty good with very few nodes.

Less calculations to perform, and avoiding contradicting calculations speeds renders up.

In the end? Each rendered pixel has just a single R,G,B, value, and the pixel does not care where that came from.

tonyvilters posted at 6:25AM Tue, 16 July 2019 - #4357120

Speeding up render times is actually quite easy if you remember that everything you add has to be calculated.

I see some adding nodes and nodes and nodes, but remember. . . . . Everything you add has to be calculated.

Same goes for polycount, number of material zones, number and size of textures, number and type of lights.

And if you use the "modern" PBR workflow with older content, please remove all old "cheating nodes" when it is render time.

Many have proved that all content renders pretty good with very few nodes.

Less calculations to perform, and avoiding contradicting calculations speeds renders up.

In the end? Each rendered pixel has just a single R,G,B, value, and the pixel does not care where that came from.

Nodes aren't the real problem though with PBR. It's how the light bounces around during render times. If you'll notice, most of the suggestions for speeding up rendering are actually for how much, how and where the light bounces around a scene. Firefly fakes a lot of this, but PBR actually does calculate the light bounces in a scene.

Light is what you see bouncing around and the calculations can not be seen, but have to be calculated.

Render speed is all about the amount of math behind the scene to get to the end result.

Nodes are not dangerous. People are. So is a little knowledge.

bagginsbill posted at 5:18PM Tue, 16 July 2019 - #4357179

Nodes are not dangerous. People are. So is a little knowledge.

I wish this forum had a like button. Best post I've seen in days.

bagginsbill posted at 3:32AM Wed, 17 July 2019 - #4357179

Nodes are not dangerous. People are. So is a little knowledge.

You're both right. And both wrong. There is no single bottleneck that applies to all scenes equally. You can have scenes that spender 90% of their render time on shader evaluation, you can have scenes that are 90% ray intersections, you can have scenes that are 90% lighting. Even without going to pathological artificial examples, I've seen pretty much all of that in the wild.

If you want the true answer, Blender now has an integrated profiler for Cycles that will give you a report of how it spent its time: https://developer.blender.org/D3892

stewer posted at 7:46AM Wed, 17 July 2019 - #4357199

bagginsbill posted at 3:32AM Wed, 17 July 2019 - #4357179

Nodes are not dangerous. People are. So is a little knowledge.

You're both right. And both wrong.

I don't see how you can say that when the point I was making was identical to what you said after. I was trying to be droll but humor is often lost in these forums.

Let me be more explicit. I have, on numerous occasions, timed how much a math node costs and it is near zero. Adding 20 math nodes so that a particular configuration parameter I have designed works in a way to make the end-user have a good experience is nearly cost free. So, for example, on a leather shader where you want ONE parameter to control all aspects of "shine", this is a good trade. The cost to render times is typically 1 to 5% due to the math nodes.

Addition of a single HSV node often makes tone adjustments so much easier. The cost is typically 1/300th of the render time.

So to say adding many nodes is the primary cause of long render times, when those nodes are math nodes, is completely incorrect. When those nodes are lighting nodes, they do add some time but what on earth are you doing rendering with SuperFly if lighting isn't your point?

To add MULTIPLE lighting nodes, such as in BB Hair, so that you get that last 5% of realism, yes that is not for everybody. But neither is a BMW or a Volvo and I have three of those.

Well, no clue what a BMW or a Volvo are doing here. LOL.

I used to own 2 private airplanes (Sold both due to age); A Jodel D-120A the OO-FDP a 95hp 2 seater, and a MS - 894 the OO-CCB a 235hp 4-5 seater.

The first currently in the UK and the second currently in maintenance in the Netherlands. Do they count? LOL. Oh, and a car, and a 4x4 quad, and a motorcycle, and 8 bicycles. + Why not, some roller blades. LOL.

We are discussing the cost of various rendering components or features and the argument that expensive components should be avoided is invalid if the costs are proportionally small for the person in question. If a render takes 30 seconds and a node you want to use adds only 2 seconds, that is insignificant. By analogy, expensive luxury car costs are insignificant to some people and conversely unreachable expensive for others.

Specifically, Tony, you said this "I see some adding nodes and nodes and nodes, but remember. . . . . Everything you add has to be calculated."

And you could have just as well said "I see some buying cars and cars and cars but remember - Every car you buy has to be paid for"

Yes it does. And just as the cars I buy are fine by me, so are my nodes, none of which are added without a purpose. Every single node has a job to do that, without it, would not be done.

You frequently suggest that simple is the best, and for people learning how to use a rendering engine, that is not accurate advice. Simpler is usually better, but at some point you are stuck in the uncanny valley, (particularly YOU are Tony - your lady is severely in the uncanny valley) and the only way out is more expensive renders.

Oh, on that point, I agree completely BB;

The reason behind the quote ; " nodes and nodes and nodes" is that most end users keep adding and adding and adding, often creating contradicting calculations, without understanding what they do.

And as far as my test-figures go : I repeated on several occasions that they are test-figures, nothing less, but certainly nothing more.

The obj files, the riggings, the textures, the nodes ? ? ALL of them change almost on a daily basis, and every 6 months they get deleted and rebuild from the ground up.

Hello BB, I follow every post I can find of yours and I know you will not be glad if I ask, but could you attach in https://sites.google.com/site/bagginsbill/free-stuff the BBNylon2.mt5 for FF and Nylon+leg specifically for stockings? Do you still have those? Or the .mm1 for matmatic at least? too much time has passed and I can't find it anywhere .. Sorry, this is not in line with the topic but the most recent post I found ..

https://www.youtube.com/watch?v=eGAjsSNtX6E

don't mind me, i found it

rokket posted at 8:28AM Sat, 24 August 2019 - #4357097

Caustics, volumetrics and all of that are why some people, like seachnasaigh built a render farm. And he renders using the render queue. Rendering in background is another viable option if your machine has the RAM to do it because it allows you to work on a scene while rendering.

Eh? I thought Rendering in the background just reduced the resource strain so you could still use your computer while rendering. Rendering one scene while working on the next? rokket, you just improved my workflow.