In the last few days I got to creating an official normal block 'micro' 
perturbation only pattern from the initial 'bevy 9' playpen code(a). 
Attaching an image that fell out while testing.

(a) - There is a bug in how the 'x' directions are handled in the 'bevy 
9' shipped with the povr branch tarball back in October. I didn't pick 
it up with my initial test cases...

Bill P.

Post a reply to this message

Attachments:
Download 'microreflectionplay.jpg' (77 KB)

Preview of image 'microreflectionplay.jpg'

Op 23-1-2022 om 12:38 schreef William F Pokorny:
> In the last few days I got to creating an official normal block 'micro' 
> perturbation only pattern from the initial 'bevy 9' playpen code(a). 
> Attaching an image that fell out while testing.
> 
> (a) - There is a bug in how the 'x' directions are handled in the 'bevy 
> 9' shipped with the povr branch tarball back in October. I didn't pick 
> it up with my initial test cases...
> 

Very nice one! More images should "fall out"...


-- 
Thomas

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... Attaching an image that fell out while testing.

no idea what I'm looking for, or at, but it is "pleasant to behold".  :-)


> (a) - There is a bug in how the 'x' directions are handled in the 'bevy
> 9' shipped with the povr branch tarball back in October.

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


also, I'm currently playing with some code where I frequently use the rtr
feature to get a quick "all-round" look at an object, and it works beautifully.
so good in fact that I'd love to be able to put that preview in a frame in a
frontend, any news on the '-win $id' thing?  :-)


regards, jr.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> In the last few days I got to creating an official normal block 'micro'
> perturbation only pattern from the initial 'bevy 9' playpen code(a).
> Attaching an image that fell out while testing.
>
> (a) - There is a bug in how the 'x' directions are handled in the 'bevy
> 9' shipped with the povr branch tarball back in October. I didn't pick
> it up with my initial test cases...
>
> Bill P.

To me this looks close to just as cute as the cutest cat ! Any chance of such a
feature ever making it to main POV master ?

Post a reply to this message

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.

Post a reply to this message

Attachments:
Download 'hmm99_nocam.jpg' (271 KB)

Preview of image 'hmm99_nocam.jpg'

On 1/23/22 10:32, jr 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
> 
> 
> also, I'm currently playing with some code where I frequently use the rtr
> feature to get a quick "all-round" look at an object, and it works beautifully.
> so good in fact that I'd love to be able to put that preview in a frame in a
> frontend, any news on the '-win $id' thing?:-)
> 

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.

Aside: The sky_sphere's 'emission' keyword was always only a color 
vector multiplier. Backgrounds and sky_spheres always emit light in the 
radiosity sense.

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. :-)

Bill P.

Post a reply to this message

On 1/23/22 14:02, Mr wrote:
> To me this looks close to just as cute as the cutest cat ! Any chance of such a
> feature ever making it to main POV master ?

Thanks. A chance I guess should the work be picked up by real POV-Ray 
developers. The micro normal pattern is relatively stand alone.

The big jitter and true random jitter features of povr make 'micro' a 
little more flexible in practice.

All the povr changes are part of the tarball and I consider all my code 
work contributed to the POV-Ray team should they have an interest in any 
of it.

As I move forward with my personal povr branch, my fix and feature 
environment is moving further from the current POV-Ray baseline. Often 
enough now, if a posted problem works for me in povr, but not for those 
in one of the official releases, I find myself unsure why. Unsure what 
combination of changes/fixes make it so.

Bill P.

Post a reply to this message

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