On 1/24/22 05:51, William F Pokorny wrote:
> Attached is another test image.

And attaching one more. It's the previous image, but where I've applied 
'normal { micro ... }' to the camera too.

Bill P.

Post a reply to this message

Attachments:
Download 'hmm99_cam.jpg' (82 KB)

Preview of image 'hmm99_cam.jpg'

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/23/22 10:32, jr wrote:
> > ...sky_sphere code ...
>
> Thanks.
>
> In current and future povr releases the sky_sphere emission keyword
> should instead be 'amplify'.
>
> The 'amplify' keyword being a block oriented color multiplier vector in
> povr. These multipliers exist already to some extent under different
> keyword names and where they don't I've been adding them.

no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>

which brings me to the next problem, how to write a scene so both 'povr' and the
various POV-Rays are happy?  I had hoped that the version could be used, given
the "unofficial" declaration[*], but cannot see a difference.  asking because I
use a mixture of (shell) aliases + functions and scripts like 'povr' (all
different executables) for the scenes, and ideally the emission/amplify thing
and such would be conditional.  do I have to use self-declared constants?

[*] that too is confusing.  the docs say 'version' is a float, yet in your
scenes you use "#version unofficial 3.8;".  where is stuff like that documented?
 not here:
<https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>


> No news on the -win id thing. The end of the year was both busy and
> bumpy health wise for me. Truth is I'm mostly only now getting back to
> last work left hanging last October. :-)

glad you're "back in the groove".  (I get the feeling that option is not much of
a priority.  :-))


regards, jr.

Post a reply to this message

On 1/24/22 07:36, jr wrote:
> no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
> 

As you know the povr documentation is kinda hit or miss a present - 
partly because I don't want to document while still settling on 
approaches only to need to do the work again.

The new functions as documented in functions.inc are decent, but 
otherwise....

Grepping now I see amplify mentioned some in revisions_povr.txt and 
pretty sure I added notes about it in a posting or two as well.

> which brings me to the next problem, how to write a scene so both 'povr' and the
> various POV-Rays are happy?  I had hoped that the version could be used, given
> the "unofficial" declaration[*], but cannot see a difference.  asking because I
> use a mixture of (shell) aliases + functions and scripts like 'povr' (all
> different executables) for the scenes, and ideally the emission/amplify thing
> and such would be conditional.  do I have to use self-declared constants?
> 
> [*] that too is confusing.  the docs say 'version' is a float, yet in your
> scenes you use "#version unofficial 3.8;".  where is stuff like that documented?
>   not here:
> <https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>
> 

Yeah, it's unfortunately a bit of mess since v3.7. One which clipka 
tried variously to somewhat address.

Writing from memory from earlier last year or late 2020... The 
versioning stuff is something in an awkward state and I have no idea how 
to really fix it.

Ignoring that there was a more complex versioning proposal part of 
uberpov, it was supposed to be we could write something like:

#version unofficial povr 3.8;

where the 'unofficial' keyword would STOP folks running a scene targeted 
for some particular unofficial release in an official release of POV-Ray.

I have no idea why unofficial is not itself documented. It's been there 
a long time. Maybe because there was a worry folks would add it to 
regular POV-Ray scenes or something... I think it should be documented.

My 'assumption' is official window's releases do stop cold on seeing 
'unofficial', but I don't run windows - so I don't know.

The non-windows stuff is compiled by other people whether individuals or 
by package providers. Those releases are ALL unofficial though probably 
today the majority in use. In such releases you only get warnings where 
an unofficial keyword is used. Stopping cold would probably be better 
for at least the distribution provided packages.

The 'povr' or whatever token was supposed to be a hook upon which 
conditional stuff could be done in the SDL. You can still see this form 
of versioning if you look say at:

http://megapov.inetart.net/samples.html

Unfortunately, and guessing some, it seems we at some point (v3.7 ?) 
broke the ability to indicate the branch token and this state of affairs 
exists in many recent official releases of POV-Ray proper...

So, where you see me using only:

