Returning User Render Settings help

3dOutlaw

Hi all,

I've been working with DS (again, it's been a while) some again, due to the Smoothing Modifier (love that feature!)

Anyway, I put together this new character (V4-based), and I wanted to have someone check out my settings here.

NEW CHARACTER LINK/IMAGE

I am using:

UberEnvironment2 (default except):
- Occ Samples=64
- ShadingRate=1.00
- MaxError=0.2

I've got a Specular backlight spotlight, default settings

I am using a Area Light Plane for the main light, default settings

My render settings are:
- Bucketsize=16
- MRTD=1
- Pixel Sample x=12
- Pixel Sample y=12
- shadow samples=32
- Gain=1
- Gamma=1
- Shading Rate =0.1
- Pixel Filter Width (both X/Y)=8

Am I doing anything dumb, or could do better, or forgetting? It's about a 30 minute render. Hair takes about 10 minutes of that. (I did apply UberSurface to the hair, and turned off raytracing and Occ)

Totte

Looks pretty much like what I use.

Scott Livingston

adamr001 has some render profiles here: http://www.daz3d.com/forums/discussion/16085/
What you're using looks like his "Very High Quality" profile. If you're happy with the quality and speed, I'd stick with that (I usually use something more like "High Quality"--in other words, lower quality settings than you--but then, I have a slow computer).

Totte

Scott is right there about speed (those settings works well on a 8+ core machine, can churn out renders pretty quick)

3dOutlaw

Yea, I've got an I7, but I only run it 6 cores for DS, so I can render in the background, and still use the system for other things.

It is Very Hi Quality. I will drop it to high, and see if there is a significant difference.

3dOutlaw

Using Hi Quality, dropped the render time almost in half (from 29 minutes to 16 minute): RESULT IMAGE FOR COMPARE

I can only see a slightly improved shadow (less grainy) in the dark around the neck and right arm. Not sure if its worth that extra 13 minutes?

3dOutlaw

So far, testing has shown that Shading Rate has the biggest effect on time, going under 0.2. Adam had some math that he posted last year that talked about shading rate and pixel samples, which made it seem like they were related to the amount of sampling done...

Based on that math, I was thinking that having everything consistent....using a Shading Rate of 0.1 and a Pixel Sample of 8, would be equivalent to a 0.2 shading rate and a pixel sample of 16...from a time to sample/render perspective, right? I tried both, and the 0.2/16 was almost twice as fast to render, but did not reduce shadow grain as much as a 0.1/8 setup.

Doesn't seem the Pixel Sample lends much bang for the buck, as going from 0.2 to 0.15 or so in shading rate.

I can up the shading rate to 5 and get this pic, and then lower it to 0.1 for final render. Its a difference from 3 minute render to a 30 minutes render. wow...

That fast one was:

- Pixel Sample x=16
- Pixel Sample y=16
- shadow samples=64
- Shading Rate =5
- Pixel Filter Width (both X/Y)=8

I am not finding a higher pixel sample or shadow samples is affecting render time really at all so far.

adamr001

Pixel Samples don't affect "Quality" per say. They affect the color of the pixel being rendered. They tell the Render Engine how far away in X/Y dimensions to compare the current pixel to other pixels to decide what color it should be.

Here's the dialog on Pixel Samples and Shading rate from the old thread:

Let's talk about what shading rate and pixel samples actually mean.

Unfortunately, I cannot really speak about one without speaking about the other as they're so intertwined that they're inseparable as far as I am concerned.

But here's a stab a separating them anyway:
Shading Rate - How many times to sample a given area for determining the color of a given pixel.
Pixel Samples - Number of Pixels to traverse away from the current pixel when sampling color for shading rate.

So now to talk about them together... Examples are easier so here we go!

Consider a Shading Rate value of 1.00. The DS3 Default value. At this value you're comparing 1 pixel at a time to each pixel in the pixel sample width X and Y values to determine it's color. So if you have a pixel sample width of X=6 and Y=6, you're going to sample +6 pixels on the X axis, -6 pixels on the X axis, +6 pixels on Y and of course, -6 pixels on Y. So at a shading rate of 1.00 each pixel is sampled 24 times (given a pixel sample width of 6x6) to determine it's color.

So now, let's talk about Shading Rate values of LESS than 1. Effectively, what you do is some math. Wink It really translates to sampling the same area of pixels nearby over and over again to determine the color of the active pixel. So let's take my recommended "best" setting for shading rate of 0.20.

The math goes like this: (Shading Rate * Pixel Sample X Value * 2) + (Shading Rate * Pixel Sample Y Value * 2)

When you're under a value of one though, you have to divide 1 by that value... so

At 0.20 the math works like this:
1 / 0.20 = 5
(5 * Pixel Filter Width X Value * 2) + (5 * Pixel Filter Width Y Value * 2)

So given a Pixel Sample Width of 6x6 again, that would be
(5 * 6 * 2) + (5 * 6 * 2) = 120. So that single pixel is compared against it's neighbors 120 times. That's quite a jump over the 24 comparisons it does by default.

So if you use the absolute best shading rate DAZ Studio can do (0.010), the math works out like this:

1 / 0.010 = 100
(100 * 6 * 2) + (100 * 6 * 2) = 2400

Yes, two THOUSAND four hundred samples per pixel. If you're doing a 1000x1000 pixel render, well, the math adds up. (2 billion, 400 million samples must be taken at 0.010 vs. 120 million at 0.20).

