William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/21/23 15:42, Bald Eagle wrote:
> > I looked in the distro, and it appears that we're missing an example scene for
> > this feature.
>
> .../textures/pigments/irid.pov

Oh, right - I forgot about that - I had found that, looked at the rendered
thumbnail, SDL code, and it just wasn't what I was looking for - so I mentally
discarded it.

It was also hard to find, since clipka moved it into the finish {} block, so
that's where I was looking.

> I'm no expert, but looks like you've figured things out from your most
> recent post.
>
> Aside: I've never had much luck setting diffuse to larger values as you
> recently, elsewhere suggested - and as suggested by others in the past.
> With most finish{} contributions, you have to leave room in the totaled
> 'color response' for the finish contributions for them to be seen. Room
> before the totaled color contributions turn white (in most outputs).

That could certainly pose a challenge for many people.
It wouldn't be a bad idea to:
1. Put something in the docs about that.
2. Have a better example scene, with some code commentary to that effect
3. Have a ready-made drop-down insert menu code snippet
4. move (or add) the example code to the finish subdirectory

Also, since it's not a feature that seems to enjoy extensive use, perhaps
consider issuing a warning when irid {} gets implemented in a texture statement
with a high diffuse value. (What is the function range of irid, anyway?}

Also, that seems to be a fairly frequent problem when implementing features with
values that can overrun the 0-1 range.
We have a lot of nuisance warnings in the code like suspicious color value after
rgb, and the scaling by 0 one, so maybe a "rgbft value out of range" warning
might help debug some of the less-obvious problems.

Aside from the future modification of source code, maybe there's a way to make
some example scenes, or a spreadsheet or something, that would help illustrate
the domains and ranges of functions/algorithms/features of POV-Ray and allow the
user to graph their potential interaction and flag problems.

(having the rgbft values visible in some way to SDL would be an interesting
feature too.  Not sure how that could be implemented, since that would be a
surface phenomenon wrt patterns and light-source dependent features like aoi,
irid, etc.  It would also have to be a render-time implementation.  All I can
think of is maybe enable a feature whereby flagged value pixels gets rendered
differently, or logged to a render stats text file, or.....)

Yes, POV-Ray is a raytracer, but as we know, people use it for way more than
that, esp in the math and science communities.

- BW

Post a reply to this message