https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167


Primary feature of this update is the addition of blue noise dithering.

Blue noise dithering is a comparatively new ordered dithering algorithm,
using a tiling pattern to vary the quantization threshold. However,
unlike the extremely regular pattern used in the otherwise similar Bayer
dithering, the pattern used in blue noise dithering is constructed to be
extremely irregular at small scales, while at the same time being
extremely regular at large scales. In other words, it has a lot of
high-frequency noise, while at the same time having very little
low-frequency noise.

The pattern used by POV-Ray is a hard-coded 64x64 pattern, generated
using a so-called void-and-cluster approach (utilizing a public domain
Python script by - as it happens - fellow "Rheinlandian", 3D enthusiast
and namesake Christoph Peters).

Due to its high quality and ease of use, blue noise dithering is now the
default algorithm, and is also used in the preview window, replacing the
inferior Bayer dithering there.


The blue noise dithering comes in two variants: Aside from a
straightforward implementation (`+THbn`) where the threshold of all
channels is varied according to the same pattern, an experimental
implementation is available (`+THbnx`) in which the threshold for the
red and blue channels is varied according to the inverse of the pattern,
to reduce the noise in the brightness domain (at the cost of more noise
in the chromaticity domain).


In the wake of this, ...

- A couple more error diffusion dithering filters have been added
(primarily for giggles and because we can). See
povray.documentation.inbuilt, recent thread "Some stuff related to
output file formats" for details.

- The lower limit for the bit depth (previously 5) has been dropped;
anything between 1 and 16 is fair game now (affects PNG and PPM/PGM
only; again, mostly for giggles, to better demonstrate dithering, but
maybe some of you folks may want to experiment with it).

- Greyscale output no longer forces bit depth to 16 (also primarily for
dithering demonstration purposes).

- Greyscale file output now also switches the preview window to greyscale.

- The `+F` option can now be used to specify both greyscale (`g` suffix)
and non-default bit depth (numeric suffix) simultaneously. (The `g` must
come first.)

- Gamma handling in PGM (greyscale "PPM") files has been changed to be
consistent with colour PPM.

- Gamma handling in dithering has been improved.


I /think/ that's all.

Post a reply to this message

Le 18-09-30 à 23:48, clipka a écrit :
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
> 
> 
> Primary feature of this update is the addition of blue noise dithering.
> 
> Blue noise dithering is a comparatively new ordered dithering algorithm,
> using a tiling pattern to vary the quantization threshold. However,
> unlike the extremely regular pattern used in the otherwise similar Bayer
> dithering, the pattern used in blue noise dithering is constructed to be
> extremely irregular at small scales, while at the same time being
> extremely regular at large scales. In other words, it has a lot of
> high-frequency noise, while at the same time having very little
> low-frequency noise.
> 
> The pattern used by POV-Ray is a hard-coded 64x64 pattern, generated
> using a so-called void-and-cluster approach (utilizing a public domain
> Python script by - as it happens - fellow "Rheinlandian", 3D enthusiast
> and namesake Christoph Peters).
> 
> Due to its high quality and ease of use, blue noise dithering is now the
> default algorithm, and is also used in the preview window, replacing the
> inferior Bayer dithering there.
> 
> 
> The blue noise dithering comes in two variants: Aside from a
> straightforward implementation (`+THbn`) where the threshold of all
> channels is varied according to the same pattern, an experimental
> implementation is available (`+THbnx`) in which the threshold for the
> red and blue channels is varied according to the inverse of the pattern,
> to reduce the noise in the brightness domain (at the cost of more noise
> in the chromaticity domain).
> 
> 
> In the wake of this, ...
> 
> - A couple more error diffusion dithering filters have been added
> (primarily for giggles and because we can). See
> povray.documentation.inbuilt, recent thread "Some stuff related to
> output file formats" for details.
> 
> - The lower limit for the bit depth (previously 5) has been dropped;
> anything between 1 and 16 is fair game now (affects PNG and PPM/PGM
> only; again, mostly for giggles, to better demonstrate dithering, but
> maybe some of you folks may want to experiment with it).
> 
> - Greyscale output no longer forces bit depth to 16 (also primarily for
> dithering demonstration purposes).
> 
> - Greyscale file output now also switches the preview window to greyscale.
> 
> - The `+F` option can now be used to specify both greyscale (`g` suffix)
> and non-default bit depth (numeric suffix) simultaneously. (The `g` must
> come first.)
> 
> - Gamma handling in PGM (greyscale "PPM") files has been changed to be
> consistent with colour PPM.
> 
> - Gamma handling in dithering has been improved.
> 
> 
> I /think/ that's all.
> 

