POV-Ray : Newsgroups : povray.general : Tracking down slow renders : Re: Tracking down slow renders Server Time
10 Nov 2024 06:23:52 EST (-0500)
  Re: Tracking down slow renders  
From: William F Pokorny
Date: 10 May 2023 16:01:21
Message: <645bf811$1@news.povray.org>
On 5/8/23 18:09, William F Pokorny wrote:
> (a) - Makes me wonder if different bucketing of some of those features 
> relative to the quality level would be useful given we don't today use 
> all the values? The internal cost of the conditionals would be similar 
> (the same?), I think. It would make the quality setting different than 
> what folks are used to using. Something to think about I guess.

While taking a break from Cousin Ricky's interior id assignment crash, I 
decided to look at the idea above.

What I found is that Christoph had already worked to extend / clean up 
the quality settings up in post v3.7 code. I didn't run down when 
exactly he did the work, but it's been in place for years - 2018 or 
earlier. Meaning, what we have documented for quality levels and 
behavior is not what is in v3.8 beta 2.

For quality levels our v3.8 documentation has:

0, 1       - Just show quick colors. Use full ambient lighting only.
              Quick colors are used only at 5 or below.
2, 3       - Show specified diffuse and ambient light.
4          - Render shadows, but no extended lights.
5          - Render shadows, including extended lights.
6, 7       - Compute texture patterns, compute photons
8          - Compute reflected, refracted, and transmitted rays.
9, 10, 11  - Compute media, radiosity and subsurface light transport.

Which even in v3.7 was not quite right I know as 9 was the true highest 
quality level. Aside: 'extended lights' above means 'area lights'.


What is in coretypes.h for all recent v3.8 / v4.0 code is:

     explicit QualityFlags(int level) :
         ambientOnly (level <= 1),
         quickColour (level <= 5),
         shadows     (level >= 4),
         areaLights  (level >= 5),
         refractions (level >= 6),
         reflections (level >= 8),
         normals     (level >= 8),
         media       (level >= 9),
         radiosity   (level >= 9),
         photons     (level >= 9),
         subsurface  (level >= 9)
     {}

So, even today we can pull apart refractions / transparent rays from 
reflected rays by run time flag or ini setting. On suspecting internal 
reflections are the cause of long run times, we could set the quality 
level to 7 to test the thought.

Disclaimer. The hooks are there in the code, but I've not tested each 
v3.8/v4.0 quality level to be sure it works.


For my povr fork play (as an idea for v4.0) I'm thinking for a start 
I'll change the bucketing to:

     explicit QualityFlags(int level) :
         ambientOnly (level <= 1),
         quickColour (level <= 5),
         shadows     (level >= 4),
         areaLights  (level >= 5),
         refractions (level >= 6),
         reflections (level >= 7),
         normals     (level >= 8),
         media       (level >= 10),
         radiosity   (level >= 11),
         photons     (level >= 9),
         subsurface  (level >= 12)
     {}

and make the default quality level 12 instead of 9.

It seems to me in lumping so many of the most expensive features 
together we lose the debugging capability we can get from the quality 
level feature.

For 'quality' you do want to run media, radiosity, photons and 
subsurface together. They are tangled and affect each other.

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.