SU Podium Forum
Sign up  |   |   |  Calendar  |  Latest Topics
 
 
 


Reply
  Author   Comment  
splatcreativeau

Registered:
Posts: 36
Reply with quote  #1 
Hi guys. After several test renders done using the exterior preview setting, I was happy with everything. They were just a little too grainy to use.
But the final render, using the exterior default setting, produced the lighting issue  shown (on the stairs). A bit frustrating after a 6 hour render time.

Any ideas why this would happen?

(Incidentally, I have not experienced any more of that weird texture issue I reported recently. Appears to be only that one file, and that job is finished, thankfully.)

Pool area visualisation - dwg 4B-Podium 2018-01-11 19311500000.jpg Pool area visualisation - dwg 4B-Podium 2018-01-11 18084100000.jpg

An update on my issue:
Subsequent to this, I have gained the same unwanted result using the normal "default" setting, but have been successful using the exterior high preset. However, calculating on the time taken to render this small test image, it will take in excess of 50 hours to create an image of the required size 1920x1080.
It is not a massive image at 267014 faces, and there are no errors reported.
Any tips on this part?

bigstick

Avatar / Picture

Moderator
Registered:
Posts: 10,646
Reply with quote  #2 
It's difficult to comment on the render time without seeing the model.

The blotches are caused by sampling errors created by the normal, biased (i.e. non QMC) presets.
The way the normal presets work is to take a scene and calculate an initial map of light distribution based on a series of randomly-assigned cells which result from a fixed number of photons fired into a scene. These cells are much larger than individual pixels, and their density across the scene varies. There are more cells where there is a greater change in contrast, and fewer on large blank areas. Typically you will find cell density highest in corners. The light distribution in each cell is considered to the the same, and the illumination is blended/smoothed/interpolated between cells.

If you look at the pixels in the last image above the lights, you can see that immediately above each light is a shadow, where the light from the fitting hits the floor, bounces up, and illuminates the wall, but the wall immediately above the fitting is in shadow.

The initial light pass has identified that there is light above the fittings, but there aren't enough cells to identify the extent of the shadow. There are dark blotches, which may be dark shadow samples, or may just be errors where the calculations try to reconcile lighting that isn't accurate.
The majority of the area above the light is treated as bright, so this creates the effect you have. Where you have overly-large cells with a dark sample next to some with a light sample, the algorithm has a lot to try and work out!

The default presets are tuned to try to produce fast but high quality results for the majority of scenes, and generally they work fine. They have a preconfigured number of photons and final gathering rays fired. If the first pass isn't accurate, there is no way to add more refinement or samples. We have to try to balance speed and quality with reliability. If we fired more photons or more final gathering rays, we would get a more reliable, higher quality image, but every scene would take longer to render. If the first pass isn't accurate enough, you get blotches like in this image.

The High presets add an extra final gathering pass which subdivides the first set of cells, to calculate a more accurate and refined image. Typically this increases render time significantly. It won't double render time, because that assumes that every cell is divided into two more detailed sub-cells. In reality each cell may need to be subdivided into maybe 5 or 10 smaller sub-cells, which means that render time can be increased five-fold, which explains the increased render time.

Because of the selective sampling in specific areas in the image, render algorithms that work this way are called 'biased'. The render algorithms that we use mostly are called 'photon mapping with irradiance caching'.

This entire approach is problematic, because it relies on having enough samples to create an accurate image, and sometimes, even with the High presets, there still aren't enough samples, and there are still blotches.

The QMC presets use an algorithm called 'path tracing'. This traces the path of a fixed number of photons in a scene, and calculates the illumination at every pixel. This is much, much slower, but easier to configure.

Some render engines use a variation called 'progressive path tracing' where once the fixed number of photons has been calculated, more and more photons are fired into the scene to refine it continually, and technically the render could never complete. The image is saved while the render is in progress. This creates the most accurate renders, but the slowest.

Our QMC presets only fire a fixed number of photons into a scene, so that the render completes.

Just for interest, the algorithms in the biased presets fire photons into the scene at random, in a technique known as 'Russian roulette' sampling. This means that every render of the same scene is different because the distribution of cells is different every time.

QMC stands for Quasi Monte Carlo, which is a mathematical sampling method used in the algorithm.

What does the dialog show if you run the Analyse model tool - the spanner/wrench icon.

I suspect that it's the combination of 3d plants with lots of leaves together with artificial lights that is creating the long render time. If the leaves have a slight amount of reflection applied, that will kill your render time.



__________________

That which does not kill us makes us stronger
-Friedrich Nietzsche

splatcreativeau

Registered:
Posts: 36
Reply with quote  #3 
"Be careful what you wish for" - so the saying goes!
Thank you for your concise, and for me insightful, explanation of the process. It is somewhat calming to understand the limitations / extents - in a basic way at least. I (and others I am sure) appreciate the time you have taken.
With this new found understanding under my belt, I approached the issue in a different (and it seems in this case, perhaps a speedier) way. 
I rendered the image in 2 parts - removing the trees, etc that were bogging it down and using the QMC preset for the other areas. Then blended the images in Photoshop. 
You are welcome to criticise. Pool area visualisation - comp 1.jpg 

bigstick

Avatar / Picture

Moderator
Registered:
Posts: 10,646
Reply with quote  #4 
That's better - it has a really nice atmospheric feel!

How long did the renders take?

Another couple of points you may find interesting;

1. The Russian roulette sampling method is why we can't use the non-QMC presets to create animations - you end up with flicker on the surfaces caused by subtly different light distribution. PodiumWalker GPU doesn't have this limitation, because it uses a biased render algorithm, however for good performance it needs a great big mofo of a GPU, and only an Nvidia one at that. And it's Windows only...

2. There is a method which allows us to cache the samples for subsequent renders, so that each lighting is identical, and has the benefit of accelerating the render process because one of the passes is pre-calculated. However the problem this creates, is when we might need to recalculate the lighting, for example if your animation is to transition from inside to outside. it's a similar issue to Render All or Generate All - they all use the same preset.



__________________

That which does not kill us makes us stronger
-Friedrich Nietzsche

Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.