I no longer see the post render info when using isosurfaces with 
improper max_gradient.

Post a reply to this message

Am 04.10.2018 um 17:53 schrieb Alain:
> I no longer see the post render info when using isosurfaces with
> improper max_gradient.

Can you provide a sample scene, and what exactly you'd expect?

Post a reply to this message

Le 18-10-05 à 11:08, clipka a écrit :
> Am 04.10.2018 um 17:53 schrieb Alain:
>> I no longer see the post render info when using isosurfaces with
>> improper max_gradient.
> 
> Can you provide a sample scene, and what exactly you'd expect?
> 

#version 3.8;
global_settings{assumed_gamma 1}
#declare tip = function(Vert) { sqrt(6.25 - pow(Vert,2)) - 1.5 }
#declare rad = function(H) {(H*H+1) / max(H,1e-6) / 2}
#declare hgt = function(x,R,H) { sqrt(pow(R,2) - pow(x,2)) + H - R }
#declare hght= function(x,H) { hgt(x, rad(H), H) }
#declare height=function(x,y) { hght(x, tip(y+1)) }

#declare OBJ=isosurface {
     function { z * (z - hght(x, tip(y+1))) }
     threshold 0
     //max_gradient 9 // the original
     max_gradient 1 // for this test
     contained_by {box {<-1,-1,0>, <1,1,1>}}
   }

object{OBJ pigment{rgb <1,0.5,0.3>}}
camera{location -7*z look_at 0}
light_source{<25,25,-25> rgb 1}

I expected some message about the max_gradient found to be around 9 but 
set at 1.0.
The resulting image show obvious holes.

But, I don't get any message after the render is complete.


Alain

Post a reply to this message

Am 05.10.2018 um 20:33 schrieb Alain:

> I expected some message about the max_gradient found to be around 9 but
> set at 1.0.
> The resulting image show obvious holes.
> 
> But, I don't get any message after the render is complete.

Can't reproduce:

- I only see an (almost perfect) clay-brown slab, even with the
max_gradient 1 setting. No holes for me.

- Previous versions (tested with v3.7) do not produce a max_gradient
warning for this scene either. [*]

- When I set max_gradient even lower (0.1), I do get holes, but I also
do get a warning with alpha.9861167. [*]

- The reported maximum gradient found is 0.990, not around 9.


[* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
that fails to issue a warning.]

Post a reply to this message

