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

On 1/25/22 08:39, William F Pokorny wrote:
> I'll look at your idea today and see if I can make something work for povr.

OK.

I spent some time looking at testing whether some keyword is defined. 
It's a tangle.

The short of it is the v4.0 master branch and the povr branch look like 
they can actually do something like:

#ifdef (sphere)

or

#if defined(sphere)

Though you currently get a warning, "...results might not be what you 
expect...", it appears to work in that an option would be to test for a 
povr only keyword say and then run that keyword and have it return povr 
information on versions or whatever.

Unfortunately, it appears this work-ability is part of the later parser 
work clipka was doing. He backed well off those parser updates for the 
v3.8 release. Plus, I fully expect earlier POV-Ray versions do not 
handle testing whether keywords are defined(a).

(a) - Just v3.8 support would have worked for povr as it's strictly a 
v3.8+ branch.

---

The only thing I've come up with, which I think might work, would be for 
povr to re-use a function its currently eliminated in 'f_odd()'.

The function was always useless in that it was, code wise, a duplicate 
of f_cushion. I suspect it was perhaps a place holder for some sort of 
odd / even testing or similar that just never got done.

My thinking is that povr - or any other non-official and substantially 
different - version of POV-Ray could return some unique double value 
given a particular set of inputs. We'd use maybe certain sets of inputs 
for various derivatives. The current inbuilt function would return what 
it returns. The povr branch or others would be hard coded to return some 
other value which would mean something like: This the povr branch and 
the version is, and it's Monday, or...

Would using f_odd() in this way be useful or not? It's all I've got for 
options at the moment.

I kept thinking we need a time machine. Go back to v3.0 and stick in a 
few parser functions which were simply made available to various patch / 
derivative authors to return whatever they wanted for strings and values.

Bill P.

Post a reply to this message

On 1/25/22 16:15, Bald Eagle wrote:
> 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.
> 

Yeah, that's a thought. I didn't really think about the normal 
components potentially canceling and going to zero. It could happen, but 
I'd say not all that often - but maybe there is some clamping or cut 
offs somewhere in the code that get us to zeroing.

Using aoi a good thought too! The povr aoi pattern doesn't cut off like 
the official POV-Ray one does where the normals point away. I made this 
change so folks can to a degree see any perturbed normal inversions - 
they can run something to see at what bump_size they have a problem.

Any recent POV-Ray release support blend maps with arbitrary negative to 
positive ranges internally. Unfortunately, without changes like those in 
povr, one can't make use of the capability. Something to try.

Bill P.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> running into a different problem with 'povr_6e4ed6c2', the sky_sphere code was
> originally copied from the docs, and the image renders fine with 'beta.2':
>
> File 'o22.pov' line 207:
> Possible Parse Error:
> Unmatched {
> File 'o22.pov' line 217:
> Parse Error:
> No matching }, emission found instead
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> 206
> 207 sky_sphere {
> 208   pigment {
> 209     gradient y
> 210     color_map {
> 211       [.5 color rgb <.74902,.847059,.847059>]
> 212       [1  color rgb <.258824,.258824,.435294>]
> 213     }
> 214     scale 2.5
> 215     translate -1
> 216   }
> 217   emission rgb <.825,.825,1>
> 218 }
> 219
>

[running v3.8.0 beta 1 in Windows 10]
It parses and renders OK for me as well.

But that example in the docs is a rather strange one, IMO-- only because the
explicitly-given 'emission' color *changes* the color_map's colors.

The docs say that the intended(?) result of the example is this:
"This gives a soft blend from CornflowerBlue at the horizon to MidnightBlue at
the zenith."

But not so; the given emission component values are simple multipliers, and
produce a slightly different color. I have never actually used an explicit
'emission' for a sky_sphere; it's the common understanding that it is set to 1.0
behind-the-scenes as a default (so that the sky_sphere's colors are successfully
used in radiosity, for example).

BTW, I find it interesting that the sky_sphere syntax does not accept an actual
finish{...} block, like...

     finish{emission rgb <.825,.825,1>}

.... even though it does accept a pigment{...} block.

Post a reply to this message