#version unofficial 3.8; // povr

in example povr scenes I post or ship, it's because creating a warning 
about the SDL using 'unofficial' is all I can reliably do to warn people 
it's unofficial SDL code for povr.

> 
>> No news on the -win id thing. The end of the year was both busy and
>> bumpy health wise for me. Truth is I'm mostly only now getting back to
>> last work left hanging last October.:-)
> glad you're "back in the groove".  (I get the feeling that option is not much of
> a priority.  :-))

Eh, I don't know. Pretty much all of the pfm rtr frame snap shot 
capability and actual cycle control was done with a -win capability in 
mind. The work just got dropped along with everything else.

Unfortunately it's really painful once you are out of the coding 
"groove" to get back in it. What was I thinking months back? Where did I 
put those files? Oh yeah! They're in that jr_causing_trouble directory. 
:-)

Bill P.

Post a reply to this message

Op 24/01/2022 om 12:31 schreef William F Pokorny:
> On 1/24/22 05:51, William F Pokorny wrote:
>> Attached is another test image.
> 
> And attaching one more. It's the previous image, but where I've applied 
> 'normal { micro ... }' to the camera too.
> 
> Bill P.
> 

Haha! That's Cooky Monster looking back at you!

-- 
Thomas

Post a reply to this message

Op 24/01/2022 om 11:51 schreef William F Pokorny:
> On 1/23/22 07:49, Thomas de Groot wrote:
>> Very nice one! More images should "fall out"...
> 
> Thanks! :-)
> 
> It's on my todo list to aim more often for more complex images! For 
> whatever reason I always drift back into chasing things in the code.
> 
> Attached is another test image. The one where I first turned up the 
> POV-Ray issue with 'too large for our exr reader' channel values in the 
> exr HRDI sky_sphere file.
> 
> The three spheres are using different normal 'micro' pattern bump sizes. 
> Further the scene uses povr's intensity_max control in both the 
> reflection block and with the metallic in the overall finish block. The 
> latter keeps all the reflected colors in a 0-1 channel range where the 
> AA still works.
> 
> Most puzzling to me is the upper left sphere where I made the micro 
> bump_size large (1.5 I think). It happens once bump_size values get over 
> the usual 0.5 limit where normals can start to invert in one or more of 
> the x,y,z directions due the perturbation values being so large compared 
> to the raw normal values(a). Where perturbed normal inversions occur, 
> the result starts to look more like a milky glass. I don't completely 
> understand why...
> 
> Bill P.
> 
> (a) Only a few of povr's normal patterns prevent such inversions - and 
> micro doesn't.

That milky glass effect is quite nice imo, while the lower right sphere 
seems strongly overdone. Food for thoughts... especially the milky glass.

-- 
Thomas

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/24/22 07:36, jr wrote:
> > no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
> ...
> Grepping now I see amplify mentioned some in revisions_povr.txt and
> pretty sure I added notes about it in a posting or two as well.

yeah, my memory..  :-(


> > ..."#version unofficial 3.8;" ...
>
> Yeah, it's unfortunately a bit of mess since v3.7. One which clipka
> tried variously to somewhat address.
>
> Writing from memory from earlier last year or late 2020... The
> versioning stuff is something in an awkward state and I have no idea how
> to really fix it.
>
> Ignoring that there was a more complex versioning proposal part of
> uberpov, it was supposed to be we could write something like:
>
> #version unofficial povr 3.8;
>
> where the 'unofficial' keyword would STOP folks running a scene targeted
> for some particular unofficial release in an official release of POV-Ray.
>
> I have no idea why unofficial is not itself documented. It's been there
> a long time. Maybe because there was a worry folks would add it to
> regular POV-Ray scenes or something... I think it should be documented.

if asked, and if written as above, I'd suggest introducing 'unofficial' as a new
built-in variable which only exists if the keyword was used.  it could contain
the id string, allowing something like:

#if (defined(global.unofficial))
  #if (!strcmp(unofficial,"povr"))
  ...
  #end
#else
  ...
#end

aside - 'povr' emits a warning when I use unofficial, the 'beta.2' simply
ignores it :-).