On 5-10-2018 20:33, Alain wrote:
> Le 18-10-05 à 11:08, clipka a écrit :
>> Am 04.10.2018 um 17:53 schrieb Alain:
>>> I no longer see the post render info when using isosurfaces with
>>> improper max_gradient.
>>
>> Can you provide a sample scene, and what exactly you'd expect?
>>
> 
> #version 3.8;
> global_settings{assumed_gamma 1}
> #declare tip = function(Vert) { sqrt(6.25 - pow(Vert,2)) - 1.5 }
> #declare rad = function(H) {(H*H+1) / max(H,1e-6) / 2}
> #declare hgt = function(x,R,H) { sqrt(pow(R,2) - pow(x,2)) + H - R }
> #declare hght= function(x,H) { hgt(x, rad(H), H) }
> #declare height=function(x,y) { hght(x, tip(y+1)) }
> 
> #declare OBJ=isosurface {
>      function { z * (z - hght(x, tip(y+1))) }
>      threshold 0
>      //max_gradient 9 // the original
>      max_gradient 1 // for this test
>      contained_by {box {<-1,-1,0>, <1,1,1>}}
>    }
> 
> object{OBJ pigment{rgb <1,0.5,0.3>}}
> camera{location -7*z look_at 0}
> light_source{<25,25,-25> rgb 1}
> 
> I expected some message about the max_gradient found to be around 9 but 
> set at 1.0.
> The resulting image show obvious holes.
> 
> But, I don't get any message after the render is complete.
> 
> 
> Alain

Isn't this the typical "naked" isosurface syndrome? i.e. a #declared 
isosurface do /not/ show warning messages, simply provide the isosurface 
as-is, does instead.

Try instead, without the #declare:

isosurface {
       function { z * (z - hght(x, tip(y+1))) }
       threshold 0
       //max_gradient 9 // the original
       max_gradient 1 // for this test
       contained_by {box {<-1,-1,0>, <1,1,1>}}
       pigment{rgb <1,0.5,0.3>}
     }


-- 
Thomas

Post a reply to this message

On 10/05/2018 03:04 PM, clipka wrote:
> Am 05.10.2018 um 20:33 schrieb Alain:
> 
>> I expected some message about the max_gradient found to be around 9 but
>> set at 1.0.
>> The resulting image show obvious holes.
>>
>> But, I don't get any message after the render is complete.
> 
> Can't reproduce:
> 
> - I only see an (almost perfect) clay-brown slab, even with the
> max_gradient 1 setting. No holes for me.
> 
> - Previous versions (tested with v3.7) do not produce a max_gradient
> warning for this scene either. [*]
> 
> - When I set max_gradient even lower (0.1), I do get holes, but I also
> do get a warning with alpha.9861167. [*]
> 
> - The reported maximum gradient found is 0.990, not around 9.
> 
> 
> [* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
> that fails to issue a warning.]
> 

I do see a few apparent holes (no AA) in the upper let corner for 
example, but otherwise agree with Christoph.

I think the bounding is off with z low being zero:

  contained_by {box {<-1,-1,0>, <1,1,1>}}

In other words, I think the function is mostly being clipped so we are 
seeing a slice of the function's "inside" and which on that slice is 
noisy at the edges. Change that zlow bounding 0 to -1, for example, and 
you'll get gradient warnings for the max gradient of 1.

Aside 1: Another way to clean up the edges in the clipped (zlow=0) case 
is to crank the accuracy way up so the clipped inside resolves more 
cleanly at the edges. Say maybe 0.00005 or less.

Aside 2: IIRC there is still a thread collision in the current 
implementation (which Thomas, in 3.8 no longer needs to be "naked" 
thanks to Christoph's updates) - meaning you are not guaranteed to see 
the very worst found gradient. In practice it's close. Practical 
implication is you need to bump any reported max a little for the 
setting not so much for result, but to be sure some later render doesn't 
report a slightly larger gradient just due the internal ordering of 
stuff.

Bill P.

Post a reply to this message

On 6-10-2018 13:14, William F Pokorny wrote:
> Aside 2: IIRC there is still a thread collision in the current 
> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
> thanks to Christoph's updates) - meaning you are not guaranteed to see 
> the very worst found gradient. In practice it's close. Practical 
> implication is you need to bump any reported max a little for the 
> setting not so much for result, but to be sure some later render doesn't 
> report a slightly larger gradient just due the internal ordering of stuff.
> 

Good! Progress passing me by :-)

Thanks for the info.

-- 
Thomas

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167

playing around with some code, I get:

  File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
  Fatal error in parser: Cannot parse input.

