![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Updated yuqk tarballs for Unix/Linux. 427af17e
Date: 24 Jan 2024 12:12:34
Message: <65b14502@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: Updated yuqk tarballs for Unix/Linux. 427af17e
Date: 28 Jan 2024 08:04:59
Message: <65b650fb$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: Updated yuqk tarballs for Unix/Linux. 427af17e
Date: 28 Jan 2024 15:59:30
Message: <65b6c032$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![story.png](/povray.binaries.programming/attachment/%3C65b6c032%241%40news.povray.org%3E/story.png?ttop=443755&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |