povray.documentation.inbuilt message digest

[William F Pokorny] Re: Issues with sor tutorial example. [161 days 4 hours and 49 minutes ago]

Mon, 3 Nov 2025 08:21:48 GMT

On 11/2/25 14:08, Kenneth wrote:

Thanks for confirming on windows.

> So I wonder if the problem is just shadow artifacts: sturm on/off has the
> opposite effect on the inside and outside-- and on the lighted surface vs.
> shadowed surface(!)
> 

I agree. The bad sturm results for official are shadow related.

However, I believe this due the sturm results, sometimes, not being that 
accurate - by position. Specifically, I'd bet here on a 'quicker exit' 
bug in the regula-falsi code - fixed in yuqk - which finishes off the 
root calculation once an interval with a single root has been found by 
the sturmian portion of 'sturm'(*).

> The appearance of the noise and the artifacts on the*outside* depends on the
> the camera position, its look_at point, the position of the light(s) and the
> orientation of the SOR-- all of which interact, unfortunately. It looks the
> worst to me  when the y-positions of all three are the same (and not just when
> the camera is looking straight into +z).
> 
> Since the SOR when 'open' is really just an infinitely thin shell, it seems to
> me that using it this way is not a good idea anyway, as  the walls have no
> thickness at all and look unrealistic. (The docs also mention that it shouldn't
> be used in CSG this way.)

No... :-) The sor{}s are more like cylinders/cones in having well 
defined inside regions always with two surfaces when using caps and, 
potentially, only a single surface - with the same, well defined, inside 
region - depending on the ray path when not using caps.

In playing more with the sor{} shape recently, I've come to think it 
more useful due potential use in CSG! The sor{} doesn't have the fuzzy 
issues with defining an inside regions which Cousin Ricky highlighted 
recently for the lathe{} at fold-backs, for example.

Bill P.

(*) - I have more sturmian solver work years now on the todo list; 
Including replacing the regula-falsi code with a dedicated 
newton-raphson solver I wrote from scratch that always resolves to the 
root once given an interval known to have a root. That work though is 
tangled in also wanting to remove a re-ordering of coefficients into the 
sturmian part of 'sturm' that I suspect was long ago done for 
convenience, but which burns time.

I have too another solver approach which, for accuracy is much better 
than 'sturm'. However, it requires even more re-working of code because 
it merges the per shape polynomial generation and solver into one 
method. Maybe someday...

[Kenneth] Re: Issues with sor tutorial example. [161 days 16 hours and 41 minutes ago]

Sun, 2 Nov 2025 20:30:01 GMT

Animation #4

[Kenneth] Re: Issues with sor tutorial example. [161 days 17 hours and 21 minutes ago]

Sun, 2 Nov 2025 19:50:00 GMT

Animation #3

[Kenneth] Re: Issues with sor tutorial example. [161 days 17 hours and 31 minutes ago]

Sun, 2 Nov 2025 19:40:01 GMT

Animation #2

[Kenneth] Re: Issues with sor tutorial example. [161 days 17 hours and 41 minutes ago]

Sun, 2 Nov 2025 19:30:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I'll follow up here with a few of the test animations I made.

Animation #1

[Kenneth] Re: Issues with sor tutorial example. [161 days 17 hours and 51 minutes ago]

Sun, 2 Nov 2025 19:20:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> It looks the
> worst to me when the y-positions of all three are the same (and not just when
> the camera is looking straight into +z).
>

That was not clear, sorry: the y-positions of the camera location, its look_at
point, and the light.

[Kenneth] Re: Issues with sor tutorial example. [161 days 18 hours and 1 minute ago]

Sun, 2 Nov 2025 19:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Documenting long standing exposures with the sor tutorial example.
>
> Ref:
>
>
https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Index_Entry_sor_tutorial
>

[running v3.7.0 and 3.8 beta 1-- the results are essentially the same]
Windows 10

I ran a lot of animation tests, moving the scene elements around in relation to
one another, and this is how the situation appears to me when using 'sturm':

1) For the OUTSIDE surface of the SOR that *faces* the light source (whether or
not 'open' is also used):
     sturm OFF: lots of noise and artifacts
     sturm ON: no noise that I can see

2) For the 'open' INSIDE surface, in the *shadow* areas:
     sturm OFF: no noise that I can see
     sturm ON: lots of noise etc.

So I wonder if the problem is just shadow artifacts: sturm on/off has the
opposite effect on the inside and outside-- and on the lighted surface vs.
shadowed surface(!)

The appearance of the noise and the artifacts on the *outside* depends on the
the camera position, its look_at point, the position of the light(s) and the
orientation of the SOR-- all of which interact, unfortunately. It looks the
worst to me  when the y-positions of all three are the same (and not just when
the camera is looking straight into +z).

Since the SOR when 'open' is really just an infinitely thin shell, it seems to
me that using it this way is not a good idea anyway, as  the walls have no
thickness at all and look unrealistic. (The docs also mention that it shouldn't
be used in CSG this way.)

(BTW: I tried using 'inverse' in the SOR, just to see if it made any difference
at all. It does not.)

I'll follow up here with a few of the test animations I made.

[Bald Eagle] Re: SOR documentation [162 days 19 hours and 26 minutes ago]

Sat, 1 Nov 2025 17:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I think it's good enough to begin testing the Catmull-Rom bounding.

Here's what I presently have in terms of computing per-segment bounding
cylinders.
Now I just need to code up some bounding cylinder intersection tests to see what
happens.

> Also, there is a mouse in my kitchen.

I have adopted a local stray.
No mouse, but now there is a cat that gets onto my kitchen counter.   :|

Am I winning yet?

- BE

[William F Pokorny] Issues with sor tutorial example. [166 days 2 hours and 14 minutes ago]

Wed, 29 Oct 2025 10:56:24 GMT

Documenting long standing exposures with the sor tutorial example.

Ref:

https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Index_Entry_sor_tutorial

---
The cocktail outline has a flattish portions which are difficult for the 
solvers to handle. Similar to the lathe, the sor likes curvature in the 
spline used (excepting linear splines with the lathe).

In the attached image, the blue results come from v3.8 beta 2, the 
yellow from R20 of yuqk. No AA to better see the issues.

The two columns for each version of POV-Ray represent the non-sturmian 
solver and then the sturmian solver.

The bottom two rows put the camera into the cocktail. The very bottom 
row adds caps and the results 'should be' completely black.

Notes:

a) The non-sturmian solver has difficultly in both v3.8 beta 2 and 
yuqk(R20) given certain ray approaches.

b) The sturmian solver has trouble too in v3.8 b2 - in the shadow 
regions of the top row, for example.

c) The sturmian solver in yuqk returns clean results for all the 
examples run.

d) The yellow pixels at the very top of the yuqk results in the lower 
right are due the intersections hitting deep in the crevice between the 
lip of the cocktail form and the cap.

When the intersection is closer to the cap plane than the internal 
shadow tolerance value (1e-3) shadow rays see through to lights. The 
artifacts exist in both v3.8 and yuqk at larger image sizes.

The yuqk fork has the 'shadow_tolerance' global setting which allows the 
default 1e-3 value to be reduced - greatly reducing the likelihood 
shadow rays will see through the cap due the shadow tolerance value. The 
exposure never goes completely away in situations like this. AA often 
helps hide these issues when they come up.

Bill P.

[William F Pokorny] Re: SOR documentation [166 days 2 hours and 23 minutes ago]

Wed, 29 Oct 2025 10:48:04 GMT

On 10/24/25 05:02, William F Pokorny wrote:
> I think the normalization - including y - is necessary for other reasons 
> like the generation of the polynomials, but I also believe I see your 
> point about what is needed for the initial bounding cylinder check, 
> specifically. I'll try with branch-off code which drops the 'y' 
> component for the initial cylinder test only.
> 

See the attach code excerpt file for what I've settled upon for the 
changes.

> Aside: I'd make a moderate bet this tangled with the issues I had in 
> some rotation about x tests where parts (partial segments/intervals) of 
> the sor would drop out. IIRC, those tests included negative on curve 
> (between end control points, points). We'll see.

Lost my bet here.

Bill P.

[Bald Eagle] Re: SOR documentation [170 days 10 hours and 26 minutes ago]

Sat, 25 Oct 2025 02:45:00 GMT

Seeing how exciting that last post was, let me now slay you with a diagram of
what's going on in that paper.

[Bald Eagle] Re: SOR documentation [170 days 10 hours and 36 minutes ago]

Sat, 25 Oct 2025 02:35:00 GMT

Just briefly scanning this over (as I was up late making rapid-fire changes) and
I noticed that the parser allowed and didn't complain about:

#local in2 = #local Result = {EcResult [2], EcResult [4]};

So who know what other wacky constructs it will let slip through.

Anyway, fixing 2 such statements allowed me to render this stunning grey
rectangle, which I'm assuming must be my cylinder.

- BW

[Bald Eagle] Re: SOR documentation [171 days and 21 minutes ago]

Fri, 24 Oct 2025 12:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
once I fix the issue with the end caps, then I
> > will begin to run some comprehensive tests. (*)
>
> Well, that took way longer than it should have.

The issues here were that it was unclear how and when each function should be
called, and in what order.
There were some issues with the signs of normals and dot products.
And then there was the issue with hits on the end cap that should have replaced
the hit on the infinite cylinder.
And clipping of the edge between the cylinder end cap was leaving residual hits.
So there were 4 places that I needed to add code to undef the results of the
infinite cylinder intersection test.

After that, I kinda needed to write a 3rd macro to take everything and assemble
the output of the 2 macros.

A cautionary tale here is that you have the math and geometry, the code that you
write to do it all, and then the code that you write to interpret and visualize
the result.
Don't go chasing bugs in the first two parts, if the problem is in the third
part.

> However, now I just have to debug the function call and subsequent calculations,
> and I'm hoping to get an actual homemade render soon.

That might not get done until the weekend, when I have another 5 straight hours
to scroll back and forth through the code, inventing new expletives until I
finally get something to work.

Stage One is where all of the things in the code get pondered and picked at.
Even if it's the code I wrote myself.

Stage Two is where a "sense" of deeper understanding starts to occur, and one
starts to gain traction, where the parts of the code that really matter start to
be modified and manipulated in a such a way that you can tell that that's where
much of the solution lies.

Stage Three is where you're probably on the edge of giving up, and just make the
decision to spend another 1-2h just trying to push ahead.  Weird things happen.
It seems like code gets edited and restored in an unproductive circle, yet
somehow something happens that nudges it forward.  Then some key debugging
output coupled with new tests and sections of code finally lead you down the
path to success.

Stage Three is where it ALL happens.  DO IT.

- BE

[William F Pokorny] Re: SOR documentation [171 days 4 hours and 9 minutes ago]

Fri, 24 Oct 2025 09:02:07 GMT

On 10/23/25 09:51, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>>> 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
>>> version of source code are you seeing this?
>>
>> Right because that line is not explicitly there.
>> D is implicitly defined as the ray direction.
>>
>> Then in line 256 we do:    len = D.length();
>>
>> Which is why we need to get rid of the y component for reasons explained.
>>
>> So really what we need is an extra line that REdefines the _projected_ ray
>> direction as D = <D.x, 0, D.y> before that length and normalization take place.
>>
>> - BW
> 
> https://news.povray.org/web.68e8688f251da1bc1f9dae3025979125%40news.povray.org
> 
> "2. The issue (*) above was a result of the ray direction being used as-is.
> When I had an angled ray, the length was too large, and overly shortened my
> perpendicular vector.
> When I only used the ray projection onto the xz plane, all of my perpendicular
> vectors were of the proper length."
> 

Thanks Bill.

I think the normalization - including y - is necessary for other reasons 
like the generation of the polynomials, but I also believe I see your 
point about what is needed for the initial bounding cylinder check, 
specifically. I'll try with branch-off code which drops the 'y' 
component for the initial cylinder test only.

Aside: I'd make a moderate bet this tangled with the issues I had in 
some rotation about x tests where parts (partial segments/intervals) of 
the sor would drop out. IIRC, those tests included negative on curve 
(between end control points, points). We'll see.

Bill P.

[Bald Eagle] Re: SOR documentation [171 days 9 hours and 16 minutes ago]

Fri, 24 Oct 2025 03:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> So at present, I believe that I have code that reliably tests for intersections
> with the infinite cylinder, and once I fix the issue with the end caps, then I
> will begin to run some comprehensive tests. (*)

Well, that took way longer than it should have.
It would have probably gone a lot faster if I wasn't stupid and if the paper
explained the code better, or wrote it in a way that showed the pairing of
functions in a use case.

Once I hunted down why everything seemed half-right, upside-down, and
inside-out, I finally got the bounded cylinder to render without any residual
infinite cylinder hits.

> After that, I can either let you look over and test the code on your own, or I
> can work on plugging it into the Section 3.9 raytracer as a function call.

I kinda got a rectangle, which I'm optimistically hoping was my cylinder.
I was still using radius and other data from the sphere sample raytracer, and
when I "fixed" that, I get a black render.

However, now I just have to debug the function call and subsequent calculations,
and I'm hoping to get an actual homemade render soon.

Here's my SDL test scene shooting a bunch of rays from a grid, all having the
same direction vector, and showing missed rays (red), entry hits (green), and
exit hits (blue).

I think it's good enough to begin testing the Catmull-Rom bounding.

- BW

Also, there is a mouse in my kitchen.
Happens every year around this time.   :\

[Bald Eagle] Re: SOR documentation [171 days 19 hours and 16 minutes ago]

Thu, 23 Oct 2025 17:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

@Ingo:  Thank you!

@all: In addition to:
> (*)  I have made a list of 16 different types of rays to test, and want to
> parameterize them so that I can just auto-calculate rays for any cylinder
> parameters I enter.
>
> (1) Ray parallel to cylinder axis, which misses the cylinder
> (2) Ray that is skew/perpendicular to cylinder axis which misses the cylinder
> (3) Ray parallel to cylinder axis, which intersects the cylinder edge
> (4) Ray that is skew/perpendicular and that intersects tangentially
> (5) Ray parallel to cylinder axis, which intersects the cylinder inside
> (6) Ray that is skew/perpendicular and that intersects inside
> Diagonal rays that:
> (7) hit the bottom end cap, then the top end cap (non-perpendicularly)
> (8) hit the cylinder then the bottom end cap
> (9) hit the top end cap then the cylinder
> (10) hit the cylinder then the top end cap
>
> (11) Ray that is parallel to bottom end cap and misses
> (12) Ray that is parallel to bottom end cap and intersects
> (13) Ray that is parallel to top end cap and misses
> (14) Ray that is parallel to top end cap and intersects
> (15) Ray that clips a bottom corner
> (16) Ray that clips a top corner

I also have to create cases starting on the surface of the cylinder as well as
originating from the interior of the cylinder.

- BE

[ingo] Re: SOR documentation [171 days 22 hours and 46 minutes ago]

Thu, 23 Oct 2025 14:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Appreciate you tracking that down for me.
>
Sent

ingo

[Bald Eagle] Re: SOR documentation [171 days 23 hours and 16 minutes ago]

Thu, 23 Oct 2025 13:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
> > version of source code are you seeing this?
>
> Right because that line is not explicitly there.
> D is implicitly defined as the ray direction.
>
> Then in line 256 we do:    len = D.length();
>
> Which is why we need to get rid of the y component for reasons explained.
>
> So really what we need is an extra line that REdefines the _projected_ ray
> direction as D = <D.x, 0, D.y> before that length and normalization take place.
>
> - BW

https://news.povray.org/web.68e8688f251da1bc1f9dae3025979125%40news.povray.org

"2. The issue (*) above was a result of the ray direction being used as-is.
When I had an angled ray, the length was too large, and overly shortened my
perpendicular vector.
When I only used the ray projection onto the xz plane, all of my perpendicular
vectors were of the proper length."

[Bald Eagle] Re: SOR documentation [171 days 23 hours and 21 minutes ago]

Thu, 23 Oct 2025 13:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I'll look on my other computer at work tomorrow.

No, I do not have that one.
Appreciate you tracking that down for me.

- BW

[Bald Eagle] Re: SOR documentation [171 days 23 hours and 31 minutes ago]

Thu, 23 Oct 2025 13:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> The benefits of (2) depend on:
>
> a) how much void space there is between that outer cylinder and all the
> inner per segment ones.

Yes, that is a better way to express what is going on.

> b) the alignment of rays with the bounding box used for global bounding.
> I looked too at completely eliminating the initial cylinder bound test
> as we already do cylinder bounding for each segment / interval.

I was having some troubles getting my endcap intersection tests to work
properly.
I think in the pre-work absorbing coffee phaze/haze that I figured out half of
that.

The second half may be directly related and solved by that realization.

So at present, I believe that I have code that reliably tests for intersections
with the infinite cylinder, and once I fix the issue with the end caps, then I
will begin to run some comprehensive tests. (*)

After that, I can either let you look over and test the code on your own, or I
can work on plugging it into the Section 3.9 raytracer as a function call.

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.9#The_idea_and_the_code

- BW

(*)  I have made a list of 16 different types of rays to test, and want to
parameterize them so that I can just auto-calculate rays for any cylinder
parameters I enter.

(1) Ray parallel to cylinder axis, which misses the cylinder
(2) Ray that is skew/perpendicular to cylinder axis which misses the cylinder
(3) Ray parallel to cylinder axis, which intersects the cylinder edge
(4) Ray that is skew/perpendicular and that intersects tangentially
(5) Ray parallel to cylinder axis, which intersects the cylinder inside
(6) Ray that is skew/perpendicular and that intersects inside
Diagonal rays that:
(7) hit the bottom end cap, then the top end cap (non-perpendicularly)
(8) hit the cylinder then the bottom end cap
(9) hit the top end cap then the cylinder
(10) hit the cylinder then the top end cap

(11) Ray that is parallel to bottom end cap and misses
(12) Ray that is parallel to bottom end cap and intersects
(13) Ray that is parallel to top end cap and misses
(14) Ray that is parallel to top end cap and intersects
(15) Ray that clips a bottom corner
(16) Ray that clips a top corner

[Bald Eagle] Re: SOR documentation [172 days 2 hours and 36 minutes ago]

Thu, 23 Oct 2025 10:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
> version of source code are you seeing this?

Right because that line is not explicitly there.
D is implicitly defined as the ray direction.

Then in line 256 we do:    len = D.length();

Which is why we need to get rid of the y component for reasons explained.

So really what we need is an extra line that REdefines the _projected_ ray
direction as D = <D.x, 0, D.y> before that length and normalization take place.

- BW

[William F Pokorny] Re: SOR documentation [172 days 5 hours and 36 minutes ago]

Thu, 23 Oct 2025 07:34:30 GMT

On 10/10/25 16:03, William F Pokorny wrote:
> I'm loosely following your sor updates - good work. I'll try and carve 
> out some time to code up your suggested changes in my working yuqk code 
> & do some testing.

OK. Looking specifically at these two suggestions:

1. replace
D = ray.Direction;
with
D = <ray.Direction.x, 0, ray.Direction.z>;

and

2. replace
#if (r0 > Radius2)
with
#if (fabs(r0) > Radius2)

----

1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what 
version of source code are you seeing this?

2) Your fabs() suggestion looks like a win and I plan to adopt it for 
release 20 of yuqk.

---

The benefits of (2) depend on:

a) how much void space there is between that outer cylinder and all the 
inner per segment ones.

b) the alignment of rays with the bounding box used for global bounding. 
I looked too at completely eliminating the initial cylinder bound test 
as we already do cylinder bounding for each segment / interval.

Summarizing the performance changes for a bunch of testing.

------ Worst case bounding box alignment (cyl bound helps most)

56.03 -> 54.79s ---> -2.21% Old to New

55.70 -> 54.79s ---> -1.63% No_InitialCylTest to New

------ Best case bounding box alignment (cyl bound helps least)

43.99 -> 43.89s ---> -0.23%   Old to New

44.47 -> 43.89s ---> -1.30%   No_InitialCylTest to New

------ Turning global bounding completely off in yuqk with '-b'

100.72 -> 98.01s ---> -2.69%  Old to New

  98.44 -> 98.01s ---> -0.44%  No_InitialCylTest to New (*)

(*) Where every ray sees the initial cylinder test (New) vs not, the 
performance is less different due the expensive sqrt() starting to eat 
the better in bounding benefit. The change is still a win because we're 
not running without global bounding except in rare cases.

Bill P.

[Bald Eagle] Re: SOR documentation [172 days 12 hours and 56 minutes ago]

Thu, 23 Oct 2025 00:15:00 GMT

"ingo" <nomail@nomail> wrote:

> looks interesting. do you need it or do you already have it? I can mail it.
>
> ingo

Thanks Ingo.
Let me check and see if I was able to get that one.

I'll look on my other computer at work tomorrow.
I was in the midst of a flurry of activity and can't recall if I managed to get
that one.

The original sor {} paper(s) for our source code would be very nice to have.  ;)

- BW

[ingo] Re: SOR documentation [173 days 5 hours and 16 minutes ago]

Wed, 22 Oct 2025 07:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 2025 paper, if someone can access the full article.
>
>
https://www.researchgate.net/publication/3904359_Ray_tracing_surfaces_of_revolution_An_old_problem_with_a_new_perspec
ti
> ve

looks interesting. do you need it or do you already have it? I can mail it.

ingo

[Bald Eagle] Re: SOR documentation [173 days 19 hours and 6 minutes ago]

Tue, 21 Oct 2025 18:05:00 GMT

2025 paper, if someone can access the full article.

https://www.researchgate.net/publication/3904359_Ray_tracing_surfaces_of_revolution_An_old_problem_with_a_new_perspecti
ve

Ray tracing surfaces of revolution: An old problem with a new perspective
February 2001Proceedings of Computer Graphics International Conference, CGI

Abstract
We present a new subdivision scheme that is shown to improve the performance of
ray tracing surfaces of revolution over Kajiya's (1983) classical work. This is
based on a monotonic interval partitioning of a generatrix of a surface of
revolution. The algorithm has a search complexity upper bound of O(log(m n)) for
m monotonic intervals and n subdivisions for each interval and runs up to three
times faster on large scenes. This method also suggests a novel hybrid bounding
volume scheme that reduces this number of intersection tests between a ray and
the actual object surface

[Bald Eagle] Re: SOR documentation [183 days 1 hour and 16 minutes ago]

Sun, 12 Oct 2025 11:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> I'm loosely following your sor updates - good work. I'll try and carve
> out some time to code up your suggested changes in my working yuqk code
> & do some testing.

Thank you, Sir.
I'm hoping that at least a little bit of improvement will come of all of this.

Interested in your thoughts about the possibility of breaking the sor {} up into
individual spline segments for rendering to optimize the cylindrical bounding.

- BW

[William F Pokorny] Re: SOR documentation [184 days 17 hours and 8 minutes ago]

Fri, 10 Oct 2025 20:03:01 GMT

On 10/9/25 22:08, Bald Eagle wrote:
> And here is a much simplified diagram showing only 3 rays, with all extraneous
> lines removed.
> 
> Only the rays and the perpendicular distances are shown, color coded for
> bounding intersection test state.
> 

I'm loosely following your sor updates - good work. I'll try and carve 
out some time to code up your suggested changes in my working yuqk code 
& do some testing.

Bill P.

[Bald Eagle] Re: SOR documentation [184 days 23 hours and 56 minutes ago]

Fri, 10 Oct 2025 13:15:00 GMT

Desmos live graphing

Move the ray origin or the direction vector endpoint.
Very useful for working things out.

https://www.desmos.com/calculator/o50ybsmkw3

- BE

[Bald Eagle] Re: SOR documentation [185 days 11 hours and 1 minute ago]

Fri, 10 Oct 2025 02:10:00 GMT

And here is a much simplified diagram showing only 3 rays, with all extraneous
lines removed.

Only the rays and the perpendicular distances are shown, color coded for
bounding intersection test state.

[Bald Eagle] Re: SOR documentation [185 days 11 hours and 6 minutes ago]

Fri, 10 Oct 2025 02:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Next post will fix that with fabs(r0)

As you can see, there is a lot more red in this render, showing the removal of
erroneous bounding intersection positives, and the rays fail on both the left
and the right now, with only the rays that actually intersect the bounding
cylinder triggering the root-solving phase.

[Bald Eagle] Re: SOR documentation [185 days 11 hours and 11 minutes ago]

Fri, 10 Oct 2025 02:00:00 GMT

GOT IT.

OK, so I am pretty confident that I have the whole initial bounding-test section
of the code worked out.

And that has led me to prove that one problem I thought was happening IS
happening,

and

there's another issue that is taking place that might explain why sometimes some
of the segments fail to render.

> Diagrammatically, it's all looking good, but for some strange reason, the
> perpendicular distance seems to be shorter than it should be, with the error
> increasing the farther away the ray is. (*)

1. The rays that give a negative perpendicular dot product erroneously test as
hitting the bounding cylinder, and so a bunch of root solving gets done that
shouldn't be.

1a.  The code tests a bounding cylinder that is based on the largest diameter of
the whole sor {}.   But the sor {} is not so much a single object as it is a
stack of individual segments.
I believe that we ought to be testing intersection with each individual segment
to optimize the bounding tests.

2. The issue (*) above was a result of the ray direction being used as-is.
When I had an angled ray, the length was too large, and overly shortened my
perpendicular vector.
When I only used the ray projection onto the xz plane, all of my perpendicular
vectors were of the proper length.

2a.  This too-short vector projection likely leads to false positives and causes
additional unnecessary root-finding.


So, I would like to propose 2 correction to this section of the sor {} source.

1. replace
D = ray.Direction;
with
D = <ray.Direction.x, 0, ray.Direction.z>;

and
2. replace
#if (r0 > Radius2)
with
#if (fabs(r0) > Radius2)


The attached diagram is a mess, but what we have is the sor {} circled in black
with the radius equal to the greatest x-value of the control points.

along the bottom, the ray origin changes, and the direction vector stays the
same, resulting in a sweep from left to right.  As you can (hopefully) see, the
parallel lines change from green to red.
The green lines signify a successful _intersection test_ of the ray with the
bounding cylinder.  The red are fails.
The thing to notice here is that only the misses to the right actually fail the
intersection test.
All of the rays on the left pass the test and go on to calculate the roots of
where the ray intersects the polynomial.

The fan shape above that is holding the ray origin fixed, while making the ray
direction go around in a circle 360 degrees.
The same false positive issue occurs.

Next post will fix that with fabs(r0)

[Bald Eagle] Re: SOR documentation [185 days 14 hours and 41 minutes ago]

Thu, 9 Oct 2025 22:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> r0 = P.x * D.z - P.z * D.x;
> and that is only multiplied by the y unit basis vector,
> so since there are no other dimensional units, this directly evaluates to the
> length of the perpendicular y vector, and we don't have to do the expensive
> square root of the sum of the squares.
>
> a is the squared length of the [NORMALIZED and PROJECTED] direction vector
> which, if non-zero, the vector cross product length gets divided by,
> which should be the shortest, perpendicular length.

So what happens is that the "perp dot product" is essentially taking one vector,
rotating it counterclockwise by 90 degrees, and then taking the dot product,
which projects one vector onto the other.
This gives its projected length along the other vector.

And that's supposed to give the perpendicular, shortest distance between the
origin and the ray.

Diagrammatically, it's all looking good, but for some strange reason, the
perpendicular distance seems to be shorter than it should be, with the error
increasing the farther away the ray is.

- BW

If anyone has any ideas what the source of this error is, I'm all ears.

[Bald Eagle] Re: SOR documentation [188 days 12 hours and 36 minutes ago]

Tue, 7 Oct 2025 00:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> a is the squared length of the direction vector
> which, if non-zero, the vector cross product length gets divided by,
> which should be the shortest, perpendicular length.

a is the squared length of the PROJECTED direction vector

> A few minor problems.
> The ray direction vector already gets normalized at the beginning of
> Sor_Intersect, so why are we calculating it's length again, and then checking if
> it's more than zero, when at this point it should always be ONE.

Because although the RAY is normalized, it's PROJECTION isn't unit-length unless
it's parallel to the xz plane.

> Which bring up the potential divide-by-zero error when the normalization
> calculation is done - and there is NO checking THERE!
> And then there is the vector cross product sign issue.
>
> So, after this gets rigorously checked, I'd suggest that
> 1. the ray direction vector length check gets moved to earlier in the code

> 3. Line 276 r0 = P[X] * D[Z] - P[Z] * D[X];
> should be r0 = fabs(P[X] * D[Z] - P[Z] * D[X]);
> so that the "length" is always positive.

- BE

[Bald Eagle] Re: SOR documentation [191 days 16 hours and 46 minutes ago]

Fri, 3 Oct 2025 20:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

>     MInvTransPoint(P, ray.Origin, Trans);
>
>     MInvTransDirection(D, ray.Direction, Trans);

Now I can't really find if and where Trans gets defined as anything but an
Identity matrix in Line 776.

The sor gets created "at the origin" / around the y-axis,
so I'm now presuming that when we do
sor { ... translate <x, y, z>}

that the sor gets created and evaluated in its default position, and then all of
the results just get filtered through the translate transform as a
post-intersection process.

And if THAT's the case, then why do we have all of the transforms in the various
functions when we don't need them?

But then again, I could be missing something, and be completely wrong.

- BE

[Bald Eagle] Re: SOR documentation [191 days 19 hours and 16 minutes ago]

Fri, 3 Oct 2025 17:55:00 GMT

"BW: since this is before we do any projection, and we're only testing height
and
width, can't we have a slanted ray that WOULD intersect the sor spline once it
got rotated around the y-axis?"

This was meant to be deleted, after I had worked all that out.

[Bald Eagle] Re: SOR documentation [191 days 19 hours and 16 minutes ago]

Fri, 3 Oct 2025 17:55:00 GMT

"giving a y vector that is parallel to the 2 projected vectors."

Clearly I meant to write perpendicular.

[Bald Eagle] Re: SOR documentation [191 days 19 hours and 21 minutes ago]

Fri, 3 Oct 2025 17:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> bool Sor::Intersect, line 239 in sor.cpp
>
> Line 276 has the interesting expression:  r0 = P[X] * D[Z] - P[Z] * D[X];

>  /* Get distance of the ray from rotation axis (= y axis). */
....
> Apparently it's a sort of 2D cross-product, or "perp-product"
....
>     #if ((a = Dx * D.x + D.z * D.z) > 0.0)
>             #local r0 = r0/sqrt(a);
>     #end

OK, so r0 gets calculated by taking the vector cross product of
the PROJECTIONS of the ray origin and the ray direction (after they have been
translated into "object space")
[still hunting down how that Trans gets calculated, but I have an idea]

So, since they are projections onto the xz plane, y=0 for both vectors.
that means that two of the 2x2 determinants drop out due to multiplication by 0,
leaving only the one determinant to multiply by the y basis vector,
giving a y vector that is parallel to the 2 projected vectors.

Thus the shortened form P[X] * D[Z] - P[Z] * D[X]

However, in working this out, I had my vectors in different places in the
matrix, and so I got P[Z] * D[X] - P[X] * D[Z] which should just be the opposite
sign of the calculation in code.  Not really a worry, since it's just a vector
cross product.

The potential problem that I see is the test that uses this value:

    /* Test if ray misses object's bounds. */

    #if (r0 > Radius2)                      // Radius2 is xmax of the sor CP's
        #local Result = false;
    #else

If the sign of the vector cross product is negative, then that rejection test
will always fail, and the ray will always move on to have the intersection
tested.   Which, if I'm interpreting all of this correctly, means that all of
the rays on one side of the sor always get fully evaluated for intersections,
this potentially making rendering slower than it needs to be.

Shouldn't we be using at least abs (r0) to account for P-cross-D AND D-cross-P?

In more detail:

First we translate and then normalize the ray direction vector.

Then we test the ray to see if it is above or below the sor
as well as to the left or right of the sor

starting at line 266
    if (((D[Y] >= 0.0) && (P[Y] >  Height2)) ||
        ((D[Y] <= 0.0) && (P[Y] <  Height1)) ||
        ((D[X] >= 0.0) && (P[X] >  Radius2)) ||
        ((D[X] <= 0.0) && (P[X] < -Radius2)))
    {
        return(false);
    }

Line 266 checks if the ray direction is flat or points up, and the ray origin is
higher than the highest sor control point (Height2 = ymax)
So it will never intersect the rotated sor spline
This is OK

Line 267 checks if the ray direction is flat or points down, and the ray origin
is lower than the lowest sor control point (Height1 = ymin)
So it will never intersect the rotated sor spline
This is OK

Line 268 checks if the ray direction is straight or points right, and the ray
origin is to the right of the rightmost sor control point (Radius2 = xmax)
So it will never intersect the rotated sor spline
This is OK

Line 269 checks if the ray direction is straight or points left, and the ray
origin is to the left of the leftmost (rotated) sor control point (-Radius2 =
-xmax)
So it will never intersect the rotated sor spline
This is OK

BW: since this is before we do any projection, and we're only testing height and
width, can't we have a slanted ray that WOULD intersect the sor spline once it
got rotated around the y-axis?

Then we are doing a calculation that purports to be the DISTANCE between the ray
and the y-axis.

Working that out from first principles, it is the geometric problem of
determining the perpendicular distance (the shortest distance) between a point
and a line.
We simplify this by projecting onto 2D since the vertical angle of the ray makes
no difference at this point.
The vector cross product of 2 vectors gives us the area of the parallelogram
defined by those 2 vectors (just use those 2 vectors to make the remaining 2
sides)
The area is also equal to the base times the height of the parallelogram, and so
we solve for the height (H), which is the perpendicular - and therefore the
shortest distance between the point (y-axis in the xz plane, <0, 0, 0>) and the
line (the ray composed of origin and unit directional vector)
That gives us LENGTH (P-cross-D) = H times LENGTH (D)
Rearranging gives us H = LENGTH (P-cross-D) / LENGTH (D)

Now, in code, we have
r0 = P.x * D.z - P.z * D.x;
and that is only multiplied by the y unit basis vector,
so since there are no other dimensional units, this directly evaluates to the
length of the perpendicular y vector, and we don't have to do the expensive
square root of the sum of the squares.

a is the squared length of the direction vector
which, if non-zero, the vector cross product length gets divided by,
which should be the shortest, perpendicular length.

A few minor problems.
The ray direction vector already gets normalized at the beginning of
Sor_Intersect, so why are we calculating it's length again, and then checking if
it's more than zero, when at this point it should always be ONE.
Which bring up the potential divide-by-zero error when the normalization
calculation is done - and there is NO checking THERE!
And then there is the vector cross product sign issue.

So, after this gets rigorously checked, I'd suggest that
1. the ray direction vector length check gets moved to earlier in the code
2. we can do away with recalculating the length, checking for non-zero length,
and dividing the vector cross product length by a ray length which should
already always be 1.
3. Line 276 r0 = P[X] * D[Z] - P[Z] * D[X];
should be r0 = fabs(P[X] * D[Z] - P[Z] * D[X]);
so that the "length" is always positive.

- BE

[Bald Eagle] Re: SOR documentation [192 days 23 hours and 21 minutes ago]

Thu, 2 Oct 2025 13:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > I also cannot find the following 2 functions in the code repository.
> > I can't search without being logged in, and username/pswd are scribbled down
> > somewhere at home.
> >
> >     MInvTransPoint(P, ray.Origin, Trans);
> >
> >     MInvTransDirection(D, ray.Direction, Trans);
> >
> > Anyone?
>
> core/math/matrix.h has the prototypes, hth.
>
> and thx re other thread.
>
>
> regards, jr.

Thanks, jr!

Ah, I think I (mostly) understand now.
matrix.h declares those inline functions for use in the namespace, and the
MInvTransPoint and MInvTransDirection functions just use the
MTransPoint and MTransDirection functions but somehow using the multiplicative
inverse of the transform matrix as input instead of the regular matrix.

in matrix.cpp, (line 535) we have

void Compute_Scaling_Transform (TRANSFORM *result, const Vector3d& vector)
{
    MIdentity (result->matrix);

    (result->matrix)[0][0] = vector[X];
    (result->matrix)[1][1] = vector[Y];
    (result->matrix)[2][2] = vector[Z];

    MIdentity (result->inverse);

    (result->inverse)[0][0] = 1.0 / vector[X];
    (result->inverse)[1][1] = 1.0 / vector[Y];
    (result->inverse)[2][2] = 1.0 / vector[Z];
}

and at line 155, there is:

void MIdentity (MATRIX result)
{
    int i, j;

    for (i = 0; i < 4; i++)
    {
        for (j = 0; j < 4; j++)
        {
            if (i == j)
            {
                result[i][j] = 1.0;
            }
            else
            {
                result[i][j] = 0.0;
            }
        }
    }
}

I'm still trying to get a feel for all of this, having only ever coded in "c++"
(Arduino) for maybe 6 months, several years back.

(Currently reading www.learncpp.com in small spurts, then I'll probably start
going through things with Stroustrup in hand to more rigorously work things
out.)

I guess perhaps in the same way that we can have operator overloading, where I
have two functions with the same name, but different input types,
a single function can yield one of several different types of outputs if that
class member access operator -> is used ...?

- BW

[jr] Re: SOR documentation [192 days 23 hours and 56 minutes ago]

Thu, 2 Oct 2025 13:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I also cannot find the following 2 functions in the code repository.
> I can't search without being logged in, and username/pswd are scribbled down
> somewhere at home.
>
>     MInvTransPoint(P, ray.Origin, Trans);
>
>     MInvTransDirection(D, ray.Direction, Trans);
>
> Anyone?

core/math/matrix.h has the prototypes, hth.

and thx re other thread.


regards, jr.

[Bald Eagle] Re: SOR documentation [193 days and 16 minutes ago]

Thu, 2 Oct 2025 12:55:00 GMT

I also cannot find the following 2 functions in the code repository.
I can't search without being logged in, and username/pswd are scribbled down
somewhere at home.

    MInvTransPoint(P, ray.Origin, Trans);

    MInvTransDirection(D, ray.Direction, Trans);

Anyone?

[Bald Eagle] Re: SOR documentation [194 days 17 hours and 56 minutes ago]

Tue, 30 Sep 2025 19:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> So A through D have something to do with the spline segments.
> I just don't "see" where they come from or what their exact meaning is.
> Perhaps somewhere else farther upstream in the code is a place where the control
> points get grouped in sets of 4, and so A through D would be sets of control
> points.

And this is the challenge of trying to do this piecemeal, in fits and starts
during random available 15 min opportunistic time slots.

Just a few lines above that is:

/* Step through the list of intersections. */

    for (j = 0; j < cnt; j++)
    {
        /* Get current segment. */

        Entry = &Spline->Entry[intervals[j].n];

and I'm kinda guessing that intervals comes from insert_hit in
https://github.com/POV-Ray/povray/blob/master/source/core/bounding/boundingcylinder.cpp

So that's my current working theory.

[Bald Eagle] Re: SOR documentation [195 days 23 hours and 1 minute ago]

Mon, 29 Sep 2025 14:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

I have a functional, if not yet rigorous understanding about the ray-radius
intersection test(s).  I am hoping to understand it completely enough to make
one of my explanatory diagrams.

> immediately following that, I have a comparison of the length of the ray
> direction vector D with some variable "a", which due to poor source code
> documentation, I have no idea what "a" exactly is, or why if they are equal that
> r0 has to get divided by the sqrt of a.
>
>     #if ((a = Dx * D.x + D.z * D.z) > 0.0)
>             #local r0 = r0/sqrt(a);
>     #end

I believe I see what's going on here.
in c++, == is a comparison.
= is an assignment.

So the #if line is simultaneously assigning the evaluation of the expression to
a, and then comparing it's value to 0.0.

> I also have Entry->A (through D) which I need to figure out.

This has to do with the arrow operator, or "Class Member Access Operator".

In sor.h, we have

struct Sor_Spline_Entry_Struct final
{
    DBL A, B, C, D;
};

and

struct Sor_Spline_Struct final
{
    int References;
    SOR_SPLINE_ENTRY *Entry;
    BCYL *BCyl;                 /* bounding cylinder.                  */
};

So "Entry" is a pointer to SOR_SPLINE_ENTRY, which has class members A through
D.

"Entry->A" is a whole identifier, which snakes through the 2 structs to identify
and use A.

and

class Sor final : public ObjectBase
{
    public:
        int Number;
        SOR_SPLINE *Spline;      /* List of spline segments     */
.... etc.

So A through D have something to do with the spline segments.
I just don't "see" where they come from or what their exact meaning is.
Perhaps somewhere else farther upstream in the code is a place where the control
points get grouped in sets of 4, and so A through D would be sets of control
points.

- BW

[Bald Eagle] Re: SOR documentation [198 days 22 hours and 26 minutes ago]

Fri, 26 Sep 2025 14:45:00 GMT

I'm still working on unraveling the source code for
bool Sor::Intersect, line 239 in sor.cpp

Line 276 has the interesting expression:  r0 = P[X] * D[Z] - P[Z] * D[X];
and I wasn't sure what that exactly did, especially since the comment that
precedes it is
 /* Get distance of the ray from rotation axis (= y axis). */
and that didn't look like any distance formula that I've ever seen.
The minus sign certainly helped obscure its meaning and purpose.

Apparently it's a sort of 2D cross-product, or "perp-product"

https://s.goessner.net/articles/crossProductHarmful.html
Also being covered in Graphics Gems IV:
Hill, F. S., Jr., The Pleasures of `Perp Dot' Products, p. 138-148.

And since I'm speculating that there are other examples this to be found in
source, I'm documenting this fully here for future reference.

immediately following that, I have a comparison of the length of the ray
direction vector D with some variable "a", which due to poor source code
documentation, I have no idea what "a" exactly is, or why if they are equal that
r0 has to get divided by the sqrt of a.

    #if ((a = Dx * D.x + D.z * D.z) > 0.0)
            #local r0 = r0/sqrt(a);
    #end

I also have Entry->A (through D) which I need to figure out.

- BW

[William F Pokorny] Re: SOR documentation [213 days 10 hours and 44 minutes ago]

Fri, 12 Sep 2025 02:27:06 GMT

On 9/11/25 10:36, Bald Eagle wrote:
>> Attached an image of some more testing. It includes the fix for the
>> segment blink out issue & that fix looks good thus far.
> So what did you do?

The current fix is:

     if ((r[n] >= y[0]) && (r[n] <= y[1]))
     {
//      x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
         double tmpVal = (r[n] * (r[n] * (r[n] * A + B) + C) + D);
         if (tmpVal>=0.0)
             x[n] = sqrt(tmpVal);
         else
         {
             tmpVal = std::abs(tmpVal);
             x[n] = sqrt(tmpVal);
             x[n] *= -1.0;
         }
     }

As for the bounding suggestion, I don't know. Of note is that the 
Radius1 value is never used that I see.

Something I did try was faking a user bounding radius multiplier option. 
In some configurations where only a subset of the on curve points were 
negative in x. It often helped with apparent clipping - but there always 
remained some issue with the the ray directions relative to the overall 
sor - where all or part of sor 'segment(s)' would drop away (this an 
issue apart from the entire-segment blink out issue up top).

My wild guess. There are internally calculated A,B,C,D values used for 
the quadratic eqn solved while setting the two bounding radii values. 
Those calculated values involve the x values as given for the sor point 
set. Maybe something could go 'more right' there when negative values 
are present - I don't know.

Bill P.

[Bald Eagle] Re: SOR documentation [213 days 22 hours and 31 minutes ago]

Thu, 11 Sep 2025 14:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Attached an image of some more testing. It includes the fix for the
> segment blink out issue & that fix looks good thus far.

So what did you do?

in line 1082
x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);

I'd suggest changing that something like

x[n] = sqrt( fabs(r[n] * (r[n] * (r[n] * A + B) + C) + D) );

> Not going to go through the image in detail, but in answer to your
> question about on curve points going negative it looks like a no go
> without a deep dive and probable re-work of the current code.

I'd suggest the above, if you haven't already done that.

Also, it may have something to do with calculating the intersections.

There's a check on Radius2 that I saw, so see what happens when you change:

Lines 1110-1111
Radius1 = xmin;
Radius2 = xmax;

to use fabs()

> For reasons I don't understand, when I allow on curve points to go
> negative the camera ray direction affects results. This shown in the
> fourth row where the sor slowly disappears then reappears as rotated
> about x.

> The descending in y on curve points doesn't work at all.

Not surprising - all the checks for the control point order need to be
rewritten.

> You had mentioned not being able to flip the two control points in y.
> Where everything I'd tried to that point seemed to work.

I'll have to do some more experimenting when I get the chance.

> You also
> mentioned this bit of code in sor.cpp :
>
> if ((fabs(P[i+2][Y] - P[i][Y]) < gkMinIsectDepthReturned) ||
>      (fabs(P[i+3][Y] - P[i+1][Y]) < gkMinIsectDepthReturned))
> {
> throw POV_EXCEPTION_STRING("Incorrect point in surface of revolution.");
> }
>
> I'm finding it is this run time check which sometimes doesn't allow
> control points flipping in y.

That def seems to be related to what you're seeing in those last 2 rows - since
the cp's are nearly coincident in y.

> The shapes with negative control points do break up more
> often, but as we found this can happen today with certain point lists.

Do you think as a quick fix, we could just add -ymin to all the values to
translate everything into the first quadrant, starting at y=0, and then
translate everything back after the math gets done?

Very nice that some of this is getting worked out after 30 years.  :)

- BW

[William F Pokorny] Re: SOR documentation [214 days 3 hours and 12 minutes ago]

Thu, 11 Sep 2025 09:58:33 GMT

On 9/10/25 11:16, William F Pokorny wrote:
> If you're referring to the sqrt I think you are, you've guessed 
> correctly! ðŸ™‚ I have a potential fix for it. The sqrt(-) along
with some 
> fine detail in how std::min(), std::max() work when passed a -nan value 
> as the first argument vs the second argument cause the segment blink out 
> issue. Only limited testing thus far. Maybe I'll get to more tonight.

Attached an image of some more testing. It includes the fix for the 
segment blink out issue & that fix looks good thus far. For testing I 
disabled all the point list sanity checking to see what works and not.

---

Not going to go through the image in detail, but in answer to your 
question about on curve points going negative it looks like a no go 
without a deep dive and probable re-work of the current code.

For reasons I don't understand, when I allow on curve points to go 
negative the camera ray direction affects results. This shown in the 
fourth row where the sor slowly disappears then reappears as rotated 
about x.

---

The descending in y on curve points doesn't work at all.

---

Allowing the first and last control points to go negative is fine and I 
plan to add that relaxing to the blank out fix for yuqk's next release.

---

You had mentioned not being able to flip the two control points in y. 
Where everything I'd tried to that point seemed to work. You also 
mentioned this bit of code in sor.cpp :

if ((fabs(P[i+2][Y] - P[i][Y]) < gkMinIsectDepthReturned) ||
     (fabs(P[i+3][Y] - P[i+1][Y]) < gkMinIsectDepthReturned))
{
throw POV_EXCEPTION_STRING("Incorrect point in surface of revolution.");
}

I'm finding it is this run time check which sometimes doesn't allow 
control points flipping in y. For yuqk what will be in the next release 
is some added error text when that check trips so it is easier to 
understand what is wrong.

Error! Problem point in sor segment 0 point set.
fabs(P[2][Y] - P[0][Y] || fabs(P[3][Y] - P[1][Y])
fabs(0.5 - 0.5 || fabs(0.9 - 0) < 4.44089e-08

The center images in the bottom two rows(*) of the attached image trip 
this check and error. So, that code is catching some 'particular' cases 
where given the control point locations relative to other on curve 
points doesn't render correctly.

(*) Those rows are start the control points at one extreme and slowly 
flip them to the opposite extreme in y moving left to right in the lower 
two rows.

---

So with the segment blink out fix, it does look like more could be 
allowed as valid point sets for the sor & yuqk will adopt those 
relaxations. The shapes with negative control points do break up more 
often, but as we found this can happen today with certain point lists.

(I've not really looked at intersections and differences as yet)

Bill P.

Aside: Somewhere I should mentioned too that that blink out fix corrects 
the blink out, but in certain cases it also slightly corrects bounding 
cylinders where due how min/max work there was no blink out. In other 
words some fringe fixes/differences might appear too due the blink out fix.

[William F Pokorny] Re: SOR documentation [214 days 21 hours and 54 minutes ago]

Wed, 10 Sep 2025 15:16:51 GMT

On 9/10/25 09:27, Bald Eagle wrote:
> I'll make a speculative prediction and say that the algorithm will try to take
> the sqrt of that negative radius and fail - either throwing an error, or just
> blanking out that portion of the curve - or the whole segment.

Thanks for reference! :-)

If you're referring to the sqrt I think you are, you've guessed 
correctly! :-) I have a potential fix for it. The sqrt(-) along with 
some fine detail in how std::min(), std::max() work when passed a -nan 
value as the first argument vs the second argument cause the segment 
blink out issue. Only limited testing thus far. Maybe I'll get to more 
tonight.

I see some other not really wrong, but not optimal stuff happening too 
with the cylinder segment bounding in y. Sort of as if it was written to 
support on curve points in ascending or descending order less any 
optimization for the y coordinates (The cylinders get taller and taller 
as you have more segments instead of aligning with each of the segments 
in y).

Bill P.

[Bald Eagle] Re: SOR documentation [214 days 23 hours and 41 minutes ago]

Wed, 10 Sep 2025 13:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
.... how the internal cylinder bounding is being done. I

Check out Fig. 5, pg 11
https://www.cemyuksel.com/research/catmullrom_param/catmullrom_cad.pdf

We might have better luck if we changed how the bounding is done.
It also shows how I can create a set of control points where the curve
overshoots the control point polygon, and so I can use that to have the
interpolated curve cross over the rotation axis to see what happens.

I'll make a speculative prediction and say that the algorithm will try to take
the sqrt of that negative radius and fail - either throwing an error, or just
blanking out that portion of the curve - or the whole segment.

I'll probably have to convert most of the solver code to SDL and then use what I
get out of that to start to answer some other questions.

- BW

[Bald Eagle] Re: SOR documentation [215 days 17 hours and 21 minutes ago]

Tue, 9 Sep 2025 19:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Now, moving down to line 1078, we have:
>         while (n--)
>         {
>             if ((r[n] >= y[0]) && (r[n] <= y[1]))
>             {
>                 x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
>             }
>         }
>
> and I'm confused as to why r is getting compared to the y value and not the x
> value.  It seems that the radius ought to be compared to the control point x
> values - unless I'm missing something.

This is because good ole' Dieter likes to mix and match labels between the
comments and the code.
r here is the array of roots found by the polynomial solver, not the radius of
the sor at that height (which is x).  So we're just checking to make sure we're
testing between the roots.  Still need to see why the roots bracket a spline
segment . . .

- BW

[Bald Eagle] Re: SOR documentation [215 days 19 hours and 31 minutes ago]

Tue, 9 Sep 2025 17:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

>      <+1.5,+0.91> // C4
>
> and the shape breaks apart(a)(b). In the bottom row I changed that last
> control point to:
>
>     <+1.5,+0.901> // C4
>
> and the entire top segment drops out.

Looking at the code, I'd say that either it's the solver or the EPSILON value -
or both.  That's definitely a weird result, and you have an excellent sense for
employing good incidental test cases.
I'd say that this is the kind of thing where more extensive diagramming of the
actual control points and cubic spline would be helpful, and maybe have a grid
of sor {} objects with varying control points.

I have a bit of trouble putting all of the pieces in sor.cpp together to see how
all of the data flows in order to make the actual sor on-screen.  If you could
explain that briefly, that would be a huge help in my ongoing investigations and
debugging.

Do you see anywhere that the code would simply not render the surface?  Any way
to indicate to the user that it does such a thing?

> (b) In yuqk the parts of the sor there all look good. In v3.8 beta 2,
> the results for top segment are noisy; Likely solver differences.

In the source:
Where is "Number" defined?
Where is EPSILON defined?

Some things I've noticed and am confused by:

In void Sor::Compute_Sor(Vector2d *P, RenderStatistics& stats) [Line 960]

starting at line 1003, we have:
    for (i = 0; i < Number; i++)
    {
        if ((fabs(P[i+2][Y] - P[i][Y]) < EPSILON) ||
            (fabs(P[i+3][Y] - P[i+1][Y]) < EPSILON))
        {
            throw POV_EXCEPTION_STRING("Incorrect point in surface of
revolution.");
        }

which is the only check that throws that error, and because it uses fabs (),
that doesn't actually check for the control points doubling back on themselves,
it seems like that's a check to make sure the tangent doesn't have a slope of
zero.

Now, moving down to line 1078, we have:
        while (n--)
        {
            if ((r[n] >= y[0]) && (r[n] <= y[1]))
            {
                x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
            }
        }

and I'm confused as to why r is getting compared to the y value and not the x
value.  It seems that the radius ought to be compared to the control point x
values - unless I'm missing something.

Also, as far as I'm aware, the Catmull-Rom spline doesn't have as well-defined a
control polygon as a Bezier spline does, and so I'm wondering if there needs to
be a better bounding estimate for the min and max values.

So something that's been bouncing around the ole' noggin but I haven't yet
articulated is:
If we interpolate a spline with entirely valid control points, but the
interpolated part winds up crossing the rotation axis - what happens?

[Bald Eagle] Re: SOR documentation [216 days and 6 minutes ago]

Tue, 9 Sep 2025 13:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/8/25 14:06, Bald Eagle wrote:
> >> (*) I tried inverting all the on curve points and this does NOT work as
> >> I incorrectly remembered for some recent sor{} post - that must be a
> >> lathe{} only thing.
> ...> Right, because sor is an implicit interpolation, and lathe is a
> parametric
> > interpolation.
>
> Unsure. With the lathe the reason to flip the point set order is to flip
> the normals (and perhaps too textures on parts of the resulting shape). Ref:
>
>
https://news.povray.org/povray.binaries.images/thread/%3C5745b756%241@news.povray.org%3E/

Yes, but this is not what I'm talking about.
I'm not trying to reverse the order of the entire point set, (which _ought_ to
be a valid point set for the sor - I think it's just "lazily" coded to check in
one direction - I think it could easily check for points going sequentially in
either direction)  I'm just trying to use ANY value for either the first or last
control point to change the tangent direction at the endpoints.

> I see no reason this couldn't be true for the sor too - even if all that
> happens internally is normalizing the decreasing point during parsing
> and setting a flag to flip the normals.

Yes, but even if we still just had the current sor monotonically increasing in
y, we could just switch texture and interior_texture to achieve the same result.
But I agree that given your point, sor could really use a much more in-depth
investigation and possible/probable recoding.

With regard to the abs() implementation, that was only to be applied to the r
result of the sor, so that anything that crossed the rotation axis would be a
valid control point.  I just didn't see why a mirror-image control point would
be invalid.

> That said. When I relaxed the parser's sanity checking so I could try
> and render the reversed point set I got no sor result. Given other
> discoveries this morning this might also be related to segments simply
> dropping out due how the internal cylinder bounding is being done.

I skimmed over the internal bounding part, but can try to devote some more time
to verifying what it does and how.

One thing that I noticed with going over the source code several different
objects is that we have a repetition of spline code - why don't we have all the
splines in one place and use them as the basis for all the various objects that
use them?

Simplifying things like that would make sure that the splines are consistent
between the various objects, and potentially open up the ability to use
user-defined spline interpolations for defining the outline of the objects.

- BW

[William F Pokorny] Re: SOR documentation [216 days 1 hour and 26 minutes ago]

Tue, 9 Sep 2025 11:45:00 GMT

On 9/8/25 14:06, Bald Eagle wrote:
>> (*) I tried inverting all the on curve points and this does NOT work as
>> I incorrectly remembered for some recent sor{} post - that must be a
>> lathe{} only thing.
...> Right, because sor is an implicit interpolation, and lathe is a 
parametric
> interpolation.

Unsure. With the lathe the reason to flip the point set order is to flip 
the normals (and perhaps too textures on parts of the resulting shape). Ref:

https://news.povray.org/povray.binaries.images/thread/%3C5745b756%241@news.povray.org%3E/

I see no reason this couldn't be true for the sor too - even if all that 
happens internally is normalizing the decreasing point during parsing 
and setting a flag to flip the normals.

That said. When I relaxed the parser's sanity checking so I could try 
and render the reversed point set I got no sor result. Given other 
discoveries this morning this might also be related to segments simply 
dropping out due how the internal cylinder bounding is being done. I 
don't know. I don't know. I don't know.

Bill P.

[William F Pokorny] Re: SOR documentation [216 days 1 hour and 37 minutes ago]

Tue, 9 Sep 2025 11:33:42 GMT

On 9/8/25 11:10, William F Pokorny wrote:
> Thinking aloud, it might be possible to allow x<0 control points - ONLY 
> - where both on curve points and off curve control points are forced to 
> be always ascending (>= previous) in y. This, probably, would cover the 
> 'useful' x<0 control point cases while preventing the curve from 
> crossing into -x?Â  I'll try to play with this thought some more when I 
> again have time - need to run.

I spent some time on this idea and, on seeing some issues where entire 
segments would just blink out of existence, I went back to trying more 
parser legal point sets and found similar weirdness. :-(

There exists internal cylinder bounding of segments intended to reduce 
the number of calls to the solvers. My guess is that code isn't 
completely solid, but who knows.

Attached an image where the top row uses the currently legal point set of:

     <+1.5,-0.01> // C0
     <+0.4, 0.0>  // P1
     <+0.3, 0.5>  // P2
     <+0.4, 0.9>  // P3
     <+1.5,+0.91> // C4

and the shape breaks apart(a)(b). In the bottom row I changed that last 
control point to:

    <+1.5,+0.901> // C4

and the entire top segment drops out.

So yep...

Bill P.

(a) Curve going negative can already happen without negative control 
points.

(b) In yuqk the parts of the sor there all look good. In v3.8 beta 2, 
the results for top segment are noisy; Likely solver differences.

[Bald Eagle] Re: SOR documentation [216 days 15 hours and 46 minutes ago]

Mon, 8 Sep 2025 21:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

using
3.8.0-beta.2+gh7.msvc14.win64


scene file attached

[Bald Eagle] Re: SOR documentation [216 days 17 hours and 36 minutes ago]

Mon, 8 Sep 2025 19:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Ah, and to quote Alain:
>
> "When using cutaway_texture, the object used to cut away part of the
> rest must NOT have any texture."
>
> Unsure your set up with respect to the particular post, but the overall
> images suggest both the box and sor might have textures ?

I initially did leave the textures attached to the objects when first doing the
differences, but my code is such that it was easy to leave them textureless for
use with cutaway_textures, so no, that doesn't appear to be the problem.

Will post the scene file when I get out of here in an hour.

With regard to c_t not using interior_texture, that seems to be a reasonably
expected behaviour, and one which I'd have to think hard about how to code a
workaround for.

I also had that recent scene where I was getting washed-out colors, and I really
don't believe that I have any overlapping objects, however I will have to make a
detailed check to be absolutely sure.

- BW

[Bald Eagle] Re: SOR documentation [216 days 19 hours and 1 minute ago]

Mon, 8 Sep 2025 18:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> First, Are you using v3.8 beta 2 for all your testing?
Probably.  Will confirm when I get home.

> Second, Did you take care when you did the differences with the box to
> not have coincident surfaces with the caps (if there) or that y height
> when the caps are not there?

Yeah, I have an E value set that I routinely use to avoid CS.
I had the caps present when I skipped adding/subtracting that, and then when I
fixed it, the caps went away.

> (*) I tried inverting all the on curve points and this does NOT work as
> I incorrectly remembered for some recent sor{} post - that must be a
> lathe{} only thing.

Right, because sor is an implicit interpolation, and lathe is a parametric
interpolation.

Thanks for checking on these.  Will compare notes when I get back later.

- BW

[William F Pokorny] Re: SOR documentation [216 days 22 hours ago]

Mon, 8 Sep 2025 15:10:19 GMT

On 9/8/25 09:52, William F Pokorny wrote:
> I'll try and look at some of the other issues you mention as I have 
> time; Including temporarily removing the x>0.0 restriction on the first 
> and last points to see what happens. Aside: we did remove a similar 
> restriction for the lathe for v3.8 vs v3.7.

Well, the current code drops portions of the curve that get pulled into 
x<0 territory by control points x<0. See attached image.

Might be fixable / map-able to x>=0 as you, I think, were suggesting 
with the abs() comment. It might even acceptable as a final result, IF, 
the inside tests, normal calculations and uv mapping code map in a sane 
way to the result.

Thinking aloud, it might be possible to allow x<0 control points - ONLY 
- where both on curve points and off curve control points are forced to 
be always ascending (>= previous) in y. This, probably, would cover the 
'useful' x<0 control point cases while preventing the curve from 
crossing into -x?  I'll try to play with this thought some more when I 
again have time - need to run.

Bill P.

[William F Pokorny] Re: SOR documentation [216 days 22 hours and 59 minutes ago]

Mon, 8 Sep 2025 14:11:13 GMT

On 9/8/25 10:04, William F Pokorny wrote:
> Answering without thinking much,

Ah, and to quote Alain:

"When using cutaway_texture, the object used to cut away part of the 
rest must NOT have any texture."

Unsure your set up with respect to the particular post, but the overall 
images suggest both the box and sor might have textures ?

Bill P.

[William F Pokorny] Re: SOR documentation [216 days 23 hours and 6 minutes ago]

Mon, 8 Sep 2025 14:04:37 GMT

On 9/8/25 07:08, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> As shown, when I use cutaway_textures, I DON'T see the expected
>> interior_texture, but the surface texture {}.  And when I use sor {open}, I do
>> not see a hollow infinitely thin surface, I get a solid object sliced in half.
> 
> Also, I'm curious as to why the cutaway_textures feature requires the use of an
> untextured object as a cutter to be able to function properly.
> One would reasonably expect that we should be able to use any object.
> If, as per wiki documentation, the cutaway_textures feature result is based on
> insidedness tests, then the texture of the cutter should be irrelevant.
> 
> - BE
> 
> 
> 

Answering without thinking much, I don't think the cutaway_textures 
feature copies the inside texture(*), but maybe I'm not remembering 
correctly.

A reminder the yuqk fork fixed a cutaway_textures bug which exists in 
official POV-Ray releases. See:

https://news.povray.org/povray.bugreports/thread/%3C65806257%241%40news.povray.org%3E/

Bill P.

(*) - The inside_texture{}s feature has a few inconsistencies, besides, 
with respect to how texture{}s are handled.

[William F Pokorny] Re: SOR documentation [216 days 23 hours and 18 minutes ago]

Mon, 8 Sep 2025 13:52:21 GMT

On 9/7/25 12:10, Bald Eagle wrote:
> According to the sor {} tutorial in the wiki:
> https://wiki.povray.org/content/ 
> Documentation:Tutorial_Section_3#Surface_of_Revolution_Object
> "First and last point from the list are used to determine slope at beginning and
> end of curve and can be defined for any height."
> 
> However, I find that to not be the case.
> Swapping the first and last control points causes a
> "Parse Error: Incorrect point in surface of revolution"
> But if I only set the LAST control point y value to zero, technically making the
> spline double-back in the y-direction, everything works fine.

First, Are you using v3.8 beta 2 for all your testing?

Second, Did you take care when you did the differences with the box to 
not have coincident surfaces with the caps (if there) or that y height 
when the caps are not there?

As to the point above, I don't see what you see. The following list 
works for me where I have flipped / crossed the first and last control 
points(*). See the attached image where the first is magenta and the 
last is yellow.

     <+1.5,+1.1> // C0
     <+0.4,0.0>  // C1
     <+0.3,0.5>  // C2
     <+0.4,0.9>  // C3
     <+1.5,+0.1> // C4

I'll try and look at some of the other issues you mention as I have 
time; Including temporarily removing the x>0.0 restriction on the first 
and last points to see what happens. Aside: we did remove a similar 
restriction for the lathe for v3.8 vs v3.7.

(*) I tried inverting all the on curve points and this does NOT work as 
I incorrectly remembered for some recent sor{} post - that must be a 
lathe{} only thing.

Bill P.

[Bald Eagle] Re: SOR documentation [217 days 2 hours and 1 minute ago]

Mon, 8 Sep 2025 11:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> As shown, when I use cutaway_textures, I DON'T see the expected
> interior_texture, but the surface texture {}.  And when I use sor {open}, I do
> not see a hollow infinitely thin surface, I get a solid object sliced in half.

Also, I'm curious as to why the cutaway_textures feature requires the use of an
untextured object as a cutter to be able to function properly.
One would reasonably expect that we should be able to use any object.
If, as per wiki documentation, the cutaway_textures feature result is based on
insidedness tests, then the texture of the cutter should be irrelevant.

- BE

[Bald Eagle] Re: SOR documentation [217 days 20 hours and 51 minutes ago]

Sun, 7 Sep 2025 16:20:00 GMT

Same renderings, but of sor {open}

[Bald Eagle] Re: SOR documentation [217 days 20 hours and 56 minutes ago]

Sun, 7 Sep 2025 16:15:00 GMT

So, in the course of making some documentation renders, it became apparent that
there were a few things that were puzzling, needed to be sorted out, and some of
that was related to the behaviour of other keywords.

The following is a summary:

sor {} can have control points ON the axis, just not crossing it.
Else you get a "Parse Error: Incorrect point in surface of revolution"
I believe this is hard-coded behaviour in the source algorithm.
If I were to edit the source, it would allow the first and last control points
to cross the axis, since those points only exist to calculate the tangent
direction.

I do recall discussing this briefly in a thread with clipka and suggesting to
use abs {} somewhere in the algorithm, but I'd have to familiarize myself more
deeply with the specifics of what is going on numerically.

When using the sor {] object as the "cutter" in a difference {}, I unexpectedly
got some interior_texture {} showing in the result. Strangely enough, when i use
sor {open} the interior_texture {} is NOT visible, and I only see the surface
texture {}

When cutting away from the sor {}, I see the expected result, though I haven't
pursued this to see what more complicated geometry / CSG yields.

According to the sor {} tutorial in the wiki:
https://wiki.povray.org/content/Documentation:Tutorial_Section_3#Surface_of_Revolution_Object
"First and last point from the list are used to determine slope at beginning and
end of curve and can be defined for any height."

However, I find that to not be the case.
Swapping the first and last control points causes a
"Parse Error: Incorrect point in surface of revolution"
But if I only set the LAST control point y value to zero, technically making the
spline double-back in the y-direction, everything works fine.

and finally on to what sparked this whole investigation off:
I wanted to make a render comparing sor{} with sor {open}, but I had a devil of
a time slicing the vase in half and seeing the interior.

jr managed to achieve the desired result using clipped_by

As shown, when I use cutaway_textures, I DON'T see the expected
interior_texture, but the surface texture {}. And when I use sor {open}, I do
not see a hollow infinitely thin surface, I get a solid object sliced in half.

So, I would say that there are problems with the sor {} caps, possibly with the
normal vector.

As shown in the bottom left, when I slice the sor {open} in half with a box, I
get an apparently solid object. This is of course counterintuitive to what the
user expects, even though the documentation cautions that the open version might
yield unexpected results when used in CSG. I would probably classify this
result as sufficiently unexpected as to warrant its classification as a bug, or
for an extended warning with the clipped_by solution to be added to the
documentation.

Futhermore, if the documentation implies that a sor is solid - just look at the
CSG results of difference {} - then clipped_by ought to give me what I'm seeing
as difference {} only with the interior_texture {} properly displayed.

Other things I notice are that there is some noisy "cruft" at the base of the
clipped_by object. I also see some of that at the bottom of the difference{}s.

The texture is a tiling with a color_map, and is uv_mapped onto the surface(s).
As you can see on the right side of the object, the pattern does not line up
properly at the edges. In the model below that, "top cp doubles back", I
changed the scaling of the tiling to an even number, and it now lines up.

I recall reading about properly scaling patterns so that make them fit, and that
of course employed the use of pi or tau to calculate the proper scaling. This
might be a worthwhile keyword to implement for uv-mapping, perhaps some sort of
"scaling warp". Likely to be pattern and direction dependent.

All objects are rendered with sturm.

Enjoy & Discuss.

- BE

[Bald Eagle] Re: SOR documentation [234 days 13 hours and 36 minutes ago]

Thu, 21 Aug 2025 23:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> ... I'll probably make a
> parametric {} and isosurface {} object to further test how well things match up.

So this is the isosurface version, overlaid on the POV-Ray sor {} object

object {SOR scale 0.999999}

(It's actually one isosurface for every individual segment of the CR spline)

If I scale to 5 nines, I get a LOT more coincident surface artefacts, so I'd say
that everything is working very nicely.

I would still like to see that original 1989 paper, and perhaps I can work out
the square root thing with some level of rigor.

I'm pretty happy with what I've got, and will get working on some sort of
write-up.

If anyone has any questions, or would like to see a specific type of render,
animation, or mathematical derivation, just let me know, so I can include that.

- BE

[Bald Eagle] Re: SOR documentation [235 days 10 hours and 41 minutes ago]

Thu, 21 Aug 2025 02:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I still feel like there should be some minus signs in there to make the
> interpolation work - but maybe those pop out the other side of the MInvers () .
> .. . I'll have to write that out in SDL and run it to find out.

Sent values of A-D for each segment to the debug stream, and there are
definitely minus signs.

> I also don't quite understand why we need to take the square root of the result
> in line 1082
> x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
> to get the interpolated spline values, but perhaps that may become clear as I
> find more bits of time here and the to properly focus on this.

This apparently has to do with the value of "alpha" in the interpolation, with 0
being Uniform, 1/2 being Centripetal, and 1 being Chordal.
I'm not really sure where "r" comes from in the source, or how that while loop
interpolates the spline, but I just ignored all of that, and things worked out
anyway.  :D

After fixing some boneheaded visualization bugs, the math seemed to be working
out with the spline, so I took my SDL version of the SOR spline and used the X
value (minus the minor radius) as the major radius of a torus, and "plotted" a
torus at each interpolation point. (RED)

Seems to overlay the sor {} object (BLUE) very closely.  Errors are probably due
to my janky simulation method, and coincident surfaces.

I'll try to work out the details as I write things up, and I'll probably make a
parametric {} and isosurface {} object to further test how well things match up.

- BE

[Bald Eagle] Re: SOR documentation [235 days 19 hours and 51 minutes ago]

Wed, 20 Aug 2025 17:20:00 GMT

At the moment, everything is looking to more or less ok, there probably only
needs to be a minor amount of clarification and explanation to make the
documentation sufficiently user-friendly.

I added some comments to the source code for sor.cpp
and hopefully I can make a little more progress on comparing my own version
written from scratch to what's going on in source.

There are normal, chordal, and centripetal forms.
I suspect mine is the normal form, and the one in source is centripetal.

(I will need to check source against the following, which I stumbled upon)

https://splines.readthedocs.io/en/latest/euclidean/catmull-rom-properties.html

So the first thing we need to do is set up our system of equations that relates
a cubic interpolation between the START (P1) and END (P2) points of the spline
to the constraints for the data, namely that the spline has to pass _through_
the endpoints, and the tangents at the endpoints for the spline segments are
defined using the additional spline points P0 and P3.

Following along with the comments that summarize the matrix values, it will be
fairly easy to match this up with what is going on in this video:
https://www.youtube.com/watch?v=DLsqkWV6Cag

 /* Use cubic interpolation. */

        k[0] = P[i+1][X] * P[i+1][X];       // P1.x^2, actual spline start
        k[1] = P[i+2][X] * P[i+2][X];       // P2.x^2, actual spline end
        k[2] = (P[i+2][X] - P[i][X]) / (P[i+2][Y] - P[i][Y]);    // df/dt at
spline start
        k[3] = (P[i+3][X] - P[i+1][X]) / (P[i+3][Y] - P[i+1][Y]);   // df/dt at
spline end (tangent)

        k[2] *= 2.0 * P[i+1][X];       // = 2 P1.x * (P2.x - P0.x)
                ----------------------
                  (P2.y - P0.y)

        k[3] *= 2.0 * P[i+2][X];       // = 2 P2.x * (P3.x - P1.x)
                ----------------------
                  (P3.y - P1.y)

        w = P[i+1][Y];

        Mat[0][0] = w * w * w;        // P1.y^3
        Mat[0][1] = w * w;        // P1.y^2
        Mat[0][2] = w;         // P1.y
        Mat[0][3] = 1.0;        // 1

        Mat[2][0] = 3.0 * w * w;       // 3*P1.y^2
        Mat[2][1] = 2.0 * w;        // 2*P1.y
        Mat[2][2] = 1.0;        // 1
        Mat[2][3] = 0.0;        // 0

        w = P[i+2][Y];

        Mat[1][0] = w * w * w;        // P2.y^3
        Mat[1][1] = w * w;        // P2.y^2
        Mat[1][2] = w;         // P2.y
        Mat[1][3] = 1.0;        // 1

        Mat[3][0] = 3.0 * w * w;       // 3*P2.y^2
        Mat[3][1] = 2.0 * w;        // 2*P2.y
        Mat[3][2] = 1.0;        // 1
        Mat[3][3] = 0.0;        // 0


-------------------------------------------------------------------------
One can solve a system of linear equations in a matrix using a number of
different methods.
The source uses the method of finding the matrix inverse, and then multiplying
both sides of the matrix equation by the matrix inverse.
(This is where the over-brief equation in the docs is confusing, without any
other context)

-------------------------------------------------------------------------



 // Now we find the matrix inverse so that we can solve for the coefficients
 /*
       ax = b
 (1/a)*ax = (1/a)*b
 (a^-1)ax = (a^-1)b
 (a^-1)*x = 1, so
        x = (a^-1) b
 */

        MInvers(Mat, Mat);        // in math/matrix.cpp

 // Once we have the matrix inverse, we take the data constraints and the matrix
inverse and
 // multiply them to calculate the coefficients.

        /* Calculate coefficients of cubic patch. */
 // k[] is the column vector of the constraints
 // and Mat[] is the *matrix_inverse* M
 // so multiplying together equals the column vector of the coefficients

        A = k[0] * Mat[0][0] + k[1] * Mat[0][1] + k[2] * Mat[0][2] + k[3] *
Mat[0][3];
        B = k[0] * Mat[1][0] + k[1] * Mat[1][1] + k[2] * Mat[1][2] + k[3] *
Mat[1][3];
        C = k[0] * Mat[2][0] + k[1] * Mat[2][1] + k[2] * Mat[2][2] + k[3] *
Mat[2][3];
        D = k[0] * Mat[3][0] + k[1] * Mat[3][1] + k[2] * Mat[3][2] + k[3] *
Mat[3][3];


I still feel like there should be some minus signs in there to make the
interpolation work - but maybe those pop out the other side of the MInvers () .
.. . I'll have to write that out in SDL and run it to find out.

I also don't quite understand why we need to take the square root of the result
in line 1082
x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
to get the interpolated spline values, but perhaps that may become clear as I
find more bits of time here and the to properly focus on this.

Just wanted to issue a progress report.   :)

- BE

[Bald Eagle] Re: SOR documentation [239 days 23 hours and 51 minutes ago]

Sat, 16 Aug 2025 13:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> I'll reply tomorrow (Sunday), via email, on topic.

Well, before I go changing the documentation for POV-Ray,  I'd like to point out
that currently I have only worked out some form of the Catmull-Rom spline that
seems to work in a predictable way.

I'm currently at the state where I'm looking at the source code in sor.cpp to
try and figure out if the 2 things match in some way.

https://github.com/POV-Ray/povray/blob/master/source/core/shape/sor.cpp

1. The source uses the x and y values of the control points separately in the
terms of the equations used to solve for the coefficients.  I do not.

2. The source uses powers of the control point y values in the matrix, whereas I
do not.

3. The source performs a matrix inversion before calculating the coefficients.
No idea why, or what that does (yet).

4. Then there are other adjustments after that,
c[0] = 3.0 * A;
c[1] = 2.0 * B;
c[2] = C;


5. and then they somehow need to "solve a polynomial" - presumably to find a
root.
        n = Solve_Polynomial(2, c, r, false, 0.0, stats);

6. then this n value is used as the iterator in the interpolation
while (n--)
        {
            if ((r[n] >= y[0]) && (r[n] <= y[1]))
            {
                x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
            }
        }


Which all seems bewilderingly complex to me, but seems to jive with current
documentation.
HOW that all works is currently beyond me.
It's just a giant big black box.

Somewhere around 2000, it seemed to be beyond Warp as well.

I have some thing to do today and tomorrow, but Maybe I can spin my version
around the y-axis and compare it the actual sor object and see if they're even
close.

- BW

[jr] Re: SOR documentation [240 days 7 hours and 1 minute ago]

Sat, 16 Aug 2025 06:10:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> With regard to the "equations as images" that we have in ours docs, I'd like to
> see some level of plain text version that can be copy/pasted.  Or if there is
> some way, perhaps we can have MathJax implemented so that we can have great
> looking equations.

I'll reply tomorrow (Sunday), via email, on topic.  on the above, the wiki has a
math extension installed, perhaps that should enable you to write the equations
"in text" (see attached).

regards, jr.

[Bald Eagle] Re: SOR documentation [240 days 23 hours and 56 minutes ago]

Fri, 15 Aug 2025 13:15:00 GMT

This covers the basics,

https://www.cs.cmu.edu/~fp/courses/graphics/asst5/catmullRom.pdf

but Wikipedia shows that there are uniform, chordal, and centripetal forms as
well.

(granted for our present purposes, I think we are just using the uniform version
with a tension of 1.0 )

[Bald Eagle] Re: SOR documentation [241 days and 11 minutes ago]

Fri, 15 Aug 2025 13:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> having just read your follow-up, it seems that the interpolation "loose end"
> needs to be sorted.

So, I just wrote the whole thing from scratch, the way it seemed to me to work,
according to that last linked Wordpress page.

https://wiki.povray.org/content/File:RefImgCurvmath.png
Looks like it was made, or at least uploaded by Jim Holsenback.

> if then you can provide a (working) "worked example" and
> (brief ;-)) explanation, we can update that part of the documentation.

I can likely provide a "mathematical" or a code example - either as the vector *
matrix form, or as the intermediate result (A, B, C, & D).

There are some YT videos that seem to go over the topic, so perhaps I can either
use on of those, or dig up the original paper by Catmull and Rom to show the
derivation, and why the vector and matrix values are what they are.

In typical fashion, I can expand all that to simulate / demonstrate how that
curve gets wrapped around the axis to make the "sor" object (both
graphically/geometrically and mathematically), as well as render it as a
parametric {} and an isosurface {}.  Easy enough to do that as a union of
triangle{}s, perhaps mesh {}, less likely mesh2{}.

I already edited the doc page in OpenOffice as a first rough draft, however it
may need revision after I at some point figure out exactly what's going on with
the lathe {} object.

As with all things, I'd like to see some level of clarity, completeness, and
comprehensiveness in our documentation.  So, in my mind, I would like to see
POV-Ray serve as a repository of computer graphics education that clearly and
completely explains all of the historical and current concepts in computer
graphics, with references, working code, and of course eye-popping artistic
renders.
So perhaps we can make a list of all of the various different kinds of splines,
and see if we can't get as many of them implemented as is practical.  I know
Jerome worked out Rational Bezier Splines a while back, and TOK has NURBS worked
out.  Even though none of it is in source, it can be implemented via
macros/include files, and in a way, that's a better educational resource that
people can refer to.

* Because we need to attract more people here to spur further development *

- BW

P. S.

With regard to the "equations as images" that we have in ours docs, I'd like to
see some level of plain text version that can be copy/pasted.  Or if there is
some way, perhaps we can have MathJax implemented so that we can have great
looking equations.

[Bald Eagle] Re: SOR documentation [242 days 13 hours and 36 minutes ago]

Wed, 13 Aug 2025 23:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> So hopefully I'll be able to get the SDL to work tonight.

It took longer than i thought, because in order to make the f(h) equation match
the documentation, I had to flip everything upside down and backwards from the
way I did it in Excel.  And I used arrays.

But it all works, which is what I needed to do.

With regard to POV 4.0, I see no reason why the number of points needs to be
specified, since the source can count the points when parsing the SDL.
There ought to be a way to specify the "tension" like in a proper Catmull-Rom
spline.

Anyway, here ya go.

- BW

[Bald Eagle] Re: SOR documentation [242 days 17 hours and 21 minutes ago]

Wed, 13 Aug 2025 19:50:00 GMT

I suppose that my next logical question is:

the sor documentation states, "The intersection test with a SOR object involves
solving a cubic polynomial while the test with a lathe object requires to solve
a 6th order polynomial" ...

but upon reviewing the lathe documentation, one can choose between a variety of
different spline types.

So perhaps that needs some clarification / correction / expansion.

(I've also written a Newton-Raphson root solver, and so probably should
investigate the Sturmian root solver.)

- BW

[Bald Eagle] Re: SOR documentation [242 days 17 hours and 41 minutes ago]

Wed, 13 Aug 2025 19:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
https://andrewhungblog.wordpress.com/2017/03/03/catmull-rom-splines-in-plain-english/

This last one seemed to be pretty straightforward to follow, and I managed to
implement it in Excel.

So hopefully I'll be able to get the SDL to work tonight.

- BW

[Bald Eagle] Re: SOR documentation [242 days 19 hours and 11 minutes ago]

Wed, 13 Aug 2025 18:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> having just read your follow-up, it seems that the interpolation "loose end"
> needs to be sorted.  if then you can provide a (working) "worked example" and
> (brief ;-)) explanation, we can update that part of the documentation.

I'll try to get it worked out, unless someone else manages to do it before me.

I just had some success following up on a hunch that the spline is a Catmull-Rom
type.

https://qroph.github.io/2018/07/30/smooth-paths-using-catmull-rom-splines.html

https://www.cs.cmu.edu/~fp/courses/graphics/asst5/catmullRom.pdf

https://andrewhungblog.wordpress.com/2017/03/03/catmull-rom-splines-in-plain-english/

-BW

[jr] Re: SOR documentation [242 days 21 hours and 1 minute ago]

Wed, 13 Aug 2025 16:10:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I was wanting to work out the SOR segment equations, and found the existing
> documentation to be a bit confusing / incomplete.
> https://wiki.povray.org/content/Reference:Surface_of_Revolution
> The notation is a bit confusing, and there's not enough information to lead me
> through the jumps in operations so that I can connect what's going on.
> I know there has been some recent effort to improve some of the documentation,
> and I think this page would be a good candidate for revision.
> If anyone has the knowledge or ability to work out how the curve for each
> segment gets interpolated, then a better written explanation and/or SDL
> calculating all the points along the entire SOR curve would be great.

having just read your follow-up, it seems that the interpolation "loose end"
needs to be sorted.  if then you can provide a (working) "worked example" and
(brief ;-)) explanation, we can update that part of the documentation.


regards, jr.

[Bald Eagle] Re: SOR documentation [242 days 23 hours and 51 minutes ago]

Wed, 13 Aug 2025 13:20:00 GMT

So where my confusion lies is with the following:

The documentation says,
"The coefficients A(j), B(j), C(j) and D(j) are calculated for every segment
using the equation"
and then immediately gives "b = M * x".


b is a column vector, M is a matrix, and then x is a column vector of the
coefficients that we're supposed to be calculating as implied by that initial
sentence.

The best I have been able to do in terms of trying to work this out and make any
sense of it is:

if b = M * x, and x is the column vector of coefficients, then x = b/M.

So, why start off with how to calculate b, if b is already given in the next
line, and why express it that way if what you actually want to say is that x =
b/M?

The next problem is that M has values that are hard-coded as zeroes, which would
lead to division by zero in every instance, and if a control point leads to any
of the terms of the matrix evaluating to zero, then the same problem occurs.

Finally, it seems that the h's in the b and M calculations are the actual
geometric heights of the control points, whereas the h's in the equation r^2 =
f(h) = A*h^3 + B*h^2 + C*h + D are the values of an interpolant along a single
segment. (otherwise with multiple control points, which of the h's get used? and
which control points get used, if the discussion that immediately follows states
that the function is divided up into separate segments?

Also, I see no "interpolation" happening between point J and point (j+1).

If I am in error, hopefully someone can show me where I missed or misinterpreted
something.

The source code (
https://github.com/POV-Ray/povray/blob/master/source/core/shape/sor.cpp )
states that

*  Ideas for the surface of revolution were taken from:
*
*    P. Burger and D. Gillies, "Rapid Ray Tracing of General Surfaces
*    of Revolution", New Advances in Computer Graphics, Proceedings
*    of CG International '89, R. A. Earnshaw, B. Wyvill (Eds.),
*    Springer, ..., pp. 523-531

and try as I might, I have not been able to find a readable copy of this 1989
paper, nor have had enough time to try and puzzle out the source code to work
backwards.

- BE

[Bald Eagle] SOR documentation [243 days 20 hours and 36 minutes ago]

Tue, 12 Aug 2025 16:35:00 GMT

I was wanting to work out the SOR segment equations, and found the existing
documentation to be a bit confusing / incomplete.

https://wiki.povray.org/content/Reference:Surface_of_Revolution

The notation is a bit confusing, and there's not enough information to lead me
through the jumps in operations so that I can connect what's going on.

I know there has been some recent effort to improve some of the documentation,
and I think this page would be a good candidate for revision.

If anyone has the knowledge or ability to work out how the curve for each
segment gets interpolated, then a better written explanation and/or SDL
calculating all the points along the entire SOR curve would be great.

Thanks,

- BE

[Bald Eagle] Re: Boolean isosurfaces [295 days 13 hours and 56 minutes ago]

Sat, 21 Jun 2025 23:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I worked out the particulars of min and max in Desmos, and provided descriptions
> of each domain of the functions.

[Bald Eagle] Boolean isosurfaces [295 days 14 hours and 1 minute ago]

Sat, 21 Jun 2025 23:10:00 GMT

In continued discussions with jr about certain sections of POV-Ray's
documentation,  I was reviewing the tutorial on isosurfaces and it struck me
that the use of min and max was sort of generally accepted as a bit of
mathematical magic, and the provided use cases were limited.

I worked out the particulars of min and max in Desmos, and provided descriptions
of each domain of the functions.

After looking over Boolean functions on Wikipedia, Shadertoy, and a few other
sites, I worked out the complete range of Boolean functions and how to render
them as isosurfaces.  Added the binary representations of how the y can be
mapped to the vertices of a tesseract, which should provide a basis for
interesting future work.

Enjoy.

[jr] Re: Confusing error when trying to use brick pat... [337 days 6 hours and 21 minutes ago]

Sun, 11 May 2025 06:50:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-08-04 16:39 (-4), kirbyanddee wrote:
> > ...
> > the render fails and it leaves this error:
> >
> > File 'firstimg.pov' line 13: Possible Parse Error: Unmatched {
> > File 'firstimg.pov' line 14: Parse Error: No matching }, pigment identifier
> >  found instead
> > Fatal error in parser: Cannot parse input.
>
> This appears to be an error in the documentation, as there is no such
> pigment Black_Marble.  Try Red_Marble, White_Marble, or Blood_Marble.

corrected, thanks.


regards, jr.

[Bald Eagle] Re: Irregardless of whether or not it's a word... [405 days 16 hours and 56 minutes ago]

Mon, 3 Mar 2025 20:15:00 GMT

I see you share one of my minor hobbies . . . :D

[Cousin Ricky] Irregardless of whether or not it's a word... [405 days 17 hours and 33 minutes ago]

Mon, 3 Mar 2025 19:37:41 GMT

While looking up dictionaries in the reference manual, I discovered that
Section 3.3.1.10.1 "Declaring Arrays" contains the word "irregardless."
While Merriam-Webster acknowledges that this *is* a word, and I believe
other dictionaries concur, and while they document the English language
rather than prescribe it, they aren't above passing judgment on its
usage.  For the sake of professional appearance, it may be best to
change it to "regardless."

A quick grep of the documentation files reveals 4 other occurrences:

  2.3.4.3 "Gamma in Output Images"
  3.5.1.1.5 "Height Field"
  3.6.1.2.3.1 "Specifying a Bump Map"
  3.6.2.4.2 "Image Pattern"

The bona fide, albeit substandard, word also appears in the wiki:

  https://wiki.povray.org/content/Documentation:Tutorial_Section_3.3
  https://wiki.povray.org/content/Reference:Array
  https://wiki.povray.org/content/Reference:Height_Field
  https://wiki.povray.org/content/Reference:Bump_Map
  https://wiki.povray.org/content/Reference:Image_Pattern

[Bald Eagle] Re: Shapes [601 days 19 hours and 51 minutes ago]

Mon, 19 Aug 2024 17:20:00 GMT

Also, an entry for the Lemon shape is missing.

https://wiki.povray.org/content/Reference:Lemon

[Bald Eagle] Shapes [601 days 20 hours and 6 minutes ago]

Mon, 19 Aug 2024 17:05:00 GMT

With regard to recent discussion with jr about how we define our shapes, I was
going through the wiki docs to refresh and summarize the syntaxes and noticed a
few things. (so far)

The parametric is listed under "Finite Solid Primitives", however the
documentation on that shape then directly contradicts that by saying,
"The parametric object is not a solid it is hollow, like a thin shell."

Perhaps this ought to be moved under the more general "objects" heading to
eliminate confusion?


Under Isosurface, we have the notification that:
"New in version 3.8 a potential pattern has been added to define a pattern based
on the potential field of a blob or isosurface object. See also: Potential
Pattern."

However the same notice is not present under Blob.


On the page:
https://wiki.povray.org/content/Category:Objects

All objects are listed as "*Reference:[Shape Name]"
however Mesh is listed as "*Reference Talk:Mesh"

Also, the shapes are listed by "extended/expanded shape name" instead of the
actual SDL keyword.  So, for instance, Reference:Surface of Revolution
might benefit from an entry of "Reference:sor" pointing to the same page, or
just putting sor in parentheses like so: Reference:Surface of Revolution (sor).

Just for clarity and so it's less confusing for new users.

- BW

[Mr] Re: Digital Decay (almost off topic but relevant) [655 days 1 hour and 41 minutes ago]

Thu, 27 Jun 2024 11:30:00 GMT

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > Would this sample or tutorial I'm sharing be better off on my own personal web
> > page / blog, or a big player like Youtube, or Git Hub...? or even better, when
> > the content is good enough, into official POV-Ray ressources?
>
> in the IndieWeb community the motto is, publish on your own site first.
> Especially for social media postings. Then post and link (as a real link or just
> text) on the social media sites. Even if it are 'just' comments and even if it
> lacks context on your page/site. You have full control over your own site, not
> over other sites.  You cannot be sure of the future of archive.org or github et
> al.
>
> One thing I miss in all the web/publishing frameworks is proper versioning with
> linking back to historical versions, although on several authors can implement
> it themselves.
>
> ingo

Hi, precisely, the fact that it's "Indie" means it's relatively more expensive
to maintain long term... and individuals shutting down their sites mean all
those dynamic links loosing their sources forever if it hasn't been crawled by
something else.

There must be some process that guarantees one's site gets visited and archived
by such sites as the Internet Archive, right?

[Bald Eagle] Re: Digital Decay (almost off topic but relevant) [655 days 18 hours and 41 minutes ago]

Wed, 26 Jun 2024 18:30:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> Any thoughts?

Hi Maurice,

This topic has come up before, and I suggested that it wouldn't be that
expensive for a few people to request a full backup of the entire POV-Ray
website and whatever other things are stored but are invisible/inaccessible
through the website front end.

The cost of traditional hard drives has plummeted, and SSD / thumb-drives / sd
cards are available in - what can only be described as astonishing capacities -
has bloomed in recent years.

Sign me up for a personal backup copy.


- BE

[jr] Re: Digital Decay (almost off topic but relevant) [655 days 20 hours and 1 minute ago]

Wed, 26 Jun 2024 17:10:00 GMT

hi,

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Hi,
> When this popped into my news flow, I felt compelled to share it here,
> Because POV-Ray is not neglecting its legacy:
>
> {...}
>
> Many of the ressources in the CG fields have "decayed" in recent years,
> For instance, one of the biggest losses was the disappearance of CG Society web
> forums.
> ...
> Any thoughts?

tangential.  "the" big loss for me is that "proper"/technical documentation of
s/wares and such seems to have "decayed" (both quality + quantity), especially
when compared to before the 90s.

("it'll end in tears.." </shrug+grin>)

regards, jr.

[ingo] Re: Digital Decay (almost off topic but relevant) [658 days 3 hours and 46 minutes ago]

Mon, 24 Jun 2024 09:25:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Would this sample or tutorial I'm sharing be better off on my own personal web
> page / blog, or a big player like Youtube, or Git Hub...? or even better, when
> the content is good enough, into official POV-Ray ressources?

in the IndieWeb community the motto is, publish on your own site first.
Especially for social media postings. Then post and link (as a real link or just
text) on the social media sites. Even if it are 'just' comments and even if it
lacks context on your page/site. You have full control over your own site, not
over other sites.  You cannot be sure of the future of archive.org or github et
al.

One thing I miss in all the web/publishing frameworks is proper versioning with
linking back to historical versions, although on several authors can implement
it themselves.

ingo

[Mr] Digital Decay (almost off topic but relevant) [658 days 5 hours and 31 minutes ago]

Mon, 24 Jun 2024 07:40:00 GMT

Hi,
When this popped into my news flow, I felt compelled to share it here,
Because POV-Ray is not neglecting its legacy:

https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/

Many of the ressources in the CG fields have "decayed" in recent years,
For instance, one of the biggest losses was the disappearance of CG Society web
forums.

The POV community has been one of the most aware of this problem, finding
solutions such as :

*The Internet Archive,
*Reocities,
*Awesome backup handling of its own website generously provided by Chris Cason,

etc.

We are part of a precious endeavor, so whenever we share something POV related
around here or elsewhere we should always try to see this big picture ; where do
we keep / duplicate the long term data?

Would this sample or tutorial I'm sharing be better off on my own personal web
page / blog, or a big player like Youtube, or Git Hub...? or even better, when
the content is good enough, into official POV-Ray ressources?

Would duplicating content tend to dilute this responsibility?
Most of all, just always be aware, that some paste bins and image bins are very
often "flushed" thus breaking forum / newsgroups links.

Any thoughts?

[B Gimeno] Re: inverse transform in v3.7 [750 days and 1 minute ago]

Sun, 24 Mar 2024 13:10:00 GMT

"B. Gimeno" <nomail@nomail> wrote:
> Hi, trying to reach here (inverse transform):
> https://www.povray.org/documentation/view/3.6.1/51/
>
> from here: (inverse keyword)
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_2
>
> redirects to: (inverse object modifier)
> https://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_5_5_5
>
> v3.6
> https://www.povray.org/documentation/view/3.6.1/49/
> v3.7
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_12
>
> Maybe should be added as 3.3.1.12.5 and some kind of desambiguation?
>
> Greeting,
> B. Gimeno

I have also checked the documentation attached to version 3.8 and it is the
same.

[B Gimeno] inverse transform in v3.7 [750 days 1 hour and 46 minutes ago]

Sun, 24 Mar 2024 11:25:00 GMT

Hi, trying to reach here (inverse transform):
https://www.povray.org/documentation/view/3.6.1/51/

from here: (inverse keyword)
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_2

redirects to: (inverse object modifier)
https://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_5_5_5

v3.6
https://www.povray.org/documentation/view/3.6.1/49/
v3.7
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_12

Maybe should be added as 3.3.1.12.5 and some kind of desambiguation?

Greeting,
B. Gimeno

[Cousin Ricky] Re: Confusing error when trying to use brick pat... [982 days 15 hours and 10 minutes ago]

Fri, 4 Aug 2023 22:01:09 GMT

On 2023-08-04 16:39 (-4), kirbyanddee wrote:
> Hi, I'm very new to POV-Ray so i've been looking at the reference docs to find
> out what I can do. this code is present in the docs:
> 
> pigment {
>   brick pigment{Jade}, pigment{Black_Marble}
>   }
> 
> but i can't seem to get it working in a file. here's an example:
> 
> [snip]
> 
> the render fails and it leaves this error:
> 
> File 'firstimg.pov' line 13: Possible Parse Error: Unmatched {
> File 'firstimg.pov' line 14: Parse Error: No matching }, pigment identifier
>  found instead
> Fatal error in parser: Cannot parse input.

This appears to be an error in the documentation, as there is no such
pigment Black_Marble.  Try Red_Marble, White_Marble, or Blood_Marble.

[jr] Re: library_path limit [1043 days 19 hours and 1 minute ago]

Sun, 4 Jun 2023 18:10:00 GMT

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> Thorsten <tho### [at] trfde> wrote:
> > There is no limit other than the addressable memory. So you should be
> > safe up to about 2**58 path entries on a 64 bit system. I don't know how
> > long those would take to parse though ;-)

thanks.  (good to know it's "future-proof" :-))


> That is what I figured after I went to 97 library_paths with 61 objects and
> functions.
> Parse time was 7.03 sec.

97, eh ?!  you've more stamina than me.. ;-)


(my interest came from the mention in section 2.3 of the collection's
usersguide)


regards, jr.

[Leroy] Re: library_path limit [1043 days 20 hours and 21 minutes ago]

Sun, 4 Jun 2023 16:50:00 GMT

Thorsten <tho### [at] trfde> wrote:
> On 02.06.2023 16:43, jr wrote:
> > hi,
> >
> > Alain Martel <kua### [at] videotronca> wrote:
> >> Le 2023-06-01 à 16:45, Leroy a écrit :
> >>> ...
> >>> I put 41 Library_Paths in an ini and ran short pov ...
> >> Faster and simpler test : Make a scene that use something from the very
> >> last library path.
> >
> > thank you both.  did the latter, with 51 'library_path' lines in ini, no
> > problems with 3.8-alpha or 3.7.0.8.  good to know, still, there has to be an
> > "official" limit mentioned somewhere ?
>
>
> There is no limit other than the addressable memory. So you should be
> safe up to about 2**58 path entries on a 64 bit system. I don't know how
> long those would take to parse though ;-)
>
> Thorsten

That is what I figured after I went to 97 library_paths with 61 objects and
functions.
Parse time was 7.03 sec.

[Alain Martel] Re: library_path limit [1044 days 21 hours and 40 minutes ago]

Sat, 3 Jun 2023 15:30:41 GMT

Le 2023-06-03 Ã  09:53, Thorsten a Ã©critÂ :
> On 02.06.2023 16:43, jr wrote:
>> hi,
>>
>> Alain Martel <kua### [at] videotronca> wrote:
>>> Le 2023-06-01 Ã  16:45, Leroy a Ã©critÂ :
>>>> ...
>>>> I put 41 Library_Paths in an ini and ran short pov ...
>>> Faster and simpler test : Make a scene that use something from the very
>>> last library path.
>>
>> thank you both.Â  did the latter, with 51 'library_path' lines in ini, no
>> problems with 3.8-alpha or 3.7.0.8.Â  good to know, still, there has to 
>> be an
>> "official" limit mentioned somewhere ?
> 
> 
> There is no limit other than the addressable memory. So you should be 
> safe up to about 2**58 path entries on a 64 bit system. I don't know how 
> long those would take to parse though ;-)
> 
> Thorsten
> 
> 
> 
Want to access a file from the 100th library path : Look into the folder 
of path 1 to find the file. Not there. Look into folder of path 2 to 
find the file. Not there. Look into path 3 to find the file. Not there. 
... Look into path 100 to find the file. File found !

That will take some time.

[Thorsten] Re: library_path limit [1044 days 23 hours and 17 minutes ago]

Sat, 3 Jun 2023 13:53:16 GMT

On 02.06.2023 16:43, jr wrote:
> hi,
> 
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2023-06-01 Ã  16:45, Leroy a Ã©critÂ :
>>> ...
>>> I put 41 Library_Paths in an ini and ran short pov ...
>> Faster and simpler test : Make a scene that use something from the very
>> last library path.
> 
> thank you both.  did the latter, with 51 'library_path' lines in ini, no
> problems with 3.8-alpha or 3.7.0.8.  good to know, still, there has to be an
> "official" limit mentioned somewhere ?


There is no limit other than the addressable memory. So you should be 
safe up to about 2**58 path entries on a 64 bit system. I don't know how 
long those would take to parse though ;-)

Thorsten

[jr] Re: library_path limit [1045 days 22 hours and 26 minutes ago]

Fri, 2 Jun 2023 14:45:00 GMT

hi,

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-06-01 à 16:45, Leroy a écrit :
> > ...
> > I put 41 Library_Paths in an ini and ran short pov ...
> Faster and simpler test : Make a scene that use something from the very
> last library path.

thank you both.  did the latter, with 51 'library_path' lines in ini, no
problems with 3.8-alpha or 3.7.0.8.  good to know, still, there has to be an
"official" limit mentioned somewhere ?

("hey, A/J Holsenback", are you reading this ?  :-))

regards, jr.

[Alain Martel] Re: library_path limit [1046 days 9 hours and 59 minutes ago]

Fri, 2 Jun 2023 03:11:11 GMT

Le 2023-06-01 Ã  16:45, Leroy a Ã©critÂ :
> "jr" <cre### [at] gmailcom> wrote:
>> hi,
>>
>> in v3.6 and older documentation, the 'Library_Path's section mentions the (then)
>> upper limit of 20.  I believe it's been increased to 25, but cannot find the
>> corresponding info in the current docs[*].  does someone have a reference,
>> please.
>>
>>
>> [*]
>> <https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Library_Paths>
>>
>>
>> regards, jr.
> 
> That's a good question! I checked my V3.7 docs and found nothing. So I did a
> test.
> I put 41 Library_Paths in an ini and ran short pov witch didn't use any of them,
> with no problem. A better test would run a pov that did use them all.
> I might do that, but it take some time.
> Have Fun!
> 
> 
Faster and simpler test : Make a scene that use something from the very 
last library path.

The reason is that, if you are over the limit, that path won't be 
recognized as valid, and the parsing will fail with an error message. 
Possible bonus : That message may also tell you what the actual limit is.

[Leroy] Re: library_path limit [1046 days 16 hours and 21 minutes ago]

Thu, 1 Jun 2023 20:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> in v3.6 and older documentation, the 'Library_Path's section mentions the (then)
> upper limit of 20.  I believe it's been increased to 25, but cannot find the
> corresponding info in the current docs[*].  does someone have a reference,
> please.
>
>
> [*]
> <https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Library_Paths>
>
>
> regards, jr.

That's a good question! I checked my V3.7 docs and found nothing. So I did a
test.
I put 41 Library_Paths in an ini and ran short pov witch didn't use any of them,
with no problem. A better test would run a pov that did use them all.
I might do that, but it take some time.
Have Fun!

[jr] library_path limit [1046 days 22 hours and 51 minutes ago]

Thu, 1 Jun 2023 14:20:00 GMT

hi,

in v3.6 and older documentation, the 'Library_Path's section mentions the (then)
upper limit of 20.  I believe it's been increased to 25, but cannot find the
corresponding info in the current docs[*].  does someone have a reference,
please.


[*]
<https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Library_Paths>


regards, jr.

[Cousin Ricky] Re: [solved] "mandel" as function in isosurface ... [1213 days 14 hours and 17 minutes ago]

Fri, 16 Dec 2022 22:53:13 GMT

On 2022-12-16 03:27 (-4), Lars Rohwedder wrote:
> 
> https://www.povray.org/documentation/view/3.6.1/377/
> 
> See the explanations for "interior" and "exterior" types 0 and 1.
> A default color map is not mentioned there at all, hence I did not know
> about that. :-/
> 
> 
>>> So I had expected that a formula like 0.9 - mandel would give the
>>
>>> What went wrong here?
>>
Bald Eagle wrote:
>> Part of what's going wrong is that mandel is a POV-Ray pattern that
>> has a built in color map.Â Â  And that wreaks hell with
everything
>> right from the beginning.
> 
> I see. It should be mentioned in the documentation of the mandel
> pattern. :-/
> 
>> I'd say try using:
>>
>> #declare Mandel = function { pigment {mandel 1000 exterior 1, 1
>> color_map {[0 rgb 0] [1 rgb 1]}}}
>>
>> But you're having more success than I am.
> 
> Thank you a lot! Changing the color map into a stupid black-to-white
> ramp solves the problem.

Forwarding to the documentation newsgroup.

[John Briggs] PoVray 3.8 ini files (unix only) [1615 days 13 hours and 10 minutes ago]

Wed, 10 Nov 2021 00:01:05 GMT

I have been experimenting with 3.8-beta2. Similar to version 3.7 the 
povray.ini file has the following entries:

  Library_Path="/usr/local/share/povray/3.8"
  Library_Path="/usr/local/share/povray/3.8/ini"
  Library_Path="/usr/local/share/povray/3.8/include"

if you want povray v3.8 to recognise the Library_Path to the ini files 
you have to comment out:
  Library_Path="/usr/local/share/povray/3.8" 
Because if povrary v3.8 cannot find your ini files it appends the second 
line to the first line and it appears to become circular.

[Alain Martel] Re: I have a problem with atan2() [1637 days 20 hours and 45 minutes ago]

Mon, 18 Oct 2021 16:25:17 GMT

Le 2021-10-18 Ã  11:42, kurtz le pirate a Ã©critÂ :
> On 17/10/2021 23:46, Cousin Ricky wrote:
> 
>> ... Of course, the inverse tangent of A/0 is undefined, because A/0 is
>> undefined.Â  But a simple limits exercise, as well as the very definition
>> of the tangent of an angle, show that these undefined tangents
>> correspond to the angles pi/2 and -pi/2, and it is therefore useful to
>> pretend that they are valid.
>>
>> The purpose of atan2() is to handle these special cases, by converting a
>> naive atan()'s argument into an ordered pair, thus allowing the would-be
>> inverse tangent of A/0 to be computed without having to divide by 0.Â  A
>> simple scene file shows that the *only* time atan2() fails with a domain
>> error is when *both* A and B are zero.Â  Of course, (0, 0) is an
>> indeterminate case, for which returning a value would be nonsensical.
>> ...
> 
> Cousin Ricky is right about everything!
> 
> And therefore, my problem is when A AND B are equal to zero.
> 
> Lot of datas to deal with, the debugging will be long...
> (i'm working on the visualization of complex functions with domain 
> coloring)
> 
> 
> 
Add a test to see if both A and B are zero, and replace that with some 
small value for B. It could be something like the following just before 
the call to atan2 :

#if (A=0 ! B=0) #declare B= 0.001; #end
... atan2(A,B) ...

[kurtz le pirate] Re: I have a problem with atan2() [1637 days 21 hours and 28 minutes ago]

Mon, 18 Oct 2021 15:42:41 GMT

On 17/10/2021 23:46, Cousin Ricky wrote:

> ... 
> Of course, the inverse tangent of A/0 is undefined, because A/0 is
> undefined.  But a simple limits exercise, as well as the very definition
> of the tangent of an angle, show that these undefined tangents
> correspond to the angles pi/2 and -pi/2, and it is therefore useful to
> pretend that they are valid.
> 
> The purpose of atan2() is to handle these special cases, by converting a
> naive atan()'s argument into an ordered pair, thus allowing the would-be
> inverse tangent of A/0 to be computed without having to divide by 0.  A
> simple scene file shows that the *only* time atan2() fails with a domain
> error is when *both* A and B are zero.  Of course, (0, 0) is an
> indeterminate case, for which returning a value would be nonsensical.
> ...

Cousin Ricky is right about everything!

And therefore, my problem is when A AND B are equal to zero.

Lot of datas to deal with, the debugging will be long...
(i'm working on the visualization of complex functions with domain coloring)



-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] Re: I have a problem with atan2() [1638 days 15 hours and 24 minutes ago]

Sun, 17 Oct 2021 21:46:33 GMT

On 2021-10-17 6:40 AM (-4), kurtz le pirate wrote:
> 
> I have a problem withÂ  atan2(a,b) when b = zero.
> 
> The documentation on the page
> <http://www.povray.org/documentation/view/3.7.1/228/> says :
> 
> Arc-tangent of (A/B). Returns the angle, measured in radians, whose
> tangent is (A/B). **Returns appropriate value even if B is zero**
> 
> In my case, i get : Parse Error: Domain error in atan2!

Is your value for A also zero?

> So it's up to me to test if b=zero and return the appropriate value ?

It seems that some people are confused about atan2().

Of course, the inverse tangent of A/0 is undefined, because A/0 is
undefined.  But a simple limits exercise, as well as the very definition
of the tangent of an angle, show that these undefined tangents
correspond to the angles pi/2 and -pi/2, and it is therefore useful to
pretend that they are valid.

The purpose of atan2() is to handle these special cases, by converting a
naive atan()'s argument into an ordered pair, thus allowing the would-be
inverse tangent of A/0 to be computed without having to divide by 0.  A
simple scene file shows that the *only* time atan2() fails with a domain
error is when *both* A and B are zero.  Of course, (0, 0) is an
indeterminate case, for which returning a value would be nonsensical.

----------[BEGIN CODE]----------
#version 3.7;
global_settings { assumed_gamma 1 }
#declare Args = array [9]
{ <0, 1>, <1, 1>, <1, 0>, <1, -1>, <0, -1>,
  <-1, -1>, <-1, 0>, <-1, 1>, <0, 0>,
}
#for (I, 0, 8)
  #debug concat ("atan2 (", vstr (2, Args[I], ", ", 0, 0), ") = ")
  #debug concat (str (atan2 (Args[I].x, Args[I].y), 0, 6), "\n")
#end
-----------[END CODE]-----------

This scene runs fine with the 3rd and 7th arguments; it does not halt
with a parse error until it gets to the last argument.

Perhaps "unless both A and B are zero" could be added to the documentation.

[Kenneth] Re: Mysterious function argument [1651 days 18 hours and 16 minutes ago]

Mon, 4 Oct 2021 18:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/3/21 7:05 PM, Kenneth wrote:
> >
> > Question 2:
> > Your F3 function  is
> >          #declare F3 = function { F0(x+1,y/2,z) }
> > and the V3 function is
> >          #declare V3 = F3(1,2,3);
> >
> > Those have 3 components <x...,y...,z...>, yet your #debug for V3 uses just
> > 'str' to pull out some kind of*single*  value (not 'vstr' to pull out
> > all 3 or 5). I thought  str  would outright *fail* with a 3-component
> >  function... yet it does not, interestingly. Is your F3 function
> > 'continuous', or does it just create a single value?
>
> F3 is continuous because F0 is. F3 calls F0 which is defined as
> function{pattern{bozo}} as as such it is a scalar function - it returns
> a single value. F0 is continuous only because the bozo pattern is a
> continuous pattern.

Ah! That's the 'missing piece of the puzzle' for me, in TWO ways:
1) It explains the successful  str  use in #debug-- because function F0 (the
bozo PATTERN) is a *scalar* function, not a multi-component color function. I
have always assumed that such pigment 'patterns', even though grayscale, still
contain 3 (or maybe 5) color components like <.3,.3,.3,0,0>. But they are just a
SINGLE value like .3.  Thanks! That clears up a long-standing misconception for
me.

2) It also explains to me why F0 (and F3), when actually used (as they are),
cannot have a dot operator like .gray added-- because the function is *scalar*
with only one component; the dot operator 'mechanism' assumes that there or 2 or
more components, and fails.

Much food for thought! I'm still 'putting all of the pieces together'...

[William F Pokorny] Re: Mysterious function argument [1652 days 4 hours and 28 minutes ago]

Mon, 4 Oct 2021 08:42:18 GMT

On 10/3/21 7:05 PM, Kenneth wrote:
> My big discovery(??):
>  From experimenting, it looks like your integers (1,2,3) are pulling a
> *point-sample*  color  from  F1's  'continuous' bozo function,  from a specific
> location point in bozo's 3-D spatial pigment... the location being <1,2,3>.  And
> with the corresponding #debug results of  <0.000,1.000,0.000,0.000,0.000> as the
> color at that spatial point. Am I correct??

Close. When you make a function call to a function{pattern{}} or a 
function{pigment{}} you pass 3D positional values for x,y,z - always - 
to the pattern. In the example code this is the bozo pattern. The bozo 
pattern returns a single, continuous, scalar value in the [0..1)|] 
range. With functions, this single value can be returned directly - or 
it can be used as an index into a *_map and a vector of values from that 
map can be returned.

If you use function{pattern{bozo}}, you get the scalar pattern value and 
the function is considered a scalar function internal to POV-Ray.

If you use function{pigment{bozo}}, you get the 5D color vector from the 
*map at the map index of scalar value returned by the bozo pattern. 
Internal to POV_ray the function is then considered a vector function.

> 
> For example, by  giving your F1 and V1 functions some different values:
> #declare F1 = function{pigment{gradient x}}
> #declare V1 = F1(0.5,0,0);
> ..... the #debug result-- AND the resulting*single*  V1 color applied to a 1X1
> box
> as pigment{V1} )--  is  <0.500,0.500,0.500,0.000,0.000> -- the linear gray
> 'color' found halfway across the gradient x  map (which has a default grayscale
> color_map of its own).  Very neat!
> 
> (BTW, for animation tests, I can even do this:
> #declare V1 = F1(clock, 0.5 ,0.7) or whatever)
> 

Cool. Not something I've done and it could be useful. I've been toying 
with rtr/kla scenes as a way to document certain features - supposing I 
can get going some simple dynamic user control as the animation rolls 
ever onward...

> But going back to your original F1 and V1 functions:, I am curious about two of
> the #debug results:
> 
> Question 1:
>> v3.7/3.8 returns:
>> V1 = 0.000,1.000,0.000,0.000,0.000
> Yes, for me as well.
> 
>> The povr branch returns:
>> V1 = 0.421,0.421,0.421,0.000,0.000
>> (***) The povr branch defaults to rgb [0...1] color_maps for all
>> continuous patterns.
> *If*  I am correct about my analysis of function use as I described, your 0.421
> results are an interesting mystery to me-- especially for *all 3* red-green-blue
> channels, rather than just the green channel alone, as in Windows. The bozo
> pigment/pattern has discrete color areas that don't 'blend', AFAIK, so I'm
> curious as to which part(s) of your own color_map are producing that value...
> and for all 3 channels! My own logic tells me that the Windows and povr results
> should match-- that is, producing only a single value in the green channel,
> regardless of what that value might be.

The window / povr results would match except the povr branch uses a 
default color map of 0-1 for all continuous patterns - povr is set up 
differently so function{pigment{}} will often - but not always - return 
a different result.

> 
> Question 2:
> Your F3 function  is
>          #declare F3 = function { F0(x+1,y/2,z) }
> and the V3 function is
>          #declare V3 = F3(1,2,3);
> 
> Those have 3 components <x...,y...,z...>, yet your #debug for V3 uses just
> 'str' to pull out some kind of*single*  value (not 'vstr' to pull out all 3 or
> 5). I thought  str  would outright*fail*  with a 3-component function... yet it
> does not, interestingly. Is your F3 function 'continuous', or does it just
> create a single value? (Such distinctions are still a bit fuzzy to me.) But I'm
> equally curious as to where the final result of  0.489 comes from,
> mathematically (in 3-D space?). I can't figure that out, so far.

F3 is continuous because F0 is. F3 calls F0 which is defined as 
function{pattern{bozo}} as as such it is a scalar function - it returns 
a single value. F0 is continuous only because the bozo pattern is a 
continuous pattern. You could instead use the discrete checker pattern 
in F0 and it would then return discrete single values depending upon the 
3D location.

Aside: povr, at present, uses the default color maps as they are in 
POV-Ray proper for the half dozen or so discrete patters like checker, 
triangular, etc.

Hope my ramblings of some help.

Bill P.

[Kenneth] Re: Mysterious function argument [1652 days 13 hours and 41 minutes ago]

Sun, 3 Oct 2021 23:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> ..the other one (IIRC) that I was
> surprised at was the inability to predeclare a matrix for use in transforms.
>

Works for me! (With a transform wrapper)

#declare VIRGINIA =
transform{
matrix < 1, 1, 0,
       0, 1, 0,
       0, 0, 1,
       0, 0, 0 >
       }

box{0,1
transform{VIRGINIA}
}

[Kenneth] Re: Mysterious function argument [1652 days 14 hours and 1 minute ago]

Sun, 3 Oct 2021 23:10:00 GMT

>
> // povray +mv3.8 +iThisParseTest.inc
> #declare F0 = function {pattern {bozo}}
> #declare F1 = function {pigment {bozo}}
> #declare F2 = function {pigment {bozo
>          color_map {[0,rgbft 0][1,rgbft 1]}
>      }}
> #declare F3 = function { F0(x+1,y/2,z) }
> //#declare V0 = F0(x+1,y/2,z);
> // Parse Error: Float expected but vector or color expression found.
> #declare V1 = F1(1,2,3);
> #declare V2 = F2(1,2,3);
> #declare V3 = F3(1,2,3);
> #debug concat("\nV1 = ",vstr(5,V1,",",1,3),"\n")
> #debug concat("V2 = ",vstr(5,V2,",",1,3),"\nV3 = ",str(V3,1,3),"\n\n")
>
> #error "Parse Test. Stop early"
> //---
>

Hi again!

I've been looking at your code examples in detail for several days, and running
animation tests(!) while varying some of the function parameters (my usual
method of 'discovery' when I do not fully understand how certain code constructs
work... to *visually* see what's going on.) I am actually learning some new and
basic things about functions and their uses, that always mystified me--
specifically, plugging integers (or even floats) into a function, like your
      #declare V1 = F1(1,2,3);

In the past, Bald Eagle has valiantly tried to beat such stuff into my brain,
but I've been kind of a dunce and just didn't grasp it. :-\  Well, I think I've
finally had one of those 'eureka' moments.

My big discovery(??):
From experimenting, it looks like your integers (1,2,3) are pulling a
*point-sample* color  from  F1's  'continuous' bozo function,  from a specific
location point in bozo's 3-D spatial pigment... the location being <1,2,3>.  And
with the corresponding #debug results of  <0.000,1.000,0.000,0.000,0.000> as the
color at that spatial point. Am I correct??

For example, by  giving your F1 and V1 functions some different values:
#declare F1 = function{pigment{gradient x}}
#declare V1 = F1(0.5,0,0);
..... the #debug result-- AND the resulting *single* V1 color applied to a 1X1
box
as pigment{V1} )--  is  <0.500,0.500,0.500,0.000,0.000> -- the linear gray
'color' found halfway across the gradient x  map (which has a default grayscale
color_map of its own).  Very neat!

(BTW, for animation tests, I can even do this:
#declare V1 = F1(clock, 0.5 ,0.7) or whatever)

But going back to your original F1 and V1 functions:, I am curious about two of
the #debug results:

Question 1:
> v3.7/3.8 returns:
> V1 = 0.000,1.000,0.000,0.000,0.000
Yes, for me as well.

> The povr branch returns:
> V1 = 0.421,0.421,0.421,0.000,0.000
> (***) The povr branch defaults to rgb [0...1] color_maps for all
> continuous patterns.

*If* I am correct about my analysis of function use as I described, your 0.421
results are an interesting mystery to me-- especially for *all 3* red-green-blue
channels, rather than just the green channel alone, as in Windows. The bozo
pigment/pattern has discrete color areas that don't 'blend', AFAIK, so I'm
curious as to which part(s) of your own color_map are producing that value...
and for all 3 channels! My own logic tells me that the Windows and povr results
should match-- that is, producing only a single value in the green channel,
regardless of what that value might be.

Question 2:
Your F3 function  is
        #declare F3 = function { F0(x+1,y/2,z) }
and the V3 function is
        #declare V3 = F3(1,2,3);

Those have 3 components <x...,y...,z...>, yet your #debug for V3 uses just
'str' to pull out some kind of  *single* value (not 'vstr' to pull out all 3 or
5). I thought  str  would outright *fail* with a 3-component function... yet it
does not, interestingly. Is your F3 function 'continuous', or does it just
create a single value? (Such distinctions are still a bit fuzzy to me.) But I'm
equally curious as to where the final result of  0.489 comes from,
mathematically (in 3-D space?). I can't figure that out, so far.

I apologize if a lot of this is off-topic-- but it's all fascinating and
instructive.

[William F Pokorny] Re: Mysterious function argument [1652 days 15 hours and 37 minutes ago]

Sun, 3 Oct 2021 21:33:45 GMT

On 10/3/21 1:02 PM, Alain Martel wrote:
> Le 2021-10-02 à 09:02, William F Pokorny a écrit :
> 
>> (*) - POV-Ray proper has unique default color maps for each continuous 
>> pattern. Be sure to always specify the color map you want!
> 
>> Bill P.
>>
> 
> Not quite accurate. Several continuous patterns do have an unique 
> default colour_map, but not all.
> Those don't have a specific default map, unless this counts as a 
> specific colour_map
> colour_map{[0 rgb 0][1 rgb 1]}
>   :
> bumps, spotted, leopard, quilted, ripples, waves, granite, crackle, 
> marble, dents, spherical, boxed, cylindrical, planar.
> 
> Those have continuous gradients, but they repeat abruptly, and don't 
> have default colour map :
> gradient, onion.
> 
> The first two are identical to a bozo pattern, but without the colour_map.

Thank you for the correction Alain.

Bill P.

[Alain Martel] Re: Mysterious function argument [1652 days 20 hours and 8 minutes ago]

Sun, 3 Oct 2021 17:02:37 GMT

Le 2021-10-02 à 09:02, William F Pokorny a écrit :

> (*) - POV-Ray proper has unique default color maps for each continuous 
> pattern. Be sure to always specify the color map you want!

> Bill P.
> 

Not quite accurate. Several continuous patterns do have an unique 
default colour_map, but not all.
Those don't have a specific default map, unless this counts as a 
specific colour_map
colour_map{[0 rgb 0][1 rgb 1]}
  :
bumps, spotted, leopard, quilted, ripples, waves, granite, crackle, 
marble, dents, spherical, boxed, cylindrical, planar.

Those have continuous gradients, but they repeat abruptly, and don't 
have default colour map :
gradient, onion.

The first two are identical to a bozo pattern, but without the colour_map.

[Bald Eagle] Re: Mysterious function argument [1652 days 21 hours and 1 minute ago]

Sun, 3 Oct 2021 16:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/2/21 10:38 PM, Kenneth wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:

I've gotten tripped up with the pattern vs pigment issue myself on numerous
occasions.  I suppose that's another thing that will have to be clarified with
some example scenes, etc.

> The missing declare ability I trip over frequently, when writing raw
> SDL, is: #declare Warp00 = warp{...}.

I might have tried that in the past, but the other one (IIRC) that I was
surprised at was the inability to predeclare a matrix for use in transforms.

There are a lot of things in SDL that have similar structures, but are
separate/isolated from each other.  matrices, splines, prisms --- it would be
nice if their internal data were all addressable/accessible like arrays.

[William F Pokorny] Re: Mysterious function argument [1653 days and 48 minutes ago]

Sun, 3 Oct 2021 12:23:06 GMT

On 10/2/21 10:38 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> #declare F0 = function {pattern {bozo}}
>>   ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
>>   found instead"
>>
> [and...]
>> I just ran that 'pattern' version in v3.7.0 (Windows), and it
>> fails there too, same error message...
> 
> MY ERROR! I mixed up my various tests :-\  Those two #declared functions DO
> parse OK in Windows, in both v3.7.0 and v3.8.0 beta 1. Very sorry for the
> confusion.
> 
> What I actually *tested* was this comparison, by mistake (but still interesting,
> and maybe odd- but certainly off-topic here):
> 
> #declare PATT =
> pattern{bozo}
> ... which fails parsing
> 
> or..
> 
> #declare PATT =
> pigment{bozo}
> ...which parses successfully
> 

Ah, good. Thanks for following up.

---
Aside: In my tcl wrapper for SDL, I have functions which allow me to 
declare Patterns, Warps, Radiosity, and other blocks(1) by name so they 
can just be references later by name as needed(1). The capability to 
pre-declare certain blocks by ID unfortunately isn't / wasn't 
implemented for some features of POV-Ray's SDL.

(1) - Underneath it creates macros which then are, repeatedly, inserted 
as needed.

The missing declare ability I trip over frequently, when writing raw 
SDL, is: #declare Warp00 = warp{...}.

Bill P.

[Kenneth] Re: Mysterious function argument [1653 days 10 hours and 31 minutes ago]

Sun, 3 Oct 2021 02:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> #declare F0 = function {pattern {bozo}}
>  ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
>  found instead"
>
[and...]
> I just ran that 'pattern' version in v3.7.0 (Windows), and it
> fails there too, same error message...

MY ERROR! I mixed up my various tests :-\  Those two #declared functions DO
parse OK in Windows, in both v3.7.0 and v3.8.0 beta 1. Very sorry for the
confusion.

What I actually *tested* was this comparison, by mistake (but still interesting,
and maybe odd- but certainly off-topic here):

#declare PATT =
pattern{bozo}
... which fails parsing

or..

#declare PATT =
pigment{bozo}
...which parses successfully

[Kenneth] Re: Mysterious function argument [1653 days 17 hours and 36 minutes ago]

Sat, 2 Oct 2021 19:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/1/21 3:13 PM, Kenneth wrote:
>
>#declare F0 = function {pattern {bozo}}
> ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
> found instead"
>
>
> Hmm. Do others on windows see this sort of fail?
>
> The code parses for me with v3.7 and v3.8.
>

Good question. I just ran that 'pattern' version in v3.7.0 (Windows), and it
fails there too, same error message. I have a faint recollection that it parsed
OK in some earlier version of POV-ray like v3.6; but I could be wrong. It seems
to be a strange result in the Windows version nevertheless.

[William F Pokorny] Re: Mysterious function argument [1654 days and 8 minutes ago]

Sat, 2 Oct 2021 13:02:32 GMT

On 10/1/21 3:13 PM, Kenneth wrote:
> #declare F0 = function {pattern {bozo}}
> ...throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
> found instead"

Hmm. Do others on windows see this sort of fail?

The code parses for me with v3.7 and v3.8.

---
What I had in mind when asking myself whether u & v were also set with 
function{pattern{}} was the function{pattern{function{}}} usage. It's 
what one does to enable all the pattern modifiers for the the pattern 
wrapped function(a). The answer is the u and v values are indeed set to 
the x and y values passed through the pattern mechanism.

// povr parse test
#declare Fn00 = function {
     pattern { function { f_boom(x,y,z,u,v,0) }
         // turbulence, warps... - can applied
     }
}
#declare V00  = Fn00(1,2,3);
//---

Returns:

f_boom
1(x) -> 1,
2(y) -> 2,
3(z) -> 3,
4(0) -> 1,  // u
5(1) -> 2,  // v
6(2) -> 0

(a) - This is easier to do in the povr branch due the raw_wave and 
function_interval pattern modifiers.

---
Posting too the following v3.7..v4.0 generic code to highlight a couple 
other function {pattern | pigment} traps / concerns.

// povray +mv3.8 +iThisParseTest.inc
#declare F0 = function {pattern {bozo}}
#declare F1 = function {pigment {bozo}}
#declare F2 = function {pigment {bozo
         color_map {[0,rgbft 0][1,rgbft 1]}
     }}
#declare F3 = function { F0(x+1,y/2,z) }
//#declare V0 = F0(x+1,y/2,z);
// Parse Error: Float expected but vector or color expression found.
#declare V1 = F1(1,2,3);
#declare V2 = F2(1,2,3);
#declare V3 = F3(1,2,3);
#debug concat("\nV1 = ",vstr(5,V1,",",1,3),"\n")
#debug concat("V2 = ",vstr(5,V2,",",1,3),"\nV3 = ",str(V3,1,3),"\n\n")

#error "Parse Test. Stop early"
//---

v3.7/v.38 returns:
------------------
V1 = 0.000,1.000,0.000,0.000,0.000 (*)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489

The povr branch returns:
------------------------
V1 = 0.421,0.421,0.421,0.000,0.000 (**)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489

(*) - POV-Ray proper has unique default color maps for each continuous 
pattern. Be sure to always specify the color map you want!
(**) - The povr branch defaults to rgb [0..1] color maps for all 
continuous patterns.
(***) - The function{pigment{}} mechanism uses a full 5D color vector 
which, in all current versions of POV-Ray of which I'm aware, use only 
single float channels; Making this mechanism to pass around values more 
problematic - especially for isosurface / parametric function use. The 
function{pattern{}} mechanism returns a double float and it's faster 
than using function{pigment{}}.

Bill P.

[Kenneth] Re: Mysterious function argument [1654 days 17 hours and 56 minutes ago]

Fri, 1 Oct 2021 19:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm forever trying to do things like:
> #declare F0 = function {pattern {bozo}}
>
> and then do something like F0 (x+1, y/2, z)
>
> or F0 = function {pattern {bozo} / <2, 1, 1>}
>

Using v3.8.0 beta 1 in Windows, the following is interesting... or maybe
strange?

#declare F0 = function {pattern {bozo}}
...throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
found instead"

But...
#declare F0 = function {pigment {bozo}}
...works fine.

I had assumed that they were the same basic kind of entity (except for a
grayscale version when using 'pattern'.)

But more on-topic: Given a pigment instead, your 1st example does run, if a
function wrapper is included (plus an optional color_map, simply to make the
results more visually understandable). AND with only a single argument(?) pulled
out of the function, using a dot operator. For example, I can do some crazy
things with it...

pigment{
function{F0 (max(x,.5),pow(y,1.3),sqrt(z)).red}
color_map {[0,rgb 0][1,rgb <1,0,0>]}
}

Or .x for the function instead of .red

[Bald Eagle] Re: Mysterious function argument [1655 days 14 hours and 41 minutes ago]

Thu, 30 Sep 2021 22:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

> Aside: I've been playing with other stuff most of the day, but
> we have too that function { pattern {} } mode where you don't - cannot -
> specify an argument list for the function. In that case I expect all the
> values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify
> u and v set to x and y I guess, but expect that the case.

Ah, yeah.
I've had to wrangle a lot with those too.
I'm forever trying to do things like:
#declare F0 = function {pattern {bozo}}

and then do something like F0 (x+1, y/2, z)

or F0 = function {pattern {bozo} / <2, 1, 1>}

Functions are certainly challenging in the current implementation.  It takes a
while to get used to what you can and cannot do, and there are a lot of "tricks"
to getting the syntax and expressions worked out to accomplish what one wants.

[Bald Eagle] Re: Mysterious function argument [1655 days 15 hours and 11 minutes ago]

Thu, 30 Sep 2021 22:00:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
> >
> > As Ricky says, it's certainly a useful "feature",
>
> Hardly.  I think it's a horrible feature.

A horribly useful feature then.  :D

[Cousin Ricky] Re: Mysterious function argument [1655 days 15 hours and 20 minutes ago]

Thu, 30 Sep 2021 21:50:55 GMT

On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
> 
> As Ricky says, it's certainly a useful "feature",

Hardly.  I think it's a horrible feature.

My point was that if it's significant enough to use in an example, then it

> [...] could probably use a good
> post, some example code, or at some point, a more detailed explanation in the
> documentation.

[Cousin Ricky] Re: Mysterious function argument [1655 days 15 hours and 26 minutes ago]

Thu, 30 Sep 2021 21:44:43 GMT

On 2021-09-30 1:03 PM (-4), B. Gimeno wrote:
> 
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
> 
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;

This does not apply in the context of function parameters.  Function
parameters are not vector constants, but variable scalars.

In the foo3 example in particular, you can see that the pre-declared
value of x is not used: 0 does not equal <1, 0, 0>.

[William F Pokorny] Re: Mysterious function argument [1655 days 19 hours and 24 minutes ago]

Thu, 30 Sep 2021 17:46:26 GMT

On 9/30/21 1:27 PM, Bald Eagle wrote:
> AFAIK, if you use all of those identifiers in a function, they will all return
> zero until you assign them a value by passing a value into the function call
> using that variable name.

Excepting 't'. In the function body use of 't' where it is otherwise not 
defined results in:

File 'wham.inc' line 19:
Parse Error:
Expected 'operand', 't' found instead
Fatal error in parser: Cannot parse input.
Render failed

Aside: I've been playing with other stuff most of the day, but
we have too that function { pattern {} } mode where you don't - cannot - 
specify an argument list for the function. In that case I expect all the 
values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify 
u and v set to x and y I guess, but expect that the case.

Bill P.

[Bald Eagle] Re: Mysterious function argument [1655 days 19 hours and 41 minutes ago]

Thu, 30 Sep 2021 17:30:00 GMT

"B. Gimeno" <nomail@nomail> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > This suggests that POV-Ray pre-assigned 0 to x.  That this construction
> > is given as an example suggests that this is a significant feature
> > (however inadvisable to use), and not just a parser glitch.  Shouldn't
> > there be some explanation of this feature?
>
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6
>
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
>
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;
>
>
> It shouldn't be like you say. But by the trunk of the fifth elephant that it is.
>
> B. Gimeno

Right, but those are if you're accessing those values from the regular parser.
When you access them from the _function parser / VM_, you get a different set of
values.  I made a post about this once - and of course I can't find it ATM.

AFAIK, if you use all of those identifiers in a function, they will all return
zero until you assign them a value by passing a value into the function call
using that variable name.

As Ricky says, it's certainly a useful "feature", but could probably use a good
post, some example code, or at some point, a more detailed explanation in the
documentation.

[B Gimeno] Re: Mysterious function argument [1655 days 20 hours and 6 minutes ago]

Thu, 30 Sep 2021 17:05:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> This suggests that POV-Ray pre-assigned 0 to x.  That this construction
> is given as an example suggests that this is a significant feature
> (however inadvisable to use), and not just a parser glitch.  Shouldn't
> there be some explanation of this feature?

https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6

"All built-in vector identifiers never change value. They are defined as though
the following lines were at the start of every scene.

#declare x = <1, 0, 0>;
#declare y = <0, 1, 0>;
#declare z = <0, 0, 1>;
#declare t = <0, 0, 0, 1>;
#declare u = <1, 0>;
#declare v = <0, 1>;


It shouldn't be like you say. But by the trunk of the fifth elephant that it is.

B. Gimeno

[Cousin Ricky] Mysterious function argument [1655 days 23 hours and 31 minutes ago]

Thu, 30 Sep 2021 13:39:42 GMT

The reference manual (section 3.3.1.8.3, or 2.3.1.8.3 in the wiki) gives
the following as a legal function definition:

  #declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }

The function body refers to x, even though x is not one of the declared
arguments.  But the function still works, somehow.  The following scene

----------[BEGIN SCENE]----------
#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }
#declare G = foo3 (1, 2, 3, 4);
#debug concat ("G = ", str (G, 0, 1), "\n")
-----------[END SCENE]-----------

yields the output:

G = 18.0

Manually working through the function yields
  x + y * z + k1 * y + k2
= x + 4 * 3 + 1 * 4 + 2
= x + 12 + 4 + 2
= x + 18

This suggests that POV-Ray pre-assigned 0 to x.  That this construction
is given as an example suggests that this is a significant feature
(however inadvisable to use), and not just a parser glitch.  Shouldn't
there be some explanation of this feature?

[Alain Martel] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1721 days 21 hours and 48 minutes ago]

Mon, 26 Jul 2021 15:22:13 GMT

Le 2021-07-25 à 18:00, clipka a écrit :
> It might be worth weaving the following information into the 
> documentation of our "datetime" function:
> 
> -------------------------
> 
> Which codes are supported depends on the platform POV-Ray is compiled 
> an/or running on.
> 
> In POV-Ray v3.7, the following codes can be expected to work reliably:
> 
> a,A,b,B,c,d,H,I,j,m,M,p,S,U,w,W,x,X,y,Y,Z,%
> 
> In POV-Ray v3.8, the following additional codes can be expected to work 
> reliably:
> 
> a,A,b,B,c,C,d,D,e,F,g,G,h,H,I,j,m,M,n,p,r,R,S,t,T,u,U,V,w,W,x,X,y,Y,z,Z,%
> 
> -------------------------
> 
> (Side note: The C99/C++11 standards define additional two-letter codes 
> starting with E or O; while those should also work in POV-Ray v3.8, 
> their result _will_ differ between systems, depending on the language 
> settings of the computer.
> 
> 
> (Also, note to self and fellow developers: It may be worth adding a 
> check in POV-Ray itself, to verify whether the formatting string 
> submitted is actually portable across platforms, and warn if it isn't.)

It may also be good to give the actual meaning of those codes when used 
with datetime.
In the current documentation, we only have
«%Y-%m-%d %H:%M:%S» as the default format string.

Here, %Y can be assumed to represent the year, %m the month, %d the day, 
%H the hour, %M the minutes and %S the seconds.

I have no hint about the meaning of any of the others.

[clipka] Re: POV-Ray v3.8.0-beta 1 - Parse error using "%... [1722 days 15 hours and 10 minutes ago]

Sun, 25 Jul 2021 22:00:58 GMT

It might be worth weaving the following information into the 
documentation of our "datetime" function:

-------------------------

Which codes are supported depends on the platform POV-Ray is compiled 
an/or running on.

In POV-Ray v3.7, the following codes can be expexted to work reliably:

a,A,b,B,c,d,H,I,j,m,M,p,S,U,w,W,x,X,y,Y,Z,%

In POV-Ray v3.8, the following additional codes can be expexted to work 
reliably:

a,A,b,B,c,C,d,D,e,F,g,G,h,H,I,j,m,M,n,p,r,R,S,t,T,u,U,V,w,W,x,X,y,Y,z,Z,%

-------------------------

(Side note: The C99/C++11 standards define additional two-letter codes 
starting with E or O; while those should also work in POV-Ray v3.8, 
their result _will_ differ between systems, depending on the language 
settings of the computer.


(Also, note to self and fellow developers: It may be worth adding a 
check in POV-Ray itself, to verify whether the formatting string 
submitted is actually portable across platforms, and warn if it isn't.)

[clipka] Re: Not a v3.8 feature [1745 days 6 hours and 35 minutes ago]

Sat, 3 Jul 2021 06:35:39 GMT

Am 02.07.2021 um 23:00 schrieb Mr:

>> However, the 40 character limit for identifiers had already been dropped
>> much earlier, at least before v3.6.2. Somehow it had just stayed in the
>> docs in a few places, up to (and including) v3.7.
> 
> Hi,
> duly noted and corrected in the eight or so places that came up from the wiki
> search. let me know if the specific one you saw it In has not been amended yet.

Thanks for taking care of this; however:

- I highly doubt v3.6.2 was the actual version in which it was changed; 
it was just the earliest version which I tested it with.

- Does it really make sense to have this information in a section titled 
"Version 3.8" and starting with "These changes [...] pertain to the 
version 3.8 release"?

If it should remain there, I would argue to put it in a separate 
sub-section thereof, specifically for belated changes to the docs. 
Something dedicated to the topic of, "Things that may be new to you, but 
are actually totally old, and just hadn't made it into the 
documentationm until now".

[Mr] Re: Default values in v3.8.0 [1745 days 16 hours and 1 minute ago]

Fri, 2 Jul 2021 21:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> > Isn't like a mid-grey the accepted graphics "standard" for "nothing".
>
> Mid-grey is certainly /one/ standard, but it is not the only one - white
> being another (e.g. the default material for geometric primitives in DAZ
> studio).
>
> White has the decided advantage over mid-grey in that it is well-defined
> in terms of gamma: White is always white.
>
> Also, with `diffuse` defaulting to a value below 1.0, it is effectively
> not pearly white.

Also prediction of tint is easier with 1 as multiplier than with anything else,
plus, it provides one less value shift in the case of bitmapped textured
finishes.

[Mr] Re: Not a v3.8 feature [1745 days 16 hours and 6 minutes ago]

Fri, 2 Jul 2021 21:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> In the section on new v3.8 features, the docs on the Wiki claim that:
>
>      Identifiers are no longer limited to just 40 characters in length
>
>
> In a sense, that is totally true: In v3.8, identifiers are not limited
> to just 40 characters in length.
>
> However, the 40 character limit for identifiers had already been dropped
> much earlier, at least before v3.6.2. Somehow it had just stayed in the
> docs in a few places, up to (and including) v3.7.

Hi,
duly noted and corrected in the eight or so places that came up from the wiki
search. let me know if the specific one you saw it In has not been amended yet.

[clipka] Not a v3.8 feature [1746 days 17 hours and 44 minutes ago]

Thu, 1 Jul 2021 19:26:23 GMT

In the section on new v3.8 features, the docs on the Wiki claim that:

     Identifiers are no longer limited to just 40 characters in length


In a sense, that is totally true: In v3.8, identifiers are not limited 
to just 40 characters in length.

However, the 40 character limit for identifiers had already been dropped 
much earlier, at least before v3.6.2. Somehow it had just stayed in the 
docs in a few places, up to (and including) v3.7.

[clipka] Re: Radiosity block `brilliance` setting [1761 days 3 hours and 15 minutes ago]

Thu, 17 Jun 2021 09:55:55 GMT

Am 17.06.2021 um 10:21 schrieb Ash Holsenback:

>
https://wiki.povray.org/content?limit=50&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

> 
> 
> made one change and added support for the /new/ section. it's needed for 
> the document map... section numbering

Thanks, much appreciated.

[Ash Holsenback] Re: Radiosity block `brilliance` setting [1761 days 4 hours and 50 minutes ago]

Thu, 17 Jun 2021 08:21:03 GMT

On 6/16/21 5:00 PM, Mr wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Hi folks,
>>
>> The following - or something along those lines - needs to be woven into
>> the Radiosity reference documentation on the Wiki
>> (http://wiki.povray.org/content/Reference:Radiosity); in addition, it
>> might be worth mentioning in the what's-new section:
>>
>> --------------------- Syntax:
>>
>> (The syntax needs to be extended to include another setting,
>> `brilliance`, which takes a boolean parameter, i.e. `on` or `off`.)
>>
>> --------------------- Description:
>>
>> By default, radiosity computations presume that the texture to render
>> has a `brilliance` setting of 1. In scenes that make heavy use of
>> radiosity, this may cause surfaces to look excessively dull.
>>
>> As of POV-Ray v3.8, you can force radiosity to respect the `brilliance`
>> finish parameter, by specifying `brilliance on` in the radiosity block.
>> Note however that this comes at a cost of rendering speed, especially
>> when combining surfaces with various different `brilliance` settings in
>> close proximity.
> 
> Added so it doesn't get lost, do not hesitate to advice me restyling if needed.
> 

https://wiki.povray.org/content?limit=50&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

made one change and added support for the /new/ section. it's needed for 
the document map... section numbering

[clipka] Re: Radiosity block `brilliance` setting [1761 days 12 hours and 50 minutes ago]

Thu, 17 Jun 2021 00:20:50 GMT

Am 16.06.2021 um 23:00 schrieb Mr:

> Added so it doesn't get lost, do not hesitate to advice me restyling if needed.

Looks good. However, I _think_ it doesn't need `#version 3.8` to work.


Which, now that I think of it, isn't really such a good idea, because it 
means it can be used in a scene that claims to be a v3.7 scene, and then 
someone gets surprised when they try to render that scene with genuine 
v3.7...

I think I've just found myself some more work cut out for me...


So leave that in the documentation, because that's how it _should_ be.

[Mr] Re: Radiosity block `brilliance` setting [1761 days 16 hours and 6 minutes ago]

Wed, 16 Jun 2021 21:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> The following - or something along those lines - needs to be woven into
> the Radiosity reference documentation on the Wiki
> (http://wiki.povray.org/content/Reference:Radiosity); in addition, it
> might be worth mentioning in the what's-new section:
>
> --------------------- Syntax:
>
> (The syntax needs to be extended to include another setting,
> `brilliance`, which takes a boolean parameter, i.e. `on` or `off`.)
>
> --------------------- Description:
>
> By default, radiosity computations presume that the texture to render
> has a `brilliance` setting of 1. In scenes that make heavy use of
> radiosity, this may cause surfaces to look excessively dull.
>
> As of POV-Ray v3.8, you can force radiosity to respect the `brilliance`
> finish parameter, by specifying `brilliance on` in the radiosity block.
> Note however that this comes at a cost of rendering speed, especially
> when combining surfaces with various different `brilliance` settings in
> close proximity.

Added so it doesn't get lost, do not hesitate to advice me restyling if needed.

[clipka] Radiosity block `brilliance` setting [1762 days and 40 minutes ago]

Wed, 16 Jun 2021 12:30:34 GMT

Hi folks,

The following - or something along those lines - needs to be woven into 
the Radiosity reference documentation on the Wiki 
(http://wiki.povray.org/content/Reference:Radiosity); in addition, it 
might be worth mentioning in the what's-new section:

--------------------- Syntax:

(The syntax needs to be extended to include another setting, 
`brilliance`, which takes a boolean parameter, i.e. `on` or `off`.)

--------------------- Description:

By default, radiosity computations presume that the texture to render 
has a `brilliance` setting of 1. In scenes that make heavy use of 
radiosity, this may cause surfaces to look excessively dull.

As of POV-Ray v3.8, you can force radiosity to respect the `brilliance` 
finish parameter, by specifying `brilliance on` in the radiosity block. 
Note however that this comes at a cost of rendering speed, especially 
when combining surfaces with various different `brilliance` settings in 
close proximity.

[Ash Holsenback] Re: Terminology error in the spline workshop [2022 days 2 hours and 53 minutes ago]

Tue, 29 Sep 2020 10:17:57 GMT

On 9/26/20 1:46 PM, Cousin Ricky wrote:
> In the spline workshop (section 2.3.1.1.1 of the tutorial, section 
> 1.3.1.1.1 in the wiki), bezier_spline is referred to as a type of 
> quadratic spline.Â  But POV-Ray's BÃ©zier spline implementation
is cubic.

corrected

[Cousin Ricky] Terminology error in the spline workshop [2024 days 19 hours and 24 minutes ago]

Sat, 26 Sep 2020 17:46:13 GMT

In the spline workshop (section 2.3.1.1.1 of the tutorial, section 
1.3.1.1.1 in the wiki), bezier_spline is referred to as a type of 
quadratic spline.  But POV-Ray's BÃ©zier spline implementation is cubic.

[Ash Holsenback] Re: Undocumented -b / +b flag matching Bounding= [2085 days 23 hours and 47 minutes ago]

Mon, 27 Jul 2020 13:23:22 GMT

On 7/26/20 10:16 AM, William F Pokorny wrote:
> More accurately the following:
> 
> 3.2.8.4 Automatic Bounding Control
> 
> Bounding=boolÂ Â  Turn bounding on/off
>
+MBÂ Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding on; Set threshold to 3 or previous amount
>
-MBÂ Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding off
> Bounding_Threshold=nÂ  Set bound threshold to n
>
+MBnÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding on; bound threshold to n
>
-MBnÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding off; set future threshold to n
> 
> Should be:
> 
> Bounding=boolÂ Â  Turn bounding on/off
>
+BÂ Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding on; Set threshold to 3 or previous amount
>
-BÂ Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding off
> Bounding_Threshold=nÂ  Set bound threshold to n
>
+MBnÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding on; bound threshold to n
>
-MBnÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
Turn bounding off; set future threshold to n
> 
> Bill P.

done

[William F Pokorny] Undocumented -b / +b flag matching Bounding= [2086 days 22 hours and 54 minutes ago]

Sun, 26 Jul 2020 14:16:38 GMT

More accurately the following:

3.2.8.4 Automatic Bounding Control

Bounding=bool   Turn bounding on/off
+MB             Turn bounding on; Set threshold to 3 or previous amount
-MB             Turn bounding off
Bounding_Threshold=n  Set bound threshold to n
+MBn                  Turn bounding on; bound threshold to n
-MBn                  Turn bounding off; set future threshold to n

Should be:

Bounding=bool   Turn bounding on/off
+B              Turn bounding on; Set threshold to 3 or previous amount
-B              Turn bounding off
Bounding_Threshold=n  Set bound threshold to n
+MBn                  Turn bounding on; bound threshold to n
-MBn                  Turn bounding off; set future threshold to n

Bill P.

[Le Forgeron] Re: Details about the interaction of CSG with no... [2210 days 22 hours and 5 minutes ago]

Tue, 24 Mar 2020 15:05:31 GMT

Le 24/03/2020 Ã  14:21, Oblomov a Ã©critÂ :
> Hello all,
> 
> I have [recently discovered][link] that `no_image` has no effect in a nested
> difference > union > member CSG.
> 
> [link]:
>
http://news.povray.org/povray.general/thread/%3Cweb.5e7944321f97b21e393d37fe0%40news.povray.org%3E/
> 
> I have perused the existing documentation before asking on the povray.general
> newsgroup, but I haven't found sufficiently detailed information about the
> interaction of these attributes with CSG. Are the details documented somewhere
> that I have missed? If not, would it be a good idea to document it somewhere? Is
> there any way I can help contribute?

The documentation is in Wiki (and that's the master for other
documentations, as far as I known).

http://wiki.povray.org/content/Main_Page

The page of the wiki are usually locked (due to hooligans), but you can
provide contribution in the "discussion" page of the page you want to
change.

Now, to become a registered user on the wiki, I forgot how to do that.

As everyone is lazy (ok, I am very lazy when it comes to documentation),
it is probably better to provide fully updated paragraph(s) in the
discussion page, than providing only questions & comments (but you can
have questions and comments in discussion page, no problem), or
indication such as "the subject should be plural, or you need to
conjugate the verb" (you have the solution; so share it, and do not make
other think and redo your work).

I would believe that object modifiers such as no_image, no_reflection,
no_shadow would apply only at the top level (CSG are probably alone in
having depths in composition), but I really never though about it.

[Oblomov] Details about the interaction of CSG with no_ima... [2210 days 23 hours and 46 minutes ago]

Tue, 24 Mar 2020 13:25:00 GMT

Hello all,

I have [recently discovered][link] that `no_image` has no effect in a nested
difference > union > member CSG.

[link]:
http://news.povray.org/povray.general/thread/%3Cweb.5e7944321f97b21e393d37fe0%40news.povray.org%3E/

I have perused the existing documentation before asking on the povray.general
newsgroup, but I haven't found sufficiently detailed information about the
interaction of these attributes with CSG. Are the details documented somewhere
that I have missed? If not, would it be a good idea to document it somewhere? Is
there any way I can help contribute?

Cheers,

Oblomov

[Melody] Re: Version 3.8: Input_File_Name - where has it ... [2308 days 6 hours and 1 minute ago]

Wed, 18 Dec 2019 07:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Sound as disparaging as you want.  I have an ex-wife.  You'd need to struggle to
> register on that logarithmic scale.  ;)  :D

OK. : )

I know why. A whole world of ex-wifes ...
I cant get the ringing out of my head.
It's Tommy Lee, Professor of Darkness, telling off the Heretic Preacher,
"The shadow of the ax hangs over every joy, every ..."
 sooner or later, futility.
....
"And if that pain were actually collective instead of simply reiterative then
the sheer weight of it would drag the world from the walls of the universe and
send it crashing and burning through whatever night it might yet be capable of
engendering until it was not even ash."

It's destroying mine, and they point fingers and say, "See what you've created."
I say, you see the impact of others yet?

Is Tommy still here?
Always ends the same? that has to be arrogance.

[greytery] Re: Version 3.8: Input_File_Name - where has it ... [2308 days 18 hours and 6 minutes ago]

Tue, 17 Dec 2019 19:05:01 GMT

PROBLEM IDENTIFIED/FIXED

The OLD .ini files contain the option 'Radiosity=On' and the new files DONT.
The .ini file is correctly read, but when hitting this option, the failure is:
'Failed to parse command-line option'.
Simply commenting out this option in the OLD .ini files means the command line
"povray inifilename" works exactly as expected.
This option was changed in Version 3.7 AFAIK - and the OLD files specifically
state Version 3.1 (Doh!).
So, maybe a case of backwards incompatibility?  This is downgraded to a moan:
Could the 'Failed to parse ...' message be a bit more helpful?

Got loads of ideas for further use of this library, and will post as and when..


> > If you want I can post that .mac file here, but I think we should get Anton
> > involved because the files all have his Copyright.
>
> good idea.  I've not seen an email address in the files yet, so, if you have it,
> perhaps he can be persuaded to join in, here?
>

Have left a message on his website: www.virtualbricks.nl

tery

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2309 days 22 hours and 11 minutes ago]

Mon, 16 Dec 2019 15:00:04 GMT

hi,

"greytery" <gre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> Yep. I 'fixed' the renaming issue for these OLD models with a "renamed.mac"
> file, which contains about 120 lines like :
>     #macro f_block1_12(color_tex,age) plate1x12(color_tex,age) #end
> Then in each of the OLD .pov files, #include "renamed.mac", and it flies.

neat.


> The color issues - at the moment I've edited the NEW material.lib to contain the
> OLD colors / textures, but it would be better to include the missing colors in
> the "renamed.mac" file.
> Another problem is with material_map. I found I had to remove 'interpolate 4'
> from these OLD macros, otherwise the transfers are smudged.

thanks for info.


> If you want I can post that .mac file here, but I think we should get Anton
> involved because the files all have his Copyright.

good idea.  I've not seen an email address in the files yet, so, if you have it,
perhaps he can be persuaded to join in, here?


> > > got to dash - UK election news starts in 5 mins - will be up all night!
> > was it .. worth it?  ;-)
>
> Don't like watching grown men cry.  But it takes all the satisfaction out of
> Voting if you have to hold your nose and keep your eyes shut when you put your
> cross in the box.

like DB, I was surprised by the scale, 365 seats!  (incredible..)  alas, that
post appears to have .. disappeared.


regards, jr.

[greytery] Re: Version 3.8: Input_File_Name - where has it ... [2311 days 18 hours and 26 minutes ago]

Sat, 14 Dec 2019 18:45:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>

OK OK OK. 'FIXED'. Stand Down. As you were ...

The problem is with the .ini files in each of the OLD examples, e.g. 6338.ini.
These were generated by Version 3.1.  I've 'fixed' that by copying one of the
NEW ini, e.g. crocodile_engine.ini, and replacing the OLD .ini file - changing
the 'Input_File_Name=' of course.  Once done they ALL behave themselves as
normal. Just what the real underlying problem is - not sure - probably low level
file format handling, unix/windows, blah, blah. Whatever.
They are now producing some smashing .tga scenes and much fun will follow.

> ok, had a quick first look at 6338.  problems with (a) renamed components (eg
> "ffblock2_2" is now "tile2x2".  there are quite a few others) in 6338.{mac,pov},
> and  (b) names of materials (eg there's no "red_tex" but a "bright_red_tex"
> exists); also, one or two instances where macro #arguments do not match up.
> </sigh>  will have a closer look in the coming week.
>

Yep. I 'fixed' the renaming issue for these OLD models with a "renamed.mac"
file, which contains about 120 lines like :
    #macro f_block1_12(color_tex,age) plate1x12(color_tex,age) #end
Then in each of the OLD .pov files, #include "renamed.mac", and it flies.
The color issues - at the moment I've edited the NEW material.lib to contain the
OLD colors / textures, but it would be better to include the missing colors in
the "renamed.mac" file.
Another problem is with material_map. I found I had to remove 'interpolate 4'
from these OLD macros, otherwise the transfers are smudged.
If you want I can post that .mac file here, but I think we should get Anton
involved because the files all have his Copyright.

> > got to dash - UK election news starts in 5 mins - will be up all night!
> was it .. worth it?  ;-)

Don't like watching grown men cry.  But it takes all the satisfaction out of
Voting if you have to hold your nose and keep your eyes shut when you put your
cross in the box.

tery

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2313 days 1 hour and 56 minutes ago]

Fri, 13 Dec 2019 11:15:01 GMT

hi,

"greytery" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > if you still have unmodified copies of 6338, would you mind posting?  I do want
> > to have a look (next week).

ok, had a quick first look at 6338.  problems with (a) renamed components (eg
"ffblock2_2" is now "tile2x2".  there are quite a few others) in 6338.{mac,pov},
and  (b) names of materials (eg there's no "red_tex" but a "bright_red_tex"
exists); also, one or two instances where macro #arguments do not match up.
</sigh>  will have a closer look in the coming week.

> got to dash - UK election news starts in 5 mins - will be up all night!

was it .. worth it?  ;-)

regards, jr.

[greytery] Re: Version 3.8: Input_File_Name - where has it ... [2313 days 15 hours and 11 minutes ago]

Thu, 12 Dec 2019 22:00:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> if you still have unmodified copies of 6338, would you mind posting?  I do want
> to have a look (next week).
>

Best 'unmodified copies' are at Melody's 2nd posting with the
attachment"more_lego.zip" ... see:

http://news.povray.org/povray.binaries.utilities/thread/%3Cweb.5dc87d5f9ec945b49da690110%40news.povray.org%3E/

got to dash - UK election news starts in 5 mins - will be up all night!
tery

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2314 days 21 hours and 6 minutes ago]

Wed, 11 Dec 2019 16:05:02 GMT

hi,

"greytery" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> > sorry, am getting .. lost in translation.  :-)  is this the same library as
> > available on the link below?  if yes, which file(s)?
> > ...
> > nice site, thanks.  I looked at the lego library posted here, recently, but
> > found that to be in .. a not-useful state.  the one from the Dutch site is much
> > better, even has documentation!
> >
> I started with the links to the older version of the library posted by Melody;
> Subject: LEGO Library Date: 10 Nov 2019 21:15:01
> This older library is for Version 3.1 but contains 4/5 example LEGO models. Out
> Of Date - but looked very interesting so I disappeared down the LEGO rabbit
> hole. I could be here for some time ....
>
> The new version at the Dutch site is Version 3.7, has changed partnames and
> colours, and includes radiosity, for example. Also it contains 4/5 different
> examples. E.G. 04551_Crocodile_Engine.   'povray crocodile_engine' invokes the
> 'crocodile_engine.ini' just fine, output is tga. (Note: edit the pov file to
> switch off radiosity or lose the will to live).

right.  the "new" version is all I have here.

had to change definition and use of 'grey' in 'material.lib' to 'grey1' to avoid
the keyword name clash, but works ok from then.  the formatting of some files
too is weird -- all content in a single line!

you're not wrong on radiosity.  have now set 'quality=8' in the 'povray.ini'.
:-)


> Switch to one of the earlier examples (6338_hurricane_harbour) and that's when I
> hit the Command Line problem on 3.8: The 6338.ini/6338.pov files cant be called
> successfully unless it's 'povray +I6338.pov', which ignores the .ini file
> anyway.

so, the new version only has 4551, 6482, and 6923 samples.  the Dutch site says
'6338' source "not yet available".

> ...
> My point is that the Command Line call is failing to behave as expected.

if you still have unmodified copies of 6338, would you mind posting?  I do want
to have a look (next week).


regards, jr.

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2314 days 21 hours and 6 minutes ago]

Wed, 11 Dec 2019 16:05:02 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > yes, I appreciate that.  hence the idea that there should be two distinct
> > frontend (prisms and pulleys) macros, utilising the existing more or less as
> > they are.
>
> Nope, just need to add one more bit to find a tangent between a point and a
> circle.
> ...
> > wrt moving parts, my guess is that the "trick" will be working with (and from
> > the perspective of?) the full length of the rope/cable, since it needs to look
> > reasonably realistic when animated.
>
> Seems like Leroy worked most of that out already.

yes!  hoping, at some point, to get a look at his code.


> If you could get this to work with that...
> ...
> :)  :)  :)

need to find time to look at those links.  (not this week though.  bought a new
2nd hand machine today, to be used for POV-Ray, pretty much exclusively.  :-))


regards, jr.

[greytery] Re: Version 3.8: Input_File_Name - where has it ... [2315 days 14 hours and 56 minutes ago]

Tue, 10 Dec 2019 22:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> sorry, am getting .. lost in translation.  :-)  is this the same library as
> available on the link below?  if yes, which file(s)?
> ...
> nice site, thanks.  I looked at the lego library posted here, recently, but
> found that to be in .. a not-useful state.  the one from the Dutch site is much
> better, even has documentation!
>
I started with the links to the older version of the library posted by Melody;
Subject: LEGO Library Date: 10 Nov 2019 21:15:01
This older library is for Version 3.1 but contains 4/5 example LEGO models. Out
Of Date - but looked very interesting so I disappeared down the LEGO rabbit
hole. I could be here for some time ....

The new version at the Dutch site is Version 3.7, has changed partnames and
colours, and includes radiosity, for example. Also it contains 4/5 different
examples. E.G. 04551_Crocodile_Engine.   'povray crocodile_engine' invokes the
'crocodile_engine.ini' just fine, output is tga. (Note: edit the pov file to
switch off radiosity or lose the will to live).

Switch to one of the earlier examples (6338_hurricane_harbour) and that's when I
hit the Command Line problem on 3.8: The 6338.ini/6338.pov files cant be called
successfully unless it's 'povray +I6338.pov', which ignores the .ini file
anyway.

Now,the old examples use parts/colours that aren't in the new library and
materials include files, and so will fail to parse anyway. (But I've then
started to edit the model files to use the new partnames/colours and it's nearly
working ...)
My point is that the Command Line call is failing to behave as expected.

Anyway, I'll continue to dig while I'm down this hole.
tery

[Bald Eagle] Re: Version 3.8: Input_File_Name - where has it ... [2315 days 18 hours and 21 minutes ago]

Tue, 10 Dec 2019 18:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:

> yes, I appreciate that.  hence the idea that there should be two distinct
> frontend (prisms and pulleys) macros, utilising the existing more or less as
> they are.

Nope, just need to add one more bit to find a tangent between a point and a
circle.
http://www.ambrsoft.com/TrigoCalc/Circles2/CirclePoint/CirclePointDistance.htm

> wrt moving parts, my guess is that the "trick" will be working with (and from
> the perspective of?) the full length of the rope/cable, since it needs to look
> reasonably realistic when animated.

Seems like Leroy worked most of that out already.

If you could get this to work with that...
http://news.povray.org/povray.binaries.images/thread/%3C3c4d365b%40news.povray.org%3E/

:)  :)  :)

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 6 hours and 51 minutes ago]

Tue, 10 Dec 2019 06:20:01 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 12/9/19 8:20 PM, also sprach jr:
> > alias nicepov='nice -n 19 povray'
> >
> just fyi, "nice" really doesn't do anything, at least not since the
> invention of multicore CPUs.  The scheduler just picks stuff and goes.
>
> This is an improvement, over where for several years cores could remain
> idle with tasks pending.  Say you've got a normal priority task running
> one thread. It gets dispatched and since there are no other normal
> priority tasks pending, the scheduler is done, even though there are 3
> idle cores and several "low" priority tasks pending.
>
> There is a compile in replacement for the scheduler that fixes the
> current behavior, but the author recommends not using it and waiting for
> his new scheduler, which hopefully Linus will accept into the kernel.
>
> I got no answers to this question ...
> but further research led me to the statements above.

interesting, thanks, and new to me.  I suspect I will simply continue to use it
in aliases and scripts though.

wrt the problem in the question, have you read 'man 7 cpuset'?  no personal
experience, but the reading suggests it should be possible to sort of partition
the system resources and then set up to get the benefit of the "Scheduler load
balancing".

btw, re 'qtpovmodeler', what's with the baseinsertrules.xml file not found?
(same for the docmap xml).  also, and that may be my window manager to blame
(WindowMaker 0.95.7), main menu accelerator key bindings do not work for me.

regards, jr.

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 6 hours and 51 minutes ago]

Tue, 10 Dec 2019 06:20:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > and those.  (have never actually used quick colours)  (inis make using multiple
> > declare=xyz=off type controls easy, I prefer it over having to '#switch' in the
> > scene)
>
> Not immediately apparent to me - maybe you can post an illustrative example
> somewhere at some point.

first off, don't know why I wrote 'xyz=off' which wouldn't work, numbers only,
afaik.  also poorly written, sorry.

off the top of head, any scene which can be used with different sets of constant
values to get corresponding results, like Bruno Cabasson changing the sun's
angle to get differently lit clouds.  these parameter sets, in the scene, are
likely to be inside a '#switch' or an '#if .. #elseif .. #end'.  instead, they
can be placed in an ini, not bloating the scene, and no more editing the scene
if just one value needs adjusting, or a new set of parameters needs adding.

not much of a case but works for me.  (perhaps just some "faulty" wiring in my
brain  ;-))

> > I don't want to sound .. disparaging, but, ime, that's not how it works, you
> > just have to have no alternative (initially, at least).
>
> Sound as disparaging as you want.  I have an ex-wife.  You'd need to struggle to
> register on that logarithmic scale.  ;)  :D

ouch.

> > when (_if_) I get to the point where I can understand and make your code "my
> > own", I plan to replicate the pulleys depicted on the cover of this book:
> > <www.amazon.com/POSIX-4-Programmers-Guide-Programming-World/dp/1565920740>
>
> Well that ought to be easy, though I'll have to see how well-suited what I have
> is for the hanging weight-to-pulley parts.  Most of what I was aiming for was
> drawing "closed" curves, not the "open" or loose-end parts of block and tackle.

yes, I appreciate that.  hence the idea that there should be two distinct
frontend (prisms and pulleys) macros, utilising the existing more or less as
they are.

wrt moving parts, my guess is that the "trick" will be working with (and from
the perspective of?) the full length of the rope/cable, since it needs to look
reasonably realistic when animated.

regards, jr.

[Dick Balaska] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 9 hours and 20 minutes ago]

Tue, 10 Dec 2019 03:50:52 GMT

Am 12/9/19 8:20 PM, also sprach jr:

> alias nicepov='nice -n 19 povray'
> 
just fyi, "nice" really doesn't do anything, at least not since the 
invention of multicore CPUs.  The scheduler just picks stuff and goes.

This is an improvement, over where for several years cores could remain 
idle with tasks pending.  Say you've got a normal priority task running 
one thread. It gets dispatched and since there are no other normal 
priority tasks pending, the scheduler is done, even though there are 3 
idle cores and several "low" priority tasks pending.

There is a compile in replacement for the scheduler that fixes the 
current behavior, but the author recommends not using it and waiting for 
his new scheduler, which hopefully Linus will accept into the kernel.

I got no answers to this question
https://askubuntu.com/questions/1180605/priority-trouble-with-nice-renice
but further research led me to the statements above.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Bald Eagle] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 11 hours and 1 minute ago]

Tue, 10 Dec 2019 02:10:01 GMT

"jr" <cre### [at] gmailcom> wrote:

> and those.  (have never actually used quick colours)  (inis make using multiple
> declare=xyz=off type controls easy, I prefer it over having to '#switch' in the
> scene)

Not immediately apparent to me - maybe you can post an illustrative example
somewhere at some point.

> I don't want to sound .. disparaging, but, ime, that's not how it works, you
> just have to have no alternative (initially, at least).

Sound as disparaging as you want.  I have an ex-wife.  You'd need to struggle to
register on that logarithmic scale.  ;)  :D

> when (_if_) I get to the point where I can understand and make your code "my
> own", I plan to replicate the pulleys depicted on the cover of this book:
> <www.amazon.com/POSIX-4-Programmers-Guide-Programming-World/dp/1565920740>

Well that ought to be easy, though I'll have to see how well-suited what I have
is for the hanging weight-to-pulley parts.  Most of what I was aiming for was
drawing "closed" curves, not the "open" or loose-end parts of block and tackle.

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 11 hours and 46 minutes ago]

Tue, 10 Dec 2019 01:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...when "developing" a scene, to have
> > an ini with an unnamed section, with the "lo" quality settings for quick render,
> > and a named section with settings for "final" render.
>
> Yes, that of course makes sense.  There are all of the other options one can
> write into the SDL as well (quick_color, etc)

and those.  (have never actually used quick colours)  (inis make using multiple
declare=xyz=off type controls easy, I prefer it over having to '#switch' in the
scene)

> > (laziness, I guess. forget command-line options, just 'pov38 myini')
>
> I'm still transitioning from Win to Linux via QtPOV-Ray (gui).
> Maybe at some point if I have enough uninterrupted free time _with_ peace of
> mind, I'll get some of the proper command line stuff learned with official or hg
> or WP's branch(es)

I don't want to sound .. disparaging, but, ime, that's not how it works, you
just have to have no alternative (initially, at least).  so, exercise: do a
Ctrl-Alt-F2 and you should see a console login prompt.  login, then add an alias
to your .bashrc, something like:
alias nicepov='nice -n 19 povray'

using 'vi[m]' or like.  logout.  to get back to your desktop should be Alt-F7.
set yourself small tasks and switch to a console to carry them out, then the
"feel" for command-lines will just happen.

for instance, self, all 'root'[*] stuff is done on the console, lo-tech.
tedious, yes, but forces the .. presence of mind needed when using "the
powers".

[*] I use 'sudo' only for a few specific tasks (time server syncing and such).

> > btw, you did ask for a reminder re tangents/pulleys.  here's another.  ;-)
>
> Why yes - and I didn't forget - just busy with - December.
> I'm just gonna throw the extant file over in the other thread and you can see
> what you can make of it.   Ping me with questions comments improvements, etc.

thank you v much.  it'll be a few days before I can get to playing with it.

> And make something.  :)

when (_if_) I get to the point where I can understand and make your code "my
own", I plan to replicate the pulleys depicted on the cover of this book:
<www.amazon.com/POSIX-4-Programmers-Guide-Programming-World/dp/1565920740>

regards, jr.

[Bald Eagle] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 13 hours and 36 minutes ago]

Mon, 9 Dec 2019 23:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> ...when "developing" a scene, to have
> an ini with an unnamed section, with the "lo" quality settings for quick render,
> and a named section with settings for "final" render.

Yes, that of course makes sense.  There are all of the other options one can
write into the SDL as well (quick_color, etc)

> (laziness, I guess. forget command-line options, just 'pov38 myini')

I'm still transitioning from Win to Linux via QtPOV-Ray (gui).
Maybe at some point if I have enough uninterrupted free time _with_ peace of
mind, I'll get some of the proper command line stuff learned with official or hg
or WP's branch(es)

> btw, you did ask for a reminder re tangents/pulleys.  here's another.  ;-)

Why yes - and I didn't forget - just busy with - December.

I'm just gonna throw the extant file over in the other thread and you can see
what you can make of it.   Ping me with questions comments improvements, etc.
And make something.  :)

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 15 hours and 6 minutes ago]

Mon, 9 Dec 2019 22:05:02 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > if you use sections in the ini, you'll have to use quotes:
> >   $ povray 'myini[hires]'
>
> ...
>
> Well... huh.

:-)

> Learned something new.   I don't really use ini files except for animations so,
> ....

without ini files we'd have to (ab)use 'Makefile's.  :-)  I use them mostly for
animations too, but (now) find it convenient, when "developing" a scene, to have
an ini with an unnamed section, with the "lo" quality settings for quick render,
and a named section with settings for "final" render.  (laziness, I guess.
forget command-line options, just 'pov38 myini')

btw, you did ask for a reminder re tangents/pulleys.  here's another.  ;-)

regards, jr.

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 15 hours and 6 minutes ago]

Mon, 9 Dec 2019 22:05:02 GMT

hi,

"greytery" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ....
>
> Thanks for quick reply.  Made me go back and check.  No it doesn't!!! - Oh. Yes
> it does???
>
> I have two scene files (part of the Anton Raves LEGO library). One works as
> expected, just as you say - perfectly, beautifully - while another just does not
> like the call without the +I switch, and even then ignores the .ini file.

sorry, am getting .. lost in translation.  :-)  is this the same library as
available on the link below?  if yes, which file(s)?

> At the moment I'm baffled - perhaps a version incompatibility. But cant do more
> this week. Will update when I've got further.  Meanwhile..:
> a) ignore this.
> b) go play with the LEGO models at ...
> and be a kid this Christmas.

nice site, thanks.  I looked at the lego library posted here, recently, but
found that to be in .. a not-useful state.  the one from the Dutch site is much
better, even has documentation!

regards, jr.

[Bald Eagle] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 18 hours and 6 minutes ago]

Mon, 9 Dec 2019 19:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> if you use sections in the ini, you'll have to use quotes:
>
>   $ povray 'myini[hires]'

http://wiki.povray.org/content/Documentation:Unix_Section_5#INI_File_Sections

Well... huh.
Learned something new.   I don't really use ini files except for animations so,
....

:D

[greytery] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 18 hours and 46 minutes ago]

Mon, 9 Dec 2019 18:25:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
> ....
> > ini file works, don't use the switch (only used with scene files, aiui).  eg:
> >   $ povray myini
> ...
> regards, jr.

Thanks for quick reply.  Made me go back and check.  No it doesn't!!! - Oh. Yes
it does???

I have two scene files (part of the Anton Raves LEGO library). One works as
expected, just as you say - perfectly, beautifully - while another just does not
like the call without the +I switch, and even then ignores the .ini file.

At the moment I'm baffled - perhaps a version incompatibility. But cant do more
this week. Will update when I've got further.  Meanwhile..:

a) ignore this.

b) go play with the LEGO models at https://www.virtualbricks.nl/downloads.php
and be a kid this Christmas.

tery

[jr] Re: Version 3.8: Input_File_Name - where has it ... [2316 days 23 hours and 41 minutes ago]

Mon, 9 Dec 2019 13:30:01 GMT

hi,

"greytery" <nomail@nomail> wrote:
> Downloaded and compiled the Linux version of v3.8 master.
>
> The Command Line parameter Input_File_Name (+Ifile) is no longer working as per
> V3.7, and has been removed from the 3.8 documentation. Was "3.2.5.2 Include File
> Name" in V3.7. (Yet it is still mentioned elsewhere).
> If I specify +Iscene.ini it is treated as if it is a .pov file and fails to
> parse.
>
> Why has it been removed?
>
> How do you do animations from the Command Line (i.e. Linux) if you can't control
> frames, clock, etc via the .ini file?

ini file works, don't use the switch (only used with scene files, aiui).  eg:

  $ povray myini

if you use sections in the ini, you'll have to use quotes:

  $ povray 'myini[hires]'


regards, jr.

[greytery] Version 3.8: Input_File_Name - where has it gone? [2316 days 23 hours and 51 minutes ago]

Mon, 9 Dec 2019 13:20:00 GMT

Downloaded and compiled the Linux version of v3.8 master.

The Command Line parameter Input_File_Name (+Ifile) is no longer working as per
V3.7, and has been removed from the 3.8 documentation. Was "3.2.5.2 Include File
Name" in V3.7. (Yet it is still mentioned elsewhere).
If I specify +Iscene.ini it is treated as if it is a .pov file and fails to
parse.

Why has it been removed?

How do you do animations from the Command Line (i.e. Linux) if you can't control
frames, clock, etc via the .ini file?

[omniverse] Re: wiki vs. html [2594 days 8 hours and 1 minute ago]

Thu, 7 Mar 2019 05:10:00 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> On 2/28/2019 4:47 PM, clipka wrote:
> > Am 28.02.2019 um 18:17 schrieb Mike Horvath:
> >
> >> The index on Windows is all messed up. I wanted to help fix it, but
> >> never could find the time. Also I don't know what needs to be done.
> >>
> >> The index is the most useful feature IMO.
> >
> > Are you talking about the v3.7.0 help?
> > That's a known issue that has already been fixed.
>
> I don't know. I am running 3.8 alpha right now which does not spawn a
> help window.

Having seen this asked in the message Digests, thought I would try to answer.
A 3.8 compatible help file was put at:

https://github.com/POV-Ray/povray/tree/master/distribution/platform-specific/windows/Help

After downloading and placing into POV 3.7 Help folder, where you use 3.8,
right-click on the file in Explorer and go to Properties.

Under the General tab apply Unblock so it isn't ignored by Windows.

Newsgroup messages discussing it here:

http://news.povray.org/povray.beta-test/thread/%3C5bd744be%241%40news.povray.org%3E/?mtop=425192

Bob

[Mike Horvath] Re: wiki vs. html [2600 days 14 hours and 15 minutes ago]

Thu, 28 Feb 2019 22:56:07 GMT

On 2/28/2019 4:47 PM, clipka wrote:
> Am 28.02.2019 um 18:17 schrieb Mike Horvath:
> 
>> The index on Windows is all messed up. I wanted to help fix it, but 
>> never could find the time. Also I don't know what needs to be done.
>>
>> The index is the most useful feature IMO.
> 
> Are you talking about the v3.7.0 help?
> That's a known issue that has already been fixed.

I don't know. I am running 3.8 alpha right now which does not spawn a 
help window.


Mike

[clipka] Re: wiki vs. html [2600 days 15 hours and 24 minutes ago]

Thu, 28 Feb 2019 21:47:03 GMT

Am 28.02.2019 um 18:17 schrieb Mike Horvath:

> The index on Windows is all messed up. I wanted to help fix it, but 
> never could find the time. Also I don't know what needs to be done.
> 
> The index is the most useful feature IMO.

Are you talking about the v3.7.0 help?
That's a known issue that has already been fixed.

[Mike Horvath] Re: wiki vs. html [2600 days 19 hours and 53 minutes ago]

Thu, 28 Feb 2019 17:17:15 GMT

On 11/28/2018 8:41 AM, clipka wrote:
> Am 28.11.2018 um 12:01 schrieb Jim Holsenback:
>> On 11/27/18 3:27 PM, dick balaska wrote:
>>> So, my question is, how do y'all manage the multiple editions of your
>>> docs?Â  IIRC, the wiki is now the master and you port it to
html?Â  How?
>>
>> a php script pulls the pages from the wiki and converts it to html. 
>> that is used for nix/mac versions. win version requires post 
>> processing into chm
> 
> BTW, the post-processing script is available in the GitHub repo, in 
> `tools/windows/htmlhelp`. Its input is produced by the same PHP script 
> used for the Unix/Mac versions, but with some extra "fluff" pertaining 
> the help index.

The index on Windows is all messed up. I wanted to help fix it, but 
never could find the time. Also I don't know what needs to be done.

The index is the most useful feature IMO.


Mike

[ingo] Re: [3.8] macro optional example [2682 days 20 hours and 20 minutes ago]

Sat, 8 Dec 2018 16:50:42 GMT

in news:5c0ba8c7$1@news.povray.org Jim Holsenback wrote:

> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

Thanks,

ingo

[Jim Holsenback] Re: [3.8] macro optional example [2683 days 1 hour and 51 minutes ago]

Sat, 8 Dec 2018 11:19:35 GMT

On 12/7/18 1:20 PM, ingo wrote:
> The example for the optional option for macros has a bit too many ";" 't
> won't run like that.

done: http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

[ingo] [3.8] macro optional example [2683 days 18 hours and 50 minutes ago]

Fri, 7 Dec 2018 18:20:41 GMT

http://wiki.povray.org/content/Reference:User_Defined_Macros#The_macro_Dir
ective#Optional_Parameters

The example for the optional option for macros has a bit too many ";" 't 
won't run like that.

cleaned up:

#macro Foo(P1, optional P2)
#ifndef(local.P2) #local P2 = 0; #end // provide default for P2
...
#end

#declare X=1;
#declare Y=2;
Foo(X,Y)
#undef Y
Foo(X,Y)
Foo(X,)

ingo

[ingo] Re: 3.8 array mixed [2683 days 18 hours and 56 minutes ago]

Fri, 7 Dec 2018 18:14:26 GMT

in news:5c0a5cad$1@news.povray.org Jim Holsenback wrote:

> On 12/6/18 4:54 AM, ingo wrote:
> 
> clarification please ... i see something already in the Additional
> usage examples are as follows: passage at the bottom of this section.
> 

Jim,

The mixed example gets a bit lost down there, I think. Just above the 
example I partly referenced the new option mixed is introduced so I 
expexted an example right there.

ingo

[Jim Holsenback] Re: 3.8 array mixed [2684 days 1 hour and 28 minutes ago]

Fri, 7 Dec 2018 11:42:37 GMT

On 12/6/18 4:54 AM, ingo wrote:
> Ref: http://wiki.povray.org/content/Reference:Array
> Imo the mixed option needs a little example,
> 
> #declare MyArray = array[10];
> #declare MyArray[5] = pigment{White};     //all other elements must
>                                           //be pigments too.
> #declare MyArray[2] = normal{bumps 0.2};  //generates an error
> #declare Thing = MyArray[4];              //error: uninitialized array
> element
> 
> #declare MyMixedArray = array mixed[10];
> #declare MyMixedArray[5] = pigment{White};
> #declare MyMixedArray[2] = <1,2,3>;
> 
> #declare SphereMix = array mixed[3]{<1,2,3>, 3, pigment{z}};
> sphere{
>      	SphereMix[0], SphereMix[1]
>      	texture{Spheremix[2]}
> }
> 
> ingo
> 

clarification please ... i see something already in the Additional usage 
examples are as follows: passage at the bottom of this section.

[ingo] 3.8 array mixed [2685 days 3 hours and 16 minutes ago]

Thu, 6 Dec 2018 09:54:21 GMT

Ref: http://wiki.povray.org/content/Reference:Array
Imo the mixed option needs a little example,

#declare MyArray = array[10];
#declare MyArray[5] = pigment{White};     //all other elements must 
                                         //be pigments too.
#declare MyArray[2] = normal{bumps 0.2};  //generates an error
#declare Thing = MyArray[4];              //error: uninitialized array 
element

#declare MyMixedArray = array mixed[10];
#declare MyMixedArray[5] = pigment{White};
#declare MyMixedArray[2] = <1,2,3>;

#declare SphereMix = array mixed[3]{<1,2,3>, 3, pigment{z}};
sphere{
    	SphereMix[0], SphereMix[1] 
    	texture{Spheremix[2]}
}

ingo

[clipka] Re: POV-Ray v3.8.0-alpha.9945627 [2685 days 18 hours and 26 minutes ago]

Wed, 5 Dec 2018 18:44:23 GMT

Am 05.12.2018 um 17:23 schrieb jr:

> while on punctuation,  following your reply to ingo on brackets etc (facepalm
> moment :-)) I re-read the declaring arrays section (3.3.1.10.1), and noticed in
> the table titled "Additional usage examples are as follows" the use of
> semicolons after the #undefs.  the documentation (3.3.2.2.4) offers no
> explanation.

The examples are wrong - my bad. As a C++ programmer I tend to add 
semicolons where POV-Ray expects none. If semicolons work at the end of 
`#undef` in some cases, that's only by coincidence.

(http://wiki.povray.org/content/Reference:Array#Declaring_Arrays)

[clipka] Re: wiki vs. html [2692 days 23 hours and 29 minutes ago]

Wed, 28 Nov 2018 13:41:17 GMT

Am 28.11.2018 um 12:01 schrieb Jim Holsenback:
> On 11/27/18 3:27 PM, dick balaska wrote:
>> So, my question is, how do y'all manage the multiple editions of your
>> docs?Â  IIRC, the wiki is now the master and you port it to
html?Â  How?
> 
> a php script pulls the pages from the wiki and converts it to html. that 
> is used for nix/mac versions. win version requires post processing into chm

BTW, the post-processing script is available in the GitHub repo, in 
`tools/windows/htmlhelp`. Its input is produced by the same PHP script 
used for the Unix/Mac versions, but with some extra "fluff" pertaining 
the help index.

[Jim Holsenback] Re: wiki vs. html [2693 days 2 hours and 10 minutes ago]

Wed, 28 Nov 2018 11:01:07 GMT

On 11/27/18 3:27 PM, dick balaska wrote:
> So, my question is, how do y'all manage the multiple editions of your
> docs?  IIRC, the wiki is now the master and you port it to html?  How?

a php script pulls the pages from the wiki and converts it to html. that 
is used for nix/mac versions. win version requires post processing into chm

[Le Forgeron] Re: wiki vs. html [2693 days 15 hours and 24 minutes ago]

Tue, 27 Nov 2018 21:46:18 GMT

Le 27/11/2018 Ã  21:27, dick balaska a Ã©critÂ :
> I noticed the hgpovray has a section on the wiki, and I thought that
> would be neat for qtpovray. I should at least port it to wiki foo
> because, reasons.
> 
> But I like distributing the html with the app.
> 
> So, my question is, how do y'all manage the multiple editions of your
> docs?  IIRC, the wiki is now the master and you port it to html?  How?
> 
> Thanks.
> 

On github, it's MD, which get served as HTML. (but the MD of github &
bitbucket are different, in regard to hierarchy and links, and TOC handling)

hgpovray's doc based on 3.7 was in github & bitbucket. But it is
cumbersome to edit: it's its own repository, and to see it, I have to
commit & push.
Of cource you can have MD editor with preview... but not always working
with github version of MD, or bitbucket version, so once done for a
page, it need to be done again because it does not work on that server.

And hgpovray 3.7 was also documented in a single big page in the wiki
(experiments before hgpovray ever existed), such big page being splitted
now as features are reported in hgpovray 3.8.

For hgpovray based on 3.8:
* I dropped bitbucket
* the doc is in the wiki, in hope someday it might be useful if some
feature get into official
* the github doc is not in the same repository, it's two clones to make,
one for source of app, one for doc, so maybe all that should be in
github doc section is a link to the wiki, but I have not cleaned yet.
(there is no branches for the doc repository, as far as I know, on
github, so documenting multiple branches can be challenging)
* there is more control in the wiki, and it's easier to edit & preview.

[dick balaska] wiki vs. html [2693 days 16 hours and 43 minutes ago]

Tue, 27 Nov 2018 20:27:27 GMT

I noticed the hgpovray has a section on the wiki, and I thought that
would be neat for qtpovray. I should at least port it to wiki foo
because, reasons.

But I like distributing the html with the app.

So, my question is, how do y'all manage the multiple editions of your
docs?  IIRC, the wiki is now the master and you port it to html?  How?

Thanks.

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Jim Holsenback] Re: broken page in the wiki [2721 days 5 hours and 21 minutes ago]

Wed, 31 Oct 2018 07:49:12 GMT

On 10/30/18 10:11 AM, William F Pokorny wrote:
> On 10/30/18 9:24 AM, tth wrote:
>> Hello
>>
>> I'm seeking informations about blender->pov exported, and
>> found that a relevant page was fully broken :
>>
>> http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender
>>
>> tTh.
>>
> 
> Hmm. There had been just a link to:
> 
> https://en.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/POV-Ray
> 
> for that HowTo - which still works for me. Same link can be found on the 
> POV-Ray wikipedia page. Perhaps use that link for now.
> 
> It looks like Maurice made edits July 6th of this year attempting to 
> replicate the en.blender.org page on the POV-Ray wiki which didn't work 
> so well. His initial comment was "Backing up threatened pages." Maurice?

iirc ... maurice emailed me asking if he could set up shop on povwiki, 
because blender wiki was going with another platform. i was delayed in 
my response that i wasn't 1000% sure of the fate our wiki. i also 
offered that we were /several/ updates behind and the last time we /did/ 
update it was problematic... it broke more than several things. i 
/think/ we ended up back pedaling. i also noticed his false start with 
no further progress. i can only conclude he is actively looking for a 
new home.

[William F Pokorny] Re: broken page in the wiki [2721 days 22 hours and 59 minutes ago]

Tue, 30 Oct 2018 14:11:34 GMT

On 10/30/18 9:24 AM, tth wrote:
> Hello
> 
> I'm seeking informations about blender->pov exported, and
> found that a relevant page was fully broken :
> 
> http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender
> 
> tTh.
> 

Hmm. There had been just a link to:

https://en.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/POV-Ray

for that HowTo - which still works for me. Same link can be found on the 
POV-Ray wikipedia page. Perhaps use that link for now.

It looks like Maurice made edits July 6th of this year attempting to 
replicate the en.blender.org page on the POV-Ray wiki which didn't work 
so well. His initial comment was "Backing up threatened pages." Maurice?

Bill P.

[tth] broken page in the wiki [2721 days 23 hours and 47 minutes ago]

Tue, 30 Oct 2018 13:24:08 GMT

Hello

I'm seeking informations about blender->pov exported, and
found that a relevant page was fully broken :

http://wiki.povray.org/content/HowTo:Use_POV-Ray_with_Blender

tTh.

[clipka] Re: Some stuff related to output file formats [2724 days 2 hours and 2 minutes ago]

Sun, 28 Oct 2018 11:08:25 GMT

Am 27.10.2018 um 14:40 schrieb Jim Holsenback:
> On 9/29/18 3:31 PM, clipka wrote:
>> Also:
>>
>> (4)
>>
>> In v3.8, enabling greyscale output will no longer force the bit depth to
>> 16 bits per channel.
>>
>> (5)
>>
>> In v3.8, the `+F` option will allow specifying both the `G` greyscale
>> flag and the bit depth, using the format `+FxGn`.
>>
>> (6)
>>
>> In v3.8, when creating a greyscale image, the preview display _will_
>> show the image in greyscale.
>>
> 
> 1 thru 6 are done:
> http://wiki.povray.org/content/Reference:Global_Settings#HF_Gray_16

Looks good to me, except the greyscale variant of the `+F`/`-F` option: 
The order has to be `G` /before/ bit depth, not the other way round as 
currently documented. Also, since the `g` is to be taken literally, 
rather than being a placeholder for something, I think it should be 
wrapped in <code> instead of <em>. (Personally I'd even lean towards 
also making it uppercase for more clarity, though it might be argued 
that only the actual option "keys" should be rendered in uppercase.)

[clipka] Re: Some stuff related to output file formats [2724 days 2 hours and 19 minutes ago]

Sun, 28 Oct 2018 10:51:12 GMT

Am 27.10.2018 um 18:08 schrieb Jim Holsenback:

> these are done as well:
> http://wiki.povray.org/content/Reference:File_Output_Options#Output_File_Dithering 

Thanks.
Found only a minor typo this time.

[Jim Holsenback] Re: Some stuff related to output file formats [2724 days 21 hours and 3 minutes ago]

Sat, 27 Oct 2018 16:08:10 GMT

On 9/30/18 5:43 PM, clipka wrote:
> More:
> 
> (7) Output File Dithering:
> 
> The following dithering algorithms are supported:
> 
> + Ordered dithering algorithms:
> 
> - `B2`..`B4`: Bayer pattern dithering using 2x2, 3x3 or 4x4 patterns,
> respectively
> - `BN`: {{New}} in version 3.8, blue noise pattern dithering using a
> 64x64 pattern.
> - `BNX`: {{New}} in version 3.8, same as BN, but using the pattern's
> inverse for the R and B channels.
> 
> + Error diffusion dithering algorithms:
> 
> - `AT`: {{New}} in version 3.8, Atkinson error diffusion dithering
> - `BK`: {{New}} in version 3.8, Burkes error diffusion dithering
> - `D1`: Simple 1-dimensional error diffusion dithering
> - `D2`: Sierra Lite error diffusion dithering
> - `FS`: Floyd-Steinberg error diffusion dithering
> - `JN`: {{New}} in version 3.8, Jarvis-Judice-Ninke error diffusion
> dithering
> - `S2`: {{New}} in version 3.8, Two-Row Sierra error diffusion dithering
> - `S3`: {{New}} in version 3.8, Three-Row Sierra error diffusion dithering
> - `ST`: {{New}} in version 3.8, Stucki error diffusion dithering
> 
> [Not for docs: Absence of extra memory requirements info is deliberate;
> the extra memory should be negligible in all but highly pathological
> cases. Also, current info is no longer accurate, as requirements for D2
> and FS have changed.]
> 
> {{New}} in version 3.8, the default is `-THbn`, i.e: dithering is off,
> with `BN` being the default if only `+TH` is specified.
> 
> {{New}} in version 3.8, dithering is fully gamma-aware, i.e the overall
> apparent brightness of the resulting image is faithfully reproduced.
> 
> 
> (8) Preview Window Dithering:
> 
> In v3.8, the preview window always uses blue noise dithering [this was
> Bayer 4x4 in v3.7, but I can't find it documented anywhere except in the
> change logs].

these are done as well:
http://wiki.povray.org/content/Reference:File_Output_Options#Output_File_Dithering

[Jim Holsenback] Re: Some stuff related to output file formats [2725 days and 31 minutes ago]

Sat, 27 Oct 2018 12:40:09 GMT

On 9/29/18 3:31 PM, clipka wrote:
> Also:
> 
> (4)
> 
> In v3.8, enabling greyscale output will no longer force the bit depth to
> 16 bits per channel.
> 
> (5)
> 
> In v3.8, the `+F` option will allow specifying both the `G` greyscale
> flag and the bit depth, using the format `+FxGn`.
> 
> (6)
> 
> In v3.8, when creating a greyscale image, the preview display _will_
> show the image in greyscale.
> 

1 thru 6 are done:
http://wiki.povray.org/content/Reference:Global_Settings#HF_Gray_16

[clipka] Re: Mixed-type arrays [2743 days 20 hours and 53 minutes ago]

Mon, 8 Oct 2018 16:18:05 GMT

Am 06.10.2018 um 11:23 schrieb Jim Holsenback:
> On 10/5/18 1:32 PM, clipka wrote:
>> Am 04.10.2018 um 13:09 schrieb Jim Holsenback:
>>
>>> done: http://wiki.povray.org/content/Reference:Array
>>
>> Thanks.
>>
>> As usual, I keep finding nits to pick.
> 
> lord have mercy on me ... you've just got too much time on your hands.

Indeed, currently I do.

> /somebody/ please give me a amen on this! i'm finding most of what you
> write is just so tedious ... takes me reading it 3 or 4 times before it
> finally sinks in.

Sorry about that; I've never claimed to be a good documentation writer.

> i see more value in proceeding with the release and
> tabling this /overhaul/ until a later date

I presume you're talking about the syntax overhaul there - yes, I'm
perfectly fine with shelving the idea for now. It's mainly just a
thought that I had to follow a couple of steps and then get out of my
system. It needs some ripening anyway.

[Stephen] Re: Mixed-type arrays [2745 days 21 hours and 19 minutes ago]

Sat, 6 Oct 2018 15:51:25 GMT

On 06/10/2018 14:29, Jim Holsenback wrote:
>>
> i was going to say holy crap (ok pun intended) instead ... i'm wondering 
> what/if you'd have posted if i did. 

Isn't that what Manna is, Holy Crap? :)

According to Jack L. Chalker it was what Tinker bell's fairy dust was. 
(Maybe not so holy.)

> style points for what you /did/ post

:D

I do like a good Amen and that one makes a change from Handel's Messiah.

-- 

Regards
     Stephen

[Jim Holsenback] Re: Mixed-type arrays [2745 days 23 hours and 41 minutes ago]

Sat, 6 Oct 2018 13:29:58 GMT

On 10/6/18 6:19 AM, Stephen wrote:
> On 06/10/2018 10:23, Jim Holsenback wrote:
>> On 10/5/18 1:32 PM, clipka wrote:
>>> Am 04.10.2018 um 13:09 schrieb Jim Holsenback:
>>>
>>>> done: http://wiki.povray.org/content/Reference:Array
>>>
>>> Thanks.
>>>
>>> As usual, I keep finding nits to pick.
>>
>> lord have mercy on me ... you've just got too much time on your hands. 
>> /somebody/ please give me a amen on this! 
> 
> 
> https://www.youtube.com/watch?v=GAhbLcSpdlw
> 
> ;)
> 
> 
i was going to say holy crap (ok pun intended) instead ... i'm wondering 
what/if you'd have posted if i did. style points for what you /did/ post

[Stephen] Re: Mixed-type arrays [2746 days 2 hours and 51 minutes ago]

Sat, 6 Oct 2018 10:19:15 GMT

On 06/10/2018 10:23, Jim Holsenback wrote:
> On 10/5/18 1:32 PM, clipka wrote:
>> Am 04.10.2018 um 13:09 schrieb Jim Holsenback:
>>
>>> done: http://wiki.povray.org/content/Reference:Array
>>
>> Thanks.
>>
>> As usual, I keep finding nits to pick.
> 
> lord have mercy on me ... you've just got too much time on your hands. 
> /somebody/ please give me a amen on this! 


https://www.youtube.com/watch?v=GAhbLcSpdlw

;)


-- 

Regards
     Stephen

[Jim Holsenback] Re: Mixed-type arrays [2746 days 3 hours and 47 minutes ago]

Sat, 6 Oct 2018 09:23:29 GMT

On 10/5/18 1:32 PM, clipka wrote:
> Am 04.10.2018 um 13:09 schrieb Jim Holsenback:
> 
>> done: http://wiki.povray.org/content/Reference:Array
> 
> Thanks.
> 
> As usual, I keep finding nits to pick.

lord have mercy on me ... you've just got too much time on your hands. 
/somebody/ please give me a amen on this! i'm finding most of what you 
write is just so tedious ... takes me reading it 3 or 4 times before it 
finally sinks in. i see more value in proceeding with the release and 
tabling this /overhaul/ until a later date

[dick balaska] Re: Mixed-type arrays [2746 days 16 hours and 27 minutes ago]

Fri, 5 Oct 2018 20:44:04 GMT

On 10/05/2018 01:32 PM, clipka wrote:

> 
> Thus, it should be `array[mixed][ INT ][[ INT ]]..` (or, maybe even
> clearer yet, `array [mixed] [ INT ] [[ INT ]]..`).
> 

Definitely need the space after array.  The top one I read as the token
is either 'array' or 'arraymixed' .

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[clipka] Re: Mixed-type arrays [2746 days 19 hours and 28 minutes ago]

Fri, 5 Oct 2018 17:42:17 GMT

Am 05.10.2018 um 19:32 schrieb clipka:

> As usual, I keep finding nits to pick.

I was a bit too quick with my previous post; there's more:

New nit:

- The bullet list "New to version 3.8 points to also consider" still
simply claims that "Array alements no longer have to be all of the same
type"; I'd simply replace that entire bullet item with "Arrays declared
as `mixed` have a larger memory footprint, even if all elements are
actually of the same type." or something along that line.

Old nit:

- A lot of the bullets refer to dynamically-sized arrays; maybe it is
worth "bundling" them together as is done for the dictionary-related
bullet points.

[clipka] Re: Mixed-type arrays [2746 days 19 hours and 38 minutes ago]

Fri, 5 Oct 2018 17:32:38 GMT

Am 04.10.2018 um 13:09 schrieb Jim Holsenback:

> done: http://wiki.povray.org/content/Reference:Array

Thanks.

As usual, I keep finding nits to pick.

New nits:

- The syntax isn't clean with respect to which square brackets (`[`,
`]`) are literal characters and which indicate optional items. Most
notably, `[ mixed ]` (an optional keyword) is currently written in just
the same style as `[ INT ]` (an integer surrounded by brackets).

To the best of my understanding, the convention is that an opening
square bracket followed by a blank or a closing square bracket preceded
by a blank is meant to indicate a literal square bracket, while an
opening (closing) square bracket followed (preceded) by anything else is
meant to indicate an optional item.

Thus, it should be `array[mixed][ INT ][[ INT ]]..` (or, maybe even
clearer yet, `array [mixed] [ INT ] [[ INT ]]..`).

- The sentence "Any attempt to reference an uninitialized element
results in an error." may be misunderstood to apply only when the
`mixed` keyword is used.

Old nits:

- The syntax of `DICTIONARY_ITEM` is broken w/r/t the first variant:
Besides the aforementioned bracket issue (here being just the other way
round), the syntax implies that the string must be a literal, while in
fact it can be an arbitrary string expression. So it should be something
along the lines of `[ STRING ] :` or `[ STRING_EXPRESSION ] :`.

- The syntax of ARRAY_DECLARATION does not yet reflect that the
dimensions may be omitted altogether (creating a 1-dimensional
dynamically-sized array), so it should actually be `array [mixed] [[ INT
]]..`.


While I'm at it, maybe we should overhaul the way we present the syntax
altogether; I've written up a few ideas in
http://wiki.povray.org/content/User:Clipka/Syntax, some of which should
be reasonably easy to write.

(Of course if we go that route, I wouldn't expect you to do the boring
part of the work, just to set up the necessary framework.)

BTW, is there no easy shortcut to writing `<code>` tags? It's being used
a lot in our docs and is tedious to write. In Markdown, one would simply
use backticks (`) around the code, for instance.

[Jim Holsenback] Re: Mixed-type arrays [2748 days 2 hours and 1 minute ago]

Thu, 4 Oct 2018 11:09:51 GMT

On 9/23/18 1:53 PM, clipka wrote:
> Contrary to earlier claims, intentions, the documentation already on the
> Wiki, and my own clouded memory, the restriction that array elements
> have to be of the same type has /not/ been removed.
> 
> While I could fix this, I have decided not to, as same-type arrays are
> clearly the default use case, and it may actually be helpful to get an
> early error message when accidently assigning a value of a mismatching
> type to one element.
> 
> Instead, the behaviour will be changed as follows:
> 
> 
> In an array declaration, the `array` keyword may be followed by the
> `mixed` keyword. This declares the array as a /mixed-type array/,
> allowing it to hold elements of different types.
> 
> Example:
> 
>      #declare Foo = array mixed[3];
>      #declare Foo[0] = 42;
>      #declare Foo[1] = "Fnord";
>      #declare Foo[2] = sphere { <0,0,0>, 1 }
> 

done: http://wiki.povray.org/content/Reference:Array

[clipka] Re: Default values in v3.8.0 [2750 days 11 hours and 27 minutes ago]

Tue, 2 Oct 2018 01:44:07 GMT

Am 02.10.2018 um 00:41 schrieb Jim Holsenback:
> On 9/30/18 8:45 PM, clipka wrote:
>> "The default pigment has been {{Change}}d in version 3.8 from `rgb
>> <0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
>> setting or command-line option; see [Version Directive] for more
>> details)."
> 
> it's been fixed in pigment and a couple of other places...look here for
> all the places i touched:
> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

Looks good.

Just one more thing regardig the "Version Directive" section,
specifically the portion giving example code for the version 3.8
defaults behaviour:

The revised presentation of the example code gives it the air of three
separate examples, but that's not how it was intended; rather, it was
designed as a single example, intended to demonstrate how the `#version`
directive can (or cannot) switch back and forth between defaults.

As a matter of fact, the third portion of the example wouldn't have the
described effect if used stand-alone - even if the `#default` statement
was moved from the end of the 2nd portion to the beginning of the 3rd one.

[Jim Holsenback] Re: Default values in v3.8.0 [2750 days 14 hours and 27 minutes ago]

Mon, 1 Oct 2018 22:43:25 GMT

On 10/1/18 9:24 AM, clipka wrote:

> The text on the Wiki currently reads as quoted above (unless Jim has
> already found time to change it).

yep it's been changed

[Jim Holsenback] Re: Default values in v3.8.0 [2750 days 14 hours and 29 minutes ago]

Mon, 1 Oct 2018 22:41:31 GMT

On 9/30/18 8:45 PM, clipka wrote:
> "The default pigment has been {{Change}}d in version 3.8 from `rgb
> <0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
> setting or command-line option; see [Version Directive] for more details)."

it's been fixed in pigment and a couple of other places...look here for 
all the places i touched:
http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

[clipka] Re: Default values in v3.8.0 [2750 days 23 hours and 47 minutes ago]

Mon, 1 Oct 2018 13:24:03 GMT

Am 01.10.2018 um 11:22 schrieb Stephen:
> On 01/10/2018 01:55, clipka wrote:
>> Am 01.10.2018 um 02:45 schrieb clipka:
>>
>>> The text currently reads "When #version is set as either the VERY first
>>> statement of the scene file or via command-line option and the version
>>> is 3.8 or greater ..."
>>
>> (Just for the records, The wording /can/ be interpreted to be correct:
>> If you don't specify `#version` as the VERY first statement with SOME
>> value, you can't set it to 3.8 later, and thus can't switch to the new
>> defaults. And the new defaults are enabled if the version is 3.8 or
>> greater at SOME particular point. But I guess that's not how most people
>> would understand it.)
>>
> 
> Is there a functional or technical reason that you are implementing
> this? It will make things harder for me using my modeller as I can only
> change the Pov version from the default (3.6) after the default version
> has been declared in the .pov file.

Wait, what?

Ok, let me clarify:

The text on the Wiki currently reads as quoted above (unless Jim has
already found time to change it).

This CAN be interpreted as:

"To get the new defaults, the VERY first statement in the scene file
must be `#version 3.8` [...]"

And as a matter of fact that's how it was(!) implemented in earlier
v3.7.1 / v3.8.0 pre-releases, and why it was worded like that.

However, the implementation has recently been changed; now the statement
in the wiki can only be considered correct (and only technically so) if
interpreted as:

"To get the new defaults, the VERY first statement in the scene file
must be `#version <whatever>` [...], and it needs to be set to 3.8
eventually.`

To make it completely clear, the updated requirements to get the new
defaults are as follows:

(1) Start the scene with ANY odd `#version` statement. (Not a primary
requirement, but you can't switch to `#version 3.8` otherwise.)

(2) Switch to `#version 3.8` before the `pigment`/`finish`/`camera`
statements that are supposed to be based on the new defaults. (You'll
get v3.7 defaults otherwise.)

(3) Make sure you have switched to `#version 3.8` before any `default`
statement. (`#version` will cease to auto-switch defaults after you have
specified defaults manually, for reasons that I guess are self-evident.)

And here's the same from the implementation point of view:

(A) Defaults are initially set up according to the `Version` INI setting
or equivalent command-line option; if absent, v3.7 [or, technically more
exact, v3.62] defaults are used.

(B) Any `#version` statement changes the defaults accordingly [unless
rule (C) has kicked in].

(C) Any `default` statement prevents all subsequent `#version`
statements from changing the defaults.

(D) If rule (C) has kicked in, any `#version` statement that would
otherwise change the defaults will generate a warning instead.

Plus, unrelated:

(X) If a `#version` statement in the main scene file tries to set the
version to 3.8 or higher, and the first statement was not a `#version`
statement, generate an error.

So unless your modeller is throwing you some additional curveball, I
think you should be fine.

[Stephen] Re: Default values in v3.8.0 [2751 days 3 hours and 48 minutes ago]

Mon, 1 Oct 2018 09:22:23 GMT

On 01/10/2018 01:55, clipka wrote:
> Am 01.10.2018 um 02:45 schrieb clipka:
> 
>> The text currently reads "When #version is set as either the VERY first
>> statement of the scene file or via command-line option and the version
>> is 3.8 or greater ..."
> 
> (Just for the records, The wording /can/ be interpreted to be correct:
> If you don't specify `#version` as the VERY first statement with SOME
> value, you can't set it to 3.8 later, and thus can't switch to the new
> defaults. And the new defaults are enabled if the version is 3.8 or
> greater at SOME particular point. But I guess that's not how most people
> would understand it.)
> 

Is there a functional or technical reason that you are implementing 
this? It will make things harder for me using my modeller as I can only 
change the Pov version from the default (3.6) after the default version 
has been declared in the .pov file.

-- 

Regards
     Stephen

[clipka] Re: Default values in v3.8.0 [2751 days 12 hours and 16 minutes ago]

Mon, 1 Oct 2018 00:55:00 GMT

Am 01.10.2018 um 02:45 schrieb clipka:

> The text currently reads "When #version is set as either the VERY first
> statement of the scene file or via command-line option and the version
> is 3.8 or greater ..."

(Just for the records, The wording /can/ be interpreted to be correct:
If you don't specify `#version` as the VERY first statement with SOME
value, you can't set it to 3.8 later, and thus can't switch to the new
defaults. And the new defaults are enabled if the version is 3.8 or
greater at SOME particular point. But I guess that's not how most people
would understand it.)

[clipka] Re: Default values in v3.8.0 [2751 days 12 hours and 25 minutes ago]

Mon, 1 Oct 2018 00:45:48 GMT

Am 01.10.2018 um 02:11 schrieb Jim Holsenback:
> On 9/30/18 7:47 PM, clipka wrote:
>> Am 01.10.2018 um 00:06 schrieb Jim Holsenback:
>>
>>> for default pigment just a brief /change/ annotation:
>>> http://wiki.povray.org/content/Reference:Pigment
>>
>> Just to make sure we're on the same page here: The behaviour you
>> presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
>> eventually behave.
> 
> ....as long as no explicit #default directive statement is specified????

Sorry, I guess it wasn't clear what exactly I was referring to; this is
about the `#version` interaction.

The text currently reads "When #version is set as either the VERY first
statement of the scene file or via command-line option and the version
is 3.8 or greater ..."

As correctly explained on the `#verison` page, thanks to the recent
overhaul it will no longer be necessary to have a `#version 3.8` as the
VERY first statement to get the changed default; unfortunately the
overhauled behaviour is more complex, and maybe the easiest and least
disruptive way to solve this is just to phrase it something like this:

"The default pigment has been {{Change}}d in version 3.8 from `rgb
<0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
setting or command-line option; see [Version Directive] for more details)."

[Jim Holsenback] Re: Default values in v3.8.0 [2751 days 12 hours and 59 minutes ago]

Mon, 1 Oct 2018 00:12:00 GMT

On 9/30/18 7:47 PM, clipka wrote:
> Am 01.10.2018 um 00:06 schrieb Jim Holsenback:
> 
>> for default pigment just a brief /change/ annotation:
>> http://wiki.povray.org/content/Reference:Pigment
> 
> Just to make sure we're on the same page here: The behaviour you
> presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
> eventually behave.

...as long as no explicit #default directive statement is specified????
> 
> 
>> i created a talk page for the rest:
>> http://wiki.povray.org/content/Reference_Talk:Version_Directive
> ...
>> in the 1st paragraph after the syntax at the sentence... As with version
>> 3.8 or later... things kind of fell apart for me. what you had written
>> just didn't make any sense so that was the best i could do. please
>> review and edit on the talk page.
> 
> See there. I hope the complete rephrasing clarifies things.
> 
yep... i going to merge that over to reference

[clipka] Re: Some stuff related to output file formats [2751 days 13 hours and 4 minutes ago]

Mon, 1 Oct 2018 00:07:10 GMT

Am 01.10.2018 um 00:09 schrieb Jim Holsenback:

>> I intend to write up a short(-ish) dithering tutorial based on the (new,
>> to be pushed soon) `distribution\scenes\output\dither_showcase.pov`
>> sample scene, but anyone willing to pick up that glove would be welcome.
>>
> lol...quit piling it on. i'm starting a 14 day run today at work and my
> time will be spotty

If it's any consolation, I've been feeling guilty about it ever since (4) ;)

The good news is, this concludes the streak of output file format
related changes (for now at any rate). Next up are probably a couple of
changes under the hood again.

[clipka] Re: Default values in v3.8.0 [2751 days 13 hours and 24 minutes ago]

Sun, 30 Sep 2018 23:47:06 GMT

Am 01.10.2018 um 00:06 schrieb Jim Holsenback:

> for default pigment just a brief /change/ annotation:
> http://wiki.povray.org/content/Reference:Pigment

Just to make sure we're on the same page here: The behaviour you
presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
eventually behave.


> i created a talk page for the rest:
> http://wiki.povray.org/content/Reference_Talk:Version_Directive
...
> in the 1st paragraph after the syntax at the sentence... As with version
> 3.8 or later... things kind of fell apart for me. what you had written
> just didn't make any sense so that was the best i could do. please
> review and edit on the talk page.

See there. I hope the complete rephrasing clarifies things.

[Jim Holsenback] Re: Some stuff related to output file formats [2751 days 15 hours and 1 minute ago]

Sun, 30 Sep 2018 22:09:17 GMT

On 9/30/18 5:43 PM, clipka wrote:
> More:
> 
> (7) Output File Dithering:
> 
> The following dithering algorithms are supported:
> 
> + Ordered dithering algorithms:
> 
> - `B2`..`B4`: Bayer pattern dithering using 2x2, 3x3 or 4x4 patterns,
> respectively
> - `BN`: {{New}} in version 3.8, blue noise pattern dithering using a
> 64x64 pattern.
> - `BNX`: {{New}} in version 3.8, same as BN, but using the pattern's
> inverse for the R and B channels.
> 
> + Error diffusion dithering algorithms:
> 
> - `AT`: {{New}} in version 3.8, Atkinson error diffusion dithering
> - `BK`: {{New}} in version 3.8, Burkes error diffusion dithering
> - `D1`: Simple 1-dimensional error diffusion dithering
> - `D2`: Sierra Lite error diffusion dithering
> - `FS`: Floyd-Steinberg error diffusion dithering
> - `JN`: {{New}} in version 3.8, Jarvis-Judice-Ninke error diffusion
> dithering
> - `S2`: {{New}} in version 3.8, Two-Row Sierra error diffusion dithering
> - `S3`: {{New}} in version 3.8, Three-Row Sierra error diffusion dithering
> - `ST`: {{New}} in version 3.8, Stucki error diffusion dithering
> 
> [Not for docs: Absence of extra memory requirements info is deliberate;
> the extra memory should be negligible in all but highly pathological
> cases. Also, current info is no longer accurate, as requirements for D2
> and FS have changed.]
> 
> {{New}} in version 3.8, the default is `-THbn`, i.e: dithering is off,
> with `BN` being the default if only `+TH` is specified.
> 
> {{New}} in version 3.8, dithering is fully gamma-aware, i.e the overall
> apparent brightness of the resulting image is faithfully reproduced.
> 
> 
> (8) Preview Window Dithering:
> 
> In v3.8, the preview window always uses blue noise dithering [this was
> Bayer 4x4 in v3.7, but I can't find it documented anywhere except in the
> change logs].
> 
> 
> 
> I intend to write up a short(-ish) dithering tutorial based on the (new,
> to be pushed soon) `distribution\scenes\output\dither_showcase.pov`
> sample scene, but anyone willing to pick up that glove would be welcome.
> 
lol...quit piling it on. i'm starting a 14 day run today at work and my 
time will be spotty

[Jim Holsenback] Re: Default values in v3.8.0 [2751 days 15 hours and 4 minutes ago]

Sun, 30 Sep 2018 22:06:55 GMT

On 9/22/18 8:14 PM, clipka wrote:
> Am 23.09.2018 um 00:40 schrieb Jim Holsenback:
>> On 9/19/18 4:46 PM, clipka wrote:
>>> In POV-Ray v3.8.0, default values will be chaned as follows:
>>
>> haven't started on this yet...a quick glance was all i did for now but i
>> /think/ i've already done some of them. i'm burnt so give me a bit
> 
> The new `ambient` and camera defaults are indeed already doc'd, so it's
> a matter of finding a good place to document the new pigment colour (the
> old default of pitch black doesn't seem to be explicitly mentioned) and
> to overhaul the behaviour of the `#version` statement with respect to
> the defaults.
> 
> Nothing too urgent I think, so no pressure.
> 

for default pigment just a brief /change/ annotation:
http://wiki.povray.org/content/Reference:Pigment

i created a talk page for the rest:
http://wiki.povray.org/content/Reference_Talk:Version_Directive

i cleaned up the intro paragraph. after the syntax diagram i grouped the 
expanded discussions together. followed by examples.

in the 1st paragraph after the syntax at the sentence... As with version 
3.8 or later... things kind of fell apart for me. what you had written 
just didn't make any sense so that was the best i could do. please 
review and edit on the talk page.

[clipka] Re: Some stuff related to output file formats [2751 days 15 hours and 28 minutes ago]

Sun, 30 Sep 2018 21:43:05 GMT

More:

(7) Output File Dithering:

The following dithering algorithms are supported:

+ Ordered dithering algorithms:

- `B2`..`B4`: Bayer pattern dithering using 2x2, 3x3 or 4x4 patterns,
respectively
- `BN`: {{New}} in version 3.8, blue noise pattern dithering using a
64x64 pattern.
- `BNX`: {{New}} in version 3.8, same as BN, but using the pattern's
inverse for the R and B channels.

+ Error diffusion dithering algorithms:

- `AT`: {{New}} in version 3.8, Atkinson error diffusion dithering
- `BK`: {{New}} in version 3.8, Burkes error diffusion dithering
- `D1`: Simple 1-dimensional error diffusion dithering
- `D2`: Sierra Lite error diffusion dithering
- `FS`: Floyd-Steinberg error diffusion dithering
- `JN`: {{New}} in version 3.8, Jarvis-Judice-Ninke error diffusion
dithering
- `S2`: {{New}} in version 3.8, Two-Row Sierra error diffusion dithering
- `S3`: {{New}} in version 3.8, Three-Row Sierra error diffusion dithering
- `ST`: {{New}} in version 3.8, Stucki error diffusion dithering

[Not for docs: Absence of extra memory requirements info is deliberate;
the extra memory should be negligible in all but highly pathological
cases. Also, current info is no longer accurate, as requirements for D2
and FS have changed.]

{{New}} in version 3.8, the default is `-THbn`, i.e: dithering is off,
with `BN` being the default if only `+TH` is specified.

{{New}} in version 3.8, dithering is fully gamma-aware, i.e the overall
apparent brightness of the resulting image is faithfully reproduced.


(8) Preview Window Dithering:

In v3.8, the preview window always uses blue noise dithering [this was
Bayer 4x4 in v3.7, but I can't find it documented anywhere except in the
change logs].



I intend to write up a short(-ish) dithering tutorial based on the (new,
to be pushed soon) `distribution\scenes\output\dither_showcase.pov`
sample scene, but anyone willing to pick up that glove would be welcome.

[clipka] Re: Some stuff related to output file formats [2752 days 17 hours and 39 minutes ago]

Sat, 29 Sep 2018 19:31:51 GMT

Also:

(4)

In v3.8, enabling greyscale output will no longer force the bit depth to
16 bits per channel.

(5)

In v3.8, the `+F` option will allow specifying both the `G` greyscale
flag and the bit depth, using the format `+FxGn`.

(6)

In v3.8, when creating a greyscale image, the preview display _will_
show the image in greyscale.

[clipka] Some stuff related to output file formats [2752 days 20 hours and 26 minutes ago]

Sat, 29 Sep 2018 16:44:50 GMT

(1) Greyscale:

The `Greyscale=BOOL` INI setting and the optional `G` in the `+F`
command-line switch are currently documented (only) in the SDL reference
section for the obsolete `hf_gray_16` global scene setting.

I would suggest moving the documentation of these new-in-v3.7 features
to the file output options reference section, and essentially trim down
the `hf_gray_16` documentation to a reference thence.


(2) Changes to the PGM ("greyscale PPM") format:

Previously, the "greyscale PPM" (technically PGM) output file format
always used linear output. In v3.8, this will be changed to match that
of the regular (non-greyscale) PPM format (i.e. `File_Gamma` will be
honored if specified, otherwise the ITU-R BT.709 gamma transfer function
will be applied).


(3) Changes to the bit depth:

Previously, the bit depth (as specified by either the `n` in `+Fxn` or
by the `Bits_Per_Color` setting) was limited to the range 5..16; in
v3.8, this will be changed to allow values as low as 1.

[clipka] Re: Mixed-type arrays [2758 days 16 hours and 58 minutes ago]

Sun, 23 Sep 2018 20:12:36 GMT

Am 23.09.2018 um 20:56 schrieb Kenneth:
> Great feature.
> 
> With which version number (or alpha/beta) did 'mixed' become usable? I must have
> missed the earlier announcement(s).

Mixed-type arrays were /supposed/ to work ever since v3.7.1-beta.1
(without requiring the `mixed` keyword), but strangely enough nobody
seems to have actually tried it out.

It /does/ work (requiring `mixed`) since v3.8.0-alpha.9850723. (Which,
as you may notice, hasn't even been announced yet at the time I'm
writing this.)

[Kenneth] Re: Mixed-type arrays [2758 days 18 hours and 11 minutes ago]

Sun, 23 Sep 2018 19:00:01 GMT

Great feature.

With which version number (or alpha/beta) did 'mixed' become usable? I must have
missed the earlier announcement(s).

[clipka] Mixed-type arrays [2758 days 19 hours and 17 minutes ago]

Sun, 23 Sep 2018 17:53:56 GMT

Contrary to earlier claims, intentions, the documentation already on the
Wiki, and my own clouded memory, the restriction that array elements
have to be of the same type has /not/ been removed.

While I could fix this, I have decided not to, as same-type arrays are
clearly the default use case, and it may actually be helpful to get an
early error message when accidently assigning a value of a mismatching
type to one element.

Instead, the behaviour will be changed as follows:


In an array declaration, the `array` keyword may be followed by the
`mixed` keyword. This declares the array as a /mixed-type array/,
allowing it to hold elements of different types.

Example:

    #declare Foo = array mixed[3];
    #declare Foo[0] = 42;
    #declare Foo[1] = "Fnord";
    #declare Foo[2] = sphere { <0,0,0>, 1 }

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days and 7 minutes ago]

Sun, 23 Sep 2018 13:03:21 GMT

On 9/23/18 8:53 AM, clipka wrote:
> Am 23.09.2018 um 14:43 schrieb Jim Holsenback:
>> On 9/23/18 8:37 AM, clipka wrote:
>>> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>>>
>>>>>>> Also, I guess it might be useful to add another visual cue between
>>>>>>> the
>>>>>>> type 3 description and the subsequent description of common features.
>>>>>>
>>>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>>>
>>>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>>>> totally happy with it ;)
>>>>
>>>> go for it...i haven't given up either
>>>
>>> Done. Feel free to throw it overboard again if inspiration strikes you.
>>>
>>
>> well i could have done that but i does look better...like i said i was
>> being lazy and trying to avoid touching the two upstream section map
>> files that wikidocgen uses to do the section renumbering. adding
>> sub-sections is not a free move
> 
> Sorry about that.
> Any way to help you with that? Or add some automation to it?
> 
no worries...found my script. i had to fire up an old 32bit box

[clipka] Re: Anti-aliasing mode 3 [2759 days and 18 minutes ago]

Sun, 23 Sep 2018 12:53:04 GMT

Am 23.09.2018 um 14:43 schrieb Jim Holsenback:
> On 9/23/18 8:37 AM, clipka wrote:
>> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>>
>>>>>> Also, I guess it might be useful to add another visual cue between
>>>>>> the
>>>>>> type 3 description and the subsequent description of common features.
>>>>>
>>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>>
>>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>>> totally happy with it ;)
>>>
>>> go for it...i haven't given up either
>>
>> Done. Feel free to throw it overboard again if inspiration strikes you.
>>
> 
> well i could have done that but i does look better...like i said i was
> being lazy and trying to avoid touching the two upstream section map
> files that wikidocgen uses to do the section renumbering. adding
> sub-sections is not a free move

Sorry about that.
Any way to help you with that? Or add some automation to it?

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days and 27 minutes ago]

Sun, 23 Sep 2018 12:43:16 GMT

On 9/23/18 8:37 AM, clipka wrote:
> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
> 
>>>>> Also, I guess it might be useful to add another visual cue between the
>>>>> type 3 description and the subsequent description of common features.
>>>>
>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>
>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>> totally happy with it ;)
>>
>> go for it...i haven't given up either
> 
> Done. Feel free to throw it overboard again if inspiration strikes you.
> 

well i could have done that but i does look better...like i said i was 
being lazy and trying to avoid touching the two upstream section map 
files that wikidocgen uses to do the section renumbering. adding 
sub-sections is not a free move

[clipka] Re: Anti-aliasing mode 3 [2759 days and 33 minutes ago]

Sun, 23 Sep 2018 12:37:38 GMT

Am 23.09.2018 um 14:18 schrieb Jim Holsenback:

>>>> Also, I guess it might be useful to add another visual cue between the
>>>> type 3 description and the subsequent description of common features.
>>>
>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>
>> Mind if I mess with it? Then you can blame it on me if you're still not
>> totally happy with it ;)
> 
> go for it...i haven't given up either

Done. Feel free to throw it overboard again if inspiration strikes you.

[clipka] Re: Anti-aliasing mode 3 [2759 days and 45 minutes ago]

Sun, 23 Sep 2018 12:25:15 GMT

Am 23.09.2018 um 13:49 schrieb Jim Holsenback:
> On 9/23/18 7:36 AM, Jim Holsenback wrote:
>>> ----------------------------------------------------------
>>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>>> the sampling process. This is called jittering and works because the
>>> human visual system is much more forgiving to noise than it is to
>>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>>> one of the other methods, the location of the super-samples is also
>>> jittered or wiggled a tiny amount jittering by default, but may be
>>> turned off with the Jitter=off option or -J option, or the amount of
>>> jittering can be set with the Jitter_Amount=n.n option. When using
>>> switches the jitter scale may be specified after the +Jn.n option. For
>>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>>> the maximum jitter which will insure that all super-samples remain
>>> inside the original pixel.
>>> -----------------------------------------------------------
> 
> one more thing i just thought of...so is -j is useless if using +am3.
> does it throw a warning if the user specifies? i couldn't check because
> i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on
> pavement plane) beauty run

`+j/-j` has no effect whatsoever when using `+am3`.

I'm not sure whether throwing a warning would be the right thing to do;
it's not general policy to throw warnings for using INI file or
command-line settings that turn out to be without effect due to the
other settings. For example, `+am3` by itself (without `+a`) has no
effect either and also doesn't give you a warning.

This actually makes sense, if you consider that you can set up INI stuff
in the master povray.ini. For example, a user might deliberately specify

    Antialias=off
    Sampling_Method=3
    Antialias_Confidence=0.95
    Antialias_Threshold=0.02
    Jitter=off
    Jitter_Amount=0.2

in their povray.ini to tell POV-Ray that they normally want no
anti-aliasing, but if they do they prefer method 3 with a confidence of
95% and a threshold of 2%, and if they choose a different method they
want no jitter, and if they explicitly turn on jitter they want just a
little of it.

Such a user wouldn't want a warning every time they start a render.

The portions of POV-Ray concerned with the /semantics/ of the ini and
command-line settings cannot tell whether they came from a povray.ini, a
quickres.ini, a scene-specific ini or the command-line, whether they
were specified using ini file style or command-line style, nor even the
order in which they were issued, so they are unable to tell whether the
specific settings were intentional as in the above example, or by
mistake as might be presumed in a `+am3 -j` command-line.

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days and 52 minutes ago]

Sun, 23 Sep 2018 12:18:57 GMT

On 9/23/18 8:00 AM, clipka wrote:
>>> - The section states that "the adaptive non-recursive method is the
>>> default". I would suggest adding "if anti-aliasing is enabled" or
>>> something along those lines, because the "out of the box" default is no
>>> anti-aliasing at all.
>>
>> yep
> 
> Hm... the new version of the sentence seems garbled.

my bad...it's been cleaned up

>>> Also, I guess it might be useful to add another visual cue between the
>>> type 3 description and the subsequent description of common features.
>>
>> wasn't /feeling/ any of the several things i tried so i left it as is
> 
> Mind if I mess with it? Then you can blame it on me if you're still not
> totally happy with it ;)

go for it...i haven't given up either

[clipka] Re: Anti-aliasing mode 3 [2759 days 1 hour and 10 minutes ago]

Sun, 23 Sep 2018 12:00:54 GMT

Am 23.09.2018 um 13:36 schrieb Jim Holsenback:

>> Sampling Methods Synopsis:
>>
>> - Excellent! Love this mini section!
> 
> at least it's better than the run-on sentence that used to be there

I consider it genuinely brilliant.


>> Details, Type 1:
>>
>> - The section states that "the adaptive non-recursive method is the
>> default". I would suggest adding "if anti-aliasing is enabled" or
>> something along those lines, because the "out of the box" default is no
>> anti-aliasing at all.
> 
> yep

Hm... the new version of the sentence seems garbled.


>> - It may or may not be worth also considering an optional alpha channel
>> in the formula given (but see further below).
> 
> if you /really/ think it's worth it help me out a bit...i /did/ do
> something near the end of common as there was already a +ag discussion
> going on... it seemed to fit.

I think that's good enough.


>>> besides the am3 additions i also did some general cleanup and added a
>>> few visual cues to help better separate the method detail descriptions
>>
>> Would it make sense to use sub-headings instead of just bold text?
...
>> Also, I guess it might be useful to add another visual cue between the
>> type 3 description and the subsequent description of common features.
> 
> wasn't /feeling/ any of the several things i tried so i left it as is

Mind if I mess with it? Then you can blame it on me if you're still not
totally happy with it ;)

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days 1 hour and 22 minutes ago]

Sun, 23 Sep 2018 11:49:09 GMT

On 9/23/18 7:36 AM, Jim Holsenback wrote:
>> ----------------------------------------------------------
>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>> the sampling process. This is called jittering and works because the
>> human visual system is much more forgiving to noise than it is to
>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>> one of the other methods, the location of the super-samples is also
>> jittered or wiggled a tiny amount jittering by default, but may be
>> turned off with the Jitter=off option or -J option, or the amount of
>> jittering can be set with the Jitter_Amount=n.n option. When using
>> switches the jitter scale may be specified after the +Jn.n option. For
>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>> the maximum jitter which will insure that all super-samples remain
>> inside the original pixel.
>> -----------------------------------------------------------

one more thing i just thought of...so is -j is useless if using +am3. 
does it throw a warning if the user specifies? i couldn't check because 
i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on 
pavement plane) beauty run

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days 1 hour and 34 minutes ago]

Sun, 23 Sep 2018 11:36:12 GMT

On 9/22/18 7:39 PM, clipka wrote:
> Am 23.09.2018 um 00:26 schrieb Jim Holsenback:
> 
>> please review:
>>
>> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
> 
> My thoughts on it:
> 
> 
> Stochastic Seed:
> 
> - Typo: "Set's a value" should read "Sets a value".

oops

> 
> Sampling Methods Synopsis:
> 
> - Excellent! Love this mini section!

at least it's better than the run-on sentence that used to be there

> 
> Details, Type 1:
> 
> - The section states that "the adaptive non-recursive method is the
> default". I would suggest adding "if anti-aliasing is enabled" or
> something along those lines, because the "out of the box" default is no
> anti-aliasing at all.

yep

> 
> - It may or may not be worth also considering an optional alpha channel
> in the formula given (but see further below).

if you /really/ think it's worth it help me out a bit...i /did/ do 
something near the end of common as there was already a +ag discussion 
going on... it seemed to fit.

> 
> Details, Type 3:
> 
> - The formula for the actual maximum number of rays per pixel is
> literally written as "4^n" (four-caret-n), rather than using proper
> superscript notation. Not sure if this is an oversight or technical
> necessity. In the latter case, maybe Unicode character U+207F would be
> an alternative to genuine superscript.

the hex equivalent was too small... 4<sup>n</sup> looked slightly better.

> 
> - The word "moire" in "moire pattern" lacks an accent.

found the hex version used elsewhere on the page

> 
> Common section:
> 
> - The common section ("With all methods..."), as currently written,
> implies that the `Jitter` setting affects all anti-aliasing modes; that
> is incorrect: Anti-aliasing mode 3 always uses a constant amount of
> jitter. I would suggest to use something like the following wording instead:
> 
> ----------------------------------------------------------
> Another way to reduce anti-aliasing artifacts is to introduce noise into
> the sampling process. This is called jittering and works because the
> human visual system is much more forgiving to noise than it is to
> regular patterns, and is inherent in anti-aliasing mode 3. When using
> one of the other methods, the location of the super-samples is also
> jittered or wiggled a tiny amount jittering by default, but may be
> turned off with the Jitter=off option or -J option, or the amount of
> jittering can be set with the Jitter_Amount=n.n option. When using
> switches the jitter scale may be specified after the +Jn.n option. For
> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
> the maximum jitter which will insure that all super-samples remain
> inside the original pixel.
> -----------------------------------------------------------

i mangled this paragraph on purpose because i was fishing for 
clarification... lol and you bit!

> 
> Additional noteworthy information:
> 
> - It may be worth noting that if the image contains an alpha channel,
> that channel will also be considered in the comparisons, pretty much
> like the colour channels, except that unlike the other channels it is
> not subject to `Antialias_Gamma`.

almost verbatim near the end...

> 
> 
>> besides the am3 additions i also did some general cleanup and added a
>> few visual cues to help better separate the method detail descriptions
> 
> Would it make sense to use sub-headings instead of just bold text?

ugh...i'm being lazy

> 
> Also, I guess it might be useful to add another visual cue between the
> type 3 description and the subsequent description of common features.

wasn't /feeling/ any of the several things i tried so i left it as is

[clipka] Re: Default values in v3.8.0 [2759 days 12 hours and 56 minutes ago]

Sun, 23 Sep 2018 00:14:22 GMT

Am 23.09.2018 um 00:40 schrieb Jim Holsenback:
> On 9/19/18 4:46 PM, clipka wrote:
>> In POV-Ray v3.8.0, default values will be chaned as follows:
> 
> haven't started on this yet...a quick glance was all i did for now but i
> /think/ i've already done some of them. i'm burnt so give me a bit

The new `ambient` and camera defaults are indeed already doc'd, so it's
a matter of finding a good place to document the new pigment colour (the
old default of pitch black doesn't seem to be explicitly mentioned) and
to overhaul the behaviour of the `#version` statement with respect to
the defaults.

Nothing too urgent I think, so no pressure.

[clipka] Re: Anti-aliasing mode 3 [2759 days 13 hours and 31 minutes ago]

Sat, 22 Sep 2018 23:39:36 GMT

Am 23.09.2018 um 00:26 schrieb Jim Holsenback:

> please review:
> 
> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

My thoughts on it:


Stochastic Seed:

- Typo: "Set's a value" should read "Sets a value".

Sampling Methods Synopsis:

- Excellent! Love this mini section!

Details, Type 1:

- The section states that "the adaptive non-recursive method is the
default". I would suggest adding "if anti-aliasing is enabled" or
something along those lines, because the "out of the box" default is no
anti-aliasing at all.

- It may or may not be worth also considering an optional alpha channel
in the formula given (but see further below).

Details, Type 3:

- The formula for the actual maximum number of rays per pixel is
literally written as "4^n" (four-caret-n), rather than using proper
superscript notation. Not sure if this is an oversight or technical
necessity. In the latter case, maybe Unicode character U+207F would be
an alternative to genuine superscript.

- The word "moire" in "moire pattern" lacks an accent.

Common section:

- The common section ("With all methods..."), as currently written,
implies that the `Jitter` setting affects all anti-aliasing modes; that
is incorrect: Anti-aliasing mode 3 always uses a constant amount of
jitter. I would suggest to use something like the following wording instead:

----------------------------------------------------------
Another way to reduce anti-aliasing artifacts is to introduce noise into
the sampling process. This is called jittering and works because the
human visual system is much more forgiving to noise than it is to
regular patterns, and is inherent in anti-aliasing mode 3. When using
one of the other methods, the location of the super-samples is also
jittered or wiggled a tiny amount jittering by default, but may be
turned off with the Jitter=off option or -J option, or the amount of
jittering can be set with the Jitter_Amount=n.n option. When using
switches the jitter scale may be specified after the +Jn.n option. For
example +J0.5 uses half the normal jitter. The default amount of 1.0 is
the maximum jitter which will insure that all super-samples remain
inside the original pixel.
-----------------------------------------------------------

Additional noteworthy information:

- It may be worth noting that if the image contains an alpha channel,
that channel will also be considered in the comparisons, pretty much
like the colour channels, except that unlike the other channels it is
not subject to `Antialias_Gamma`.


> besides the am3 additions i also did some general cleanup and added a
> few visual cues to help better separate the method detail descriptions

Would it make sense to use sub-headings instead of just bold text?

Also, I guess it might be useful to add another visual cue between the
type 3 description and the subsequent description of common features.

[Jim Holsenback] Re: Default values in v3.8.0 [2759 days 14 hours and 30 minutes ago]

Sat, 22 Sep 2018 22:40:49 GMT

On 9/19/18 4:46 PM, clipka wrote:
> In POV-Ray v3.8.0, default values will be chaned as follows:

haven't started on this yet...a quick glance was all i did for now but i 
/think/ i've already done some of them. i'm burnt so give me a bit

[Jim Holsenback] Re: Anti-aliasing mode 3 [2759 days 14 hours and 44 minutes ago]

Sat, 22 Sep 2018 22:26:59 GMT

On 9/19/18 7:30 AM, clipka wrote:
> Am 19.09.2018 um 12:53 schrieb Jim Holsenback:
>> On 9/16/18 8:15 PM, clipka wrote:
>>> As I'm writing this post, I'm about to finalize the integration of
>>> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.
>>
>> ok... i've read and don't have any questions about what you've written.
>> looks like a quick and easy add... only challenge will be finding time.
>> should i bother generating distribution packages?
> 
> Yes, please. This time around I'm sure I'll find the time to actually
> process them and include them in the repository.

please review:

http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
http://wiki.povray.org/content/Reference:Tracing_Options#Stochastic_Seed

besides the am3 additions i also did some general cleanup and added a 
few visual cues to help better separate the method detail descriptions

[clipka] Re: Default values in v3.8.0 [2761 days 1 hour and 35 minutes ago]

Fri, 21 Sep 2018 11:35:41 GMT

Am 21.09.2018 um 13:24 schrieb Kenneth:

>           right  x*image_width/image_height
> 
> Honestly, I thought that was the default(!).

Well, it is now ;)

> But I see that 4/3*x or <1.33,0,0>
> is the real one.

The latter actually. Which means that by default the aspect ratio wasn't
even really fitting for classic 4:3 images.

[Kenneth] Re: Default values in v3.8.0 [2761 days 1 hour and 41 minutes ago]

Fri, 21 Sep 2018 11:30:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

>
> By specifying `right` you are not using any defaults at all. The
> defaults only come into play when you *don't* specify `right`.
>

Oh.  I actually had to look that up in the docs-- it's been ages since I read
those sections. (I rarely if ever think about right, up etc). Just to clarify, I
always use AND specify
          right  x*image_width/image_height

Honestly, I thought that was the default(!). But I see that 4/3*x or <1.33,0,0>
is the real one. I can't recall when I started using one vs. the other-- it
was in the dim and murky past!

Thanks for the clarification.

[clipka] Re: Default values in v3.8.0 [2761 days 10 hours and 1 minute ago]

Fri, 21 Sep 2018 03:09:33 GMT

Am 21.09.2018 um 02:21 schrieb Mike Horvath:
> On 9/20/2018 8:00 PM, Kenneth wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 20.09.2018 um 22:19 schrieb Kenneth:
>>
>>>> I don't usually mess withÂ Â  rightÂ 
x*image_width/image_height...
>>>
>>> Presuming that by "I don't usually mess with..." you mean "I usually
>>> use..." (as opposed to e.g. "I don't even try to use..."), there's no
>>> need to worry.
>>>
>>
>> Yeah, that's the case-- I always specify right... in a camera, but
>> almost always
>> leave it alone (at the default.)
>>
>>
> 
> By specifying `right` you are not using any defaults at all. The
> defaults only come into play when you *don't* specify `right`.

Absolutely right.

(Irresistible.)

[clipka] Re: Default values in v3.8.0 [2761 days 10 hours and 12 minutes ago]

Fri, 21 Sep 2018 02:58:12 GMT

Am 21.09.2018 um 00:43 schrieb dick balaska:
> On 09/20/2018 05:47 PM, clipka wrote:
>> Am 20.09.2018 um 22:19 schrieb Kenneth:
> 
>>
>> Also, white makes for nice images if you're really just interested in shape.
> 
> Isn't like a mid-grey the accepted graphics "standard" for "nothing".

Mid-grey is certainly /one/ standard, but it is not the only one - white
being another (e.g. the default material for geometric primitives in DAZ
studio).

White has the decided advantage over mid-grey in that it is well-defined
in terms of gamma: White is always white.

Also, with `diffuse` defaulting to a value below 1.0, it is effectively
not pearly white.

> The quickres.ini he mentions does not have "Right" as an attribute (just
> Width, Height, and Antialias foo). So 1280x720 *will* look different
> then he has previously seen.  It will be more correct :) but it will be
> different.

It will be more correct for people who don't use the `right
x*image_width/image_height` idiom. Which is pretty much the point of it ;)

[Mike Horvath] Re: Default values in v3.8.0 [2761 days 12 hours and 49 minutes ago]

Fri, 21 Sep 2018 00:21:16 GMT

On 9/20/2018 8:00 PM, Kenneth wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 20.09.2018 um 22:19 schrieb Kenneth:
> 
>>> I don't usually mess with   right  x*image_width/image_height...
>>
>> Presuming that by "I don't usually mess with..." you mean "I usually
>> use..." (as opposed to e.g. "I don't even try to use..."), there's no
>> need to worry.
>>
> 
> Yeah, that's the case-- I always specify right... in a camera, but almost always
> leave it alone (at the default.)
> 
> 

By specifying `right` you are not using any defaults at all. The 
defaults only come into play when you *don't* specify `right`.


Mike

[Kenneth] Re: Default values in v3.8.0 [2761 days 13 hours and 6 minutes ago]

Fri, 21 Sep 2018 00:05:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 20.09.2018 um 22:19 schrieb Kenneth:

> > I don't usually mess with   right  x*image_width/image_height...
>
> Presuming that by "I don't usually mess with..." you mean "I usually
> use..." (as opposed to e.g. "I don't even try to use..."), there's no
> need to worry.
>

Yeah, that's the case-- I always specify right... in a camera, but almost always
leave it alone (at the default.)

[dick balaska] Re: Default values in v3.8.0 [2761 days 14 hours and 24 minutes ago]

Thu, 20 Sep 2018 22:46:15 GMT

On 09/20/2018 06:43 PM, dick balaska wrote:

> 
> The quickres.ini he mentions does not have "Right" as an attribute (just
> Width, Height, and Antialias foo). So 1280x720 *will* look different
> then he has previously seen.  It will be more correct :) but it will be
> different.

That was a dumb statement.  There is no camera in quickres, so there
couldn't be a "right".

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[dick balaska] Re: Default values in v3.8.0 [2761 days 14 hours and 27 minutes ago]

Thu, 20 Sep 2018 22:43:28 GMT

On 09/20/2018 05:47 PM, clipka wrote:
> Am 20.09.2018 um 22:19 schrieb Kenneth:

> 
> Also, white makes for nice images if you're really just interested in shape.

Isn't like a mid-grey the accepted graphics "standard" for "nothing".

> First of all, as long as you explicitly specify a "right" vector,
> nothing changes at all. User-specified "right" wins over default, as
> previously.

The quickres.ini he mentions does not have "Right" as an attribute (just
Width, Height, and Antialias foo). So 1280x720 *will* look different
then he has previously seen.  It will be more correct :) but it will be
different.

> 
> And second, "right x*image_width/image_height" is in fact exactly what
> the new default boils down to.
> 

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[clipka] Re: Default values in v3.8.0 [2761 days 15 hours and 24 minutes ago]

Thu, 20 Sep 2018 21:47:06 GMT

Am 20.09.2018 um 22:19 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>> In POV-Ray v3.8.0, default values will be chaned as follows:
>>
>> - The `ambient` setting now defaults to zero instead of 0.1.
> 
> Great! Nice and consistent with the other newer finish defaults.

Um... what other newer finish defaults?

>> - The default pigment is now plain white (rgb <1,1,1>) instead of black.
> 
> I''m curious about the reason for this change. (Personally, it will take some
> getting used to.) Is it perhaps due in some philosophical way to the change of
> #default ambient to 0.0 (where pure shadows would now be pure black instead of
> 'lit' with ambient 0.1? Meaning, it would be hard to discern a previously
> un-pigmented object-- black until now-- from it's now-black shadow duo to
> ambient 0.0?)

Since ambient is also multiplied with pigment, traditional default was
pitch-black and thus invisible.

The rationale is simply that hey, the default of pitch black is of no
practical use /at all/ - white, on the other hand, eliminates one of the
N things that you have to do to see /anything/ at all. Those used to be:

(1) Place at least one object in your scene.
(2) Place your camera somewhere outside the object.
(3) Aim your camera at the object.
(4) Place a light source somewhere reasonable outside the object.
(5) Give your object a pigment that isn't pitch black.

(Alternatively to (5), you could also (5a) Set up a background or sky
sphere that isn't pitch black, but that isn't nearly as satisfying.)

With white default pigment, we're only left with steps (1)-(4) for a new
user to produce their first remotely satisfying image.

Also, white makes for nice images if you're really just interested in shape.

>> - The camera `right` vector length now defaults to the output image
>> aspect ratio (presuming square pixels; for example, at 1280x1024 the
>> vector will have a length of 1,25) instead of 1.33. The rules governing
>> the direction of the vector remain unaffected.
>>
> 
> I don't usually mess with   right  x*image_width/image_height,  and run
> different aspect-ratio images simply by choosing another entry in quickres.ini.
> (1280X720 instead of 800X600, for example.)  Will this change affect the visual
> result of the render (in some *strange* way), if I continue to use my simple
> scheme? Sorry if my question seems naive, but it's not clear if my quickres.ini
> entries would also need changing.

Presuming that by "I don't usually mess with..." you mean "I usually
use..." (as opposed to e.g. "I don't even try to use..."), there's no
need to worry.

First of all, as long as you explicitly specify a "right" vector,
nothing changes at all. User-specified "right" wins over default, as
previously.

And second, "right x*image_width/image_height" is in fact exactly what
the new default boils down to.

[Kenneth] Re: Default values in v3.8.0 [2761 days 16 hours and 51 minutes ago]

Thu, 20 Sep 2018 20:20:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> In POV-Ray v3.8.0, default values will be chaned as follows:
>
> - The `ambient` setting now defaults to zero instead of 0.1.

Great! Nice and consistent with the other newer finish defaults.

> - The default pigment is now plain white (rgb <1,1,1>) instead of black.

I''m curious about the reason for this change. (Personally, it will take some
getting used to.) Is it perhaps due in some philosophical way to the change of
#default ambient to 0.0 (where pure shadows would now be pure black instead of
'lit' with ambient 0.1? Meaning, it would be hard to discern a previously
un-pigmented object-- black until now-- from it's now-black shadow duo to
ambient 0.0?)
>
> - The camera `right` vector length now defaults to the output image
> aspect ratio (presuming square pixels; for example, at 1280x1024 the
> vector will have a length of 1,25) instead of 1.33. The rules governing
> the direction of the vector remain unaffected.
>

I don't usually mess with   right  x*image_width/image_height,  and run
different aspect-ratio images simply by choosing another entry in quickres.ini.
(1280X720 instead of 800X600, for example.)  Will this change affect the visual
result of the render (in some *strange* way), if I continue to use my simple
scheme? Sorry if my question seems naive, but it's not clear if my quickres.ini
entries would also need changing.

[clipka] Default values in v3.8.0 [2762 days 16 hours and 24 minutes ago]

Wed, 19 Sep 2018 20:46:58 GMT

In POV-Ray v3.8.0, default values will be chaned as follows:


- The default pigment is now plain white (rgb <1,1,1>) instead of black.

- The `ambient` setting now defaults to zero instead of 0.1.

- The camera `right` vector length now defaults to the output image
aspect ratio (presuming square pixels; for example, at 1280x1024 the
vector will have a length of 1,25) instead of 1.33. The rules governing
the direction of the vector remain unaffected.


The new defaults require that the language version is explicitly set to
3.8 or higher via the `#version` directive, the `Version=n.n` INI
setting or the `+MVn.n` command-line option, otherwise POV-Ray will fall
back to legacy defaults for backwards compatibility.

The `#version` directive can be used to switch back and forth between
the defaults, as long as no explicit `default` statement is specified.
However, as soon as the first `default` statement is encountered, any
subsequent `#version` directives that would normally affect the defaults
will instead just cause a warning.


For example, consider the following scene:

    #version 3.7;
    #declare LegacyTexture = texture { ... }
    #version 3.8;
    #declare ModernTexture = texture { ... }
    default { pigment { color rgb <1,0,0> } }
    #version 3.7;
    #declare OtherTexture = texture { ... }

The first `#version` directive switches to v3.7 defaults, so if
`LegacyTexture` does not explicitly specify an ambient value, it will
have an ambient value of 0.1.

The second `#version` directive switches to v3.8 defaults, so if
`ModernTexture` does not explicitly specify an ambient value, it will
have an ambient value of zero.

The thirst `#version` directive just creates a warning, because the
earlier `default` statement has "locked" the v3.8 defaults (overriding
the pigment in the process)., so if `OtherTexture` does not explicitly
specify an ambient value, it will also have an ambient value of zero.


---------------------------------------------------------------------

Notes NOT intended for the docs:

- The current v3.8.0-alpha releases do not yet allow switching back and
forth between defaults after the first `#version` statement; this will
be changed in the next development releases.

- As soon as that behaviour is released, users may experience lots of
warnings regarding `#version` and `default` in standard include files.
This is to be expected for any v3.8 scenes that place a `default`
statement before the standard include files, and will be fixed later
(probably with the first beta) by changes to the standard include files.

[clipka] Re: Anti-aliasing mode 3 [2763 days 1 hour and 40 minutes ago]

Wed, 19 Sep 2018 11:30:34 GMT

Am 19.09.2018 um 12:53 schrieb Jim Holsenback:
> On 9/16/18 8:15 PM, clipka wrote:
>> As I'm writing this post, I'm about to finalize the integration of
>> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.
> 
> ok... i've read and don't have any questions about what you've written.
> looks like a quick and easy add... only challenge will be finding time.
> should i bother generating distribution packages?

Yes, please. This time around I'm sure I'll find the time to actually
process them and include them in the repository.

[Jim Holsenback] Re: Anti-aliasing mode 3 [2763 days 2 hours and 18 minutes ago]

Wed, 19 Sep 2018 10:53:01 GMT

On 9/16/18 8:15 PM, clipka wrote:
> As I'm writing this post, I'm about to finalize the integration of
> UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.

ok... i've read and don't have any questions about what you've written. 
looks like a quick and easy add... only challenge will be finding time. 
should i bother generating distribution packages?

[clipka] Anti-aliasing mode 3 [2765 days 12 hours and 55 minutes ago]

Mon, 17 Sep 2018 00:15:15 GMT

As I'm writing this post, I'm about to finalize the integration of
UberPOV's Anti-aliasing mode 3 into POV-Ray v3.8.0-alpha.


This change affects the following command-line and INI file options:

Anti-aliasing options:

    Sampling_Method=n / +AMn             (now allows value 3)
    Antialias_Confidence=n.n / +ACn.n    (new)

General tracing options:

    Stochastic_Seed=n / +SSn             (new)


Description of Anti-aliasing mode 3:


This third, adaptive, non-recursive stochastic oversampling mode
repeatedly iterates over the pixels to be rendered, jittering each ray
randomly within the pixel on each pass, while keeping track of
statistical parameters such as average colour and mean deviation. On
subsequent passes, the algorithm ceases to oversample pixels where the
statistical parameters for the pixel itself and its immediate four
neighbors indicate that the result is "probably good enough".

What constitutes "probably good enough" is determined by a /confidence/
parameter specified by the `Antialias_Confidence=n.n` or `+ACn.n`
option, as well as a /threshold/ parameter specified by the
`Antialias_Threshold=n.n` or `+An.n` option.

The /threshold/ determines what absolute sampling error (i.e. difference
between the computed pixel colour and the theoretically correct one) you
consider acceptable, while the /confidence/ specifies how sure you want
to be that a pixel that /seems/ acceptable actually /is/ acceptable. In
effect, this determines how many pixels in the resulting image /will/
indeed be acceptable.

For example, if you specify a confidence of 0.95, then you can expect
approximately 95% of all pixels to be within the threshold (as compared
to a theoretically correct image). Of the remaining ones, many will be
off by slightly more than the threshold, while only few will be
significantly off, and extreme outlies are possible but extremely unlikely.

Recommended values are a threshold of 0.3 or lower, and a confidence of
0.9 or higher, which are the defults.

The total number of rays shot per pixel is limited by the
`Antialias_Depth=n` or `+Rn` parameter. As with the other modes the
parameter is limited to the range from 1 to 9, with the actual maximum
number of rays per pixel being 4^n.

By default, the sub-pixel jittering is different for each render, thus
giving slightly different results, with the intent that multiple renders
can be averaged to get a higher-quality image. To produce exactly the
same output each time, use the `Stochastic_Seed=n` or `+SSn` option.
(Note however that the jitter sequence is also affected by the actual
image content, and will thus always differ between the frames of an
animation.)

As oversampling mode 3 is a very generic adaptive oversampling
algorithm, its performance in pure edge anti-aliasing is generally
inferior to the other modes; however, it is ideally suited to suppress
random image noise created by other stochastic mechanisms, such as
jittered area lights, subsurface light transport, or micronormals-based
blurred reflections. It has also proven well-suited to eliminating moire
patterns.


Description of Stochastic_Seed / +SS:


By default, some stochastic mechanisms in POV-Ray intentionally give
different results for each render, with the intent that multiple renders
can be averaged to get a higher-quality image. To this end, the
corresponding pseudo-random number generators are seeded with a value
derived from the current date and time.

If the `Stochastic_Seed=n` or `+SSn` option is specified, the seed will
instead be derived from the specified value, allowing to produce exactly
the same output each time by specifying the same value.

Alternatively, the mechanism may be co-opted to prevent separate renders
started at the same time from producing identical results, by explicitly
specifying different values.

Note that even if the seed is set identical, other factors may cause
differences in the result, for example the render block size (+BSn) or
the render pattern (+RPn). Results may also differ between versions of
POV-Ray.

At present, the following features are sensitive to the stochastic seed
setting:

  - Anti-aliasing mode 3


----------------------------------------------------------------------


Differences to UberPOV (not intended for the docs):


* Threshold parameter:

UberPOV's anti-aliasing mode 3 required a threshold setting of 0.1 or
lower for good results, far lower than the default of 0.3 the other
modes are perfectly happy with. This is because UberPOV's mode 3
compared the differences of each colour channel to the threshold
individually, whereas the other modes compare the sum of all channels'
differences to the threshold instrad.

I have changed this in POV-Ray, so that mode 3 will also compare the sum
rather than the per-channel differences.


* Stochastic Seed:

UberPOV used a different seed for each thread (differing by 1), and did
not re-seed the random number generator between render blocks; as a
result, multi-threaded renders couldn't be reliably reproduced even when
explicitly setting the seed.

POV-Ray is re-seeding the random number generator for each render block,
using the specified seed + the running ID of the render block as the
actual seed. This allows to reproduce renders, provided that the same
render block size and render pattern are used.


----------------------------------------------------------------------


Additional related side notes (not intended for the docs):

The observant reader will note that the anti-aliasing mode 3's maximum
number of samples per pixel is close, but not identical, to the value
for mode 2 as specified in the docs in the table of `Antialias_Depth=n`
/ `+Rn` values.

It may be worth mentioning that the table for mode 2 is inaccurate in
that it doesn't take into account that samples at a pixel's corner or
edge are re-used for adjacent pixels where applicable. Only at the
render block border are edge or corner samples really used for one pixel
only.

So even the worst-case maximum per pixel in mode 2 is actually far
closer to 4^n than the (2^n+1)^2 given in the table.

[Mike Horvath] Re: New tutorial about 2D screen coordinates [2782 days 10 hours and 32 minutes ago]

Fri, 31 Aug 2018 02:38:43 GMT

On 8/30/2018 10:36 PM, Mike Horvath wrote:
> I just created a new tutorial about how to calculate very precise values 
> for the 2D screen coordinates of objects in a POV-Ray render.
> 
> http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene 
> 
> 
> LMKWYT
> 
> 
> Mike


Oops. Wrong group.


Mike

[Mike Horvath] New tutorial about 2D screen coordinates [2782 days 10 hours and 34 minutes ago]

Fri, 31 Aug 2018 02:36:20 GMT

I just created a new tutorial about how to calculate very precise values 
for the 2D screen coordinates of objects in a POV-Ray render.

http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene

LMKWYT


Mike

[Mike Horvath] Re: Wiki link captcha confirm mechanism broken. [2782 days 11 hours and 7 minutes ago]

Fri, 31 Aug 2018 02:03:35 GMT

On 6/11/2018 9:21 AM, William F Pokorny wrote:
> FYI.
> 
> In some edits today unable to include links back into newsgroups due the 
> captcha mechanism we use no longer being supported by Google.
> 
> Bill P.

I just noticed this as well. The captcha widget is no longer working, 
and I can't add any links to external resources.

Mike

[clipka] Re: revisiting rand(...) [2824 days 21 hours and 12 minutes ago]

Thu, 19 Jul 2018 15:58:56 GMT

Am 19.07.2018 um 03:38 schrieb Alain:

>> I did find the topic of rounding to be more complex than my initial naive
>> concept.Â  There are different ways to do it, and it would be useful and
>> instructive to see examples of code that performed all the different
>> variations.
> 
> Mostly, there are 3 ways : Round down, or truncate, round to the closest
> and round up.

Actually there are a few more commonly used:

- Round towards negative infinity (round down)
- Round towards positive infinity (round up)
- Round towards zero (truncate)
- Round towards infinity of same sign
- Round to nearest ("proper" rounding)

In the latter mode, there is again a host of ways to handle values smack
in the middle between the nearest representable numbers (think 0.5):

- Round towards negative infinity (round down)
- Round towards positive infinity (round up)
- Round towards zero (truncate)
- Round towards infinity of same sign
- Round up if even, down if odd
- Round down if even, up if odd

[Alain] Re: revisiting rand(...) [2825 days 11 hours and 31 minutes ago]

Thu, 19 Jul 2018 01:39:52 GMT

Le 18-07-18 Ã  18:55, Kenneth a Ã©critÂ :
> Alain <kua### [at] videotronca> wrote:
> 
>>
>> If you get scale 0, a warning is generated and the scalling will default
>> to scale 1.
>>
>> So, no error, just a warning.
>>
> 
> That's true; I probably used a poor code example to demonstrate what might occur
> IF rand(...) actually hit 0.0
> 
> 

#declare Something = Value/rand(R);

Crash with divide by zero if rand(R) return zero.

[Alain] Re: revisiting rand(...) [2825 days 11 hours and 33 minutes ago]

Thu, 19 Jul 2018 01:38:00 GMT

Le 18-07-18 Ã  20:02, Bald Eagle a Ã©critÂ :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> Alain <kua### [at] videotronca> wrote:
>>>
>>>> All values are equally possible, including 0 and 1. The mantissa for a
>>>> float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
>>>> a 0 and the same of getting a 1. Very small but not zero chance.
>>>
>>> So then maybe round to the nearest Q decimal place to "compress" the range and
>>> increase the likelihood of getting a 1 or a 0.
>>>
>>
>> Compressing the range is an interesting concept, that I wasn't aware of. I'll
>> give some thought to the formula presented there. But I would suspect that
>> POV-Ray's internal rounding would be *either* 'round up' OR 'round down', but
>> not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
>> 1.0).
> 
> I did find the topic of rounding to be more complex than my initial naive
> concept.  There are different ways to do it, and it would be useful and
> instructive to see examples of code that performed all the different variations.

Mostly, there are 3 ways : Round down, or truncate, round to the closest 
and round up.

Using int() or floor() is useful to round down.
Using ceil() is the way to round up.
Adding half of the desired interval and using int() or floor() or 
subtract half the range and use int() or ceil() to round to the closest.
The advantage of floor() and ceil() is that it's easier to round to 
non-integer bounds.

> 
> Likewise, it would likely be useful for people writing code that requires
> variations of inclusive / exclusive bounds to be able to
> 
> (0, 5) = 1, 2, 3, 4
> (0, 5] = 1, 2, 3, 4, 5
> [0, 5) = 0, 1, 2, 3, 4
> [0, 5] = 0, 1, 2, 3, 4, 5
> 
> 
> It would also be informative to know just what the probability of any given rand
> () result is, given the starting arguments / formulation.
> 
> 

Various seed() should all result in the same probabilities, but with 
various sequences.

[Bald Eagle] Re: revisiting rand(...) [2825 days 13 hours and 6 minutes ago]

Thu, 19 Jul 2018 00:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Alain <kua### [at] videotronca> wrote:
> >
> > > All values are equally possible, including 0 and 1. The mantissa for a
> > > float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
> > > a 0 and the same of getting a 1. Very small but not zero chance.
> >
> > So then maybe round to the nearest Q decimal place to "compress" the range and
> > increase the likelihood of getting a 1 or a 0.
> >
>
> Compressing the range is an interesting concept, that I wasn't aware of. I'll
> give some thought to the formula presented there. But I would suspect that
> POV-Ray's internal rounding would be *either* 'round up' OR 'round down', but
> not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
> 1.0).

I did find the topic of rounding to be more complex than my initial naive
concept.  There are different ways to do it, and it would be useful and
instructive to see examples of code that performed all the different variations.

Likewise, it would likely be useful for people writing code that requires
variations of inclusive / exclusive bounds to be able to

(0, 5) = 1, 2, 3, 4
(0, 5] = 1, 2, 3, 4, 5
[0, 5) = 0, 1, 2, 3, 4
[0, 5] = 0, 1, 2, 3, 4, 5


It would also be informative to know just what the probability of any given rand
() result is, given the starting arguments / formulation.

[Kenneth] Re: revisiting rand(...) [2825 days 14 hours and 11 minutes ago]

Wed, 18 Jul 2018 23:00:01 GMT

Alain <kua### [at] videotronca> wrote:

>
> If you get scale 0, a warning is generated and the scalling will default
> to scale 1.
>
> So, no error, just a warning.
>

That's true; I probably used a poor code example to demonstrate what might occur
IF rand(...) actually hit 0.0

[clipka] Re: revisiting rand(...) [2825 days 14 hours and 15 minutes ago]

Wed, 18 Jul 2018 22:55:31 GMT

Am 18.07.2018 um 16:38 schrieb Kenneth:
> Jim Holsenback <ash### [at] nospamcom> wrote:
>> On 07/17/2018 06:27 AM, Kenneth wrote:
>>> (BTW, I tried to find the rand() entry in the online wiki, just to see if the
>>> info there has changed since the latest(?) POV-included documentation, but I
>>> didn't know where to look.)
>>
>> most of the time i look here first:
>> http://wiki.povray.org/content/Reference:Keywords
> 
> Well, that's strange (and it does indeed have info on "rand"). But I originally
> looked at a different "keywords" page...
> 
> http://wiki.povray.org/content/Reference:Keywords

I guess you mean `http://wiki.povray.org/content/Keyword`.

> Clicking on "rand" there brings up no actual information, just the word itself.
> :-(

Yeah. The entire "Keyword" section of the Wiki (as opposed to the
"Reference:Keywords" page) is, to the best of my knowledge, only there
for technical reasons, related to some age-old bad decision that nobody
had the time or energy to roll back yet.

[Alain] Re: revisiting rand(...) [2825 days 20 hours and 47 minutes ago]

Wed, 18 Jul 2018 16:23:45 GMT

Le 18-07-17 Ã  17:25, Kenneth a Ã©critÂ :
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> Theoretically and without too detailed analysis(*), the random number
>> generator should be able to generate 2^32 (approx. 4 [short] billion)
>> different results, including both 0.0 and 1.0. So unless you did your
>> experiment with 200 different seeds, you're still far from the threshold
>> where you could expect /any/ particular result value crop up for sure.
>>
> 
> I do see your point (and Alain's): Let's say I write some code where I naively
> *expect* a rand() value of 0.0 or 1.0 to pop up every now and then (well, with a
> 1-in-4-billion chance, assuming *equal* probability.) But those are distinct,
> specific values-- it would be like expecting the exact value of .4729418830...
> to pop up now and again. Which is highly unlikely (but still possible.)
> 
> But there's a practical aspect to consider, when writing a typical scene using
> rand()-- if my own experience is any indication:
> 
> Let's say I want to make 10,000,000 stars in the sky. My own current way of
> doing this (simplified) would be...
> 
> union{
> #for(i,1,10000000)
> sphere{0,1 scale 100*rand(R)
> translate ...
> }
> #end
>    texture{...}
> }
> 
> .... and I would ignore the *remote* possibility of rand() being 0.0, and thus
> scale being <0.0,0.0,0.0>, which would trigger an error. Yet this *seems* to be
> the behavior of rand(), in a practical sense, so I always feel safe in ignoring
> that possibility.
> 
> But to be extra-safe, the code *should* be something like this...
> ....
> sphere{0,1 scale 100*(rand(R) + "some tiny positive value")
> ....
> 
> .... even though rand() 'never' hits exactly 0.0, in my experience.
> 
> 
> 
> 
> 

If you get scale 0, a warning is generated and the scalling will default 
to scale 1.

So, no error, just a warning.


Alain

[Kenneth] Re: revisiting rand(...) [2825 days 22 hours and 31 minutes ago]

Wed, 18 Jul 2018 14:40:01 GMT

Jim Holsenback <ash### [at] nospamcom> wrote:
> On 07/17/2018 06:27 AM, Kenneth wrote:
> > (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> > info there has changed since the latest(?) POV-included documentation, but I
> > didn't know where to look.)
>
> most of the time i look here first:
> http://wiki.povray.org/content/Reference:Keywords

Well, that's strange (and it does indeed have info on "rand"). But I originally
looked at a different "keywords" page...

http://wiki.povray.org/content/Reference:Keywords

Clicking on "rand" there brings up no actual information, just the word itself.
:-(

The wiki page that I usually look at first, as a general starting place, is...

http://wiki.povray.org/content/Documentation:Contents

 ... and I see now that it does indeed have the correct link to "identifiers and
keywords"-- but that link is located in the first paragraph of the page, which I
didn't originally notice :-O  I think a better place for that link would be in
the left-hand column of the page (with the other entries there), rather than in
the body of the page. And perhaps there's some confusing redundancy of 'keyword'
pages in the wiki?

[clipka] Re: revisiting rand(...) [2825 days 23 hours and 52 minutes ago]

Wed, 18 Jul 2018 13:18:43 GMT

Am 17.07.2018 um 22:11 schrieb Kenneth:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> Alain <kua### [at] videotronca> wrote:
>>
>>> All values are equally possible, including 0 and 1. The mantissa for a
>>> float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
>>> a 0 and the same of getting a 1. Very small but not zero chance.
>>
>> So then maybe round to the nearest Q decimal place to "compress" the range and
>> increase the likelihood of getting a 1 or a 0.
>>
> 
> Compressing the range is an interesting concept, that I wasn't aware of. I'll
> give some thought to the formula presented there. But I would suspect that
> POV-Ray's internal rounding would be *either* 'round up' OR 'round down', but
> not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
> 1.0).

While that's indeed the way most floating-point random number generators
work -- usually giving you a number ranging from 0.0 inclusive to 1.0
exclusive -- POV-Ray's SDL random number generator is designed to be
inclusive both fenceposts.

[Jim Holsenback] Re: revisiting rand(...) [2826 days 4 hours and 16 minutes ago]

Wed, 18 Jul 2018 08:54:13 GMT

On 07/17/2018 06:27 AM, Kenneth wrote:
> (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> info there has changed since the latest(?) POV-included documentation, but I
> didn't know where to look.)

most of the time i look here first:
http://wiki.povray.org/content/Reference:Keywords

[Kenneth] Re: revisiting rand(...) [2826 days 15 hours and 41 minutes ago]

Tue, 17 Jul 2018 21:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> Theoretically and without too detailed analysis(*), the random number
> generator should be able to generate 2^32 (approx. 4 [short] billion)
> different results, including both 0.0 and 1.0. So unless you did your
> experiment with 200 different seeds, you're still far from the threshold
> where you could expect /any/ particular result value crop up for sure.
>

I do see your point (and Alain's): Let's say I write some code where I naively
*expect* a rand() value of 0.0 or 1.0 to pop up every now and then (well, with a
1-in-4-billion chance, assuming *equal* probability.) But those are distinct,
specific values-- it would be like expecting the exact value of .4729418830...
to pop up now and again. Which is highly unlikely (but still possible.)

But there's a practical aspect to consider, when writing a typical scene using
rand()-- if my own experience is any indication:

Let's say I want to make 10,000,000 stars in the sky. My own current way of
doing this (simplified) would be...

union{
#for(i,1,10000000)
sphere{0,1 scale 100*rand(R)
translate ...
}
#end
  texture{...}
}

.... and I would ignore the *remote* possibility of rand() being 0.0, and thus
scale being <0.0,0.0,0.0>, which would trigger an error. Yet this *seems* to be
the behavior of rand(), in a practical sense, so I always feel safe in ignoring
that possibility.

But to be extra-safe, the code *should* be something like this...
....
sphere{0,1 scale 100*(rand(R) + "some tiny positive value")
....

.... even though rand() 'never' hits exactly 0.0, in my experience.

[Warren] Re: revisiting rand(...) [2826 days 15 hours and 46 minutes ago]

Tue, 17 Jul 2018 21:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 17.07.2018 um 12:27 schrieb Kenneth:
> > I'm wondering about the documentation for rand(...).
> >
> > It has stated for a long time that the values that rand produces are "between
> > 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> > actually hits those exact values. (Some of my code would actually have a problem
> > if that happened; but I've never encountered such a problem... which is why I
> > now ignore the 'inclusivity.')
> >
> > On a whim, I ran some tests (with different seed(...) values)-- 10,000,000 tries
> > each time. But I haven't yet seen a 1.0 or a 0.0 occur.
>
> Theoretically and without too detailed analysis(*), the random number
> generator should be able to generate 2^32 (approx. 4 [short] billion)
> different results, including both 0.0 and 1.0. So unless you did your
> experiment with 200 different seeds, you're still far from the threshold
> where you could expect /any/ particular result value crop up for sure.
>
> (*The floating-point random number generator is based on an integer
> Linear Congruential Generator; there is some chance the configuration
> parameters of that LCG cause it to disfavour result values 0.0 and/or
> 1.0. However, without detailed analysis, the same could be said for any
> other of the 2^32 possible result values.)

I always thought the interval of the numbers geanrated with the rand function of
povray was between 0 (included) and 1 (excluded). That scheme would be more
relevant. Imagine you want a random integer between 0 and 4 to easily take
something in an array with an index made randomly (to avoid a switch for
example).

//Code
#declare CollectionOfThings = array[5]

#declare RandomGen = seed(789456);

#declare Thing = CollectionOfThings[int(5 * rand(RandomGen) ];

Here the index will be strictly between 0 and 5 (excluded), with a random number
between 0.0 and 0.2 (excluded) , you get an index of 0 , with a random number
between 0.2 and 0.4 (excluded) you get an index of 1 for the array, etc..

//-------------
For a random System that generate number between 0 and 1 , both included , the
above code has a bug. From 0.8 to 1.0 (excluded) you get an index of 4 and
there's still a chance of getting an index of 5 (almost null I admit it) and a
segfault. So you might think replacing the problematic code with:

#declare Thing = CollectionOfThings[int(4 * rand(RandomGen) )]

But here you have almost no chance of getting an index of 4. ;-)

[Kenneth] Re: revisiting rand(...) [2826 days 16 hours and 56 minutes ago]

Tue, 17 Jul 2018 20:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Alain <kua### [at] videotronca> wrote:
>
> > All values are equally possible, including 0 and 1. The mantissa for a
> > float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
> > a 0 and the same of getting a 1. Very small but not zero chance.
>
> So then maybe round to the nearest Q decimal place to "compress" the range and
> increase the likelihood of getting a 1 or a 0.
>

Compressing the range is an interesting concept, that I wasn't aware of. I'll
give some thought to the formula presented there. But I would suspect that
POV-Ray's internal rounding would be *either* 'round up' OR 'round down', but
not both (?) In other words, a 1.0 (but never a 0.0), OR a 0.0 (but never a
1.0).

[clipka] Re: revisiting rand(...) [2826 days 19 hours and 25 minutes ago]

Tue, 17 Jul 2018 17:45:22 GMT

Am 17.07.2018 um 12:27 schrieb Kenneth:
> I'm wondering about the documentation for rand(...).
> 
> It has stated for a long time that the values that rand produces are "between
> 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> actually hits those exact values. (Some of my code would actually have a problem
> if that happened; but I've never encountered such a problem... which is why I
> now ignore the 'inclusivity.')
> 
> On a whim, I ran some tests (with different seed(...) values)-- 10,000,000 tries
> each time. But I haven't yet seen a 1.0 or a 0.0 occur.

Theoretically and without too detailed analysis(*), the random number
generator should be able to generate 2^32 (approx. 4 [short] billion)
different results, including both 0.0 and 1.0. So unless you did your
experiment with 200 different seeds, you're still far from the threshold
where you could expect /any/ particular result value crop up for sure.

(*The floating-point random number generator is based on an integer
Linear Congruential Generator; there is some chance the configuration
parameters of that LCG cause it to disfavour result values 0.0 and/or
1.0. However, without detailed analysis, the same could be said for any
other of the 2^32 possible result values.)

[Bald Eagle] Re: revisiting rand(...) [2826 days 21 hours and 1 minute ago]

Tue, 17 Jul 2018 16:10:00 GMT

Alain <kua### [at] videotronca> wrote:
> Le 18-07-17 Ã  06:27, Kenneth a Ã©critÂ :
> > I'm wondering about the documentation for rand(...).

> All values are equally possible, including 0 and 1. The mantissa for a
> float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting
> a 0 and the same of getting a 1. Very small but not zero chance.

So then maybe round to the nearest Q decimal place to "compress" the range and
increase the likelihood of getting a 1 or a 0.

See this post in an old thread:
http://news.povray.org/povray.newusers/message/%3C51fb4924%241%40news.povray.org%3E/#%3C51fb4924%241%40news.povray.org%
3E

[Alain] Re: revisiting rand(...) [2826 days 21 hours and 59 minutes ago]

Tue, 17 Jul 2018 15:11:24 GMT

Le 18-07-17 Ã  06:27, Kenneth a Ã©critÂ :
> I'm wondering about the documentation for rand(...).
> 
> It has stated for a long time that the values that rand produces are "between
> 0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
> actually hits those exact values. (Some of my code would actually have a problem
> if that happened; but I've never encountered such a problem... which is why I
> now ignore the 'inclusivity.')
> 
> On a whim, I ran some tests (with different seed(...) values)-- 10,000,000 tries
> each time. But I haven't yet seen a 1.0 or a 0.0 occur.
> 
> #declare S = seed(17);
> #for(i,1,10000000)
> #declare R = rand(S);
> #if(R = 0.0 | R = 1.0)
> #debug concat("\n","rand = ",str(R,1,6),"\n")
> #else
> #end
> #end
> 
> Unless there *is* a one-in-a-gazillion chance of it happening (uh, like the
> decay of a proton, for example), I think the docs should say, "between 0.0 and
> 1.0, exclusive."
> 
> (BTW, I tried to find the rand() entry in the online wiki, just to see if the
> info there has changed since the latest(?) POV-included documentation, but I
> didn't know where to look.)
> 
> 

All values are equally possible, including 0 and 1. The mantissa for a 
float is about 52 bits IIRC, so, you have a 1 in 2^52 chances of getting 
a 0 and the same of getting a 1. Very small but not zero chance.

[Kenneth] revisiting rand(...) [2827 days 2 hours and 41 minutes ago]

Tue, 17 Jul 2018 10:30:00 GMT

I'm wondering about the documentation for rand(...).

It has stated for a long time that the values that rand produces are "between
0.0 and 1.0, inclusive." But in all my uses of it in scenes, the value never
actually hits those exact values. (Some of my code would actually have a problem
if that happened; but I've never encountered such a problem... which is why I
now ignore the 'inclusivity.')

On a whim, I ran some tests (with different seed(...) values)-- 10,000,000 tries
each time. But I haven't yet seen a 1.0 or a 0.0 occur.

#declare S = seed(17);
#for(i,1,10000000)
#declare R = rand(S);
#if(R = 0.0 | R = 1.0)
#debug concat("\n","rand = ",str(R,1,6),"\n")
#else
#end
#end

Unless there *is* a one-in-a-gazillion chance of it happening (uh, like the
decay of a proton, for example), I think the docs should say, "between 0.0 and
1.0, exclusive."

(BTW, I tried to find the rand() entry in the online wiki, just to see if the
info there has changed since the latest(?) POV-included documentation, but I
didn't know where to look.)

[William F Pokorny] Wiki link captcha confirm mechanism broken. [2862 days 23 hours and 49 minutes ago]

Mon, 11 Jun 2018 13:21:11 GMT

FYI.

In some edits today unable to include links back into newsgroups due the 
captcha mechanism we use no longer being supported by Google.

Bill P.

[Jim Holsenback] Re: Clarification on new 3.8 user_defined {} cap... [2966 days 2 hours and 10 minutes ago]

Wed, 28 Feb 2018 11:00:14 GMT

On 02/11/2018 08:13 AM, William F Pokorny wrote:
> In responding to another post was reminded we should add a note to:
> 
> http://wiki.povray.org/content/Reference:User_Defined_Pattern
> 
> that this user_defined { } capability extends to density {} blocks as 
> well as pigments though of course using only the red, green and blue 
> function values. Our current documentation mentions only the pigment {} 
> usage.
> 
> Bill P.
done

[Mike Horvath] Re: #for missing online 3.7.1 [2977 days 10 hours and 16 minutes ago]

Sat, 17 Feb 2018 02:55:10 GMT

On 2/16/2018 10:41 AM, clipka wrote:
> Am 16.02.2018 um 09:03 schrieb dick balaska:
>> http://www.povray.org/documentation/view/3.7.1/241/
>>
>> discusses #if #ifdef #switch #range #while, basically everything except
>> #for.
>>
>> (Also I notice a 2008 copyright on the bottom of that page. I didn't
>> think 3.7.1 was *that* old. ;) )
> 
> What (besides the URL itself) makes you believe that's the v3.7.1 online
> documentation - and how did you arrive at that URL in the first place?
> 
> Note the tab above the text reading "POV-Ray 3.6 Documentation Online View".
> 
> Also, for giggles, try this URL:
> 
> http://www.povray.org/documentation/view/3.8.2/241/
> 
> 
> The most recent documentation on www.povray.org is the official
> documentation of v3.7.0, and its URLs read something like:
> 
> http://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_1_3
> 
> 
> The "most official" documentation of v3.7.1 / v3.8 can be found on the
> Wiki (http://wiki.povray.org).
> 

POV-Ray 8.2.0 docs are the most accurate docs, because they were written 
in the future.

http://www.povray.org/documentation/view/8.2.0/241/


Mike

[Mike Horvath] Re: Corrections to documented media defaults. [2977 days 10 hours and 18 minutes ago]

Sat, 17 Feb 2018 02:52:16 GMT

On 2/15/2018 4:17 PM, dick balaska wrote:
> On 02/15/2018 04:03 PM, Mike Horvath wrote:
>> Off-topic, but your posts always show up as belonging to clipka in 
>> Thunderbird. I think it is because you both use the same anonymous 
>> email address.
>>
>>
>> Mike
> 
> I don't see that. (Thunderbird/Ubuntu).
> You likely have anonymous in your address book and it substitutes.
> 


Yes. I since removed clipka from my address book (sorry, Christoph!), 
and Bill's name is showing up correctly now.


Mike

[William F Pokorny] Re: Corrections to documented media defaults. [2977 days 12 hours and 7 minutes ago]

Sat, 17 Feb 2018 01:04:06 GMT

On 02/16/2018 01:44 PM, Alain wrote:
> Le 18-02-16 Ã  07:56, William F Pokorny a Ã©critÂ :
>> On 02/15/2018 07:36 PM, Alain wrote:
> 
> Then, the various defaults should be given for each sampling methods.
> 
> Default :
> Sampling method = 3
> samples 10 (if you use two values, the second will be silently ignored)
> intervals 1 (Don't change as it drastically increase rendering time)
> confidance, variance are not used.
> 
> Optional methods are 1 and 2. For those the defaults are :
> samples min 1 max 1
> intervals 10
> ...
> 

Better documentation on what settings are used by each media method 
would be helpful for sure, but today the defaults set are the same no 
matter the method defaulted or set. In other words, there are not 
different defaults set for methods 1 & 2 should the user specify one of 
those in the media.

Aside: Not universally true, but often keywords and their settings can 
be given in any order in a block {}. Further you can often later in a 
parse refer to a defined 'item' and override some part of it. Useful, 
but this freedom makes having different default sets or sanity checking 
a group of settings for consistency during the parsing phase more 
difficult. The only place where I know we've today got some pseudo post 
parse checking is with patterns and in that case the extra verification 
happens only with the pavement and tiling patterns.

Bill P.

[Bald Eagle] Re: Corrections to documented media defaults. [2977 days 15 hours and 26 minutes ago]

Fri, 16 Feb 2018 21:45:01 GMT

This is just something that I always wish there was something in POV-Ray where
you could just do something like:

#displaydefault {media}

#man media

or something similar.

I usually [try to] embed some sort of debugging output flag into my code so that
when it's enabled, the code spits out any (ok, every) relevant value.

Perhaps something to think about for 4.0 so that the software itself can answer
questions instead of / in addition to a separate documentation page.

Think "measurement", not "label".

[Alain] Re: Corrections to documented media defaults. [2977 days 18 hours and 27 minutes ago]

Fri, 16 Feb 2018 18:43:48 GMT

Le 18-02-16 Ã  07:56, William F Pokorny a Ã©critÂ :
> On 02/15/2018 07:36 PM, Alain wrote:
>> Le 18-02-15 Ã  13:30, William F Pokorny a Ã©critÂ :
>>> On the page:
>>>
>>> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
>>>
>>> samplesÂ Â Â Â Â  : Min 1, Max 1
>>>
>>> should be:
>>>
>>> samplesÂ Â Â Â Â  : Min 10, Max
10
>>>
>>> given we otherwise have the >=3.5 method 3 defaults documented.
>>>
>>> Bill P.
>>
>> It should be "samples 10"
>> min and max are only used with method 1 and 2.
> 
> Understand what you are saying, but here we are documenting what POV-Ray 
> is setting as the default if the language level seen by the parser is >= 
> 3.5. This override happens on seeing the media keyword. A user can, for 
> example, still specify method 2 in that media and then knowing that 
> default max value is 10 matters.
> 
> Aside: I'm with you in not understanding why the parser sets the max 
> value for language level >= 3.5 for method 3, but it does. If it didn't 
> we'd need to leave Max 1 for the same reason - it helps users understand 
> what defaults are when those defaults apply to the method they are using.
> 
> Bill P.

Then, the various defaults should be given for each sampling methods.

Default :
Sampling method = 3
samples 10 (if you use two values, the second will be silently ignored)
intervals 1 (Don't change as it drastically increase rendering time)
confidance, variance are not used.

Optional methods are 1 and 2. For those the defaults are :
samples min 1 max 1
intervals 10
...

[dick balaska] Re: #for missing online 3.7.1 [2977 days 18 hours and 44 minutes ago]

Fri, 16 Feb 2018 18:26:13 GMT

On 02/16/2018 10:41 AM, clipka wrote:
> Am 16.02.2018 um 09:03 schrieb dick balaska:
>> http://www.povray.org/documentation/view/3.7.1/241/
>>
>> discusses #if #ifdef #switch #range #while, basically everything except
>> #for.
>>
>> (Also I notice a 2008 copyright on the bottom of that page. I didn't
>> think 3.7.1 was *that* old. ;) )
> 
> What (besides the URL itself) makes you believe that's the v3.7.1 online
> documentation - and how did you arrive at that URL in the first place?

Bleh. I was tired. :)
It was the url. And part of my brain said "there is no 3.7.1 specific 
docs. It's 3.7".  And Mr. Google sent me there.


> 
> Note the tab above the text reading "POV-Ray 3.6 Documentation Online View".

This is the part where, if this were facebook, would look like:
1) Open mouth
2) Insert foot
3) Delete post.


-- 
dik
Rendered 920576 of 921600 pixels (99%)

[Kenneth] Re: Corrections to documented media defaults. [2977 days 18 hours and 56 minutes ago]

Fri, 16 Feb 2018 18:15:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
.....and I think photon jitter put into the photon media
> depositing while debugging and got left in accidentally. I can see no
> reason to introduce the banding artifact - see our optics.pov scene
> (more visible if you reduce the media gather radius but it's there in
> the scene we ship). The default jitter should be the full 1.0 always as
> far as I can see.
>

I agree. Although I haven't used photons in awhile, I noticed a long time ago
that jitter 0.5 wasn't enough to eliminate visible 'rings', especially seen
close-up. I never mentioned it, though :-(  And I no longer have the test
scene that I used. If 0.5 is still the default, it does need reworking for a
smoother more-random appearance.

[Thorsten Froehlich] Re: #for missing online 3.7.1 [2977 days 21 hours and 6 minutes ago]

Fri, 16 Feb 2018 16:05:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 16.02.2018 um 09:03 schrieb dick balaska:
> > http://www.povray.org/documentation/view/3.7.1/241/
> >
> > discusses #if #ifdef #switch #range #while, basically everything except
> > #for.
> >
> > (Also I notice a 2008 copyright on the bottom of that page. I didn't
> > think 3.7.1 was *that* old. ;) )
>
> What (besides the URL itself) makes you believe that's the v3.7.1 online
> documentation - and how did you arrive at that URL in the first place?
>
> Note the tab above the text reading "POV-Ray 3.6 Documentation Online View".
>
> Also, for giggles, try this URL:
>
> http://www.povray.org/documentation/view/3.8.2/241/

Indeed. The script behind it is able to resolve older (3.5) documentation links
and translate them to 3.6 links based on a table. The script was made to always
use the latest doc version in case of an error. Apparently nobody updated the
table to also include 3.7.

[clipka] Re: #for missing online 3.7.1 [2977 days 21 hours and 29 minutes ago]

Fri, 16 Feb 2018 15:41:50 GMT

Am 16.02.2018 um 09:03 schrieb dick balaska:
> http://www.povray.org/documentation/view/3.7.1/241/
> 
> discusses #if #ifdef #switch #range #while, basically everything except
> #for.
> 
> (Also I notice a 2008 copyright on the bottom of that page. I didn't
> think 3.7.1 was *that* old. ;) )

What (besides the URL itself) makes you believe that's the v3.7.1 online
documentation - and how did you arrive at that URL in the first place?

Note the tab above the text reading "POV-Ray 3.6 Documentation Online View".

Also, for giggles, try this URL:

http://www.povray.org/documentation/view/3.8.2/241/


The most recent documentation on www.povray.org is the official
documentation of v3.7.0, and its URLs read something like:

http://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_1_3


The "most official" documentation of v3.7.1 / v3.8 can be found on the
Wiki (http://wiki.povray.org).

[William F Pokorny] Re: Corrections to documented media defaults. [2977 days 23 hours and 46 minutes ago]

Fri, 16 Feb 2018 13:24:51 GMT

On 02/15/2018 11:11 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> What's also missing from all of the various media wiki references I've looked at
> is that, with method 3, a *single* samples value can be used instead...
> 
> samples  35
> 
> ....but even then, it isn't clear if method 3 is the *only* method that can do
> that. Do methods 1 and 2 *require* 2 values?
> 
> The docs do need updating about this-- but I'm wondering if, sometime within the
> v3.5-to-3.7 interval, the default samples value changed more than once(?) In
> which case, changing the docs' default to  samples 10 (or 10,10?)  might raise
> questions for users of those older versions-- if samples 1,1  as the default
> 'came and went' with various versions.  (Of course, that predicament cold be
> easily solved with an extra note in the docs, about old vs. new behavior.)
> 

Agree further doc updates are needed. As I dig deeper into media I'm 
gathering a list of other documentation updates that would be helpful I 
think including some of what you discuss. Trying not to go after too 
much at once - and some behavior suppose we might change sooner rather 
than later.

For example, while I've never made use of photons beyond playing with 
the distribution sample scenes, I now know it's "method" for media is 
it's own thing. 'Method photons' - suppose I see it as most like method 
2 at this point - is not using at all the sample or jitter settings for 
example. ...and I think photon jitter put into the photon media 
depositing while debugging and got left in accidentally. I can see no 
reason to introduce the banding artifact - see our optics.pov scene 
(more visible if you reduce the media gather radius but it's there in 
the scene we ship). The default jitter should be the full 1.0 always as 
far as I can see.

We have this page:

http://wiki.povray.org/content/Reference:Sampling_Parameters_%26_Methods#Index_Entry_method_media

where it might be good to mention the effective method 'photons', how it 
is different, how it can and cannot be controlled by media block 
settings.  There is limited documentation where the photons feature is 
documented.

(Yes, that page lists the default method 3 aa_level as 4 when it's 3 as 
indicated on the initial wiki page of this thread.)

Anyway... Also so much of the whole of media behavior I still don't 
understand.

Bill P.

[William F Pokorny] Re: Corrections to documented media defaults. [2978 days and 15 minutes ago]

Fri, 16 Feb 2018 12:56:02 GMT

On 02/15/2018 07:36 PM, Alain wrote:
> Le 18-02-15 Ã  13:30, William F Pokorny a Ã©critÂ :
>> On the page:
>>
>> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
>>
>> samplesÂ Â Â Â Â  : Min 1, Max 1
>>
>> should be:
>>
>> samplesÂ Â Â Â Â  : Min 10, Max
10
>>
>> given we otherwise have the >=3.5 method 3 defaults documented.
>>
>> Bill P.
> 
> It should be "samples 10"
> min and max are only used with method 1 and 2.

Understand what you are saying, but here we are documenting what POV-Ray 
is setting as the default if the language level seen by the parser is >= 
3.5. This override happens on seeing the media keyword. A user can, for 
example, still specify method 2 in that media and then knowing that 
default max value is 10 matters.

Aside: I'm with you in not understanding why the parser sets the max 
value for language level >= 3.5 for method 3, but it does. If it didn't 
we'd need to leave Max 1 for the same reason - it helps users understand 
what defaults are when those defaults apply to the method they are using.

Bill P.

[dick balaska] #for missing online 3.7.1 [2978 days 5 hours and 7 minutes ago]

Fri, 16 Feb 2018 08:03:14 GMT

http://www.povray.org/documentation/view/3.7.1/241/

discusses #if #ifdef #switch #range #while, basically everything except 
#for.

(Also I notice a 2008 copyright on the bottom of that page. I didn't 
think 3.7.1 was *that* old. ;) )

-- 
dik
Rendered 920576 of 921600 pixels (99%)

[Kenneth] Re: Corrections to documented media defaults. [2978 days 8 hours and 56 minutes ago]

Fri, 16 Feb 2018 04:15:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On the page:
>
> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
>
> samples      : Min 1, Max 1
>
> should be:
>
> samples      : Min 10, Max 10
>
> given we otherwise have the >=3.5 method 3 defaults documented.
>

What's also missing from all of the various media wiki references I've looked at
is that, with method 3, a *single* samples value can be used instead...

samples  35

....but even then, it isn't clear if method 3 is the *only* method that can do
that. Do methods 1 and 2 *require* 2 values?

The docs do need updating about this-- but I'm wondering if, sometime within the
v3.5-to-3.7 interval, the default samples value changed more than once(?) In
which case, changing the docs' default to  samples 10 (or 10,10?)  might raise
questions for users of those older versions-- if samples 1,1  as the default
'came and went' with various versions.  (Of course, that predicament cold be
easily solved with an extra note in the docs, about old vs. new behavior.)

[Alain] Re: Corrections to documented media defaults. [2978 days 12 hours and 32 minutes ago]

Fri, 16 Feb 2018 00:38:25 GMT

Le 18-02-15 Ã  16:03, Mike Horvath a Ã©critÂ :
> On 2/15/2018 1:30 PM, William F Pokorny wrote:
>> On the page:
>>
>> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
>>
>> samplesÂ Â Â Â Â  : Min 1, Max 1
>>
>> should be:
>>
>> samplesÂ Â Â Â Â  : Min 10, Max
10
>>
>> given we otherwise have the >=3.5 method 3 defaults documented.
>>
>> Bill P.
> 
> Off-topic, but your posts always show up as belonging to clipka in 
> Thunderbird. I think it is because you both use the same anonymous email 
> address.
> 
> 
> Mike

Show correctly here. Thunderbird under Windows 7.

[Alain] Re: Corrections to documented media defaults. [2978 days 12 hours and 35 minutes ago]

Fri, 16 Feb 2018 00:36:03 GMT

Le 18-02-15 Ã  13:30, William F Pokorny a Ã©critÂ :
> On the page:
> 
> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
> 
> samplesÂ Â Â Â Â  : Min 1, Max 1
> 
> should be:
> 
> samplesÂ Â Â Â Â  : Min 10, Max 10
> 
> given we otherwise have the >=3.5 method 3 defaults documented.
> 
> Bill P.

It should be "samples 10"
min and max are only used with method 1 and 2.

[dick balaska] Re: Corrections to documented media defaults. [2978 days 15 hours and 53 minutes ago]

Thu, 15 Feb 2018 21:17:22 GMT

On 02/15/2018 04:03 PM, Mike Horvath wrote:
> Off-topic, but your posts always show up as belonging to clipka in 
> Thunderbird. I think it is because you both use the same anonymous email 
> address.
> 
> 
> Mike

I don't see that. (Thunderbird/Ubuntu).
You likely have anonymous in your address book and it substitutes.

-- 
dik
Rendered 920576 of 921600 pixels (99%)

[Mike Horvath] Re: Corrections to documented media defaults. [2978 days 16 hours and 7 minutes ago]

Thu, 15 Feb 2018 21:03:28 GMT

On 2/15/2018 1:30 PM, William F Pokorny wrote:
> On the page:
> 
> http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types
> 
> samplesÂ Â Â Â Â  : Min 1, Max 1
> 
> should be:
> 
> samplesÂ Â Â Â Â  : Min 10, Max 10
> 
> given we otherwise have the >=3.5 method 3 defaults documented.
> 
> Bill P.

Off-topic, but your posts always show up as belonging to clipka in 
Thunderbird. I think it is because you both use the same anonymous email 
address.

Mike

[William F Pokorny] Corrections to documented media defaults. [2978 days 18 hours and 40 minutes ago]

Thu, 15 Feb 2018 18:30:34 GMT

On the page:

http://wiki.povray.org/content/Reference:Media#Index_Entry_media_types

samples      : Min 1, Max 1

should be:

samples      : Min 10, Max 10

given we otherwise have the >=3.5 method 3 defaults documented.

Bill P.

[Mike Horvath] Is blurred reflection possible in POV-Ray [2981 days 10 hours ago]

Tue, 13 Feb 2018 03:11:04 GMT

This topic is in

http://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_13


There should be an additional mention of not using the averaged normals 
approach, but using a single normal plus focal blur and antialiasing.


Clipka talks about this approach here:

http://news.povray.org/povray.binaries.images/thread/%3C5a8191e7%241%40news.povray.org%3E/


Quote:
 > You need:
 >
 > (1) A way to randomize the reflection. A `normal` statement with a very
 > small scale does nicely.
 >
 > (2) A way to force POV-Ray to shoot a high number of rays per pixel
 > where the randomized reflection is. A small bit of focal blur (with high
 > quality settings) does nicely.
 >
 > Together this gives you nice blurred reflections at a (hopefully)
 > reasonable speed.




The code I used is this:


	texture
	{
		pigment { InPigment }
		finish { InFinish }
		normal { InNormal }
		normal {bumps BlurAmount scale 0.01}
	}

along with some focal blur and antialiasing.


I'm not sure how the section should be worded however.



Mike

[William F Pokorny] Clarification on new 3.8 user_defined {} capabil... [2982 days 23 hours and 57 minutes ago]

Sun, 11 Feb 2018 13:13:31 GMT

In responding to another post was reminded we should add a note to:

http://wiki.povray.org/content/Reference:User_Defined_Pattern

that this user_defined { } capability extends to density {} blocks as 
well as pigments though of course using only the red, green and blue 
function values. Our current documentation mentions only the pigment {} 
usage.

Bill P.

[Kenneth] Re: 3.2.8.7 Anti-Aliasing Options -- a small cor... [2983 days 15 hours and 56 minutes ago]

Sat, 10 Feb 2018 21:15:01 GMT

Jim Holsenback <spa### [at] nothanksnet> wrote:

>
> mo betta?
> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

Hey, that's great; MUCH clearer now. Thanks bunches.

[Jim Holsenback] Re: 3.2.8.7 Anti-Aliasing Options -- a small cor... [2983 days 17 hours and 24 minutes ago]

Sat, 10 Feb 2018 19:47:00 GMT

On 2/8/2018 6:51 PM, Kenneth wrote:
> Alain <kua### [at] videotronca> wrote:
> 
>>
>> That,s for +am2.
>> I think that it mean that if the anti-aliasing threshold is not
>> reatched...
> 
> Maybe so. If that's the case, then I think a different phrase needs to be used,
> rather than "no anti-aliasing". Otherwise, the sentence looks kind of like: 'use
> anti-aliasing while not using anti-aliasing' (!)

mo betta? 
http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

[Jim Holsenback] Re: Is an update due [2983 days 17 hours and 40 minutes ago]

Sat, 10 Feb 2018 19:31:02 GMT

On 2/8/2018 4:25 AM, clipka wrote:
> Am 08.02.2018 um 02:05 schrieb William F Pokorny:
> 
>> It got me wondering whether our documentation at:
>>
>> http://wiki.povray.org/content/Reference:Scene_Parsing_Options#Language_Version
>>
>>
>> should be revised a bit?
>>
>> 1) I see an odd line break when viewing in firefox.
>>
>> ....
>> off expression parsing as well as many warning messages so that nearly
>> all 1.0 files will still <--- LINE OR PARAGRAPH BREAK HERE.
>> work. Naturally the default setting for this option is the current
>> version number.
>> ....
> 
> Actually there are two such odd line breaks: The one you found, and
> another half a paragraph earlier between `See section The #version
> Directive` and `for more details [...]`.
> 
> That's a strange one, as there are indeed paragraph breaks in the HTML
> code there (so it's not just Firefox), but there seems to be nothing in
> the Wiki source that would warrant such paragraph breaks.
> 

the markup for the multi-link extension was the culprit... 
http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

...i also updated the note at the end of language version

[Kenneth] Re: 3.2.8.7 Anti-Aliasing Options -- a small cor... [2985 days 13 hours and 16 minutes ago]

Thu, 8 Feb 2018 23:55:01 GMT

Alain <kua### [at] videotronca> wrote:

>
> That,s for +am2.
> I think that it mean that if the anti-aliasing threshold is not
> reatched...

Maybe so. If that's the case, then I think a different phrase needs to be used,
rather than "no anti-aliasing". Otherwise, the sentence looks kind of like: 'use
anti-aliasing while not using anti-aliasing' (!)

[Mike Horvath] Re: Is an update due [2985 days 13 hours and 49 minutes ago]

Thu, 8 Feb 2018 23:22:10 GMT

I know I have volunteered several times to help with the wiki, but I 
never find the time for it.

Mike

[Alain] Re: 3.2.8.7 Anti-Aliasing Options -- a small cor... [2985 days 15 hours and 22 minutes ago]

Thu, 8 Feb 2018 21:48:23 GMT

Le 18-02-07 Ã  05:57, Kenneth a Ã©critÂ :
> 3.2.8.7 Anti-Aliasing Options (also in the wiki)
> 
> Underneath the 'recursive super-sampling' diagram, it says...
> "Note: The maximum number of samples in the recursive case is hardly ever
> reached for a given pixel. If the recursive method is used with no anti-aliasing
> each pixel will be the average of the rays traced at its corners. In most cases
> a recursion level of three is sufficient."
> 
> "...If the recursive method is used with no anti-aliasing ..."  ??  Uh, with NO
> anti-aliasing? Maybe I'm not grasping what is meant there (and never have), but
> that sounds illogical (?) It has been in the docs forever, so even now I was
> hesitating to mention it; but it has always seemed strange to me.
> 
> In the wiki:
> 
> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
> 
> 
> 

That,s for +am2.
I think that it mean that if the anti-aliasing threshold is not 
reatched, then you get the average of those 4 sub-pixels with no further 
subsampling.

[Jim Holsenback] Re: Is an update due [2986 days 1 hour and 24 minutes ago]

Thu, 8 Feb 2018 11:46:41 GMT

On 2/7/2018 8:05 PM, William F Pokorny wrote:
> 2) The note at the end should perhaps itself end with:
> 
> ...
> Nevertheless, we strongly recommend you update scenes to at least 
> POV-Ray 3.7 syntax, if you plan to use them in future versions of POV-Ray.

gotta run or i'll be late ... i'll do it a soon as i can

[Jim Holsenback] Re: Is an update due [2986 days 1 hour and 26 minutes ago]

Thu, 8 Feb 2018 11:44:50 GMT

On 2/8/2018 4:25 AM, clipka wrote:
> Am 08.02.2018 um 02:05 schrieb William F Pokorny:
> 
>> It got me wondering whether our documentation at:
>>
>> http://wiki.povray.org/content/Reference:Scene_Parsing_Options#Language_Version
>>
>>
>> should be revised a bit?
>>
>> 1) I see an odd line break when viewing in firefox.
>>
>> ....
>> off expression parsing as well as many warning messages so that nearly
>> all 1.0 files will still <--- LINE OR PARAGRAPH BREAK HERE.
>> work. Naturally the default setting for this option is the current
>> version number.
>> ....
> 
> Actually there are two such odd line breaks: The one you found, and
> another half a paragraph earlier between `See section The #version
> Directive` and `for more details [...]`.
> 
> That's a strange one, as there are indeed paragraph breaks in the HTML
> code there (so it's not just Firefox), but there seems to be nothing in
> the Wiki source that would warrant such paragraph breaks.
> 
yep i'm seeing those too ... i looked at the mark-up and saw nothing 
either. i think it's wiki parser. the nix standalone html version looks 
ok even when i resize, it wraps around perfectly. dunno about built-in 
windows version.

[clipka] Re: Is an update due [2986 days 3 hours and 45 minutes ago]

Thu, 8 Feb 2018 09:25:43 GMT

Am 08.02.2018 um 02:05 schrieb William F Pokorny:

> It got me wondering whether our documentation at:
> 
> http://wiki.povray.org/content/Reference:Scene_Parsing_Options#Language_Version
> 
> 
> should be revised a bit?
> 
> 1) I see an odd line break when viewing in firefox.
> 
> ....
> off expression parsing as well as many warning messages so that nearly
> all 1.0 files will still <--- LINE OR PARAGRAPH BREAK HERE.
> work. Naturally the default setting for this option is the current
> version number.
> ....

Actually there are two such odd line breaks: The one you found, and
another half a paragraph earlier between `See section The #version
Directive` and `for more details [...]`.

That's a strange one, as there are indeed paragraph breaks in the HTML
code there (so it's not just Firefox), but there seems to be nothing in
the Wiki source that would warrant such paragraph breaks.

[William F Pokorny] Is an update due [2986 days 12 hours and 5 minutes ago]

Thu, 8 Feb 2018 01:05:49 GMT

There was recently a discussion thread related to #version at:

http://news.povray.org/povray.general/thread/%3C5a7b670c%241%40news.povray.org%3E/

It got me wondering whether our documentation at:

http://wiki.povray.org/content/Reference:Scene_Parsing_Options#Language_Version

should be revised a bit?

1) I see an odd line break when viewing in firefox.

...
off expression parsing as well as many warning messages so that nearly 
all 1.0 files will still <--- LINE OR PARAGRAPH BREAK HERE.
work. Naturally the default setting for this option is the current 
version number.
...

2) The note at the end should perhaps itself end with:

...
Nevertheless, we strongly recommend you update scenes to at least 
POV-Ray 3.7 syntax, if you plan to use them in future versions of POV-Ray.
...

Aside: Our shipped .inc and .pov files as of the release/3.8 branch set 
one .inc at 3.1 and otherwise use a mix of 3.5 through 3.8.

Bill P.

[Kenneth] 3.2.8.7 Anti-Aliasing Options -- a small correct... [2987 days 2 hours and 11 minutes ago]

Wed, 7 Feb 2018 11:00:03 GMT

3.2.8.7 Anti-Aliasing Options (also in the wiki)

Underneath the 'recursive super-sampling' diagram, it says...
"Note: The maximum number of samples in the recursive case is hardly ever
reached for a given pixel. If the recursive method is used with no anti-aliasing
each pixel will be the average of the rays traced at its corners. In most cases
a recursion level of three is sufficient."

"...If the recursive method is used with no anti-aliasing ..."  ??  Uh, with NO
anti-aliasing? Maybe I'm not grasping what is meant there (and never have), but
that sounds illogical (?) It has been in the docs forever, so even now I was
hesitating to mention it; but it has always seemed strange to me.

In the wiki:

http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

[William F Pokorny] Re: BITMAP_TYPE and HF_TYPE documentation versus... [2987 days 2 hours and 32 minutes ago]

Wed, 7 Feb 2018 10:38:48 GMT

On 02/06/2018 06:44 AM, Jim Holsenback wrote:
> On 2/5/2018 6:44 AM, William F Pokorny wrote:
>> On 02/04/2018 02:45 PM, Jim Holsenback wrote:
>>> On 1/8/2018 6:22 AM, Jim Holsenback wrote:
>>>>
>>>> i'll follow up when i have more than a few moments ... which hasn't 
>>>> been very often lately
>>>
>>> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
>>>
>>> click in the "diff" link to see what's been changed
>>
>> For all but the height_field page - which already has the optional 
>> indicator brackets around HF_TYPE - we should add braces [] around 
>> BITMAP_TYPE to indicate those specifications are also optional.
> 
> done ...
> 

Thanks. Much better. There is still one BITMAP_TYPE at the top of the page:

http://wiki.povray.org/content/Reference:Patterned_Textures

without the braces. If you do a search from the top of the page for 
BITMAP_TYPE, it's the first found.

Bill P.

[Jim Holsenback] Re: BITMAP_TYPE and HF_TYPE documentation versus... [2988 days 1 hour and 27 minutes ago]

Tue, 6 Feb 2018 11:44:04 GMT

On 2/5/2018 6:44 AM, William F Pokorny wrote:
> On 02/04/2018 02:45 PM, Jim Holsenback wrote:
>> On 1/8/2018 6:22 AM, Jim Holsenback wrote:
>>>
>>> i'll follow up when i have more than a few moments ... which hasn't 
>>> been very often lately
>>
>> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
>>
>> click in the "diff" link to see what's been changed
> 
> For all but the height_field page - which already has the optional 
> indicator brackets around HF_TYPE - we should add braces [] around 
> BITMAP_TYPE to indicate those specifications are also optional.

done ...

> 
> There is also sometimes text which needs to be changed too - or perhaps 
> as well deleted. The material_map section for example has:
> 
> "After the required BITMAP_TYPE keyword is a string expression 
> containing the name of a bitmapped material file of the specified type."

changed required to optional

> 
> When today BITMAP_TYPE is not required and it is not in fact completely 
> necessary to indicate the type by the filename if your input type 
> matches POV-Rays current output type. This relates to the hierarchy of 
> methods POV-Ray uses to determine the file type to read. I attempted to 
> outline what happens. Today we today best describe it all in our 
> image_map documentation though the fact BITMAP_TYPE is optional is not 
> indicated there-in - as yet.
> 
> Not sure repeating POV-Ray's type decision hierarchy in every 'map' 
> section is necessary though - perhaps get it right / flush it out in the 
> image_map doc with some method to reference it from the others?
> 
> Bill P.

[William F Pokorny] Re: BITMAP_TYPE and HF_TYPE documentation versus... [2989 days 1 hour and 26 minutes ago]

Mon, 5 Feb 2018 11:44:33 GMT

On 02/04/2018 02:45 PM, Jim Holsenback wrote:
> On 1/8/2018 6:22 AM, Jim Holsenback wrote:
>>
>> i'll follow up when i have more than a few moments ... which hasn't 
>> been very often lately
> 
> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
> 
> click in the "diff" link to see what's been changed

For all but the height_field page - which already has the optional 
indicator brackets around HF_TYPE - we should add braces [] around 
BITMAP_TYPE to indicate those specifications are also optional.

There is also sometimes text which needs to be changed too - or perhaps 
as well deleted. The material_map section for example has:

"After the required BITMAP_TYPE keyword is a string expression 
containing the name of a bitmapped material file of the specified type."

When today BITMAP_TYPE is not required and it is not in fact completely 
necessary to indicate the type by the filename if your input type 
matches POV-Rays current output type. This relates to the hierarchy of 
methods POV-Ray uses to determine the file type to read. I attempted to 
outline what happens. Today we today best describe it all in our 
image_map documentation though the fact BITMAP_TYPE is optional is not 
indicated there-in - as yet.

Not sure repeating POV-Ray's type decision hierarchy in every 'map' 
section is necessary though - perhaps get it right / flush it out in the 
image_map doc with some method to reference it from the others?

Bill P.

[Jim Holsenback] Re: BITMAP_TYPE and HF_TYPE documentation versus... [2989 days 17 hours and 25 minutes ago]

Sun, 4 Feb 2018 19:45:58 GMT

On 1/8/2018 6:22 AM, Jim Holsenback wrote:
> On 1/7/2018 12:38 PM, William F Pokorny wrote:
>> The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
>> image_pattern and material_map. HF_TYPE is used for height_fields. 
>> Over time I think the documentation has gotten somewhat scrambled with 
>> respect to current functionality.
>>
>> bump_map:
>> Â Â  http://wiki.povray.org/content/Reference:Bump_Map
>>
>> height_field:
>> http://wiki.povray.org/content/Reference:Height_Field
>>
>> image_pattern:
>> Â Â  http://wiki.povray.org/content/Reference:Image_Pattern
>>
>> image_map:
>> Â Â  http://wiki.povray.org/content/Reference:Image_Map
>>
>> material_map:
>> http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps
>>
>> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe 
>> from 3.7 onward it is everywhere optional.Â  When specified, this is 
>> the file type POV-Ray will try and read no matter the filename given 
>> or the output file type.
>>
>> Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
>> except for height_fields where it is "filename".Â  I think "filename" 
>> is best because that string needs to be the filename POV-Ray looks to 
>> read no matter format.
>>
>> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, 
>> POV-Ray will first look for any known extension in the "filename" 
>> string.Â  If found, that extension is the image format POV-Ray will try 
>> and read.
>>
>> Where the filename has no recognizable extension and BITMAP_TYPE | 
>> HF_TYPE has not been specified, POV-Ray will try and read the 
>> "filename" as whatever the current output image format is. Only the 
>> image_map documentation mentions this latter behavior.
>>
>> There is too in some documentation - material_map for example - this 
>> note:
>>
>> "Note: Earlier versions of POV-Ray allowed some modifiers before the 
>> BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
>> described here."
>>
>> which probably we can drop. At least for the modifiers I tried before 
>> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.
> 
> i'll follow up when i have more than a few moments ... which hasn't been 
> very often lately

http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

click in the "diff" link to see what's been changed

[Kenneth] Re: 3.6.1.1.2 Color Map-- a very minor fix [2990 days 12 hours and 21 minutes ago]

Sun, 4 Feb 2018 00:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> Already fixed on the Wiki (which is where the docs are maintained).

Oops.  This was one of the few times that I didn't check the wiki as well :-(

[clipka] Re: 3.6.1.1.2 Color Map-- a very minor fix [2991 days 1 hour and 21 minutes ago]

Sat, 3 Feb 2018 11:49:57 GMT

Am 03.02.2018 um 04:18 schrieb Kenneth:
> I happened to run across this in "3.6.1.1.2 Color Map"...
> 
> COLOR_MAP:
>   color_map { COLOR_MAP_BODY } | color_map { COLOR_MAP_BODY }
> 
> I assume that the 2nd option was meant to be...
> 
>   | colour_map { COLOUR_MAP_BODY }

Already fixed on the Wiki (which is where the docs are maintained).

[Kenneth] 3.6.1.1.2 Color Map-- a very minor fix [2991 days 9 hours and 51 minutes ago]

Sat, 3 Feb 2018 03:20:00 GMT

I happened to run across this in "3.6.1.1.2 Color Map"...

COLOR_MAP:
  color_map { COLOR_MAP_BODY } | color_map { COLOR_MAP_BODY }

I assume that the 2nd option was meant to be...

  | colour_map { COLOUR_MAP_BODY }

That's my great contribution for the day ;-)

[Kenneth] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3016 days 11 hours and 31 minutes ago]

Tue, 9 Jan 2018 01:40:01 GMT

I wanted to clearly understand all of this behavior (in Windows), so I made an
image_map test-- the four permutations of using (or not using) BITMAP_TYPE and
the image's file extension... along with a chosen Output_File_Type in my
resolution .ini file.

TEST 1 should be with Output_File_Type=N  (to match the .png image used below.)
TEST 2 should be with Output_File_Type=J (or B,P,T etc.-- to purposely mismatch
the input image type.)

RESULTS: TEST 1 works successfuly with all four examples.
         TEST 2 fails on the last example-- a mismatch between image
                type and Output_File_Type.

---------------
#version 3.71;
global_settings {assumed_gamma 1.0 max_trace_level 5}

camera {
  perspective
  location  <.5, .5, -2>
  look_at   <.5, .5,  0>
  right     x*image_width/image_height
  angle 67
}

// Typical use. This *always* works, of course.
box{0, <1,1,.01>
    pigment{image_map{png "MY_IMAGE.png"}}
    scale .5
    }

// BITMAP_TYPE but no file extension.
// This works with both TEST 1 and TEST 2
box{0, <1,1,.01>
    pigment{image_map{png "MY_IMAGE"}}
    scale .5
    translate .5
    }

// No BITMAP_TYPE but with the file extension.
// This works with both TEST 1 and TEST 2
box{0, <1,1,.01>
    pigment{image_map{"MY_IMAGE.png"}}
    scale .5
    translate 1
    }

// No BITMAP_TYPE or file extension.
// This works with TEST 1 but fails with TEST 2.
box{0, <1,1,.01>
    pigment{image_map{"MY_IMAGE"}}
    scale .5
    translate 1.5
    }

[Kenneth] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3016 days 18 hours and 56 minutes ago]

Mon, 8 Jan 2018 18:15:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> My own opinion is that, by
> leaving out any mention of BITMAP_TYPE or HF_TYPE in the docs, new users might
> *possibly* run into a problem due to leaving out the file extension-- and not
> know why.

My apologies; I was confusing BIT_MAP type with the filename extension. I'll
follow up later; I'm currently digging out my car from the snowstorm that hit
the U.S East Coast...

[clipka] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3016 days 20 hours and 13 minutes ago]

Mon, 8 Jan 2018 16:57:18 GMT

Am 08.01.2018 um 09:05 schrieb Kenneth:

>> Where the filename has no recognizable extension and BITMAP_TYPE |
>> HF_TYPE has not been specified, POV-Ray will try and read the "filename"
>> as whatever the current output image format is. Only the image_map
>> documentation mentions this latter behavior.
> 
> The only problem I could imagine is if two files have the same name but
> different file extensions.

No, POV-Ray would actually try to load a file of the name /without/ any
file extensions.

On Windows, files virtually always have a file extension, even though
the Windows Explorer is trying to hide them from the user by default.

Windows makes no attempt to hide those file extensions from /programs/
though; to the contrary, a program trying to opening a file by name
/must/ specify the extension.

When you specify a filename without extension in POV-Ray, the program
does this by guessing the extension, based on the file type keyword.

If the file type keyword isn't specified either, POV-Ray is lost, and
can only guess that the user might intend to load a file that has no
extension at all.

[Jim Holsenback] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3017 days 1 hour and 48 minutes ago]

Mon, 8 Jan 2018 11:22:30 GMT

On 1/7/2018 12:38 PM, William F Pokorny wrote:
> The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
> image_pattern and material_map. HF_TYPE is used for height_fields. Over 
> time I think the documentation has gotten somewhat scrambled with 
> respect to current functionality.
> 
> bump_map:
>  Â  http://wiki.povray.org/content/Reference:Bump_Map
> 
> height_field:
> http://wiki.povray.org/content/Reference:Height_Field
> 
> image_pattern:
>  Â  http://wiki.povray.org/content/Reference:Image_Pattern
> 
> image_map:
>  Â  http://wiki.povray.org/content/Reference:Image_Map
> 
> material_map:
>    
> http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps
> 
> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from 
> 3.7 onward it is everywhere optional.Â  When specified, this is the file 
> type POV-Ray will try and read no matter the filename given or the 
> output file type.
> 
> Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
> except for height_fields where it is "filename".Â  I think "filename" is 
> best because that string needs to be the filename POV-Ray looks to read 
> no matter format.
> 
> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray 
> will first look for any known extension in the "filename" string.Â  If 
> found, that extension is the image format POV-Ray will try and read.
> 
> Where the filename has no recognizable extension and BITMAP_TYPE | 
> HF_TYPE has not been specified, POV-Ray will try and read the "filename" 
> as whatever the current output image format is. Only the image_map 
> documentation mentions this latter behavior.
> 
> There is too in some documentation - material_map for example - this note:
> 
> "Note: Earlier versions of POV-Ray allowed some modifiers before the 
> BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
> described here."
> 
> which probably we can drop. At least for the modifiers I tried before 
> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

i'll follow up when i have more than a few moments ... which hasn't been 
very often lately

[Jim Holsenback] Re: image_pattern docs have a wrong sub-link [3017 days 1 hour and 51 minutes ago]

Mon, 8 Jan 2018 11:19:29 GMT

On 1/6/2018 7:20 PM, Kenneth wrote:
> In 3.6.2.4.2 Image Pattern, it says...
> 
> "Note: This pattern uses an image to get the gray values. If you want exactly
> the same possibilities but need to get gray values from a pigment, you can use
> the  --pigment_pattern--."
> 
> That pigment_pattern link is incorrect; it leads to 3.6.1.1.3 Pigment Map
> instead. The correct link should be  3.6.2.1.19 Pigment Pattern.
> 
> 
> 

this was a poorly formed /multi-link/ that i changed to a /single/ link 
that goes to the proper place now

[Kenneth] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3017 days 5 hours and 1 minute ago]

Mon, 8 Jan 2018 08:10:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray
> will first look for any known extension in the "filename" string.  If
> found, that extension is the image format POV-Ray will try and read.

I didn't know this. (I've never left out the file type, so I never noticed it.)
>
> Where the filename has no recognizable extension and BITMAP_TYPE |
> HF_TYPE has not been specified, POV-Ray will try and read the "filename"
> as whatever the current output image format is. Only the image_map
> documentation mentions this latter behavior.

The only problem I could imagine is if two files have the same name but
different file extensions. I've actually done this with some image files, but
just as tests (.png vs. jpeg versions, for example.) In which case, I suppose
the jpeg file would be chosen... alphabetically? My own opinion is that, by
leaving out any mention of BITMAP_TYPE or HF_TYPE in the docs, new users might
*possibly* run into a problem due to leaving out the file extension-- and not
know why. (I honestly can't think of a problematic file-type example-- other
than the one Clipka mentioned-- but who knows?)

I can also imagine that, in the 'new' scenario, new users who see an 'old' scene
file-- one with "my_image.jpg" in it, for example-- may scratch their heads
about why the file type was included like that-- when the docs no longer mention
it.

[Just playing 'Devil's advocate' here.]

[clipka] Re: BITMAP_TYPE and HF_TYPE documentation versus... [3017 days 17 hours and 49 minutes ago]

Sun, 7 Jan 2018 19:21:32 GMT

Am 07.01.2018 um 18:38 schrieb William F Pokorny:

> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from
> 3.7 onward it is everywhere optional.Â  When specified, this is the file
> type POV-Ray will try and read no matter the filename given or the
> output file type.

Both bitmap-based patterns and hight fields do indeed use the same code
to parse, and have essentially the same behaviour with respect to the
~_TYPE field (the difference being that height fields don't accept IFF
files, for reasons that are beyond me, while accepting POT files).

> "Note: Earlier versions of POV-Ray allowed some modifiers before the
> BITMAP_TYPE but that syntax is being phased out in favor of the syntax
> described here."
> 
> which probably we can drop. At least for the modifiers I tried before
> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

POV-Ray 3.7 and 3.8 still allow the BITMAP_TYPE field (but not the
HF_TYPE field) to be preceded by an arbirtary number of vectors or
numerical values; according to the warning that this will produce, this
was an old syntax for specifying the map_type, as well as apparently the
image map's orientation in space.

[William F Pokorny] BITMAP_TYPE and HF_TYPE documentation versus fun... [3017 days 19 hours and 32 minutes ago]

Sun, 7 Jan 2018 17:38:49 GMT

The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
image_pattern and material_map. HF_TYPE is used for height_fields. Over 
time I think the documentation has gotten somewhat scrambled with 
respect to current functionality.

bump_map:
   http://wiki.povray.org/content/Reference:Bump_Map

height_field:
http://wiki.povray.org/content/Reference:Height_Field

image_pattern:
   http://wiki.povray.org/content/Reference:Image_Pattern

image_map:
   http://wiki.povray.org/content/Reference:Image_Map

material_map:
   http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps

We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from 
3.7 onward it is everywhere optional.  When specified, this is the file 
type POV-Ray will try and read no matter the filename given or the 
output file type.

Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
except for height_fields where it is "filename".  I think "filename" is 
best because that string needs to be the filename POV-Ray looks to read 
no matter format.

If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray 
will first look for any known extension in the "filename" string.  If 
found, that extension is the image format POV-Ray will try and read.

Where the filename has no recognizable extension and BITMAP_TYPE | 
HF_TYPE has not been specified, POV-Ray will try and read the "filename" 
as whatever the current output image format is. Only the image_map 
documentation mentions this latter behavior.

There is too in some documentation - material_map for example - this note:

"Note: Earlier versions of POV-Ray allowed some modifiers before the 
BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
described here."

which probably we can drop. At least for the modifiers I tried before 
BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

Bill P.

[Kenneth] image_pattern docs have a wrong sub-link [3018 days 12 hours and 46 minutes ago]

Sun, 7 Jan 2018 00:25:00 GMT

In 3.6.2.4.2 Image Pattern, it says...

"Note: This pattern uses an image to get the gray values. If you want exactly
the same possibilities but need to get gray values from a pigment, you can use
the  --pigment_pattern--."

That pigment_pattern link is incorrect; it leads to 3.6.1.1.3 Pigment Map
instead. The correct link should be  3.6.2.1.19 Pigment Pattern.

[dick balaska] Insert Menu - needs lemon [3033 days 14 hours ago]

Fri, 22 Dec 2017 23:10:29 GMT

I watched lemon.cpp go by was thinking, it needs an Insert Menu entry, 
probably next to "ovus".

(I have been having fun creating random shapes and coloring with random 
textures from the Insert Menu. :) )

--
dik

[Kenneth] suggestion-- FOG files in a separate folder [3046 days 15 hours and 51 minutes ago]

Sat, 9 Dec 2017 21:20:00 GMT

This post is possibly not in the correct newsgroup thread, but I thought I would
give it a shot anyway...

The various FOG demo files in the POV-Ray install directory are currently spread
over two locations: scenes/interior and scenes/advanced. I would suggest that
they be combined into a single 'fog' folder -- like scenes/fog.  (Most are
currently in scenes/interior, but fog itself doesn't actually use SDL's
'interior' parameters, so the files seem out of place there anyway.)

The files are:
fog_f
fog_ft
fog_std
fog_layr
fog_lyr2
nu_fog2

mist

[clipka] Re: User:clipka assumed_gamma [3064 days 22 hours and 26 minutes ago]

Tue, 21 Nov 2017 14:44:48 GMT

Am 21.11.2017 um 08:21 schrieb Kenneth:

> The *only* small addition I can think of that might be useful would be to
> mention that most image-viewer apps-- even modern ones-- may not be showing the
> *actual* embedded gamma of a PNG image. (I'm thinking of our discussions re:
> I've's IC/Lilysoft app, which *does* show the proper embedded gamma, especially
> when that gamma is wrong.) I would imagine that many POV-Ray users might jump to
> the opposite conclusion (uh, like I did)-- that most apps are 'correct' and that
> IC (or some other likewise-correct app) is actually at fault when a PNG's
> embedded gamma is plain wrong.

I already added a hint about this in
http://wiki.povray.org/content/User:Clipka/Gamma#Getting_The_Output_Image_File_Right:

"The PNG file format (+FN) provides a means to inform reading
applications (e.g. file viewers) about the encoding gamma used, so
software may display the output image virtually identical regardless of
the encoding gamma you choose; however, this mechanism seems to be
falling out of favour."

Not the most explicit mention of that issue, I concede, but right now my
focus is on other stuff, so I'll leave it as is for now.

[Kenneth] Re: User:clipka assumed_gamma [3065 days 5 hours and 46 minutes ago]

Tue, 21 Nov 2017 07:25:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 21.11.2017 um 01:58 schrieb clipka:
> > Am 21.11.2017 um 01:47 schrieb Kenneth:
> >
> >> Something else I noticed...
> >
> > .... was already outdated by the time you pressed the "send" button ;)
>
> (Your post, that is. The Wiki article was /no longer/ outdated by that
> time ;))

So I see!! Hey, that's a good magic trick ;-)

Thanks for taking the time to write such an understandable and all-inclusive
gamma   primer for POV-Ray.

The *only* small addition I can think of that might be useful would be to
mention that most image-viewer apps-- even modern ones-- may not be showing the
*actual* embedded gamma of a PNG image. (I'm thinking of our discussions re:
I've's IC/Lilysoft app, which *does* show the proper embedded gamma, especially
when that gamma is wrong.) I would imagine that many POV-Ray users might jump to
the opposite conclusion (uh, like I did)-- that most apps are 'correct' and that
IC (or some other likewise-correct app) is actually at fault when a PNG's
embedded gamma is plain wrong.

I admit that this is probably a 'special case' scenario, one that most users
would almost never run into. But as a general note about PNG and the current
state of modern viewing apps, it seems appropriate.

[clipka] Re: User:clipka assumed_gamma [3065 days 12 hours and 6 minutes ago]

Tue, 21 Nov 2017 01:05:08 GMT

Am 21.11.2017 um 01:58 schrieb clipka:
> Am 21.11.2017 um 01:47 schrieb Kenneth:
> 
>> Something else I noticed...
> 
> .... was already outdated by the time you pressed the "send" button ;)

(Your post, that is. The Wiki article was /no longer/ outdated by that
time ;))

[clipka] Re: User:clipka assumed_gamma [3065 days 12 hours and 12 minutes ago]

Tue, 21 Nov 2017 00:58:28 GMT

Am 21.11.2017 um 01:47 schrieb Kenneth:

> Something else I noticed...

... was already outdated by the time you pressed the "send" button ;)

[Kenneth] Re: User:clipka assumed_gamma [3065 days 12 hours and 21 minutes ago]

Tue, 21 Nov 2017 00:50:00 GMT

I hadn't seen that otherwise-excellent page before, but I agree about the
strange "Remove assumed_gamma" statement. I have two theories about this: 1) The
statement may be outdated, from a time before v3.7x became more 'astute' about
handling legacy scenes. 2) Possibly it's CORRECT (?)-- maybe older v3.6 scenes
ARE just so out-of-whack re: 3.7x that *any* assumed_gamma would be wrong. But
that causes the 'no assumed_gamma' error, so *something's* not correct there.

Mention is made that older scenes will probably require lots of work of various
kinds anyway, to bring them fully up to date. That being the case, it would seem
logical to start with assumed_gamma 1.0 as the first 'fix.'

Something else I noticed...

-----
'Gamma Settings:'
 POV-Ray's gamma handling is governed by the following parameters:

 The 'gamma' scene file keyword applied to color values, which forces POV-Ray to
apply gamma decoding to individual colors.
-----
(No mention is made  of using 3.7x's 'srgb' colors-- as of version
3.7.0.beta.41-- instead of adding the 'gamma' keyword)

And in...

-----
'Getting Individual Colors Right:'
If you frequently pick colors, or feel more at home with defining colors by
pixel values rather than physical brightness levels, you can use the gamma
keyword to have POV-Ray do the computations automatically for you, e.g.:

#local MyColor = color rgb <255,128,0>/255 gamma 2.2;

This syntax also allows for using the sRGB transfer function; as the sRGB color
space has become quite widespread through the influence of the World Wide Web,
where it is the official standard, it is probably an even better bet than a
power-law function with a gamma of 2.2:

#local MyColor = color rgb <255,128,0>/255 gamma srgb;
-----

(These examples likewise don't mention 3.7x 's 'srgb' colors, so should another
example be included? Like so...)

#local MyColor = color srgb <255,128,0>/255 ; // As of version 3.7.0.beta.41

[dick balaska] Re: User:clipka assumed_gamma [3065 days 12 hours and 49 minutes ago]

Tue, 21 Nov 2017 00:22:00 GMT

Am 11/20/2017 06:12 PM, also sprach clipka:

 > carries a note saying "Under Construction"

With a little work, I think you could get that in an even smaller font. ;)

> I'm a bit surprised you didn't spot more errors ;)
> 

Well I didn't actually *read* it.
I was trying to shut up the warning, couldn't remember the exact syntax, 
and thought it might be faster to google "povray assumed_gamma" than 
look at one of my own source files. ;)

But nowhere did you actually print
global_settings{assumed_gamma 1.0}
:)

-- 
dik

[clipka] Re: User:clipka assumed_gamma [3065 days 13 hours and 59 minutes ago]

Mon, 20 Nov 2017 23:12:05 GMT

Am 20.11.2017 um 21:30 schrieb dick balaska:
> Not an inbuilt, per se, but:
> 
> The bottom of this page
> http://wiki.povray.org/content/User:Clipka/Gamma
> says
> " Change #version to 3.7.
> Remove the assumed_gamma statement. "
> 
> When I do that, povray 3.7.2-alpha (github/master) says
> " assumed_gamma not specified in this POV-Ray 3.7 or later
> Â scene. Future versions of POV-Ray may consider this a fatal error. To
> avoid
> Â this warning, explicitly specify 'assumed_gamma 1.0' in the
> global_settings
> Â section."
> 
> These statements conflict, yes?

Um... er...

... well, it /does/ work (despite the warnings), doesn't it, and
besides, the section carries a note saying "Under Construction"... I was
just about to...

... ah, dang it - you got me there.

The section was written at a time before modern gamma handling was truly
finalized. I'm a bit surprised you didn't spot more errors ;)

[dick balaska] User:clipka assumed_gamma [3065 days 16 hours and 40 minutes ago]

Mon, 20 Nov 2017 20:30:37 GMT

Not an inbuilt, per se, but:

The bottom of this page
http://wiki.povray.org/content/User:Clipka/Gamma
says
" Change #version to 3.7.
Remove the assumed_gamma statement. "

When I do that, povray 3.7.2-alpha (github/master) says
" assumed_gamma not specified in this POV-Ray 3.7 or later
  scene. Future versions of POV-Ray may consider this a fatal error. To 
avoid
  this warning, explicitly specify 'assumed_gamma 1.0' in the 
global_settings
  section."

These statements conflict, yes?
-- 
dik

[Kenneth] Re: PIGMENT documentation-- a minor clarification [3072 days 20 hours and 56 minutes ago]

Mon, 13 Nov 2017 16:15:01 GMT

Jim Holsenback <spa### [at] nothanksnet> wrote:
> Kenneth wrote...
> > (It's also in the online wiki, in "Tutorial Section
> > 3.3", under "Advanced Texture Options / Pigments"...
> >
> > http://wiki.povray.org/content
> > /Documentation:Tutorial_Section_3.3#Gamma_in_Legacy_Scenes
>
> huh?!?
>

Sorry; when I came to the 'Tutorial 3.3' section looking for 'Pigments', I must
have taken a detour into 'Gamma In Legacy Scenes' first (before reading further
down about 'Pigments') and posted the gamma link instead. Yeah, *I* thought the
link looked odd too!

>
> http://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Pigments

Looks good. Many thanks! (This little nit-pick has actually been on my mind for
a l*o*n*g time.)

[Jim Holsenback] Re: PIGMENT documentation-- a minor clarification [3073 days 11 hours and 30 minutes ago]

Mon, 13 Nov 2017 01:40:26 GMT

On 11/12/2017 2:41 PM, Kenneth wrote:
> I have a small nit-pick about the in-built documentation at "2.3.5.1 Pigments"
> within the first paragraph. (It's also in the online wiki, in "Tutorial Section
> 3.3", under "Advanced Texture Options / Pigments"...

that's because they are one in the same ...

> 
>
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Gamma_in_Legacy_Scenes

huh?!?

> 
> Both places say this:
> "Pigments can also be layered one on top of the next so long as the uppermost
> layers are at least partially transparent so the ones beneath can show through."

only in one place on that page ...

> I would suggest a simple addition to the end of the documentation's sentence,
> maybe in parentheses: "See "Using Transparent Pigments and Layered Textures"
> below."  That should remove any mystery.

http://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Pigments

[Kenneth] PIGMENT documentation-- a minor clarification [3073 days 17 hours and 26 minutes ago]

Sun, 12 Nov 2017 19:45:00 GMT

I have a small nit-pick about the in-built documentation at "2.3.5.1 Pigments"
within the first paragraph. (It's also in the online wiki, in "Tutorial Section
3.3", under "Advanced Texture Options / Pigments"...

http://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Gamma_in_Legacy_Scenes

Both places say this:
"Pigments can also be layered one on top of the next so long as the uppermost
layers are at least partially transparent so the ones beneath can show through."

As this is mentioned as a 'general' statement in the very first paragraph, and
before any qualifications are given, a naive or new-user might naturally assume
that the following construct is a nice way to get, for example,  a sort of
color-filtered bozo effect.(I'm using specific pigments to clarify the point)...

texture{
pigment{bozo}
pigment {rgbt <.2,.5,.7,.5>
......

But that doesn't work-- the second pigment completely overrides the first, which
could be a frustrating surprise-- because adding pigments together this way is
not what is really meant by the doc's initial description *as it stands*. (Only
later in the docs is the pigment_map introduced, and/or multiple textures, which
are the correct methods of using/overlaying multiple pigments.) BTW, I was
tripped up by this too, when I first started using POV-Ray.

I would suggest a simple addition to the end of the documentation's sentence,
maybe in parentheses: "See "Using Transparent Pigments and Layered Textures"
below."  That should remove any mystery.

[Bald Eagle] Polynomial and isosurface graphics [3091 days 20 hours and 16 minutes ago]

Wed, 25 Oct 2017 16:55:03 GMT

So, I just got done working out a polynomial object, and also tested out the
original equation as a function in an isosurface.

While doing some debugging and test renders using the output of my spreadsheet,
I was looking through the documentation to match the pigment, background,
light-angle, and overall look of these shapes, and nopticed that they seem to be
"backwards" (rotated 180 deg, or pi radians).

The X arrow points to the left, and the Z arrow points away from the camera.

I just figured I'd point this out, since this might lead to unintended confusion
for a new-user.

Also, with respect to visually misleading or confusing lighting /; shadows, etc.
:
http://wiki.povray.org/content/File:TutImgIso_16.png
has always been problematic for me to "see" properly.

My mind initially wants to take the shadow of the interior of the right part of
the cylinder, and have it be the end-cap of a cylinder that sits in that vee and
extends backwards at an angle - the lit portion behind the shadow looks like
it's the body of a solid cylinder with a shadowed end-cap.

Perhaps if it were rotated a little or lit differently, it would "look correct"
(to my brain).  Since it's an isosurface and not an actual difference, I would
assume that using an interior_texture wouldn't work, and there's no actual
"differencing shape" to apply a contrsting color to.

[Kenneth] Re: broken web link in '3.2.8.6 BSP Bounding' se... [3116 days 4 hours and 1 minute ago]

Sun, 1 Oct 2017 09:10:00 GMT

Jim Holsenback <spa### [at] nothanksnet> wrote:

>
> i was doing some 3.8 updates and was able to find the article ...
> changed the link here:
>
> http://wiki.povray.org/content/Reference:Tracing_Options#BSP_Bounding
>

Excellent detective work! Much appreciated.

[Jim Holsenback] Re: broken web link in '3.2.8.6 BSP Bounding' se... [3116 days 13 hours and 20 minutes ago]

Sat, 30 Sep 2017 23:51:04 GMT

On 9/26/2017 3:12 PM, Kenneth wrote:
> I just came across a broken web link in the docs, pertaining to BSP bounding
> (I'm using v3.7.1 beta 9)
> 
> In the section  3.2.8.6 BSP Bounding,   the link is in this sentence...
> 
> "For an explanation of what the values mean you may refer to Ray Tracing News
> Â»article by Eric Haines."
> 
> I found Haines's current webpage at
> http://erich.realtimerendering.com/
> 
> .... then the link there to the archived 'Ray Tracing News' stuff at
> http://www.realtimerendering.com/resources/RTNews/html/
> 
> But I don't know which of those many articles is the appropriate one.
> 
> 
i was doing some 3.8 updates and was able to find the article ... 
changed the link here:

http://wiki.povray.org/content/Reference:Tracing_Options#BSP_Bounding

thanks!

[Kenneth] broken web link in '3.2.8.6 BSP Bounding' section [3120 days 17 hours and 56 minutes ago]

Tue, 26 Sep 2017 19:15:01 GMT

I just came across a broken web link in the docs, pertaining to BSP bounding
(I'm using v3.7.1 beta 9)

In the section  3.2.8.6 BSP Bounding,   the link is in this sentence...

"For an explanation of what the values mean you may refer to Ray Tracing News
»article by Eric Haines."

I found Haines's current webpage at
http://erich.realtimerendering.com/

.... then the link there to the archived 'Ray Tracing News' stuff at
http://www.realtimerendering.com/resources/RTNews/html/

But I don't know which of those many articles is the appropriate one.

[Jim Holsenback] Re: adj_range2() function-- question [3183 days 2 hours and 21 minutes ago]

Wed, 26 Jul 2017 10:49:24 GMT

On 7/24/2017 8:32 PM, Kenneth wrote:
> In   3.8.1.1.13.1 Float functions and macros,   in the in-built documentation,
> it has this:
> 
> "adj_range2(V, InMin, InMax, OutMin, OutMax)    Like f_range(), but adjusts
> input values in the range [InMin, InMax] to the range [OutMin, OutMax]."
> 
> But there's no f_range() in POV-Ray, that I can find. Is that an old,
> no-longer-included function?
> 
> OR, is it meant to refer to the function directly above it in the docs,
> 
> adj_range(V, Min, Max)
> 
> ?
> 
> This latter possibility seems to be the more logical one, IMO.

yeah i think it's a typo as well ... fixed
http://wiki.povray.org/content/Reference:Math.inc#Float_functions_and_macros

[Kenneth] adj_range2() function-- question [3184 days 12 hours and 36 minutes ago]

Tue, 25 Jul 2017 00:35:01 GMT

In   3.8.1.1.13.1 Float functions and macros,   in the in-built documentation,
it has this:

"adj_range2(V, InMin, InMax, OutMin, OutMax)    Like f_range(), but adjusts
input values in the range [InMin, InMax] to the range [OutMin, OutMax]."

But there's no f_range() in POV-Ray, that I can find. Is that an old,
no-longer-included function?

OR, is it meant to refer to the function directly above it in the docs,

adj_range(V, Min, Max)

?

This latter possibility seems to be the more logical one, IMO.

[William F Pokorny] Re: github #304. Inconsistent camera documentati... [3202 days 17 hours and 34 minutes ago]

Thu, 6 Jul 2017 19:36:32 GMT

On 07/06/2017 02:55 PM, clipka wrote:
> Am 06.07.2017 um 18:31 schrieb William F Pokorny:
> 
>> Anyone know why the right vector perspective camera default is set to a
>> hard coded 1.33 and not 4.0/3.0? Compatibility with old TV standards or
>> something?
> 
> My guess is that it simply was deemed precise enough back in the Amiga
> days (320/1.33 = 240 plus change).
> 
> The quest for backward compatibility presumably did the rest.
> 
Thanks. The github user who recently noticed this, ubuntuslave, posted a 
link to the following newsgroup thread:

http://news.povray.org/povray.beta-test/thread/%3C3### [at] gmxde%3E/

from 2001. I agree with Warp's post in that old thread recommending a 
change to 4.0/3.0 as the default. Any potential compatibility with past 
scenes can be addressed by hard coding a right vector to the current 
default value of 1.33.

The documentation update would then be making the default ratio 4/3 
everywhere.

Today there is a mix of defaults listed. Where all the camera defaults 
listed 1.33 is used. Below when talking about Up and Right vectors the 
default is specified as 4/3. In the Aspect ratio section it is 
right<1.33,0,0> but then claims a resulting aspect ratio of "4 to 3." 
when it is really 3.99 to 3.

Bill P.

[clipka] Re: github #304. Inconsistent camera documentati... [3202 days 18 hours and 15 minutes ago]

Thu, 6 Jul 2017 18:55:21 GMT

Am 06.07.2017 um 18:31 schrieb William F Pokorny:

> Anyone know why the right vector perspective camera default is set to a
> hard coded 1.33 and not 4.0/3.0? Compatibility with old TV standards or
> something?

My guess is that it simply was deemed precise enough back in the Amiga
days (320/1.33 = 240 plus change).

The quest for backward compatibility presumably did the rest.

[William F Pokorny] github #304. Inconsistent camera documentation g... [3202 days 20 hours and 39 minutes ago]

Thu, 6 Jul 2017 16:31:16 GMT

Please see github issue:

https://github.com/POV-Ray/povray/issues/304

Poster has a point about the documentation inconsistency I think.

Anyone know why the right vector perspective camera default is set to a 
hard coded 1.33 and not 4.0/3.0? Compatibility with old TV standards or 
something?

Bill P.

[Jim Holsenback] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days and 29 minutes ago]

Sat, 10 Jun 2017 12:42:04 GMT

On 6/9/2017 12:19 PM, clipka wrote:
> Am 09.06.2017 um 14:41 schrieb Jim Holsenback:
>> On 6/9/2017 8:15 AM, Jim Holsenback wrote:
>>> ... they didn't make it into the docs most likely due to a foo
>>> somewhere with regex pattern matching in WikiDocGen. I'll have a look
>>
>> i take it back ... a quick look on the wiki and i think it's the markup
>> concerning < and > that appear (and is missing in one place ... the box
>> declaration) where > and < should have been used in the predefined
>> text blocks that encloses the examples. this weekend i'll make some
>> edits and test my theory.
> 
> I concur.

confirmed

> the help file viewer apparently misinterprets it as a (malformed) HTML
> tag. The text is actually in the help file, but it's not displayed.

same deal with the nix and mac versions ... i turned on debugging and 
ran WikiDocGen before making the edits on the wiki and discovered a few 
things that i've had to mark as fix me. basically i need to test <pre> 
blocks rather than JUST keep reading until i find </pre> ... btw: i 
looked at the history on the wiki and i guess a mea culpa is in order 
because it looks like i'm the one who busted that passage. check your 
email ... i've posted an update to include in the next release

[clipka] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days 17 hours and 10 minutes ago]

Fri, 9 Jun 2017 20:00:47 GMT

Am 09.06.2017 um 19:56 schrieb Kenneth:

> (A little side note: I can actually open the help file--in its entirety-- in
> Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
> doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
> robust enough to open and display just about any 'programming language.' But
> then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
> an understatement!!) ;-)

The help file is a binary file.

Most "compiled" stuff is binary files.

A binary file may contain arbitrary sequences of arbitrary bytes, from 0
to 255 (hexadecimal 00 to FF).

Most notably, a binary file may contain byte value 0 (hexadecimal 00)
anywhere in the file.


The vast majority of programming languages is based on plain ASCII text
files.

A canonical ASCII text file may contain only bytes that represent
_printable_ ASCII characters (32 to 126 = hexadecimal 20 to 7E), as well
as a few select control characters (horizontal tabulator, line feed,
carriage return, end of file = 9, 10, 13, 26 = hexadecimal 09, 0A, 0D, 1A).

Most notably, an ASCII text file must _never_ contain byte value 0
(hexadecimal 00) _anywhere_ in the file.


When a program handles text, it needs to keep track of where the text
ends. One obvious way to do this is to store the length in a separate
numerical data field, but this has the drawback of potentially wasting a
lot of memory if you're working with lots of small yet occasionally
large pieces of text: Unless you want to restrict yourself to at most
255 characters per piece of text, you need to set aside at least 2 extra
bytes per piece of text for that length data field; and if your text
pieces may potentially exceed 65535 characters, you'll need 4 extra
bytes for the length data field.

A more compact scheme is to not store the length of the text, but rather
mark its end with a special pseudo-character; this only requires 1 extra
byte per piece of text (presuming the text uses byte encoding such as
ASCII, or byte-based variable-length encoding such as UTF8). Commonly,
the byte value hex 00 is used as this end-of-string marker, in which
case this scheme is referred to as "null-terminated strings".

Virtually all text editors can cope with files containing arbitrary
characters from the range 1 to 255 (hexadecimal 01 to FF), at least to
some degree; but text editors that happen to use null-terminated strings
to store the lines of text may screw up on any files containing the byte
value hex 00.


The text editor module in POV-Ray for Windows presumably suffers from
this null-terminated-string ailment, while the Windows Wordpad
apparently does not. Whether it is because Wordpad does not use
null-terminated strings, or because it immediately replaces any hex 00
byte value with a placeholder upon loading, I can't tell.

[Kenneth] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days 18 hours and 56 minutes ago]

Fri, 9 Jun 2017 18:15:02 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> I really liked the following excerpt from Graphics Gems 3:
>
> https://doc.lagout.org/Others/Game%20Development/Programming/Graphics%20Gems%203.pdf
>
> Since the first volume of Graphics Gems was published, I have spoken to many
> readers
> and discovered that these books have helped people learn graphics by starting
> with
> working codes and just exploring intuitively....

Yes, that's an excellent 'philosophy', about *anything* in life, actually. I
love to experiment, with anything and everything; it's a wonderful way to learn
new stuff. But as you (and the author) say, there needs to be a 'germ' of
understanding, to begin with. Sometimes that little germ is missing :-(

[Kenneth] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days 19 hours and 11 minutes ago]

Fri, 9 Jun 2017 18:00:07 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> In most pre-formatted blocks, "<" and ">" are represented as "<" and
> ">", respectively, in both the original Wiki source text as well as
> the compiled help file for POV-Ray for Windows; not so in the case of
> the max_extent example: There, literal "<" and ">" are used in the Wiki
> source, and also exported as such to the compiled help file.
>
> The Wiki seems to be robust enough to display the text as intended, but
> the help file viewer apparently misinterprets it as a (malformed) HTML
> tag. The text is actually in the help file, but it's not displayed.

If the included help file was 'just' HTML, I would fix it myself. But alas, it's
compiled :-(

(A little side note: I can actually open the help file--in its entirety-- in
Windoze Wordpad. The contents are meaningless of course, mostly symbols. But It
doesn't open likewise in POV-Ray-- just one little 'word.' I thought POV was
robust enough to open and display just about any 'programming language.' But
then again, I'm somewhat naive about 'compiled' languages ('somewhat'?? That's
an understatement!!) ;-)

[Kenneth] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days 19 hours and 26 minutes ago]

Fri, 9 Jun 2017 17:45:05 GMT

Jim Holsenback <spa### [at] nothanksnet> wrote:

>
> you are correct ... however look at
> http://wiki.povray.org/content/Reference:Vector_Expressions#Functions
> and the example is complete.

Ah yes, thanks. I didn't think to look on-line, as I was running the latest
POV-Ray beta anyway, with the 'latest' help file.

Wow, I was woefully wrong about
            #declare MatteNormalizationScale = Resolution;

:-O

[clipka] Re: 3.7xx: max_extent (re: image resolution) is ... [3229 days 20 hours and 51 minutes ago]

Fri, 9 Jun 2017 16:19:27 GMT

Am 09.06.2017 um 14:41 schrieb Jim Holsenback:
> On 6/9/2017 8:15 AM, Jim Holsenback wrote:
>> ... they didn't make it into the docs most likely due to a foo
>> somewhere with regex pattern matching in WikiDocGen. I'll have a look
> 
> i take it back ... a quick look on the wiki and i think it's the markup
> concerning < and > that appear (and is missing in one place ... the box
> declaration) where > and < should have been used in the predefined
> text blocks that encloses the examples. this weekend i'll make some
> edits and test my theory.

I concur.

In most pre-formatted blocks, "<" and ">" are represented as "<" and
">", respectively, in both the original Wiki source text as well as
the compiled help file for POV-Ray for Windows; not so in the case of
the max_extent example: There, literal "<" and ">" are used in the Wiki
source, and also exported as such to the compiled help file.

The Wiki seems to be robust enough to display the text as intended, but
the help file viewer apparently misinterprets it as a (malformed) HTML
tag. The text is actually in the help file, but it's not displayed.

[Jim Holsenback] Re: 3.7xx: max_extent (re: image resolution) is ... [3230 days and 29 minutes ago]

Fri, 9 Jun 2017 12:41:22 GMT

On 6/9/2017 8:15 AM, Jim Holsenback wrote:
> ... they didn't make it into the docs most likely due to a foo somewhere 
> with regex pattern matching in WikiDocGen. I'll have a look

i take it back ... a quick look on the wiki and i think it's the markup 
concerning < and > that appear (and is missing in one place ... the box 
declaration) where > and < should have been used in the predefined 
text blocks that encloses the examples. this weekend i'll make some 
edits and test my theory.

[Jim Holsenback] Re: 3.7xx: max_extent (re: image resolution) is ... [3230 days and 55 minutes ago]

Fri, 9 Jun 2017 12:16:06 GMT

On 6/8/2017 1:26 PM, Kenneth wrote:
> (running 3.7.1 beta 8)
> In the in-built documentation "3.3.1.6.5 Functions"...
> 
> In the section "min_extent/max_extent', concerning the new 3.7xx feature of
> reading the pixel resolution of an image, the example given there seems to be
> missing something. Part of it is written like this...
> 
> ......
> #declare Resolution = max_extent ( MatteImage );
> #declare MatteNormalizationScale =
> ;

you are correct ... however look at 
http://wiki.povray.org/content/Reference:Vector_Expressions#Functions 
and the example is complete. Scroll down a bit further there is another 
example just after the "New" annotation regarding Df3NormalizationScale 
... they didn't make it into the docs most likely due to a foo somewhere 
with regex pattern matching in WikiDocGen. I'll have a look

[Bald Eagle] Re: 3.7xx: max_extent (re: image resolution) is ... [3230 days 17 hours and 46 minutes ago]

Thu, 8 Jun 2017 19:25:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Yep, *that* by itself makes sense; good idea. The docs still need some
> overhauling.

Yes, and I understand, from experience, how difficult a job it is to document
something, well, and keep it updated.

I think that having a few lines of working SDL to demonstrate how something
works is worth pages of documentation and dozens of (often redundant) forum
question and answer threads.

I really liked the following excerpt from Graphics Gems 3:

https://doc.lagout.org/Others/Game%20Development/Programming/Graphics%20Gems%203.pdf

Since the first volume of Graphics Gems was published, I have spoken to many
readers
and discovered that these books have helped people learn graphics by starting
with
working codes and just exploring intuitively. I didn’t expect people to play
with the codes
so freely, but I think I now see why this helps. It is often exciting to start
learning a new
medium by simply messing around in it, and understanding how it flows. My piano
teacher
encourages new students to begin by spending time playing freely at the
keyboard: keep a
few scales or chord progressions in mind, but otherwise explore the spaces of
melody,
harmony, and rhythm. When I started to learn new mediums in art classes, I often
spent
time simply playing with the medium: squishing clay into odd shapes or brushing
paint on
paper in free and unplanned motions. Of course one often moves on to develop
control
and technique in order to communicate one’s message better, hut much creativity
springs
from such uncontrolled and spirited play.
It is difficult for the novice to play at programming. There is little room for
simple
expression or error. A simple program does not communicate with the same range
and
strength as a masterfully simple line drawing or haunting melody. A programmer
cannot
hit a few wrong notes, or tolerate an undesired ripple in a line. If the syntax
isn’t right, the
program won’t compile; if the semantics aren’t right, the program won’t
do
anything
interesting. There are exceptions to the latter statement, but they are notable
because of
their rarity. If you’re going to write a program to accomplish a task,
you’ve
got to do some
things completely right, and everything else almost perfectly. That can be an
intimidating
realization particularly for the beginner: if a newly constructed program
doesn’t work, the
problem could be in a million places, anywhere from the architecture to data
structures,

algorithms, or coding errors. The chance to start with something that already
works
removes the barrier to exploration: your program already works. If you want to
change it,
you can, and you will discover which new ideas work and which ones don’t.

[Kenneth] Re: 3.7xx: max_extent (re: image resolution) is ... [3230 days 18 hours and 56 minutes ago]

Thu, 8 Jun 2017 18:15:05 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> Note that there are only  x and y non-zero-values to the max_extent, so that's
> what the addition of the vector in defining Resolution is for (to avoid warnings
> when using scale.
>

Yep, *that* by itself makes sense; good idea. The docs still need some
overhauling.

[Bald Eagle] Re: 3.7xx: max_extent (re: image resolution) is ... [3230 days 19 hours and 21 minutes ago]

Thu, 8 Jun 2017 17:50:06 GMT

Well, here's how I've been using it for the past several years:

//  Sized image Map - 1 unit thick box
#declare XSize = 40;
#declare ImageMap = pigment {image_map {jpeg "TestGear.jpg" once} };
#declare Resolution = max_extent (ImageMap) + <0, 0, 1>;


#declare ImageMappedBox =
 box {0, 1
  texture {
   pigment {ImageMap}
  }
  translate <-0.5, -0.5, -0.5>
  scale Resolution*(1/Resolution.x)*XSize
  //translate y*(Resolution.y / Resolution.x)*XSize/2
 }


Note that there are only  x and y non-zero-values to the max_extent, so that's
what the addition of the vector in defining Resolution is for (to avoid warnings
when using scale.

That last translation is to move the box from origin-centered to having it's
base at y=0.

[Kenneth] 3.7xx: max_extent (re: image resolution) is miss... [3230 days 19 hours and 41 minutes ago]

Thu, 8 Jun 2017 17:30:00 GMT

(running 3.7.1 beta 8)
In the in-built documentation "3.3.1.6.5 Functions"...

In the section "min_extent/max_extent', concerning the new 3.7xx feature of
reading the pixel resolution of an image, the example given there seems to be
missing something. Part of it is written like this...

......
#declare Resolution = max_extent ( MatteImage );
#declare MatteNormalizationScale =
;

There's nothing following   MatteNormalizationScale   except a semi-colon (which
naturally produces a fatal parse error, when I place an image_map pigment into
the preceeding max_extent). Should it instead be written as...

#declare MatteNormalizationScale = Resolution;

??

(Personally, I don't know, as I haven't tried using the feature yet.)

*However*, the remainder of that example says...

box { 0, <1,1,0.001 pigment { MatteImage }
scale MatteNormalizationScale // Fit matte to unit square
scale MatteSceneScale // Size matte for scene
}

....in which case,    MatteNormalizationScale = Resolution   would not seem to
make sense, as it does not "Fit matte to unit square ". (The matte image is
*already* fit to the unit square, by default.)

Some clarification(s) needed?

[Kenneth] Re: Output_File_Name -- missing double quotes in... [3289 days 15 hours and 56 minutes ago]

Mon, 10 Apr 2017 21:15:00 GMT

Alain <kua### [at] videotronca> wrote:

>
> Since 3.1g, probably sooner, it's possible to dirrect your image to any
> user specified folder.
> The use of quotes, single or double, is mandatorry whenever you have
> space anywhere in the path. It must be as old as the introduction of
> long file names, way back to 1995.
> Before that, spaces where not allowed at all, and the use of quotes was
> never needed.

I'm thinking more of 'new users' (or older users who don't know or remember the
'special case' of using double-quotes when there are spaces, vs. no
double-quotes when there are no spaces.) *Years* ago, when I first began adding
my own folder path(s) to the povray.ini file, I didn't know this rule (or where
to look for it in the docs), and could never figure out why my folder paths
worked sometimes but not at other times. I naturally assumed the answer would be
in the 'Output_File_Name' sections; but the only examples there are written
without double quotes-- simply because those examples don't happen to have any
spaces. ;-)

If I am any example of a 'typical' Windows user, I would assume that others like
me would not know to look in 'command line' references in the docs to find this
special rule-- one reason being that the Windows GUI version of POV-Ray doesn't
really *require* command-line input (i.e., the GUI menus-- and resolution .ini
file-- take care of most if not all of POV-Ray's functions, with the
command-line being a secondary consideration and rarely used.) Hence, no reason
to look *there* for the info. This is my main argument for adding the
special-rule info somewhere in the Output_File_Name section(s)... as that seems
a logical place for it to be. Or at least putting a link there to the proper
section(s) of the docs.

[clipka] Re: Output_File_Name -- missing double quotes in... [3290 days 1 hour and 9 minutes ago]

Mon, 10 Apr 2017 12:01:35 GMT

Am 10.04.2017 um 07:18 schrieb Mike Horvath:
> On 4/9/2017 10:55 PM, Alain wrote:
>> Since 3.1g, probably sooner, it's possible to dirrect your image to any
>> user specified folder.
>> The use of quotes, single or double, is mandatorry whenever you have
>> space anywhere in the path. It must be as old as the introduction of
>> long file names, way back to 1995.
>> Before that, spaces where not allowed at all, and the use of quotes was
>> never needed.
> 
> Is it also necessary to escape all backslashes in strings? I never could
> remember for sure.

I'd strongly recommend to use forward slashes in POV-Ray, even when
using the Windows version. POV-Ray for Windows is designed to fully
support them.

(Besides, modern Windows versions themselves are also designed to
support forward slashes; there are just a few niches, such as various
inbuilt commands of the "good" old command prompt, where there are some
caveats.)

[Mike Horvath] Re: Output_File_Name -- missing double quotes in... [3290 days 7 hours and 52 minutes ago]

Mon, 10 Apr 2017 05:18:35 GMT

On 4/9/2017 10:55 PM, Alain wrote:
> Since 3.1g, probably sooner, it's possible to dirrect your image to any
> user specified folder.
> The use of quotes, single or double, is mandatorry whenever you have
> space anywhere in the path. It must be as old as the introduction of
> long file names, way back to 1995.
> Before that, spaces where not allowed at all, and the use of quotes was
> never needed.

Is it also necessary to escape all backslashes in strings? I never could 
remember for sure.


Mike

[Alain] Re: Output_File_Name -- missing double quotes in... [3290 days 10 hours and 15 minutes ago]

Mon, 10 Apr 2017 02:55:21 GMT

Le 17-04-09 à 02:00, Thorsten Froehlich a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> I don't know if this is specific to the Windows platform, but there's a small
>> error in the v3.7.1 beta 5 documentation, as well as on the current wiki page at
>>
>> http://wiki.povray.org/content/Reference:File_Output_Options
>>
>>  re: Output_File_Name. I think the docs' errors have been there for awhile,
>> actually.
>>
>> In Windows, if I want to specify my own folder location for output renders, I
>> have to write it like this-- with double quotes at beginning and end--
>>
>> Output_File_Name="C:\Users\Computer\Documents\Kens POV-Ray rendered IMAGES\"
>>
>> The documentation doesn't mention those double quotes. Leaving them out causes a
>> (non-fatal) render error, but the image isn't written to a file (as far as I can
>> tell.)
>>
>> The Windows-specific included documentation doesn't mention this either, at
>> 1.4.7 The Render Window.
>
> It is not required as long as the name does not include spaces. This has been
> the case since 3.6 iirc. I am pretty sure it was documented somewhere in the
> command line reference section. If I had to guess, it would be in the
> introductory section of the command line reference...
>
>
>

Since 3.1g, probably sooner, it's possible to dirrect your image to any 
user specified folder.
The use of quotes, single or double, is mandatorry whenever you have 
space anywhere in the path. It must be as old as the introduction of 
long file names, way back to 1995.
Before that, spaces where not allowed at all, and the use of quotes was 
never needed.

[Kenneth] Re: Output_File_Name -- missing double quotes in... [3291 days 4 hours and 6 minutes ago]

Sun, 9 Apr 2017 09:05:00 GMT

Ah yes, you're both correct. I knew I had seen that information *somewhere*
during the past years. It has only been recently that I needed to look it up
again, while working with the 3.7.1 betas (which install a 'fresh' copy of the
povray.ini file; I needed to re-add my output folder location to it, as a
library path.) I assumed the double-quote info was in one or the other
'Output_File_Name' locations I mentioned, as that seemed a logical place to
look.

I would suggest adding a short note to 3.2.4.2 at least, mentioning this.

[omniverse] Re: Output_File_Name -- missing double quotes in... [3291 days 5 hours and 36 minutes ago]

Sun, 9 Apr 2017 07:35:00 GMT

"Thorsten Froehlich" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > I don't know if this is specific to the Windows platform, but there's a small
> > error in the v3.7.1 beta 5 documentation, as well as on the current wiki page at
> >
> > http://wiki.povray.org/content/Reference:File_Output_Options
> >
> >  re: Output_File_Name. I think the docs' errors have been there for awhile,
> > actually.
> >
> > In Windows, if I want to specify my own folder location for output renders, I
> > have to write it like this-- with double quotes at beginning and end--
> >
> > Output_File_Name="C:\Users\Computer\Documents\Kens POV-Ray rendered IMAGES\"
> >
> > The documentation doesn't mention those double quotes. Leaving them out causes a
> > (non-fatal) render error, but the image isn't written to a file (as far as I can
> > tell.)
> >
> > The Windows-specific included documentation doesn't mention this either, at
> > 1.4.7 The Render Window.
>
> It is not required as long as the name does not include spaces. This has been
> the case since 3.6 iirc. I am pretty sure it was documented somewhere in the
> command line reference section. If I had to guess, it would be in the
> introductory section of the command line reference...

I had to go looking for it but it is there. Can be found in section 2.2.8.2 at
very end. Here's that portion:

If a file or path contains blanks the whole file and path specification has to
be put in quotes. You may either use a double-quote or a single-quote, but you
have to use the same at the beginning and end. For example:
 +I"my file.pov"
 +I'my file.pov'
 Input_File="my file.pov"
 Input_File='my file.pov'

By using either single or double quotes it is possible to specify files whose
name or path contains either as part of the name. For example:
 +I"file's.pov"
 +I'my "big" file.pov'
 Input_File="file's.pov"
 Input_File='my "big" file.pov'


Might not be the most obvious place unless looking for it there, since this is
under the (POV-Ray for Windows help) POV-Ray Tutorial > Getting Started >
Setting POV-Ray Options > Using INI Files

Guess I just thought the quoting was mentioned in the Reference > Command-Line
and INI Options

Found another mention about quoting, end of section 1.3.2 Special Command-Line
Options and highlighted:

Note: When supplying a filename with spaces in it, you will need to enclose the
filename itself within quotes.

[Thorsten Froehlich] Re: Output_File_Name -- missing double quotes in... [3291 days 7 hours and 6 minutes ago]

Sun, 9 Apr 2017 06:05:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> I don't know if this is specific to the Windows platform, but there's a small
> error in the v3.7.1 beta 5 documentation, as well as on the current wiki page at
>
> http://wiki.povray.org/content/Reference:File_Output_Options
>
>  re: Output_File_Name. I think the docs' errors have been there for awhile,
> actually.
>
> In Windows, if I want to specify my own folder location for output renders, I
> have to write it like this-- with double quotes at beginning and end--
>
> Output_File_Name="C:\Users\Computer\Documents\Kens POV-Ray rendered IMAGES\"
>
> The documentation doesn't mention those double quotes. Leaving them out causes a
> (non-fatal) render error, but the image isn't written to a file (as far as I can
> tell.)
>
> The Windows-specific included documentation doesn't mention this either, at
> 1.4.7 The Render Window.

It is not required as long as the name does not include spaces. This has been
the case since 3.6 iirc. I am pretty sure it was documented somewhere in the
command line reference section. If I had to guess, it would be in the
introductory section of the command line reference...

[Kenneth] Re: Output_File_Name -- missing double quotes in... [3291 days 11 hours and 56 minutes ago]

Sun, 9 Apr 2017 01:15:01 GMT

Forgot to include this location as well (in POV-Ray's included documentation)--

3.2.4.2 Output File Name

[Kenneth] Output_File_Name -- missing double quotes in doc... [3291 days 12 hours and 1 minute ago]

Sun, 9 Apr 2017 01:10:01 GMT

I don't know if this is specific to the Windows platform, but there's a small
error in the v3.7.1 beta 5 documentation, as well as on the current wiki page at

http://wiki.povray.org/content/Reference:File_Output_Options

 re: Output_File_Name. I think the docs' errors have been there for awhile,
actually.

In Windows, if I want to specify my own folder location for output renders, I
have to write it like this-- with double quotes at beginning and end--

Output_File_Name="C:\Users\Computer\Documents\Kens POV-Ray rendered IMAGES\"

The documentation doesn't mention those double quotes. Leaving them out causes a
(non-fatal) render error, but the image isn't written to a file (as far as I can
tell.)

The Windows-specific included documentation doesn't mention this either, at
1.4.7 The Render Window.

[William F Pokorny] Re: Inconsistencies in how patterns are grouped ... [3300 days 14 hours and 46 minutes ago]

Thu, 30 Mar 2017 22:24:13 GMT

On 03/30/2017 08:53 AM, Jim Holsenback wrote:
> On 3/28/2017 10:11 AM, William F Pokorny wrote:
>> Some inconsistencies therein and I suggest the following changes in
>> where and how patterns are listed in the subsections :
>
> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
>
Much better, thanks!
Bill P.

[Jim Holsenback] Re: Inconsistencies in how patterns are grouped ... [3301 days and 17 minutes ago]

Thu, 30 Mar 2017 12:53:31 GMT

On 3/28/2017 10:11 AM, William F Pokorny wrote:
> Some inconsistencies therein and I suggest the following changes in
> where and how patterns are listed in the subsections :

http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

[William F Pokorny] Inconsistencies in how patterns are grouped by s... [3302 days 23 hours ago]

Tue, 28 Mar 2017 14:11:10 GMT

I happened to run across these sections today which are listed at the 
bottom of the page:

http://wiki.povray.org/content/Reference:Pattern

Some inconsistencies therein and I suggest the following changes in 
where and how patterns are listed in the subsections :

http://wiki.povray.org/content/Reference:General_Patterns
--------------------
agate
boxed
bozo
brick - Move to Discontinuous_Patterns
bumps
cubic
crackle - (note "solid keyword makes discontinuous")
cylindrical
density_file - Move to Special_Patterns
dents
facets  - Move to Discontinuous_Patterns
fractal
function
gradient
granite
hexagon - Remove. Already listed in Discontinuous_Patterns
leopard
marble
onion
pavement - Move to Discontinuous_Patterns
pigment_pattern - Move to Special_Patterns
planar
potential - Add as not today listed and new to 3.7.1
quilted
radial
ripples
spherical
spiral1
spiral2
spotted
square - Remove. Already listed in Discontinuous_Patterns
tiling - Move to Discontinuous_Patterns
waves
wood
wrinkles

http://wiki.povray.org/content/Reference:Discontinuous_Patterns
(Perhaps call these Discrete-Region Patterns?)
--------------------
cells
checker
crackle (note "when used with solid keyword")
hexagon
object
pavement - Move here from General
square
tiling - Move here from General
triangular

Add a note something like:
"Parts of the pavement and tiling patterns are discontinuous or clamped 
while other parts ramp."


http://wiki.povray.org/content/Reference:Normal-Dependent_Patterns
--------------------
aoi
facets  - Move here from general
slope

Need to strike the general sentence:
"As such, these patterns are suitable for object normals only."
for perhaps:
"The facets pattern can only be used in a normal statement."


http://wiki.povray.org/content/Reference:Special_Patterns
--------------------
average
density_file - Move here from General
image
pigment_pattern - Move here from General

Thanks.
Bill P.

[Mike Horvath] Color macro input ranges [3312 days 16 hours and 50 minutes ago]

Sat, 18 Mar 2017 20:20:25 GMT

In colors.inc, please say in the docs what the ranges for all the macro 
inputs are. For instance, the macro CHSL2RGB() inputs are in the ranges 
of 0-360, 0-1, and 0-1. Thanks.


Mike

[clipka] Re: #version [3322 days 11 hours and 40 minutes ago]

Thu, 9 Mar 2017 01:30:41 GMT

Am 08.03.2017 um 23:47 schrieb Mike Horvath:

> This article mentions what I would call screw cap conspiracy theorists.
> 
>
http://www.npr.org/sections/thesalt/2014/01/02/259128689/cork-versus-screw-cap-dont-judge-a-wine-by-how-its-sealed

Might I, at this point, suggest you move this discussion to
povray.off-topic?

Thanks.

[Mike Horvath] Re: #version [3322 days 14 hours and 23 minutes ago]

Wed, 8 Mar 2017 22:47:38 GMT

On 3/8/2017 12:40 PM, Le_Forgeron wrote:
> Le 08/03/2017 Ã  08:12, Mike Horvath a Ã©crit :
>> On 1/26/2017 10:26 AM, Alain wrote:
>>> Le 17-01-26 Ã  01:26, Mike Horvath a Ã©crit :
>>>> On 1/19/2017 8:09 PM, dick balaska wrote:
>>>>> Am 2017-01-19 16:47, also sprach dick balaska:
>>>>>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>>>>>>
>>>>>> "Naturally the default setting for this option is #version 3.5."
>>>>>> Should that not be 3.7?
>>>>>
>>>>> I see. It's more complicated than that. The default is 3.62.
>>>>>
>>>>
>>>> Old versions are always better. Like fine wine.
>>>>
>>>> Mike
>>>
>>> Not always. If the wine is to old, it tend to turn into vinegar, or
>>> worst.
>>
>> Which is why wine makers should use screw tops instead of corks. Screw
>> tops preserve their contents for longer.
>
> Excepted that wine should be allowed to breath, something a screw tops
> do not do and that corks do.
>
> Screw tops is for spirit strong beverage. Or beer.
>
> The corks must be kept wet, so the bottle should be stored horizontally
> and not vertically.
>


This article mentions what I would call screw cap conspiracy theorists.

http://www.npr.org/sections/thesalt/2014/01/02/259128689/cork-versus-screw-cap-dont-judge-a-wine-by-how-its-sealed


Mike

[Le Forgeron] Re: #version [3322 days 19 hours and 30 minutes ago]

Wed, 8 Mar 2017 17:40:40 GMT

Le 08/03/2017 Ã  08:12, Mike Horvath a Ã©crit :
> On 1/26/2017 10:26 AM, Alain wrote:
>> Le 17-01-26 Ã  01:26, Mike Horvath a Ã©crit :
>>> On 1/19/2017 8:09 PM, dick balaska wrote:
>>>> Am 2017-01-19 16:47, also sprach dick balaska:
>>>>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>>>>>
>>>>> "Naturally the default setting for this option is #version 3.5."
>>>>> Should that not be 3.7?
>>>>
>>>> I see. It's more complicated than that. The default is 3.62.
>>>>
>>>
>>> Old versions are always better. Like fine wine.
>>>
>>> Mike
>>
>> Not always. If the wine is to old, it tend to turn into vinegar, or
>> worst.
> 
> Which is why wine makers should use screw tops instead of corks. Screw
> tops preserve their contents for longer.

Excepted that wine should be allowed to breath, something a screw tops
do not do and that corks do.

Screw tops is for spirit strong beverage. Or beer.

The corks must be kept wet, so the bottle should be stored horizontally
and not vertically.

[Mike Horvath] Re: #version [3323 days 5 hours and 58 minutes ago]

Wed, 8 Mar 2017 07:12:18 GMT

On 1/26/2017 10:26 AM, Alain wrote:
> Le 17-01-26 Ã  01:26, Mike Horvath a Ã©crit :
>> On 1/19/2017 8:09 PM, dick balaska wrote:
>>> Am 2017-01-19 16:47, also sprach dick balaska:
>>>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>>>>
>>>> "Naturally the default setting for this option is #version 3.5."
>>>> Should that not be 3.7?
>>>
>>> I see. It's more complicated than that. The default is 3.62.
>>>
>>
>> Old versions are always better. Like fine wine.
>>
>> Mike
>
> Not always. If the wine is to old, it tend to turn into vinegar, or worst.

Which is why wine makers should use screw tops instead of corks. Screw 
tops preserve their contents for longer.

Mike

[William F Pokorny] 40 char limit indicated on normal page. [3334 days 21 hours and 19 minutes ago]

Fri, 24 Feb 2017 15:52:03 GMT

At the bottom of the page:

http://wiki.povray.org/content/Reference:Normal

we still have a note about the identifier being limited to 40 characters.

Thanks,
Bill P.

[William F Pokorny] threshold pop-up ref to potential pattern missing. [3338 days 22 hours and 19 minutes ago]

Mon, 20 Feb 2017 14:51:20 GMT

On the page:

http://wiki.povray.org/content/Reference:Keywords

the cursor, hover-over, pop-up sub-index for 'threshold' is missing a 
link to the potential pattern.

Bill P.

[William F Pokorny] 'POV-Team' is a trademarks as noted in other doc... [3342 days 22 hours and 26 minutes ago]

Thu, 16 Feb 2017 14:44:28 GMT

However POV-Team is not listed in our documentation's list of Trademarks 
at :

http://wiki.povray.org/content/Documentation:Windows_Section_1#Trademarks

The term is, for example, referenced elsewhere in the documentation as a 
trademark at:

http://wiki.povray.org/content/Documentation:Tutorial_Section_1

as well as elsewhere on the web site.

Bill P.

[Alain] Re: #version [3363 days 21 hours and 45 minutes ago]

Thu, 26 Jan 2017 15:26:10 GMT

Le 17-01-26 Ã  01:26, Mike Horvath a Ã©crit :
> On 1/19/2017 8:09 PM, dick balaska wrote:
>> Am 2017-01-19 16:47, also sprach dick balaska:
>>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>>>
>>> "Naturally the default setting for this option is #version 3.5."
>>> Should that not be 3.7?
>>
>> I see. It's more complicated than that. The default is 3.62.
>>
>
> Old versions are always better. Like fine wine.
>
> Mike

Not always. If the wine is to old, it tend to turn into vinegar, or worst.

[Mike Horvath] Re: #version [3364 days 6 hours and 44 minutes ago]

Thu, 26 Jan 2017 06:26:11 GMT

On 1/19/2017 8:09 PM, dick balaska wrote:
> Am 2017-01-19 16:47, also sprach dick balaska:
>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>>
>> "Naturally the default setting for this option is #version 3.5."
>> Should that not be 3.7?
>
> I see. It's more complicated than that. The default is 3.62.
>

Old versions are always better. Like fine wine.

Mike

[dick balaska] Re: #version [3370 days 12 hours and 1 minute ago]

Fri, 20 Jan 2017 01:09:52 GMT

Am 2017-01-19 16:47, also sprach dick balaska:
> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5
>
> "Naturally the default setting for this option is #version 3.5."
> Should that not be 3.7?

I see. It's more complicated than that. The default is 3.62.

-- 
dik

[dick balaska] #version [3370 days 15 hours and 24 minutes ago]

Thu, 19 Jan 2017 21:47:05 GMT

http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_5

"Naturally the default setting for this option is #version 3.5."
Should that not be 3.7?
-- 
dik

[Jaime Vives Piqueres] Re: Animation docs inaccurate [3399 days 2 hours and 21 minutes ago]

Thu, 22 Dec 2016 10:49:40 GMT

El 22/12/16 a las 08:55, Stephen escribiÃ³:
> Jaime might be using "clock" as a synonym for animation.
>
> I use frame subsets for animations and testing values too. I prefer
> using integers to fractional numbers in my calculations. It makes more
> sense to me as you can't render a frame that is not a whole number.
>

   Yes, I was using integer clock values too...

--
jaime

[Stephen] Re: Animation docs inaccurate [3399 days 5 hours and 15 minutes ago]

Thu, 22 Dec 2016 07:55:34 GMT

On 12/22/2016 5:26 AM, dick balaska wrote:
> Am 2016-12-21 03:29, also sprach Jaime Vives Piqueres:
>> El 21/12/16 a las 05:22, clipka escribiÃ³:
>>> Do you know of any possible reason for entering animation when both
>>> initial and final frames are equal but neither 0 nor 1?
>>>
>>
>>   It makes sense when you're using the clock to obtain a series of
>> different stills. I remember with my Tierra project, I used to let an
>> animation rendering overnight with different, random parameters for each
>> frame. Then at the next day I would check them all and re-render at
>> better quality only the good-looking ones.
>>
>> --
>> jaime
>
> But if initial and final are equal, what would the clock be?
> final - initial = 0; which is not a good clock divisor.
> I do final = 10; and then +SF2 +EF2 to do single frames.
>

Jaime might be using "clock" as a synonym for animation.

I use frame subsets for animations and testing values too. I prefer 
using integers to fractional numbers in my calculations. It makes more 
sense to me as you can't render a frame that is not a whole number.

-- 

Regards
     Stephen

[dick balaska] Re: Animation docs inaccurate [3399 days 7 hours and 44 minutes ago]

Thu, 22 Dec 2016 05:26:36 GMT

Am 2016-12-21 03:29, also sprach Jaime Vives Piqueres:
> El 21/12/16 a las 05:22, clipka escribió:
>> Do you know of any possible reason for entering animation when both
>> initial and final frames are equal but neither 0 nor 1?
>>
>
>   It makes sense when you're using the clock to obtain a series of
> different stills. I remember with my Tierra project, I used to let an
> animation rendering overnight with different, random parameters for each
> frame. Then at the next day I would check them all and re-render at
> better quality only the good-looking ones.
>
> --
> jaime

But if initial and final are equal, what would the clock be?
final - initial = 0; which is not a good clock divisor.
I do final = 10; and then +SF2 +EF2 to do single frames.

-- 
dik

[clipka] Re: Finish-level Fresnel [3399 days 8 hours and 11 minutes ago]

Thu, 22 Dec 2016 04:59:27 GMT

Am 22.12.2016 um 02:45 schrieb Jim Holsenback:
> On 12/21/2016 6:08 PM, clipka wrote:
>> Am 21.12.2016 um 18:09 schrieb Jim Holsenback:
>>> On 12/21/2016 10:35 AM, clipka wrote:
>>>> As for the syntax, I've decided to take it into my own hands now.
>>>
>>> good thing i'm /going with the flow/ ... i've touched this waaaay too
>>> many times to justify my further involvement with the issues on this
>>> page. btw: look at the old page and see that i've /done/ a lot to clean
>>> up the one big gigantic run one sentence that this page /was/ before i
>>> got hold of it
>>
>> Care to define "old" page?
> 
> what was released @ 3.7

To be honest, I don't really see any major changes to the Finish page
between the first import to the Wiki and today, with the sole exception
of the cleanup of ambient/emission and the reflection exponent stuff.

You sure are thinking of some other page there, right?

>>>> You know that something is utterly wrong with the structure of a
>>>> page if
>>>> the table of contents is preceded by an entire 2 pages worth of text.
>>>
>>> this is a side-effect of the half-baked reference re-sectioning that i
>>> was opposed to at 3.7 release ... added __NOTOC__ to suppress table of
>>> contents
>>
>> ... which now makes the thing inconsistent with the other pages (e.g.
>> http://wiki.povray.org/content/Reference:Light_Source). Meh.
> 
> you griped and i responded ... the ___NOTOC___ wiki markup appears in
> more than several pages even had to create a filter in wikidocgen to
> remove from the content because it's /not/ html

... and I'm speaking out loud what I think of it. I didn't gripe because
of the presence of a TOC 2 pages down the text, but because it took 2
pages of scrolling to get to those TOC, and because of the length and
content of those 2 pages.

>> With the pages on the Wiki being as long as they are, I'd really love to
>> have a TOC in there. Preferably high up on the page. Maybe the simplest
>> way to achieve this would be to insert a heading before the syntax pane
>> on all those pages. (If that sits well with you, but you don't want to
>> be burdened with the work, let me know and I'll do the edits.)
> 
> wiki only creates TOC in pages with more than 3 headings ...

Any way to force it to? Maybe a "__TOC__"?

Also, if a page has just 3 headings but is long enough that the reader
would wish for a TOC, then maybe that page would deserve more structuring?

[Jim Holsenback] Re: Finish-level Fresnel [3399 days 11 hours and 17 minutes ago]

Thu, 22 Dec 2016 01:53:18 GMT

On 12/21/2016 6:30 PM, Stephen wrote:
> On 12/21/2016 11:08 PM, clipka wrote:
>> and I realized it would be far easier to just do the changes
>> than go into a lengthy discussion with you why it was wrong. I even
>> resisted a brief urge to do other changes to the syntax pane, such as
>> re-ordering the finish items.
>
>
> Wouldn't it be far easier to write it yourself and let Jim check it then
> insert it?
> It would probable be quicker and you would have nothing to correct.
>

you'd think so wouldn't you ... i'm (rather was) perfectly ok with 
taking prose then doing the html mark up but i can't seem to get 
cooperation on that

[Jim Holsenback] Re: Finish-level Fresnel [3399 days 11 hours and 25 minutes ago]

Thu, 22 Dec 2016 01:45:23 GMT

On 12/21/2016 6:08 PM, clipka wrote:
> Am 21.12.2016 um 18:09 schrieb Jim Holsenback:
>> On 12/21/2016 10:35 AM, clipka wrote:
>>> As for the syntax, I've decided to take it into my own hands now.
>>
>> good thing i'm /going with the flow/ ... i've touched this waaaay too
>> many times to justify my further involvement with the issues on this
>> page. btw: look at the old page and see that i've /done/ a lot to clean
>> up the one big gigantic run one sentence that this page /was/ before i
>> got hold of it
>
> Care to define "old" page?

what was released @ 3.7
>
>
>>> You know that something is utterly wrong with the structure of a page if
>>> the table of contents is preceded by an entire 2 pages worth of text.
>>
>> this is a side-effect of the half-baked reference re-sectioning that i
>> was opposed to at 3.7 release ... added __NOTOC__ to suppress table of
>> contents
>
> ... which now makes the thing inconsistent with the other pages (e.g.
> http://wiki.povray.org/content/Reference:Light_Source). Meh.

you griped and i responded ... the ___NOTOC___ wiki markup appears in 
more than several pages even had to create a filter in wikidocgen to 
remove from the content because it's /not/ html

>
> With the pages on the Wiki being as long as they are, I'd really love to
> have a TOC in there. Preferably high up on the page. Maybe the simplest
> way to achieve this would be to insert a heading before the syntax pane
> on all those pages. (If that sits well with you, but you don't want to
> be burdened with the work, let me know and I'll do the edits.)

wiki only creates TOC in pages with more than 3 headings ...

>
>>> I think the description of the finish-level `fresnel` keyword and its
>>> effect is utterly misplaced there, and should instead be given a section
>>> of its own
>>
>> disagree ... but it's in your hands now ... correct?
>
> I don't know. Is it? How about the rest of the docs?
>
> I just grabbed hold of the syntax because it absolutely positively
> failed to match the code, there was no ambiguity in how it would have to
> be fixed, and I realized it would be far easier to just do the changes
> than go into a lengthy discussion with you why it was wrong. I even
> resisted a brief urge to do other changes to the syntax pane, such as
> re-ordering the finish items.
>

[Stephen] Re: Finish-level Fresnel [3399 days 13 hours and 40 minutes ago]

Wed, 21 Dec 2016 23:30:49 GMT

On 12/21/2016 11:08 PM, clipka wrote:
> and I realized it would be far easier to just do the changes
> than go into a lengthy discussion with you why it was wrong. I even
> resisted a brief urge to do other changes to the syntax pane, such as
> re-ordering the finish items.

Wouldn't it be far easier to write it yourself and let Jim check it then 
insert it?
It would probable be quicker and you would have nothing to correct.

-- 

Regards
     Stephen

[clipka] Re: Finish-level Fresnel [3399 days 14 hours and 2 minutes ago]

Wed, 21 Dec 2016 23:08:35 GMT

Am 21.12.2016 um 18:09 schrieb Jim Holsenback:
> On 12/21/2016 10:35 AM, clipka wrote:
>> As for the syntax, I've decided to take it into my own hands now.
> 
> good thing i'm /going with the flow/ ... i've touched this waaaay too
> many times to justify my further involvement with the issues on this
> page. btw: look at the old page and see that i've /done/ a lot to clean
> up the one big gigantic run one sentence that this page /was/ before i
> got hold of it

Care to define "old" page?

>> You know that something is utterly wrong with the structure of a page if
>> the table of contents is preceded by an entire 2 pages worth of text.
> 
> this is a side-effect of the half-baked reference re-sectioning that i
> was opposed to at 3.7 release ... added __NOTOC__ to suppress table of
> contents

... which now makes the thing inconsistent with the other pages (e.g.
http://wiki.povray.org/content/Reference:Light_Source). Meh.

With the pages on the Wiki being as long as they are, I'd really love to
have a TOC in there. Preferably high up on the page. Maybe the simplest
way to achieve this would be to insert a heading before the syntax pane
on all those pages. (If that sits well with you, but you don't want to
be burdened with the work, let me know and I'll do the edits.)

>> I think the description of the finish-level `fresnel` keyword and its
>> effect is utterly misplaced there, and should instead be given a section
>> of its own
> 
> disagree ... but it's in your hands now ... correct?

I don't know. Is it? How about the rest of the docs?

I just grabbed hold of the syntax because it absolutely positively
failed to match the code, there was no ambiguity in how it would have to
be fixed, and I realized it would be far easier to just do the changes
than go into a lengthy discussion with you why it was wrong. I even
resisted a brief urge to do other changes to the syntax pane, such as
re-ordering the finish items.

[omniverse] Re: Finish-level Fresnel [3399 days 19 hours and 6 minutes ago]

Wed, 21 Dec 2016 18:05:01 GMT

Although the following paragraph mentions refraction, but only to say the
treatment is as though ior=1, maybe there should be at least a note about ior >1
affecting (or activating?) fresnel finish.

quote:
In the following example the diffuse, phong and specular syntax, which is
normally used to specify the effective bi-hemispheric albedo of that respective
component, does not work as advertised when finish-level fresnel is set to
non-zero. Instead, diffuse will specify the albedo that the object would exhibit
if it had a refractive index of 1, while phong and specular will specify the
albedo that the object would exhibit if it had an infinitely large refractive
index. As a result, while you would normally want to choose parameters such that
D_Value + P_Value + S_Value <= 1. With finish-level fresnel set to a non-zero
value you would want to choose parameters such that D_Value <= 1 and P_Value +
S_Value <= 1. For optimal realism, you should specify the settings as noted
below, and control the brightness of the diffuse component via the layer
pigment.

[Jim Holsenback] Re: Finish-level Fresnel [3399 days 20 hours and 1 minute ago]

Wed, 21 Dec 2016 17:09:51 GMT

On 12/21/2016 10:35 AM, clipka wrote:
> As for the syntax, I've decided to take it into my own hands now.

good thing i'm /going with the flow/ ... i've touched this waaaay too 
many times to justify my further involvement with the issues on this 
page. btw: look at the old page and see that i've /done/ a lot to clean 
up the one big gigantic run one sentence that this page /was/ before i 
got hold of it

> You know that something is utterly wrong with the structure of a page if
> the table of contents is preceded by an entire 2 pages worth of text.

this is a side-effect of the half-baked reference re-sectioning that i 
was opposed to at 3.7 release ... added __NOTOC__ to suppress table of 
contents

>
> I think the description of the finish-level `fresnel` keyword and its
> effect is utterly misplaced there, and should instead be given a section
> of its own

disagree ... but it's in your hands now ... correct?

> (In a similar vein, I think the `use_alpha` keyword is also misplaced.
> There's not much to say about it, but it is a dedicated feature
> nonetheless, and shouldn't be in the section that deals with finish /per
> se/.)

disagree on the placement issue here as well

>
>
> The "Diffuse", "Phong" and "Specular" sections still have the "fresnel"
> keyword appearing in examples that seems to no longer have any
> connection to that keyword.
>
> Speaking of the "Diffuse" section, the description of the example in
> there has struck my as rather odd:
>
> -------------------------------------------------------
> finish { diffuse albedo 0.7 fresnel }
>
> Means that 70% of the light seen comes from direct illumination from
> light sources. The default value for diffuse is 0.6.
> -------------------------------------------------------
>
> In this form this is nonsense: "the light seen" that "comes from direct
> illumination from light sources" would also include highlights.
>
> I'd suggest something along the following lines:
> -------------------------------------------------------
> finish { diffuse albedo 0.7 }
>
> means that a white object with this finish reflects 70% of all incoming
> light /diffusely/.
> -------------------------------------------------------
>
>
> On to the "Phong" and "Specular" sections: In both of these, the
> `albedo` keyword description was inserted in a section that deals with
> `phong_size` or `roughness`, respectively, now leaving the sentence "If
> phong/specular is not specified phong_size/roughmess has no effect."
> dangling, disconnected from the section it belongs to.
>
>
> Also, the description of the reflection's `exponent` parameter is pretty
> bogus (but that's not your fault): Claiming that "POV-Ray uses a limited
> light model that cannot distinguish between objects which are simply
> brightly colored and objects which are extremely bright" is just plain
> wrong.
>
> I guess the text is just the result of people struggling to find an
> explanation for a phenomenon they failed to understand back then, which
> can now be named with just one word: Gamma!
>
> The text mentions "partially reflective surfaces". Now while most
> operations in the render engines _multiply_ colours, in this particular
> case colours are _added_ - namely the object's own colour and the
> reflected colour. And while multiplications work fine in any power-law
> gamma colour space, additions absolutely positively don't. In
> "assumed_gamma 2.2" mode, "middle and lower brightness objects typically
> look too bright" when another colour is added to them.
>
> So we might just as well replace the entire section with something like:

done ...

> -------------------------------------------------------
> exponent
> This property pre-dates the introduction of proper gamma handling.
> People found that it was difficult to model partially reflective
> surfaces in a realistic way, as middle and lower brightness objects
> typically looked too bright when reflected. As a means work around the
> phenomenon the optional exponent keyword was added, producing non-linear
> reflection intensities. The default value of 1.0 produces a linear
> curve. Lower values darken middle and low intensities and keep high
> intensity reflections bright. While this feature may still be used for
> artistic effects, it is strongly discouraged for renders aiming at
> realism. The original phenomenon is well understood by now, and using
> "assumed_gamma 1.0" as recommended will avoid it entirely.
> -------------------------------------------------------
>
> (Hold off on this for a moment though; I'll do a few experiments to
> verify that I'm right in my explanation of that old phenomenon.)
>

[clipka] Re: Finish-level Fresnel [3399 days 20 hours and 31 minutes ago]

Wed, 21 Dec 2016 16:39:14 GMT

Am 21.12.2016 um 16:35 schrieb clipka:

> So we might just as well replace the entire section with something like:
> -------------------------------------------------------
> exponent
> This property pre-dates the introduction of proper gamma handling.
> People found that it was difficult to model partially reflective
> surfaces in a realistic way, as middle and lower brightness objects
> typically looked too bright when reflected. As a means work around the
> phenomenon the optional exponent keyword was added, producing non-linear
> reflection intensities. The default value of 1.0 produces a linear
> curve. Lower values darken middle and low intensities and keep high
> intensity reflections bright. While this feature may still be used for
> artistic effects, it is strongly discouraged for renders aiming at
> realism. The original phenomenon is well understood by now, and using
> "assumed_gamma 1.0" as recommended will avoid it entirely.
> -------------------------------------------------------
> 
> (Hold off on this for a moment though; I'll do a few experiments to
> verify that I'm right in my explanation of that old phenomenon.)

Go ahead. My hypothesis turns out to fit nicely.

[clipka] Re: Finish-level Fresnel [3399 days 21 hours and 35 minutes ago]

Wed, 21 Dec 2016 15:35:38 GMT

Am 21.12.2016 um 14:55 schrieb Jim Holsenback:
> On 12/21/2016 3:55 AM, clipka wrote:
>> I'm changing the way the `finish` keyword will act when specified right
>> inside the `finish` block.
> 
> updated to include the additional narrative you posted here:
> http://wiki.povray.org/content/Reference:Finish

I'm afraid so say that, but I'm still not happy with the status quo :}

As for the syntax, I've decided to take it into my own hands now. As for
the rest of the page, I'll just continue to gripe and whine.

You know that something is utterly wrong with the structure of a page if
the table of contents is preceded by an entire 2 pages worth of text.

I think the description of the finish-level `fresnel` keyword and its
effect is utterly misplaced there, and should instead be given a section
of its own -- possibly behind "Conserve Energy for Reflection", because
these two are actually pretty closely related: finish-level `fresnel`
does a similar thing for the various finish components that
`conserve_energy` has been doing for transmitted light (with the
difference being that `fresnel` goes solely by the materials refractive
index, whereas `conserve_energy` would also honor non-fresnel variable
reflection).

In the sections describing the individual finish components, I would
briefly mention that the respective component is also affected by the
finish-level `fresnel` keyword, but defer the reader to the
fresnel-specific section for details.

(In a similar vein, I think the `use_alpha` keyword is also misplaced.
There's not much to say about it, but it is a dedicated feature
nonetheless, and shouldn't be in the section that deals with finish /per
se/.)

The "Diffuse", "Phong" and "Specular" sections still have the "fresnel"
keyword appearing in examples that seems to no longer have any
connection to that keyword.

Speaking of the "Diffuse" section, the description of the example in
there has struck my as rather odd:

-------------------------------------------------------
finish { diffuse albedo 0.7 fresnel }

Means that 70% of the light seen comes from direct illumination from
light sources. The default value for diffuse is 0.6.
-------------------------------------------------------

In this form this is nonsense: "the light seen" that "comes from direct
illumination from light sources" would also include highlights.

I'd suggest something along the following lines:
-------------------------------------------------------
finish { diffuse albedo 0.7 }

means that a white object with this finish reflects 70% of all incoming
light /diffusely/.
-------------------------------------------------------

On to the "Phong" and "Specular" sections: In both of these, the
`albedo` keyword description was inserted in a section that deals with
`phong_size` or `roughness`, respectively, now leaving the sentence "If
phong/specular is not specified phong_size/roughmess has no effect."
dangling, disconnected from the section it belongs to.

Also, the description of the reflection's `exponent` parameter is pretty
bogus (but that's not your fault): Claiming that "POV-Ray uses a limited
light model that cannot distinguish between objects which are simply
brightly colored and objects which are extremely bright" is just plain
wrong.

I guess the text is just the result of people struggling to find an
explanation for a phenomenon they failed to understand back then, which
can now be named with just one word: Gamma!

The text mentions "partially reflective surfaces". Now while most
operations in the render engines _multiply_ colours, in this particular
case colours are _added_ - namely the object's own colour and the
reflected colour. And while multiplications work fine in any power-law
gamma colour space, additions absolutely positively don't. In
"assumed_gamma 2.2" mode, "middle and lower brightness objects typically
look too bright" when another colour is added to them.

So we might just as well replace the entire section with something like:
-------------------------------------------------------
exponent
This property pre-dates the introduction of proper gamma handling.
People found that it was difficult to model partially reflective
surfaces in a realistic way, as middle and lower brightness objects
typically looked too bright when reflected. As a means work around the
phenomenon the optional exponent keyword was added, producing non-linear
reflection intensities. The default value of 1.0 produces a linear
curve. Lower values darken middle and low intensities and keep high
intensity reflections bright. While this feature may still be used for
artistic effects, it is strongly discouraged for renders aiming at
realism. The original phenomenon is well understood by now, and using
"assumed_gamma 1.0" as recommended will avoid it entirely.
-------------------------------------------------------

(Hold off on this for a moment though; I'll do a few experiments to
verify that I'm right in my explanation of that old phenomenon.)

[Jim Holsenback] Re: Finish-level Fresnel [3399 days 23 hours and 15 minutes ago]

Wed, 21 Dec 2016 13:55:32 GMT

On 12/21/2016 3:55 AM, clipka wrote:
> I'm changing the way the `finish` keyword will act when specified right
> inside the `finish` block.

updated to include the additional narrative you posted here: 
http://wiki.povray.org/content/Reference:Finish

[Stephen] Re: Finish-level Fresnel [3399 days 23 hours and 25 minutes ago]

Wed, 21 Dec 2016 13:45:22 GMT

On 12/21/2016 12:48 PM, clipka wrote:
> Am 21.12.2016 um 13:41 schrieb Stephen:
>> On 12/21/2016 12:10 PM, Jim Holsenback wrote:
>>> On 12/21/2016 6:49 AM, Stephen wrote:
>>>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>>>
>>>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>>>
>>>> You should control the release to the main program when you are happy
>>>> with the documentation.
>>>>
>>>
>>> if it /were/ only true!!! lately i've been practicing /going with the
>>> flow/ so i guess the only thing to do is run faster ;-)
>>
>> Watch you don't get the sidewalk coded away from under you. :)
>
> When I'm done coding, he'll be able to render his own perfectly
> realistic sidewalk ;)
>
> Now off with you -- let the man do his job...
>

I will if you stop moving the goal posts.
Remember I have my beady eye on you.

-- 

Regards
     Stephen

[clipka] Re: Finish-level Fresnel [3400 days and 22 minutes ago]

Wed, 21 Dec 2016 12:48:57 GMT

Am 21.12.2016 um 13:41 schrieb Stephen:
> On 12/21/2016 12:10 PM, Jim Holsenback wrote:
>> On 12/21/2016 6:49 AM, Stephen wrote:
>>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>>
>>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>>
>>> You should control the release to the main program when you are happy
>>> with the documentation.
>>>
>>
>> if it /were/ only true!!! lately i've been practicing /going with the
>> flow/ so i guess the only thing to do is run faster ;-)
> 
> Watch you don't get the sidewalk coded away from under you. :)

When I'm done coding, he'll be able to render his own perfectly
realistic sidewalk ;)

Now off with you -- let the man do his job...

[clipka] Re: Finish-level Fresnel [3400 days and 24 minutes ago]

Wed, 21 Dec 2016 12:46:26 GMT

Am 21.12.2016 um 13:10 schrieb Jim Holsenback:
> On 12/21/2016 6:49 AM, Stephen wrote:
>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>
>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>
>> You should control the release to the main program when you are happy
>> with the documentation.
>>
> 
> if it /were/ only true!!! lately i've been practicing /going with the
> flow/ so i guess the only thing to do is run faster ;-)

That's the spirit!

Here, let me dangle this carrot before your nose... ;)

[Stephen] Re: Finish-level Fresnel [3400 days and 30 minutes ago]

Wed, 21 Dec 2016 12:41:05 GMT

On 12/21/2016 12:10 PM, Jim Holsenback wrote:
> On 12/21/2016 6:49 AM, Stephen wrote:
>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>
>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>
>> You should control the release to the main program when you are happy
>> with the documentation.
>>
>
> if it /were/ only true!!! lately i've been practicing /going with the
> flow/ so i guess the only thing to do is run faster ;-)

Watch you don't get the sidewalk coded away from under you. :)

-- 

Regards
     Stephen

[clipka] Re: Finish-level Fresnel [3400 days and 42 minutes ago]

Wed, 21 Dec 2016 12:29:06 GMT

Am 21.12.2016 um 12:33 schrieb Jim Holsenback:
> On 12/21/2016 3:55 AM, clipka wrote:
>> I'm changing the way the `finish` keyword will act when specified right
>> inside the `finish` block.
>>
>> The future syntax will be as follows:
>>
>>     FINISH:
>>       finish { [FINISH_IDENTIFIER] [FINISH_ITEMS...] }
>>     FINISH_ITEMS:
>>       ... | fresnel FLOAT | ...
>>
>>
>> Setting this to `on` (=1) will cause POV-Ray to realistically account
>> for the Fresnel effect in all of the following features:
>>
>>   - ambient
>>   - diffuse
>>   - emission
>>   - phong
>>   - specular
> 
> lol ... how am i supposed to get caught up if you keep changing/adding

Sorry. Call it necessary cleanup (adding ambient and emission to the
mix), plus a minor improvement while I was on it (making it a float
setting rather than a bool).

Smile and be glad, for things could be worse -- I'm currently already
restraining myself when it comes to entirely /new/ features ;)

(*tries to wriggle out of straightjacket*)

> testing allows:
> 
> finish {
>   fresnel on
>   specular S_Value fresnel off
>   }
> 
> does that mean /all/ applicable attributes get fresnel treatment
> /except/ specular

No, it means that /no/ attribute gets fresnel treatment, because the
setting /always/ applies to /all/ elements, and the later "fresnel off"
supersedes the earlier "fresnel on".

This is similar how the "metallic" setting at the finish level works:
While it is perfectly legal to write

    finish {
      phong 1 metallic on
      specular 1 metallic off
      }

this is misleading style, since "metallic" always applies to both phong
and specular. You might just as well write

    finish {
      phong 1
      specular 1
      metallic on metallic off
      }

with the later "metallic" statement winning over the earlier one. Which
in turn is just like

    finish {
      specular 1
      specular 0
      }

is also perfectly legal but only the second "specular" wins.

This is a side effect of (A) allowing users to specify the finish
parameters in arbitrary order, (B) allowing users to specify a
"template" finish at the beginning of the finish block and then override
individual parameters from that template, and (C) still keeping the
parser reasonably simple (well, maybe more like "not _batshit_ crazy
convoluted").

[Jim Holsenback] Re: Finish-level Fresnel [3400 days 1 hour and 1 minute ago]

Wed, 21 Dec 2016 12:10:08 GMT

On 12/21/2016 6:49 AM, Stephen wrote:
> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>
>> lol ... how am i supposed to get caught up if you keep changing/adding
>
> You should control the release to the main program when you are happy
> with the documentation.
>

if it /were/ only true!!! lately i've been practicing /going with the 
flow/ so i guess the only thing to do is run faster ;-)

[Stephen] Re: Finish-level Fresnel [3400 days 1 hour and 21 minutes ago]

Wed, 21 Dec 2016 11:49:29 GMT

On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>
> lol ... how am i supposed to get caught up if you keep changing/adding

You should control the release to the main program when you are happy 
with the documentation.

-- 

Regards
     Stephen

[Jim Holsenback] Re: Finish-level Fresnel [3400 days 1 hour and 37 minutes ago]

Wed, 21 Dec 2016 11:33:16 GMT

On 12/21/2016 3:55 AM, clipka wrote:
> I'm changing the way the `finish` keyword will act when specified right
> inside the `finish` block.
>
> The future syntax will be as follows:
>
>     FINISH:
>       finish { [FINISH_IDENTIFIER] [FINISH_ITEMS...] }
>     FINISH_ITEMS:
>       ... | fresnel FLOAT | ...
>
>
> Setting this to `on` (=1) will cause POV-Ray to realistically account
> for the Fresnel effect in all of the following features:
>
>   - ambient
>   - diffuse
>   - emission
>   - phong
>   - specular

lol ... how am i supposed to get caught up if you keep changing/adding

testing allows:

finish {
   fresnel on
   specular S_Value fresnel off
   }

does that mean /all/ applicable attributes get fresnel treatment 
/except/ specular

[clipka] Re: Finish-level Fresnel [3400 days 3 hours and 51 minutes ago]

Wed, 21 Dec 2016 09:20:03 GMT

Am 21.12.2016 um 09:55 schrieb clipka:

> The `diffuse albedo DIFFUSE`, `phong albedo PHONG` and `specular albedo
> SPECULAR` syntax, which is normally used to specify the effective
> _bihemispherical albedo_ of that respective component, does not work as

Make that "bihemispheric albedo".

[clipka] Re: Finish-level Fresnel [3400 days 4 hours and 3 minutes ago]

Wed, 21 Dec 2016 09:07:38 GMT

Am 21.12.2016 um 09:55 schrieb clipka:
> I'm changing the way the `finish` keyword will act when specified right
> inside the `finish` block.

Just posted a pair of sample images to povray.binaries.images.

[clipka] Finish-level Fresnel [3400 days 4 hours and 15 minutes ago]

Wed, 21 Dec 2016 08:55:56 GMT

I'm changing the way the `finish` keyword will act when specified right
inside the `finish` block.

The future syntax will be as follows:

    FINISH:
      finish { [FINISH_IDENTIFIER] [FINISH_ITEMS...] }
    FINISH_ITEMS:
      ... | fresnel FLOAT | ...


Setting this to `on` (=1) will cause POV-Ray to realistically account
for the Fresnel effect in all of the following features:

  - ambient
  - diffuse
  - emission
  - phong
  - specular

Setting this to `off` (=0) will cause POV-Ray to revert to the default
behaviour.

The parameter can also be set to an intermediate value, in order to
allow for the (approximate) modelling of anti-rective coatings.

_Interaction with Albedo_:

The `diffuse albedo DIFFUSE`, `phong albedo PHONG` and `specular albedo
SPECULAR` syntax, which is normally used to specify the effective
_bihemispherical albedo_ of that respective component, does not work as
advertised when finish-level `fresnel` is set to non-zero. Instead,
`diffuse albedo DIFFUSE` will specify the albedo the object would
exhibit if it had a refractive index of 1, while `phong albedo PHONG`
and `specular albedo SPECULAR` will specify the albedo the object would
exhibit if it had an infinitely large refractive index.

As a result, while you would normally want to choose paramaters such
that DIFFUSE + PHONG + SPECULAR <= 1, with finish-level `fresnel` set to
a non-zero value you would want to choose parameters such that DIFFUSE
<= 1 and PHONG + SPECULAR <= 1.

For optimal realism, you should specify `diffuse albedo 1 phong albedo 0
specular albedo 1`, and control the brightness of the diffuse component
via the layer pigment.

_Interaction with Reflection_:

Setting finish-level `fresnel` will automatically activate (if set to a
non-zero value) or de-activate (if set to zero) the reflection-level
`fresnel` parameter. This can be overridden by specifying the reflection
parameters _after_ the finish-level `fresnel` parameter.

For optimal realism, the maximum reflection should be set equal to the
finish-level `fresnel` parameter, while the minimum reflection should be
set to zero.

_Interaction with Subsurface Light Transport_:

When subsurface light transport is enabled, the finish-level `fresnel`
parameter will have no effect on the diffuse feature; instead, the
feature will always act as if the parameter had been set to 1.

_Interaction with Radiosity_:

Radiosity-based illumination currently does not account for the Fresnel
effect on incoming light, regardless of the finish-level `fresnel`
parameter.

[Jaime Vives Piqueres] Re: Animation docs inaccurate [3400 days 4 hours and 41 minutes ago]

Wed, 21 Dec 2016 08:29:49 GMT

El 21/12/16 a las 05:22, clipka escribió:
> Do you know of any possible reason for entering animation when both
> initial and final frames are equal but neither 0 nor 1?
>

   It makes sense when you're using the clock to obtain a series of
different stills. I remember with my Tierra project, I used to let an
animation rendering overnight with different, random parameters for each
frame. Then at the next day I would check them all and re-render at
better quality only the good-looking ones.

--
jaime

[clipka] Re: Animation docs inaccurate [3400 days 5 hours and 44 minutes ago]

Wed, 21 Dec 2016 07:26:46 GMT

Am 21.12.2016 um 07:58 schrieb omniverse:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 21.12.2016 um 06:49 schrieb omniverse:
>>
>>> Just looked at what clock says it is when trying equal frames.
>>>
>>> -nan(ind)
>>>
>>> Not a number (with a dash, minus??), but I don't know what the ind means.
>>> Thought you probably would.
>>
>> Yes: "Indeterminate". Meaning that the expression has no solution at all
>> (not even infinity), or that it has more than one solution (typically
>> infinitely many).
> --->8 ok 8<---
>> Not sure what that minus sign means. Might be just an intrinsic part of
>> the way "Not-a-Number" values are reported, or might actually mean
>> _something_. Maybe the IEEE would know.
> 
> Curiously, the clock was put in as a light_source color when I tried this.
> Thought maybe it went to -1 and luckily I used a simple candle scene, lit
> externally by that other light, so the flame light should have still been there.
> 
> Tried -1 instead of clock and the flame light was still there, just not the same
> as with the NaN clock! Found it takes more like -100 to get the equivalent
> appearance, extinguishing the flame entirely. Difficult to know exactly but -50
> was ever so slightly different on the wick and melted wax edges.
> 
> Try and explain that. Why would it equate to approximately -100 for a
> light_source? Anyway... going astray I fear.  ;)

"NaN" values propagate through every computation they take part in --
until they are converted to integer values, at which point their effect
depends on what compiler was used to build the application, what
compiler settings were used, and what colour your socks are.

In POV-Ray, that point is the actual writing of the output image file
(or display in the preview window), and the result will typically be
either bright white or pitch black pixels.

[omniverse] Re: Animation docs inaccurate [3400 days 6 hours and 11 minutes ago]

Wed, 21 Dec 2016 07:00:06 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 21.12.2016 um 06:49 schrieb omniverse:
>
> > Just looked at what clock says it is when trying equal frames.
> >
> > -nan(ind)
> >
> > Not a number (with a dash, minus??), but I don't know what the ind means.
> > Thought you probably would.
>
> Yes: "Indeterminate". Meaning that the expression has no solution at all
> (not even infinity), or that it has more than one solution (typically
> infinitely many).
--->8 ok 8<---
> Not sure what that minus sign means. Might be just an intrinsic part of
> the way "Not-a-Number" values are reported, or might actually mean
> _something_. Maybe the IEEE would know.

Curiously, the clock was put in as a light_source color when I tried this.
Thought maybe it went to -1 and luckily I used a simple candle scene, lit
externally by that other light, so the flame light should have still been there.

Tried -1 instead of clock and the flame light was still there, just not the same
as with the NaN clock! Found it takes more like -100 to get the equivalent
appearance, extinguishing the flame entirely. Difficult to know exactly but -50
was ever so slightly different on the wick and melted wax edges.

Try and explain that. Why would it equate to approximately -100 for a
light_source? Anyway... going astray I fear.  ;)

Bob

[clipka] Re: Animation docs inaccurate [3400 days 6 hours and 46 minutes ago]

Wed, 21 Dec 2016 06:24:42 GMT

Am 21.12.2016 um 06:49 schrieb omniverse:

> Just looked at what clock says it is when trying equal frames.
> 
> -nan(ind)
> 
> Not a number (with a dash, minus??), but I don't know what the ind means.
> Thought you probably would.

Yes: "Indeterminate". Meaning that the expression has no solution at all
(not even infinity), or that it has more than one solution (typically
infinitely many).

For example, the expression

    a / b

is supposed to yield the number x that satisfies

    x * b = a

so the expression

    0 / 0

should yield the number x that satisfies

    x * 0 = 0

which is true for all numbers, so the computer can't decide on any
particular one to give as a result.


At the other end of the spectrum, the expression

    sqrt(-1)

has no answer at all in the set of real numbers, so the computer is
again can't give you any meaningful result.


A slightly different case is the expression

    1 / 0

for which some mathematical systems add two special values to the set of
real numbers, named "positive infinity" (defined as 1/0) and "negative
infinity" (defined as -1/0), so in this case the computer does have a
result to present -- which is still "not a number" though, so it is
reported in a similar way:

    nan(inf)


Not sure what that minus sign means. Might be just an intrinsic part of
the way "Not-a-Number" values are reported, or might actually mean
_something_. Maybe the IEEE would know.

[omniverse] Re: Animation docs inaccurate [3400 days 7 hours and 21 minutes ago]

Wed, 21 Dec 2016 05:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 20.12.2016 um 23:01 schrieb Thorsten Froehlich:
> > clipka <ano### [at] anonymousorg> wrote:
> >> I've just noticed that the documentation of the animation settings is
> >> not entirely in line with the actual implementation.
> >>
> >> The docs claim:
> >> -----------------------------------------------------------
> >> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> >> animation loop.
> >> -----------------------------------------------------------
> >>
> >> According to the code however, animation seems to be activated whenever
> >> the initial and final frames are neither both equal to 0 nor both equal
> >> to 1.
> >>
> >>
> >> This discrepancy raises the question which one is correct: The code or
> >> the documentation?
> >
> > I don't recall how the old code worked, but there was some inconsistency or bug
> > that triggered a change so the animation would only run if there was more than
> > one frame. I don't think the docs were ever updated.
>
> Apparently that's not how it was changed: If for instance you specify
> `+kfi2 +kff2`, POV-Ray still enters into animation mode (and screws up
> the clock; well, until a workaround I just checked in).
>
> Do you know of any possible reason for entering animation when both
> initial and final frames are equal but neither 0 nor 1?

Hmmm. The pre-3.0 versions lacked subset frames, but I don't know if that means
initial and final frame could have possibly been meant to act as such once that
was implemented for post-2.2 versions.

Clock was basically all there was for animations back then.

Goes against common sense anyhow, unless the clock variable still recognized a
default initial frame of 1 or somehow ignored the start=end frame.

Just looked at what clock says it is when trying equal frames.

-nan(ind)

Not a number (with a dash, minus??), but I don't know what the ind means.
Thought you probably would.

Bob

[clipka] Re: Animation docs inaccurate [3400 days 8 hours and 48 minutes ago]

Wed, 21 Dec 2016 04:22:52 GMT

Am 20.12.2016 um 23:01 schrieb Thorsten Froehlich:
> clipka <ano### [at] anonymousorg> wrote:
>> I've just noticed that the documentation of the animation settings is
>> not entirely in line with the actual implementation.
>>
>> The docs claim:
>> -----------------------------------------------------------
>> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
>> animation loop.
>> -----------------------------------------------------------
>>
>> According to the code however, animation seems to be activated whenever
>> the initial and final frames are neither both equal to 0 nor both equal
>> to 1.
>>
>>
>> This discrepancy raises the question which one is correct: The code or
>> the documentation?
> 
> I don't recall how the old code worked, but there was some inconsistency or bug
> that triggered a change so the animation would only run if there was more than
> one frame. I don't think the docs were ever updated.

Apparently that's not how it was changed: If for instance you specify
`+kfi2 +kff2`, POV-Ray still enters into animation mode (and screws up
the clock; well, until a workaround I just checked in).

Do you know of any possible reason for entering animation when both
initial and final frames are equal but neither 0 nor 1?

[Thorsten Froehlich] Re: Animation docs inaccurate [3400 days 15 hours and 6 minutes ago]

Tue, 20 Dec 2016 22:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> I've just noticed that the documentation of the animation settings is
> not entirely in line with the actual implementation.
>
> The docs claim:
> -----------------------------------------------------------
> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> animation loop.
> -----------------------------------------------------------
>
> According to the code however, animation seems to be activated whenever
> the initial and final frames are neither both equal to 0 nor both equal
> to 1.
>
>
> This discrepancy raises the question which one is correct: The code or
> the documentation?

I don't recall how the old code worked, but there was some inconsistency or bug
that triggered a change so the animation would only run if there was more than
one frame. I don't think the docs were ever updated.

[omniverse] Re: Animation docs inaccurate [3400 days 17 hours and 56 minutes ago]

Tue, 20 Dec 2016 19:15:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> I've just noticed that the documentation of the animation settings is
> not entirely in line with the actual implementation.
>
> The docs claim:
> -----------------------------------------------------------
> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> animation loop.
> -----------------------------------------------------------
>
> According to the code however, animation seems to be activated whenever
> the initial and final frames are neither both equal to 0 nor both equal
> to 1.
>
>
> This discrepancy raises the question which one is correct: The code or
> the documentation?

That goes back to version 3.0 and I would guess it was meant to be a short way
of saying positive integers for final frame would activate animation.
So knowing default initial frame is 1 that meant it had to be at least 2,
obviously not 0, unless you set initial to 0 and could use final 1 instead.

Bob

[clipka] Animation docs inaccurate [3400 days 20 hours and 2 minutes ago]

Tue, 20 Dec 2016 17:08:37 GMT

I've just noticed that the documentation of the animation settings is
not entirely in line with the actual implementation.

The docs claim:
-----------------------------------------------------------
Any Final_Frame setting other than -1 will trigger POV-Ray's internal
animation loop.
-----------------------------------------------------------

According to the code however, animation seems to be activated whenever
the initial and final frames are neither both equal to 0 nor both equal
to 1.


This discrepancy raises the question which one is correct: The code or
the documentation?

[clipka] Re: Reference:Arrays note about 40 character ide... [3407 days 12 hours and 33 minutes ago]

Wed, 14 Dec 2016 00:37:30 GMT

Am 13.12.2016 um 18:26 schrieb Jim Holsenback:

>>> *NOTE*: These pseudo-dictionaries *REPLACE* the `local()` and `global()`
>>> pseudo-functions, which are currently mentioned in the tutorial's "New
>>> features" section, the "Identifier Name Collisions" section in the
>>> reference page on #declare and #local, and in the "Optional Parameters"
>>> section in the reference page on macros.
>>>
>>
>> ok so some clean up and one add ... local and global are /still/
>> keywords?
> 
> one more question ... id name collisions it's just a delete but optional
> params part i see in 1st note reference to /local/ should the link now
> point to the add i'll be doing to the array page? what about example
> just below the note ... still valid example?

I think we should keep some mention of the mechanism in the "Identifier
Name Collisions" section, except of course that it needs to be re-worded
to fit the dictionary-ish version rather than the function-ish one. And
it may be shortened to a reference to the section on dictionaries.

Where the "Optional Parameters" note links to depends on where we want
to put the primary information on the "local" pseudo-dictionary: In the
dictionaries reference, or the identifier name collision section. I'd
advocate the former.

The text "... make use of the `local()` pseudo-function..." of course
needs to be replaced with "... make use of the `local`
pseudo-dictionary...", and the example indeed needs fixing as well:

    #macro Foo(P1, optional P2)
      #ifndef(local.P2) #local P2 = 0; #end // provide default for P2
      ...
    #end

    #declare X=1;
    #declare Y=2;
    Foo(X,Y);
    #undef Y;
    Foo(X,Y);
    Foo(X,);

[Jim Holsenback] Re: Reference:Arrays note about 40 character ide... [3407 days 19 hours and 44 minutes ago]

Tue, 13 Dec 2016 17:26:11 GMT

On 12/13/2016 11:52 AM, Jim Holsenback wrote:
> On 12/12/2016 1:05 PM, clipka wrote:
>> Am 12.12.2016 um 13:38 schrieb Jim Holsenback:
>>> On 12/12/2016 6:44 AM, William F Pokorny wrote:
>>>> Ref:
>>>>
>>>> http://wiki.povray.org/content/Reference:Array
>>>>
>>>> I believe identifiers can be longer than 40 characters & that we've
>>>> recently added such notes elsewhere. Perhaps we need not mention the
>>>> identifier limit specifically for arrays should we want to avoid
>>>> another
>>>> change note.
>>>
>>> i've already addressed that here:
>>> http://wiki.povray.org/content/Reference_Talk:Array
>>>
>>> but haven't moved it over yet ... was waiting for some kind of heads up
>>> that the other feature add/change was going to make it into release
>>> branch
>>
>> Then let it hereby be known that flexible-size arrays, mixed-type arrays
>> and dictionaries have joined the master branch on November 25th. ;)
>>
>> Also included are two pseudo-dictionaries, `local` and `global`,
>> representing the "most local" identifiers and the global identifiers,
>> respectively. For example:
>>
>>     #declare local.Foo = 4711;
>>     #undef global.Foo;
>>
>> will declare a local variable named "Foo", and undefine any global
>> variable of the same name, respectively.
>>
>> *NOTE*: These pseudo-dictionaries *REPLACE* the `local()` and `global()`
>> pseudo-functions, which are currently mentioned in the tutorial's "New
>> features" section, the "Identifier Name Collisions" section in the
>> reference page on #declare and #local, and in the "Optional Parameters"
>> section in the reference page on macros.
>>
>
> ok so some clean up and one add ... local and global are /still/ keywords?

one more question ... id name collisions it's just a delete but optional 
params part i see in 1st note reference to /local/ should the link now 
point to the add i'll be doing to the array page? what about example 
just below the note ... still valid example?

[clipka] Re: Reference:Arrays note about 40 character ide... [3407 days 19 hours and 45 minutes ago]

Tue, 13 Dec 2016 17:25:55 GMT

Am 13.12.2016 um 17:52 schrieb Jim Holsenback:

> ok so some clean up and one add ... local and global are /still/ keywords?

Yes.

`local` is now a special keyword that essentially evaluates to the
directory of "most local" variables.

`global` is now a special keyword that essentially evaluates to the
directory of "least local" (i.e. global) variables.


In addition to that, `local` of course retains its well-established
meaning after `#` to form the `#local` directive. (Technically, all the
directives are actually the `#` token followed by a keyword.)

[Jim Holsenback] Re: Reference:Arrays note about 40 character ide... [3407 days 20 hours and 19 minutes ago]

Tue, 13 Dec 2016 16:52:10 GMT

On 12/12/2016 1:05 PM, clipka wrote:
> Am 12.12.2016 um 13:38 schrieb Jim Holsenback:
>> On 12/12/2016 6:44 AM, William F Pokorny wrote:
>>> Ref:
>>>
>>> http://wiki.povray.org/content/Reference:Array
>>>
>>> I believe identifiers can be longer than 40 characters & that we've
>>> recently added such notes elsewhere. Perhaps we need not mention the
>>> identifier limit specifically for arrays should we want to avoid another
>>> change note.
>>
>> i've already addressed that here:
>> http://wiki.povray.org/content/Reference_Talk:Array
>>
>> but haven't moved it over yet ... was waiting for some kind of heads up
>> that the other feature add/change was going to make it into release branch
>
> Then let it hereby be known that flexible-size arrays, mixed-type arrays
> and dictionaries have joined the master branch on November 25th. ;)
>
> Also included are two pseudo-dictionaries, `local` and `global`,
> representing the "most local" identifiers and the global identifiers,
> respectively. For example:
>
>     #declare local.Foo = 4711;
>     #undef global.Foo;
>
> will declare a local variable named "Foo", and undefine any global
> variable of the same name, respectively.
>
> *NOTE*: These pseudo-dictionaries *REPLACE* the `local()` and `global()`
> pseudo-functions, which are currently mentioned in the tutorial's "New
> features" section, the "Identifier Name Collisions" section in the
> reference page on #declare and #local, and in the "Optional Parameters"
> section in the reference page on macros.
>

ok so some clean up and one add ... local and global are /still/ keywords?

[clipka] Re: Revoked features [3407 days 23 hours and 39 minutes ago]

Tue, 13 Dec 2016 13:31:49 GMT

Am 13.12.2016 um 14:06 schrieb Jim Holsenback:
> On 12/13/2016 4:40 AM, clipka wrote:
>> I'm declaring the following features non-existent in 3.7.1 for now:
>>
>> - Wavefront OBJ import
> 
> removed ... copied existing content to Mesh talk page for if/when we
> need it in the future.

Thanks.

[clipka] New in 3.7.1 [3408 days ago]

Tue, 13 Dec 2016 13:11:07 GMT

As a reference for the work on the documentation, I've updated the
following two files in the master branch:

revision.txt:

Since the version tagged as "v3.7.0.0", this list has seen three
updates: A major one in April this year, a minor one in May, and now
another major one. Each time the new content was essentially
auto-generated (with minor manual edits) from the GitHub version history
tree, so that it now includes each and every commit even remotely
relevant for the current master branch (up to, but excluding, commit
6671b3e).

chages.txt:

This list has seen semi-infrequent updates along with individual
commits, and as such would be unreliable. However, with each of the
updates to revision.txt I have sifted through the delta of commits, and
taken some effort to make sure that any user-visible changes do get a
brief mention in changes.txt.

Thus, changes.txt should serve as a good reference for what changes
should be mentioned on the Wiki.


Should you find anything in changes.txt that isn't mentioned in the Wiki
yet, and for which you can't find sufficiently detailed information in
the newsgroups (or, as is sometimes the case, revision.txt), feel free
to holler out, and I'll throw together a rough description of the
respective feature here.

[Jim Holsenback] Re: Revoked features [3408 days and 4 minutes ago]

Tue, 13 Dec 2016 13:06:48 GMT

On 12/13/2016 4:40 AM, clipka wrote:
> I'm declaring the following features non-existent in 3.7.1 for now:
>
> - Wavefront OBJ import

removed ... copied existing content to Mesh talk page for if/when we 
need it in the future.

> - two-parameter `brilliance`

hadn't done anything with that yet ... so no action on this one

[clipka] Re: dictionary container types [3408 days 2 hours and 27 minutes ago]

Tue, 13 Dec 2016 10:43:39 GMT

Am 13.12.2016 um 11:00 schrieb clipka:

> (A)
> 
>     #declare Fnord = dictionary {
>       Foo: 42,
>       Bar: sphere { <0,0,0>, 1 }
>     }
...
> (C)
> 
>     #declare Fnord = dictionary {
>       .Foo: 42,
>       .Bar: sphere { <0,0,0>, 1 }
>     }

Here's another case study showing how (A) might be disadvantageous:

    #declare Value = "Bar";
    #declare Fnord = dictionary;
    #declare Fnord.Foo = Value;

In (A) notation, the equivalent would be:

    #declare Value = "Bar";
    #declare Fnord = dictionary {
      Foo: Value
    }

But if the identifier `Value` on the right-hand side is evaluated to
"Bar", wouldn't a user also expect, with some legitimacy, the identifier
`Foo` on the left-hand side to be evaluated in the same manner? Thus, a
user may be fooled into expecting the following to work:

    #declare Key = "Foo";
    #declare Value = "Bar";
    #declare Fnord = dictionary {
      Key: Value
    }

In (C) notation, it would instead be:

    #declare Value = "Bar";
    #declare Fnord = dictionary {
      .Foo: Value
    }

Here, the mandatory dot gives the user a hint that there is /something/
different about the way the two identifiers act.


There's also another, much more far-reaching rationale to pick the dot
notation: Some day or another we'll want to overhaul the entire Scene
Description Language, and replace it with something similar but more
powerful while at the same time much more self-consistent.

One part of the deal would be to demote parameters (such as the
"diffuse" in the "finish" block) from reserved keywords to something
much more akin to "variables". We would also want users to be able to
define their own data structures that behave in exactly the same way, so
that users might e.g. define their own parameterizable geometric shapes.

However, in such a world it could become increasingly difficult to tell
apart parameters from genuine variables - and one possible solution to
that problem might lie in adopting the dot notation for parameters,
while using "undotted" identifiers for variables defined elsewhere; e.g.
a finish definition might end up looking like this:

    finish {
      .diffuse:    rand(R);
      .specular:   1 - .diffuse;
      .reflection: .specular * ReflectionFactor;
    }

Looking familiar? ;)

[clipka] Re: dictionary container types [3408 days 3 hours and 11 minutes ago]

Tue, 13 Dec 2016 10:00:06 GMT

Am 13.12.2016 um 10:17 schrieb clipka:

>> I still think the dot is superfluous.
> 
> Think about it:
> 
>     #declare Foo = "Dang";
>     #declare Bar = "What";
> 
>     #declare Fnord = dictionary {
>       Foo: 42,
>       Bar: sphere { <0,0,0>, 1 }
>     }
> 
> Which of the following would that supposedly be equivalent to?

To elaborate more on that point: When designing the syntax for
dictionary initializers, one could come up with the following
alternatives to all denote the same:

(Intent)

    #declare Fnord = dictionary;
    #declare Fnord["Foo"] = 42;
    #declare Fnord["Bar"] = sphere { <0,0,0>, 1 }

(A)

    #declare Fnord = dictionary {
      Foo: 42,
      Bar: sphere { <0,0,0>, 1 }
    }

(B)

    #declare Fnord = dictionary {
      "Foo": 42,
      "Bar": sphere { <0,0,0>, 1 }
    }

(C)

    #declare Fnord = dictionary {
      .Foo: 42,
      .Bar: sphere { <0,0,0>, 1 }
    }

(D)

    #declare Fnord = dictionary {
      ["Foo"]: 42,
      ["Bar"]: sphere { <0,0,0>, 1 }
    }

Note how variants (A) and (B) are fundamentally incompatible: If the key
can be a string literal, it is legitimate to also expect other string
expressions to work, and this would include plain references to string
variables. Thus, a consistent implementation of (B) would also allow for
the following:

    #declare Key1="Foo";
    #declare Key2="Bar";
    #declare Fnord = dictionary {
      Key1: 42,
      Key2: sphere { <0,0,0>, 1 }
    }

This however would take on a completely different meaning under variant (A).

Now one could rule in favour of either A or B, and I think both have
their merits. Which is why I think it wise to go for neither of them,
and instead opt for variants that are collision-free not only with
respect to each other, but even with respect to the entire set of
_possible_ alternatives.

[clipka] Revoked features [3408 days 3 hours and 30 minutes ago]

Tue, 13 Dec 2016 09:40:57 GMT

I'm declaring the following features non-existent in 3.7.1 for now:

- Wavefront OBJ import
- two-parameter `brilliance`

The former is simply not finalized syntax-wise; my plan is to replace it
with a more generic import statement, which would then presumably return
a dictionary of objects that could be manipulated further. However, I
don't see myself finding the time soon to implement that.

The latter is a kludge to make another kludge less kludgey, and I expect
it to become obsoleted comparatively soon by those advanced diffuse
models already in the pipeline (Oren-Nayar, Lommel-Seeliger and Minnaert
at the moment), which can presumably achieve similar effects yet are
methematically and scientifically much more sound.

I'm leaving the code in there for now, just disabled with a preprocessor
switch.


The background is that I'd like to get the master branch back into a
shape where we could release a beta at a moment's notice, and I just
wouldn't be happy to include those two features in their present state.

[clipka] Re: dictionary container types [3408 days 3 hours and 54 minutes ago]

Tue, 13 Dec 2016 09:17:02 GMT

Am 22.11.2016 um 08:35 schrieb Mike Horvath:
> On 11/19/2016 7:34 PM, clipka wrote:
>> Am 20.11.2016 um 01:10 schrieb Mike Horvath:
>>> On 11/19/2016 2:26 PM, clipka wrote:
>>>>     // alternative
>>>>     #declare Fnord = dictionary {
>>>>       .Foo: 42,
>>>>       .Bar: sphere { <0,0,0>, 1 }
>>>>     }
>>>
>>> Will the dotted syntax allow people to use strings like ".declare" or
>>> ".texture"? I don't think it should.
>>
>> No -- just like with variable identifiers, keywords are not allowed
>> there.
> 
> I still think the dot is superfluous.

Think about it:

    #declare Foo = "Dang";
    #declare Bar = "What";

    #declare Fnord = dictionary {
      Foo: 42,
      Bar: sphere { <0,0,0>, 1 }
    }

Which of the following would that supposedly be equivalent to?

(A)

    #declare Fnord = dictionary;
    #declare Fnord.Foo = 42;
    #declare Fnord.Bar = sphere { <0,0,0>, 1 }

(B)

    #declare Fnord = dictionary;
    #declare Fnord[Foo] = 42;
    #declare Fnord[Bar] = sphere { <0,0,0>, 1 }

aka

    #declare Fnord = dictionary;
    #declare Fnord.Dang = 42;
    #declare Fnord.What = sphere { <0,0,0>, 1 }

I think mandating the dot is a nice way to prevent such ambiguity; plus,
it makes things a tiny bit more consistent: Whatever you'd normally put
after the dictionary identifier, you just pop it into the initializer.

[Jim Holsenback] Re: That Perfectly Useless Wiki Page & Namespace [3408 days 12 hours and 18 minutes ago]

Tue, 13 Dec 2016 00:53:00 GMT

On 12/12/2016 12:33 PM, clipka wrote:
> Say, what's up with the http://wiki.povray.org/content/Keyword page, and
> all the effectively empty pages in the
> http://wiki.povray.org/content/Keyword: namespace it links to?
>
> Can't we ditch them? They keep popping up in search results and looking
> promising, only to utterly disappoint.

probably has something to do with multi-link extension that Thorsten 
added a while back ... i see his brand on those files when i click view 
history. lol ... /i/ ain't touching em

[clipka] Re: Reference:Arrays note about 40 character ide... [3408 days 19 hours and 5 minutes ago]

Mon, 12 Dec 2016 18:05:54 GMT

Am 12.12.2016 um 13:38 schrieb Jim Holsenback:
> On 12/12/2016 6:44 AM, William F Pokorny wrote:
>> Ref:
>>
>> http://wiki.povray.org/content/Reference:Array
>>
>> I believe identifiers can be longer than 40 characters & that we've
>> recently added such notes elsewhere. Perhaps we need not mention the
>> identifier limit specifically for arrays should we want to avoid another
>> change note.
> 
> i've already addressed that here:
> http://wiki.povray.org/content/Reference_Talk:Array
> 
> but haven't moved it over yet ... was waiting for some kind of heads up
> that the other feature add/change was going to make it into release branch

Then let it hereby be known that flexible-size arrays, mixed-type arrays
and dictionaries have joined the master branch on November 25th. ;)

Also included are two pseudo-dictionaries, `local` and `global`,
representing the "most local" identifiers and the global identifiers,
respectively. For example:

    #declare local.Foo = 4711;
    #undef global.Foo;

will declare a local variable named "Foo", and undefine any global
variable of the same name, respectively.

*NOTE*: These pseudo-dictionaries *REPLACE* the `local()` and `global()`
pseudo-functions, which are currently mentioned in the tutorial's "New
features" section, the "Identifier Name Collisions" section in the
reference page on #declare and #local, and in the "Optional Parameters"
section in the reference page on macros.

[clipka] That Perfectly Useless Wiki Page & Namespace [3408 days 19 hours and 38 minutes ago]

Mon, 12 Dec 2016 17:33:09 GMT

Say, what's up with the http://wiki.povray.org/content/Keyword page, and
all the effectively empty pages in the
http://wiki.povray.org/content/Keyword: namespace it links to?

Can't we ditch them? They keep popping up in search results and looking
promising, only to utterly disappoint.

[William F Pokorny] Re: Reference:Arrays note about 40 character ide... [3408 days 23 hours and 12 minutes ago]

Mon, 12 Dec 2016 13:58:40 GMT

On 12/12/2016 07:38 AM, Jim Holsenback wrote:
> On 12/12/2016 6:44 AM, William F Pokorny wrote:
>> Ref:
>>
>> http://wiki.povray.org/content/Reference:Array
>>
>> I believe identifiers can be longer than 40 characters & that we've
>> recently added such notes elsewhere. Perhaps we need not mention the
>> identifier limit specifically for arrays should we want to avoid another
>> change note.
>
> i've already addressed that here:
> http://wiki.povray.org/content/Reference_Talk:Array
>
> but haven't moved it over yet ... was waiting for some kind of heads up
> that the other feature add/change was going to make it into release branch
>
I didn't think to look there - cool! :-)

Bill P.

[Jim Holsenback] Re: Reference:Arrays note about 40 character ide... [3409 days and 32 minutes ago]

Mon, 12 Dec 2016 12:38:55 GMT

On 12/12/2016 6:44 AM, William F Pokorny wrote:
> Ref:
>
> http://wiki.povray.org/content/Reference:Array
>
> I believe identifiers can be longer than 40 characters & that we've
> recently added such notes elsewhere. Perhaps we need not mention the
> identifier limit specifically for arrays should we want to avoid another
> change note.

i've already addressed that here: 
http://wiki.povray.org/content/Reference_Talk:Array

but haven't moved it over yet ... was waiting for some kind of heads up 
that the other feature add/change was going to make it into release branch

[William F Pokorny] Reference:Arrays note about 40 character identif... [3409 days 1 hour and 26 minutes ago]

Mon, 12 Dec 2016 11:44:25 GMT

Ref:

http://wiki.povray.org/content/Reference:Array

There is this:

Where IDENTIFIER is the name of the identifier up to 40 characters long 
and INT is a valid float expression which is internally truncated to an 
integer which specifies the size of the array.

I believe identifiers can be longer than 40 characters & that we've 
recently added such notes elsewhere. Perhaps we need not mention the 
identifier limit specifically for arrays should we want to avoid another 
change note.

Bill P.

[Jim Holsenback] Re: Document -CC/+CC command line andCreate_Cont... [3410 days 22 hours and 24 minutes ago]

Sat, 10 Dec 2016 14:46:31 GMT

On 12/9/2016 1:14 PM, William F Pokorny wrote:
> On 12/08/2016 01:42 PM, clipka wrote:
>> Am 08.12.2016 um 17:37 schrieb Jim Holsenback:
>>> On 12/8/2016 11:35 AM, Jim Holsenback wrote:
>>>> i see from wiki history that i removed these back in sep 2013. besides
>>>> the feature listing there was also some narrative as well. rather than
>>>> restore all that and document as deprecated ... how about a well placed
>>>> "Note" instead
>>>
>>>
http://wiki.povray.org/content?title=Reference:Display_Output_Options&diff=8385&oldid=8161
>>>
>>
>> Still accepted on the command line and in INI files, so might bring a
>> short description back in. Something to the effect that
>> platform-specific versions /may/ use these parameters for blah-blah.
>>
>> (For instance - but please don't put this in the docs - the `+Dn`
>> setting might be revived by some future version to choose between a
>> windowed (sized to image), maximized (sized to screen) and fullscren (no
>> taskbar and such) mode for the preview.)
>>
>
> I couldn't pick up any note with these old eyes. I agree with Christoph
> that bringing back a short description instead of the whole mess is
> probably in order.
>
> Bill P.

i just went ahead and restored the whole thing and clarified the status: 
http://wiki.povray.org/content/Reference:Display_Output_Options#Display_Hardware_Settings

[William F Pokorny] Re: System output type (S), aka sys, supported o... [3411 days 2 hours and 13 minutes ago]

Sat, 10 Dec 2016 10:57:35 GMT

On 12/09/2016 02:07 PM, Thorsten Froehlich wrote:
> Just because you do not see any code supporting "s" on other platforms now, does
> not mean it was not there in the past. That is the point about legacy support
> after all ;-) The documentation is correct.
>

Alright, Thanks.

Bill P.

[Thorsten Froehlich] Re: System output type (S), aka sys, supported o... [3411 days 18 hours and 1 minute ago]

Fri, 9 Dec 2016 19:10:01 GMT

Just because you do not see any code supporting "s" on other platforms now, does
not mean it was not there in the past. That is the point about legacy support
after all ;-) The documentation is correct.

William F Pokorny <ano### [at] anonymousorg> wrote:
> On the page:
>
> http://wiki.povray.org/content/Reference:File_Output_Options
>
> we talk about :
>
> .. S System-specific format: See the notation at the end of this section.
>
> and at the end of the section we have this:
>
> Note: System-specific or type "s" output file format is being retained
> for legacy support reasons. Windows and Unix mapping remains the same,
> BMP and TGA respectively, however on Macintosh it has been changed to
> PNG, and a warning is issued when type "s" is used.
>
> +FS or Output_File_Type=S die outright for syntax on my linux Ubuntu
> machine in 3.7 and 3.71 master.
>
> When I look at the code the only platform where I see build support (the
> right set of #declares) to get image sys image support is windows. I see
> no indication of a warning being generated in any case,
> but perhaps I missed it in the code.
>
> I think the note should read something like:
>
> Note: System-specific or type "s" output file format is being retained
> for legacy support reasons on the Windows versions of POV-Ray and the
> type remains BMP.
>
> Bill P.

[William F Pokorny] System output type (S), aka sys, supported only ... [3411 days 18 hours and 45 minutes ago]

Fri, 9 Dec 2016 18:25:56 GMT

On the page:

http://wiki.povray.org/content/Reference:File_Output_Options

we talk about :

.. S System-specific format: See the notation at the end of this section.

and at the end of the section we have this:

Note: System-specific or type "s" output file format is being retained 
for legacy support reasons. Windows and Unix mapping remains the same, 
BMP and TGA respectively, however on Macintosh it has been changed to 
PNG, and a warning is issued when type "s" is used.

+FS or Output_File_Type=S die outright for syntax on my linux Ubuntu 
machine in 3.7 and 3.71 master.

When I look at the code the only platform where I see build support (the 
right set of #declares) to get image sys image support is windows. I see 
no indication of a warning being generated in any case,
but perhaps I missed it in the code.

I think the note should read something like:

Note: System-specific or type "s" output file format is being retained 
for legacy support reasons on the Windows versions of POV-Ray and the 
type remains BMP.

Bill P.

[William F Pokorny] Re: Document -CC/+CC command line andCreate_Cont... [3411 days 18 hours and 56 minutes ago]

Fri, 9 Dec 2016 18:14:43 GMT

On 12/08/2016 01:42 PM, clipka wrote:
> Am 08.12.2016 um 17:37 schrieb Jim Holsenback:
>> On 12/8/2016 11:35 AM, Jim Holsenback wrote:
>>> i see from wiki history that i removed these back in sep 2013. besides
>>> the feature listing there was also some narrative as well. rather than
>>> restore all that and document as deprecated ... how about a well placed
>>> "Note" instead
>>
>>
http://wiki.povray.org/content?title=Reference:Display_Output_Options&diff=8385&oldid=8161
>
> Still accepted on the command line and in INI files, so might bring a
> short description back in. Something to the effect that
> platform-specific versions /may/ use these parameters for blah-blah.
>
> (For instance - but please don't put this in the docs - the `+Dn`
> setting might be revived by some future version to choose between a
> windowed (sized to image), maximized (sized to screen) and fullscren (no
> taskbar and such) mode for the preview.)
>

I couldn't pick up any note with these old eyes. I agree with Christoph 
that bringing back a short description instead of the whole mess is 
probably in order.

Bill P.

[clipka] Re: Document -CC/+CC command line andCreate_Cont... [3412 days 18 hours and 28 minutes ago]

Thu, 8 Dec 2016 18:43:05 GMT

Am 08.12.2016 um 17:37 schrieb Jim Holsenback:
> On 12/8/2016 11:35 AM, Jim Holsenback wrote:
>> i see from wiki history that i removed these back in sep 2013. besides
>> the feature listing there was also some narrative as well. rather than
>> restore all that and document as deprecated ... how about a well placed
>> "Note" instead
> 
>
http://wiki.povray.org/content?title=Reference:Display_Output_Options&diff=8385&oldid=8161

Still accepted on the command line and in INI files, so might bring a
short description back in. Something to the effect that
platform-specific versions /may/ use these parameters for blah-blah.

(For instance - but please don't put this in the docs - the `+Dn`
setting might be revived by some future version to choose between a
windowed (sized to image), maximized (sized to screen) and fullscren (no
taskbar and such) mode for the preview.)

[Jim Holsenback] Re: Document -CC/+CC command line andCreate_Cont... [3412 days 20 hours and 33 minutes ago]

Thu, 8 Dec 2016 16:37:27 GMT

On 12/8/2016 11:35 AM, Jim Holsenback wrote:
> i see from wiki history that i removed these back in sep 2013. besides
> the feature listing there was also some narrative as well. rather than
> restore all that and document as deprecated ... how about a well placed
> "Note" instead

http://wiki.povray.org/content?title=Reference:Display_Output_Options&diff=8385&oldid=8161

[Jim Holsenback] Re: Document -CC/+CC command line and Create_Con... [3412 days 20 hours and 35 minutes ago]

Thu, 8 Dec 2016 16:35:11 GMT

On 12/8/2016 8:41 AM, William F Pokorny wrote:
> "Documentation indicates:"
>
> The list starts off with a set of 4 features our documentation has as
> available which are not in 3.7. I think the documentation should
> probably indicate these as Deprecated for the time being.

http://wiki.povray.org/content/Reference:Animation_Options#Field_Rendering

http://wiki.povray.org/content/Reference:General_Output_Options#Interrupting_Options
>
> The two undocumented features near the bottom of the block should
> probably be restored to the documentation and also listed as Deprecated.
> Our code allows them to exist - and they no doubt do - in old ini files.

i see from wiki history that i removed these back in sep 2013. besides 
the feature listing there was also some narrative as well. rather than 
restore all that and document as deprecated ... how about a well placed 
"Note" instead

> Just below the block, in parens, I wonder about the text we have in the
> documentation about the very old and long gone Buffer_output and
> Buffer_Size options. Thinking it should just be deleted - yep, I missed
> documenting where I saw that text...

http://wiki.povray.org/content/Reference:File_Output_Options#Output_File_Buffer

besides the content there's only a couple of other places that need to 
be touched to just get rid of it altogether ... nuke it?

> I've used the term "Deprecated" to be consistent with other
> documentation, but I believe all options marked this way are "Deprecated
> and Non-functional." Perhaps we should better indicate this.

i'm ok with this term mainly because it /is/ consistent with what's been 
done so far ... only possible drawback is confusion with /deprecated/ 
keyword. as long as <code> is used when taking about keyword and <em> is 
used otherwise i think we should be fine

[clipka] Re: Document -CC/+CC command line and Create_Con... [3412 days 21 hours and 42 minutes ago]

Thu, 8 Dec 2016 15:28:36 GMT

Am 08.12.2016 um 14:41 schrieb William F Pokorny:

> I don't know what to do with Antialias_Gamma_type as it didn't look to
> me like end users have ever seen it documented in any fashion, but
> others might know differently. I'd say leave it completely out of the
> documentation pending any other information.

kPOVAttrib_AntialiasGammaType is just a (placeholder) companion to
kPOVAttrib_AntialiasGamma, just as kPOVAttrib_FileGammaType is a
(genuine) companion to kPOVAttrib_FileGamma. The latter two combine to
convey the information provided via the "File_Gamma" setting (with
kPOVAttrib_FileGammaType being used to convey special values such as
"sRGB"). Since "Antialias_Gamma" currently only supports float values,
the type portion is unused.

[William F Pokorny] isosurface all_intersections documentation. [3412 days 23 hours and 24 minutes ago]

Thu, 8 Dec 2016 13:46:42 GMT

(Not really all) Please see:

http://news.povray.org/povray.bugreports/message/%3C584874e0%241%40news.povray.org%3E/#%3C584874e0%241%40news.povray.org%3E

Bill P.

[William F Pokorny] Re: Document -CC/+CC command line and Create_Con... [3412 days 23 hours and 29 minutes ago]

Thu, 8 Dec 2016 13:41:12 GMT

On 12/07/2016 07:38 AM, Jim Holsenback wrote:
> On 12/6/2016 6:43 AM, William F Pokorny wrote:
>
> like what? might as well see if i can address those while i'm over there
> anyways
>

OK. Might be some thinking aloud on my part. Take a look at my comment to :

https://github.com/POV-Ray/povray/issues/167

and specifically within that comment the block with the leader:

"Documentation indicates:"

The list starts off with a set of 4 features our documentation has as 
available which are not in 3.7. I think the documentation should 
probably indicate these as Deprecated for the time being.

The two undocumented features near the bottom of the block should 
probably be restored to the documentation and also listed as Deprecated. 
Our code allows them to exist - and they no doubt do - in old ini files.

I don't know what to do with Antialias_Gamma_type as it didn't look to 
me like end users have ever seen it documented in any fashion, but 
others might know differently. I'd say leave it completely out of the 
documentation pending any other information.

Just below the block, in parens, I wonder about the text we have in the 
documentation about the very old and long gone Buffer_output and 
Buffer_Size options. Thinking it should just be deleted - yep, I missed 
documenting where I saw that text...

I've used the term "Deprecated" to be consistent with other 
documentation, but I believe all options marked this way are "Deprecated 
and Non-functional." Perhaps we should better indicate this.

There are further questions about how our code is handling many of these 
non-functioning option - you'll see I rolled a flyspray issue I think 
you opened into this github issue - but I don't think this is the 
newsgroup / issue in which to work those out.

I think a good first step with github #167 is to do some documentation 
updates to reflect the status today.

Bill P.

[clipka] Re: Document -CC/+CC command line and Create_Con... [3413 days 20 hours and 49 minutes ago]

Wed, 7 Dec 2016 16:21:52 GMT

Hi folks,

Am 07.12.2016 um 13:38 schrieb Jim Holsenback:
> On 12/6/2016 6:43 AM, William F Pokorny wrote:
>> Per recent discussions and issue work I think we should document the -CC
>> option.
> 
> agreed ... i recall this feature being added but don't remember when. at
> first i thought back in 3.7 when Max_Image_Buffer_Memory was added but
> after looking i don't think so ... 3.7.1??

Just did a quick code compare: 3.7.1 it is.

[Jim Holsenback] Re: Document -CC/+CC command line and Create_Con... [3414 days and 32 minutes ago]

Wed, 7 Dec 2016 12:39:00 GMT

On 12/6/2016 6:43 AM, William F Pokorny wrote:
> Per recent discussions and issue work I think we should document the -CC
> option.

agreed ... i recall this feature being added but don't remember when. at 
first i thought back in 3.7 when Max_Image_Buffer_Memory was added but 
after looking i don't think so ... 3.7.1??

> I think it comes to adding something like :
>
> ---
>
> Create_Continue_Trace_Log=bool  Save state information in file on/off
> +CC Save state information in file on
> -CC Save state information in file off
>
> The state or continue trave information file must exist for the
> Continue_Trace=true / +C option to work.

yep ... thanks

> to the section:
>
> http://wiki.povray.org/content/Reference:General_Output_Options#Resuming_Options
>
>
> Also in that section we today have this bit:
>
> "This option reads in the previously generated output file, displays the
> partial image rendered so far, then proceeds with the ray-tracing. This
> option cannot be used if file output is disabled with Output_to_file=off
> or -F."
>
> However, I think "Output_to_file=off or -F" suppresses the creation of
> the final output image file not the state/log file needed to continue a
> trace. Thinking we might re-work the above paragraph to refer to the
> state/log file instead and drop reference to the output to file option
> here.

good catch ... think you're correct about -F

>
> Aside: There are other documentation updates sitting in the two
> references above, but thinking we should go after those later in
> dedicated threads for sake of clarity.

like what? might as well see if i can address those while i'm over there 
anyways

[William F Pokorny] Document -CC/+CC command line and Create_Continu... [3415 days 1 hour and 27 minutes ago]

Tue, 6 Dec 2016 11:43:26 GMT

Per recent discussions and issue work I think we should document the -CC 
option.

Reference :

http://news.povray.org/povray.windows/message/%3C584605a0%241%40news.povray.org%3E/#%3C584605a0%241%40news.povray.org%3E

and

https://github.com/POV-Ray/povray/issues/167

I think it comes to adding something like :

---

Create_Continue_Trace_Log=bool  Save state information in file on/off
+CC Save state information in file on
-CC Save state information in file off

The state or continue trave information file must exist for the 
Continue_Trace=true / +C option to work.

---

to the section:

http://wiki.povray.org/content/Reference:General_Output_Options#Resuming_Options

Also in that section we today have this bit:

"This option reads in the previously generated output file, displays the 
partial image rendered so far, then proceeds with the ray-tracing. This 
option cannot be used if file output is disabled with Output_to_file=off 
or -F."

However, I think "Output_to_file=off or -F" suppresses the creation of 
the final output image file not the state/log file needed to continue a 
trace. Thinking we might re-work the above paragraph to refer to the 
state/log file instead and drop reference to the output to file option 
here.

Aside: There are other documentation updates sitting in the two 
references above, but thinking we should go after those later in 
dedicated threads for sake of clarity.

Bill P.

[William F Pokorny] Re: Stumbled across #version unofficial 3.71; su... [3425 days 21 hours and 46 minutes ago]

Fri, 25 Nov 2016 15:24:48 GMT

On 11/23/2016 11:32 AM, clipka wrote:
> Am 23.11.2016 um 17:03 schrieb William F Pokorny:
>
> That keyword has effectively been around for ages -- it just wasn't
> syntax-highlighted.
>
> Support for this syntax used to be mandatory in patched versions,
> according to the old POV-Ray Modification License
> (http://www.povray.org/source-license-3.6.html).
>
> Official POV-Ray has been supporting this syntax in the sense that it
> gives a special error message upon encountering `#version unofficial`.
>
Thanks. I now see the introduction of 'unofficial' to reservedwords.cpp 
in commit e1e7b0d (Fix GitHub issue #53. include file version...) was a 
code change in support & not a keyword addition.

I'm taking what you wrote to mean "leave 'unoffical' undocumented."

Bill P.

[Jim Holsenback] Re: dictionary container types [3426 days 1 hour and 10 minutes ago]

Fri, 25 Nov 2016 12:00:36 GMT

On 11/24/2016 10:01 AM, clipka wrote:
> Am 24.11.2016 um 15:07 schrieb Jim Holsenback:
>> On 11/23/2016 12:17 PM, clipka wrote:
>>> I think I got you confused
>>
>> lol ... ok enough with the back-and-forth already ;-)
>>
>> not sure why i kept wanting to treat as two different subjects ...
>> hopefully i've cleared things up:
>> http://wiki.povray.org/content/Reference_Talk:Array and we can stick a
>> fork in this one!
>
> Almost there.

argh ... you're stifling my creativity ;-)

[clipka] Re: dictionary container types [3426 days 22 hours and 9 minutes ago]

Thu, 24 Nov 2016 15:01:33 GMT

Am 24.11.2016 um 15:07 schrieb Jim Holsenback:
> On 11/23/2016 12:17 PM, clipka wrote:
>> I think I got you confused
> 
> lol ... ok enough with the back-and-forth already ;-)
> 
> not sure why i kept wanting to treat as two different subjects ...
> hopefully i've cleared things up:
> http://wiki.povray.org/content/Reference_Talk:Array and we can stick a
> fork in this one!

Almost there.


"Additional points to consider are as follows:"

- Please add a note that this is new in 3.7.1. ;)

- I'd remove the "will" from "1. Array elements will no longer...".

- I'd collapse 1.a and 1.b into a single paragraph.

- I'd collapse 3.b and 3.c into a single paragraph.

- I'm noticing only just now that points 4. and 5. apply only to
dictionaries. I think something should be done to make this clearer.

- I'm noticing only just now that 6. is a duplicate of 4.

- I'd add a few end-of-sentence markers (aka full stops) to the items. ;)

- I'd personally prefer a bullet list, as there's no hierarchy among the
items.


Also, I'd move anything related to dictionary initializers to the "Array
Initializers" section, possibly with a line of text or two.

[Jim Holsenback] Re: dictionary container types [3426 days 23 hours and 3 minutes ago]

Thu, 24 Nov 2016 14:08:01 GMT

On 11/23/2016 12:17 PM, clipka wrote:
> I think I got you confused

lol ... ok enough with the back-and-forth already ;-)

not sure why i kept wanting to treat as two different subjects ... 
hopefully i've cleared things up: 
http://wiki.povray.org/content/Reference_Talk:Array and we can stick a 
fork in this one!

[Jim Holsenback] Re: dictionary container types [3427 days 18 hours and 43 minutes ago]

Wed, 23 Nov 2016 18:27:26 GMT

On 11/23/2016 12:17 PM, clipka wrote:
> Am 23.11.2016 um 17:43 schrieb Jim Holsenback:
>> On 11/23/2016 10:04 AM, clipka wrote:
>>> The changes to array syntax and behaviour don't fit into the
>>> "Dictionary" section; they should instead be in the "Array" section.
>>
>> thanks for keeping me honest:
>> http://wiki.povray.org/content/Reference_Talk:Array
>
> I think I got you confused.

no doubt ... back when all this happened i was /not/ following the 
goings on, but now i'm finding time to get caught up.

[clipka] Re: dictionary container types [3427 days 19 hours and 53 minutes ago]

Wed, 23 Nov 2016 17:17:17 GMT

Am 23.11.2016 um 17:43 schrieb Jim Holsenback:
> On 11/23/2016 10:04 AM, clipka wrote:
>> The changes to array syntax and behaviour don't fit into the
>> "Dictionary" section; they should instead be in the "Array" section.
> 
> thanks for keeping me honest:
> http://wiki.povray.org/content/Reference_Talk:Array

I think I got you confused.

The information I provided in the earlier post was for the entire bundle
of changes in the `feature/dictionary` branch currently waiting to be
tested and merged. The branch has grown to become somewhat of a
misnomer, and `feature/containers` would be a more fitting name by now,
as besides introducing the new `dictionary` container type it also
contains improvements to the classic old-school integer-indexed `array`
container.

All the information you put in the numbered-list section starting with
"Array elements will no longer have to be all of the same type [...]"
applies to arrays, not dictionaries.

It's ok (and, if I am asked, desirable) to have the dictionary-related
stuff in a separate section.

Also, typo:

"There has been a Change that removes than restriction."
                                        ^^^

I'm also noticing right now that the comments in the example section are
a bit inconsistent; please replace "testing" and "removing" with "test"
and "remove".

[Jim Holsenback] Re: dictionary container types [3427 days 20 hours and 27 minutes ago]

Wed, 23 Nov 2016 16:43:34 GMT

On 11/23/2016 10:04 AM, clipka wrote:
> The changes to array syntax and behaviour don't fit into the
> "Dictionary" section; they should instead be in the "Array" section.

thanks for keeping me honest: 
http://wiki.povray.org/content/Reference_Talk:Array

[clipka] Re: Stumbled across #version unofficial 3.71; su... [3427 days 20 hours and 38 minutes ago]

Wed, 23 Nov 2016 16:32:26 GMT

Am 23.11.2016 um 17:03 schrieb William F Pokorny:
> While looking at another issue I stumbled across the 'unofficial'
> keyword having been added to the 3.7.1 master branch at some point? This
> isn't the uberpov approach, but suppose it could be useful in marking
> scene files as not working with any official POV-Ray release as in:
> 
> #version unofficial 3.71;
> ....scene here...
> 
> Should this keyword capability be documented?
> 
> Thinking otherwise patch developers are unlikely to know about it except
> by stumbling across it as I just did.

That keyword has effectively been around for ages -- it just wasn't
syntax-highlighted.

Support for this syntax used to be mandatory in patched versions,
according to the old POV-Ray Modification License
(http://www.povray.org/source-license-3.6.html).

Official POV-Ray has been supporting this syntax in the sense that it
gives a special error message upon encountering `#version unofficial`.

[William F Pokorny] Stumbled across #version unofficial 3.71; suppor... [3427 days 21 hours and 7 minutes ago]

Wed, 23 Nov 2016 16:03:22 GMT

While looking at another issue I stumbled across the 'unofficial' 
keyword having been added to the 3.7.1 master branch at some point? This 
isn't the uberpov approach, but suppose it could be useful in marking 
scene files as not working with any official POV-Ray release as in:

#version unofficial 3.71;
...scene here...

Should this keyword capability be documented?

Thinking otherwise patch developers are unlikely to know about it except 
by stumbling across it as I just did.

Bill P.

[clipka] Re: dictionary container types [3427 days 22 hours and 6 minutes ago]

Wed, 23 Nov 2016 15:04:44 GMT

Am 23.11.2016 um 13:11 schrieb Jim Holsenback:
> On 11/22/2016 5:25 PM, Jim Holsenback wrote:
>> On 11/19/2016 2:26 PM, clipka wrote:
>>> for the records:
>>
>> thanks for that ... i went ahead and created a talk page:
>> http://wiki.povray.org/content/Reference_Talk:Array
>>
>> i still need to work the new keyword into the syntax diagram and do an
>> overall review of the rest of the page ... go ahead and work over there
>> if you want to make any changes
> 
> finished page clean up and made a stab at the syntax diagram ... please
> review that to make sure that i haven't forgotten or mis-characterized
> anything

Array:

"[...] IDENTIFIER is the name of the identifier up to 40 characters long
[...]"

That's outdated; there is no hard-coded limit for the length of
identifiers anymore.

"Large uninitialized arrays do not take much memory. Internally they are
arrays of pointers so they probably use just 4 bytes per element"

We should probably update that to "8 bytes per element", to account for
the rise of 64-bit machines.

Dictionary:

The DICTIONARY_DECLARATION syntax implies that a DICTIONARY_INITIALIZER
can only be specified with #declare, not with #local. That is not true:
Both #declare and #local allow for a DICTIONARY_INITIALIZER.

The DICTIONARY_ITEM syntax implies that it can be a
DICTIONARY_INITIALIZER; this is also wrong. The corresponding portion of
the array syntax accounts for the nested initializers of
multi-dimensional arrays, but dictionaries always have just one dimension.

The DICTIONARY_ENTRY syntax implies that it can only be an int, float or
string. This is not the case: Anything you can shove into an array can
also be shoved into a dictionary.

The changes to array syntax and behaviour don't fit into the
"Dictionary" section; they should instead be in the "Array" section.

[Jim Holsenback] Re: dictionary container types [3428 days and 59 minutes ago]

Wed, 23 Nov 2016 12:11:32 GMT

On 11/22/2016 5:25 PM, Jim Holsenback wrote:
> On 11/19/2016 2:26 PM, clipka wrote:
>> for the records:
>
> thanks for that ... i went ahead and created a talk page:
> http://wiki.povray.org/content/Reference_Talk:Array
>
> i still need to work the new keyword into the syntax diagram and do an
> overall review of the rest of the page ... go ahead and work over there
> if you want to make any changes

finished page clean up and made a stab at the syntax diagram ... please 
review that to make sure that i haven't forgotten or mis-characterized 
anything

[Jim Holsenback] Re: dictionary container types [3428 days 14 hours and 45 minutes ago]

Tue, 22 Nov 2016 22:25:11 GMT

On 11/19/2016 2:26 PM, clipka wrote:
> for the records:

thanks for that ... i went ahead and created a talk page: 
http://wiki.povray.org/content/Reference_Talk:Array

i still need to work the new keyword into the syntax diagram and do an 
overall review of the rest of the page ... go ahead and work over there 
if you want to make any changes

[Mike Horvath] Re: dictionary container types [3429 days 5 hours and 35 minutes ago]

Tue, 22 Nov 2016 07:35:40 GMT

On 11/19/2016 7:34 PM, clipka wrote:
> Am 20.11.2016 um 01:10 schrieb Mike Horvath:
>> On 11/19/2016 2:26 PM, clipka wrote:
>>>     // alternative
>>>     #declare Fnord = dictionary {
>>>       .Foo: 42,
>>>       .Bar: sphere { <0,0,0>, 1 }
>>>     }
>>
>> Will the dotted syntax allow people to use strings like ".declare" or
>> ".texture"? I don't think it should.
>
> No -- just like with variable identifiers, keywords are not allowed there.
>

I still think the dot is superfluous.


Mike

[clipka] Re: dictionary container types [3429 days 5 hours and 39 minutes ago]

Tue, 22 Nov 2016 07:31:45 GMT

Am 19.11.2016 um 20:26 schrieb clipka:

>     // testing whether a dictionary contains a particular key
>     // (e.g.)
>     #ifdef (Fnord.["Foo"]) ... #end
>     #declare FooKeyExists = defined(Fnord.Foo);

Of course that should be

    #ifdef (Fnord["Foo"]) ... #end

[Jim Holsenback] Re: Parametric [3429 days 13 hours and 5 minutes ago]

Tue, 22 Nov 2016 00:05:33 GMT

On 11/21/2016 5:05 PM, Mike Horvath wrote:
> On 11/21/2016 4:56 PM, Jim Holsenback wrote:
>> On 11/21/2016 4:00 PM, Mike Horvath wrote:
>>> On 11/21/2016 3:50 PM, Jim Holsenback wrote:
>>>> On 11/21/2016 3:16 PM, Mike Horvath wrote:
>>>>> http://wiki.povray.org/content/Reference:Parametric
>>>>>
>>>>> This page could use a little more info about what are good values for
>>>>> max_gradient, or how to choose a good value.
>>>>
>>>> lol ... ok but first you're going to have to be more specific. what /i
>>>> do/ know about max_gradient is that the value changes with more complex
>>>> the objects. this page is a markup and grammar disaster so i'm going to
>>>> be touching the page anyways.
>>>>
>>>
>>> I don't know how to use max_gradient either. Maybe someone who actually
>>> knows can chime in?
>>
>> like i said ... the max_gradient value changes (increases) the more
>> complex the object is
>>
>
> How complex is more complex?

you're kidding right? i've finished de-shamblizing that page and trying 
out something a little different from the bunch of run on sentences:

http://wiki.povray.org/content/Reference:Parametric

[Mike Horvath] Re: Parametric [3429 days 15 hours and 5 minutes ago]

Mon, 21 Nov 2016 22:05:41 GMT

On 11/21/2016 4:56 PM, Jim Holsenback wrote:
> On 11/21/2016 4:00 PM, Mike Horvath wrote:
>> On 11/21/2016 3:50 PM, Jim Holsenback wrote:
>>> On 11/21/2016 3:16 PM, Mike Horvath wrote:
>>>> http://wiki.povray.org/content/Reference:Parametric
>>>>
>>>> This page could use a little more info about what are good values for
>>>> max_gradient, or how to choose a good value.
>>>
>>> lol ... ok but first you're going to have to be more specific. what /i
>>> do/ know about max_gradient is that the value changes with more complex
>>> the objects. this page is a markup and grammar disaster so i'm going to
>>> be touching the page anyways.
>>>
>>
>> I don't know how to use max_gradient either. Maybe someone who actually
>> knows can chime in?
>
> like i said ... the max_gradient value changes (increases) the more
> complex the object is
>

How complex is more complex?

Mike

[Jim Holsenback] Re: Parametric [3429 days 15 hours and 14 minutes ago]

Mon, 21 Nov 2016 21:56:20 GMT

On 11/21/2016 4:00 PM, Mike Horvath wrote:
> On 11/21/2016 3:50 PM, Jim Holsenback wrote:
>> On 11/21/2016 3:16 PM, Mike Horvath wrote:
>>> http://wiki.povray.org/content/Reference:Parametric
>>>
>>> This page could use a little more info about what are good values for
>>> max_gradient, or how to choose a good value.
>>
>> lol ... ok but first you're going to have to be more specific. what /i
>> do/ know about max_gradient is that the value changes with more complex
>> the objects. this page is a markup and grammar disaster so i'm going to
>> be touching the page anyways.
>>
>
> I don't know how to use max_gradient either. Maybe someone who actually
> knows can chime in?

like i said ... the max_gradient value changes (increases) the more 
complex the object is

[Mike Horvath] Re: Emission [3429 days 16 hours and 5 minutes ago]

Mon, 21 Nov 2016 21:05:21 GMT

On 11/21/2016 3:36 PM, Jim Holsenback wrote:
> On 11/21/2016 1:37 PM, clipka wrote:
>> Am 21.11.2016 um 18:19 schrieb Jim Holsenback:
>>> On 11/21/2016 10:16 AM, Mike Horvath wrote:
>>>> I don't think this is the primary reason to use emission. I think that
>>>> emission is supposed to be used for glowing objects. The wording makes
>>>> it seem like it is just a hack to retain old behavior from POV 3.6.
>>>> This
>>>> is what threw the developer off in the thread I linked to.
>>>
>>> to quote myself from an earlier post in different NG ... mo betta?
>>>
>>> http://wiki.povray.org/content/Reference:Finish#Emission
>>
>> Actually, no -- sorry ;)
>
> it's been fixed bwana ... along with several run-on sentences and bad
> grammar etc ... looked at the entire page
>

That is better but may be too terse.

Mike

[Mike Horvath] Re: Parametric [3429 days 16 hours and 10 minutes ago]

Mon, 21 Nov 2016 21:00:18 GMT

On 11/21/2016 3:50 PM, Jim Holsenback wrote:
> On 11/21/2016 3:16 PM, Mike Horvath wrote:
>> http://wiki.povray.org/content/Reference:Parametric
>>
>> This page could use a little more info about what are good values for
>> max_gradient, or how to choose a good value.
>
> lol ... ok but first you're going to have to be more specific. what /i
> do/ know about max_gradient is that the value changes with more complex
> the objects. this page is a markup and grammar disaster so i'm going to
> be touching the page anyways.
>

I don't know how to use max_gradient either. Maybe someone who actually 
knows can chime in?

Mike

[Jim Holsenback] Re: Parametric [3429 days 16 hours and 20 minutes ago]

Mon, 21 Nov 2016 20:50:30 GMT

On 11/21/2016 3:16 PM, Mike Horvath wrote:
> http://wiki.povray.org/content/Reference:Parametric
>
> This page could use a little more info about what are good values for
> max_gradient, or how to choose a good value.

lol ... ok but first you're going to have to be more specific. what /i 
do/ know about max_gradient is that the value changes with more complex 
the objects. this page is a markup and grammar disaster so i'm going to 
be touching the page anyways.

[Jim Holsenback] Re: Emission [3429 days 16 hours and 34 minutes ago]

Mon, 21 Nov 2016 20:37:01 GMT

On 11/21/2016 1:37 PM, clipka wrote:
> Am 21.11.2016 um 18:19 schrieb Jim Holsenback:
>> On 11/21/2016 10:16 AM, Mike Horvath wrote:
>>> I don't think this is the primary reason to use emission. I think that
>>> emission is supposed to be used for glowing objects. The wording makes
>>> it seem like it is just a hack to retain old behavior from POV 3.6. This
>>> is what threw the developer off in the thread I linked to.
>>
>> to quote myself from an earlier post in different NG ... mo betta?
>>
>> http://wiki.povray.org/content/Reference:Finish#Emission
>
> Actually, no -- sorry ;)

it's been fixed bwana ... along with several run-on sentences and bad 
grammar etc ... looked at the entire page

[Mike Horvath] Parametric [3429 days 16 hours and 54 minutes ago]

Mon, 21 Nov 2016 20:16:48 GMT

http://wiki.povray.org/content/Reference:Parametric

This page could use a little more info about what are good values for 
max_gradient, or how to choose a good value.


Mike

[Mike Horvath] Re: Emission [3429 days 18 hours and 21 minutes ago]

Mon, 21 Nov 2016 18:49:58 GMT

On 11/21/2016 1:37 PM, clipka wrote:
> instead, the new `emission` keyword has
> been added specifically for this purpose.

"instead, the new emission keyword should be used to model glowing objects."

Mike

[clipka] Re: Emission [3429 days 18 hours and 33 minutes ago]

Mon, 21 Nov 2016 18:37:44 GMT

Am 21.11.2016 um 18:19 schrieb Jim Holsenback:
> On 11/21/2016 10:16 AM, Mike Horvath wrote:
>> I don't think this is the primary reason to use emission. I think that
>> emission is supposed to be used for glowing objects. The wording makes
>> it seem like it is just a hack to retain old behavior from POV 3.6. This
>> is what threw the developer off in the thread I linked to.
> 
> to quote myself from an earlier post in different NG ... mo betta?
> 
> http://wiki.povray.org/content/Reference:Finish#Emission

Actually, no -- sorry ;)

"There has been a Change as of version 3.7 that allows you to add the
emission keyword to the finish block. One intention is to simplify the
use of materials designed for non-radiosity scenes that are in scenes
with radiosity, or the design of scenes that can be rendered with or
without radiosity. However, emission can also be used with objects that
are intended to glow."

That description implies that there would be two entirely different use
cases: one radiosity-related, and one related to glowing materials. The
truth is that they are one and the same.


Maybe something like this:

---------------------------------------------
The `emission` keyword, NEW in version 3.7, can be used to model glowing
materials, eliminating the need to co-opt `ambient` for this purpose.

The syntax and effect are virtually identical to `ambient`, except that
`emission` is unaffected by the global `ambient_light` parameter, and is
not turned off when using radiosity.
---------------------------------------------

Also, the "Ambient" section may need a bit of love and care as well; I
suggest replacing the last paragraph before the final note with
something like this:

---------------------------------------------
Ambient light affects both shadowed and non-shadowed areas, so if you
turn up the ambient value, you may want to turn down the diffuse and
reflection values.

There has been a CHANGE as of version 3.7 in that the `ambient`
mechanism is now automatically turned off when radiosity is enabled
(provided `#version` is set to 3.7 or higher), allowing you to use the
same material definitions for both radiosity and non-radiosity scenes.
As a consequence, the practice of co-opting `ambient` to model glowing
materials will no longer work in radiosity scenes and is therefore
strongly discouraged altogether; instead, the new `emission` keyword has
been added specifically for this purpose.
---------------------------------------------

[Jim Holsenback] Re: Emission [3429 days 19 hours and 52 minutes ago]

Mon, 21 Nov 2016 17:19:09 GMT

On 11/21/2016 10:16 AM, Mike Horvath wrote:
> I don't think this is the primary reason to use emission. I think that
> emission is supposed to be used for glowing objects. The wording makes
> it seem like it is just a hack to retain old behavior from POV 3.6. This
> is what threw the developer off in the thread I linked to.

to quote myself from an earlier post in different NG ... mo betta?

http://wiki.povray.org/content/Reference:Finish#Emission

[Mike Horvath] Re: Emission [3429 days 21 hours and 54 minutes ago]

Mon, 21 Nov 2016 15:16:50 GMT

On 11/20/2016 7:45 AM, Jim Holsenback wrote:
> On 11/19/2016 1:23 PM, Mike Horvath wrote:
>> Per this thread:
>>
>> http://forums.ldraw.org/showthread.php?tid=21710&pid=23882&mode=threaded
>>
>> The wording of the docs may not be entirely clear. Not sure what to
>> replace it with, however.
>
>
> hmmm ... not sure if I'm following. With regards to emission passage all
> I'm seeing is a bit of change to the wiki/html markup. Since it was a
> /change/ in behavior at 3.7 I'd emphasize that with the wiki {{Change}}
> template at the beginning of the 1st paragraph. In the 2nd paragraph I'd
> tag the word /except/ with 'em' and it's neighboring /emission/ with
> 'code' so it appears green like the other keywords

The docs say, "The intention is to simplify the use of materials 
designed for non-radiosity scenes in scenes with radiosity, or the 
design of scenes that can be rendered with or without radiosity."

I don't think this is the primary reason to use emission. I think that 
emission is supposed to be used for glowing objects. The wording makes 
it seem like it is just a hack to retain old behavior from POV 3.6. This 
is what threw the developer off in the thread I linked to.


Mike

[Jim Holsenback] Re: Emission [3431 days and 26 minutes ago]

Sun, 20 Nov 2016 12:45:04 GMT

On 11/19/2016 1:23 PM, Mike Horvath wrote:
> Per this thread:
>
> http://forums.ldraw.org/showthread.php?tid=21710&pid=23882&mode=threaded
>
> The wording of the docs may not be entirely clear. Not sure what to
> replace it with, however.

hmmm ... not sure if I'm following. With regards to emission passage all 
I'm seeing is a bit of change to the wiki/html markup. Since it was a 
/change/ in behavior at 3.7 I'd emphasize that with the wiki {{Change}} 
template at the beginning of the 1st paragraph. In the 2nd paragraph I'd 
tag the word /except/ with 'em' and it's neighboring /emission/ with 
'code' so it appears green like the other keywords

[clipka] Re: dictionary container types [3431 days 12 hours and 36 minutes ago]

Sun, 20 Nov 2016 00:34:31 GMT

Am 20.11.2016 um 01:10 schrieb Mike Horvath:
> On 11/19/2016 2:26 PM, clipka wrote:
>>     // alternative
>>     #declare Fnord = dictionary {
>>       .Foo: 42,
>>       .Bar: sphere { <0,0,0>, 1 }
>>     }
> 
> Will the dotted syntax allow people to use strings like ".declare" or
> ".texture"? I don't think it should.

No -- just like with variable identifiers, keywords are not allowed there.

[Mike Horvath] Re: dictionary container types [3431 days 13 hours ago]

Sun, 20 Nov 2016 00:10:11 GMT

On 11/19/2016 2:26 PM, clipka wrote:
>     // alternative
>     #declare Fnord = dictionary {
>       .Foo: 42,
>       .Bar: sphere { <0,0,0>, 1 }
>     }

Will the dotted syntax allow people to use strings like ".declare" or 
".texture"? I don't think it should.

Mike

[clipka] Re: dictionary container types [3431 days 13 hours and 52 minutes ago]

Sat, 19 Nov 2016 23:18:55 GMT

Am 19.11.2016 um 20:26 schrieb clipka:

> It's not in the main branch yet, so should probably not be added to the
> docs yet; however, for the records:

BTW, the syntax can be test-driven with this version:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-x.dictionary.8877243

[William F Pokorny] Re: Documentation for blend_mode and blend_gamma? [3431 days 17 hours and 25 minutes ago]

Sat, 19 Nov 2016 19:45:37 GMT

On 11/19/2016 09:45 AM, Jim Holsenback wrote:
> On 11/18/2016 3:43 PM, William F Pokorny wrote:
>> Christoph mentioned blend_mode elsewhere today. To my knowledge the two
>> options blend_mode and blend_gamma are not yet in our documentation for
>> 3.7.1 and should be I think.
>
> http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Version_3.7.1
>
>
> btw: thanks for pulling the necessary info into your previous post ...
> made the task /much/ easier :-)
>
Thanks Jim, Looks good.

As I looked over these updates I did notice we still have statements 
for the *_maps sections like:

"There may be from 2 to 256 entries in the map."

I believe Christoph eliminated that limit in the 3.7.1 master. Commit 
cf1c3fb :

     Refactored blend map handling
     Removed the hard-coded limit of 256 blend map entries along the way.
...

Bill P.

[clipka] Re: dictionary container types [3431 days 17 hours and 44 minutes ago]

Sat, 19 Nov 2016 19:26:53 GMT

Am 19.11.2016 um 16:38 schrieb Jim Holsenback:
> from discussion Classes/containers in sdl? in p.advanced-users i know
> for a fact that this hasn't been added to docs either ... it was
> mentioned that the syntax is still in flux. i just wanted to post here
> as a reminder to follow up. @Bill ... would you mind following up with a
> link so i can have a look at what we have so far and /maybe/ get started
> on that ... thanks in advance

It's not in the main branch yet, so should probably not be added to the
docs yet; however, for the records:

Arrays will be modified as follows:

- Array elements will no longer have to be all of the same type.
- Caveat: Mixing elements of different type will increase memory
consumption; the increased memory footprint will not revert even if the
array is later set to elements all of the same type.

- An array can be declared without specifying any dimensions; in this
case the array will be one-dimensional and be able to grow in size
dynamically.
- Accessing an element beyond the nominal size of such an array will
automatically increase the nominal size just enough to include that element.
- Caveat: The memory footprint may be twice as high as required for the
current nominal size.
- Caveat: Growth of such an array is triggered by /any/ access to an
element beyond the nominal size; this includes tests such as
`#ifdef(ARRAY[INDEX])`.

Also, so-called "dictionaries" will be added, i.e. containers that map
string keys to arbitrary-type values; if the syntax remains as currently
implemented, it will be as follows:

    // create an empty dictionary
    #declare Fnord = dictionary;

    // create a dictionary with elements
    #declare Fnord = dictionary {
      ["Foo"]: 42,
      ["Bar"]: sphere { <0,0,0>, 1 }
    }

    // alternative
    #declare Fnord = dictionary {
      .Foo: 42,
      .Bar: sphere { <0,0,0>, 1 }
    }

    // access a dictionary element
    #declare Fnord["Foo"] = 42;
    #declare Answer = Fnord["Foo"];

    // alternative
    #declare Fnord.Foo = 42;
    #declare Answer = Fnord.Foo;

    // testing whether a dictionary contains a particular key
    // (e.g.)
    #ifdef (Fnord.["Foo"]) ... #end
    #declare FooKeyExists = defined(Fnord.Foo);

    // removing a key from a dictionary
    // (e.g.)
    #undef Fnord["Foo"];

When using square bracket notation, the keys do not necessarily have to
be string literals, but can be arbitrary string expressions.

When using dot notation, the indices must follow the generic rules for
identifiers.

[Mike Horvath] Emission [3431 days 18 hours and 47 minutes ago]

Sat, 19 Nov 2016 18:23:13 GMT

Per this thread:

http://forums.ldraw.org/showthread.php?tid=21710&pid=23882&mode=threaded

The wording of the docs may not be entirely clear. Not sure what to 
replace it with, however.

Mike

[Jim Holsenback] dictionary container types [3431 days 21 hours and 32 minutes ago]

Sat, 19 Nov 2016 15:38:36 GMT

from discussion Classes/containers in sdl? in p.advanced-users i know 
for a fact that this hasn't been added to docs either ... it was 
mentioned that the syntax is still in flux. i just wanted to post here 
as a reminder to follow up. @Bill ... would you mind following up with a 
link so i can have a look at what we have so far and /maybe/ get started 
on that ... thanks in advance

[Jim Holsenback] Re: Documentation for blend_mode and blend_gamma? [3431 days 22 hours and 25 minutes ago]

Sat, 19 Nov 2016 14:45:24 GMT

On 11/18/2016 3:43 PM, William F Pokorny wrote:
> Christoph mentioned blend_mode elsewhere today. To my knowledge the two
> options blend_mode and blend_gamma are not yet in our documentation for
> 3.7.1 and should be I think.

http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Version_3.7.1

btw: thanks for pulling the necessary info into your previous post ... 
made the task /much/ easier :-)

[William F Pokorny] Documentation for blend_mode and blend_gamma? [3432 days 16 hours and 27 minutes ago]

Fri, 18 Nov 2016 20:43:52 GMT

Christoph mentioned blend_mode elsewhere today. To my knowledge the two 
options blend_mode and blend_gamma are not yet in our documentation for 
3.7.1 and should be I think.

 From the commit there is this:

     Implemented non-linear colour and pigment map interpolation.

     The syntax is changed as follows:

         COLOR_MAP:
           color_map { COLOR_MAP_BODY } | colour_map { COLOR_MAP_BODY }
         COLOR_MAP_BODY:
           COLOR_MAP_IDENTIFIER | [blend_mode INT] [blend_gamma FLOAT] 
COLOR_MAP_ENTRY...

         PIGMENT_MAP:
           pigment_map { PIGMENT_MAP_BODY }
         PIGMENT_MAP_BODY:
           PIGMENT_MAP_IDENTIFIER | [blend_mode INT] [blend_gamma FLOAT] 
PIGMENT_MAP_ENTRY...

     The possible values for blend_mode are as follows:

         0 (default): Colour interpolation is performed working gamma 
space as defined by assumed_gamma.
         1: Colour interpolation is performed in linear colour space.
         2: Colour interpolation is performed in the gamma space defined 
by blend_gamma (defaulting to 2.5).
         3: Chromaticity interpolation is performed in linear space, 
while brightness interpolation is performed in the gamma space defined 
by blend_gamma.

Sorry about the wrapping.

Bill P.

[clipka] Re: New cone and cylinder uv_mapping added to 3.... [3433 days and 14 minutes ago]

Fri, 18 Nov 2016 12:56:26 GMT

Am 18.11.2016 um 12:20 schrieb Mr:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
>> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
>> at:
>>
>> http://wiki.povray.org/content/Reference:UV_Mapping
>>
>> to reflect this. I believe the behavior is essentially like that of the
>> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>>
>> 2) We've decided to leave the uv_mapping of the torus reversed in U
>> relative to other uv_mapping given it has been this way for a long time
>> (early 2000s I think).
>>
>> I think adding a note its mapping is reversed in U with respect to
>> others would be good.
>>
>> Bill P.
> 
> Does this mean the map_type 3 and 4 are in development,
> for POV-Ray, to add more basic mappings to any object even meshes and
> environment textures, like:
> 
> FLAT map_type 0
> SPHERE map_type 1
> TUBE map_type 2?
> CYLINDER?
> CONE?
> any CUBE? or still have to use "warp { cubic }..."

Judging from your question, I presume you're not familiar with POV-Ray's
`uv_mapping` keyword.

You can think of this as a "default warp" that is different for each
primitive.

(A drawback of `uv_mapping`, is that it is only useful for surface
textures, whereas `warp` can also be used for volumetric effects.)

[Mr] Re: New cone and cylinder uv_mapping added to 3.... [3433 days 1 hour and 46 minutes ago]

Fri, 18 Nov 2016 11:25:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
> at:
>
> http://wiki.povray.org/content/Reference:UV_Mapping
>
> to reflect this. I believe the behavior is essentially like that of the
> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>
> 2) We've decided to leave the uv_mapping of the torus reversed in U
> relative to other uv_mapping given it has been this way for a long time
> (early 2000s I think).
>
> I think adding a note its mapping is reversed in U with respect to
> others would be good.
>
> Bill P.

Does this mean the map_type 3 and 4 are in development,
for POV-Ray, to add more basic mappings to any object even meshes and
environment textures, like:

FLAT map_type 0
SPHERE map_type 1
TUBE map_type 2?
CYLINDER?
CONE?
any CUBE? or still have to use "warp { cubic }..."

[William F Pokorny] Re: New cone and cylinder uv_mapping added to 3.... [3433 days 2 hours and 38 minutes ago]

Fri, 18 Nov 2016 10:33:05 GMT

On 11/17/2016 09:12 AM, Jim Holsenback wrote:
> On 11/16/2016 9:54 AM, William F Pokorny wrote:
>> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
>> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
>> at:
>>
>> http://wiki.povray.org/content/Reference:UV_Mapping
>>
>> to reflect this. I believe the behavior is essentially like that of the
>> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>>
>> 2) We've decided to leave the uv_mapping of the torus reversed in U
>> relative to other uv_mapping given it has been this way for a long time
>> (early 2000s I think).
>>
>> I think adding a note its mapping is reversed in U with respect to
>> others would be good.
>
> http://wiki.povray.org/content/Reference:UV_Mapping#Supported_Objects
>
Additions look good to me Jim - thanks.

Bill P.

[Jim Holsenback] Re: New cone and cylinder uv_mapping added to 3.... [3433 days 22 hours and 58 minutes ago]

Thu, 17 Nov 2016 14:12:15 GMT

On 11/16/2016 9:54 AM, William F Pokorny wrote:
> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
> at:
>
> http://wiki.povray.org/content/Reference:UV_Mapping
>
> to reflect this. I believe the behavior is essentially like that of the
> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>
> 2) We've decided to leave the uv_mapping of the torus reversed in U
> relative to other uv_mapping given it has been this way for a long time
> (early 2000s I think).
>
> I think adding a note its mapping is reversed in U with respect to
> others would be good.

http://wiki.povray.org/content/Reference:UV_Mapping#Supported_Objects

[Jim Holsenback] Re: New cone and cylinder uv_mapping added to 3.... [3434 days 19 hours and 26 minutes ago]

Wed, 16 Nov 2016 17:44:54 GMT

On 11/16/2016 12:19 PM, Jim Holsenback wrote:
> On 11/16/2016 9:54 AM, William F Pokorny wrote:
>> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
>> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
>> at:
>>
>> http://wiki.povray.org/content/Reference:UV_Mapping
>>
>> to reflect this. I believe the behavior is essentially like that of the
>> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>>
>> 2) We've decided to leave the uv_mapping of the torus reversed in U
>> relative to other uv_mapping given it has been this way for a long time
>> (early 2000s I think).
>>
>> I think adding a note its mapping is reversed in U with respect to
>> others would be good.
>
> started a new section:
> http://wiki.povray.org/content/Reference_Talk:UV_Mapping#Supported_Objects_Updates
>
>
> i'll keep an eye on that then do the updates later
>
disregard ... i /should/ be able to glean enough from discussion in 
p.beta-test

lol ... think i'll take a nap. dang must be getting old!

[Jim Holsenback] Re: New cone and cylinder uv_mapping added to 3.... [3434 days 19 hours and 51 minutes ago]

Wed, 16 Nov 2016 17:19:49 GMT

On 11/16/2016 9:54 AM, William F Pokorny wrote:
> 1) Cone and cylinder uv_mapping have been added to the 3.7.1 master
> branch compliments of JÃ©rÃ´me. We'll need to update the
supported objects
> at:
>
> http://wiki.povray.org/content/Reference:UV_Mapping
>
> to reflect this. I believe the behavior is essentially like that of the
> recently add lemon uv_mapping - but JÃ©rÃ´me knows best.
>
> 2) We've decided to leave the uv_mapping of the torus reversed in U
> relative to other uv_mapping given it has been this way for a long time
> (early 2000s I think).
>
> I think adding a note its mapping is reversed in U with respect to
> others would be good.

started a new section: 
http://wiki.povray.org/content/Reference_Talk:UV_Mapping#Supported_Objects_Updates

i'll keep an eye on that then do the updates later

[William F Pokorny] New cone and cylinder uv_mapping added to 3.7.1 ... [3434 days 22 hours and 16 minutes ago]

Wed, 16 Nov 2016 14:54:31 GMT

1) Cone and cylinder uv_mapping have been added to the 3.7.1 master 
branch compliments of JÃ©rÃ´me. We'll need to update the supported
objects 
at:

http://wiki.povray.org/content/Reference:UV_Mapping

to reflect this. I believe the behavior is essentially like that of the 
recently add lemon uv_mapping - but JÃ©rÃ´me knows best.

2) We've decided to leave the uv_mapping of the torus reversed in U 
relative to other uv_mapping given it has been this way for a long time 
(early 2000s I think).

I think adding a note its mapping is reversed in U with respect to 
others would be good.

Bill P.

[Jim Holsenback] Re: New 3.7.1 global keyword not in keyword sect... [3435 days and 39 minutes ago]

Wed, 16 Nov 2016 12:31:19 GMT

On 11/16/2016 7:19 AM, William F Pokorny wrote:
> On 11/15/2016 11:17 AM, William F Pokorny wrote:
>> Looks like the new global() keyword discussed along with the new local()
>> one at:
>>
>>
http://wiki.povray.org/content/Reference:Declare_and_Local_Directives#Identifier_Name_Collisions
>>
>>
>> is not listed in the keywords at:
>>
>> http://wiki.povray.org/content/Reference:Keywords
>>
>> Aside: the local keyword was already pointing to that section.
>>
>> Bill P.
>
> Thanks much Jim! :-)

LOL ... saw it before i replied

[Jim Holsenback] Re: New 3.7.1 global keyword not in keyword sect... [3435 days and 41 minutes ago]

Wed, 16 Nov 2016 12:29:26 GMT

On 11/15/2016 11:17 AM, William F Pokorny wrote:
> Looks like the new global() keyword discussed along with the new local()
> one at:
>
>
>
http://wiki.povray.org/content/Reference:Declare_and_Local_Directives#Identifier_Name_Collisions
>
>
> is not listed in the keywords at:
>
> http://wiki.povray.org/content/Reference:Keywords
>
> Aside: the local keyword was already pointing to that section.

since #local and local are two different animals i added an additional 
entry in keywords section ... also added global

BOTH are now mentioned here: 
http://wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary

[William F Pokorny] Re: New 3.7.1 global keyword not in keyword sect... [3435 days and 51 minutes ago]

Wed, 16 Nov 2016 12:19:50 GMT

On 11/15/2016 11:17 AM, William F Pokorny wrote:
> Looks like the new global() keyword discussed along with the new local()
> one at:
>
>
http://wiki.povray.org/content/Reference:Declare_and_Local_Directives#Identifier_Name_Collisions
>
> is not listed in the keywords at:
>
> http://wiki.povray.org/content/Reference:Keywords
>
> Aside: the local keyword was already pointing to that section.
>
> Bill P.

Thanks much Jim! :-)

[William F Pokorny] New 3.7.1 global keyword not in keyword section. [3435 days 20 hours and 54 minutes ago]

Tue, 15 Nov 2016 16:17:02 GMT

Looks like the new global() keyword discussed along with the new local() 
one at:

 
http://wiki.povray.org/content/Reference:Declare_and_Local_Directives#Identifier_Name_Collisions

is not listed in the keywords at:

http://wiki.povray.org/content/Reference:Keywords

Aside: the local keyword was already pointing to that section.

Bill P.

[William F Pokorny] Re: Remaining documentation question for FS#226 [3461 days 23 hours and 33 minutes ago]

Thu, 20 Oct 2016 13:37:37 GMT

On 10/19/2016 01:11 PM, clipka wrote:
> Am 19.10.2016 um 13:56 schrieb William F Pokorny:
>> The remaining question for the still open FlySpray issue 214 was whether
>> to better document which of the old X11 flags no longer functioned due
>> the use of the Simple DirectMedia Library for display.
> ...
>
>> I've closed the issue and the information above can be added to the
>> documentation - or not. My personal opinion is we probably should add at
>> least a sentence saying explicitly not all the listed X11 supported
>> options will work as expected - something the known bugs link implies
>> but doesn't say outright.
>
> In my personal opinion, I think we should properly amputate any
> remaining code related to X11 options (if still present) -- either by
> deletion or via "#ifdef", depending on whether we want to retain the
> option to ever revive the code -- and then strip all reference to the
> options from the docs.
>
I'm not up on X11 history, but given the length of time we have now been 
using the Simple DirectMedia Layer (SDL) alternative, I lean this way too.

I hedge some because I still occasionally see flaky behavior with SDL 
V1.2. Some of that I suspect is due the V1.2 SDL library and some of I 
think is probably due our current code not closing down SDL as cleanly 
as it could(1).

I've been reading up on and playing with SDL V2.0 on the side. My plan 
is to get my own daily version of povray onto SDL V2.0 to take it for a 
test drive, but we'll see. If I get the V2 library going, I'll open up a 
related github issue.

Bill P.

(1) - One reason for pull request #109 is that I have been for years 
using cntl-c on unix to quit renders early. Slowly, I came to suspect it 
was occasionally after these aborts that I would find my windowing 
messed up in not updating properly or at all. The 'q' key is a more 
organized way to quit, but I didn't know it was active during a 
previewed render by the current unix console messages. I'm now trying to 
use 'q' only to quit to see if I see the window update issue less, but 
I'm finding my cntl-c quit-fingering-memory habit hard to break.

[clipka] Re: Remaining documentation question for FS#226 [3462 days 19 hours and 59 minutes ago]

Wed, 19 Oct 2016 17:11:47 GMT

Am 19.10.2016 um 13:56 schrieb William F Pokorny:
> The remaining question for the still open FlySpray issue 214 was whether
> to better document which of the old X11 flags no longer functioned due
> the use of the Simple DirectMedia Library for display.
...

> I've closed the issue and the information above can be added to the
> documentation - or not. My personal opinion is we probably should add at
> least a sentence saying explicitly not all the listed X11 supported
> options will work as expected - something the known bugs link implies
> but doesn't say outright.

In my personal opinion, I think we should properly amputate any
remaining code related to X11 options (if still present) -- either by
deletion or via "#ifdef", depending on whether we want to retain the
option to ever revive the code -- and then strip all reference to the
options from the docs.

[William F Pokorny] Remaining documentation question for FS#226 [3463 days 1 hour and 14 minutes ago]

Wed, 19 Oct 2016 11:56:43 GMT

The remaining question for the still open FlySpray issue 214 was whether 
to better document which of the old X11 flags no longer functioned due 
the use of the Simple DirectMedia Library for display.

The last comment was:

Comment by Grimbert JÃ©rÃ´me (Le_Forgeron) - Friday, 09 December
2011, 
14:28 GMT+5

 From my point of view, the original issue is closed (as now with #5460, 
the offending line would be dumped, the detection of forgotten alias or 
magic macro should be trivial).

The part about the Wiki of Unix options is still open: 3.7 use the SDL 
library, which does not intercept the X11 setting. so -display, -icon 
and so on are not supported. Supported specific options are in the unix 
specific source file (from memory: -help, -version; and their shortcuts).

-display and al. were supported at least in 3.1, and that was before SDL 
library. I do not know when the change occurred (3.5, 3.6, or 3.7)

----------

See: 
http://wiki.povray.org/content/Documentation:Unix_Section_6#Understanding_POV-Ray_Options

In my testing of the listed special unix options do the following:

-display <display_name>  --> Will fail with a command line parse error 
so long as a display name is given. +-display otherwise acts like +-D.

-geometry [WIDTHxHEIGHT][+XOFF+YOFF] --> Fails with a command line parse 
error.

-help --> Works fine.

-icon --> Fails due the -i being seen as specifying a scene file name 
con, unless the scene file comes after -icon in which case things run 
without complaint.

-title <title> --> Fails with a command line parse error.

-visual <visual_type> --> Fails with a command line parse error if a 
visual_type is specified and runs without complaint otherwise.

I've closed the issue and the information above can be added to the 
documentation - or not. My personal opinion is we probably should add at 
least a sentence saying explicitly not all the listed X11 supported 
options will work as expected - something the known bugs link implies 
but doesn't say outright.

I'll be closing the issue with a comment pointing to this thread.

Bill P.

[Jim Holsenback] Re: Orientation and left handed frame [3465 days 15 hours and 22 minutes ago]

Sun, 16 Oct 2016 21:48:32 GMT

On 10/16/2016 4:11 PM, Christian Froeschlin wrote:
> On 16.10.2016 15:59, Jim Holsenback wrote:
>> On 10/15/2016 6:57 PM, Christian Froeschlin wrote:
>>> It may also lead to a bit more pleasing layout as the narrow
>>> paragraph between two images looks a bit odd to me anyway.
>>
>>
http://wiki.povray.org/content/Documentation:Tutorial_Section_2#Understanding_POV-Ray.27s_Coordinate_System
>>
>
> *thumbs up* (haha)

took only one huh before i got it ... and yes i'll pardon the pun in 
this case

[Christian Froeschlin] Re: Orientation and left handed frame [3465 days 16 hours and 59 minutes ago]

Sun, 16 Oct 2016 20:11:11 GMT

On 16.10.2016 15:59, Jim Holsenback wrote:
> On 10/15/2016 6:57 PM, Christian Froeschlin wrote:
>> It may also lead to a bit more pleasing layout as the narrow
>> paragraph between two images looks a bit odd to me anyway.
>
>
http://wiki.povray.org/content/Documentation:Tutorial_Section_2#Understanding_POV-Ray.27s_Coordinate_System

*thumbs up* (haha)

[Jim Holsenback] Re: Orientation and left handed frame [3465 days 23 hours and 11 minutes ago]

Sun, 16 Oct 2016 13:59:36 GMT

On 10/15/2016 6:57 PM, Christian Froeschlin wrote:
> It may also lead to a bit more pleasing layout as the narrow
> paragraph between two images looks a bit odd to me anyway.

http://wiki.povray.org/content/Documentation:Tutorial_Section_2#Understanding_POV-Ray.27s_Coordinate_System

[Christian Froeschlin] Re: Orientation and left handed frame [3466 days 14 hours and 14 minutes ago]

Sat, 15 Oct 2016 22:57:09 GMT

On 07.10.2016 19:58, Jim Holsenback wrote:
>
> 3rd paragraph after the image

A minor thing that struck me about the page layout:

I see two images in a row with a paragraph of text between them

   [Image: LH coord sys] [text about LHS] [Image: Aerobics]

   followed by text about rotation / curling / aerobics

The text about LHS refers to positioning left hand fingers
to match coordinate system which is confusing since it is placed
next to the image showing an entirely different hand position.

Maybe as a quick hack it could be rearranged to

   [Image: LH coord sys] [text about LHS]

   [Image: Aerobics] [text about rotation / curling / aerobics]

It may also lead to a bit more pleasing layout as the narrow
paragraph between two images looks a bit odd to me anyway.

[omniverse] Re: Orientation and left handed frame [3474 days 17 hours and 31 minutes ago]

Fri, 7 Oct 2016 19:40:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Jim Holsenback <spa### [at] nothanksnet> wrote:
>
> > i think you're making this /more/ complicated then it needs to be ...
>
> *** Point the left thumb in the +axis direction, curl the fingers, and that's
> the positive direction of rotation.   ***
>
> A picture or two may be a nice addition, but I don't think anything needs to be
> added to the text or changed.

I was getting a look at the camera 'right' being negative and using a viewpoint
from +z as was mentioned here.

So for any curious people I posted a couple animations showing the difference
from the more typical positive right and -z camera location.

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.57f7f2f38d36d3bfb1933f770%40news.povray.org%3E/

[Jim Holsenback] Re: Orientation and left handed frame [3474 days 19 hours and 12 minutes ago]

Fri, 7 Oct 2016 17:58:38 GMT

On 10/7/2016 12:38 PM, clipka wrote:
> I second this change...

done: 
http://wiki.povray.org/content/Documentation:Tutorial_Section_2#Understanding_POV-Ray.27s_Coordinate_System

3rd paragraph after the image

[Bald Eagle] Re: Orientation and left handed frame [3474 days 20 hours and 31 minutes ago]

Fri, 7 Oct 2016 16:40:00 GMT

Jim Holsenback <spa### [at] nothanksnet> wrote:

> i think you're making this /more/ complicated then it needs to be ...
> experience with the rules of working with coordinates (regardless of
> left or right handiness) is a most basic concept as noted in post from
> Le_Forgeron

Right - anyone who deals with chiral spaces learns whatever convention is used
for that system.

There is a "Right-hand rule" for physics (electromagnetism), engineering, math,
architecture, etc.

The left hand rule for POV-ray ought to be just as straightforward.

*** Point the left thumb in the +axis direction, curl the fingers, and that's
the positive direction of rotation.   ***

A picture or two may be a nice addition, but I don't think anything needs to be
added to the text or changed.

[clipka] Re: Orientation and left handed frame [3474 days 20 hours and 32 minutes ago]

Fri, 7 Oct 2016 16:38:19 GMT

Am 07.10.2016 um 17:08 schrieb lelama:
> 
> After this discussion, I come with a question:
> 
> 
> I was thinking about replacing the folloing sentence in the documentation :
> 
> 
>     "In a right-handed system we use our right hand for the "Aerobics"."
> 
> 
> By the following:
> 
> 
>     When a right-handed system is used in Pov-Ray,  we use our right hand
>     for the "Aerobics", both for the coordinate system
>    and for the rotations.

I second this change...

>     A rotation of 90 degrees around the vector +X sends the vector +Y
>    to the vector +Z, in any system, left handed or right handed.

... but this sentence is both redundant and, for that section of the
docs, overly technical...

>    There is no option to change this behaviour.

... and this is information most members of that section's target
audience won't care about.

Remember that there is such a thing as too much information; people need
to be able to digest the package of information we provide them with,
and this section is part of the docs intended for people who aren't
accustomed to heavy meals.

I guess the reference section about rotations would be a more suitable
place to go into technical details.

[Jim Holsenback] Re: Orientation and left handed frame [3474 days 21 hours and 35 minutes ago]

Fri, 7 Oct 2016 15:35:25 GMT

On 10/7/2016 11:08 AM, lelama wrote:
>  If this is confusing for some people, let's keep the old formulation. 
But if
> it's not confusing, it would be more clear for people who wander whether it is
> possible to play independtly with the coordinate system and the rotations, and
> to people who want to know what may be changed with options.

i think you're making this /more/ complicated then it needs to be ... 
experience with the rules of working with coordinates (regardless of 
left or right handiness) is a most basic concept as noted in post from 
Le_Forgeron

[lelama] Re: Orientation and left handed frame [3474 days 22 hours and 1 minute ago]

Fri, 7 Oct 2016 15:10:00 GMT

After this discussion, I come with a question:


I was thinking about replacing the folloing sentence in the documentation :


    "In a right-handed system we use our right hand for the "Aerobics"."


By the following:


    When a right-handed system is used in Pov-Ray,  we use our right hand
    for the "Aerobics", both for the coordinate system
   and for the rotations.

    A rotation of 90 degrees around the vector +X sends the vector +Y
   to the vector +Z, in any system, left handed or right handed.
   There is no option to change this behaviour.


If this is confusing for some people, let's keep the old formulation. But if
it's not confusing, it would be more clear for people who wander whether it is
possible to play independtly with the coordinate system and the rotations, and
to people who want to know what may be changed with options.

[lelama] Re: Orientation and left handed frame [3477 days 15 hours and 16 minutes ago]

Tue, 4 Oct 2016 21:55:00 GMT

clipka <ano### [at] anonymousorg> wrote:
>
> "The left hand can also be used to determine rotation directions. To do
> this we must perform the famous 'Computer Graphics Aerobics' exercise.
> [...]
> In a right-handed system we use our right hand for the 'Aerobics'."
>
> I think that's clear enough.
>

OKay. I agree that there is no ambiguity.

Laurent.

[lelama] Re: Orientation and left handed frame [3477 days 15 hours and 21 minutes ago]

Tue, 4 Oct 2016 21:50:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
>
> There is no option to change the fact that
> * +y rotated by +quarter of circle +x becomes +z
> * +z rotated by +quarter of circle +y becomes +x
> * +x rotated by +quarter of circle +z becomes +y
>
> Never. Consider it a part of the definition of the base.
>
>

Thanks, this is very clear.

Laurent.

[clipka] Re: Orientation and left handed frame [3477 days 15 hours and 36 minutes ago]

Tue, 4 Oct 2016 21:34:39 GMT

Am 04.10.2016 um 23:05 schrieb lelama:

>> POV-Ray's documentation [...] just
>> documents how POV-Ray does it.
>> [...] other people might experience it as unnecessarily confusing [...]
> 
> The point is not a question of taste, it is about ambiguity. When the camera is
> given a negative right vector, it is not clear what is a positive rotation in
> this context. Only the expert users that are aware that there is a quite uniform
> convention among different disciplines may guess. The other users have to check
> that what they have in mind correspond (or not ) to povray's behaviour. Maybe
> there is a line in the doc that I missed, but I have not seen where I could find
> the solution without trial and error for a camera with a negative right vector.
> 
> Some people consider a  rotation as a geometric concept (screwing/unscrewing),
> like physicists using the corkscrew rule. For instance in france, the corkscrew
> rule is quite common, probably because of the wine ;-) These people will
> probably guess that povray keeps the same screwing/unscrewing convention for a
> negative right vector and for a positive right vector. And they will be wrong.
> When a negative right vector is used, povray keeps the same algebraic formulas
> for the rotations and toggles the corkscrew rule. The other choice (toggling the
> formulas and keeping the corkscrew rule ) woud have been possible too.

"The left hand can also be used to determine rotation directions. To do
this we must perform the famous 'Computer Graphics Aerobics' exercise.
[...]
In a right-handed system we use our right hand for the 'Aerobics'."

I think that's clear enough.

If for some reason you ignore the hand-based description in favour of
some other culture-specific rule, and then get confused because your
culture-specific rule doesn't cover questions that are answered quite
clearly in the hand-based description, I wouldn't call that a fault of
the POV-Ray documentation.

[lelama] Re: Orientation and left handed frame [3477 days 16 hours and 1 minute ago]

Tue, 4 Oct 2016 21:10:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> Actually this is not a matter of choice of the coordinate system -- it
> is a matter of choice of how to represent rotations.
>

Agree with that.

> As Jerome already mentioned, there is a very strong consensus across
> disciplines of theoretical and applied science of what constitutes
> positive rotation

OK, didn't know that. Thanks for the remark.

> POV-Ray's documentation [...] just
> documents how POV-Ray does it.
> [...] other people might experience it as unnecessarily confusing [...]

The point is not a question of taste, it is about ambiguity. When the camera is
given a negative right vector, it is not clear what is a positive rotation in
this context. Only the expert users that are aware that there is a quite uniform
convention among different disciplines may guess. The other users have to check
that what they have in mind correspond (or not ) to povray's behaviour. Maybe
there is a line in the doc that I missed, but I have not seen where I could find
the solution without trial and error for a camera with a negative right vector.

Some people consider a  rotation as a geometric concept (screwing/unscrewing),
like physicists using the corkscrew rule. For instance in france, the corkscrew
rule is quite common, probably because of the wine ;-) These people will
probably guess that povray keeps the same screwing/unscrewing convention for a
negative right vector and for a positive right vector. And they will be wrong.
When a negative right vector is used, povray keeps the same algebraic formulas
for the rotations and toggles the corkscrew rule. The other choice (toggling the
formulas and keeping the corkscrew rule ) woud have been possible too.

[clipka] Re: Orientation and left handed frame [3477 days 19 hours and 58 minutes ago]

Tue, 4 Oct 2016 17:12:58 GMT

Am 04.10.2016 um 18:09 schrieb lelama:

> The doc says that povray is a left handed system and uses the left hand for both
> the axis relative locations and the rotations. It was not clear to me when I
> read the doc whether I can change the default behaviour and use the left hand
> for the axis and the right hand for the roations.

You cannot.

> The default choices are clearly documented. But, what if we change the default
> convention ?  I see no place in the doc where it is written if we can make the
> choices for the axis and for the rotations independently.

Actually this is not a matter of choice of the coordinate system -- it
is a matter of choice of how to represent rotations.

As Jerome already mentioned, there is a very strong consensus across
disciplines of theoretical and applied science of what constitutes
positive rotation around an arbitrary vector in any given coordinate
system. Tools produced by individual laymen may occasionally deviate
from this consensus, but so far I haven't seen any professional,
semi-professional or even major hobbyist tool that implements rotation
differently.

POV-Ray's documentation therefore does not make much effort to explain
that there is, in theory, a choice to be made there, and instead just
documents how POV-Ray does it.

You may be confused by POV-Ray /not/ mentioning this theoretical
possibility; other people might experience it as unnecessarily confusing
if POV-Ray /did/ mention it (/especially/ because POV-Ray does not allow
a choice there).

[lelama] Re: Orientation and left handed frame [3477 days 21 hours and 1 minute ago]

Tue, 4 Oct 2016 16:10:01 GMT

> >
> > These two choices may be done independently. The documentation suggests that
> > these two choices are dependent, making the doc difficult to read.
>
> I don't see the documentation implying anything of that sort. It simply
> describes how POV-Ray does things, and neither asserts nor denies a
> connection between the two features.
>

The doc says that povray is a left handed system and uses the left hand for both
the axis relative locations and the rotations. It was not clear to me when I
read the doc whether I can change the default behaviour and use the left hand
for the axis and the right hand for the roations.

The default choices are clearly documented. But, what if we change the default
convention ?  I see no place in the doc where it is written if we can make the
choices for the axis and for the rotations independently.

As far as I understand, this is not possible to choose the conventions
independently (whereas it is logically possible in principle). I think it would
be more clear if it was written explicitly that it is not possible.


> - What /is/ the "left handed convention"? The current wording easily
> explains POV-Ray's coordinate system by means of physiological
> properties shared by well over 99.99% of all human beings, rather than
> relying on the reader being familiar with arbitrary conventions
> established in mathematics or computer graphics.

Yes, OK with that.  My problem is not with the wording. It is about the fact
that ( if I am correct ) only two conventions are possible among the 4 possible
choices that exist in theory.

Laurent.

[Le Forgeron] Re: Orientation and left handed frame [3477 days 21 hours and 11 minutes ago]

Tue, 4 Oct 2016 15:59:56 GMT

Le 04/10/2016 Ã  16:44, lelama a Ã©crit :
> 
> The documentation of povray seems to me inacurate on the oritentation
> considerations if I look at http://www.povray.org/documentation/view/3.7.0/15/
> 
> To fix the orientattion conventions, there are 2 choices to be done :
> - does xyz follow the left or right handed convention ?
> - do we screw or unscrew the rotations with a positive angle ?
> 
> These two choices may be done independently. The documentation suggests that
> these two choices are dependent, making the doc difficult to read. In my
> opinion, the correct formulation should be that :
> 
> By default:
> - xyz follows the left handed convention
> - rotations with a positive angle with respect to a vector unscrews if the eye
> is in the direction of the vector.
> If we change the camera right vector to change to the right handed convention,
> povray will implicitly change automatically change the second convention and
> will screw positive rotations.
> 

There is only one choice: between left or right handed system.

(As long as we are using perpendicular vectors for up, right and direction)

And whatever the choice, the positive angle rotation along an axis k
will be the shortest rotation which transform axis k+1 into axis k+2
(modulo 3).
(the opposite rotation for the same transformation would be with a
negative angle whose absolute value would be 3 times bigger, modulo the
full rotation)

aka:
* rotation of +90Â° along +x transform +y into +z
* rotation of +90Â° along +y transform +z into +x
* rotation of +90Â° along +z transform +x into +y&

It works for left handed ( +x to the right, +y up, +z forward)
and it works for right-handed ( +x to the left, +y forward, +z up)

(IIRC, right handed is for architect: you do schema of floor on <x,y>, z
is the height of the floors,
while left handed is for mathematician: you draw <x,y> on the
blackboard, and extend the depth with z later)

The shortest rotation is always "screwing" (with a right helix, the
usual screw you encounter 99.9% of the time) along its axis... if that
can make sense to you, but:

the documentation page talks about the aerobic exercise, done with the
relevant hand, thumb along the axis, to fold the straight index finger
onto the already half folded middle finger.
There is no part which talks about screwing.

There is no option to change the fact that
* +y rotated by +quarter of circle +x becomes +z
* +z rotated by +quarter of circle +y becomes +x
* +x rotated by +quarter of circle +z becomes +y

Never. Consider it a part of the definition of the base.




> To produce povray code from an  other software that cooperates with povray,
> sometimes the other software does not follow the same conventions. In this case,
> the documentation is not sufficient and it is necessary to experiment to reelly
> understand what's going on.
> 
> My 2 cents,
> Laurent.
> 
> 
>

[clipka] Re: Orientation and left handed frame [3477 days 21 hours and 32 minutes ago]

Tue, 4 Oct 2016 15:38:32 GMT

Am 04.10.2016 um 16:44 schrieb lelama:
> 
> The documentation of povray seems to me inacurate on the oritentation
> considerations if I look at http://www.povray.org/documentation/view/3.7.0/15/
> 
> To fix the orientattion conventions, there are 2 choices to be done :
> - does xyz follow the left or right handed convention ?
> - do we screw or unscrew the rotations with a positive angle ?
> 
> These two choices may be done independently. The documentation suggests that
> these two choices are dependent, making the doc difficult to read.

I don't see the documentation implying anything of that sort. It simply
describes how POV-Ray does things, and neither asserts nor denies a
connection between the two features.

> In my
> opinion, the correct formulation should be that :
> 
> By default:
> - xyz follows the left handed convention

- What /is/ the "left handed convention"? The current wording easily
explains POV-Ray's coordinate system by means of physiological
properties shared by well over 99.99% of all human beings, rather than
relying on the reader being familiar with arbitrary conventions
established in mathematics or computer graphics. Also, there are even
conventions out there using the terms "left handed" and "right handed"
with the reverse meaning, assigning the x, y and z axis to the middle
finger, index finger and thumb instead. By explicitly stating the finger
assignment, the current wording avoids this problem.

- The "left handed convention" does not say anything about the
orientation of the axes in space (such as which axis is up), just their
relation to each other. POV-Ray has a clearly defined default
orientation in space, and the current wording mentions that.

> - rotations with a positive angle with respect to a vector unscrews if the eye
> is in the direction of the vector.

- The current wording again explains POV-Ray's handling of rotations by
means of easily accessible physiological properties, rather than relying
on the arbitrary engineering conventions of what rotation direction will
tighten or loosen a (conventional) screw, or even whether the screw's
head would be facing towards or away from you when you do that feat.
"Clockwise" and "anti-clockwise" would probably be better references
than screws, but I think human physiological properties win hands down
(pun somewhat intented).


I see no fault in the current wording, except maybe for the coordinate
system diagram that is ambiguous, since we don't really know whether the
Z axis points into or out of the image. We should probably add some
3-dimensional shape near the center to resolve the ambiguity.

[lelama] Orientation and left handed frame [3477 days 22 hours and 21 minutes ago]

Tue, 4 Oct 2016 14:50:01 GMT

The documentation of povray seems to me inacurate on the oritentation
considerations if I look at http://www.povray.org/documentation/view/3.7.0/15/

To fix the orientattion conventions, there are 2 choices to be done :
- does xyz follow the left or right handed convention ?
- do we screw or unscrew the rotations with a positive angle ?

These two choices may be done independently. The documentation suggests that
these two choices are dependent, making the doc difficult to read. In my
opinion, the correct formulation should be that :

By default:
- xyz follows the left handed convention
- rotations with a positive angle with respect to a vector unscrews if the eye
is in the direction of the vector.
If we change the camera right vector to change to the right handed convention,
povray will implicitly change automatically change the second convention and
will screw positive rotations.

To produce povray code from an  other software that cooperates with povray,
sometimes the other software does not follow the same conventions. In this case,
the documentation is not sufficient and it is necessary to experiment to reelly
understand what's going on.

My 2 cents,
Laurent.