> >> ... the -win id thing ...
>
> Eh, I don't know. Pretty much all of the pfm rtr frame snap shot
> capability and actual cycle control was done with a -win capability in
> mind. The work just got dropped along with everything else.

have only used the snapshot setting a couple of times, to try.  found that
'convert' works just fine, no need for the "i version" ('file' too recognises
them).

I am hoping that your (+ JG's) work on the X window handling, and the "-win
thing" perhaps, will appear in POV-Ray proper (and before the heat-death of the
universe, ideally :-)  is anyone working on 'beta.3'?).


> Unfortunately it's really painful once you are out of the coding
> "groove" to get back in it. What was I thinking months back? Where did I
> put those files? Oh yeah! They're in that jr_causing_trouble directory.
> :-)

</grin>  (must weigh Gigabytes, by now ;-))


regards, jr.

Post a reply to this message

On 1/25/22 02:14, Thomas de Groot wrote:
> Haha! That's Cooky Monster looking back at you!

:-) Indeed. Those do look like eyes...

Bill P.

Post a reply to this message

On 1/25/22 02:21, Thomas de Groot wrote:
> That milky glass effect is quite nice imo, while the lower right sphere 
> seems strongly overdone. Food for thoughts... especially the milky glass.

Agree, though, I still don't get what all is happening there to get the 
milky effect. On the overdone sphere - remember I'm testing limits not 
going for any given look. Even the milky effect I found by using bump 
sizes larger than what I think most would / should typically use in 
practice.

I'm thinking some of the milkiness is coming from getting less overall 
reflection because some of the normals are inverting and some not - some 
we see more of the metallic effect in the result. More of the raw color 
shows through.

The reflections which are there are no longer fuzzy though, which has me 
puzzling. A significant number are pointing away / against the raw 
surface normal sphere rather than mostly being aligned. Guessing we are 
hitting some limit where maybe the perturbed normal gets ignored or 
something except maybe for being inverted. I don't know! I'd have to 
spend more time in the code to figure it out. The question is rattling 
around up there in my empty space - maybe the reasons will fully come to me.

I'll attach another image using again the milky effect, but on three 
star mesh include stars. Appropriate given Mike-the-elder was about on 
these newsgroups again recently after years away. His star mesh code / 
and version of it, I've used quite a bit over the years. Anyhow, the 
milky look is a little different than with the spheres I think, the 
environment is different too...

Bill P.

Post a reply to this message

Attachments:
Download 'hmm88.jpg' (84 KB)

Preview of image 'hmm88.jpg'

On 1/25/22 03:37, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/24/22 07:36, jr wrote:
>>> no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
>> ...
>> Grepping now I see amplify mentioned some in revisions_povr.txt and
>> pretty sure I added notes about it in a posting or two as well.
> 
> yeah, my memory..  :-(

Mine too. With changes like this I have a few places put in parser 
checks which generate more specific errors. For example, reflection now 
supporting only reflection blocks, but it's work and it happened in the 
reflection case mostly because the code was more or less there to do it 
even with a code comment it was the old form and that it was going away. 
It just wasn't generating an error yet though it looked like someone had 
set up to do it at some future point.

I'd like to make the differences easier to handle, but, it really comes 
to not knowing how to do it in the tiny amount of resource I have/want 
to spend on it.

I've been thinking about creating more documentation from the code base 
itself now that I understand it better, but not gotten to trying it.

> 
> 
>>> ..."#version unofficial 3.8;" ...
>>
>> Yeah, it's unfortunately a bit of mess since v3.7. One which clipka
>> tried variously to somewhat address.
>>
>> Writing from memory from earlier last year or late 2020... The
>> versioning stuff is something in an awkward state and I have no idea how
>> to really fix it.
>>
>> Ignoring that there was a more complex versioning proposal part of
>> uberpov, it was supposed to be we could write something like:
>>
>> #version unofficial povr 3.8;
>>
>> where the 'unofficial' keyword would STOP folks running a scene targeted
>> for some particular unofficial release in an official release of POV-Ray.
>>
>> I have no idea why unofficial is not itself documented. It's been there
>> a long time. Maybe because there was a worry folks would add it to
>> regular POV-Ray scenes or something... I think it should be documented.
> 
> if asked, and if written as above, I'd suggest introducing 'unofficial' as a new
> built-in variable which only exists if the keyword was used.  it could contain
> the id string, allowing something like:
> 
> #if (defined(global.unofficial))
>    #if (!strcmp(unofficial,"povr"))
>    ...
>    #end
> #else
>    ...
> #end
> 
> aside - 'povr' emits a warning when I use unofficial, the 'beta.2' simply
> ignores it :-).
> 

