Please see the attached tarballs and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_427af17e.tar.gz  January 24, 2024
yuqk R11 v0.6.5.0

The 'optional' keyword use has been restricted to macro parameters. As 
explanation the error message on such use is currently:

"The application of 'optional' keyword ahead of other than macro 
parameters is not presently allowed. This partly due the parser 
currently not always forcing closing semicolons when they are in fact 
required. Such missing semicolons are often only caught as errors when 
later identifiers are seen as undefined. The 'optional' keyword can hide 
these sorts of errors making results and debugging very confusing and 
difficult.

Further, the 'optional' keyword opens up ways for the wrong, identically 
named, elsewhere defined, identifiers to later be picked up during 
parsing.  It's undecided whether the more general 'optional' use will 
again be allowed."

Parser updates aimed at making situations involving undefined identifier 
errors, easier to understand. In particular, more often where the 
identifier name(s) are known, they are now included as part of the 
parser's error message(s).

Enabled big jitter for method 3 as well as methods 1 and 2, but as 
method 3 always randomly samples over the full 2d pixel, the jitter 
value acts as a sampling range multiplier when specified. Values like 
+j1.1 would slightly bleed sampling into adjacent pixels with method 3.

Moved Antialias methods 1 & 2 to the stochastic random number generator 
method 3 already uses. Also enabled Stochastic_Seed=n / +SSn for methods 
1 & 2 so the jitter-ing is mostly repeatable render to render.

Added Antialias_Min_Depth=n ini / +RMn flag options for antialias 
methods 2 and 3(a). It can be thought of as a way to implement initial 
non-adaptive AA sampling - better at resolving detail - prior to the 
adaptive AA. The option was added to method 1 as well, but there the min 
depth is used (if > 0) whenever the flat sub-sampling would normally be 
skipped due the current pixel not meeting the threshold test relative to 
the adjacent left and top pixels.  In other words, when using the min 
depth option with method 1 the pixel sub-sampling will toggle between 
two flat sub-sampling counts set by +RMn and +Rn, respectively.

Fixed case with cutaway_textures in difference{} block where if first 
shape was not textured, it was being left with no texture during the 
rendering phase.  Results in such cases now align with intersection - 
and difference{} is really implemented as an intersection with all but 
the first object inverted.

Relaxed smooth_triangle degeneracy treatment. Smooth triangles 
considered degenerate due the specified normals will no longer disappear 
due the setting of the shape's degenerate flag. The warning messages 
from the parser are still issued.

It was the case previously where users specified +sc1 and +ec1, or +sr1 
and +er1, the options would be ignored and all columns and/or rows would 
be rendered. These particular 1 and 1 specifications now work. Further, 
the additional checking suggested by Ryan Binns in github issue 312 was 
adopted - addressing all parts of issue 312.

Now flag vector tuples without trailing semicolon. The vector tuple / 
batch / list assignments of the vector form have always needed closing 
semicolons to stop falls into mid directive streams resulting in quietly 
corrupted parsing results.

Fixed bug in empty parentheses handing.

Post a reply to this message

Attachments:
Download 'povray-3.8.0-x.yuqk_427af17e.tar.gz' (1665 KB) Download 'yuqk_docandaid_427af17e.tar.gz' (454 KB) Download 'yuqk_examples_427af17e.tar.gz' (103 KB)

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Fixed case with cutaway_textures in difference{} block where if first
> shape was not textured, it was being left with no texture during the
> rendering phase.  Results in such cases now align with intersection -
> and difference{} is really implemented as an intersection with all but
> the first object inverted.
>

[Running Windows 10]
I am currently working on an elaborate 'object-slicing' scene that makes use of
cutaway_textures and a #default finish{...} statement. I have attached a
simplified version of the scene; would you mind running it in your current yuqk
fork? I would be curious to know if the scene produces what I see, given your
updates to cutaway_textures (and possibly both the specified #default behavior
as well as your current behind-the-scenes #defaults).

It requires a *square* render, at any resolution you choose. I designed  the
various textures and finishes-- and the #default finish-- after experimenting to
find the best combinations; I hope they still work correctly in your
fork...especially the un-textured intersection box. On my end, the results are
consistent in both official v3.7.0 and 3.8 beta 1.

There are 2 switches in the scene , with 4 possible permutations. This is what I
see:

#declare WHICH_TEST_ = 1;
#declare USE_CUTAWAY_TEXTURES_ = off;
a totally white object inside a rectangular red box, against black

#declare WHICH_TEST_ = 1;
#declare USE_CUTAWAY_TEXTURES_ = on;
a yellow and blue object (with a slight red tint), inside a rectangular red box,
against black

#declare WHICH_TEST_ = 2;
#declare USE_CUTAWAY_TEXTURES_ = off;
a totally white object against black

#declare WHICH_TEST_ = 2;
#declare USE_CUTAWAY_TEXTURES_ = on;
a yellow and blue object against black

Post a reply to this message

Attachments:
Download 'cutaway_textures_test_for_wp_from_kw_1_2024.pov.txt' (3 KB)

On 1/27/24 06:27, Kenneth wrote:
> would you mind running it in your current yuqk
> fork?

FYI. I did see your post. Thanks for the great test case. :-)

