Brute force Test Very slow :(

I tested Brute force and LC settings from another thread on a static scene with camera movement only, that I am currently working on.

Below video has been rendered by precalculating the IR and LC. The frame times were roughly 30-60mins deepening on sequence.

But I thought I would test same sequences using brute force and LC method and render times we 4x slower and more noise :frowning:

Dont know if this is normal, or I am doing something wrong :frowning:

https://vimeo.com/204018032/bbd7a31eb8

can u upload the BF version too?

nice animation.

are you using vray 3.4/3.5?

post up your settings.

I often have to deal with IR+LC when I have some interior to do… Frequently, I can’t have a good ratio between render time/quality when I try to use BF+LC.
However, I would love to definitively avoid IR !

I will try with vray 3.5 ASAP.
Anyway, I am interested in any information about it

Thank You!

I rendered the whole animation in 3.4, but I have been testing stills in 3.5.

I rendered a region of this still to demonstrate.

With ‘Brute force’ the region took ‘30 minutes’ and with ‘irradiance map’ it took 13 minutes. As you can see from example below brute force took twice as long and has clearly a lot more noise.

The Brute force settings I used were as below: all I did when I rendered the irradiance map version, was to swap brute force for irradiance map and set to medium and 60/40.

I wanted to render/animate the doors opening perhaps sun change direction, but as the precalc takes so long with animation pres pass. I wanted to look at the brute force method. But from tests frames times are 2/3/4 times slower and a lot noisier.

I rendered this a couple of years ago with animation pre-pass and brute force and that seemed to work well, but again the precalc took ages to complete.

https://vimeo.com/willmorris/3dhouse

If I am doing something wrong It would be great if someone could let me know? or if this is usual when using brute force and light cache.

Thanks again

Will



the only thing i notice is that you have the Noise Threshold set quite high for the image sampler…
i’d reduce that to at least 0.01, i’d also increase the Max Subdivs to say 24 and reduce the bucket the width to 16…

might be worth rendering a sample rate pass as it will give you a bit more information as to whats going on…

Thank you for your reply.

I tried dropping the clr threshold to 0.01 but render times increased (1h 30mins), so i kept it at 0.02 and I upped the subdivs to 40. changing bucket width has helped.

I know i shouldn’t but i switched on subpixel mapping and clampout and that made the render a lot lot quicker.

I got the frame times down to roughly 1 hour at 1920x1080, which is a balance with a little bit of noise. there is a lot of reflection, grass and trees. I am rendering a small 150 frame camera pan with the glass doors opening

I have no idea if that is reasonable? or still excessive? but it seems to be the best balance.

the noise is fine everywhere else except on the white walls and ceiling any ideas why that is?


May I ask what HDRI you are using? Or what color workflow (gamma, color settings). Interesting interior has almost same brightness as exterior.

Hello,

I am using two of Peter Guthries HDRI’s 1044(overcast) & 1853(low sun). Settings are fairly default IR+LC. Gamma 2.2. Reinhard 0.1.

The interiors I used the overcast hdri, hence why there may not be a lot of contrast between inside and out. Do you think it looks incorrect?

Another guess - is your image properly exposed through the camera and without applying any adjustments in VFB/post? If it’s underexposed and you boost the brightness artificially in VFB or post, you’re boosting the noise too.

In your BF + LC version you have AO switched on under GI. This increases the render times. BF is already accurate and works out correct contacts and there’s no need to add additional AO

yep def switch that off - i missed that..!

Thanks for your replies.

Your right my image is a little under exposed which I was going to boost in post, which i not going to help with the noise. Will tweak camera settings.

Oh yes didnt think to turn off AO, your right that is probably is affecting my render times. I will do a few tests.

I rendered these few frames last night with previous settings, its fairly clean with no flickering. I do love the fact there is no fussing with any precalc. BF+LC…render.

Frame times 1 hour per frame on my Dual Xeon (32 threads) and 3 HOURS on (8 thread) render farm machines:roll:

https://vimeo.com/204510261/5228d0f055

Just did a quick test and I also just found out dropping the shading rate from 6 to 3 has also made a huge difference to render times. tbh…not to sure why.

What GPU’s do you have? Might be worth giving RT GPU a try if you have something modern

Hi,

The Sampler Rate is glowing pretty hot around the trees. Are you using opacity maps on the leaves?

I could bet you have issues with your setup, which the IRMap masks, helped by the severe highlight burn in your Rehinard CM.
In between your shader Albedos (call it average brightness) and the lights fixtures, what you are creating is a non-decaying light field, which in turn creates noise (in other engines, it’d be fireflies, in others still it’d be so stupidly clamped you wouldn’t notice anyway), which in turn needs samples to be cleaned up.

Mandate number 1 of the “new” method is a settings reset, and *without changing a thing* setting the LC up as instructed.
So do that first, make sure you don’t calculate an AO on top of a BF render that way (that was put there a decade ago to hide the mess of the IRMap, it’s not only useless, but detrimental to render with BF/LC), stay in LWF (again, Optimised Defaults!), and recalibrate your shaders and lights to match the real world counterparts at best you can: look up light fixture specs, and copy them on your lights,find read albedo tables for material classes (you won’t for specific ones!) and try and aim for a diffuse+reflection in the shaders to be in that ballpark, often a *lot* lower than people realise (f.e. most glasses have 7-12% max total reflectivity.).

I’ll never tire of saying this: if you depart from LWF, you are very likely to be chasing your own tail.
Not only is LWF the only mathematically correct way to go about it (the radiometric equations expect a linear setup to be able to distribute light properly!), it’s also the *only* way to ensure that doing something to your shaders and lights in the max UI will produce *exactly* the expected result (double a light’s intensity in the max UI, the rendered intensity will exactly double…).
Any other color mapping setup will result in changes made to lights and shader reflect with a skew on your renders (you bias the solution, in fact, and quite severely so), and so you’re left with lights which shine less than they should, and keep raising their intensity for little to no effect, which is then compensated through shaders being brighter, exposure being higher, and contrast, along with a proper light distribution, go out of the window.
To bring back the lost contrast, cue in the 15 years old AO, which made sense before LWF was fleshed out, and per-pixel, multi-sampled, Brute Force solutions were few, not very advanced, and supremely expensive to compute, but should really only be relegated to some obscure post-work, or a data pass of sorts, these days.

TL, DR: Reset your Settings, make sure you stay at the Optimised Defaults the reset provides you with, and reconsider your scene shaders, lights and exposure settings under LWF, before rendering again for final.

Hi Lele, can you explain a bit about what you mean by total reflectivity? Is it diffuse + reflection?
For your glass example, assuming we use black as diffuse and the only reflectivity is specular, this translates to simply using pure white as Reflect color and setting the Fresnel value to 1.72 ~ 2.06, giving us reflection values of 0.07~0.12 at 0 degree incidence angle. It actually seems exactly what most people would use as their settings for glass.

For more complex shaders that actually have a diffuse component, this would mean the basic workflow that goes something like this: find albedo and fresnel ior of said material, then [albedo - specular reflections at 0 deg inc.angle = diffuse value] Adjust diffuse texture to have it’s average brightness value match this number (don’t forget to correct for srgb gamma)

does that make sense at all?

This, along with some examples, could clear up a whole lot.

It’s entirely my fault.

I spent a wee bit of time with hundreds of VRScans, profiling their measured response in RGB in a way which returned the exact albedo value (as Normal fraction, or 0.0-1.0, or %, as you wish to read it) at each incidence angle (more precisely, i sampled it at 10 bit, or 1024 samples across the 90 degree angles), and then we all got lost into other stuff, and I personally never came around to preparing the post.

I’ll sync with the VRScans team and see if we have fixes for some old issues in place, and the latest advancements made available, and if not, i’ll post some of the usable ones anyway.

As for the reflectance, i speak of the maximum reflectance (so yes, for glass at 90deg.), not the minimum one.
Eyes are often not enough to perceive it (damned, or blessed, be the log-like perception), but reflecting 15% of the sky/sun albedo is a heck of a lot of energy shot back.
When we use higher total reflectance, in the real world, we tend to make the surface rough enough to diffuse it (ie. plaster/paint), or if not, it turns exceedingly shiny (mirrors, and coats, over said glasses!).
Notice that mirrors for massive telescopes approach 95% reflectance (and more if and when they can!), while a house mirror with an aluminium back and a thick-ish glass on it will likely be in the 75% range, partly due to the non-smooth surface at micron-scale (aka: gloss at 0.975 or something. Old mirrors will well diffuse farther objects.), and partly due to the glass absorption.

So, as a general guideline, one should start with very low overall albedos, typically even lower than one would think plausible (white cloth at max 0.6f ? check!), and one will soon find out that going up from a too low albedo is quicker to iterate (faster GI/Caustics!), and much more controlled and pleasant to the eye (too low albedo leads to high contrast, which slowly recedes as one nails the ranges), than doing it the other way around: because of light not extinguishing, and various skews, rendertimes explode, and contrast typically is nowhere to be found, and super hard to retrieve.

Attached, you can see a few of those measurements: X is the angle from view, 0 to 90Deg., Y is the albedo, the curves are conveniently in R, G and B (but may be overlapping in places.); the left Sphere is the “Average Symmetrized” BTF mode used to measure the response, the right one right the full BTF, albeit likely off-scale (as the script didn’t adjust the UVs to the sample size, my mistake.), and of course, it goes without saying that the measurement was done properly, no inter-reflections, or coloured light. These renders are for display of the results only.

Notice how the curves are quite characteristics of the type of material response, with a diffuse-like paint displaying darkening at grazing angles, while a coated carpaint will show the expected grazing accentuation of reflectance (to 70% or so!), a White Matte carpaint showing the same-ish behaviour as a wall paint, and a mirror construction can be even inferred from its curves, in this case likely a poor quality, very absorbing glass on top of a poor reflective substrate, to produce said ~75% maximum reflectance, and showing the glass’ high absorption, and lack of grazing-angle reflectance, as the view gets shallow.

p.s.: in theory, if you replicated those curves in a falloff map, you’d get identical results (to the left sample!).