Does anyone know why the global 'radiosity { importance <float> }' 
setting ended up in the default{} block rather than in 'global_settings{ 
radiosity {} }' block along with the other global radiosity settings(a)?

I'm likely going to dump the 'default{}' block altogether in my yuqk 
fork(b). Not much in the way of doing it - except, there is this global, 
radiosity, importance option sitting in there. It seems out of place to 
me and I don't immediately see a reason for the set up in the internal 
code...

Am I missing reason(s) it made sense for this importance option alone of 
the global radiosity settings to be in the default{} block?

Thanks.

Bill P.

(a) - Or, as one of the effective ini / flag radiosity globals?

(b) - There are too many side-effects to having 'major version defaults' 
which are not in fact fixed version defaults.

Post a reply to this message

Le 2024-01-17 à 03:29, William F Pokorny a écrit :
> Does anyone know why the global 'radiosity { importance <float> }' 
> setting ended up in the default{} block rather than in 'global_settings{ 
> radiosity {} }' block along with the other global radiosity settings(a)?
> 
> I'm likely going to dump the 'default{}' block altogether in my yuqk 
> fork(b). Not much in the way of doing it - except, there is this global, 
> radiosity, importance option sitting in there. It seems out of place to 
> me and I don't immediately see a reason for the set up in the internal 
> code...
> 
> Am I missing reason(s) it made sense for this importance option alone of 
> the global radiosity settings to be in the default{} block?
> 
> Thanks.
> 
> Bill P.
> 
> (a) - Or, as one of the effective ini / flag radiosity globals?
> 
> (b) - There are too many side-effects to having 'major version defaults' 
> which are not in fact fixed version defaults.

My guess :
importance is an object property, just like a pigment, texture or 
finish. You set it globally in the default block to set the default 
importance value to be used by most objects, and you set it per object 
to a larger value for relatively small and bright objects.

The default block is used to set some default properties for objects 
that don't have explicit properties.
Originally, it was used to set a default texture or texture component 
such as pigment or finish. It have been extended to also be able to set 
default interior, SSLT and radiosity properties of objects.

Post a reply to this message

On 2024-01-17 04:29 (-4), William F Pokorny wrote:
> Does anyone know why the global 'radiosity { importance <float> }'
> setting ended up in the default{} block rather than in 'global_settings{
> radiosity {} }' block along with the other global radiosity settings(a)?
> 
> I'm likely going to dump the 'default{}' block altogether in my yuqk
> fork(b). Not much in the way of doing it - except, there is this global,
> radiosity, importance option sitting in there. It seems out of place to
> me and I don't immediately see a reason for the set up in the internal
> code...
> 
> Am I missing reason(s) it made sense for this importance option alone of
> the global radiosity settings to be in the default{} block?

default{} is also used for textures, and I find sometimes it useful to
change the default texture as I move onto different parts of a scene.
That capability sounds useful for default radiosity importance as well,
and global_settings{} does not allow that flexibility.

Post a reply to this message

On 1/17/24 13:24, Alain Martel wrote:
> My guess :
> importance is an object property, just like a pigment, texture or 
> finish. You set it globally in the default block to set the default 
> importance value to be used by most objects, and you set it per object 
> to a larger value for relatively small and bright objects.

I think that's a pretty good guess as to how it came about. To my mind, 
it is a global radiosity setting which changes how radiosity works 
overall. Expect I'll move it to global_settings { radiosity{} } in yuqk.

> 
> The default block is used to set some default properties for objects 
> that don't have explicit properties.
> Originally, it was used to set a default texture or texture component 
> such as pigment or finish. 

Understand.

> It have been extended to also be able to set 
> default interior, SSLT and radiosity properties of objects.

No. The only options currently available within default{} are: 
texture{}, pigment{}, normal{}, finish{}, radiosity{ importance <0..1 
float> } and camera{}.

There is an open github issue requesting that default{} support 
interior{}, but it's never been implemented(a):

https://github.com/POV-Ray/povray/issues/246
Port of FS319 - Add interior to #default directive #246

No SSLT and radiosity properties have been added to any official POV-Ray 
releases of which I am aware. Maybe it's been done somewhere?

Bill P.

