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