Le 2023-05-10 à 16:01, William F Pokorny a écrit :
> 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.
> 
> 
> 
> 

 From my experience, when using +q0 to +q3, transparent pigments do show 
as transparent. Both filter and transmit.
Then, from +q4 to +q7, anything transparent shows as black, for any 
pigment and any amount of filter or transmit.

Post a reply to this message