Your code turned up a bug which I've been chasing since yesterday. I 
thought I'd nailed it a minute ago. Alas, not yet.

I need to do some real life stuff for a bit. I'll post more when I've
finally run the bug down.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/27/24 06:27, Kenneth wrote:
> > would you mind running it in your current yuqk
> > fork?
>
> FYI. I did see your post. Thanks for the great test case. :-)
>
> Your code turned up a bug which I've been chasing since yesterday. I
> thought I'd nailed it a minute ago. Alas, not yet.
>
> I need to do some real life stuff for a bit. I'll post more when I've
> finally run the bug down.
>
No problem; thanks for taking the time to test it! You will probably notice that
the code has a mix of full texture statements plus 'naked' finish blocks. This
combination was what I had to come up with to get the results I needed (and to
take into account some slight differences between v3.7 vs 3.8 beta 1). The mix
may not be *the* ideal arrangement, as I had to experiment with a lot of
permutations. When I finally found a combination that worked, I settled on
that...without running even *more* possible(?) tests. ;-)

It could be that a few minor changes to my code's texture/finish mix would
eliminate your own bug *and* still make the result correct and consistent across
versions; I don't know.

Post a reply to this message

On 1/28/24 11:30, Kenneth wrote:
> When I finally found a combination that worked, I settled on
> that...without running even*more*  possible(?) tests.

Yes, when testing POV-Ray the test combinations tend to explode. You can 
never cover it all. Permutations - like Bald Eagles recent image! :-)

I ran the bug down to something sitting in v3.8 onward (perhaps older 
code too - I didn't check). See:

https://news.povray.org/povray.beta-test/thread/%3C65b6ba93%241%40news.povray.org%3E/

Attached is an image. The left column are the results I see for v3.8 
beta 2. The right column what I see with yuqk (R11 and my working version)

The top row shows the four combinations as you posted them. The results 
match. In the just released yuqk R11, the default{} mechanism still exists.

The middle row shows both v3.8 beta 2 and yuqk (R12 working code) 
without the default{} block. Yuqk being different on the right is how I 
caught the bug up top. With that bug fixed the result again match. (The 
fixed result is not shown).

The bottom row is a repeat on the left for v3.8 beta 2, but I have made 
edits to your scene file to define a user default texture and make 
explicit it is the base for derived textures below. This amounts to 
replacing the default{} with:

#declare DfltTxtr = texture { finish{ambient 1 emission 0 diffuse 0} }

And below that changing :

texture{pigment{rgb 1}}
     and
pigment{OBJ_COLOR_}

to become:

texture{ DfltTxtr pigment{rgb 1} }
     and
texture{ DfltTxtr pigment{OBJ_COLOR_} }

Bill P.



Aside: Your test case triggers the 'always full depth' method 3 bug 
still sitting in v3.8 beta 2.

Even when I force a minimum number of samples and use big jitter with 
the recent yuqk release code using:

//   test 1  off                                   ****     *****
   yuqk test.pov   +w300 +h300 +a0.005 +am3 +ac0.90 +rm2 +r5 +j1.1

the following command:

   p380b2 test.pov +w300 +h300 +a0.005 +am3 +ac0.90     +r5

runs 400% slower. Results are of course good with both commands.

Post a reply to this message

Attachments:
Download 'story.png' (70 KB)

Preview of image 'story.png'

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I ran the bug down to something sitting in v3.8 onward (perhaps older
> code too - I didn't check)...
>
> Attached is an image...


THANK YOU for doing such a thorough series of tests-- "above and beyond the call
of duty"! I really appreciate it.
>
> The bottom row is a repeat on the left for v3.8 beta 2, but I have made
> edits to your scene file to define a user default texture and make
> explicit it is the base for derived textures below. This amounts to
> replacing the default{} with:
>
> #declare DfltTxtr = texture { finish{ambient 1 emission 0 diffuse 0} }
> [snip]

That's a useful suggestion, thank you again for coming up with it! (I do recall
that you mentioned such changes, in one of your recent threads.) So, I decided
to eliminate my #default statement and add your edits...and everything still
works fine in v3.7 and 3.8 beta 1. I have attached the edited test scene, in
case you want to run a 'sanity check' to see if the results are still OK in your
fork.
>
> Aside: Your test case triggers the 'always full depth' method 3 bug
> still sitting in v3.8 beta 2...
>
> the following command:
>
>    p380b2 test.pov +w300 +h300 +a0.005 +am3 +ac0.90     +r5
>
> runs 400% slower.

Wow! Luckily for me, my object-slicing code will not make use of AA-- for
technical reasons having to do with that 3D SLICER medical app that I am using
for my POV-ray-to-STL 3-D-printing scheme (which is now almost ready to be
posted!)

Post a reply to this message

Attachments:
Download 'cutaway_textures_test_for_w_p_redux.pov.txt' (3 KB)