The odds of the color changing over 0.20 are pretty slim, but it might make some tiny difference. Wink It's also pretty clear why lowering the shading rate is a direct line to how long it takes something to render.

NOW, that said, there ARE reasons to use lower shading rates. Extreme displacement detail is the #1 reason to do so. This is because with extremely fine displacement, especially if it's a strong value, the pixel sample may not reach an area of the render where displacement is occurring and thus the detail is lost. This is easily seen using Pen's Fur Shader. For most products though, it's really quite overkill (imo) to set the shading rate value that small.

It also, using the text above, should be clear why an increase Pixel Samples is required to handle depth of field. Depth of Field introduces blur and blur clearly affects color and position. A larger field of pixels is needed to create a smooth blur, thus my recommendation of upping the pixel samples for DoF renders.

Such is my, more technical, understanding of Shading Rate and Pixel Samples.

Oh and Pixel Filter Width would work in a similar fashion to Pixel Samples, but applies only to the type of Pixel Filter that is being applied.

3dOutlaw

Yea, I do understand that, but based on the math above, it is talking about "samples per pixel". Whether you consider it "color" or "quality" or something else, you would assume that 24 versus 120 versus 2400 samples per pixel would affect the time to render in a similar manner. I know you aren't specifically referencing "time to render", but it is inferred that more samples per pixel is more render time.

It does, but in my render test, not equally for each parameter. Using the equation:

(Shading Rate * Pixel Sample X Value * 2) + (Shading Rate * Pixel Sample Y Value * 2)

Test 1:
Shading Rate = 0.1, Pixel Sample X/Y = 8
(10*8*2)+(10*8*2)=320
Render Time ~ 30 minutes

Test 2:
Shading Rate = 0.2, Pixel Sample X/Y = 16
(5*16*2)+(5*16*2)=320
Render Time ~ 17 minutes

Both are 320 samples per pixel, but the render time is much different. When compared to render time, Shading rate is a very exponential curve, while Pixel Sample seems very linear, with a minimal slope. Perhaps it makes more difference with DOF, but I was not testing that.

adamr001

There are lot of other variables into the equation of render time. Try this:

Using only primitives, do your test above. You'll find the render times quite similar between the two setups. Certainly nothing on the order of a 2x increase. Usually they're within 10% of each other in my testing.

The usual reason for this difference in "complex renders" is usually transparency and displacement. Since we know (from observation if nothing else) that both of these take longer to render than surfaces without them it stands to reason that sampling areas with those features more often (e.g., the same 8 pixels twice as often) would increase render time. When you go to higher pixel samples (16 for instance) some portion of that sampling may frequently extend past the transmap/displacement and thus not cause as large of an impact in render time.

3dOutlaw

OK, yea I ran that test. Very similar for a basic primitive. Loading a texture on default genesis, as well. It starts to really diverge when I use an Uber Area Light though. that's what I have in my test render, for the above. It must play into the calculation for that. Without the area light is 3 seconds...with the area light, 28 seconds. (both including a spot light, using 0.1 shading rate)

adamr001

Absolutely. When you're using a light shader like Area Lights or UberEnvironment even there's a whole new set of math that stack on top / mixes into things and really make the math hard. In fact, I've not worked out exactly how to model that math.

This is doubly true because it creates new math for the render engine to deal with. Things like a secondary set of shadow samples, occlusion samples, shadow bias, etc. all factor into the overly simplified math I stated above.

mjc1016

And to throw another log on the fire...

There are several different ways, in 3Delight, to achieve the same end result. So, depending on exactly which functions the shader is using, render times can vary greatly. So two area light shaders, written to approach emitting light from a mesh object using different means to do so can have vastly different render times with same settings.

I've been using the envlight2 (a standard 3Delight shader included in the standalone) that I converted to DS to do environmental lighting. It uses a completely different path to achieve this than UberEnvironment. I've found, on average, it to be 3 to 5 times faster to render than UE2. This is with comparable render settings...it gives nicer results at lower settings, so the boost can actually be higher.

Or another example. Shadow maps versus raytraced shadows. In the past, shadow mapping was much faster. but now with many of the recent improvements (as of 3DL10.0.70...the version in DS 4.5.1.56) they are about par (from what I've read/seen in the changelog, newer versions of 3DL may be faster at raytracing!).

A third example, using the pointcloud occlusion scripted render. Even counting the generation of the pointcloud, it is dramatically faster, than other means.

Here are two renders...

The first is UE2 Softbox 4x. It took 2 minutes 35 seconds to render.

The second is envlight2, with the same map (OmSoftbox). It took 1 minute 30 seconds...almost a full minute less and that's 'low'. In more complex scenes the difference is greater. The envlight2 shader seems to be less impacted as the complexity increases.

The render settings are the same...Pixel Samples 8; Max RTD 2; Shadow samples 32; Shading Rate 1.

adamr001

mjc1016 said:

I've been using the envlight2 (a standard 3Delight shader included in the standalone) that I converted to DS to do environmental lighting. It uses a completely different path to achieve this than UberEnvironment. I've found, on average, it to be 3 to 5 times faster to render than UE2. This is with comparable render settings...it gives nicer results at lower settings, so the boost can actually be higher.

I'd love to hear more about how you've accomplished this. :)

3dOutlaw

Me three! :)