(a) One of the things a little clunky with v3.8 is all objects now have 
an interior{} created. I think clipka did this to support the finish 
level fresnel work which 'requires' a default ior of >1.0 (He tended to 
use 1.5 and behavior is somewhat tuned for 1.5). However, today, the 
interior default ior is 1.0 - and we are carrying around a bunch of 
interior{}s we don't need.


Aside: Somewhat on the github request #246. It should be we can use:

default { finish { ior 1.5 } }

to default the automatically created interior's IORs. However, something 
either wasn't maintained correctly over time for backward compatibility 
or never implemented correctly. I suspect an order of operations problem 
in the object post processing, but who knows. The code below works:

object {
   Iso99
   texture {
     pigment { rgbt <0,0.1,0,0.9> } finish { ior 1.5 } }
   }

object {
   Iso99
   texture {
     pigment { rgbt <0,0.1,0,0.9> } finish { ior 1.5 } }
     interior {}
   }

(yuqk is on a path to two IORs. One for interiors / refraction in the 
interior{} block. One for surfaces and reflection related effects in the 
finish{} block. Started the work a long while ago now... Someday!)

Bill P.

Post a reply to this message

On 1/17/24 22:43, Cousin Ricky wrote:
> default{} is also used for textures, and I find sometimes it useful to
> change the default texture as I move onto different parts of a scene.
> That capability sounds useful for default radiosity importance as well,
> and global_settings{} does not allow that flexibility.

The default/global, radiosity, importance value isn't propagated onto 
the objects until Parser::Post_Process() - and then only if there is not 
already an importance setting for the object - or the parent-object of 
the object. In other words, being able to change the default/global, 
radiosity, importance value while parsing is of no use. The last set 
value wins for the render.

Aside: the global_settings{} block can be used multiple times too, but 
not everything can being updated once it's set.

   global_settings { assumed_gamma 1 radiosity{} }
...
   global_settings { noise_generator 3 } // This OK
...
   global_settings { assumed_gamma 2.2 } // This ignored. Warning issued.


------------
On the default{} block I understand how handy it can be. I use it. 
However, it's not something we should continue to enable in v4.0 - 
especially if we continue to allow the shortcut texture specifications(a).

(a) - I was going to pull these in yuqk, but I agree they are handy 
enough to stay.

For a larger stable ecosystem / library of include-able stuff, we need a 
methods to access the version defaults - with 100% certainty.

Today one use, anywhere, of default{} and our #version switching is 
thereafter broken (there's a warning we have probably all seen, but...). 
And, this just one of the issues with default{}. Some I've mentioned, 
some not - like there being an issue with multiple uses of default{} 
when some exist because of (header include) +hi use.

Aside 2: I wondered while thinking about / looking at default{} how far 
back the keyword was enabled. All the way back to v1.0 it turns out!

Anyhow. Dumping default{} in yuqk / v4.0 doesn't preclude some other way 
to carry 'current' settings into created objects / textures while 
parsing. But, something new would need to be better than what we can 
already do with IDs and/or macros I think.

Bill P.

Post a reply to this message

On 1/18/24 07:12, William F Pokorny wrote:
> Aside: the global_settings{} block can be used multiple times too, but 
> not everything can being updated once it's set.
> 
>    global_settings { assumed_gamma 1 radiosity{} }
> ...
>    global_settings { noise_generator 3 } // This OK
> ...
>    global_settings { assumed_gamma 2.2 } // This ignored. Warning issued.

Mentioning the bit aboce got me thinking again about global_settings{}s. 
There are things with it too which should probably change in any v4.0.

- Maybe it should only be allowed a single use in any given scene for one.

- The global noise_generator settings is deceptive because it's mostly 
not true. The setting affects some inbuilt patterns, but not much else. 
And that global noise generator setting is problematic to any global / 
library ecosystem of include-able stuff. Work up a good agate base 
texture with the default noise_generator(a), hand it to a user who has 
changed the noise generator in their global_settings{} and that texture 
will behave differently...

- If not single use limited there are settings which should act like 
assumed_gamma in not allowing settings to be changed, which today do 
allow settings to be changed...

- In official POV-Ray releases where using subsurface that 
global_settings block needs to be specified once at the top (closely 
following #version). There's a related github issue still open.

   https://github.com/POV-Ray/povray/issues/122

- The irid settings should likely be pushed into the irid feature.

Anyhow. :-)

Bill P.

Post a reply to this message