the problem is, the file ends at line 39.  :-)  line 38 contains an
'#undef' which destroys a variable '#declare'd in same file.

archive with scene to same email?

regards, jr.

Post a reply to this message

Am 07.10.2018 um 16:16 schrieb jr:

>   File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
>   Fatal error in parser: Cannot parse input.
> 
> the problem is, the file ends at line 39.  :-)  line 38 contains an
> '#undef' which destroys a variable '#declare'd in same file.
> 
> archive with scene to same email?
> 
> regards, jr.

The usual procedure, yes.

Post a reply to this message

On 2018-09-30 11:48 p.m., clipka wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
> 
While not related to the updated features, this was the winpov64 I used.
Using a newer computer and going though some older scenes.


With no included Work_Threads, or commented out, Work_Threads

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
               using 3 thread(s) with 3988.077 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.16 seconds, user 3992.17 seconds, total 3993.33 
seconds.
Elapsed time 1331.39 seconds, CPU vs elapsed time ratio 3.00.
Render averaged 2433.55 PPS (811.35 PPS CPU time) over 3240000 pixels.

Adding:
Work_Threads = 32
To my .INI file gave me the following outputs.

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours  3 minutes 10 seconds (190.047 seconds)
               using 32 thread(s) with 6039.815 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.03 seconds, user 6043.08 seconds, total 6044.11 
seconds.
Elapsed time 192.08 seconds, CPU vs elapsed time ratio 31.47.
Render averaged 16867.97 PPS (536.06 PPS CPU time) over 3240000 pixels.


Is there a default some where?

WinPov editor:
Render/Thread Count is set to 32

StephenS

Post a reply to this message

Am 14.10.2018 um 22:26 schrieb StephenS:

> While not related to the updated features, this was the winpov64 I used.
> Using a newer computer and going though some older scenes.
> 
> 
> With no included Work_Threads, or commented out, Work_Threads
> 
> Render Time:
>   Photon Time:      No photons
>   Radiosity Time:   No radiosity
>   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
>               using 3 thread(s) with 3988.077 CPU-seconds total
> POV-Ray finished

...
> Is there a default some where?

Yes:

> WinPov editor:
> Render/Thread Count is set to 32

To the best of my knowledge, the mechanism in POV-Ray for Windows is as
follows:

- The number of threads set in the "Render Thread Count" dialog is the
default for each render.

- Any change you make in the dialog is only valid for the current
session; if you close POV-Ray and re-start it, the dialog is
re-populated with the number of cores as reported by the operating system.

- Any `+wtN`, `-wtN` or `Work_Threads=N` in any applicable INI file will
override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` specified in the so-called
"command line" inut field will also override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` passed to the POV-Ray
executable as an actual command line parameter should also affect the
setting, though I'm not sure whether it will change the value in the
dialog or be equivalent to setting it in an INI file. My guess is the
latter.


Obviously the "Render Thread Count" dialog is not initialized to 3 in
your case, so the core count auto-detection works fine, and there must
be /something/ overridding the default.

The master `povray.ini` as well as any `povray.ini` in the same
directory as the scen come to mind.

Post a reply to this message

On 2018-10-15 2:08 a.m., clipka wrote:
...
> The master `povray.ini` as well as any `povray.ini` in the same
> directory as the scen come to mind.
> 

Good call, there was indeed a povray.ini in the same directory.

Separately, I will no longer be reporting WinXP32 feedback unless asked. 
The computer is no longer plugged in with all of it's parts.

StephenS

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> > archive with scene to same email?
> The usual procedure, yes.

did you receive the email?


regards, jr.

Post a reply to this message

Am 17.10.2018 um 15:57 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>>> archive with scene to same email?
>> The usual procedure, yes.
> 
> did you receive the email?

Nope.

Post a reply to this message