Something like that is a good idea. And thanks for reporting the warning 
only being there for povr. It looks like the current v4.0 master code 
has just:

#if POV_RAY_IS_OFFICIAL
         Get_Token();
         Error("This file was created for an unofficial version and\n"
               "cannot work as-is with this official version.");
#else
         // PATCH AUTHORS - you should not enable any extra features
         // unless the 'unofficial' keyword is set in the scene file.
#endif

in Parse_Version(...) where I have a warning in that #else. Maybe 
something I just did at some point? Or maybe I picked up something now 
gone in the official branches? I don't remember...

I just ran an old megapov scene in v3.7 and v3.8 beta1 (my beta 2 
testing was on my raspberry and I'm not on it at the moment). With both 
there parser dies with:

File 'area_light_refl.pov' line 16: Parse Error: Expected 'numeric
expression', undeclared identifier 'megapov' found instead...

which isn't as informative as it could be, but guess I like that the 
parsing dies up front on something that isn't going to work anyway.

I think that Get_Token() in the '...IS_OFFICIAL' branch might be to pick 
up tokens like 'mega_pov' or 'povr' and generate instead the error 
message. Maybe given the existing branches have empty warning branches I 
can just do want I want for povr in the else...

I'll look at your idea today and see if I can make something work for 
povr.

> 
>>>> ... the -win id thing ...
>>
>> Eh, I don't know. Pretty much all of the pfm rtr frame snap shot
>> capability and actual cycle control was done with a -win capability in
>> mind. The work just got dropped along with everything else.
> 
> have only used the snapshot setting a couple of times, to try.  found that
> 'convert' works just fine, no need for the "i version" ('file' too recognises
> them).
> 
> I am hoping that your (+ JG's) work on the X window handling, and the "-win
> thing" perhaps, will appear in POV-Ray proper (and before the heat-death of the
> universe, ideally :-)  is anyone working on 'beta.3'?).
> 

I'm not aware of any v3.8 beta work presently, but the github repository 
wasn't the only one. There exists some more private ones some of which I 
was aware, but I never knew much of anything about those. The developer 
mailing list has been quiet for a while - supposing I'm still connected 
to it and it's working. Some of the windows support always got done 
somewhere else as a dll I think, the documentation too. There is 
somewhere a repository or two for moray code where work seemed to start 
a few times, but then die out. There is active Blender interface work 
some of which is posted about here. All I know.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> The reflections which are there are no longer fuzzy though, which has me
> puzzling. A significant number are pointing away / against the raw
> surface normal sphere rather than mostly being aligned. Guessing we are
> hitting some limit where maybe the perturbed normal gets ignored or
> something except maybe for being inverted. I don't know! I'd have to
> spend more time in the code to figure it out. The question is rattling
> around up there in my empty space - maybe the reasons will fully come to me.

If you have a "+" normal, and a "-" normal of the same magnitude adjacent to one
another, does the intermediate region get interpolated, and therefore the two
normals cancel?

Perhaps if you apply AOI or SLOPE pigment patterns, you can pick up "flat"
regions on the surface?   Maybe that's somewhere that your RAW thing will help?


Just guessing.

Post a reply to this message