Am 21.10.2018 um 01:51 schrieb clipka:
> Am 17.10.2018 um 15:57 schrieb jr:
>> hi,
>>
>> clipka <ano### [at] anonymousorg> wrote:
>>>> archive with scene to same email?
>>> The usual procedure, yes.
>>
>> did you receive the email?
> 
> Nope.

Nevermind. I was a bit confused. Yes, the e-mail did reach me, and I
managed to come up with a fix in no time flat(*), but hadn't gotten
around to providing feedback yet, or push the fix to the repo for that
matter.

(*Interestingly, the bug was in a piece of code I had always been
suspicious about whether I had implemented it correctly. Turns out I
hadn't.)

Post a reply to this message

On 6-10-2018 13:14, William F Pokorny wrote:
> Aside 2: IIRC there is still a thread collision in the current 
> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
> thanks to Christoph's updates) - 
Hmmm... is that so? I am currently using an isosurface and the 
max_gradient warning only shows if the isosurface is "naked" i.e. 
without #declare.

Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

-- 
Thomas

Post a reply to this message

On 10/21/18 3:29 AM, Thomas de Groot wrote:
> On 6-10-2018 13:14, William F Pokorny wrote:
>> Aside 2: IIRC there is still a thread collision in the current 
>> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
>> thanks to Christoph's updates) - 
> Hmmm... is that so? I am currently using an isosurface and the 
> max_gradient warning only shows if the isosurface is "naked" i.e. 
> without #declare.
> 
> Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7
> 

While I'm a couple more days busy with real life, please post as simple 
a scene as you can showing the issue. I'll take a look later this week 
should no one else.

While the issue is certainly fixed for simple cases in 3.8, I've myself 
a mental flag(1) set. A "perhaps we sometimes still get no warnings" flag...

--- Detail
On the periphery of testing late last year or early this, I wondered if 
I'd created such a scene while re-arranging scene code. Isosurface 
warnings went away during that code clean up I thought should probably 
not have disappeared.

It was a less simple scene where the isosurface #declare'd name was used 
across multiple CSG blocks also named and used via #declares. I was 
chasing other stuff at the time and didn't immediately follow up. I 
tried a quick scene I "thought" similar prior to my response to you 
above. It though, worked/warned as it should.

The "naked" max gradient for a given isosurface can be different where 
the isosurface scene usage is other than simple - where not just a 
#declare wrapper. Said another way, if you shoot a different collection 
of rays at an isosurface you can easily have different determined max 
gradients(2).

Bill P.

(1) Mental notes. Why I tend toward drowning in detail instead of 
getting things done. Drives too my footnoting madness. :-)

(2) One of several reasons isosurfaces can be difficult to use in 
animations.

Post a reply to this message

Am 21.10.2018 um 09:29 schrieb Thomas de Groot:
> On 6-10-2018 13:14, William F Pokorny wrote:
>> Aside 2: IIRC there is still a thread collision in the current
>> implementation (which Thomas, in 3.8 no longer needs to be "naked"
>> thanks to Christoph's updates) - 
> Hmmm... is that so? I am currently using an isosurface and the
> max_gradient warning only shows if the isosurface is "naked" i.e.
> without #declare.
> 
> Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

It doesn't matter whether you use `#declare` or not; what really matters
is whether there are actually rays shot at the isosurface during the render.

So a `#declare`d isosurface that is never actually inserted into the
scene will never get a warning.

Post a reply to this message

On 22-10-2018 23:33, clipka wrote:
> It doesn't matter whether you use `#declare` or not; what really matters
> is whether there are actually rays shot at the isosurface during the render.
> 
> So a `#declare`d isosurface that is never actually inserted into the
> scene will never get a warning.
> 

@ clipka and Bill:

I am probably totally misunderstanding something, but I attach here a 
simple scene of the Kluchikov Ring with a on/off switch between a 
'declared' and a 'non-declared' isosurface. The 'non-declared' one shows 
a max_gradient warning at the end of the render; the 'declared' one does 
not.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'ak_my favourite isosurface test.7z.zip' (2 KB)

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 21.10.2018 um 01:51 schrieb clipka:
> >> did you receive the email?
>
> Nevermind. I was a bit confused. Yes, the e-mail did reach me,

phew.

> and I
> managed to come up with a fix in no time flat(*), but hadn't gotten
> around to providing feedback yet, or push the fix to the repo for that
> matter.

I saw the weather you were having the past two weeks, and suspected you might be
out sunbathing.  :-)

> (*Interestingly, the bug was in a piece of code I had always been
> suspicious about whether I had implemented it correctly. Turns out I
> hadn't.)


regards, jr.

Post a reply to this message

Am 23.10.2018 um 08:40 schrieb Thomas de Groot:
> On 22-10-2018 23:33, clipka wrote:
>> It doesn't matter whether you use `#declare` or not; what really matters
>> is whether there are actually rays shot at the isosurface during the 
>> render.
>>
>> So a `#declare`d isosurface that is never actually inserted into the
>> scene will never get a warning.
>>
> 
> @ clipka and Bill:
> 
> I am probably totally misunderstanding something, but I attach here a 
> simple scene of the Kluchikov Ring with a on/off switch between a 
> 'declared' and a 'non-declared' isosurface. The 'non-declared' one shows 
> a max_gradient warning at the end of the render; the 'declared' one does 
> not.

You are aware that the two isosurfaces are not identical? They differ in 
the max_gradient setting.

Not that it would make any difference though - I do get a warning for 
both of them.


Did you double-check that you're really seeing what you think you're seeing?

What version of POV-Ray are we talking about?

Post a reply to this message

On 23-10-2018 18:14, clipka wrote:
> Am 23.10.2018 um 08:40 schrieb Thomas de Groot:
>> On 22-10-2018 23:33, clipka wrote:
>>> It doesn't matter whether you use `#declare` or not; what really matters
>>> is whether there are actually rays shot at the isosurface during the 
>>> render.
>>>
>>> So a `#declare`d isosurface that is never actually inserted into the
>>> scene will never get a warning.
>>>
>>
>> @ clipka and Bill:
>>
>> I am probably totally misunderstanding something, but I attach here a 
>> simple scene of the Kluchikov Ring with a on/off switch between a 
>> 'declared' and a 'non-declared' isosurface. The 'non-declared' one 
>> shows a max_gradient warning at the end of the render; the 'declared' 
>> one does not.
> 
> You are aware that the two isosurfaces are not identical? They differ in 
> the max_gradient setting.

Correct. My bad. Both max_gradients should be 0.75 (or what ever).

> 
> Not that it would make any difference though - I do get a warning for 
> both of them.

I do not. I only get a warning when the isosurface is /not/ declared.

> 
> 
> Did you double-check that you're really seeing what you think you're 
> seeing?

Yes, absolutely!!

> 
> What version of POV-Ray are we talking about?

v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

You are right (of course you are right!): I had not yet used the alpha 
version 3.8.0-alpha.9861167+av620.msvc14.win as I thought they were more 
or less identical. It shows the warning for both cases indeed. I had not 
been aware that the case had been solved in between. Thanks!

Phwwww..... That was close! I am glad I do not have to put myself under 
psychiatric treatment after all ;-)

[where are my dried frog pills...?]

-- 
Thomas

Post a reply to this message

Am 24.10.2018 um 08:40 schrieb Thomas de Groot:

>> What version of POV-Ray are we talking about?
> 
> v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

Ah, the experimetal new tokenizer! Now that changes things. Since we're 
talking about alpha.9861167, I had presumed that you were using at least 
some alpha as well.

> You are right (of course you are right!): I had not yet used the alpha 
> version 3.8.0-alpha.9861167+av620.msvc14.win as I thought they were more 
> or less identical. It shows the warning for both cases indeed. I had not 
> been aware that the case had been solved in between. Thanks!

Has it? I don't recall any such fix, nor it even being necessary. So 
looks like something broke during the refactoring for the tokenizer 
changes. That's conceivable.

I'll investigate that once I turn my attention back to the tokenizer.


> Phwwww..... That was close! I am glad I do not have to put myself under 
> psychiatric treatment after all ;-)
> 
> [where are my dried frog pills...?]

Probably right where I left my glasses.

Post a reply to this message

On 25-10-2018 8:05, clipka wrote:
> Am 24.10.2018 um 08:40 schrieb Thomas de Groot:
> 
>>> What version of POV-Ray are we talking about?
>>
>> v 3.8.0-xtokenizer.9844488+av609.msvc with Win7
> 
> Ah, the experimetal new tokenizer! Now that changes things. Since we're 
> talking about alpha.9861167, I had presumed that you were using at least 
> some alpha as well.

Yes, it is bad practice to mix posts on different versions like I did. I 
apologise.

> 
>> You are right (of course you are right!): I had not yet used the alpha 
>> version 3.8.0-alpha.9861167+av620.msvc14.win as I thought they were 
>> more or less identical. It shows the warning for both cases indeed. I 
>> had not been aware that the case had been solved in between. Thanks!
> 
> Has it? I don't recall any such fix, nor it even being necessary. So 
> looks like something broke during the refactoring for the tokenizer 
> changes. That's conceivable.

Well, it definitely was an issue with versions 3.6 and below, and, as 
far as I recall, with version 3.7.

> 
> I'll investigate that once I turn my attention back to the tokenizer.
> 
> 
>> Phwwww..... That was close! I am glad I do not have to put myself 
>> under psychiatric treatment after all ;-)
>>
>> [where are my dried frog pills...?]
> 
> Probably right where I left my glasses.

That might well be the case indeed.

-- 
Thomas

Post a reply to this message

On 25-10-2018 8:39, Thomas de Groot wrote:
> Well, it definitely was an issue with versions 3.6 and below, and, as 
> far as I recall, with version 3.7.
> 
Just to confirm, after testing: Also an issue with version 
3.7.0.msvc10.win64

The correction must have been made in one of the 3.8.0 alphas.

-- 
Thomas

Post a reply to this message

Am 26.10.2018 um 09:28 schrieb Thomas de Groot:
> On 25-10-2018 8:39, Thomas de Groot wrote:
>> Well, it definitely was an issue with versions 3.6 and below, and, as 
>> far as I recall, with version 3.7.
>>
> Just to confirm, after testing: Also an issue with version 
> 3.7.0.msvc10.win64
> 
> The correction must have been made in one of the 3.8.0 alphas.

Having dug a bit in the revision history (my memory isn't as good as it 
used to be), there has indeed been such a fix, but that was already back 
in v3.7.1-alpha.8913469. Commit 3f1de0d6, dated 2016-12-11.

Post a reply to this message

On 26-10-2018 17:50, clipka wrote:
> Am 26.10.2018 um 09:28 schrieb Thomas de Groot:
>> On 25-10-2018 8:39, Thomas de Groot wrote:
>>> Well, it definitely was an issue with versions 3.6 and below, and, as 
>>> far as I recall, with version 3.7.
>>>
>> Just to confirm, after testing: Also an issue with version 
>> 3.7.0.msvc10.win64
>>
>> The correction must have been made in one of the 3.8.0 alphas.
> 
> Having dug a bit in the revision history (my memory isn't as good as it 
> used to be), there has indeed been such a fix, but that was already back 
> in v3.7.1-alpha.8913469. Commit 3f1de0d6, dated 2016-12-11.

Ah OK. As a matter of fact, I do not have any of the 3.7.1 versions any 
more... except UberPOV: 1.37.1.1-alpha.8871946.msvc14.win64, which also 
shows the issue as it happens.

-- 
Thomas

Post a reply to this message