povray.binaries.scene-files message digest

[Droj] Re: AT Devil Plate [328 days 11 hours and 17 minutes ago]

Tue, 13 May 2025 21:00:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:
> > It's probably as close to the original as it can get.
> Agreed! I think, the only improvement is to close the surface by
> removing the open statement
>
> Best regards
> Michael

Thanks, Michael, for the hint to remove 'open'.
I realised that there was still something wrong at the rim.

Your hint was the icing on the cake!

Droj

[MichaelJF] Re: AT Devil Plate [328 days 13 hours and 58 minutes ago]

Tue, 13 May 2025 18:19:04 GMT

> It's probably as close to the original as it can get.
Agreed! I think, the only improvement is to close the surface by 
removing the open statement

Best regards
Michael

[Bald Eagle] Re: AT Devil Plate [328 days 17 hours and 57 minutes ago]

Tue, 13 May 2025 14:20:00 GMT

"Droj" <803### [at] drojde> wrote:

> When you mentioned to use the function f_r (x, y, z) - although I do not have a
> clue what it does (there is no comment in functions.inc)

You need to check the wiki entry under functions.inc

f_r(x,y,z): When used alone, the R function gives a surface that consists of all
the points that are a specific distance (threshold value) from the origin,

So basically you're just comparing your surface to a spherical shell.

At least you were able to work something out and get a decent result.
Isosurfaces can certainly be tricky, especially since we don't have vector
functions and certain inbuilt functions that other software packages pull from
libraries.

Chris R does everything with isosurfaces - maybe he can focus his highly trained
mind on it.

- BW

[Droj] Re: AT Devil Plate [328 days 18 hours and 37 minutes ago]

Tue, 13 May 2025 13:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> MichaelJF <fri### [at] t-onlinede> wrote:
>
> Well, the red and orange are looking good!
>
> I'm not sure what's happening with MW's method, but I was just making a quick
> suggestion.
>
> The surface obviously extends infinitely in the +/-y directions, and so the
> select is just there to trim the function.
> I believe we can exclude that and just rely on the contained_by box.
>
> IsoExterior (10*x/15),y,z) just scales the function in the x direction.
> I'd take that out and use scale to take care of that part.
>
> I'm just guessing here, but what if you then try something like:
> IsoExterior (abs (x) - 0.01, abs (y) - 0.01, abs (z) - 0.01)
>
> maybe also experiment with subtracting from f_r (x, y, z)
> (include functions.inc)
>
> try changing the threshold from 0 to 0.01
>
> There's a lot of tricky things that have to be done to get certain functions to
> work well with isosurfaces in POV-Ray vs other software packages
>
> Maybe take a look further upstream at the preceding functions in the daisy chain
> to see if a better gradient can be fashioned.
>
> Define a set of y axes across the xz plane in the AABB, and graph the function
> along those y-axes and see what pops out.
>
> - BW
>
>
Hi,

I tried some of the solutions proposed here and yes, the orange object is the
best approximation.

When you mentioned to use the function f_r (x, y, z) - although I do not have a
clue what it does (there is no comment in functions.inc) I remembered that TOK
used it in his source code for prettyball_1_at_klp_tok.pov.txt.

I tested it with Abderrahman Taha's Clebsch_2 and it worked amazingly well.

So, I adapted the code for Devil Plate, too which now looks as follows.

=================================================================
// Iso_Devil_Plate_test8.pov
#version 3.7;

global_settings { assumed_gamma 2.2 }

#include "colors.inc"
#include "textures.inc"
#include "metals.inc"
#include "functions.inc"

#declare H = 1e-4;
#declare Th = 1/10;

#declare Xmin = -45/10;
#declare Xmax = 45/10;
#declare Ymin = -24/10;
#declare Ymax = 44/10;
#declare Zmin = -75/10;
#declare Zmax = 75/10;

// Devil=x^4+2*x^2*z^2-(36/100)*x^2-y^4+(25/100)*y^2+z^4
#declare DevilFn = function {
 pow(x,4)+2*pow(x,2)*pow(z,2)-(36/100)*pow(x,2)-pow(y,4)+(25/100)*pow(y,2)+pow(z,4)
 }

// Devil2=Devil(x,sqrt(y*y+z*z)-(15/10),z,t)
#declare DevilFn2 = function(x,y,z) {
 DevilFn (
  x,
  sqrt(y*y+z*z)-(15/10),
  z
        )
 }

// IsoExterior=Devil2(x,y,sqrt(x*x+z*z)-(15/10),t)
#declare IsoExt = function(x,y,z) {
 DevilFn2 (
  x,
  y,
  sqrt(x*x+z*z)-(15/10)
        )
 }

// DFx=((IsoExterior(x+c,y,z,t)-IsoExterior(x,y,z,t))/c)
#declare DFX = function { (IsoExt(x+H,y,z)-IsoExt(x,y,z))/H }

// DFy=((IsoExterior(x,y+c,z,t)-IsoExterior(x,y,z,t))/c)
#declare DFY = function { (IsoExt(x,y+H,z)-IsoExt(x,y,z))/H }

// DFz=((IsoExterior(x,y,z+c,t)-IsoExterior(x,y,z,t))/c)
#declare DFZ = function { (IsoExt(x,y,z+H)-IsoExt(x,y,z))/H }

// Adaptation according to TOK's code follows
#declare Fn =
    function(x, y, z, dx, dy, dz, s) {
        IsoExt(
            x + dx*s,
            y + dy*s,
            z + dz*s
        )
    }

// F(x,y,z,t) = if(y<(44/10)&y>-(24/10),ThickIsoExterior((10*x/15),y,z,t),1);
select() removed
#declare DP_Fn = function(x,y,z,dx,dy,dz) {
        Fn(x, y, z, dx, dy, dz, +Th/f_r(dx, dy, dz))
        *
        Fn(x, y, z, dx, dy, dz, -Th/f_r(dx, dy, dz))
        // instead of: IsoPlus(x,y,z)*IsoMinus(x,y,z),
}

//ISO Devil_Plate =
isosurface {
  function {DP_Fn(
             10*x/15,y,z, // scaling x
             DFX(x, y, z),
             DFY(x, y, z),
             DFZ(x, y, z)
             )
  }
        contained_by{box{<Xmin,Ymin,Zmin>, <Xmax, Ymax, Zmax>}}
        threshold 0.0 // Trace Time 0 h 26 min
        accuracy 0.01
        max_gradient 2216254
        open
        pigment {Yellow}
 rotate 90*y
}

#declare Win = image_width/image_height;

background { color <1.0,1.0,1.0> }

camera {
    location <0, 15, -25>
    up y
    right Win*x
    look_at <0.0, 0.0, 0.0>
    angle 54
}

light_source {
    <-17, 25, -35>
    color rgb <1, 1, 1>
}

=====================================================================

It's probably as close to the original as it can get.

Thanks to all of you for the input.

Droj

[Cousin Ricky] Ukrainian symbols [339 days 11 hours and 45 minutes ago]

Fri, 2 May 2025 20:31:22 GMT

I have implemented the Ukrainian small coat of arms and the official
blue and gold.  There is no light blue defined, as I cannot find an
official spec.

At this time, a great coat of arms is not yet designed; Ukrainian
officials currently appear to be occupied with a much more urgent matter.

Documentation is available on GitHub:
  https://github.com/CousinRicky/POV-Ukraine

[Bald Eagle] Re: AT Devil Plate [342 days 14 hours and 17 minutes ago]

Tue, 29 Apr 2025 18:00:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:

Well, the red and orange are looking good!

I'm not sure what's happening with MW's method, but I was just making a quick
suggestion.

The surface obviously extends infinitely in the +/-y directions, and so the
select is just there to trim the function.
I believe we can exclude that and just rely on the contained_by box.

IsoExterior (10*x/15),y,z) just scales the function in the x direction.
I'd take that out and use scale to take care of that part.

I'm just guessing here, but what if you then try something like:
IsoExterior (abs (x) - 0.01, abs (y) - 0.01, abs (z) - 0.01)

maybe also experiment with subtracting from f_r (x, y, z)
(include functions.inc)

try changing the threshold from 0 to 0.01

There's a lot of tricky things that have to be done to get certain functions to
work well with isosurfaces in POV-Ray vs other software packages

Maybe take a look further upstream at the preceding functions in the daisy chain
to see if a better gradient can be fashioned.

Define a set of y axes across the xz plane in the AABB, and graph the function
along those y-axes and see what pops out.

- BW

> This all works very fine, but Mike Williams' approach (dark purple)
> looks a little strange:
>
> #declare DevilsPlateD = function (x,y,z) {
>       select (
> -(-24/10-y)*(y-44/10),(abs(IsoExterior((10*x/15),y,z))-0.01) ,1)
> }
> isosurface {
>     function {
>        DevilsPlateD(x,y,z)
>     }
>     contained_by { box { <-45/10,-25/10,-75/10>,<45/10,45/10,75/10> } }
>     threshold 0.0
> //   open
>     max_gradient 1000000
>     pigment { colour DarkPurple }
> }
>
> All values for max_gradient are adjusted according to the log.
> max_trace_level was at maximum (256).
>
> I have no idea what happens here.
>
> Best regards
> Michael

[MichaelJF] Re: AT Devil Plate [342 days 16 hours and 3 minutes ago]

Tue, 29 Apr 2025 16:13:20 GMT

Am 28.04.2025 um 20:26 schrieb Bald Eagle:
> Try Mike Williams' isosurface thickening trick:
> 
> Thickening
> If we have a function F(x,y,z) we can turn it into two parallel surfaces by
> using abs(F(x,y,z))-C where C is some
> small value. The original function should be one that works with zero threshold.
> The two resulting surfaces are
> what you would get by rendering the original function with threshold +C and -C,
> but combined into a single
> image. The space between the two surfaces becomes the "inside" of the object. In
> this way we can construct
> things like glasses and cups that have walls of non-zero thickness.
> #declare F = function {y + f_noise3d (x*2, 0, z*2)}
> isosurface {
> function {abs (F(x, y, z))-0.1}
> ....
> 
> 
Obviously this should work. But I run into a problem with this approach. 
The yellow object depictes the devils plate function without any thickening:

#declare c=1/10000;
#declare Th=1/10;
#declare Devil = function(x,y,z) { 
x*x*x*x+2*x*x*z*z-36/100*x*x-y*y*y*y+25/100*y*y+z*z*z*z }
#declare Devil2 = function(x,y,z) { Devil(x,sqrt(y*y+z*z)-15/10,z) }
#declare IsoExterior = function (x,y,z) { Devil2(x,y,sqrt(x*x+z*z)-15/10) }

isosurface { function { IsoExterior(x,y,z) }
    contained_by { box { <-45/10,-25/10,-75/10>,<45/10,45/10,75/10> } }
    threshold 0.0
    open
    max_gradient 2500
    pigment { colour Yellow }
}

The red object shows the approach by Abderrahman Taha (MathMod). He 
calculates the numerical derivatives to approximate the normals. Then 
the shape is shifted a small amount along and against these normals. 
Finally, both functions are multiplied to form the sets of points at 
which at least one of the functions returns the value zero - the 
threshold that is then used in the isosurface:

// numerical derivatives
#declare DFx = function(x,y,z) { 
(IsoExterior(x+c,y,z)-IsoExterior(x,y,z))/c }
#declare DFy = function(x,y,z) { 
(IsoExterior(x,y+c,z)-IsoExterior(x,y,z))/c }
#declare DFz = function(x,y,z) { 
(IsoExterior(x,y,z+c)-IsoExterior(x,y,z))/c }
// normalisation
#declare R = function (x,y,z) { x/sqrt(x*x+y*y+z*z) }
#declare IsoPlus = function (x,y,z) {
    IsoExterior( x+Th*R(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
                 y+Th*R(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
                 z+Th*R(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z)))
    }
#declare IsoMinus = function (x,y,z) {
    IsoExterior( x-Th*R(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
                 y-Th*R(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
                 z-Th*R(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z)))
    }
#declare ThickIsoExterior = function (x,y,z) { 
IsoPlus(x,y,z)*IsoMinus(x,y,z) }
#declare DevilsPlate = function (x,y,z) {
    select (  -(-24/10-y)*(y-44/10),ThickIsoExterior((10*x/15),y,z), 1)
}
isosurface {
    function {
       DevilsPlate(x,y,z)
    }
    contained_by { box { <-45/10,-25/10,-75/10>,<45/10,45/10,75/10> } }
    threshold 0.0
    open
    max_gradient 20000000
    pigment { colour Red }
}

The orange object ist nearly the same as the red one but without the 
select statement, moving the range condition for y into the bounding box.

This all works very fine, but Mike Williams' approach (dark purple) 
looks a little strange:

#declare DevilsPlateD = function (x,y,z) {
      select ( 
-(-24/10-y)*(y-44/10),(abs(IsoExterior((10*x/15),y,z))-0.01) ,1)
}
isosurface {
    function {
       DevilsPlateD(x,y,z)
    }
    contained_by { box { <-45/10,-25/10,-75/10>,<45/10,45/10,75/10> } }
    threshold 0.0
//   open
    max_gradient 1000000
    pigment { colour DarkPurple }
}

All values for max_gradient are adjusted according to the log. 
max_trace_level was at maximum (256).

I have no idea what happens here.

Best regards
Michael

[Bald Eagle] Re: AT Devil Plate [343 days 13 hours and 47 minutes ago]

Mon, 28 Apr 2025 18:30:00 GMT

Try Mike Williams' isosurface thickening trick:

Thickening
If we have a function F(x,y,z) we can turn it into two parallel surfaces by
using abs(F(x,y,z))-C where C is some
small value. The original function should be one that works with zero threshold.
The two resulting surfaces are
what you would get by rendering the original function with threshold +C and -C,
but combined into a single
image. The space between the two surfaces becomes the "inside" of the object. In
this way we can construct
things like glasses and cups that have walls of non-zero thickness.
#declare F = function {y + f_noise3d (x*2, 0, z*2)}
isosurface {
function {abs (F(x, y, z))-0.1}
....

[Droj] Re: AT Devil Plate [343 days 14 hours and 17 minutes ago]

Mon, 28 Apr 2025 18:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I don't know what your ultimate goal is, but when I just evaluated the
> isosurface for
>
> function {DevilFn2(x,y,z)
>
> I get the following render (Cam and lights adjusted, white sky_sphere)
>
> - BW

When you render the function #declare Iso = function(x,y,z) {
you get the image attached.

The next 2 functions should add thickness to the shape (you see the rim of the
'plate' is thin like an eggshell).

And this is where the flaw is.

Droj

[Bald Eagle] Re: AT Devil Plate [344 days 20 hours and 2 minutes ago]

Sun, 27 Apr 2025 12:15:00 GMT

I don't know what your ultimate goal is, but when I just evaluated the
isosurface for

function {DevilFn2(x,y,z)

I get the following render (Cam and lights adjusted, white sky_sphere)

- BW

[Droj] Re: AT Devil Plate [345 days 11 hours and 52 minutes ago]

Sat, 26 Apr 2025 20:25:00 GMT

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

>
> F(x,y,z,t) =
> select ( (y<(44/10)) * (y>-(24/10)),
> 0, 1, ThickIsoExterior((10*x/15),y,z,t)
> )
>
> Hope that makes sense.

Hi BE,
I followed your advice with respect to select() and added the appropriate code
using the boolean & instead of multiply.

And it works - well, not the way it should.
I believe there is something wrong in my Povray code which is hard for me to
find out.

I added AT's equations as comment above the Povray code.

Meanwhile I read the threads initiated by klp in Povray's advanced users
<6752dcbc@news.povray.org>
in Dec 2024 about the topic but I could not find the solution there.

The interesting thing about my misinterpretation of AT's equations is:

 (1) setting threshold 1 and accuracy 0.01 (max_gradient 2352446)
 ==> Povray renders something solid (not the object I was expecting)
 ==> Trace Time: 1h 38 min using 16 threads
 (2) setting threshold 0 and accuracy 0.01 (max_gradient 2352446)
 ==> Povray renders something invisible
 ==> Trace Time: about the same as above
 (3) setting threshold 0.01 and accuracy 0.1 (max_gradient 2352446)
 ==> Povray renders an object that looks like being peeled
 ==> Trace Time: 0h 39 min using 16 threads
 And no, Povray doesn't complain about gaps in the object!

I will post an image of (1) and (3) in p.b.i

Thanks for your patience

Droj

[Droj] Re: AT Devil Plate [366 days 19 hours and 52 minutes ago]

Sat, 5 Apr 2025 12:25:00 GMT

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

> >
> > F(x,y,z,t) = if(y<(44/10)&y>-(24/10),ThickIsoExterior((10*x/15),y,z,t),1)
>
> There are likely several ways to go about this.
> Enclosing the inequalities in parentheses evaluates them as a Boolean.
> If you multiply them, if either one is false, then the product is zero.
> If they are both true, then you get 1 * 1 = 1;
> so you could try:
>
> F(x,y,z,t) =
> select ( (y<(44/10)) * (y>-(24/10)),
> 0, 1, ThickIsoExterior((10*x/15),y,z,t)
> )
>
> A zero gets added in to use the "4-parameter version" of select, and then since
> false = 0, the 1 is the next parameter, and true = 1, so ThickIsoExterior is the
> last parameter.
>
> Hope that makes sense.
>
> - BW
>
> select(A, B, C [,D])
> It can be used with three or four parameters Select compares the first argument
> with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
> floats or funtions.
>
> When used with three parameters, if A < 0 it will return B, else C (A >= 0).
>
> When used with four parameters, if A < 0 it will return B. If A = 0 it will
> return C. Else it will return D (A > 0).

Thanks, B.E.
Now it's clearer what select() is good for.
I have to chew on that for a while.

[Bald Eagle] Re: AT Devil Plate [367 days 16 hours and 32 minutes ago]

Fri, 4 Apr 2025 15:45:00 GMT

"Droj" <803### [at] drojde> wrote:

> what I could not find out is how to apply thickness
>
> ThickIsoExterior=(Iso(x,y,z,1)*Iso(x,y,z,-1))

That's just a function - like any other.
You might have discontinuities, which would drive the gradient through the roof.

> and how to apply this condition
>
> F(x,y,z,t) = if(y<(44/10)&y>-(24/10),ThickIsoExterior((10*x/15),y,z,t),1)

There are likely several ways to go about this.
Enclosing the inequalities in parentheses evaluates them as a Boolean.
If you multiply them, if either one is false, then the product is zero.
If they are both true, then you get 1 * 1 = 1;
so you could try:

F(x,y,z,t) =
select ( (y<(44/10)) * (y>-(24/10)),
0, 1, ThickIsoExterior((10*x/15),y,z,t)
)

A zero gets added in to use the "4-parameter version" of select, and then since
false = 0, the 1 is the next parameter, and true = 1, so ThickIsoExterior is the
last parameter.

Hope that makes sense.

- BW

select(A, B, C [,D])
It can be used with three or four parameters Select compares the first argument
with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
floats or funtions.

When used with three parameters, if A < 0 it will return B, else C (A >= 0).

When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).

[Droj] AT Devil Plate [367 days 17 hours and 27 minutes ago]

Fri, 4 Apr 2025 14:50:00 GMT

Hi,

Again I found an other interesting isosurface in Abderrahman Taha's MathMod
which he called Devil Plate (see his functions at the beginning of the attached
pov-file).

But this time I am stuck.

I am posting the pov-file which renders OK although it takes a 'couple
of minutes'. The result is close to the original but

what I could not find out is how to apply thickness

ThickIsoExterior=(Iso(x,y,z,1)*Iso(x,y,z,-1))

and how to apply this condition

F(x,y,z,t) = if(y<(44/10)&y>-(24/10),ThickIsoExterior((10*x/15),y,z,t),1)

Can someone help?

Regards
Droj

[Tor Olav Kristensen] Source code for Mesh Torus - Meshing the pigment... [463 days 4 hours and 47 minutes ago]

Mon, 30 Dec 2024 03:30:00 GMT

Here's the SDL file for an image that is almost the same as the one I posted
here:

Newsgroups: povray.binaries.images
Subject: Meshing the pigment too
Date: 2024-12-29 22:12:37
From: Tor Olav Kristensen
https://news.povray.org/povray.binaries.images/message/%3Cweb.67712819b83cb707d209902e89db30a9%40news.povray.org%3E

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[And] Re: sky render package [813 days 3 hours and 42 minutes ago]

Mon, 15 Jan 2024 04:35:00 GMT

It's long time ago. But after looking more paper, I notice this file of
simulation, Rayleigh scattering is too low.
The value in 'sky_render enviroment.pov' may be modified.


The lines:

#declare f_rayleigh_extinction_coefficient = // 1/kilometer
function(_altitude, _wavelgth){
0.0007*pow(730/_wavelgth,4.05)
*exp(-_altitude/20)
}


may be modified to another value:

#declare f_rayleigh_extinction_coefficient = // 1/kilometer
function(_altitude, _wavelgth){
0.003*pow(730/_wavelgth,4.05)
*exp(-_altitude/20)
}



Maybe the air scattering attenuation coeff is about 0.003 1/kilometer at sea
level.

[Cousin Ricky] Re: Chromatic dispersion adjustment and an sRGB ... [841 days 6 hours and 11 minutes ago]

Mon, 18 Dec 2023 02:05:59 GMT

... and here are the attachments.

[Cousin Ricky] Chromatic dispersion adjustment and an sRGB update [841 days 6 hours and 12 minutes ago]

Mon, 18 Dec 2023 02:04:47 GMT

POV-Ray's dispersion algorithm assumes that the given IOR is for a
wavelength midway between red and violet.  However, IORs are normally
given at wavelength D (yellow-orange), which causes POV-Ray to shift the
positions of the colors.  File iorsuggest.inc provides a function that
suggests an adjustment to a material's index of refraction that yields
reasonably accurate dispersion for most materials.

File srgb.inc has been updated to include sRGB decoders.  I omitted
these in previous versions because POV-Ray 3.7+ has a built-in sRGB
decoder.  However, since this file is supposed to be compatible to 3.5,
I added the decoders for those POVers who are still using older versions.

These files are part of my collection at
  https://github.com/CousinRicky/RC3-POV-Tools

[Colin Fleming] Source for Anders Haglund Smoke Test [878 days 22 hours and 57 minutes ago]

Fri, 10 Nov 2023 09:20:00 GMT

The original and my updates, hopefully updated with all my changes.

[Colin Fleming] Source for Black Pawn Sunset [882 days 7 hours and 2 minutes ago]

Tue, 7 Nov 2023 01:15:00 GMT

Source code for Black Pawn Sunset plus code for Sunset by Abe Madey

[Thomas de Groot] Heightfields of sediment layers - wip 1 [912 days and 4 minutes ago]

Sun, 8 Oct 2023 08:12:15 GMT

the test scene. See p.b.images for details.

-- 
Thomas

[Cousin Ricky] Lightsys IV [974 days 12 hours and 9 minutes ago]

Sun, 6 Aug 2023 20:07:53 GMT

This is my latest copy of Lightsys, version 4d, downloaded 2015 July 6.

Note that in file espd_lightsys.inc, in spline ES_Phillips_HPS (the
Philips high pressure sodium lamp), the line 598, 0.2300 should be
changed to 498, 0.2300.

This library is written by Jaime Vives Piqueres et al., and shared under
a Creative Commons Attribution ShareAlike license v4.0.

[Colin Fleming] Kirk Andrews Gothic Arch Macro [980 days 17 hours and 17 minutes ago]

Mon, 31 Jul 2023 15:00:00 GMT

Source for the image in binaries.images

[Mike Miller] Re: Mike Miller - REX5 [988 days 4 hours and 42 minutes ago]

Mon, 24 Jul 2023 03:35:00 GMT

"Colin Fleming" <Colin Fleming> wrote:
> From Franzis' Ray Tracing Box on the Internet Archive:
>
> https://archive.org/details/franzisraytracingbox

Thanks you so much!
Mike

[Colin Fleming] Mike Miller - REX5 [988 days 20 hours and 12 minutes ago]

Sun, 23 Jul 2023 12:05:01 GMT

From Franzis' Ray Tracing Box on the Internet Archive:

https://archive.org/details/franzisraytracingbox

[And] Re: Proximity and subsurface scattering macros +... [1000 days 18 hours and 22 minutes ago]

Tue, 11 Jul 2023 13:55:00 GMT

I think that I can calculate several properties together in the main loop.

1). Proximity pattern

2). Slope pattern
   just like POV-Ray's slope pattern, assign a axis, then calc the slope of that
axis

3). ...
  investigate the point is near or far from object surface



then output to series .df3 file.

[And] Re: Proximity and subsurface scattering macros +... [1002 days 3 hours and 27 minutes ago]

Mon, 10 Jul 2023 04:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> may be worth looking at PB's page, too:
> <http://paulbourke.net/miscellaneous/povexamples/#df3>
>
>
> regards, jr.

Thank you very much. I ever saw this page many years ago, but if you didn't
remind me, I have forgot it.

[jr] Re: Proximity and subsurface scattering macros +... [1002 days 10 hours and 47 minutes ago]

Sun, 9 Jul 2023 21:30:00 GMT

hi,

"And" <49341109@ntnu.edu.tw> wrote:
> I research this and Edouard's df3prox-0.95 ... I'm planing to write macros with such
pattern storage in .df3,

may be worth looking at PB's page, too:
<http://paulbourke.net/miscellaneous/povexamples/#df3>


regards, jr.

[And] Re: Proximity and subsurface scattering macros +... [1002 days 18 hours and 37 minutes ago]

Sun, 9 Jul 2023 13:40:00 GMT

I research this and Edouard's df3prox-0.95 , thanks for the idea and detail how
it can achieve. I'm planing to write macros with such pattern storage in .df3,
too. I want to write a slope pattern with proximity pattern at the same time.

[Colin Fleming] Re: Heinz W. Schuller - Moon Base [1090 days 22 hours and 2 minutes ago]

Wed, 12 Apr 2023 10:15:00 GMT

"Droj" <803### [at] drojde> wrote:
> "Colin Fleming" <Colin Fleming> wrote:
> > This is the VIVID source scene for Moone Base scene.
>
> Hi Colin,
>
> great to see that you revived some old stuff!
>
> I found that VIVID MoonBase scene of Heinz W. Schuller on a raytrace CD I bought
> back in the 90ties.
>
> Hope you find the missing files/things there.
>
> - Oswald

Thanks Oswald,

This is one of the scenes where I have all the files.

Colin.

[Droj] Re: Heinz W. Schuller - Moon Base [1091 days 10 hours and 47 minutes ago]

Tue, 11 Apr 2023 21:30:00 GMT

"Colin Fleming" <Colin Fleming> wrote:
> This is the VIVID source scene for Moone Base scene.

Hi Colin,

great to see that you revived some old stuff!

I found that VIVID MoonBase scene of Heinz W. Schuller on a raytrace CD I bought
back in the 90ties.

Hope you find the missing files/things there.

- Oswald

[Colin Fleming] Vivid Laser Logo [1091 days 21 hours and 2 minutes ago]

Tue, 11 Apr 2023 11:15:00 GMT

The original image by Martin Higgs used a Quick Basic program to create the
"sparks", this can now be done by POV-Ray SDL.

See povray.binaries.images for my rubbish attempt in POV-Ray.

[kurtz le pirate] Arrays macro [1116 days 16 hours and 58 minutes ago]

Fri, 17 Mar 2023 15:18:47 GMT

Hello,


As indicated in p.b.i, the macros here





-- 
Kurtz le pirate
Compagnie de la Banquise

[Colin Fleming] Re: BNC Connector [1116 days 19 hours and 42 minutes ago]

Fri, 17 Mar 2023 12:35:00 GMT

"Colin Fleming" <Colin Fleming> wrote:
> This is a VIVID scene file of a BNC connector.
>
> (brings back memories!)

And how about attaching the correct file (dummy!)

[Colin Fleming] VIVID - Pool Table [1116 days 19 hours and 52 minutes ago]

Fri, 17 Mar 2023 12:25:00 GMT

This is a VIVID source scene for a Pool Table, balls and cue (queue/kew?)

[Colin Fleming] VIVID Chrome Ball [1116 days 19 hours and 52 minutes ago]

Fri, 17 Mar 2023 12:25:00 GMT

This is a VIVID source scene of a Chrome Ball

[Colin Fleming] BNC Connector [1116 days 19 hours and 52 minutes ago]

Fri, 17 Mar 2023 12:25:00 GMT

This is a VIVID scene file of a BNC connector.

(brings back memories!)

[Colin Fleming] Heinz W. Schuller - Moon Base [1116 days 19 hours and 57 minutes ago]

Fri, 17 Mar 2023 12:20:00 GMT

This is the VIVID source scene for Moone Base scene.

[Colin Fleming] Heinz W. Schuller - Eagle Transport [1116 days 19 hours and 57 minutes ago]

Fri, 17 Mar 2023 12:20:00 GMT

This is the VIVID scene for Space 1999 Eagle Transport

Converted to POV-Ray v3.x syntax, it appears that there may be a file missing
for the landing pod/feet (not sure)

[Colin Fleming] Heinz W. Schuller - Zounds [1116 days 20 hours and 2 minutes ago]

Fri, 17 Mar 2023 12:15:00 GMT

This is a VIVID source scene converted to POV-Ray v3.x syntax.

The archive I have is missing "RADAR.VO".

[Colin Fleming] Panu Hassi - Bounce [1116 days 20 hours and 12 minutes ago]

Fri, 17 Mar 2023 12:05:00 GMT

Attached is Panu Hassis "Bounce" animation.

[Colin Fleming] Pany Hassi - Ring [1116 days 20 hours and 12 minutes ago]

Fri, 17 Mar 2023 12:05:00 GMT

This is an animation of chrome spheres bouncing and rotating.

[Colin Fleming] Drew Wells - Tomb [1116 days 20 hours and 12 minutes ago]

Fri, 17 Mar 2023 12:05:00 GMT

Attached is "Tomb" by Drew Wells, Panu Hassi created a RayScene ARR file to
animate the image.

I trolled the inter-web-thingy and found a couple of images to replace
"ghost.gif".

[Colin Fleming] Terry Majewski "Pop" (Vending Machines) [1116 days 20 hours and 17 minutes ago]

Fri, 17 Mar 2023 12:00:00 GMT

I remember this image on BBS (probably Paul Smiths RayTech BBS).

Terry mentions:
"Compaq 486-33 machine with 8 Meg of RAM, rendering took about 5 hours for
640x480"

My Core i5-something renders at 1280x960 in less than 15 seconds! (so, some
progress has been made!)

[Thomas de Groot] Glass for v3.8 finish features [1335 days 23 hours and 52 minutes ago]

Wed, 10 Aug 2022 08:24:16 GMT

I attach here my scene file (including my version of the Stanford bunny) 
demonstrating the glass finish features discussed in p.general and p.b.i 
(identical subject lines).

-- 
Thomas

[ingo] fft.inc complex.in [1375 days 23 hours and 27 minutes ago]

Fri, 1 Jul 2022 08:50:00 GMT

complex number include file and fast Fourier transform include file. Both fresh,
unoptimised and may be buggy. No demo scenes yet, but basic tests are in the
inc's. Just render them.

Ingo

[zebulon 1er] Re: 'Light & Shadows' big version [1449 days 21 hours and 57 minutes ago]

Mon, 18 Apr 2022 10:20:00 GMT

"Norbert Kern" <nor### [at] t-onlinede> wrote:
> Here is a 8000x4500 pixel version of the 'Light & Shadows' image posted in
> povray.binaries.images
>
> Norbert Kern

Wow! Really huge work. <3<3<3

[MichaelJF] Sources to Zanzibar Beach Scene [1458 days 14 hours and 55 minutes ago]

Sat, 9 Apr 2022 17:22:01 GMT

Hi, here are the source to may Zanzibar Beach Scene (without the XFROG-palm)

http://news.povray.org/povray.binaries.images/thread/%3C61765382%40news.povray.org%3E/?ttop=437502&toff=50

Best regards
Michael

[jr] Re: PROOF : core include files and test code. [1475 days 22 hours and 2 minutes ago]

Wed, 23 Mar 2022 10:15:00 GMT

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> ...
> > Here is an updated package, ...
> You can see the class hierachy I designed so far :
> ...

thanks.  hope for a "look around" over the weekend.


regards, jr.

[Bruno Cabasson] Re: PROOF : core include files and test code. [1476 days 17 hours and 1 minute ago]

Tue, 22 Mar 2022 15:15:20 GMT

Le 22/03/2022 Ã  13:29, Bruno Cabasson a Ã©critÂ :
> Hi,
> 
> Here is an updated package, including "oocore.inc". The test file 
> "oocore_ut.pov" provides examples on how classes can be defined and how 
> main OO features can work in the "testing whole classes" section.
> 
> Again, for the time being, this is only a study, and requires v3.8beta2.
> 
> Soon, and if this approach is accepted by people here, I will go further 
> with POV objects encapsulation within PROOF. As I already said, such an 
> encapsulation, in itself, does not bring much compared to native syntax. 
> Except we now can deal with objects and classes we can derive and attach 
> behaviour to.
> 
> To my eyes, POV-Sdl is not really a *programming* language. It is a 
> Scene Description Language, which is quite different and very 
> specialized. Since we have Object Orientedness, perhaps we could be in 
> position to make it a *real* programming language. Even if not 
> full-featured, even with limitations, even with syntactic and functional 
> sacrifices.
> 
> Of course, if it finally appears that nobody is interested, I will stop 
> the study and drop PROOF. Will not bother me much.
> 
> B.
> 

Hi.

Please find a WIP for the "objects.inc" file, with a basic test file 
(not intended for unit-testing) and a result image.

You can see the class hierachy I designed so far :

   +- ObjectItem
   |  |    - no properties -
   |  |    commit() // generates Sdl items
   |  |
   |  +- ObjectPhotons
   |  |      target_
   |  |      refraction_
   |  |      reflection_
   |  |      collect_
   |  |      pass_through_
   |  |      - no additional methods -
   |  |
   |  +- ObjectRadiosity
   |  |      importance_
   |  |      - no additional methods -
   |  |
   |  +- ObjectModifiers
   |  |      texture_
   |  |      _has_interior_texture
   |  |      interior_texture_
   |  |      _has_interior
   |  |      interior_
   |  |      _has_pigment
   |  |      pigment_
   |  |      _has_normal
   |  |      normal_
   |  |      _has_finish
   |  |      finish_
   |  |      _has_transform
   |  |      transform_
   |  |      object_photons
   |  |      _has_object_radiosity
   |  |      object_radiosity
   |  |      _has_bounded_by
   |  |      bounded_by_
   |  |      _has_clipped_by
   |  |      clipped_by_
   |  |      double_illuminate_
   |  |      hollow_
   |  |      no_shadow_
   |  |      no_image_
   |  |      no_reflection_
   |  |      no_radiosity_
   |  |      - no additional methods -
   |
   +- Object
      |   modifiers
      |   _spawned
      |   _instance
      |   spawn() // Actually creates the Sdl object
      |              (using ObjectItem's commmit() method)
      |
      +- Sphere
      |      center
      |      radius_
      |      - no additional methods -
      |
      +- Box
      |      ur
      |      ll
      |      - no additional methods -
      |
      +- Cylinder
      |      base
      |      cap
      |      radius_
      |      open_
      |     - no additional methods -
      |
      +- Torus
      |      major
      |      minor
      |      spindle_type
      |      sturm_
      |      - no additional methods -
      |
      .../... and so forth in the future for other POV objects.


I just implemented basic shapes to see what happens : sphere, box, 
cylinder and torus.

Objects classes can define 2 methods, invoked by describe() and dump() 
convenience macros:
  -) describe() ==> MyClass_describe() macro
       outputs a description of the class in the #debug channel
  -) dump() ==> MyClass_dump() macro
       outputs a dump of the contents of an instancein the #debug channel

The "object_test.pov" test file shows how these classes can be used and 
the "object_test.png" image is the result of the Run.

Using classes for such a scene is not really interresting. But we are 
now in the Object Oriented world. I will not explain the advantages of 
OO ....

RECALL : It is just the VERY beginning of a POC.

I hope I can illustrate soon how OO can help in our scenes (or 
animations). If any of you has ideas or inspiration, you are welcome to 
contribute.


Regards

     Bruno

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le logiciel antivirus
Avast.
https://www.avast.com/antivirus

[Bruno Cabasson] Re: PROOF : core include files and test code. [1476 days 19 hours and 47 minutes ago]

Tue, 22 Mar 2022 12:30:00 GMT

Hi,

Here is an updated package, including "oocore.inc". The test file 
"oocore_ut.pov" provides examples on how classes can be defined and how 
main OO features can work in the "testing whole classes" section.

Again, for the time being, this is only a study, and requires v3.8beta2.

Soon, and if this approach is accepted by people here, I will go further 
with POV objects encapsulation within PROOF. As I already said, such an 
encapsulation, in itself, does not bring much compared to native syntax. 
Except we now can deal with objects and classes we can derive and attach 
behaviour to.

To my eyes, POV-Sdl is not really a *programming* language. It is a 
Scene Description Language, which is quite different and very 
specialized. Since we have Object Orientedness, perhaps we could be in 
position to make it a *real* programming language. Even if not 
full-featured, even with limitations, even with syntactic and functional 
sacrifices.

Of course, if it finally appears that nobody is interested, I will stop 
the study and drop PROOF. Will not bother me much.

B.

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ
©rifiÃ©e par le logiciel antivirus Avast.
https://www.avast.com/antivirus

[Bruno Cabasson] Re: PROOF : core include files and test code. [1476 days 21 hours and 56 minutes ago]

Tue, 22 Mar 2022 10:21:04 GMT

Le 21/03/2022 Ã  20:22, Bald Eagle a Ã©critÂ :
> Bruno Cabasson <bru### [at] yahoofr> wrote:
> 
>>   > extend() - not sure how far you will be able to .. bend SDL , but
>> think that
>>   > an important macro like extend should be "general".  clipka's advice
>> wrt arrays
>>   > was (paraphrasing) "if you know the #elements in advance, declare the
>> array
>>   > sized"; however, if I were to:
>>   >    #declare A = array [2] {"a","b"};
>>   >    #declare B = array [2] {"c","d"};
>>   >    extend(A,B)
>>   > I'd get: "Parse Error: Array subscript out of range".
>>   >
>>
>> ===> You are correct. The use of some PROOF features may (and will)
>> imply some restrictions. But that's highly secondary for me. In this
>> particular case, I don't know if Sdl can detect if the array is of fixed
>> sized. Please, enlighten me.
> 
> I don't think it can tell in a non-error triggering way.
> 
> Looking at your code,
> 
> #macro extend(arr, extension_arr)
>      // We cannot know whether an array is "array" or "array mixed".
>      // So we let the parser generate an error if elements are of incompatible
> types.
>      #local start = dimension_size(arr, 1);
>      #for (i, 0, dimension_size(extension_arr, 1) - 1)
>          #local arr[start + i] = extension_arr[i];
>      #end
> #end
> 
> I think all you have to do is determine the size of both arrays, create a
> temporary array of either dynamic size, or big enough to hold all the elements
> of both, fill that array, and then declare the original array identifier name to
> now be the new temporary array.

==> this could change the nature of the target array. What would be the 
type of the resulting array (fixed/variable size, array/array_mixed)? 
The code should choose one possibility among 4, for example variable 
size array mixed. I think the code above is quite generic for both 
parameters, except for "arr" which must only be of variable size. That 
is one (small) of the restrictions for using PROOF. The parser does the 
appropriate checks during assignment.

However, my purpose during this VERY early stage of exploring a Proof Of 
Concept, and implementing a feasibility-showing Sdl code, is to 
determine if 3.8b2 features allow to define and implement basic 
Object-Oriented features, such as classes, properties, methods, 
inheritance, without too much dammage concerning syntax and usage ... If 
it is the case - and I think it is, see my future post with oocore.inc 
and its test code in the next hours - it would mean that we can benefit 
from the Object-Oriented'ness, even if it is with some restrictions. But 
it is just an exploration.

"primitives.inc" ans "collections.inc" are just helpers for now. They 
are NOT what is to foscus on now. Despite their quite secondary nature, 
I wrote test code to ensure minimal behaviour.

> 
> That would also let you get around the mixed array error, by making temporary
> array a mixed type.
> 

Hi,

Thanks for the suggestion.

While writing the code, I was facing two possibilities :

1) extend(my_arr, extension_arr),
	restriction :  my_arr is not declared of fixed size (PROOF standard ?)

or

2) #declare my_extended_arr = extend(my_arr, extension_arr)
	restriction : my_extended_arr is of a chosen type
	(variable/fixed size, array/array mixed), unless we use
	a 3rd parameter.

I decided arbitrarilly to write the first one : in-place extension, 
pretty much like Python's my_list.extend(extension_list), and assume the 
"small" restriction that arrays in PROOF are not declared fixed size. I 
am looking for functional OO features, not performance nor memory 
efficiency.

In the second case, perhaps a primitive named something like 
"catenate()" could to the thing. I can write it later.

I was also thinking of someting like python's "zip()"... But for now, I 
concentrate on OO aspects and feasibility.

Cheers

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le logiciel antivirus
Avast.
https://www.avast.com/antivirus

[Bald Eagle] Re: PROOF : core include files and test code. [1477 days 12 hours and 52 minutes ago]

Mon, 21 Mar 2022 19:25:00 GMT

Bruno Cabasson <bru### [at] yahoofr> wrote:

>  > extend() - not sure how far you will be able to .. bend SDL , but
> think that
>  > an important macro like extend should be "general".  clipka's advice
> wrt arrays
>  > was (paraphrasing) "if you know the #elements in advance, declare the
> array
>  > sized"; however, if I were to:
>  >    #declare A = array [2] {"a","b"};
>  >    #declare B = array [2] {"c","d"};
>  >    extend(A,B)
>  > I'd get: "Parse Error: Array subscript out of range".
>  >
>
> ===> You are correct. The use of some PROOF features may (and will)
> imply some restrictions. But that's highly secondary for me. In this
> particular case, I don't know if Sdl can detect if the array is of fixed
> sized. Please, enlighten me.

I don't think it can tell in a non-error triggering way.

Looking at your code,

#macro extend(arr, extension_arr)
    // We cannot know whether an array is "array" or "array mixed".
    // So we let the aprser generate an error if elements are of incompatible
types.
    #local start = dimension_size(arr, 1);
    #for (i, 0, dimension_size(extension_arr, 1) - 1)
        #local arr[start + i] = extension_arr[i];
    #end
#end

I think all you have to do is determine the size of both arrays, create a
temporary array of either dynamic size, or big enough to hold all the elements
of both, fill that array, and then declare the original array identifier name to
now be the new temporary array.

That would also let you get around the mixed array error, by making temporary
array a mixed type.

[Bruno Cabasson] Re: PROOF : core include files and test code. [1477 days 17 hours and 51 minutes ago]

Mon, 21 Mar 2022 14:25:50 GMT

Le 14/03/2022 Ã  17:34, jr a Ã©crit :
 > hi,
 >
 > Bruno Cabasson <bru### [at] yahoofr> wrote:
 >> Hi folks!
 >>
 >> Please find hereafter new versions of "primitives.inc" and
 >> "collections.in" with unit-testing code.
 >>
 >> Working on unit-testing "oocore.inc", the core Object Oriented features.
 >> Then will come "objects.inc" and its unit-testing file(s).
 >
 > have had a look around, some nice ideas there, genuinely looking 
forward to
 > seeing where, application-wise, your efforts will lead.  while the 
following
 > will probably read like "critique", it's not really, just highlighting
 > (potential) issues, and yes, adding a "gripe" or two .
 >
 > names.  collections.inc:234:"// Could not use 'slice' as it is a SDL 
keyword".
 > so why not 'Slice' (not that I'm advocating uppercase use :-)) or 
'_slice'?  the
 > problem, imo, is not the keyword per se, but your use of names like 
'get()' for
 > "globally visible"s, ie no "namespacing".  the "obvious" choice would 
be 'oo'
 > followed by underscore or camelcase.  (macro names used unadorned 
include:
 > check, exec, exists, extend, get, in, list, map, next.  sure, not 
keywords, but
 > common perhaps?)

===> I see these macro names as if they were part of the native 
language. Thus, I try to avoid CamelCasing or use underscores as prefix 
of suffix.

 >
 > if I understand the code correctly, in 'primitives.inc' you use the 'rgb'
 > keyword to coerce values to 3-vector format?  would '<1,1,1>*value' 
not do the
 > same, "cleaner"?
 >
 > extend() - not sure how far you will be able to .. bend SDL , but 
think that
 > an important macro like extend should be "general".  clipka's advice 
wrt arrays
 > was (paraphrasing) "if you know the #elements in advance, declare the 
array
 > sized"; however, if I were to:
 >    #declare A = array [2] {"a","b"};
 >    #declare B = array [2] {"c","d"};
 >    extend(A,B)
 > I'd get: "Parse Error: Array subscript out of range".
 >

===> You are correct. The use of some PROOF features may (and will) 
imply some restrictions. But that's highly secondary for me. In this 
particular case, I don't know if Sdl can detect if the array is of fixed 
sized. Please, enlighten me.

 > gripe(s): why does yr editor not always place whitespace between 
keyword and
 > brace?

===> Please, precise your mind.

personally also not a friend of long lines, particularly when concluded
 > by C++ style comment(s).

===> I agree that some lines are a bit long. Beautifying detail for now.

  including another include (colours) for just white +
 > yellow?  (also makes the versioning more "dependent")  tja,

===> Why not? Including a *small* file is not a problem. Did you never 
#include'ed & C/C++ file or import'ing a python module for just one 
symbol? Performance is not in my scope yet, and not significant for such 
a small file as colors.inc. Besides, #version'ing has ALWAYS been an 
issue and been part of our coding process.

    and then there's the
 > unit test output..   without any documentation for yr project, the 
results of
 > unit testing can only be of interest if the output _tells_ what one 
is looking
 > at, and states (consistently) 'fail' or 'pass', or such.  (time _is_ 
precious)
 >

===> PROOF is in an early state of POC, nothing more at the moment. Sdl 
does not ship with an UT engine, as other languages do (eg pyUnit for 
Python). So I do what Sdl currently allows me to do quite easily. My 
tests are abolutely not ment to be exhaustive. However, they are a 
minimum guarantee for myself and the code to be used for the next steps 
of the POC, even though they just output text. The output shows the 
functionning of my macros. It is no time for developping a UT engine 
prior to PROOF, in particular in this phase. Any contributor is 
welcome... It is also no time for documenting. Way too early. PROOF 
could be a conceptual flop... I try to comment (almost) everything so 
that the reader makes a global idea of things I write. I think I added 
quite a lot of explanations for where I am now.

 > anyway, as I said, curious + interested to see how it will all develop.
 >
 >
 > regards, jr.
 >

Hi. Sorry for the delay. I was on vacation last week without great 
possibility for POVing.

Your remarks are welcome and I'll take them into account in a next 
version. I also look forward for other people to comment and suggest.

New package including oocore.inc with (pseudo?)unit-tesing coming soon.

Regards

     Bruno

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le 
logiciel antivirus Avast.
https://www.avast.com/antivirus

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le logiciel antivirus
Avast.
https://www.avast.com/antivirus

[jr] Re: PROOF : core include files and test code. [1484 days 15 hours and 37 minutes ago]

Mon, 14 Mar 2022 16:40:00 GMT

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> Hi folks!
>
> Please find hereafter new versions of "primitives.inc" and
> "collections.in" with unit-testing code.
>
> Working on unit-testing "oocore.inc", the core Object Oriented features.
> Then will come "objects.inc" and its unit-testing file(s).

have had a look around, some nice ideas there, genuinely looking forward to
seeing where, application-wise, your efforts will lead.  while the following
will probably read like "critique", it's not really, just highlighting
(potential) issues, and yes, adding a "gripe" or two :-).

names.  collections.inc:234:"// Could not use 'slice' as it is a SDL keyword".
so why not 'Slice' (not that I'm advocating uppercase use :-)) or '_slice'?  the
problem, imo, is not the keyword per se, but your use of names like 'get()' for
"globally visible"s, ie no "namespacing".  the "obvious" choice would be 'oo'
followed by underscore or camelcase.  (macro names used unadorned include:
check, exec, exists, extend, get, in, list, map, next.  sure, not keywords, but
common perhaps?)

if I understand the code correctly, in 'primitives.inc' you use the 'rgb'
keyword to coerce values to 3-vector format?  would '<1,1,1>*value' not do the
same, "cleaner"?

extend() - not sure how far you will be able to .. bend SDL :-), but think that
an important macro like extend should be "general".  clipka's advice wrt arrays
was (paraphrasing) "if you know the #elements in advance, declare the array
sized"; however, if I were to:
  #declare A = array [2] {"a","b"};
  #declare B = array [2] {"c","d"};
  extend(A,B)
I'd get: "Parse Error: Array subscript out of range".

gripe(s): why does yr editor not always place whitespace between keyword and
brace?  personally also not a friend of long lines, particularly when concluded
by C++ style comment(s).  including another include (colours) for just white +
yellow?  (also makes the versioning more "dependent")  tja, and then there's the
unit test output.. :-)  without any documentation for yr project, the results of
unit testing can only be of interest if the output _tells_ what one is looking
at, and states (consistently) 'fail' or 'pass', or such.  (time _is_ precious)

anyway, as I said, curious + interested to see how it will all develop.

regards, jr.

[jr] Re: PROOF : core include files and test code. [1488 days 16 hours and 17 minutes ago]

Thu, 10 Mar 2022 16:00:00 GMT

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> ...
> Please find hereafter new versions of "primitives.inc" and
> "collections.in" with unit-testing code.

great, something for the weekend :-).


regards, jr.

[Thomas de Groot] Re: Gille Tran's media trees as a macro [2] [1490 days and 45 minutes ago]

Wed, 9 Mar 2022 07:31:44 GMT

Op 08/03/2022 om 10:28 schreef Mr:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Latest version, with the original macro by Gilles Tran added.
>>
>> --
>> Thomas
> 
> Awesome contribution, thanks! I can't wait to play with it once I see the end of
> my current refactoring tunnel for Blender to POV addon.
> 

<grin>
I already use this in a couple of scenes. Will be shown later.

-- 
Thomas

[Bruno Cabasson] Re: PROOF : core include files and test code. [1490 days 22 hours and 39 minutes ago]

Tue, 8 Mar 2022 09:37:09 GMT

Le 07/03/2022 Ã  19:26, Bruno Cabasson a Ã©critÂ :
> "jr" <cre### [at] gmailcom> wrote:
>> hi,
>>
>> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
>>> ... You can comment the #include statements.
>>
>> thanks, that did it.  will defer comment(s) until I've seen a more functional
>> example, other than to say that re yr comment about finding a way to test
>> whether the argument is a function (for 'primitives.inc:check'), have a look at
>> WFP's 'povr' and the 'setidtypes.inc' mechanism.
>>
>>
>> regards, jr.
> 
> Thanks!! Will post new version of "primitives.inc" and "collections.inc" with
> unit
> testing code. Then, I will do some unit testing with "oocore.inc". And then, I
> will expose my "objects.inc", the one that deals with scene objects,their core
> class hierachy and fundamental mechanisms.
> 
> Bruno
> 
> 
Hi folks!

Please find hereafter new versions of "primitives.inc" and 
"collections.in" with unit-testing code.

Working on unit-testing "oocore.inc", the core Object Oriented features. 
Then will come "objects.inc" and its unit-testing file(s).

Regards

     Bruno

-- 
L'absence de virus dans ce courrier Ã©lectronique a
Ã©tÃ© vÃ©rifiÃ©e par le logiciel antivirus
Avast.
https://www.avast.com/antivirus

[Mr] Re: Gille Tran's media trees as a macro [2] [1490 days 22 hours and 47 minutes ago]

Tue, 8 Mar 2022 09:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Latest version, with the original macro by Gilles Tran added.
>
> --
> Thomas

Awesome contribution, thanks! I can't wait to play with it once I see the end of
my current refactoring tunnel for Blender to POV addon.

[Bruno Cabasson] Re: PROOF : core include files and test code. [1491 days 13 hours and 47 minutes ago]

Mon, 7 Mar 2022 18:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > ... You can comment the #include statements.
>
> thanks, that did it.  will defer comment(s) until I've seen a more functional
> example, other than to say that re yr comment about finding a way to test
> whether the argument is a function (for 'primitives.inc:check'), have a look at
> WFP's 'povr' and the 'setidtypes.inc' mechanism.
>
>
> regards, jr.

Thanks!! Will post new version of "primitives.inc" and "collections.inc" with
unit
testing code. Then, I will do some unit testing with "oocore.inc". And then, I
will expose my "objects.inc", the one that deals with scene objects,their core
class hierachy and fundamental mechanisms.

Bruno

[jr] Re: PROOF : core include files and test code. [1492 days 10 hours and 32 minutes ago]

Sun, 6 Mar 2022 21:45:00 GMT

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> ... You can comment the #include statements.

thanks, that did it.  will defer comment(s) until I've seen a more functional
example, other than to say that re yr comment about finding a way to test
whether the argument is a function (for 'primitives.inc:check'), have a look at
WFP's 'povr' and the 'setidtypes.inc' mechanism.


regards, jr.

[Bruno Cabasson] Re: PROOF : core include files and test code. [1492 days 14 hours and 47 minutes ago]

Sun, 6 Mar 2022 17:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > Here is a zip containing PROOF's core include files and a basic test code file.
> >
> > Contents:
> > ...
>
> oops..  ;-)
>
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
>   ...
> ==== [Parsing...] ==========================================================
> File 'oocore.inc' line 35: Possible Parse Error: Cannot find file
>  'collections.inc', even after trying to append file type extension.
> File 'oocore.inc' line 35: Parse Error: Cannot open include file
>  collections.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> regards, jr.

Yes, ooops :)

So sorry. However, "collections.inc" is not required for "oocore.inc" and
"oocore_test.inc" ... You can comment the #include statements.

B.

[jr] Re: PROOF : core include files and test code. [1494 days 17 hours and 12 minutes ago]

Fri, 4 Mar 2022 15:05:00 GMT

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> Here is a zip containing PROOF's core include files and a basic test code file.
>
> Contents:
> ...

oops..  ;-)

Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
  ...
==== [Parsing...] ==========================================================
File 'oocore.inc' line 35: Possible Parse Error: Cannot find file
 'collections.inc', even after trying to append file type extension.
File 'oocore.inc' line 35: Parse Error: Cannot open include file
 collections.inc.
Fatal error in parser: Cannot parse input.
Render failed

regards, jr.

[jr] Re: PROOF : core include files and test code. [1496 days 14 hours and 22 minutes ago]

Wed, 2 Mar 2022 17:55:00 GMT

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> Here is a zip containing PROOF's core include files and a basic test code file.

quick.  :-)  thanks, will find some time to look at week's end.

> ...
> Rem2 : Trees are complex structures that can be embeded in classes.

fwiw, here's a (quad)tree in SDL:

<https://news.povray.org/povray.binaries.images/message/%3Cweb.5eeb464b936ed80b4d00143e0%40news.povray.org%3E/#%3Cweb.5
eeb464b936ed80b4d00143e0%40news.povray.org%3E>


regards, jr.

[Bruno Cabasson] PROOF : core include files and test code. [1496 days 22 hours and 2 minutes ago]

Wed, 2 Mar 2022 10:15:00 GMT

Hi,

Here is a zip containing PROOF's core include files and a basic test code file.

Contents:
primitives.inc : basic definitions (some could be part of POV-Sdl native syntax)
oocore.inc : object oriented core features, definitions, macros, etc ...
oocore_test.inc : test code for oocore.inc. The result is text in #debug
channel.
oocore_test.pov : scene file for oocore_test.inc. The appearance of the
                  ready made basic scene means all went OK.

                  ==> Run the "oocore_test.pov" file and see the #debug channel
(Messages tab) for the results.

Remember, it is just an WIP for an early POC.

I consider that the main OO features are available and oocore.inc makes the job.
Therefore, I had a go for objects in scene and designed classes in order to
describe spheres, boxes, cylinder, toruses, and (in the future) all POV's
objects by PROOF's classes, including voluminous objects (mesh, mesh2, blob,
complex CSG's...) for which we will be in position to control the behaviour.

REMARKS:

Rem1: splines can be described by classes and be easily controlled because
instances keep track of internal data (spline defining points in this case). We
can extend, catenate, normalize, .... in a clean and easy manner. Splines are in
my TODO list.


Rem2 : Trees are complex structures that can be embeded in classes.

Rem3 : Animation could be eased with an object-oriented approach

Rem4 : I think that if I could write Sdl code for OO, then the parser can do it
natively with the appropriate evolutions.

Regards

Bruno

[Cousin Ricky] Re: Modified golds.inc and metals.inc [1500 days 4 hours and 20 minutes ago]

Sun, 27 Feb 2022 03:56:39 GMT

On 2022-02-26 04:53 (-4), William F Pokorny wrote:
> On 2/24/22 17:41, Cousin Ricky wrote:
>>
>> I have named myself in the modification texts, yet the original authors
>> are not named.Â  This feels awkward.Â  Does anyone know who
wrote the
>> originals?
> 
> I'd say attribute the work originally to the POV-Team circa 1995/1996.

Thanks.  It just occurred to me that these files were not brought under
Creative Commons until POV-Ray 3.7; prior to that, they were under
povlegal.doc.  From that document, it appears that the proper
attribution is to the POV-Ray Team(tm), 1996.

> Not definitive by any means - and before I started to use POV-Ray - but
> there is a file called 'metals.doc' which first shows up in my captured
> source tarballs in v3.0. I don't see it or anything like it in the
> earlier v2.2.

[From metals.doc]> Â  The differences between any two adjacent finishes
should be
> negligable, yet the differences between any three should be quite
> noticeable.Â  At least, that was our goal.

I believe that I have maintained this goal with gold.inc, less so with
metals.inc.  With the non-gold metals, there is such a wide breadth
between the dullest finish and the most polished finish that it is
difficult to have a gradual transition between finishes.  But I do not
believe I did any worse than the original authors.

I did see that the original scene files in the texsamps/metals folder
explicitly set assumed_gamma at 2.2, which would seem to argue for sRGB
conversion of the pigment colors.  However, the old finish properties
were such that they exaggerated the luminance of the colors; thus, sRGB
conversion would have made the pigments too dark with my upgrade, which
is evident in my first post to p.b.i.  Therefore, I will leave the
colors as-is.

[William F Pokorny] Re: Modified golds.inc and metals.inc [1500 days 23 hours and 23 minutes ago]

Sat, 26 Feb 2022 08:53:43 GMT

On 2/24/22 17:41, Cousin Ricky wrote:
> Please find attached new versions of golds.inc and metals.inc, as well
> as the portfolio scene t_metals.pov with t_metals.ini.
> 
> I have named myself in the modification texts, yet the original authors
> are not named.  This feels awkward.  Does anyone know who wrote the
> originals?
> 
> The include files are #versioned at 3.8, but they should work fine with
> 3.7 if you change the #version.  The portfolio files are unaltered from
> 3.8.0-beta.2.

I'd say attribute the work originally to the POV-Team circa 1995/1996.

Not definitive by any means - and before I started to use POV-Ray - but 
there is a file called 'metals.doc' which first shows up in my captured 
source tarballs in v3.0. I don't see it or anything like it in the 
earlier v2.2.

It contains no list of authors(a), but the following text can be found 
at the bottom of the file:

...

Synopsis:
=========
METALS.INC is the result of studying the current metal textures and a
few other good ones that we've collected in the past year and doing our
best at determining what they have in common.  We originally came up 
with nine finishes, but eventually distilled that into the five that you 
see here.  The differences between any two adjacent finishes should be
negligable, yet the differences between any three should be quite
noticeable.  At least, that was our goal.

We also did our best at arriving at a set of five color variations for
each of the metal groups.  This isn't perfect, but we think we came pretty
close.

The finishes range from soft, rough, & dull (the "A" finishes) to hard &
highly polished (the "E" finishes)

...EOF

Bill P.

(a) - Elsewhere, Dan Farmer is listed doing other metal work, but the 
'we' in the 'metals.doc' synopsis I expect equates to POV-Team more or less.

[Thomas de Groot] Re: Modified golds.inc and metals.inc [1501 days 18 hours and 6 minutes ago]

Fri, 25 Feb 2022 14:10:58 GMT

Op 24-2-2022 om 23:41 schreef Cousin Ricky:
> Please find attached new versions of golds.inc and metals.inc, as well
> as the portfolio scene t_metals.pov with t_metals.ini.
> 
> I have named myself in the modification texts, yet the original authors
> are not named.  This feels awkward.  Does anyone know who wrote the
> originals?
> 
> The include files are #versioned at 3.8, but they should work fine with
> 3.7 if you change the #version.  The portfolio files are unaltered from
> 3.8.0-beta.2.

Thank you!

-- 
Thomas

[Cousin Ricky] Modified golds.inc and metals.inc [1502 days 9 hours and 35 minutes ago]

Thu, 24 Feb 2022 22:41:14 GMT

Please find attached new versions of golds.inc and metals.inc, as well
as the portfolio scene t_metals.pov with t_metals.ini.

I have named myself in the modification texts, yet the original authors
are not named.  This feels awkward.  Does anyone know who wrote the
originals?

The include files are #versioned at 3.8, but they should work fine with
3.7 if you change the #version.  The portfolio files are unaltered from
3.8.0-beta.2.

[Cousin Ricky] Re: Spiral image macro, version 2.0 [1513 days 10 hours and 19 minutes ago]

Sun, 13 Feb 2022 21:57:39 GMT

On 2022-02-03 20:49 (-4), Cousin Ricky wrote:
> I don't know how Matthew did his, but this is my take.
> 
> You will need SphereSweep from the Object Collection as a prerequisite.
> SphereSweep can be obtained at:
>   https://github.com/CousinRicky/POV-SphereSweep

I added some macros to compute sizes and scale the image map (pigment,
actually), and prepared it for the Object Collection when it comes back
online. It us currently hosted on GitHub:
  https://github.com/CousinRicky/POV-SpiralImage

[Cousin Ricky] Re: Spiral image macro [1514 days 12 hours and 7 minutes ago]

Sat, 12 Feb 2022 20:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I don't know how Matthew did his, but this is my take.

Doh!  "Square <0, 0, 0>...<1, 1, 1>" should be "Square <0, 0, 0>...<1, 1, 0>"!

[m@b] Re: Spiral image macro [1523 days and 23 minutes ago]

Fri, 4 Feb 2022 07:53:19 GMT

On 04/02/2022 8:49 am, Cousin Ricky wrote:
> I don't know how Matthew did his, 


Here are the bones of it:


// Starting points
#declare X0 = 0.001;
#declare Y0 = 0.001;

// Loop
#for(i, 0, 150, 0.01)

     // Displacement - how fast the spiral expands
     #declare D = i*0.003;

     // Angle between steps
     #declare A = i*100;

     // Calculate position on the input image
     #declare X = D*cosd(A);
     #declare Y = D*sind(A);

     // Get value from image
     Colour_test()

     // Draw a cylinder from previous point to current point
     cylinder{<X0,Y0,0><X,Y,0>, 0.005*Brightness}

     // Save current point for next iteration
     #declare X0 = X;
     #declare Y0 = Y;
#end

[Cousin Ricky] Spiral image macro [1523 days 7 hours and 27 minutes ago]

Fri, 4 Feb 2022 00:49:52 GMT

I don't know how Matthew did his, but this is my take.

You will need SphereSweep from the Object Collection as a prerequisite.
SphereSweep can be obtained at:
  https://github.com/CousinRicky/POV-SphereSweep

[Thomas de Groot] Re: Gille Tran's media trees as a macro [2] [1571 days 16 hours and 17 minutes ago]

Fri, 17 Dec 2021 15:59:39 GMT

Latest version, with the original macro by Gilles Tran added.

-- 
Thomas

[Thomas de Groot] Gille Tran's media trees as a macro [1572 days 18 hours and 48 minutes ago]

Thu, 16 Dec 2021 13:28:24 GMT

Attached, the media trees as created by Gilles Tran in his MakeClouds 
scene (2003).

Enjoy

-- 
Thomas

[Thomas de Groot] Apophyllite [1615 days 15 hours and 32 minutes ago]

Wed, 3 Nov 2021 16:44:06 GMT

Please find here everything necessary to render the apophyllite crystal.

-- 
Thomas

[MichaelJF] Re: Misty mountains impression [1648 days 17 hours and 17 minutes ago]

Fri, 1 Oct 2021 15:00:03 GMT

Am 20.09.2021 um 05:09 schrieb Cousin Ricky:
> Can this thread be deleted? I Accidentally posted it to the wrong newsgroup.
> 
> 
One can delete own postings by deleting them in Thunderbird. Simply 
select the posting and press delete. One cannot delete postings from 
other users. So I have no idea what will happen to this answer. If it 
works with other newsreaders, I have no idea too.

Best regards
Michael

[Cousin Ricky] Re: Misty mountains impression [1660 days 5 hours and 7 minutes ago]

Mon, 20 Sep 2021 03:10:00 GMT

Can this thread be deleted? I Accidentally posted it to the wrong newsgroup.

[Cousin Ricky] Misty mountains impression [1660 days 5 hours and 12 minutes ago]

Mon, 20 Sep 2021 03:04:59 GMT

I'm currently visiting the Blue Ridge Mountains in North Carolina, and
the mist in the air reminds me of when I visited the Shenandoah
Mountains in northwestern Virginia 13 years ago, and why I implemented
hills the way I did in my 3rd generation render rig.  Compare this with
the hills of my 4th generation reboot.

[pascal] Re: 3dclouds include file [1662 days 18 hours and 43 minutes ago]

Fri, 17 Sep 2021 13:33:20 GMT

Le 15/09/2021 à 20:44, brookville a écrit :
> Hi pascal - here's 3dclouds.pov I had from sascha
> 
> start pov -
> //---------------------------------------------------------
> #version 3.7;
> global_settings{ assumed_gamma 1.0 }
> 
> camera { location <0,2,0>
> direction z
> up y
> right x*image_width/image_height
> }
> 
> plane{ y,0 texture { checker
> texture { pigment { color srgb 1 }},
> texture {pigment { color srgb 0 }}
> } }
> 
> light_source { <0,2000,0>,1 }
> 
> sky_sphere { pigment { color srgb <0.3, 0.6,0.9> }}
> 
> #declare clouds_ambient = 2;
> #declare clouds_fill = 0.6;
> #include "3dclouds.inc"
> //--------------------------------------------------------
> -end pov
> 
> 

Wow ! That's four year ago !

Thank's a lot !

I join the 3dclouds.inc file for others who don't have it !

Thanks again,

Regards

Pascal

[Alain Martel] Re: 3dclouds include file [1663 days 15 hours and 58 minutes ago]

Thu, 16 Sep 2021 16:18:06 GMT

Le 2021-09-15 à 14:44, brookville a écrit :
> Hi pascal - here's 3dclouds.pov I had from sascha
> 
> start pov -
> //---------------------------------------------------------
> #version 3.7;
> global_settings{ assumed_gamma 1.0 }
> 
> camera { location <0,2,0>
> direction z
> up y
> right x*image_width/image_height
> }
> 
> plane{ y,0 texture { checker
> texture { pigment { color srgb 1 }},
> texture {pigment { color srgb 0 }}
> } }
> 
> light_source { <0,2000,0>,1 }
> 
> sky_sphere { pigment { color srgb <0.3, 0.6,0.9> }}
> 
> #declare clouds_ambient = 2;
> #declare clouds_fill = 0.6;
> #include "3dclouds.inc"
> //--------------------------------------------------------
> -end pov
> 
> 
srgb 1 and srgb 0 are exactly the same as rgb 1 and rgb 0.
srgb should only be used when using the colour returned from a colour 
picker.

This need the file «3dclouds.inc».
Many peoples don't have it.

[brookville] Re: 3dclouds include file [1664 days 13 hours and 32 minutes ago]

Wed, 15 Sep 2021 18:45:00 GMT

Hi pascal - here's 3dclouds.pov I had from sascha

start pov -
//---------------------------------------------------------
#version 3.7;
global_settings{ assumed_gamma 1.0 }

camera { location <0,2,0>
direction z
up y
right x*image_width/image_height
}

plane{ y,0 texture { checker
texture { pigment { color srgb 1 }},
texture {pigment { color srgb 0 }}
} }

light_source { <0,2000,0>,1 }

sky_sphere { pigment { color srgb <0.3, 0.6,0.9> }}

#declare clouds_ambient = 2;
#declare clouds_fill = 0.6;
#include "3dclouds.inc"
//--------------------------------------------------------
-end pov


pascal <pas### [at] wanadoofr> wrote:
> On 21/05/2017 08:41, Thomas de Groot wrote:
> > On 20-5-2017 12:45, Norbert Kern wrote:
> >> Thomas de Groot <tho### [at] degrootorg> wrote:
> >>
> >>> Thanks too. That one was missing from my collection :-)
> >>
> >>
> >>
> >> Hi Thomas,
> >>
> >> perhaps we should exchange our collections (I'm living in Northrhine
> >> Westphalia...)
> >>
> >> My main comps foresay for images and pov-related files about 1 to 2
> >> TB, so why
> >> not meet physically and excange (mobile) hard drives?
> >>
> >> Of course I'ld include all of my personal files too...
> >>
> >>
> >> Norbert
> >>
> >
> > Hmmm, that is more volume than I have memory to tell the truth :-) In
> > all fairness, I only collect what I /think/ I may need one day, so I
> > cannot boast to a very complete POV-Ray collection and much of it I have
> > never used. I would rather like to call for a way to bring all those
> > goodies produced over the years to the easy access of everybody
> > interested, like the Objects Collection. I think it is a pity that so
> > much has gone into oblivion.
> >
> I totally agree...
> I used to play with povray about 15 years ago...and there were plenty of
> sites, tutos etc dedicated to this. The large majority of my saved pov's
> bookmark is dead now.
> I lost the drive on which I saved all this stuff.
> And by the way...If I'd dare...I ask if someone has the Ledensky's
> "3dclouds.pov" which came with the include file ?
> Thanks in advance...
> Pascal

[jr] Re: Granite_21 - the final macro [1674 days 1 hour and 7 minutes ago]

Mon, 6 Sep 2021 07:10:00 GMT

hi,

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

> Thomas de Groot <tho### [at] degrootorg> wrote:
>
> > One way or another, the whole POV-Ray community has contributed to the
> > initiation and building of this macro. Two people need special thanks:
> > Bald Eagle, who on a regular basis asked relevant questions and
> > contributed significant solutions. He was instrumental too in the
> > writing of the documentation which is why he co-authors this document.
> > The second person is jr. He guided me through the css and html arcane
> > knowledge during the building of the web pages.

cheers, a pleasure.


> Thanks, Thomas.  You've done a masterful job with your implementation of so many
> features into this material {}, and I think this is a surface texturing example
> that is very thorough and professional.   Hopefully it inspires further
> development of other challenging textures and materials, and maybe a revisiting
> of other excellent textures developed by some of the very talented members of
> the POV-Ray community over the years.

agree, inspiring work.  (and fingers crossed)



> jr is a real workhorse, with an impressive skill set, and a thirst for attacking
> new projects with gusto.

heh, I have a C.V. now ?!  :-)



>  I'm glad the three of us got to network and
> collaborate on this so that the whole package - macro, example scenes, and
> documentation are as good as we could make them given the usual constraints of
> time and energy.

yes.  speaking for myself -- quality time, thanks to both of you.


regards, jr.

[Bald Eagle] Re: Granite_21 - the final macro [1674 days 13 hours and 47 minutes ago]

Sun, 5 Sep 2021 18:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> One way or another, the whole POV-Ray community has contributed to the
> initiation and building of this macro. Two people need special thanks:
> Bald Eagle, who on a regular basis asked relevant questions and
> contributed significant solutions. He was instrumental too in the
> writing of the documentation which is why he co-authors this document.
> The second person is jr. He guided me through the css and html arcane
> knowledge during the building of the web pages.

Thanks, Thomas.  You've done a masterful job with your implementation of so many
features into this material {}, and I think this is a surface texturing example
that is very thorough and professional.   Hopefully it inspires further
development of other challenging textures and materials, and maybe a revisiting
of other excellent textures developed by some of the very talented members of
the POV-Ray community over the years.

jr is a real workhorse, with an impressive skill set, and a thirst for attacking
new projects with gusto.  I'm glad the three of us got to network and
collaborate on this so that the whole package - macro, example scenes, and
documentation are as good as we could make them given the usual constraints of
time and energy.

> One thing is still missing though: a comprehensive HowTo for building
> your own granites materials.

It will be interesting to see how others come up with independent methods of
constructing new patterns and color maps.  You've already created quite a
selection of nice materials to serve as examples of how it all works.

> Because I am already thinking about Granites_22.

But of course you are  :D

[Thomas de Groot] Granite_21 - the final macro [1674 days 20 hours and 35 minutes ago]

Sun, 5 Sep 2021 11:41:33 GMT

The final version of Granite_21 is here.

The attached zip file contains everything you need. Particular attention 
has been paid to the documentation and two versions are offered: a PDF 
version and a HTML version. They are identical except for some layout 
constraints and you can use whichever you prefer.

To get acquainted, start with the Granite_21_demo.pov scene file. This 
is a simple scene which demonstrates the straightforward use of the 
macro and its different parameters, applied to a couple of simple objects.

One way or another, the whole POV-Ray community has contributed to the 
initiation and building of this macro. Two people need special thanks: 
Bald Eagle, who on a regular basis asked relevant questions and 
contributed significant solutions. He was instrumental too in the 
writing of the documentation which is why he co-authors this document. 
The second person is jr. He guided me through the css and html arcane 
knowledge during the building of the web pages.

The macro is intended for POV-Ray version 3.8 and higher. In its present 
form, the macro cannot be used by earlier versions. The choice for this 
has been a difficult one but was finally made because of very necessary 
and useful array structures which are only provided starting with 
version 3.8. It is not always possible nor, maybe, advisable, to stick 
to backward compatibility at all cost.

One thing is still missing though: a comprehensive HowTo for building 
your own granites materials. I need more time to work on this and 
include a number of ideas I still have on the back-burner.

Because I am already thinking about Granites_22.

In the coming months I shall probably be less present in these ng's 
(Real Life) but I shall try to answer all questions and try to solve 
issues where necessary.

I sincerely hope that Granite_21 answers all your expectations.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta 1.7 - documentation [1729 days 19 hours and 57 minutes ago]

Mon, 12 Jul 2021 12:19:21 GMT

Op 12-7-2021 om 13:23 schreef Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>> Which makes me think of that other 3.8 feature you mentioned earlier
>>> about keeping declarations between renders (circumventing #undef)?
>>
>> There's no such official v3.8 feature.
> 
> I *think* what he was referencing was this:
> 
> http://news.povray.org/web.60b43edf388d0b7a1f9dae3025979125%40news.povray.org
> 
> Not identifier values that persist between _renders_ but between sequential
> invocations of the texture-defining macro in the same scene.
> 

"optional" that is the one.

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta 1.7 - documentation [1729 days 20 hours and 52 minutes ago]

Mon, 12 Jul 2021 11:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> > Which makes me think of that other 3.8 feature you mentioned earlier
> > about keeping declarations between renders (circumventing #undef)?
>
> There's no such official v3.8 feature.

I *think* what he was referencing was this:

http://news.povray.org/web.60b43edf388d0b7a1f9dae3025979125%40news.povray.org

Not identifier values that persist between _renders_ but between sequential
invocations of the texture-defining macro in the same scene.

[clipka] Re: Granite_21 macro - beta 1.7 - documentation [1729 days 21 hours and 12 minutes ago]

Mon, 12 Jul 2021 11:04:28 GMT

Am 12.07.2021 um 08:21 schrieb Thomas de Groot:

> One thing which has been worrying me a bit is that the use of mixed 
> arrays just cuts backward compatibility, starting with 3.7. I have to 
> test with the newest beta by clipka & friends yet, to be sure about even 
> official 3.8.

Mixed arrays should still work; they were introduced quite a while 
before the rollback point.

> Which makes me think of that other 3.8 feature you mentioned earlier 
> about keeping declarations between renders (circumventing #undef)? 

There's no such official v3.8 feature.

[Bald Eagle] Re: Granite_21 macro - beta 1.7 - documentation [1729 days 22 hours and 7 minutes ago]

Mon, 12 Jul 2021 10:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Very good, and thanks. I need to go through this with a fine comb indeed
> now.
>
> Yes, I think you need my address for further discussions. A little
> rebus:

Ah yes.  !verbis sed 'rebus'  Very good, sir.

I shall email you this time zone's afternoon, the !syzygy of events permitting.

[Thomas de Groot] Re: Granite_21 macro - beta 1.7 - documentation [1730 days 1 hour and 55 minutes ago]

Mon, 12 Jul 2021 06:21:39 GMT

Op 11/07/2021 om 23:08 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> @Bald Eagle: Bill, may I ask you to go through this latest version?
> 
> I think I covered everything I could think of.
> Will you email me - we should discuss an immediate application, pre-release.
> 

Very good, and thanks. I need to go through this with a fine comb indeed 
now.

Yes, I think you need my address for further discussions. A little 
rebus: thomdegfullstop01atgmailperiodcom  :-)

One thing which has been worrying me a bit is that the use of mixed 
arrays just cuts backward compatibility, starting with 3.7. I have to 
test with the newest beta by clipka & friends yet, to be sure about even 
official 3.8.

However, it might be a good idea to start fresh as it were. ;-)

Which makes me think of that other 3.8 feature you mentioned earlier 
about keeping declarations between renders (circumventing #undef)? 
Remind me of its name as I forgot it. It might be good to include it 
under these circumstances.

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta 1.7 - documentation [1730 days 11 hours and 7 minutes ago]

Sun, 11 Jul 2021 21:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> @Bald Eagle: Bill, may I ask you to go through this latest version?

I think I covered everything I could think of.
Will you email me - we should discuss an immediate application, pre-release.

[Bald Eagle] Re: Granite_21 macro - beta 1.7 - documentation [1730 days 15 hours and 17 minutes ago]

Sun, 11 Jul 2021 17:00:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> OK. Before uploading beta 1.7, I would prefer to have a (language) check
> on the documentation that is, imo, in a fairly final stage.
>
> @Bald Eagle: Bill, may I ask you to go through this latest version?

Just DL'd and will give it a read-through later this afternoon.

It's been a long haul on this project since its inception, and you've put a lot
of work into this.  :)

[Thomas de Groot] Granite_21 macro - beta 1.7 - documentation [1730 days 17 hours and 15 minutes ago]

Sun, 11 Jul 2021 15:01:44 GMT

OK. Before uploading beta 1.7, I would prefer to have a (language) check 
on the documentation that is, imo, in a fairly final stage.

@Bald Eagle: Bill, may I ask you to go through this latest version?

Note: I have abandoned a couple of older granites (CanadianPink and 
IndiaBlack) which are too close to other provided granites to be of 
interest.

-- 
Thomas

[ingo] Re: curve.inc [1745 days 17 hours and 13 minutes ago]

Sat, 26 Jun 2021 15:04:00 GMT

in news:XnsAD34A6FC6BEB5seed7@news.povray.org ingo wrote:

> an include file for interpolating curves and spline. 20 different
> ones for now. It is based on work by Mr. Noskowicz. 

attached an updated version, fixed TCB spline, refactoring and added a CIt 
curve that takes two curves. One to modify the t value for the other 
curve. This to somewhat mimick the cuuren spline implementation in POV-Ray

Ingo

-- 
https://ingoogni.nl

[Thomas de Groot] Re: Granite_21 macro - beta #1.6 [1746 days 20 hours and 13 minutes ago]

Fri, 25 Jun 2021 12:03:30 GMT

This should do the trick.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.6 [1746 days 23 hours and 45 minutes ago]

Fri, 25 Jun 2021 08:31:53 GMT

Bill, that little scene file you wrote (color_map gradient scene) is 
going to be very useful! I post here an improved version together with 
an image output. I think that, changed into a macro, it could be very 
helpful for writing new granite maps.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.6 [1748 days 19 hours and 39 minutes ago]

Wed, 23 Jun 2021 12:37:22 GMT

Op 22-6-2021 om 21:18 schreef Bald Eagle:
> Here ya go:
> 

I started transposing your corrections to the docs. They make all the 
difference indeed. Writing correct English is a real challenge; 
notwithstanding the opinion of some. ;-)

I was aware of the lack of some definitions and better explanations but 
got lazy of course; I knew it would be thrown back at me later. ;-) 
Additional work to do here.

A couple of answers to your comments I can already make here:

"Now, you have
scale M_scale
rotate M_rotat
translate M_trans
Are these really necessary in the macro? "

They are not really essential for the macro indeed and could be left 
outside. However, I decided to keep them /inside/ the macro for a 
psychological reason: this way, the user will remain more aware of the 
changes he /forces/ on the granite.

"I think that an annotated diagram of the final texture should accompany 
this document, and perhaps
some specialized renders of the array results â€“ showing how the
texture 
elements correspond to the
array entries, especially the mask. "

Yes, I was thinking on the same lines here.

"Line 26: Why not just expand â€œTypâ€ to
â€œTypeâ€? "

Yes, of course.

"Line 391 â€“ spelling â€œaligneâ€
â†’ align "

<grin> nice typo. Shows my French background trying to struggle to the 
surface when I am not looking. :-)

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.6 [1749 days 2 hours and 10 minutes ago]

Wed, 23 Jun 2021 06:06:57 GMT

Op 22/06/2021 om 21:18 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I want to ask
>> you to critically review the structure and text of the docs on
>> comprehension and language. Native speakers, sharpen you pens! I
>> consider this to be a very essential exercise, so please do not spare me
>> nor my text.
> 
> Here ya go:
> 

Perfect Bill and thanks! That is what I mean. :-)

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.6 [1749 days 12 hours and 57 minutes ago]

Tue, 22 Jun 2021 19:20:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> I want to ask
> you to critically review the structure and text of the docs on
> comprehension and language. Native speakers, sharpen you pens! I
> consider this to be a very essential exercise, so please do not spare me
> nor my text.

Here ya go:

[Thomas de Groot] Granite_21 macro - beta #1.6 [1749 days 17 hours and 23 minutes ago]

Tue, 22 Jun 2021 14:53:55 GMT

OK. After some delays, please find the latest beta of the granite macro.

You will find that a number of fundamental changes have been made: 
changes to array names and internal parameter names; corrections of 
remaining errors; aligning the granite textures to real world 
dimensions; changing some arrays to mixed arrays. I probably forgot a 
few but they may not influence your understanding/use.

Of course, the two developed granite data include files to date (pending 
future ones) have also been corrected.

A first draft of the documentation is included here in pdf-format. It 
concerns principally the macro structure itself which is rather complex 
I confess. The documentation will be expanded later on. I want to ask 
you to critically review the structure and text of the docs on 
comprehension and language. Native speakers, sharpen you pens! I 
consider this to be a very essential exercise, so please do not spare me 
nor my text. In a final stage I may also provide a html version.

Some examples are posted in p.b.i.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1755 days 1 hour and 37 minutes ago]

Thu, 17 Jun 2021 06:39:44 GMT

Op 01/06/2021 om 14:49 schreef Thomas de Groot:
> Op 31-5-2021 om 03:41 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> - A comprehensive demo scene file
>>
>>> - An investigation/implementation of Real World dimensions (should have
>>> started with that, but you know of it goes...)
>>
>>> - Additional xxxGranite.inc files to be fed to the macro
>>
>> So I was playing with a scene for editing the material's color_map, 
>> and in
>> addition to the inc file stuff, I noticed that you had removed all of 
>> the macro
>> parameters.
>>
>> I think that works really nicely, so far.
>>
>> On the one hand, I like the #undef stuff at the end, but with what I'm 
>> doing
>> with variations on the same theme, I noticed that that causes me to 
>> have to
>> redeclare any macro parameters before each call.  No big deal - I can 
>> work with
>> that.
>>
> Yes, but it might not be the best solution...
> 
>> But I'm thinking if it doesn't change anything, maybe have it work like
>>
>> Granite_21 (optional parameters_persist)
>> (default is no)
>> and then #if (parameters_persist) would govern macro section 7
>>
> Problem is that the 'optional' parameter is still only version 3.8 of 
> POV. Not desirable for now I am afraid.
> 
Now, with POV-Ray development started in earness again, the use of the 
'optional' parameter may become interesting again. I have to delve into 
its use because I do not entirely understand /how/ it works, but with a 
couple of test scenes I shall get the hang of it I expect.

>> I have some things laid out with to-scale rulers, and with respect to 
>> the SSLT
>> I'm wondering what I should do to indicate the - depth - of the 
>> translucency
>> effect.  I'm not sure that I know of an equation / documentation / 
>> diagram for
>> calculating / estimating the effect given an rgb 1 light_source and 
>> material
>> thickness.
>>
> After all the commotion about the Granite_file, I still have to plunge 
> into this.
> 
No change here at the moment.

>> I'm going to try to figure out a way to get as much useful visual info 
>> into the
>> scene, but minimize the long render time effect of the SSLT.
>>
>> Perhaps as a lead-in to the documentation, you could just briefly 
>> comment on the
>> layout and purpose of the macro parts - the masks and such?
>>
> I shall see what I can do on short term....
> 
Slow work somehow, but it is growing. I hope it will meet your 
expectations ;-)

>> Thanks,
>>
>> - Bill
>>
>> Attached is highlighting 2 color_map entries in green, and then 
>> replacing them
>> with black.  Just a little macro to make it easier to do from within 
>> the scene
>> file.
>>
> That could be nice indeed... The original color_maps will need a serious 
> overhaul I am afraid.
> 
That "Granite Editor" of yours, Can you post me a copy? It looks like an 
interesting tool to use in the approach to re-defining the color_maps, 
and I do it intuitively by hand now. Thanks.


-- 
Thomas

[ingo] Re: curve.inc [1764 days 22 hours and 56 minutes ago]

Mon, 7 Jun 2021 09:20:21 GMT

in news:XnsAD34A6FC6BEB5seed7@news.povray.org ingo wrote:

> an include file for interpolating curves and spline. 20 different
> ones for now. It is based on work by Mr. Noskowicz. 

After unconfusing myself I rewrote the spline framework and simplified it 
quite a bit. So, new version to poke at.

(as an excersize I also did a version of it in Nim ( https://nim-lang.org/ 
), if one is interested)

Ingo
-- 
https://ingoogni.nl

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1766 days 1 hour and 54 minutes ago]

Sun, 6 Jun 2021 06:22:14 GMT

Op 05/06/2021 om 16:55 schreef Alain Martel:
> To make your turbulence smoother, reducing the octave parameter could 
> help. It default at 6. So, maybe try with octave 3.
> 
> Next, you can also reduce the lambda. Default of 2. Make it closer to 1.
> 
> Finally, the omega could also get adjusted down from the default of 0.5.
> 
> A proposition :
> octave 3
> lambda 1.4
> omega 0.25
> 
> This should make the turbulence much more wavy and smoother.

Yes indeed, and thanks for the reminder. Presently I have no time to 
deal too much with this, but Bald Eagle will take that up quite probably :-)

For now, I need to concentrate on that part of the docs I mentioned 
earlier, and deal with a couple of little thorns in the macro code which 
have not been dealt with fully to my satisfaction.

-- 
Thomas

[Alain Martel] Re: Granite_21 macro - beta #1.5 [1766 days 17 hours and 21 minutes ago]

Sat, 5 Jun 2021 14:55:38 GMT

Le 2021-06-05 à 02:39, Thomas de Groot a écrit :
> Op 04/06/2021 om 22:08 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> That is an interesting idea... we should certainly follow up that line
>>> to see where it would get us.
>>
>> We should - but I never really dug into that really great project 
>> deeply enough
>> to understand exactly how it all works.  Maybe it's time.
>>
> I have to dig up my old Geomorph code (2004-2005) in which I used 
> patterns (including crackle) in different functions to build isosurface 
> landscapes. It might inspire...
> 
>>
>>>> I mean, even for now, we could probably just add some gentle black 
>>>> hole warps or
>>>> other warps to the basic granite pattern and introduce a little bit of
>>>> variation.  I'm bad at implementing warps, but maybe the quartz 
>>>> veins could
>>>> benefit from some clever application of them.
>>>>
>>> Maybe. I am not sure what the black hole warp would really add to the
>>> turbulence warp already in place. Granites are not very turbulent by
>>> themselves and rather monotonous in fact.
>>
>> They are, but you have those other patterns which have some size 
>> variation.  It
>> might be nice to have some of that in the pattern as an option.  I'm only
>> throwing it out there so we can play with it and either decide it has 
>> promise -
>> or discard it as "nope - not a good idea".
>>
> I fully agree.
> 
>>> Well, it appears we shall not have time to get bored or idle. ;-)
>>
>> Always so much to do.   Never enough time, energy, or opportunity.   
>> Better that
>> than being idle and boring.
>>
>>
>>> In the meantime, I have started to write that piece of documentation you
>>> asked about. Steadily growing.
>>
>> Thanks  :)
>>
>>
>> Find attached a quick exploratory crackle experiment.  The sum of 2 
>> crackle
>> patterns of different scales, one with turbulence, then the whole 
>> thing with
>> some turbulence.
>>
> Interesting result indeed. The "cells" are not looking "natural" enough 
> to my taste, but with enough tweaking...
> 
> It shows, imo, how we have to be careful with the amount of turbulence.
> 
> 
To make your turbulence smoother, reducing the octave parameter could 
help. It default at 6. So, maybe try with octave 3.

Next, you can also reduce the lambda. Default of 2. Make it closer to 1.

Finally, the omega could also get adjusted down from the default of 0.5.

A proposition :
octave 3
lambda 1.4
omega 0.25

This should make the turbulence much more wavy and smoother.

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1767 days 1 hour and 37 minutes ago]

Sat, 5 Jun 2021 06:39:53 GMT

Op 04/06/2021 om 22:08 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> That is an interesting idea... we should certainly follow up that line
>> to see where it would get us.
> 
> We should - but I never really dug into that really great project deeply enough
> to understand exactly how it all works.  Maybe it's time.
> 
I have to dig up my old Geomorph code (2004-2005) in which I used 
patterns (including crackle) in different functions to build isosurface 
landscapes. It might inspire...

> 
>>> I mean, even for now, we could probably just add some gentle black hole warps or
>>> other warps to the basic granite pattern and introduce a little bit of
>>> variation.  I'm bad at implementing warps, but maybe the quartz veins could
>>> benefit from some clever application of them.
>>>
>> Maybe. I am not sure what the black hole warp would really add to the
>> turbulence warp already in place. Granites are not very turbulent by
>> themselves and rather monotonous in fact.
> 
> They are, but you have those other patterns which have some size variation.  It
> might be nice to have some of that in the pattern as an option.  I'm only
> throwing it out there so we can play with it and either decide it has promise -
> or discard it as "nope - not a good idea".
> 
I fully agree.

>> Well, it appears we shall not have time to get bored or idle. ;-)
> 
> Always so much to do.   Never enough time, energy, or opportunity.   Better that
> than being idle and boring.
> 
> 
>> In the meantime, I have started to write that piece of documentation you
>> asked about. Steadily growing.
> 
> Thanks  :)
> 
> 
> Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
> patterns of different scales, one with turbulence, then the whole thing with
> some turbulence.
> 
Interesting result indeed. The "cells" are not looking "natural" enough 
to my taste, but with enough tweaking...

It shows, imo, how we have to be careful with the amount of turbulence.


-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1767 days 12 hours and 7 minutes ago]

Fri, 4 Jun 2021 20:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> That is an interesting idea... we should certainly follow up that line
> to see where it would get us.

We should - but I never really dug into that really great project deeply enough
to understand exactly how it all works.  Maybe it's time.

> > I mean, even for now, we could probably just add some gentle black hole warps or
> > other warps to the basic granite pattern and introduce a little bit of
> > variation.  I'm bad at implementing warps, but maybe the quartz veins could
> > benefit from some clever application of them.
> >
> Maybe. I am not sure what the black hole warp would really add to the
> turbulence warp already in place. Granites are not very turbulent by
> themselves and rather monotonous in fact.

They are, but you have those other patterns which have some size variation.  It
might be nice to have some of that in the pattern as an option.  I'm only
throwing it out there so we can play with it and either decide it has promise -
or discard it as "nope - not a good idea".

> Well, it appears we shall not have time to get bored or idle. ;-)

Always so much to do.   Never enough time, energy, or opportunity.   Better that
than being idle and boring.

> In the meantime, I have started to write that piece of documentation you
> asked about. Steadily growing.

Thanks  :)

Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
patterns of different scales, one with turbulence, then the whole thing with
some turbulence.

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1767 days 20 hours and 10 minutes ago]

Fri, 4 Jun 2021 12:06:30 GMT

Op 4-6-2021 om 12:20 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> ...but seriously, I would be interested to know how to use voronoi
>> diagrams for this particular project, apart from the crackles pattern.
>> Something where the individual cells (and distribution of them) would be
>> more "controlled" by the user. Beyond the "using voronoi without knowing
>> it", that would completely change the whole granite setup I think.
> 
> Correct, and there has been some interest in exactly that for quite some time.
> 
> I have 2 or 3 implementations of Voronoi algorithms coded in GLSL/Shadertoy that
> I've been meaning to start converting to SDL, in the hopes that I could get
> something reasonably functional.
> 
I did a bit of browsing about voronoi diagrams, in particular MathWorks, 
and it occurred to me (just thinking aloud here) that if we could 
generate a 3d voronoi volume based on a random set of points in an 
array, that volume - intersected by the object we want to texture with 
granite - would give a 2d voronoi granite pattern. At least, that was 
how I interpreted the info given in MathWorks, which somehow seemed to 
click right away with those papers you directed me to.

Perhaps, we do not even need a 3d volume at all, but it seems to me that 
it would be a better, or more "natural", approach to the problem.

> 
> 
> I didn't get to spend ANY POV-time yesterday, but I was thinking about exactly
> what you're talking about, and it occurred to me that one thing we could
> probably do is plug crackle into a function and then operate on the function
> coordinates - like I did with the vortex.  That would give spatial control.
> 
> Then the whole bricks pattern trick would give further control over the
> coloring.
> 
That is an interesting idea... we should certainly follow up that line 
to see where it would get us.

> And, of course Jerome Grimbert has already addressed this in hgpovray38
> https://wiki.povray.org/content/User:Le_Forgeron#voronoi
> 
Ok. I need to look at that.

> I mean, even for now, we could probably just add some gentle black hole warps or
> other warps to the basic granite pattern and introduce a little bit of
> variation.  I'm bad at implementing warps, but maybe the quartz veins could
> benefit from some clever application of them.
> 
Maybe. I am not sure what the black hole warp would really add to the 
turbulence warp already in place. Granites are not very turbulent by 
themselves and rather monotonous in fact.

>> At
>> this moment, beyond the beta and beyond the final version.
> 
> Yes, just looking at the POV-Ray source code for the crackle and other
> voronoi-based pattern shows it to be a little complex, and IIRC, the problem was
> really that it's one of those things that you can do fairly straightforwardly
> with an algorithm when directly shading pixels, but would be difficult or
> impossible to do with straight SDL functions.
> 
> https://thebookofshaders.com/12/
> https://iquilezles.org/www/articles/voronoilines/voronoilines.htm
> https://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
> https://iquilezles.org/www/articles/voronoise/voronoise.htm
> 
Well, it appears we shall not have time to get bored or idle. ;-)

In the meantime, I have started to write that piece of documentation you 
asked about. Steadily growing.

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1767 days 21 hours and 52 minutes ago]

Fri, 4 Jun 2021 10:25:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> ...but seriously, I would be interested to know how to use voronoi
> diagrams for this particular project, apart from the crackles pattern.
> Something where the individual cells (and distribution of them) would be
> more "controlled" by the user. Beyond the "using voronoi without knowing
> it", that would completely change the whole granite setup I think.

Correct, and there has been some interest in exactly that for quite some time.

I have 2 or 3 implementations of Voronoi algorithms coded in GLSL/Shadertoy that
I've been meaning to start converting to SDL, in the hopes that I could get
something reasonably functional.

I didn't get to spend ANY POV-time yesterday, but I was thinking about exactly
what you're talking about, and it occurred to me that one thing we could
probably do is plug crackle into a function and then operate on the function
coordinates - like I did with the vortex.  That would give spatial control.

Then the whole bricks pattern trick would give further control over the
coloring.

And, of course Jerome Grimbert has already addressed this in hgpovray38
https://wiki.povray.org/content/User:Le_Forgeron#voronoi

I mean, even for now, we could probably just add some gentle black hole warps or
other warps to the basic granite pattern and introduce a little bit of
variation.  I'm bad at implementing warps, but maybe the quartz veins could
benefit from some clever application of them.

> At
> this moment, beyond the beta and beyond the final version.

Yes, just looking at the POV-Ray source code for the crackle and other
voronoi-based pattern shows it to be a little complex, and IIRC, the problem was
really that it's one of those things that you can do fairly straightforwardly
with an algorithm when directly shading pixels, but would be difficult or
impossible to do with straight SDL functions.

https://thebookofshaders.com/12/
https://iquilezles.org/www/articles/voronoilines/voronoilines.htm
https://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
https://iquilezles.org/www/articles/voronoise/voronoise.htm

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1768 days 1 hour and 31 minutes ago]

Fri, 4 Jun 2021 06:46:02 GMT

Op 03/06/2021 om 13:27 schreef Thomas de Groot:
> Op 3-6-2021 om 12:16 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> Interesting! The use of voronoi diagrams had crossed my mind as an
>>> alternative. However, I have not the slightest idea how to do that; a
>>> bit beyond my capacities I am afraid. Still, good to know it has been
>>> done. Another fork to the exploration rig. Thanks!
>>
>> Good heavens, lad!  You're already doing it.
>> Crackle IS Voronoi - and you're using crackle {solid} which is 3D 
>> Voronoi.
>>
>> Stop being so modest.  :)
>>
>>
> LOL! I completely forgot about that aspect of crackle!
> 

...but seriously, I would be interested to know how to use voronoi 
diagrams for this particular project, apart from the crackles pattern. 
Something where the individual cells (and distribution of them) would be 
more "controlled" by the user. Beyond the "using voronoi without knowing 
it", that would completely change the whole granite setup I think. At 
this moment, beyond the beta and beyond the final version.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1768 days 20 hours and 49 minutes ago]

Thu, 3 Jun 2021 11:27:34 GMT

Op 3-6-2021 om 12:16 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Interesting! The use of voronoi diagrams had crossed my mind as an
>> alternative. However, I have not the slightest idea how to do that; a
>> bit beyond my capacities I am afraid. Still, good to know it has been
>> done. Another fork to the exploration rig. Thanks!
> 
> Good heavens, lad!  You're already doing it.
> Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.
> 
> Stop being so modest.  :)
> 
>
LOL! I completely forgot about that aspect of crackle!

There is a 17th century French play by Molière, "Le bourgeois 
Gentilhomme" where de main character, wanting to get access to the upper 
echelons of society, starts to "educate" himself with the help of 
"teachers" (more interested in money) and so is delighted to learn that 
he has been speaking "prose" all his life without knowing it.

https://en.wikipedia.org/wiki/Le_Bourgeois_gentilhomme

[Admire my latest portrait on the site above. I think it is particularly 
well done and life-like] :-)

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1768 days 21 hours and 57 minutes ago]

Thu, 3 Jun 2021 10:20:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Interesting! The use of voronoi diagrams had crossed my mind as an
> alternative. However, I have not the slightest idea how to do that; a
> bit beyond my capacities I am afraid. Still, good to know it has been
> done. Another fork to the exploration rig. Thanks!

Good heavens, lad!  You're already doing it.
Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.

Stop being so modest.  :)

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1769 days 1 hour and 11 minutes ago]

Thu, 3 Jun 2021 07:05:46 GMT

Op 03/06/2021 om 08:39 schreef Thomas de Groot:
> Interesting! The use of voronoi diagrams had crossed my mind as an 
> alternative. However, I have not the slightest idea how to do that; a 
> bit beyond my capacities I am afraid. Still, good to know it has been 
> done. Another fork to the exploration rig. Thanks!
> 
Which reminded me of an old program I played with in the past: 
Tesselsphere. On Sourceforge, there are other utilities too using 
voronoi diagrams.

https://sourceforge.net/directory/os:windows/?q=voronoi

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1769 days 1 hour and 37 minutes ago]

Thu, 3 Jun 2021 06:39:15 GMT

Op 03/06/2021 om 01:30 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> hmmm.... fingers...? What do you mean by "fingers"...?
> 
> You are a rather naughty old man.
> Clearly I mean the measure of the quantity of tincture of bufo terrestris
> americanus in a whiskey glass.  :P
> 
Why didn't you say so in the first place? Filled my whiskey glass with 
other stuff I am afraid... :-)

> 
> I came across this in my notifications - it's rather old, and sparse, but it has
> a list of references that might be of more utility, and act as handles for
> searching for newer developments.
> 
>
https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
> view-paper
>
Interesting! The use of voronoi diagrams had crossed my mind as an 
alternative. However, I have not the slightest idea how to do that; a 
bit beyond my capacities I am afraid. Still, good to know it has been 
done. Another fork to the exploration rig. Thanks!

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1769 days 8 hours and 42 minutes ago]

Wed, 2 Jun 2021 23:35:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> hmmm.... fingers...? What do you mean by "fingers"...?

You are a rather naughty old man.
Clearly I mean the measure of the quantity of tincture of bufo terrestris
americanus in a whiskey glass.  :P


I came across this in my notifications - it's rather old, and sparse, but it has
a list of references that might be of more utility, and act as handles for
searching for newer developments.

https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
view-paper

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1769 days 20 hours and 23 minutes ago]

Wed, 2 Jun 2021 11:53:32 GMT

Op 2-6-2021 om 12:23 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> You know how it works: somebody in some scene uses a "smart" trick,
>> which seems to work fine, and you mindlessly copy that into your own
>> scenes, and it does seem to work... somehow, and then you tweak that
>> "smart" trick to cover another need (close, but different) and lo! it
>> just refuses to do what you expected.
> 
> Yes, I have been there on many occasions.  But let's be honest, I've also been
> thwarted from time to time by the simplest of stock SDL commands.  :D
> 
It is also when you are bending too long over the same bunch of code 
that you get blind to the most obvious things.

>> One always
>> needs a critical mind close by to get you back on the right track.
>> Thanks Bill!
>>
>> --
>> Thomas
> 
> Hey - if it somehow "worked", I would have let it slip by for a while too.   I
> only noticed it because POV-Ray was squawking about all of that undeclared
> identifier stuff.  Damned parser.
> 
> Glad you're feeling better.  How many fingers am I holding up?
> 
hmmm.... fingers...? What do you mean by "fingers"...?

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1769 days 21 hours and 52 minutes ago]

Wed, 2 Jun 2021 10:25:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> You know how it works: somebody in some scene uses a "smart" trick,
> which seems to work fine, and you mindlessly copy that into your own
> scenes, and it does seem to work... somehow, and then you tweak that
> "smart" trick to cover another need (close, but different) and lo! it
> just refuses to do what you expected.

Yes, I have been there on many occasions.  But let's be honest, I've also been
thwarted from time to time by the simplest of stock SDL commands.  :D

> One always
> needs a critical mind close by to get you back on the right track.
> Thanks Bill!
>
> --
> Thomas

Hey - if it somehow "worked", I would have let it slip by for a while too.   I
only noticed it because POV-Ray was squawking about all of that undeclared
identifier stuff.  Damned parser.

Glad you're feeling better.  How many fingers am I holding up?

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1770 days 1 hour and 49 minutes ago]

Wed, 2 Jun 2021 06:27:17 GMT

Op 01/06/2021 om 23:40 schreef Bald Eagle:
> "jamesf" <nomail@nomail> wrote:
> 
>> This is a lifting of a "protection" mechanism from the C language (at least
>> that's where I first encountered it).
> 
> .....
> 
> Thanks, James - I have seen that type of thing in the various POV-Ray include
> files, and probably in some source and arduino code.  I thought that's what was
> getting done, but at present it seems that TdG was trying to invoke some kind of
> POV "woo".
> 
>> I'm not aware of any 'magic' that happens in povscript WRT defining a
>> _filename_INC_ variable, but there could be such.
> 
> Yeah - I was stunned that there was some such thing that I had never heard of or
> seen.  On the other hand, it's an interesting concept - maybe a clever macro
> could "search" for all variants of a particular filename...
> 
>> (hope this helps clear up the concept)
> 
> So do I.  The world just keeps getting cloudier, murkier, more opaque, and more
> obscure as time goes on it seems...
> 
> I'm going to sacrifice another lime and offer up a supplication that Thomas gets
> the rest, therapy, - and medication - that he so desperately needs to find
> clarity of mind and inner peace.  We love you, Thomas.   Help is always just a
> forum-post away.   :)
> 
Just got a bootlegged batch of fresh Dried Frog Pills (pale yellow, not 
green) which does seem to do me a lot of good... [kwark!] sorry  ;-)

You know how it works: somebody in some scene uses a "smart" trick, 
which seems to work fine, and you mindlessly copy that into your own 
scenes, and it does seem to work... somehow, and then you tweak that 
"smart" trick to cover another need (close, but different) and lo! it 
just refuses to do what you expected. That is what happened to me. It 
took me an unusual long time to discover that it didn't work because I 
had been so clever as to cover up my tracks in such a way that it always 
"seemed" to work. I was sorely mislead by my tricky mind! One always 
needs a critical mind close by to get you back on the right track. 
Thanks Bill!

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1770 days 10 hours and 32 minutes ago]

Tue, 1 Jun 2021 21:45:00 GMT

"jamesf" <nomail@nomail> wrote:

> This is a lifting of a "protection" mechanism from the C language (at least
> that's where I first encountered it).

.....

Thanks, James - I have seen that type of thing in the various POV-Ray include
files, and probably in some source and arduino code.  I thought that's what was
getting done, but at present it seems that TdG was trying to invoke some kind of
POV "woo".

> I'm not aware of any 'magic' that happens in povscript WRT defining a
> _filename_INC_ variable, but there could be such.

Yeah - I was stunned that there was some such thing that I had never heard of or
seen.  On the other hand, it's an interesting concept - maybe a clever macro
could "search" for all variants of a particular filename...

> (hope this helps clear up the concept)

So do I.  The world just keeps getting cloudier, murkier, more opaque, and more
obscure as time goes on it seems...

I'm going to sacrifice another lime and offer up a supplication that Thomas gets
the rest, therapy, - and medication - that he so desperately needs to find
clarity of mind and inner peace.  We love you, Thomas.   Help is always just a
forum-post away.   :)

[jamesf] Re: Granite_21 macro - beta #1.5 [1770 days 11 hours and 57 minutes ago]

Tue, 1 Jun 2021 20:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
> > This is an ancient trick I learned decades ago ;-). The form
> > _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
> > covers all the possible forms of writing (capitals, dots, etc) of which
> > a file name is composed. And it works perfectly well for me.
>
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
>
> > And then...!!!! [thunderclap]
> > So I forgot to give you the proper Line 70, which should be of course,
> > after Line 69, as given:
> >
> > #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
> > "DakotaRedGranite.inc"  #end
> > #include Granite_file
>
> So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...?  Does it need the _INC_
> part then...?
>

This is a lifting of a "protection" mechanism from the C language (at least
that's where I first encountered it).

The basic form is in your main .c file is:
#include <somefile.h>
#include <someotherfile.h>

Assume that somefile.h also includes other files, and those include others.
Further assume that someotherfile.h also includes other files.  If it ends up
that some set of includes is /duplicated/ then you run into problems.

So, to avoid that, in C somefile.h will contain something like this:
/* file: somefile.h */
/* defines some stuff */
ifndef(_SOMEFILE_H_)
 #define _SOMEFILE_H_
 #declare bob=1
 #declare ted=2
#end

The idea is that each include file defines the variable name associated with
that file, so that if that include file is hit /again/ when resolving includes
the first ifndef line will discover that, the include file contents will be
'skipped', and nothing /more/ will happen.

I'm not aware of any 'magic' that happens in povscript WRT defining a
_filename_INC_ variable, but there could be such.

(hope this helps clear up the concept)

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1770 days 19 hours and 27 minutes ago]

Tue, 1 Jun 2021 12:50:00 GMT

Op 31-5-2021 om 03:41 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> - A comprehensive demo scene file
> 
>> - An investigation/implementation of Real World dimensions (should have
>> started with that, but you know of it goes...)
> 
>> - Additional xxxGranite.inc files to be fed to the macro
> 
> So I was playing with a scene for editing the material's color_map, and in
> addition to the inc file stuff, I noticed that you had removed all of the macro
> parameters.
> 
> I think that works really nicely, so far.
> 
> On the one hand, I like the #undef stuff at the end, but with what I'm doing
> with variations on the same theme, I noticed that that causes me to have to
> redeclare any macro parameters before each call.  No big deal - I can work with
> that.
> 
Yes, but it might not be the best solution...

> But I'm thinking if it doesn't change anything, maybe have it work like
> 
> Granite_21 (optional parameters_persist)
> (default is no)
> and then #if (parameters_persist) would govern macro section 7
> 
Problem is that the 'optional' parameter is still only version 3.8 of 
POV. Not desirable for now I am afraid.

> I have some things laid out with to-scale rulers, and with respect to the SSLT
> I'm wondering what I should do to indicate the - depth - of the translucency
> effect.  I'm not sure that I know of an equation / documentation / diagram for
> calculating / estimating the effect given an rgb 1 light_source and material
> thickness.
> 
After all the commotion about the Granite_file, I still have to plunge 
into this.

> I'm going to try to figure out a way to get as much useful visual info into the
> scene, but minimize the long render time effect of the SSLT.
> 
> Perhaps as a lead-in to the documentation, you could just briefly comment on the
> layout and purpose of the macro parts - the masks and such?
> 
I shall see what I can do on short term....

> Thanks,
> 
> - Bill
> 
> Attached is highlighting 2 color_map entries in green, and then replacing them
> with black.  Just a little macro to make it easier to do from within the scene
> file.
> 
That could be nice indeed... The original color_maps will need a serious 
overhaul I am afraid.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1770 days 19 hours and 42 minutes ago]

Tue, 1 Jun 2021 12:35:00 GMT

Op 1-6-2021 om 08:59 schreef Thomas de Groot:
>> So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
>> "operating on" the #local Granite_file declaration ...?  Does it need 
>> the _INC_
>> part then...?
>>
> Now you ask too much ;-) A learned one like William Pokorny may know...
> 
>> I'm even more confused by the #local Granite_file = 
>> "DakotaRedGranite.inc" when
>> the actual file name isn't capitalized.   Maybe I've run out of dried 
>> frog
>> pills....
>>
Well... it appears I am in serious need of a fresh batch of the "Super 
Strong Extra" frog pills myself. :-/

Don't ask me how or why I completely messed up here, that will be food 
for the psychiatrist; I have an inkling but that is for another time.

Your bewilderment was completely right and I got the full bucket of cold 
water on my head the moment when I /really/ tested with a new granite 
include file. As you can guess ("I told you so") it did not work.

So, after having flogged myself almost senseless, I guess the following 
lines should replace the offensive ones in the macro:

#ifndef (Granite_file)  #local Granite_file = "DakotaRedGranite.inc"  #end
#include Granite_file

Also, to make successive calls of the macro more comprehensive (for 
now), add the following line in section 7:

#undef Granite_file

This seems to work correctly, at least for me. Hope it does for you too 
of course.

>> You certainly have your own tricks up your sleeves that keep me on mine!!
>>
> Glad to be of help :-)
> 
Yeah... my sleeves are full of holes and I often get pretty blind to 
them... ;-[

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1771 days 1 hour and 17 minutes ago]

Tue, 1 Jun 2021 06:59:48 GMT

Op 31/05/2021 om 20:06 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> This is an ancient trick I learned decades ago ;-). The form
>> _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
>> covers all the possible forms of writing (capitals, dots, etc) of which
>> a file name is composed. And it works perfectly well for me.
> 
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
> 
No idea. I guess I learned it from a 'smart one'. I would not be 
surprised if that was Sam Benge. But others have used the trick too I am 
convinced.

>> And then...!!!! [thunderclap]
>> So I forgot to give you the proper Line 70, which should be of course,
>> after Line 69, as given:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
>> "DakotaRedGranite.inc"  #end
>> #include Granite_file
> 
> So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...?  Does it need the _INC_
> part then...?
> 
Now you ask too much ;-) A learned one like William Pokorny may know...

> I'm even more confused by the #local Granite_file = "DakotaRedGranite.inc" when
> the actual file name isn't capitalized.   Maybe I've run out of dried frog
> pills....
> 
This is one of those cases where DFP do not help I am afraid. I do not 
know th mechanism but it works. Same as my laptop: no idea how it 
functions... ;-)

> 
>> The granite include files, as I have defined them, use a 2d array
>> already.
> 
> Well, yes, but what I mean is that instead of:
> 
> array [Map1_entries][4] {
>    {0.00, not_0, not_0, not_0},
> 
> it might be preferable to have:
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0>},
> 
> or
> 
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0, not_0, not_0>},
> 
I am not a fan of this... The first would be a possibility... hmm, I 
have to think about this a bit. For instance, Map1 /never/ should have 
any filter or transmit info.

>> As the macro can render veins, where transmit info is supplied
>> by the corresponding array (the map2 one) it is just a matter of reading
>> the proper info in the right place. The macro takes care of that.
> 
> I am riding the struggle bus here.
> Convert () returns a basic rgb, not an rgbft,
> and map2 has transmit, yes, but not filter.
> My thought was that the macro should accommodate full 5D color vectors
> everywhere, because we have the Norbert Kern / Sean Day / Robert McGregor types
> who will squeeze every last bit of artistic flair out this if allowed to.
> 
They are free to try, but have to play by my rules ;-) For different 
reasons, I have restricted the use of transmit to the veins where 
filters are not allowed and imo, are not recommended.

Veins, btw, is still an issue of course.

>> Thanks for your thoughts! It keeps me on my toes. ;-)
> 
> You certainly have your own tricks up your sleeves that keep me on mine!!
> 
Glad to be of help :-)

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1771 days 14 hours and 7 minutes ago]

Mon, 31 May 2021 18:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> This is an ancient trick I learned decades ago ;-). The form
> _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
> covers all the possible forms of writing (capitals, dots, etc) of which
> a file name is composed. And it works perfectly well for me.

You're killin' me.
I have never seen this used before, or even mentioned.
Is this in the documentation?

> And then...!!!! [thunderclap]
> So I forgot to give you the proper Line 70, which should be of course,
> after Line 69, as given:
>
> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
> "DakotaRedGranite.inc"  #end
> #include Granite_file

So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
"operating on" the #local Granite_file declaration ...?  Does it need the _INC_
part then...?

I'm even more confused by the #local Granite_file = "DakotaRedGranite.inc" when
the actual file name isn't capitalized.   Maybe I've run out of dried frog
pills....

> The granite include files, as I have defined them, use a 2d array
> already.

Well, yes, but what I mean is that instead of:

array [Map1_entries][4] {
  {0.00, not_0, not_0, not_0},

it might be preferable to have:
array [Map1_entries][2] {
  {0.00, <not_0, not_0, not_0>},

or

array [Map1_entries][2] {
  {0.00, <not_0, not_0, not_0, not_0, not_0>},

> As the macro can render veins, where transmit info is supplied
> by the corresponding array (the map2 one) it is just a matter of reading
> the proper info in the right place. The macro takes care of that.

I am riding the struggle bus here.
Convert () returns a basic rgb, not an rgbft,
and map2 has transmit, yes, but not filter.
My thought was that the macro should accommodate full 5D color vectors
everywhere, because we have the Norbert Kern / Sean Day / Robert McGregor types
who will squeeze every last bit of artistic flair out this if allowed to.

> Thanks for your thoughts! It keeps me on my toes. ;-)

You certainly have your own tricks up your sleeves that keep me on mine!!

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1771 days 17 hours and 4 minutes ago]

Mon, 31 May 2021 15:12:46 GMT

Op 31-5-2021 om 11:45 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Interesting you say that and thanks for this info. When I searched
>> them that were not operational any more (the majority, but over a long
>> time period of a century or so). Looking also at the geological maps,
>> depletion is very probable for many of them indeed. The mentioned
>> granite is a very local occurrence I guess, only available around
> 
> The topic arose because I was asking about availability of "Verde Oceano." It
> may not be a true granite but it's amazingly beautiful - lots of iridescence. It
> looks like an underwater scene complete with brightly colored tropical fish.
> Photos are totally insufficient. Adding that to your granite project would be
> quite a task (maybe for the next granite update sometime around 2050), but lots
> of granites do have iridescence - or at least stones that are being sold as
> granite whatever they might actually be...
> 

Aha! a larvikite! also monzonite granitoid, and a beautiful one indeed, 
very often used in the front walls of prestigious shops or offices.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1771 days 17 hours and 11 minutes ago]

Mon, 31 May 2021 15:05:58 GMT

Op 31-5-2021 om 12:26 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> There is indeed an error there. Replace the following line:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end
>>
>> by:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
>> "DakotaRedGranite.inc"  #end
> 
> 
> So, I guess I'm still not understanding your intent.
> 
> Working backwards,
> 
> You have :"DakotaRedGranite.inc", so I guess the file you recently supplied
> needs to be renamed with capitals.
> 
No.

> Before this, You're checking to see if _GRANITE_FILE_INC_ is a declared
> identifier.  Where is this identifier supposed to be properly declared?   In the
> include file?
> 
This is an ancient trick I learned decades ago ;-). The form 
_GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow 
covers all the possible forms of writing (capitals, dots, etc) of which 
a file name is composed. And it works perfectly well for me.

And then...!!!! [thunderclap]
So I forgot to give you the proper Line 70, which should be of course, 
after Line 69, as given:

#ifndef (_GRANITE_FILE_INC_)  #local Granite_file = 
"DakotaRedGranite.inc"  #end
#include Granite_file

Sometimes I get blind to the most obvious things... :-/

For the proper use, you declare the file you want, /before/ calling the 
macro. Example:

#declare Granite_file = "MyElectricGranite.inc";

Which includes the necessary paths too of course, like:

#declare Granite_file = "FolderA/FolderB/MyElectricGranite.inc";


> I just looked through "dakotaredgranite.inc" and it doesn't get declared in
> there.
> Also, this implies that _GRANITE_FILE_INC_ is a requisite line in any color_map
> include file.  Correct?
> 
No. It should be all controlled by the above.

> Also, the arrays in any include file must have the proper names: A_Granite_map1,
> A_Granite_map2, etc.
> 
Yes indeed. Those names are then used by the macro.

> 
> I see no real problem there at the moment, although it will need to be clear how
> to properly implement multiple granite materials in a scene, so a demo ought to
> have that feature and some comments.  Just pointing it out, since some people
> like to have all of their include stuff at the top of a scene, and then do all
> the processing later.
> 
YEs, that might give some clashes. Nothing very serious but one has to 
be aware of /what/ the macro exactly does.

> One last thing that occurred to me as I was trying to get to sleep - I decided
> that I don't like the way I implemented the array for the color_map:
> 1. it uses separate entries for the color vector rather than a single vector.
> 2. That makes it difficult if not impossible to use rgbft colors
> 
> a 2d array with color_map location and color vector would likely be better.  The
> macro probably has to get tested with an rgbft statement as well to make sure an
> vector promotion happens as expected, etc.
> 
The granite include files, as I have defined them, use a 2d array 
already. As the macro can render veins, where transmit info is supplied 
by the corresponding array (the map2 one) it is just a matter of reading 
the proper info in the right place. The macro takes care of that.

Thanks for your thoughts! It keeps me on my toes. ;-)

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1771 days 21 hours and 47 minutes ago]

Mon, 31 May 2021 10:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> There is indeed an error there. Replace the following line:
>
> #ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end
>
> by:
>
> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
> "DakotaRedGranite.inc"  #end

So, I guess I'm still not understanding your intent.

Working backwards,

You have :"DakotaRedGranite.inc", so I guess the file you recently supplied
needs to be renamed with capitals.

Before this, You're checking to see if _GRANITE_FILE_INC_ is a declared
identifier.  Where is this identifier supposed to be properly declared?   In the
include file?

I just looked through "dakotaredgranite.inc" and it doesn't get declared in
there.
Also, this implies that _GRANITE_FILE_INC_ is a requisite line in any color_map
include file.  Correct?

Also, the arrays in any include file must have the proper names: A_Granite_map1,
A_Granite_map2, etc.

I see no real problem there at the moment, although it will need to be clear how
to properly implement multiple granite materials in a scene, so a demo ought to
have that feature and some comments.  Just pointing it out, since some people
like to have all of their include stuff at the top of a scene, and then do all
the processing later.

One last thing that occurred to me as I was trying to get to sleep - I decided
that I don't like the way I implemented the array for the color_map:
1. it uses separate entries for the color vector rather than a single vector.
2. That makes it difficult if not impossible to use rgbft colors

a 2d array with color_map location and color vector would likely be better.  The
macro probably has to get tested with an rgbft statement as well to make sure an
vector promotion happens as expected, etc.

- Bill

[Dave Blandston] Re: Granite_21 macro - beta #1.5 [1771 days 22 hours and 27 minutes ago]

Mon, 31 May 2021 09:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Interesting you say that and thanks for this info. When I searched
> them that were not operational any more (the majority, but over a long
> time period of a century or so). Looking also at the geological maps,
> depletion is very probable for many of them indeed. The mentioned
> granite is a very local occurrence I guess, only available around

The topic arose because I was asking about availability of "Verde Oceano." It
may not be a true granite but it's amazingly beautiful - lots of iridescence. It
looks like an underwater scene complete with brightly colored tropical fish.
Photos are totally insufficient. Adding that to your granite project would be
quite a task (maybe for the next granite update sometime around 2050), but lots
of granites do have iridescence - or at least stones that are being sold as
granite whatever they might actually be...

Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1771 days 23 hours and 43 minutes ago]

Mon, 31 May 2021 08:33:54 GMT

Op 31/05/2021 om 10:11 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Concerning that last point, and with the knowledge that the granite
>> /industry/ names /granite/ everything that is hard, grainy, pretty when
>> polished, I have started to wonder if /all/ the granite codes provided
>> originally by Daniel Mecklenburg (an employee of said industry) /are/
>> really granites. There is little doubt imp, about Canadian Pink and
>> North American Pink; Southern Gray and Medium Gray also seem to be
>> genuine, but I need more info. However, I start to seriously scratch my
>> head with the /black/ granites: Impala and India Black; and what to
>> think of St. Andre Green? I think those are not granites at all but
>> something else, gabbros, gneisses, I don't know what. Again, I need more
>> info. What I want to say by all this, is that those rocks potentially
>> may need a different approach in comparison to the granites proper.
> 
> According to the folks at our local granite supply store, some unique granite
> formations turn out to be fairly small and inconsistent over distance. So some
> variations of granite have been totally depleted and are no longer commercially
> available.
> 
> Kind regards,
> Dave Blandston
> Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
> 
Interesting you say that and thanks for this info. When I searched 
through the Saint-André Green info yesterday, I came across the list of 
quarries in Québec supplying granite and I was struck by the number of 
them that were not operational any more (the majority, but over a long 
time period of a century or so). Looking also at the geological maps, 
depletion is very probable for many of them indeed. The mentioned 
granite is a very local occurrence I guess, only available around 
Saint-André-du-Lac-Saint-Jean.

-- 
Thomas

[Dave Blandston] Re: Granite_21 macro - beta #1.5 [1772 days and 2 minutes ago]

Mon, 31 May 2021 08:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Concerning that last point, and with the knowledge that the granite
> /industry/ names /granite/ everything that is hard, grainy, pretty when
> polished, I have started to wonder if /all/ the granite codes provided
> originally by Daniel Mecklenburg (an employee of said industry) /are/
> really granites. There is little doubt imp, about Canadian Pink and
> North American Pink; Southern Gray and Medium Gray also seem to be
> genuine, but I need more info. However, I start to seriously scratch my
> head with the /black/ granites: Impala and India Black; and what to
> think of St. Andre Green? I think those are not granites at all but
> something else, gabbros, gneisses, I don't know what. Again, I need more
> info. What I want to say by all this, is that those rocks potentially
> may need a different approach in comparison to the granites proper.

According to the folks at our local granite supply store, some unique granite
formations turn out to be fairly small and inconsistent over distance. So some
variations of granite have been totally depleted and are no longer commercially
available.

Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1772 days 1 hour and 23 minutes ago]

Mon, 31 May 2021 06:53:43 GMT

Op 30/05/2021 om 14:51 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> OK. This is a /cleanup/ version of the granite macro, and associated
>> DakotaRedGranite.inc file.
>>
>> The following things need to be addressed (in no particular order):
>>
>> - A comprehensive demo scene file
>> - A comprehensive documentation
>> - An investigation/implementation of Real World dimensions (should have
>> started with that, but you know of it goes...)
>> - Additional xxxGranite.inc files to be fed to the macro
> 
> Excellent.
> 
> I got dragged into the distasteful task of fixing/replacing my old cell phone
> (swapping out the motherboard has got me 99% of the way there) and haven't had a
> chance to delve into this yet.
> 
> Having written all of this, you would be the most knowledgeable about what to
> test / show off in a demo scene.
> 
We shall see how it goes. I have number of test scenes running at the 
moment. Still need some tweaking though.

> Depending on changes, documentation might not be comprehensive until it's all
> real-world tested-broken-fixed in the wild.
> 
I agree.

> My (essentially new) phone with the granite photos is the one that suddenly and
> inexplicably died - I will see if I can still retrieve them.  Maybe the
> dimension should be a parameter...
> 
That would be nice indeed.

In the meantime, I have explored the world of the Saint-André Green 
granite in Canada (it was the one which most intrigued me) and found 
that it is not a granite as such, but a monzonite (granitoid). Does not 
matter much for our purpose; the mineral composition is different (less 
than 5% quartz compared to granites).

> I will look, at fiddling with the inc file - as this is likely to drive the
> creation of all of the previous items.
> 
Indeed. It is what I am going to do too in the coming days.

> 
> 
> Thanks for all of your expertise and industrious coding in this!
> I think it's pretty nice that we have some new patterns and materials that came
> out of this - relatively quickly - and hopefully a lot of the methods extend
> over to other materials.
> 
Thank you indeed. It became a fascinating project I confess. I certainly 
think it might generate spin-offs, either in the rock domain or in 
others maybe.

> I will get 2nd coffee and begin reading...
> 
...and I go food shopping now ;-)

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1772 days 1 hour and 38 minutes ago]

Mon, 31 May 2021 06:39:03 GMT

Op 30/05/2021 om 16:16 schreef Bald Eagle:
> Maybe I'm tired, doing it wrong - or there are errors.
> 
> In line 69 you have a capitalized inc file name, but you provide an
> all-lowercase named file.
> 
> Then in line 70 you include a file - but if Granite_file isn't declared, it
> throws an error - which I thought is what line 69 is for.
> 
> and _GRANITE_FILE_INC_ doesn't even exist until the file actually gets included,
> so aren't you checking the wrong identifier?
> 
> Shouldn't it read something like:
> 
> #ifndef (Granite_file)
>      #declare Granite_file = "dakotaredgranite.inc";
>      #declare FileOK = file_exists (Granite_file);
>      #if (FileOK)
>          #include Granite_file
>      #else error concat ("Material color_map file \"", Granite_file, "\" doesn't
> exist.  Exiting."
>      #end // end if
> #end // end ifndef
> 

There is indeed an error there. Replace the following line:

#ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end

by:

#ifndef (_GRANITE_FILE_INC_)  #local Granite_file = 
"DakotaRedGranite.inc"  #end

-- 
Thomas

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1772 days 6 hours and 32 minutes ago]

Mon, 31 May 2021 01:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> - A comprehensive demo scene file

> - An investigation/implementation of Real World dimensions (should have
> started with that, but you know of it goes...)

> - Additional xxxGranite.inc files to be fed to the macro

So I was playing with a scene for editing the material's color_map, and in
addition to the inc file stuff, I noticed that you had removed all of the macro
parameters.

I think that works really nicely, so far.

On the one hand, I like the #undef stuff at the end, but with what I'm doing
with variations on the same theme, I noticed that that causes me to have to
redeclare any macro parameters before each call.  No big deal - I can work with
that.

But I'm thinking if it doesn't change anything, maybe have it work like

Granite_21 (optional parameters_persist)
(default is no)
and then #if (parameters_persist) would govern macro section 7

I have some things laid out with to-scale rulers, and with respect to the SSLT
I'm wondering what I should do to indicate the - depth - of the translucency
effect.  I'm not sure that I know of an equation / documentation / diagram for
calculating / estimating the effect given an rgb 1 light_source and material
thickness.

I'm going to try to figure out a way to get as much useful visual info into the
scene, but minimize the long render time effect of the SSLT.

Perhaps as a lead-in to the documentation, you could just briefly comment on the
layout and purpose of the macro parts - the masks and such?

Thanks,

- Bill

Attached is highlighting 2 color_map entries in green, and then replacing them
with black.  Just a little macro to make it easier to do from within the scene
file.

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1772 days 17 hours and 57 minutes ago]

Sun, 30 May 2021 14:20:00 GMT

Maybe I'm tired, doing it wrong - or there are errors.

In line 69 you have a capitalized inc file name, but you provide an
all-lowercase named file.

Then in line 70 you include a file - but if Granite_file isn't declared, it
throws an error - which I thought is what line 69 is for.

and _GRANITE_FILE_INC_ doesn't even exist until the file actually gets included,
so aren't you checking the wrong identifier?

Shouldn't it read something like:

#ifndef (Granite_file)
    #declare Granite_file = "dakotaredgranite.inc";
    #declare FileOK = file_exists (Granite_file);
    #if (FileOK)
        #include Granite_file
    #else error concat ("Material color_map file \"", Granite_file, "\" doesn't
exist.  Exiting."
    #end // end if
#end // end ifndef

?

[Bald Eagle] Re: Granite_21 macro - beta #1.5 [1772 days 19 hours and 22 minutes ago]

Sun, 30 May 2021 12:55:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> OK. This is a /cleanup/ version of the granite macro, and associated
> DakotaRedGranite.inc file.
>
> The following things need to be addressed (in no particular order):
>
> - A comprehensive demo scene file
> - A comprehensive documentation
> - An investigation/implementation of Real World dimensions (should have
> started with that, but you know of it goes...)
> - Additional xxxGranite.inc files to be fed to the macro

Excellent.

I got dragged into the distasteful task of fixing/replacing my old cell phone
(swapping out the motherboard has got me 99% of the way there) and haven't had a
chance to delve into this yet.

Having written all of this, you would be the most knowledgeable about what to
test / show off in a demo scene.

Depending on changes, documentation might not be comprehensive until it's all
real-world tested-broken-fixed in the wild.

My (essentially new) phone with the granite photos is the one that suddenly and
inexplicably died - I will see if I can still retrieve them.  Maybe the
dimension should be a parameter...

I will look, at fiddling with the inc file - as this is likely to drive the
creation of all of the previous items.

Thanks for all of your expertise and industrious coding in this!
I think it's pretty nice that we have some new patterns and materials that came
out of this - relatively quickly - and hopefully a lot of the methods extend
over to other materials.

I will get 2nd coffee and begin reading...

[Thomas de Groot] Re: Granite_21 macro - beta #1.5 [1773 days 1 hour and 22 minutes ago]

Sun, 30 May 2021 06:54:36 GMT

OK. This is a /cleanup/ version of the granite macro, and associated 
DakotaRedGranite.inc file.

The following things need to be addressed (in no particular order):

- A comprehensive demo scene file
- A comprehensive documentation
- An investigation/implementation of Real World dimensions (should have 
started with that, but you know of it goes...)
- Additional xxxGranite.inc files to be fed to the macro

Concerning that last point, and with the knowledge that the granite 
/industry/ names /granite/ everything that is hard, grainy, pretty when 
polished, I have started to wonder if /all/ the granite codes provided 
originally by Daniel Mecklenburg (an employee of said industry) /are/ 
really granites. There is little doubt imp, about Canadian Pink and 
North American Pink; Southern Gray and Medium Gray also seem to be 
genuine, but I need more info. However, I start to seriously scratch my 
head with the /black/ granites: Impala and India Black; and what to 
think of St. Andre Green? I think those are not granites at all but 
something else, gabbros, gneisses, I don't know what. Again, I need more 
info. What I want to say by all this, is that those rocks potentially 
may need a different approach in comparison to the granites proper.

This is as far as I have presently got in my quest for the Granite 
Grail, today, Anno Domini 2021, on the 30th day of the month of May.

-- 
Thomas

[Thomas de Groot] Re: Granite_21 macro - beta #1.4 [1774 days 16 hours and 48 minutes ago]

Fri, 28 May 2021 15:28:06 GMT

Op 28-5-2021 om 17:11 schreef Thomas de Groot:
> The granite macro has been overhauled once again. Please find (and play 
> with) the latest beta version (1.4) and the first granite include file 
> (DakotaRedGranite.inc) which is also the default if you do not use the 
> file including parameter.
> 
> Put it through its paces!
> 
I forgot to mention an important info:

To load an external granite file, you need to put the following two 
lines in your scene before calling the macro:

#declare Granite_file = "DakotaRedGranite.inc"
#include Granite_file

"Granite_file" is an imperative name for the macro to read/test. 
Otherwise, you can call any file you want ("MyOwnBackyardGranite.inc") 
provided that you use exactly the same array names as in the default 
("DakotaRedGranite.inc") and adapt the number of entries, where 
necessary, for each array.

-- 
Thomas

[Thomas de Groot] Granite_21 macro - beta #1.4 [1774 days 17 hours and 5 minutes ago]

Fri, 28 May 2021 15:11:39 GMT

The granite macro has been overhauled once again. Please find (and play 
with) the latest beta version (1.4) and the first granite include file 
(DakotaRedGranite.inc) which is also the default if you do not use the 
file including parameter.

Put it through its paces!

-- 
Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1774 days 17 hours and 13 minutes ago]

Fri, 28 May 2021 15:03:55 GMT

Op 24-5-2021 om 19:29 schreef Bald Eagle:
> There should definitely be a parameter passed to the macro for width of the
> vein, and frequency of occurrence.
> 
Have to look into this.

> Now that it's looking good, I'd say it's time to think about how to pass
> alternative color maps into the texture - both to model other granite types, as
> well as use the change to spot something in the current implementation that
> might be hiding, but a different color scheme might bring out.
> 
My choice is this (See also the latest beta: Granite_21_beta_1.4.mcr 
below) is:
- a master macro: Granite_21 ()
- include files containing the necessary arrays for the different 
granites, and to be declared by the user and read by the macro.
- at this moment (also default) there is DakotaRedGranite.inc

> Piggybacking on that idea, there should be some triggerable material attribute
> data output to #debug with numbered map entries, and then we could have a
> mechanism to pass in a color for a single entry on-the-fly.  Then it would be
> easy to plug the macro calls into a loop and render a ton of different samples
> when tweaking a new material.
> 
Possibly the present bata can do this. Not tested.

> The macro should also top up my coffee or G&T while I'm working on a scene,
> depending on the value of a required parameter.  :D
> 
The coffee parameter is not yet available.

> 
>> I am trying to get a grip on how to
>> tweak the translucency parameter.
> 
> The way clipka explained it that the translucency color is geared toward what
> color you want the sslt effect to take on as it percolates through the material.
>   So for skin, where the blood will add a red color and absorb the blue and
> green, you set the color to a red-channel dominant rgb vector.
> 
Absolutely.

> Maybe the best sslt test-bed would be a back-lit wedge of material, much like
> what Ansel Adams would do with the Zone System when calibrating negatives and
> prints.
>
Yes. I used the bunny...

> Clipka also recommended in one thread to overlay the sslt texture layer with
> something else and maybe(?) he specifically said to only set the sslt in the
> lower layer...  I'd have to search and pull it up.
> 
That is definitely what one should do as far as my tests show.

-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1776 days 22 hours and 42 minutes ago]

Wed, 26 May 2021 09:35:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> I have a bunch of RL writings to do presently.


I know.  I'm busy for next 2-3 days as well, but it's all still kicking around
up there.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1777 days and 48 minutes ago]

Wed, 26 May 2021 07:28:27 GMT

Op 24-5-2021 om 19:29 schreef Bald Eagle:
> Now that it's looking good, I'd say it's time to think.... 
Yeah! Still need to answer these comments. I have a bunch of RL writings 
to do presently. However, I have some ideas and shall not forget. Just 
in need of time...

-- 
Thomas

[William F Pokorny] Re: curve.inc [1777 days 21 hours and 39 minutes ago]

Tue, 25 May 2021 10:37:35 GMT

On 5/24/21 10:24 AM, ingo wrote:
> an include file for interpolating curves and spline. 20 different ones for
> now. It is based on work by Mr. Noskowicz. There are more in his document
> but I had trouble with gtting some to go, especialy the morph between two
> curves types.
> 
> Have a poke at it,
> 
> Ingo
> 
Thanks! On my list.

Bill P.

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1777 days 22 hours and 12 minutes ago]

Tue, 25 May 2021 10:05:00 GMT

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

> Maybe the best sslt test-bed would be a back-lit wedge of material, much like
> what Ansel Adams would do with the Zone System when calibrating negatives and
> prints.

This is a thin prism (0 to 0.1) with a single point light behind the left edge.

I'm wondering if eval_pigment could act as a way to guide the result?

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1777 days 22 hours and 17 minutes ago]

Tue, 25 May 2021 10:00:00 GMT

ingo <ing### [at] tagpovrayorg> wrote:

> You are aware of Sci-hub? https://sci-hub.41610.org/
>
> Ingo

Ugh - I was, casually.  Forgot about that.  Did the trick - thanks   :)
I dug up a few other papers, will see if they have anything that helps in the
current situation.

Thanks, Ingo

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1777 days 23 hours and 29 minutes ago]

Tue, 25 May 2021 08:47:21 GMT

Op 25/05/2021 om 08:57 schreef ingo:
> in news:60ac9817$1@news.povray.org Thomas de Groot wrote:
> 
>> https://onlinelibrary.wiley.com/doi/pdf/10.1111/j.1467-8659.2007.00949.x
> 
> You are aware of Sci-hub? https://sci-hub.41610.org/
> 
> Ingo
> 
I hadn't been! Thanks a lot indeed!

-- 
Thomas

[ingo] Re: Dakota Red Granite macro - beta #1.2 [1778 days 1 hour and 19 minutes ago]

Tue, 25 May 2021 06:57:54 GMT

in news:60ac9817$1@news.povray.org Thomas de Groot wrote:

> https://onlinelibrary.wiley.com/doi/pdf/10.1111/j.1467-8659.2007.00949.x

You are aware of Sci-hub? https://sci-hub.41610.org/

Ingo

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1778 days 1 hour and 52 minutes ago]

Tue, 25 May 2021 06:24:23 GMT

Op 25/05/2021 om 02:21 schreef Bald Eagle:
> Modeling and Rendering of Heterogeneous Granular Materials: Granite Application

I got no farther than this:

https://onlinelibrary.wiley.com/doi/pdf/10.1111/j.1467-8659.2007.00949.x

Pricey guys those editors! It is slowly changing with journals gradually 
becoming more "open access". However, the /big/ journal editors (like 
Wiley) are stalling of course...

-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1778 days 7 hours and 52 minutes ago]

Tue, 25 May 2021 00:25:00 GMT

Also, maybe someone can hunt down a copy of this paper:
I couldn't find a copy anywhere (so far)

Modeling and Rendering of Heterogeneous Granular Materials: Granite Application
March 2007Computer Graphics Forum 26(1):66 - 79

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1778 days 9 hours and 17 minutes ago]

Mon, 24 May 2021 23:00:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> I am trying to get a grip on how to
> tweak the translucency parameter. For instance, I experimented with the
> use of a complementary colour instead of a regular colour taken from the
> granite colour_map, with interesting results.

http://news.povray.org/povray.binaries.images/message/%3C4f5748d5%40news.povray.org%3E/#%3C4f5748d5%40news.povray.org%3
E

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1778 days 14 hours and 47 minutes ago]

Mon, 24 May 2021 17:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Something I noticed with sslt in my settings, is that veins seem to
> become really 'thin' or, more probably, 'transparent', and thus tend to
> /disappear/ from the view except with higher magnification.

Yes, I think some of that happened in the early experiments with people applying
sslt to objects.  Some details nearly disappeared.

There should definitely be a parameter passed to the macro for width of the
vein, and frequency of occurrence.

Now that it's looking good, I'd say it's time to think about how to pass
alternative color maps into the texture - both to model other granite types, as
well as use the change to spot something in the current implementation that
might be hiding, but a different color scheme might bring out.

Piggybacking on that idea, there should be some triggerable material attribute
data output to #debug with numbered map entries, and then we could have a
mechanism to pass in a color for a single entry on-the-fly.  Then it would be
easy to plug the macro calls into a loop and render a ton of different samples
when tweaking a new material.

The macro should also top up my coffee or G&T while I'm working on a scene,
depending on the value of a required parameter.  :D

> I am trying to get a grip on how to
> tweak the translucency parameter.

The way clipka explained it that the translucency color is geared toward what
color you want the sslt effect to take on as it percolates through the material.
 So for skin, where the blood will add a red color and absorb the blue and
green, you set the color to a red-channel dominant rgb vector.

Maybe the best sslt test-bed would be a back-lit wedge of material, much like
what Ansel Adams would do with the Zone System when calibrating negatives and
prints.

Clipka also recommended in one thread to overlay the sslt texture layer with
something else and maybe(?) he specifically said to only set the sslt in the
lower layer...  I'd have to search and pull it up.

Have to head out and do some errands, so won't be back until later in case you
can't find it with a quick "sslt" search.

- Bill

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1778 days 16 hours and 43 minutes ago]

Mon, 24 May 2021 15:33:52 GMT

Op 24-5-2021 om 15:01 schreef Thomas de Groot:
> For your consideration, concerning sslt:
> 
> (1) It looks like that when using the layered texture mode, i.e. with 
> veins through the granite, sslt should *only* be switched on in the 
> /lower/ layer and *not* in the top layer. Just comment it out there.
> 
See attached image. Translucency has been a bit exagerated:
  <0.669, 0.229, 0.198>*5;

> (2) Scaling of the granite material is related to the /original/ size of 
> the object. In my system, I scale the bunny 10x /before/ applying the 
> granite material. Consequently, I use the optional M_scale = 0.10; or 
> close to that value in the macro.
> 
In fact this has nothing to do with sslt;-)

-- 
Thomas

[ingo] curve.inc [1778 days 17 hours and 52 minutes ago]

Mon, 24 May 2021 14:24:56 GMT

an include file for interpolating curves and spline. 20 different ones for 
now. It is based on work by Mr. Noskowicz. There are more in his document 
but I had trouble with gtting some to go, especialy the morph between two 
curves types.

Have a poke at it,

Ingo

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1778 days 19 hours and 15 minutes ago]

Mon, 24 May 2021 13:01:55 GMT

For your consideration, concerning sslt:

(1) It looks like that when using the layered texture mode, i.e. with 
veins through the granite, sslt should *only* be switched on in the 
/lower/ layer and *not* in the top layer. Just comment it out there.

(2) Scaling of the granite material is related to the /original/ size of 
the object. In my system, I scale the bunny 10x /before/ applying the 
granite material. Consequently, I use the optional M_scale = 0.10; or 
close to that value in the macro.

-- 
Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1778 days 20 hours and 45 minutes ago]

Mon, 24 May 2021 11:31:27 GMT

Op 24-5-2021 om 12:22 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> In the meantime, I am also working on a working sslt set... Not so easy!
>> For instance, a layered texture (veins!) makes sslt go bad.
> 
> I went looking for sslt scene code, and that rotating pyramid again...
> and got sidetracked.
> 
> Here's some granite with HDR lighting and radiosity.
Looking good and interesting.

> I noticed that I probably didn't scale the texture properly, and so I can't
> really see any of the veins.  In my readings, clipka mentioned that having the
> mm_per_unit setting was there to decouple the texture from POV-units and so be
> independent of scaling effects.  We might want to do similar with a
> default-if-not-supplied, and a debug/warning message saying what it got set to.
> 
Something I noticed with sslt in my settings, is that veins seem to 
become really 'thin' or, more probably, 'transparent', and thus tend to 
/disappear/ from the view except with higher magnification.

There are still a lot of issues with the technique (the layered textures 
I mentioned for instance) which are not (fully) addressed in the 
documentation as-is. Not for nothing that the technique is still 
experimental. However, we may get at something workable if not 
breath-taking ;-) on the way.

The mm_per_unit setting is essential and its default (10) seems at first 
glance to be ok for the granite. I am trying to get a grip on how to 
tweak the translucency parameter. For instance, I experimented with the 
use of a complementary colour instead of a regular colour taken from the 
granite colour_map, with interesting results. Visual examples later on.

> I think that sometimes it is a bit slow to render - depending on how the scene
> is set up.   Maybe have some quick-color definitions set up.  For ridiculously
> high quality, I'm guessing we'd want some switchable reflection built in as well
> for the same not0 reasons.
> 
Yes, and yes, and yes.

-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1778 days 21 hours and 52 minutes ago]

Mon, 24 May 2021 10:25:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Right. I was sure I would get this comment! ;-)
> I was lazy of course and pushed it forwards.

Sometimes it's best to just push it back out into the wild.

> > But maybe to alert the user to the fact that they may have inadvertently left
> > out a parameter or used a misspelling/typo, issue a warning in the #ifndef
> > block.
> >
> Hmm... yes, that might be smart. I need to think about this a bit.

>
> The following, I want to comment on separately. Needs more thoughts.
>
> In the meantime, I am also working on a working sslt set... Not so easy!
> For instance, a layered texture (veins!) makes sslt go bad.

I went looking for sslt scene code, and that rotating pyramid again...
and got sidetracked.

Here's some granite with HDR lighting and radiosity.
I noticed that I probably didn't scale the texture properly, and so I can't
really see any of the veins.  In my readings, clipka mentioned that having the
mm_per_unit setting was there to decouple the texture from POV-units and so be
independent of scaling effects.  We might want to do similar with a
default-if-not-supplied, and a debug/warning message saying what it got set to.

I think that sometimes it is a bit slow to render - depending on how the scene
is set up.   Maybe have some quick-color definitions set up.  For ridiculously
high quality, I'm guessing we'd want some switchable reflection built in as well
for the same not0 reasons.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1779 days 16 hours and 36 minutes ago]

Sun, 23 May 2021 15:41:02 GMT

Op 23-5-2021 om 16:25 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
> The render still looks good.  :)
> Section (5) can be condensed using a similar array method.
>
Right. I was sure I would get this comment! ;-)
I was lazy of course and pushed it forwards.

> In section 8 you have some scene code, but don't define the required parameters
> (or SS) and you have those commented out at the top of the file.
> 
Yes, needs to be expanded/made more explicit.

> IIRC, you can declare all the macro parameters to be optional, and then inside
> the macro do what you're doing with some other parameters:
> 
> #ifndef (SN_Start) #local SN_Start = 0.2; #end
> 
> But maybe to alert the user to the fact that they may have inadvertently left
> out a parameter or used a misspelling/typo, issue a warning in the #ifndef
> block.
> 
Hmm... yes, that might be smart. I need to think about this a bit.

> (I've been trying to figure out a way make a lot of the things that I write work
> "straight out of the box" without having to do much figuring at all.)
> 
Which of course, is the way to go.

> Perhaps even have a line that declares a texture identifier with the default
> parameters, so that all anyone would need to do to use it is include the file
> and then "TdGGranite" is right there for use.
> #debug "Default material {TdGGranite} defined."
> 
Absolutely. I had been thinking about this and then it got submerged by 
development issues.

> Just some ideas.
>
Much appreciated, to be sure.

The following, I want to comment on separately. Needs more thoughts.

In the meantime, I am also working on a working sslt set... Not so easy! 
For instance, a layered texture (veins!) makes sslt go bad.

> 
> I'm interested to hear a "behind-the-scenes" account of what you've discovered
> and learned from assembling this mammoth texture definition.
> Also, are there any specific ways that you envision modifying the texture for
> other purposes?  I'm thinking about all of the other materials that may come
> after this, and possible ways to make the customization of them a little easier.
> 
> So, just imagining - perhaps a small scene with 3 boxes.  on the left, the
> default granite, or whatever material is being "edited".  In the center, is a
> box where any given color map entry can be highlighted, so the user knows what
> part of the material they want to change, and where it visually occurs in the
> render.  On the left is a box with a macro call utilizing the new parameters to
> show the edited/updated material {} definition.
> Perhaps put a nice ruler in decimal subdivided centimeters along the top, and
> fractionally subdivided American Imperial inches along the bottom to give an
> indication of scale.
> 
> Maybe sets of boxes in different light groups to get a better idea about the
> effect of lighting on these complex materials.
> 
> I would also love to experiment with ideas about how to further develop the
> quartz vein feature and help visualize where it lives in 3D space.  So, a
> "bounding box" that has a pigment pattern with rgbt1 and a high transmittance
> white?  Media?
> 

-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.2 [1779 days 17 hours and 47 minutes ago]

Sun, 23 May 2021 14:30:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

The render still looks good.  :)
Section (5) can be condensed using a similar array method.

In section 8 you have some scene code, but don't define the required parameters
(or SS) and you have those commented out at the top of the file.

IIRC, you can declare all the macro parameters to be optional, and then inside
the macro do what you're doing with some other parameters:

#ifndef (SN_Start) #local SN_Start = 0.2; #end

But maybe to alert the user to the fact that they may have inadvertently left
out a parameter or used a misspelling/typo, issue a warning in the #ifndef
block.

(I've been trying to figure out a way make a lot of the things that I write work
"straight out of the box" without having to do much figuring at all.)

Perhaps even have a line that declares a texture identifier with the default
parameters, so that all anyone would need to do to use it is include the file
and then "TdGGranite" is right there for use.
#debug "Default material {TdGGranite} defined."

Just some ideas.



I'm interested to hear a "behind-the-scenes" account of what you've discovered
and learned from assembling this mammoth texture definition.
Also, are there any specific ways that you envision modifying the texture for
other purposes?  I'm thinking about all of the other materials that may come
after this, and possible ways to make the customization of them a little easier.

So, just imagining - perhaps a small scene with 3 boxes.  on the left, the
default granite, or whatever material is being "edited".  In the center, is a
box where any given color map entry can be highlighted, so the user knows what
part of the material they want to change, and where it visually occurs in the
render.  On the left is a box with a macro call utilizing the new parameters to
show the edited/updated material {} definition.
Perhaps put a nice ruler in decimal subdivided centimeters along the top, and
fractionally subdivided American Imperial inches along the bottom to give an
indication of scale.

Maybe sets of boxes in different light groups to get a better idea about the
effect of lighting on these complex materials.

I would also love to experiment with ideas about how to further develop the
quartz vein feature and help visualize where it lives in 3D space.  So, a
"bounding box" that has a pigment pattern with rgbt1 and a high transmittance
white?  Media?



> Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.2 [1781 days 19 hours and 59 minutes ago]

Fri, 21 May 2021 12:17:18 GMT

Grrr... correction of a typo done here.

-- 
Thomas

[Thomas de Groot] Dakota Red Granite macro - beta #1.2 [1781 days 20 hours and 13 minutes ago]

Fri, 21 May 2021 12:03:22 GMT

This version of the granite macro has a couple of minor changes, mainly 
name changes, and a couple of major changes suggested by Bald Eagle: 
colour_map entries are now based on 2D arrays, and the srgb conversion 
macro has been streamlined. Many thanks to the kind hinter :-)

-- 
Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1783 days 2 hours and 9 minutes ago]

Thu, 20 May 2021 06:07:13 GMT

Op 19/05/2021 om 09:44 schreef Dave Blandston:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> So if you have a few hours, they both mention this point in their videos
>> multiple times, and might possibly do a quick few lines of throwaway code that
>> they execute to demonstrate the concept.  Somewhere.
> 
> OK I'm a believer in "Not_0" now (even without spending hours researching).
> 
:-)

> One other consideration (not a suggestion, just a thought) might be to allow a
> margin of error since a value of 1/256 seems to indicate that the intended
> result is a value of 0 barring any of the conditions you mentioned. So if the
> lighting is even the slightest bit too bright then an unintentional "1" could
> result. So perhaps a default value with a little "wiggle room" might be
> appropriate, like 1/265 since it's an arbitrary starting point anyway.
> 
Seems a good idea. Done for next beta.


-- 
Thomas

[Dave Blandston] Re: Dakota Red Granite macro - beta #1.1 [1784 days and 32 minutes ago]

Wed, 19 May 2021 07:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So if you have a few hours, they both mention this point in their videos
> multiple times, and might possibly do a quick few lines of throwaway code that
> they execute to demonstrate the concept.  Somewhere.

OK I'm a believer in "Not_0" now (even without spending hours researching).

One other consideration (not a suggestion, just a thought) might be to allow a
margin of error since a value of 1/256 seems to indicate that the intended
result is a value of 0 barring any of the conditions you mentioned. So if the
lighting is even the slightest bit too bright then an unintentional "1" could
result. So perhaps a default value with a little "wiggle room" might be
appropriate, like 1/265 since it's an arbitrary starting point anyway.

Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.1 [1784 days 14 hours and 17 minutes ago]

Tue, 18 May 2021 18:00:00 GMT

"Dave Blandston" <IsN### [at] protonmailch> wrote:

> If I may offer a humble opinion/observation, using a value of 1/256 for the
> purpose of multiplying the brightness of an object does not make sense (to me,
> anyway) for this reason: Assuming the base scene is lit such that a fully-lit
> part of an object will have the same approximate output RGB value as the
> corresponding RGB value of the input pigment, a value of 1/256 will result in a
> pixel value of 0. In my opinion, that should be considered the true base value.
> What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
> foresee what value is actually going to be desired.
>
> Also, even the best monitors don't display pure black anyway. Maybe future
> technological developments will change that...

http://news.povray.org/web.607425886a35d6561f9dae3025979125%40news.povray.org

So, the idea here is that we have some "pigment" color value that defines the
visible color.

If it were considered in a vacuum, where everything would be static, and you'd
be directly mapping that value onto the monitor, then all would be fine.

The complication comes in when other things begin to happen in the scene, and
you wonder why your scene looks weird / not good / off.

And that's where the not_0 thing comes into play.  We want to define a non-zero
color component for each of the channels.  If I focus the rays of the sun onto a
black object with a big parabolic mirror or magnifying glass, then there needs
to be - from a computational standpoint, some way of calculating what the
resulting object would look like under those conditions.  And that is usually a
result of multiplying the object pigment by the light source.  If I define
reflection, metallic, or shine a red light on something, then a zero r channel
value would give a 0 * whatever result.  Zero.   And that's not going to give
you "the expected" visual result.  The same thing happens with radiosity.  I
might have a "blue" wall, but when white light reflected off of red and green
objects hit the wall, they affect the perceived color of the wall - and so you
need a non-zero value for the r and g color channels.  There needs to be
_something_ there to get multiplied, and I just figured that a value _just_
below the perceptible / representable threshold value would be a good place to
start.

You are correct, that it IS arbitrary, however it is a value that has a basis /
reason as the current starting point.  I just wanted to make sure it was
actually below the threshold and not above it.

Inigo Quilex worked for Pixar, so I'm making the grounded presumption that he
learned a lot of good professional tricks / best practices.

https://www.youtube.com/channel/UCdmAhiG8HQDlz8uyekw4ENw

And Martijn Steinrucken also seems to really know his way around the inner
workings of colors, lighting, and reflections.

https://www.youtube.com/c/TheArtofCodeIsCool/videos

So if you have a few hours, they both mention this point in their videos
multiple times, and might possibly do a quick few lines of throwaway code that
they execute to demonstrate the concept.  Somewhere.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1784 days 20 hours and 25 minutes ago]

Tue, 18 May 2021 11:51:06 GMT

Op 18-5-2021 om 12:52 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I think there are two tracks here to consider: (1) the use of 'pitch
>> black' in pigments and textures, where the use of 1/256 or 1/257 would
>> be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction
>> like a height_field or, I suppose, an isosurface or a parametric object
>> or whatever, where 'true' zero would be a must. this should be clear
>> from the onset in any scene. Height_fields in particular certainly make
>> good use of 'true' zero. Approximations should be reserved for
>> pigments/textures.
> 
> If I may offer a humble opinion/observation, using a value of 1/256 for the
> purpose of multiplying the brightness of an object does not make sense (to me,
> anyway) for this reason: Assuming the base scene is lit such that a fully-lit
> part of an object will have the same approximate output RGB value as the
> corresponding RGB value of the input pigment, a value of 1/256 will result in a
> pixel value of 0. In my opinion, that should be considered the true base value.
> What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
> foresee what value is actually going to be desired.
> 
> Also, even the best monitors don't display pure black anyway. Maybe future
> technological developments will change that...
> 
> Kind regards,
> Dave Blandston
> Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
> 

Well, personally I am no expert on the question, and I prefer to let 
others answer/discuss this point. Who's next? :-)

-- 
Thomas

[Dave Blandston] Re: Dakota Red Granite macro - beta #1.1 [1784 days 21 hours and 22 minutes ago]

Tue, 18 May 2021 10:55:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> I think there are two tracks here to consider: (1) the use of 'pitch
> black' in pigments and textures, where the use of 1/256 or 1/257 would
> be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction
> like a height_field or, I suppose, an isosurface or a parametric object
> or whatever, where 'true' zero would be a must. this should be clear
> from the onset in any scene. Height_fields in particular certainly make
> good use of 'true' zero. Approximations should be reserved for
> pigments/textures.

If I may offer a humble opinion/observation, using a value of 1/256 for the
purpose of multiplying the brightness of an object does not make sense (to me,
anyway) for this reason: Assuming the base scene is lit such that a fully-lit
part of an object will have the same approximate output RGB value as the
corresponding RGB value of the input pigment, a value of 1/256 will result in a
pixel value of 0. In my opinion, that should be considered the true base value.
What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
foresee what value is actually going to be desired.

Also, even the best monitors don't display pure black anyway. Maybe future
technological developments will change that...

Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

[jr] Re: Dakota Red Granite macro - beta #1.1 [1784 days 21 hours and 47 minutes ago]

Tue, 18 May 2021 10:30:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ... I have done very
> little in the way of arrays in the past, so this is a good opportunity
> to get better acquainted.

an array of 'array mixed' will allow to keep "sets" of parameters together.


regards, jr.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1785 days 1 hour and 40 minutes ago]

Tue, 18 May 2021 06:36:07 GMT

Op 17/05/2021 om 12:40 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>> I'm thinking that my suggestion for
>>> #local not_0 = 1/256;
>>> was close, but that would not give a pure black.  Maybe 1/257 to give a pure
>>> black monitor color but still not 0;
>>>
>> I think it is a trivial difference. As Alain said, no real black in
>> nature, and the black pigments here represent micas, which are far from
>> pitch black anyway.
> 
> I suppose it is .. trivial ... but my thought was as a general point, we should
> provide the users with the fullest range of colors as possible, realistic or
> not, so that we don't code another 20 scenes that 20 years from now people with
> throw up their hands and cry "Why did they DO *this*???"
> 
> So I was thinking it would allow the representation of the purest black
> possible, but still not be zero.  What color is a dark hole or a lightless room?
> There may also be scenes later on where people are rendering heightfields, etc,
> and want a pixel rgb that numerically is integer 0.
> 
> Nothing really to do with the present granite, just thinking ahead.
> That's all.
> 

I think there are two tracks here to consider: (1) the use of 'pitch 
black' in pigments and textures, where the use of 1/256 or 1/257 would 
be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction 
like a height_field or, I suppose, an isosurface or a parametric object 
or whatever, where 'true' zero would be a must. this should be clear 
from the onset in any scene. Height_fields in particular certainly make 
good use of 'true' zero. Approximations should be reserved for 
pigments/textures.

-- 
Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1785 days 1 hour and 52 minutes ago]

Tue, 18 May 2021 06:24:15 GMT

Op 17/05/2021 om 19:42 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> You make an error here I believe. The first expression is /not/ the
>> x-value but the *color_map entry*! And so the last one is /not/ a filter
>> value. Below, this gets wrong as a consequence:
> 
> Nope.
> I converted the entire color map into an array of /4-component/ vectors, with
> the color map entry as the first number.  And, as I anticipated, this might be
> confusing.  Maybe this should be rearranged to have the color map entry be the
> filter, or (better?) constructed as a 2D array?

I need to plunge more seriously into arrays, but yes, I believe a 2D 
array would be better in this context. I shall have a look and try to 
work out something by myself (good practice!). First to cool smoking 
brain cells... :-)

> It was just a quick example of how to not write out the whole color map twice,
> and make any changes easier.
> 
>>
>>> #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
>>> color_map {
>>>     #if (version >= 3.8)
>>>       blend_mode 2
>>>     #end
>>>     #local Entries = dimension_size (CM, 1)-1;
>>>     #for (E, 0, Entries)
>>>     [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
>> This line is confusing. How would you write the line above? Like this?
>> (? used for unknown expression):
>>        [CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]
>>
>>>     #end
>>> }
>>>
>>
>> Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb'
>> not be 'srgb'? I am getting ab bit lost here.
> 
> That line above is wrong, but for a different reason.
> It's SUPPOSED to be:
>   [CM[E].x Convert  (CSC, SatBoost, BrightBoost, <CM[E].y, CM[E].z,
> CM[E].filter>)]
> 
> That way the one macro gets used for every CSC, and the rgb / srgb / function
> gets implemented in the macro, not directly in the color map.
> I got distracted and made an oopsie.
> 
> See if anything special needs to be done in the full macro so that the srgb
> option works even though SatBoost, BrightBoost are not explicitly specified - in
> other words, an unused default placeholder value just gets passed into the
> macro.
> 
> Attaching file so it's all (hopefully) clearer.
> 

Ok. Going to wrap that up somehow. Thanks for this. I have done very 
little in the way of arrays in the past, so this is a good opportunity 
to get better acquainted.


-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.1 [1785 days 14 hours and 32 minutes ago]

Mon, 17 May 2021 17:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> You make an error here I believe. The first expression is /not/ the
> x-value but the *color_map entry*! And so the last one is /not/ a filter
> value. Below, this gets wrong as a consequence:

Nope.
I converted the entire color map into an array of /4-component/ vectors, with
the color map entry as the first number.  And, as I anticipated, this might be
confusing.  Maybe this should be rearranged to have the color map entry be the
filter, or (better?) constructed as a 2D array?
It was just a quick example of how to not write out the whole color map twice,
and make any changes easier.

>
> > #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
> > color_map {
> >    #if (version >= 3.8)
> >      blend_mode 2
> >    #end
> >    #local Entries = dimension_size (CM, 1)-1;
> >    #for (E, 0, Entries)
> >    [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
> This line is confusing. How would you write the line above? Like this?
> (? used for unknown expression):
>       [CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]
>
> >    #end
> > }
> >
>
> Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb'
> not be 'srgb'? I am getting ab bit lost here.

That line above is wrong, but for a different reason.
It's SUPPOSED to be:
 [CM[E].x Convert  (CSC, SatBoost, BrightBoost, <CM[E].y, CM[E].z,
CM[E].filter>)]

That way the one macro gets used for every CSC, and the rgb / srgb / function
gets implemented in the macro, not directly in the color map.
I got distracted and made an oopsie.

See if anything special needs to be done in the full macro so that the srgb
option works even though SatBoost, BrightBoost are not explicitly specified - in
other words, an unused default placeholder value just gets passed into the
macro.

Attaching file so it's all (hopefully) clearer.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1785 days 19 hours and 27 minutes ago]

Mon, 17 May 2021 12:49:34 GMT

Op 17-5-2021 om 00:00 schreef Bald Eagle:
> For your consideration:
> 
> #macro Convert (Csc, SatBoost, BrightBoost, Color)
>   #switch (Csc)
>   #case (1)
>    #local MyColour   = srgb Color;
>   #break
>   #case (2)
>    #local sRGB_Gamma = function(C) {select(C-0.0031308, C*12.92, 1.055*pow(C,
> 1/2.4)-0.055)}
> 
>    #local SB         = SatBoost; // Saturation boost
>    #local VB         = BrightBoost; // Brightness ("volume") boost
>    #local RawColour  = srgb <sRGB_Gamma(Color.red), sRGB_Gamma(Color.green),
> sRGB_Gamma(Color.blue)>;
>    #local SatColour  = RawColour-SB;
>    #local MyColour   = SatColour*(1+VB)*RawColour.gray/SatColour.gray;
>   #break
>   #else
>    #local MyColour   = Color;
>   #end
> 
>   MyColour
> 
> #end
> 
Yes. Smart indeed.

> #declare CSC = 1;
> 
>   #local CM = array {
>      <0.00, not_0, not_0, not_0>,
>      <0.25, 0.059, 0.059, 0.059>,
> 
>      <0.25, 0.086, 0.027, 0.059>,
>      <0.35, 0.086, 0.027, 0.059>,
> 
>      <0.35, 0.118, 0.118, 0.078>,
>      <0.45, 0.118, 0.118, 0.078>,
> 
>      <0.45, 0.200, 0.137, 0.110>,
>      <0.50, 0.150, 0.087, 0.060>,
>      <0.57, 0.200, 0.137, 0.110>,
> 
>      <0.57, 0.400, 0.337, 0.310>,
>      <0.60, 0.350, 0.287, 0.260>,
>      <0.63, 0.400, 0.337, 0.310>,
> 
>      <0.63, 0.769, 0.329, 0.298>,
>      <0.70, 0.669, 0.229, 0.198>,
>      <0.75, 0.769, 0.329, 0.298>,
> 
>      <0.75, 0.600, 0.600, 0.600>,
>      <0.85, 0.550, 0.550, 0.550>,
>      <1.00, 0.650, 0.650, 0.650>
>   }
>
You make an error here I believe. The first expression is /not/ the 
x-value but the *color_map entry*! And so the last one is /not/ a filter 
value. Below, this gets wrong as a consequence:

> #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
> color_map {
>    #if (version >= 3.8)
>      blend_mode 2
>    #end
>    #local Entries = dimension_size (CM, 1)-1;
>    #for (E, 0, Entries)
>    [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
This line is confusing. How would you write the line above? Like this? 
(? used for unknown expression):
      [CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]

>    #end
> }
> 

Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb' 
not be 'srgb'? I am getting ab bit lost here.

-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.1 [1785 days 21 hours and 32 minutes ago]

Mon, 17 May 2021 10:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> > I'm thinking that my suggestion for
> > #local not_0 = 1/256;
> > was close, but that would not give a pure black.  Maybe 1/257 to give a pure
> > black monitor color but still not 0;
> >
> I think it is a trivial difference. As Alain said, no real black in
> nature, and the black pigments here represent micas, which are far from
> pitch black anyway.

I suppose it is .. trivial ... but my thought was as a general point, we should
provide the users with the fullest range of colors as possible, realistic or
not, so that we don't code another 20 scenes that 20 years from now people with
throw up their hands and cry "Why did they DO *this*???"

So I was thinking it would allow the representation of the purest black
possible, but still not be zero.  What color is a dark hole or a lightless room?
There may also be scenes later on where people are rendering heightfields, etc,
and want a pixel rgb that numerically is integer 0.

Nothing really to do with the present granite, just thinking ahead.
That's all.

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1786 days 2 hours and 12 minutes ago]

Mon, 17 May 2021 06:04:58 GMT

Op 17/05/2021 om 00:00 schreef Bald Eagle:
> For your consideration:
> 
Thanks. You are the array expert :-) I always feel a bit unconfortable 
with those; I shall give it a go later today.

-- 
Thomas

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1786 days 2 hours and 16 minutes ago]

Mon, 17 May 2021 06:00:07 GMT

Op 16/05/2021 om 16:07 schreef Bald Eagle:
> This is looking great  :)
> 
<grin> You reminded me of the Stanford objects. I shall need to dig them 
up again from the dust. They are good test objects indeed.

> 
> I am thinking that we could consolidate the color_map code by using a macro, so
> you can select which macro to run, rather than which full color map to parse.
> 
> In that line of thinking, we could also perhaps make the color map itself a lot
> smaller using and array and a loop.
> 
Possibly. I saw your suggestion later in this thread and shall put it 
through the mill.

> 
> Looking through the extensive amount of code you've written (wow, impressive  :O
> )
> 
It grows all by itself...

> I'm thinking that my suggestion for
> #local not_0 = 1/256;
> was close, but that would not give a pure black.  Maybe 1/257 to give a pure
> black monitor color but still not 0;
> 
I think it is a trivial difference. As Alain said, no real black in 
nature, and the black pigments here represent micas, which are far from 
pitch black anyway.

> I think it will take some time and more experimentation to see what sorts of
> things we can make - and break  :D
> 
Oh, I am sure it will ;-)


-- 
Thomas

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.1 [1786 days 10 hours and 12 minutes ago]

Sun, 16 May 2021 22:05:00 GMT

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

> I am thinking that we could consolidate the color_map code by using a macro, so
> you can select which macro to run, rather than which full color map to parse.
>
> In that line of thinking, we could also perhaps make the color map itself a lot
> smaller using and array and a loop.

For your consideration:

#macro Convert (Csc, SatBoost, BrightBoost, Color)
 #switch (Csc)
 #case (1)
  #local MyColour   = srgb Color;
 #break
 #case (2)
  #local sRGB_Gamma = function(C) {select(C-0.0031308, C*12.92, 1.055*pow(C,
1/2.4)-0.055)}

  #local SB         = SatBoost; // Saturation boost
  #local VB         = BrightBoost; // Brightness ("volume") boost
  #local RawColour  = srgb <sRGB_Gamma(Color.red), sRGB_Gamma(Color.green),
sRGB_Gamma(Color.blue)>;
  #local SatColour  = RawColour-SB;
  #local MyColour   = SatColour*(1+VB)*RawColour.gray/SatColour.gray;
 #break
 #else
  #local MyColour   = Color;
 #end

 MyColour

#end

#declare CSC = 1;

 #local CM = array {
    <0.00, not_0, not_0, not_0>,
    <0.25, 0.059, 0.059, 0.059>,

    <0.25, 0.086, 0.027, 0.059>,
    <0.35, 0.086, 0.027, 0.059>,

    <0.35, 0.118, 0.118, 0.078>,
    <0.45, 0.118, 0.118, 0.078>,

    <0.45, 0.200, 0.137, 0.110>,
    <0.50, 0.150, 0.087, 0.060>,
    <0.57, 0.200, 0.137, 0.110>,

    <0.57, 0.400, 0.337, 0.310>,
    <0.60, 0.350, 0.287, 0.260>,
    <0.63, 0.400, 0.337, 0.310>,

    <0.63, 0.769, 0.329, 0.298>,
    <0.70, 0.669, 0.229, 0.198>,
    <0.75, 0.769, 0.329, 0.298>,

    <0.75, 0.600, 0.600, 0.600>,
    <0.85, 0.550, 0.550, 0.550>,
    <1.00, 0.650, 0.650, 0.650>
 }

#local C_gr21_DakotaRed_map1 = //the granite colour_map proper
color_map {
  #if (version >= 3.8)
    blend_mode 2
  #end
  #local Entries = dimension_size (CM, 1)-1;
  #for (E, 0, Entries)
  [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
  #end
}

[Alain Martel] Re: Dakota Red Granite macro - beta #1.1 [1786 days 17 hours and 39 minutes ago]

Sun, 16 May 2021 14:37:53 GMT

Le 2021-05-16 à 10:07, Bald Eagle a écrit :

> I'm thinking that my suggestion for
> #local not_0 = 1/256;
> was close, but that would not give a pure black.  Maybe 1/257 to give a pure
> black monitor color but still not 0;
> 
That's not pure black intentionally. In nature, pure black just don't exist.

Instead of using zero, I often use 0.001.

[Bald Eagle] Re: Dakota Red Granite macro - beta #1.1 [1786 days 18 hours and 7 minutes ago]

Sun, 16 May 2021 14:10:00 GMT

This is looking great  :)


I am thinking that we could consolidate the color_map code by using a macro, so
you can select which macro to run, rather than which full color map to parse.

In that line of thinking, we could also perhaps make the color map itself a lot
smaller using and array and a loop.


Looking through the extensive amount of code you've written (wow, impressive  :O
)

I'm thinking that my suggestion for
#local not_0 = 1/256;
was close, but that would not give a pure black.  Maybe 1/257 to give a pure
black monitor color but still not 0;

I think it will take some time and more experimentation to see what sorts of
things we can make - and break  :D

[Thomas de Groot] Re: Dakota Red Granite macro - beta #1.1 [1788 days 1 hour and 53 minutes ago]

Sat, 15 May 2021 06:23:47 GMT

Found already something to correct ;-)

Here is beta #1.1

-- 
Thomas

[Thomas de Groot] Dakota Red Granite macro - beta #1 [1788 days 19 hours and 51 minutes ago]

Fri, 14 May 2021 12:25:15 GMT

Here is the macro.

Please note that there are still a couple experimental features (veins, 
sslt). No html documentation yet, but you can combine most parameters to 
create 'your own' granite. ;-)

Discussion, please, with an illustration if necessary, in p.b.i.

-- 
Thomas

[William F Pokorny] Convex Hull includes of Michael Andrews (Feb 2003) [1788 days 21 hours and 2 minutes ago]

Fri, 14 May 2021 11:15:00 GMT

Re-posting these macros as the news reader lost access and the web links 
for the original three files look to all be pointing to the same thing.

Bill P.

[Mike Horvath] Re: Upgrading POV-Ray's include files #1: granit... [1790 days 4 hours and 51 minutes ago]

Thu, 13 May 2021 03:25:25 GMT

I suppose I should have posted here, but there is one other:

https://github.com/mjhorvath/POVRay-Updated-Screen-Inc


Mike

[Dave Blandston] Re: Upgrading POV-Ray's include files #1: granit... [1795 days and 2 minutes ago]

Sat, 8 May 2021 08:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> See p.b.i. for more info.
>
> --
> Thomas

Thank you!

Kind regards,
Dave Blandston

[Thomas de Groot] Re: Upgrading POV-Ray's include files #1: granit... [1821 days 19 hours and 55 minutes ago]

Sun, 11 Apr 2021 12:21:24 GMT

A second zip with granites images.

-- 
Thomas

[Thomas de Groot] Re: Upgrading POV-Ray's include files #1: granit... [1821 days 19 hours and 57 minutes ago]

Sun, 11 Apr 2021 12:19:16 GMT

A first zip with granites images.

-- 
Thomas

[Thomas de Groot] Upgrading POV-Ray's include files #1: granites.i... [1821 days 20 hours and 2 minutes ago]

Sun, 11 Apr 2021 12:14:30 GMT

See p.b.i. for more info.

-- 
Thomas

[Thomas de Groot] Tatoine ground [1903 days and 25 minutes ago]

Wed, 20 Jan 2021 07:51:28 GMT

This is a code snippet demonstrating the use of pigment_pattern. For 
discussion, see p.b.i. "Tatoine" by Ash Holsenback.

-- 
Thomas

[Bill Pragnell] Meshrelief revisited #include file [1969 days 15 hours and 37 minutes ago]

Sat, 14 Nov 2020 16:40:01 GMT

Here's the current version of my new mesh maker/displacer. There's a wall o'text
describing it at the top of the file, along with a minimal usage example.

Feel free to ask any questions etc

Bill

[Thomas de Groot] Re: faked translucency mapping [2138 days 1 hour and 47 minutes ago]

Sat, 30 May 2020 06:29:12 GMT

Op 29/05/2020 om 23:23 schreef Norbert Kern:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 24/04/2020 om 21:06 schreef Norbert Kern:
>>> Povray doesn't support translucency mapping :-(
>>>
>>
>> OK. So I studied your code which - as always - is brilliant for its
>> simple and smart solution. I wonder how you came to think of this?
>>
>> One question: leaf_tl was generated by you, I suppose. I can see a
>> number of ways to do this, in particular by combining leaf_b and leaf_c
>> (The inversed twig of leaf_a is added of course) in a smart way in GIMP
>> for instance, or by simply tonemapping in GIMP.
>>
>> In any case, there is some work to do next time I need a tree! :-)
>>
>> Thanks for sharing! Keep corona-free!
>>
>> --
>> Thomas
> 
> 
> 
> 
> Hi Thomas,
> here it was the "easy way" to get a fitting tl_map - photoshop...
> 
> Of course I tried other ways to "automate" it, but The real cause of not further
> investigating it further was - it was slow.
> In the end I used a partial render of the big oak at the middle left, because
> render speed was only a fifth.
> 
> The real use of the fake is for more intimate scenes with single usage - at
> least until we get a real implementation of translucency maps and all the other
> types of texture maps swirling around DAZ studio - roughness, normal, ao-maps
> and so on...
> 
> 
> ......
> Personally I don't fear corona anymore, because my family had an obsure severe
> illness back in march/april - and I never was a hypochondriac. I'll invest in
> antibody tests, when they are available at a reasonable price.
> 
> Norbert
> 
> and Keep corona-free!
> 

Thanks for your info. After I posted my message I thought of all kind of 
problems possibly linked to the trick. Indeed, I agree that we /really/ 
need a translucency map full implementation. Still, it is neat.

I am living in an area of the country with relatively few corona cases. 
We are careful, but not really worried though I shall hail the day when 
those plastic screens disappear from the shops.

-- 
Thomas

[Norbert Kern] Re: faked translucency mapping [2138 days 10 hours and 51 minutes ago]

Fri, 29 May 2020 21:25:05 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 24/04/2020 om 21:06 schreef Norbert Kern:
> > Povray doesn't support translucency mapping :-(
> >
>
> OK. So I studied your code which - as always - is brilliant for its
> simple and smart solution. I wonder how you came to think of this?
>
> One question: leaf_tl was generated by you, I suppose. I can see a
> number of ways to do this, in particular by combining leaf_b and leaf_c
> (The inversed twig of leaf_a is added of course) in a smart way in GIMP
> for instance, or by simply tonemapping in GIMP.
>
> In any case, there is some work to do next time I need a tree! :-)
>
> Thanks for sharing! Keep corona-free!
>
> --
> Thomas

Hi Thomas,
here it was the "easy way" to get a fitting tl_map - photoshop...

Of course I tried other ways to "automate" it, but The real cause of not further
investigating it further was - it was slow.
In the end I used a partial render of the big oak at the middle left, because
render speed was only a fifth.

The real use of the fake is for more intimate scenes with single usage - at
least until we get a real implementation of translucency maps and all the other
types of texture maps swirling around DAZ studio - roughness, normal, ao-maps
and so on...

......
Personally I don't fear corona anymore, because my family had an obsure severe
illness back in march/april - and I never was a hypochondriac. I'll invest in
antibody tests, when they are available at a reasonable price.

Norbert

and Keep corona-free!

[Thomas de Groot] Re: faked translucency mapping [2139 days 1 hour and 14 minutes ago]

Fri, 29 May 2020 07:02:17 GMT

Op 24/04/2020 om 21:06 schreef Norbert Kern:
> Povray doesn't support translucency mapping :-(
> 

OK. So I studied your code which - as always - is brilliant for its 
simple and smart solution. I wonder how you came to think of this?

One question: leaf_tl was generated by you, I suppose. I can see a 
number of ways to do this, in particular by combining leaf_b and leaf_c 
(The inversed twig of leaf_a is added of course) in a smart way in GIMP 
for instance, or by simply tonemapping in GIMP.

In any case, there is some work to do next time I need a tree! :-)

Thanks for sharing! Keep corona-free!

-- 
Thomas

[Thomas de Groot] Re: faked translucency mapping [2173 days and 59 minutes ago]

Sat, 25 Apr 2020 07:17:25 GMT

Op 24/04/2020 om 21:06 schreef Norbert Kern:
> Povray doesn't support translucency mapping :-(
> 
> Here is a small workaround...
> See this thread -
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.5ea334191a336268afdd13e10%40news.povray.org%3E/#%3Cweb.5ea
> 334191a336268afdd13e10%40news.povray.org%3E
> ..
> 
> Norbert
> 

Smart. Put it on my (depressingly long) ToDo list. Thanks!!

-- 
Thomas

[Norbert Kern] faked translucency mapping [2173 days 13 hours and 7 minutes ago]

Fri, 24 Apr 2020 19:10:01 GMT

Povray doesn't support translucency mapping :-(

Here is a small workaround...
See this thread -
http://news.povray.org/povray.binaries.images/message/%3Cweb.5ea334191a336268afdd13e10%40news.povray.org%3E/#%3Cweb.5ea
334191a336268afdd13e10%40news.povray.org%3E
..

Norbert

[Norbert Kern] 'Light & Shadows' big version [2175 days 14 hours and 2 minutes ago]

Wed, 22 Apr 2020 18:15:03 GMT

Here is a 8000x4500 pixel version of the 'Light & Shadows' image posted in
povray.binaries.images

Norbert Kern

[Cousin Ricky] Halton sequences [2202 days 7 hours and 46 minutes ago]

Fri, 27 Mar 2020 00:30:09 GMT

The attached include file can be used to generate Halton sequences in 
SDL.  An example scene file is included.  Enjoy!

[Cousin Ricky] Highlight compromise 2.0 [2258 days 8 hours and 49 minutes ago]

Thu, 30 Jan 2020 23:27:19 GMT

Versions 3.7.0 and earlier of POV-Ray don't support Fresnel highlights 
for non-metallic objects.  The attached program is an attempt to find 
reasonable specular highlight compromise values for glossy non-metallic 
objects.

In version 2.0, the formula is updated to cover low IORs, and low IOR 
test cases are added to the scene accordingly.  The formula breaks down 
at IORs above 3.0 or so, but there are not many non-metallic materials 
with such high IORs.

If you are using POV-Ray 3.8 or later, you should use finish-level 
Fresnel instead of consulting this program.

[Colin Fleming] Re: Camera [2278 days 12 hours and 47 minutes ago]

Fri, 10 Jan 2020 19:30:00 GMT

Wijnand <w.n### [at] alf4alldemonnl> wrote:
> Who can help me where to find the resources of this camera? Thanks and
> regards...

Try this:

http://news.povray.org/povray.binaries.scene-files/thread/%3C4d07b803%40news.povray.org%3E/?ttop=415701&toff=150

[Wijnand] Camera [2280 days 18 hours and 18 minutes ago]

Wed, 8 Jan 2020 13:58:34 GMT

Who can help me where to find the resources of this camera? Thanks and 
regards...

[Paolo Gibellini] Projector test for tmelram [2301 days 20 hours and 55 minutes ago]

Wed, 18 Dec 2019 11:21:15 GMT

See p.general.
Paolo

[Melody] Re: Welcome to Hawaii DEM [2306 days 5 hours and 31 minutes ago]

Sat, 14 Dec 2019 02:45:10 GMT

"Melody" <nomail@nomail> wrote:
> if your world is actually turning on time to the stars and u want azimuth,
> sidereal, julian etc ... Time Date is in MegaPOV or #version 3.63 in utilities.
>
> if you want to make the tga files, DEMPOV, in utilities.
> if you want to convert and sort more DEMs EASILY, get mirc, load the script.
>
> complex but easy. I made it easy.
>
> Hawaii-c.dem too large to include, get it here.
> http://www.webgis.com/MAPS/hi/dem_1_deg/hawaii-c.zip
>
> post command or Final_Frame failing? no problem ... there's another way.
>
http://news.povray.org/povray.binaries.images/attachment/%3Cweb.5df08bb0bc7d71fb9da690110%40news.povray.org%3E/hawaii
-c
> .vi.gif


update, latest DEMPOV and scripts

https://pasteboard.co/IL9bqBS.gif
10 meg, wait for it ... heh

should be everything to make that animation, except hawaii-c.dem ... just
comment out the version 3.63 Azimuth stuff, end of text.pov, if you cant run it,
tsk tsk ... its the year 2020, and we dont have a complete povRay?

[Melody] Welcome to Hawaii DEM [2308 days 9 hours and 42 minutes ago]

Wed, 11 Dec 2019 22:35:02 GMT

if your world is actually turning on time to the stars and u want azimuth,
sidereal, julian etc ... Time Date is in MegaPOV or #version 3.63 in utilities.

if you want to make the tga files, DEMPOV, in utilities.
if you want to convert and sort more DEMs EASILY, get mirc, load the script.

complex but easy. I made it easy.

Hawaii-c.dem too large to include, get it here.
http://www.webgis.com/MAPS/hi/dem_1_deg/hawaii-c.zip

post command or Final_Frame failing? no problem ... there's another way.
http://news.povray.org/povray.binaries.images/attachment/%3Cweb.5df08bb0bc7d71fb9da690110%40news.povray.org%3E/hawaii-c
.vi.gif

[Melody] Bezier Point Spread [2338 days 9 hours and 2 minutes ago]

Mon, 11 Nov 2019 23:15:01 GMT

requested ...

[Thomas de Groot] Object_pattern fun [2359 days 20 hours and 57 minutes ago]

Mon, 21 Oct 2019 11:20:03 GMT

See same subject in p.b.images.

Enjoy!

-- 
Thomas

[Cousin Ricky] Roughness override and specular albedo: is this ... [2367 days 4 hours and 49 minutes ago]

Mon, 14 Oct 2019 03:27:18 GMT

See post in p.binaries.images.

[Norbert Kern] verres1 file plus photons [2385 days 14 hours and 47 minutes ago]

Wed, 25 Sep 2019 17:30:03 GMT

see thread at povray.binaries.images with the same name.

Norbert

[Paolo Gibellini] 25 years of povray.org [2415 days 18 hours and 43 minutes ago]

Mon, 26 Aug 2019 13:33:14 GMT

See the image in p.b.i.

Paolo

[Alain] Re: Radiosity-Pretrace minor update [2463 days 17 hours and 1 minute ago]

Tue, 9 Jul 2019 15:15:14 GMT

Le 19-07-09 Ã  02:41, Mike Horvath a Ã©critÂ :
> On 7/8/2019 5:29 PM, Cousin Ricky wrote:
>> This file computes radiosity pretrace_start and pretrace_end, and 
>> facilitates clipka's Radiosity Voodoo recommendations for these 
>> parameters.Â  Version 1.1 does supplemental error checking, and 
>> suppresses the "#include..." debug message by default.
> 
> Does this speed up rendering?
> 
> 
> Michael

No. It streamline the setting of pretrace_start and pretrace_end.


Alain

[Mike Horvath] Re: Radiosity-Pretrace minor update [2464 days 1 hour and 35 minutes ago]

Tue, 9 Jul 2019 06:41:40 GMT

On 7/8/2019 5:29 PM, Cousin Ricky wrote:
> This file computes radiosity pretrace_start and pretrace_end, and 
> facilitates clipka's Radiosity Voodoo recommendations for these 
> parameters.Â  Version 1.1 does supplemental error checking, and 
> suppresses the "#include..." debug message by default.

Does this speed up rendering?


Michael

[Thomas de Groot] Re: Radiosity-Pretrace minor update [2464 days 1 hour and 41 minutes ago]

Tue, 9 Jul 2019 06:35:55 GMT

On 8-7-2019 23:29, Cousin Ricky wrote:
> This file computes radiosity pretrace_start and pretrace_end, and 
> facilitates clipka's Radiosity Voodoo recommendations for these 
> parameters.Â  Version 1.1 does supplemental error checking, and 
> suppresses the "#include..." debug message by default.


Thanks! A very useful include indeed. I have used it since 2014.

-- 
Thomas

[Cousin Ricky] Radiosity-Pretrace minor update [2464 days 10 hours and 47 minutes ago]

Mon, 8 Jul 2019 21:29:14 GMT

This file computes radiosity pretrace_start and pretrace_end, and 
facilitates clipka's Radiosity Voodoo recommendations for these 
parameters.  Version 1.1 does supplemental error checking, and 
suppresses the "#include..." debug message by default.

[Thomas de Groot] Realistic Wood Textures [2467 days 1 hour and 44 minutes ago]

Sat, 6 Jul 2019 06:32:13 GMT

Here are two ancient macros as discussed in p.newusers, under same 
title. Enjoy!


-- 
Thomas

[Alain] Re: Imitated Bricks [2480 days 16 hours and 6 minutes ago]

Sat, 22 Jun 2019 16:10:45 GMT

Le 19-06-21 Ã  23:59, Mike Horvath a Ã©critÂ :
> On 6/5/2015 5:51 PM, clipka wrote:
>> Am 05.06.2015 um 23:39 schrieb clipka:
>>> Am 04.06.2015 um 23:17 schrieb Reuben Pearse:
>>>
>>>> I would like try some more UberPov renders using the LDraw models that
>>>> I've
>>>> already converted to POV-Ray - could you share the full code for your
>>>> example picture.
>>
>> Here are the files that make up the scene. I might have made some 
>> minor changes by now.
> 
> Old thread, I know, but I just noticed that PlasticTranslucency is set 
> to zero. Does that mean SSLT is disabled in your scene? Further, do you 
> think SSLT is appropriate for ABS and polycarbonate plastics? Thanks for 
> the help.
> 
> 
> Michael

Setting PlasticTranslucency to zero effectively disable SSLT. It's set 
that way to render faster, often wanted during the construction of the 
scene.

Yes, SSLT is appropriate for ANY plastic unless that plastic have some 
metallic coating.

[Mike Horvath] Re: Imitated Bricks [2481 days 4 hours and 18 minutes ago]

Sat, 22 Jun 2019 03:58:53 GMT

On 6/5/2015 5:51 PM, clipka wrote:
> Am 05.06.2015 um 23:39 schrieb clipka:
>> Am 04.06.2015 um 23:17 schrieb Reuben Pearse:
>>
>>> I would like try some more UberPov renders using the LDraw models that
>>> I've
>>> already converted to POV-Ray - could you share the full code for your
>>> example picture.
> 
> Here are the files that make up the scene. I might have made some minor 
> changes by now.

Old thread, I know, but I just noticed that PlasticTranslucency is set 
to zero. Does that mean SSLT is disabled in your scene? Further, do you 
think SSLT is appropriate for ABS and polycarbonate plastics? Thanks for 
the help.

Michael

[Dave Blandston] Re: Three Icons (Account, Cart, and Search) [2504 days 2 hours and 16 minutes ago]

Thu, 30 May 2019 06:00:06 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> LOL, you read documentation? I just take things apart until they break.
> Then I know I've done something wrong.

That's pretty much how I learned most things in life too - thought I'd try
something different this time... may go back to the tried-and-true strategy if
it gets too boring...

Regards,
Dave Blandston

[Mike Horvath] Re: Three Icons (Account, Cart, and Search) [2504 days 2 hours and 50 minutes ago]

Thu, 30 May 2019 05:26:21 GMT

On 5/29/2019 2:18 PM, Dave Blandston wrote:
> so
> it's slow going at first since there's so much documentation to read and absorb.

LOL, you read documentation? I just take things apart until they break. 
Then I know I've done something wrong.


Michael

[Dave Blandston] Re: Three Icons (Account, Cart, and Search) [2504 days 13 hours and 56 minutes ago]

Wed, 29 May 2019 18:20:06 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> He lives!  And is still povving away  :)
>
> Good to see you've still got the website project going - I actually tried to
> visit it a few weeks back and it wasn't there.
>
> I was trying to gather more information about that and figured I'd reach out to
> you, since maybe only 3% of the people in my neck of the woods might have the
> faintest clue what any of that was about.  Didn't I email you a while back?
> Shoot me a reply here or there.
>
> All the best.

Hi Bald Eagle! It's amazing and it makes my day that you're one of the roughly
3% of folks who would even remember that project! I got a little wake-up call in
March when I had to renew the domain name because it was about to expire after
the first year and I hadn't even begun to work on the website. I've finally
gotten to it though. There's quite a bit to learn if one wants to customize a
website beyond the basic WordPress theme options (and what Pov-er wouldn't?) so
it's slow going at first since there's so much documentation to read and absorb.
But I would be happy to chat with you about the project or anything else. You
always have great ideas!

The e-mail address for my Pov-Ray Newsgroups account is just the
default/inaccurate one so no e-mails would reach me. I'll send you an e-mail
from my daily-use account.

Have an awesome day!

Regards,
Dave Blandston

[Bald Eagle] Re: Three Icons (Account, Cart, and Search) [2504 days 21 hours and 17 minutes ago]

Wed, 29 May 2019 11:00:00 GMT

> Regards,
> Dave Blandston

He lives!  And is still povving away  :)

Good to see you've still got the website project going - I actually tried to
visit it a few weeks back and it wasn't there.

I was trying to gather more information about that and figured I'd reach out to
you, since maybe only 3% of the people in my neck of the woods might have the
faintest clue what any of that was about.  Didn't I email you a while back?
Shoot me a reply here or there.

All the best.

[Dave Blandston] Three Icons (Account, Cart, and Search) [2505 days 2 hours and 2 minutes ago]

Wed, 29 May 2019 06:15:00 GMT

Greetings,

Here is the source code for three icons, a sample of which is displayed in the
binary images forum.

Regards,
Dave Blandston

[zenjim] Re: CrownGlass Macros [2505 days 7 hours and 32 minutes ago]

Wed, 29 May 2019 00:45:00 GMT

MichaelJF <mi-### [at] t-onlinede> wrote:
> Hi,
> here are some (older) macros to construct crown glass windows. Textures
> are simple and taken from glass.inc, wood.inc. The meshes were
> constructed with Wings 3D.
>
> I hope it of use to someone.
>
> Best regards
> Michael

I tried rendering this but I get the error "Parse Error: Cannot open include
file iw_textures.inc."

I'm using the Mac version of POVRay 3.8.0.

Where can I find the missing include file?

[Norbert Kern] colors from images [2521 days 23 hours and 27 minutes ago]

Sun, 12 May 2019 08:50:03 GMT

the source of the thread in p.b.i with the same name.

Norbert Kern

[MichaelJF] Re: CrownGlass Macros [2578 days 11 hours and 33 minutes ago]

Sat, 16 Mar 2019 20:43:10 GMT

Am 14.03.2019 um 02:54 schrieb Cousin Ricky:
> On 2019-03-12 6:43 PM (-4), MichaelJF wrote:
>> Hi,
>> here are some (older) macros to construct crown glass windows. 
>> Textures are simple and taken from glass.inc, wood.inc. The meshes 
>> were constructed with Wings 3D.
>>
>> I hope it of use to someone.
>>
>> Best regards
>> Michael
> 
> There are no author credits anywhere in the files.Â  Are you trying to 
> make it difficult not to accidentally steal your stuff?
Hm, I think I did not understand your post. Why should I credit myself? 
Or must I credit all the developers of POV or Wings 3D, because I'm 
using their programs? Or did you miss a notice that the stuff can by 
used by a CC-0 licence? This are two very simple meshes created with 
Wings 3D and straightforward mathematical arrangements. Every 
mathematical layman could do this. So where is your problem?

Best regards
Michael

[Cousin Ricky] Re: CrownGlass Macros [2581 days 6 hours and 22 minutes ago]

Thu, 14 Mar 2019 01:54:45 GMT

On 2019-03-12 6:43 PM (-4), MichaelJF wrote:
> Hi,
> here are some (older) macros to construct crown glass windows. Textures 
> are simple and taken from glass.inc, wood.inc. The meshes were 
> constructed with Wings 3D.
> 
> I hope it of use to someone.
> 
> Best regards
> Michael

There are no author credits anywhere in the files.  Are you trying to 
make it difficult not to accidentally steal your stuff?

[Thomas de Groot] Re: CrownGlass Macros [2582 days and 49 minutes ago]

Wed, 13 Mar 2019 07:28:02 GMT

On 12-3-2019 23:43, MichaelJF wrote:
> Hi,
> here are some (older) macros to construct crown glass windows. Textures 
> are simple and taken from glass.inc, wood.inc. The meshes were 
> constructed with Wings 3D.
> 
> I hope it of use to someone.
> 

Thanks indeed, Michael!

-- 
Thomas

[MichaelJF] CrownGlass Macros [2582 days 9 hours and 33 minutes ago]

Tue, 12 Mar 2019 22:43:43 GMT

Hi,
here are some (older) macros to construct crown glass windows. Textures 
are simple and taken from glass.inc, wood.inc. The meshes were 
constructed with Wings 3D.

I hope it of use to someone.

Best regards
Michael

[MichaelJF] Re: @MichaelJF: sample of Rock texture from "Cro... [2598 days 13 hours and 19 minutes ago]

Sun, 24 Feb 2019 18:57:20 GMT

Am 23.02.2019 um 08:56 schrieb Thomas de Groot:
> On 22-2-2019 19:52, MichaelJF wrote:
>> Am 29.01.2019 um 13:33 schrieb Thomas de Groot:
>>> Finally. I had to strongly clean up my code as successive additions, 
>>> changes, tweakings, had made it - at least working for the Crossing 
>>> Border scene - but not for any other one.
>>>
>>> Here is a test landscape scene, in addition to the bump_map I used 
>>> which may not be the best for the purpose. A better one should be 
>>> generated one day. I think about that. However, it works fine as-is.
>>>
>> Hi Thomas,
>> many, many thanks for your work. I was distracted a while from the 
>> POV-newsgroups by occupational issues unfortunatelly, but not inactive 
>> completelly. I soon found a spot in your scene suiting my needs to 
>> have a better scene to present my idea to model steam fog. Your 
>> texture is great seen at a certain distance, as my steam fog approach 
>> is, but at a close distance both approaches have their limits. May I 
>> ask you what kind of rock you tried to model specifically? A sort of 
>> sedimentary rock I would presume. But you are the geologist and can 
>> give hints to your model. As a statistician I can do guesswork only.
>>
> 
> Yes, the limitations of my rock approach derive almost entirely from the 
> use of a bump_map.A much better approach would be using an isosurface, 
> as the layered rocks are better modelled by functions. I think I have 
> done things like that in my long dormant (dead?) Geomorph macros, more 
> than ten years ago.

Hi Thomas,
interesting hint, I will search my archives. IIRC you have posted it to 
the scene-files ages ago.

> The rocks are supposed to be sedimentary deposits, very typical in 
> particular for the Jurassic and Cretaceous period of the Alpine regions. 
> When I was a student, we called them "pyjama formations", which tells my 
> age as I do not see any stripped pyjamas any more in modern stores, and 
> with the exception of quaint humoristic movies from a certain period...  
> :-)
> 

Very likely you are some years senior to me but I remember this kind of 
fashion as well.

Best regards
Michael

[Jörg "Yadgar" Bleimann] Re: @MichaelJF: sample of Rock texture from "Cro... [2599 days 23 hours and 30 minutes ago]

Sat, 23 Feb 2019 08:46:37 GMT

Hi(gh)!

On 23.02.19 08:56, Thomas de Groot wrote:

> The rocks are supposed to be sedimentary deposits, very typical in 
> particular for the Jurassic and Cretaceous period of the Alpine regions. 
> When I was a student, we called them "pyjama formations", which tells my 
> age as I do not see any stripped pyjamas any more in modern stores, and 
> with the exception of quaint humoristic movies from a certain period...  

They are still sold (possibly a hipster thing), while not my style either...

See you in Khyberspace!

Yadgar

Now playing: Te Recuerdo Amanda (Joan Baez)

[Thomas de Groot] Re: @MichaelJF: sample of Rock texture from "Cro... [2600 days and 20 minutes ago]

Sat, 23 Feb 2019 07:56:14 GMT

On 22-2-2019 19:52, MichaelJF wrote:
> Am 29.01.2019 um 13:33 schrieb Thomas de Groot:
>> Finally. I had to strongly clean up my code as successive additions, 
>> changes, tweakings, had made it - at least working for the Crossing 
>> Border scene - but not for any other one.
>>
>> Here is a test landscape scene, in addition to the bump_map I used 
>> which may not be the best for the purpose. A better one should be 
>> generated one day. I think about that. However, it works fine as-is.
>>
> Hi Thomas,
> many, many thanks for your work. I was distracted a while from the 
> POV-newsgroups by occupational issues unfortunatelly, but not inactive 
> completelly. I soon found a spot in your scene suiting my needs to have 
> a better scene to present my idea to model steam fog. Your texture is 
> great seen at a certain distance, as my steam fog approach is, but at a 
> close distance both approaches have their limits. May I ask you what 
> kind of rock you tried to model specifically? A sort of sedimentary rock 
> I would presume. But you are the geologist and can give hints to your 
> model. As a statistician I can do guesswork only.
> 

Yes, the limitations of my rock approach derive almost entirely from the 
use of a bump_map.A much better approach would be using an isosurface, 
as the layered rocks are better modelled by functions. I think I have 
done things like that in my long dormant (dead?) Geomorph macros, more 
than ten years ago.

The rocks are supposed to be sedimentary deposits, very typical in 
particular for the Jurassic and Cretaceous period of the Alpine regions. 
When I was a student, we called them "pyjama formations", which tells my 
age as I do not see any stripped pyjamas any more in modern stores, and 
with the exception of quaint humoristic movies from a certain period...  :-)

-- 
Thomas

[MichaelJF] Re: @MichaelJF: sample of Rock texture from "Cro... [2600 days 13 hours and 24 minutes ago]

Fri, 22 Feb 2019 18:52:36 GMT

Am 29.01.2019 um 13:33 schrieb Thomas de Groot:
> Finally. I had to strongly clean up my code as successive additions, 
> changes, tweakings, had made it - at least working for the Crossing 
> Border scene - but not for any other one.
> 
> Here is a test landscape scene, in addition to the bump_map I used which 
> may not be the best for the purpose. A better one should be generated 
> one day. I think about that. However, it works fine as-is.
> 
Hi Thomas,
many, many thanks for your work. I was distracted a while from the 
POV-newsgroups by occupational issues unfortunatelly, but not inactive 
completelly. I soon found a spot in your scene suiting my needs to have 
a better scene to present my idea to model steam fog. Your texture is 
great seen at a certain distance, as my steam fog approach is, but at a 
close distance both approaches have their limits. May I ask you what 
kind of rock you tried to model specifically? A sort of sedimentary rock 
I would presume. But you are the geologist and can give hints to your 
model. As a statistician I can do guesswork only.

Best regards
Michael

[Thomas de Groot] Strange results from min_extent and max_extent [2605 days 19 hours and 35 minutes ago]

Sun, 17 Feb 2019 12:41:40 GMT

See p.beta-test and p.b.images with same subject line

This file illustrates my confusion.

-- 
Thomas

[Norbert Kern] neighbors source [2606 days 21 hours and 22 minutes ago]

Sat, 16 Feb 2019 10:55:00 GMT

see this thread -
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5c66e93c4550b1a61fbfafc10%40news.povray.org%3E/.

Norbert Kern

[Thomas de Groot] @MichaelJF: sample of Rock texture from "Crossin... [2624 days 19 hours and 43 minutes ago]

Tue, 29 Jan 2019 12:33:19 GMT

Finally. I had to strongly clean up my code as successive additions, 
changes, tweakings, had made it - at least working for the Crossing 
Border scene - but not for any other one.

Here is a test landscape scene, in addition to the bump_map I used which 
may not be the best for the purpose. A better one should be generated 
one day. I think about that. However, it works fine as-is.

-- 
Thomas

[jr] Re: gradients.inc [zip] [2638 days 12 hours and 57 minutes ago]

Tue, 15 Jan 2019 19:20:00 GMT

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> Did a few updates on gradients.inc and added a simple function studio for
> function pattern development.

the "studio" looks useful, thanks, hope to find time this week to play a little.


regards, jr.

[ingo] gradients.inc [zip] [2639 days 14 hours and 13 minutes ago]

Mon, 14 Jan 2019 18:03:59 GMT

Posted before, in the wrong group and a wrong title. 
Ref : <XnsA9D2EF41831AEseed7@news.povray.org>
http://news.povray.org/povray.tools.general/thread/%
3CXnsA9D2EF41831AEseed7%40news.povray.org%3E/

30+ functions for animations, building isosurfaces and textures.

Did a few updates on gradients.inc and added a simple function studio for 
function pattern development.

ingo

[ingo] FABRIK IK [2674 days 16 hours and 47 minutes ago]

Mon, 10 Dec 2018 15:29:26 GMT

ref:  <XnsA9AB7C841FAFAseed7@news.povray.org>
ref: http://news.povray.org/povray.general/thread/%
3CXnsA9AB7C841FAFAseed7%40news.povray.org%3E/

An IK solver in POV-Ray SDL, still very Alpha. Rather undocumented.

ToDo's 
movement constraints
moving Leaves
closed loops
documentation
better API

ingo

[Dave Blandston] Re: Simple Slideshow [2687 days 10 hours and 12 minutes ago]

Tue, 27 Nov 2018 22:05:01 GMT

Well, the fading could have been done in a better way. I doubt anyone will ever
use this but just in case here's a better version:

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

//-f

#version 3.7;

global_settings {assumed_gamma 2.2}

#include "colors.inc"

#local CameraZ = 1;

camera {
   location <0, 0, -CameraZ>
   right (16/9) * x //Use 16:9 aspect ratio
   direction <0, 0, 1>
   look_at <0, 0, 0>
} //camera

background {DarkOliveGreen}

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* *
                                    * */
/* *
                                    * */
/* * SLIDESHOW SETTINGS
                                    * */
/* *
                                    * */
/* *
                                    * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */

#local NSlides = 3;
//Number of slides (should all be the same dimensions, named "Slide_00.png"
"Slide_01.png" etc.

#local NSeconds = 5;
//Total time in seconds the slideshow will last. Render NSeconds * (number of
frames per second) frames.

#local SlideFadeRate = .5;
//Amount of time in seconds for a new slide to fade in or out.
//Note that each slide transition will take 2 * SladeFadeRate seconds (one slide
will fade out, then the
//next slide will fade in.)

#local FadeColor = Red * .45;
//Color to fade to and from.

#local SinusoidalTransition = yes;
//Set to "yes" for a sinusoidal transition rate, "no" for a linear transition
rate.

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* *
                                    * */
/* *
                                    * */
/* * SLIDE SHOW
                                    * */
/* *
                                    * */
/* *
                                    * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * */

#local CurrentClock = clock * NSeconds;

#local TransitionTime_Total = SlideFadeRate * 2 * (NSlides - 1);
#local NonTransitionTime_Total = NSeconds - TransitionTime_Total;

#if (TransitionTime_Total > NSeconds)
   #error "Transition time exceeds total slideshow time. Increase the length of
the slideshow (NSeconds) or decrease the transition time (SlideFadeRate.)"
#end //#if

#local TransitionTime_FadeIn = array [NSlides]
#local TransitionTime_None = array [NSlides]
#local TransitionTime_FadeOut = array [NSlides]

#for (I, 0, NSlides - 1)
   #local TransitionTime_None [I] = I * NonTransitionTime_Total / NSlides + I *
SlideFadeRate * 2;
#end //#for

#for (I, 0, NSlides - 1)
   #local TransitionTime_FadeOut [I] = TransitionTime_None [I] +
NonTransitionTime_Total / NSlides;
#end //#for

#for (I, 0, NSlides - 1)
   #local TransitionTime_FadeIn [I] = TransitionTime_None [I] - SlideFadeRate;
#end //#for

#for (I, 0, NSlides - 1)
   #if (CurrentClock >= TransitionTime_FadeIn [I])
      #local CurrentSlideNumber = I;
      #local FadeRatio = (CurrentClock - TransitionTime_FadeIn [I]) /
SlideFadeRate;
   #end //#if
   #if (CurrentClock >= TransitionTime_None [I])
      #local FadeRatio = 1;
   #end //#if
   #if (CurrentClock >= TransitionTime_FadeOut [I])
      #local FadeRatio = (TransitionTime_FadeOut [I] + SlideFadeRate -
CurrentClock) / SlideFadeRate;
   #end //#if
#end //#for

#local SlideFileName = concat ("Slide_", str (CurrentSlideNumber, -2, 0),
".png")
#local SlideImagePigment = pigment {image_map {png SlideFileName gamma 2.2
map_type 0 interpolate 2 once}}
#local SlideColor = texture {SlideImagePigment finish {emission 1}}
#local SlideImageResolution = max_extent (SlideImagePigment);
#local SlideScale = CameraZ / max (SlideImageResolution.x,
SlideImageResolution.y);

#if (SinusoidalTransition)
   #local Angle = FadeRatio * 180 + 180;
   #local FadeRatio = (cos (radians (Angle)) + 1) / 2;
#end //#if

#local TransitionColor = texture {pigment {color FadeColor} finish {emission 1}}

#local XColor = texture {
   average
   texture_map {
      [FadeRatio SlideColor]
      [1 - FadeRatio TransitionColor]
   } //texture_map
} //texture

#local Slide = object {
   #local W = SlideImageResolution.x;
   #local H = SlideImageResolution.y;
   plane {
      z, 0
      clipped_by {box {<0, 0, -.1> <1, 1, .1>}}
      texture {XColor}
   } //plane
   scale <W, H, 1>
   translate <-W / 2, -H / 2, 0>
   scale <SlideScale, SlideScale, 1>
} //object

object {Slide}

[Dave Blandston] Re: Simple Slideshow [2688 days 14 hours and 37 minutes ago]

Mon, 26 Nov 2018 17:40:01 GMT

Oops, both planes should have the "no_radiosity" attribute.

Regards,
Dave Blandston

[Dave Blandston] Simple Slideshow [2689 days and 7 minutes ago]

Mon, 26 Nov 2018 08:10:02 GMT

Hi friends,

Here's the code for a very simple slideshow. It doesn't have very many settings.
It's excerpted from a more complex animation that I'm working on. It displays
any number of slides with a fade-out and fade-in between each one. It starts and
ends with slides faded all the way in.

The .zip file contains the slideshow POV code, three sample slides, and an .ini
file suitable for a five second, thirty-frame-per-second animation.

I hope someone finds this useful!

Regards,
Dave Blandston

[Dave Blandston] Bordered Characters version 1.8a [2702 days 4 hours and 17 minutes ago]

Tue, 13 Nov 2018 04:00:02 GMT

Greetings Friends,

This isn't really a new version - it just has a couple new Font Variations and
some documentation improvements. The instructions have been combined into one
new file called "BorderChars_Instructions.pov" instead of spread out among the
..inc files. This provides an identifiable starting place (which was woefully
missing). Also, the "Demo_BasicScene.pov" file has been renamed
"Demo_QuickStart.pov" and has been updated with better documentation. I hope the
documentation changes will make it easier to learn to use the bordered
characters.

Reasonably high quality pre-rendered demonstration images (.jpg format) are
included in this .zip file for the first time. This saves the trouble of having
to download each one individually from the povray.binaries.images area. I hope
this doesn't get me in trouble with the moderators. Moderators, I will be happy
to upload an imageless .zip file and post the images in the
povray.binaries.images area instead if you prefer.

Regards,
Dave Blandston

[Bald Eagle] Re: U equals zero - or not [2758 days 12 hours and 57 minutes ago]

Mon, 17 Sep 2018 19:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> Isn't it fascinating how quickly one can get to the bottom of a problem
> once a little bit of cruft, which you /thought/ was insignificant but
> totally obstructed my view on things and skewed yours, has been moved
> out of the way?

Yes, which is I why I solicited your help, because you'd think (and do) things I
wasn't doing.

Lots of little things in there that serve as a tutorial for debugging.

Your help and expertise is very much appreciated, as always.

Sometimes you just get stranded at the side of the road and need someone to
drive up with jumper cables.   (thumbs up)

Thanks!

[clipka] Re: U equals zero - or not [2759 days 18 hours and 32 minutes ago]

Sun, 16 Sep 2018 13:44:16 GMT

Am 16.09.2018 um 14:46 schrieb clipka:

> `BezierStitching_Test_3.pov` gives me a `Cannot find file
> 'GridMacro.png' in line 91, which I /think/ is not the problem we're
> talking about.

Okay, now that I've just bypassed that offending image_map and bump_map,
I get an error in line 324, the `#debug` line printing `Testing YVal =
...`, at what appears to be index U=7.


If I place a `#debug "***MATCH!***\n"` in line 327 in front of the
commented-out `#if` statement, I get the following output:

------------------------------------------------------------------
[...]
_X = 0.00000, _Y = 0.00000
Starting macro PatchUV
Starting macro ThisPatch
U = ZERO
Testing YVal = 0.00000000 vs
 [U=0.00000000] <0.00000000000000000000000000000000,
0.00000000000000000000000000000000, 0.89759790102565518000000000000000>

***MATCH!***
Testing YVal = 0.00000000 vs
 [U=1.00000000] <1.00000000000000000000000000000000,
0.89759790102565518000000000000000, 1.79519580205131040000000000000000>

Testing YVal = 0.00000000 vs
 [U=2.00000000] <2.00000000000000000000000000000000,
1.79519580205131040000000000000000, 2.69279370307696550000000000000000>
[...]
------------------------------------------------------------------

Note how this clearly and unambiguously demonstrates that the `#if`
condition in line 326 is met in the first loop iteration, i.e. POV-Ray
properly recognizes that YVal = 0 falls neatly inside the range
[0...whatever), and is consistent with it properly examining array
element 0, not anything else.


So my current hypothesis is that you /think/ the error at U=7 is not the
one you're looking for, but it's the one you're actually fighting with
at the moment.

This is also perfectly consistent with your observation that a `#local U
= 0;` right at the beginning of the loop "fixes" this issue, because
then the loop is stuck at U=0 and never reaches the offending index U=7.


Now if I weed out the cruft that's in the way - the one you say you
hoped to fix later - and change the `#for` loops in lines 316 and 337,
to run not to `Usize` and `Vsize` respectively, but `Usize-1` and
`Vsize-1`, this part of the code starts to run smoothly...


... and, hey presto! *NOW* I can at last witness the "Attempt to access
uninitialized array element" error you're presumably /really/ trying to
solve. /Now/ that /I/ have weeded out the cruft (as I had earlier
suggested /you/ do), I can at last get down to the bottom of it, rather
than fight with you about ghosts you're seeing that I'm not seeing.

And I find that while you've been trying to debug the "U side" of the
macro, the actual error message pertains to array elements initialized
by the "V side" of the macro; and indeed, there's a neat little debug
message:

    _Patch [3] V not defined

which confirms that the V side has failed to kick in, not the U side.

And if I look closely at the case at hand, I see why: The error happens
at _X (which goes into the V side) = 6.300; the ranges in VArray[] only
go up to ~6.283 though, so no matching range is found. Now theoretically
the problem might be that VArray is too short, and should be initialized
longer; but since the upper bound of the last tested array element is
equal to 2*pi, it seems plausible that VArray is fine, so _X must be at
fault.

Now all we have to figure out is why _X goes beyond 2*pi in the first
place, and we have the whole case solved.

Or you have to make _X wrap around to the range [0..2*pi) if it goes out
of that range.


I leave the rest as an exercise to you. Let me know if you hit another
impasse.


Isn't it fascinating how quickly one can get to the bottom of a problem
once a little bit of cruft, which you /thought/ was insignificant but
totally obstructed my view on things and skewed yours, has been moved
out of the way?

[clipka] Re: U equals zero - or not [2759 days 19 hours and 30 minutes ago]

Sun, 16 Sep 2018 12:46:09 GMT

Am 16.09.2018 um 14:33 schrieb clipka:
> Am 16.09.2018 um 05:09 schrieb Bald Eagle:
> 
>>> Sounds like not a minimal scene.
>>
>> It's the whole "closed system", to give you the most "precise" (accurate) way to
>> replicate what I'm seeing over here.  Now we can reference exact decimal line
>> numbers and everything.  The code you're working with "should be" good enough
>> ......  and that exact code (minus line break artefacts) was what I ran on my work
>> machine before copy-pasting it, so ....
> 
> Aaaaaalright, I'll give it a shot.
> 
> You wouldn't mind telling me which of the three `.pov` files is the one,
> would you?

Well, I guess it can't be `BillsArrayMacros.pov`, because that one
complains with an `#error` directive when attempting to parse it directly.

`BezierStitching_Test_3.pov` gives me a `Cannot find file
'GridMacro.png' in line 91, which I /think/ is not the problem we're
talking about.

`Equation_UVMap.pov` runs without an obvious hitch, nor any debug
output, and from a first glance I would say the rendered scene may make
sense, too.


So, what am I looking for?

[clipka] Re: U equals zero - or not [2759 days 19 hours and 43 minutes ago]

Sun, 16 Sep 2018 12:33:31 GMT

Am 16.09.2018 um 05:09 schrieb Bald Eagle:

>> Sounds like not a minimal scene.
> 
> It's the whole "closed system", to give you the most "precise" (accurate) way to
> replicate what I'm seeing over here.  Now we can reference exact decimal line
> numbers and everything.  The code you're working with "should be" good enough
> ......  and that exact code (minus line break artefacts) was what I ran on my work
> machine before copy-pasting it, so ....

Aaaaaalright, I'll give it a shot.

You wouldn't mind telling me which of the three `.pov` files is the one,
would you?

[Bald Eagle] Re: U equals zero - or not [2760 days 5 hours and 7 minutes ago]

Sun, 16 Sep 2018 03:10:01 GMT

....  thus narrowing the problem down to
> > why #local U = 0; "fixes" the issue.
>
> Huh? I thought the problem was that some variation of "0*N <= 0" didn't
> seem to work out; now you're saying that "U=0" wasn't holding?

Debugging developments, my Dear Boy.  The Game is afoot!

> But the output you posted from the `#debug concat ("Testing Y = ...`
> statement clearly showed that at least the debug output accessed the
> expected element of UArray, so why should the subsequent `#if` statement
> access a different element of UArray, if they both access element [U]?

Yeah - no kidding.  I have tried my best to pore over this, and am gonna go
blind or insane - which is usually the point at which I ask for genuine help.

At Line 318, I even threw in:
#if (U = 0) #debug "U = ZERO \n" #end


> > This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
> > (both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
> > tower at work.
>
> I presume that comma after "3.7.0.msvc10.win64" stands for "and", not
> further qualification; i.e. it happens in official POV-Ray for Windows
> as well as in QtPOV-Ray.

Correct - one runs on the win partition, and the other runs on the Mint
partition of the exact same laptop.

> That pretty much rules out the tenth level of floating point hell
> hypothesis, because the official POV-Ray for Windows binaries use
> "proper" floating point math.

Which is why I switched over to Windows, to see if there was an issue with
running it on the QTPOV-Ray build.

> It also means that we both /should/ get exactly the same results,
> because official version 3.7.0.msvc10.win64 is precisely the versions
> I've just verified my results with the code you posted prior to posting
> my most recent replies.


> So the `#if` clause MUST be entered in the first loop iteration (which
> /should/ be, and /is/, U=0, with UArray[U]=<0,0,1.047something) -
> because that's what is to be expected, and that's what I am absolutely
> positively seeing here, double-checked and all, with the exact same
> piece of software - unless your CPU is buggy, or some gremlin has pooped
> on your RAM, or whatever.

I think I'm reading that correctly.
You are now as officially perplexed as I am.
{But perhaps a ram has pooped on my Gremlin - and then I'd need a car wash.}

> Sounds like not a minimal scene.

It's the whole "closed system", to give you the most "precise" (accurate) way to
replicate what I'm seeing over here.  Now we can reference exact decimal line
numbers and everything.  The code you're working with "should be" good enough
.....  and that exact code (minus line break artefacts) was what I ran on my work
machine before copy-pasting it, so ....

> Is it any more enlightening than the code you posted earlier?

It "shouldn't be" - but precise is precise.  Running the scene in the zip with
the includes leaves no room for "that's not the exact code you posted..." and so
there shouldn't be ANY ambiguity, and you can tell me if the values I'm looking
at - out to 32 decimal places - are off, or I'm using one wrong variable name,
or syntax, or ---- something else I'm completely "familiarity-blind" to at this
point.

(I know, I know - the upper limit for that range (as shown below) is now
0.89759790102565518 - where it ought to be, but I'm not testing against the
upper limit now, am I?)

_X = 0.00000, _Y = 0.00000
Starting macro PatchUV
Starting macro ThisPatch
U = ZERO
Testing YVal = 0.00000000 vs
 [U=0.00000000] <0.00000000000000000000000000000000,
0.00000000000000000000000000000000, 0.89759790102565518000000000000000>





I mean, I'd love to get this worked out, and understand what the problem is -
but I'm getting that "He's gonna KILL me when he finally finds ..... whatever
stupid thing is wrong" feeling.  :(

But I mean, paste
#local U = 0;
into there and watch it go...
It'll loop endlessly, obviously.... but it doesn't step up to a U value
referencing an uninitialized array element either.

I'll play with some flags and also try converting it to a
#while (U < Usize)
loop tomorrow....




(I can only imagine the insanity that must occur on projects with tens of
thousands or millions of lines of code....)


If you haven't completely oriented yourself to the flow yet,
around Line 662 starts a new section of code that just "adds onto" the scene
generated by the prior code.
Loop from 0 to 1
Calculate x and y values (u and v) and pass those to the PatchUV macro at Line
361.   That calls ThisPatch macro which gives the array element corresponding to
an individual bicubic_patch, and then the rest of the PatchUV macro is supposed
to locate exactly where on that bicubic patch the point lies.

I was working on getting PatchUV to give me the desired and expected final scene
results when the current issue popped up.

[clipka] Re: U equals zero - or not [2760 days 7 hours and 3 minutes ago]

Sun, 16 Sep 2018 01:13:10 GMT

Am 16.09.2018 um 02:36 schrieb Bald Eagle:

> I had added them all, to see why you somehow were able to have the comparison
> evaluate successfully, and have the code execute without error, and then I
> commented out two of them and cycled through, thus narrowing the problem down to
> why #local U = 0; "fixes" the issue.

Huh? I thought the problem was that some variation of "0*N <= 0" didn't
seem to work out; now you're saying that "U=0" wasn't holding?

But the output you posted from the `#debug concat ("Testing Y = ...`
statement clearly showed that at least the debug output accessed the
expected element of UArray, so why should the subsequent `#if` statement
access a different element of UArray, if they both access element [U]?


> This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
> (both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
> tower at work.

I presume that comma after "3.7.0.msvc10.win64" stands for "and", not
further qualification; i.e. it happens in official POV-Ray for Windows
as well as in QtPOV-Ray.

That pretty much rules out the tenth level of floating point hell
hypothesis, because the official POV-Ray for Windows binaries use
"proper" floating point math.

It also means that we both /should/ get exactly the same results,
because official version 3.7.0.msvc10.win64 is precisely the versions
I've just verified my results with the code you posted prior to posting
my most recent replies.

So the `#if` clause MUST be entered in the first loop iteration (which
/should/ be, and /is/, U=0, with UArray[U]=<0,0,1.047something) -
because that's what is to be expected, and that's what I am absolutely
positively seeing here, double-checked and all, with the exact same
piece of software - unless your CPU is buggy, or some gremlin has pooped
on your RAM, or whatever.


> Attached are scene, includes, and a developmental model of the function for the
> CURVE section at the end of the main scene file.

Sounds like not a minimal scene.
Is it any more enlightening than the code you posted earlier?

[Bald Eagle] U equals zero - or not [2760 days 7 hours and 37 minutes ago]

Sun, 16 Sep 2018 00:40:00 GMT

Posting here in a new thread since advanced users does not support attachments.
:|


Maybe I'm a bit daft here, but can you please elaborate on the above
notation? Does each line represent something you tried inserting...
somehwere?

Yes.

After the `#for()` statement?... with the left showing the
result and the right showing the statement you tried?

Yes.

Did you try each
of the lines individually, or did you add them one after the other in
the above order?

I had added them all, to see why you somehow were able to have the comparison
evaluate successfully, and have the code execute without error, and then I
commented out two of them and cycled through, thus narrowing the problem down to
why #local U = 0; "fixes" the issue.

Does "no effect" mean you didn't get the desired
effect, or does it mean the observed effect isn't there? Does "Code
proceeds" mean the code works, or does it mean the `#if` clause is skipped?

No effect means I get the existing error, where the comparison craps out and the
loops runs out until I get the uninitialized array element error.


Hunting down obscure bugs is a matter of precision. This seems to be
something so strange that I need to understand /exactly/ what you're
doing and /exactly/ what your results are.

Yes, I would agree.
This happens in 3.7.0.msvc10.win64, Mr. Balaska's current QTPOV-Ray version,
(both on the same laptop, dual-boot) and the (IIRC) 32-bit 3.7.0 version on the
tower at work.


This is all the more important since I still don't seem to get the same
results; so either I didn't fully understand your description to allow
me to reproduce it - in which case precision is important so that I can
figure out what I'm still doing differently than you - or thre is
something fundamentally different between my environment and yours - in
which case precision is important because your description of the
scenario is all I have to go by to understand the root cause.

Yes.   I'm hoping it's just some strange thing that I'm reading through and not
catching

> So I tried #local U = int (U);   Nope.

You tried that where? And what exactly does "Nope" mean?

Immediately after the #for (U, 0, Usize) statement, with all of the other three
#local statement commented out.

> So, #for (U, 0, .... doesn't actually start at 0???   :|

I can pretty much rule that one out: The parser takes the literal `0`
and immediately assigns it to the local variable U, with no other fancy
operations involved. If there are any two statements by which you can
absolutely positively reliably get a clean genuine zero into some
variable, it is `#declare/local Foo=0;` and `#for (Foo,0,...)`.

Yes, I had both assumed and hoped that was the case, which makes this latest
SNAFU/FUBAR all the more puzzling.

Attached are scene, includes, and a developmental model of the function for the
CURVE section at the end of the main scene file.

[Mike Horvath] Re: 35mm Camera Macros [2818 days 7 hours and 42 minutes ago]

Fri, 20 Jul 2018 00:34:18 GMT

On 6/26/2018 11:06 AM, Stephen wrote:
> Bump post
> 
> On 16/03/2009 02:16, Edouard wrote:
>> Hi all.
>>
>> Here is version 1.0 of my camera macros.
>>
>> 35mm Camera Macros Version 1.0
>> ==============================
>>
>> The 35mm Camera macros were created to allow POV users to place
>> cameras in their scenes with the properties of a standard 35mm film
>> (or full frame digital) camera.
>>
>> The user can specify the lens (e.g. 50mm or 300mm) and the focal
>> ratio (e.g. f/1.4 or f/8), and the macros set the field of view and
>> amount of focal blur to approximate the effect seen in the real world.
>>
>> The user can specify the focal plane in several ways:
>>    - Setting it to the look_at point
>>    - Specifying a seperate point in space that is in focus
>>    - Specifying a distance to the focal plane
>>    - Allowing the camera to autofocus on an object
>>    - Setting the camera to the maximal hyperfocal point
>>
>> Multiple options can be set, such as the standard samples, variance and
>> confidence of POVs focal blur, as well as other options like the
>> circle of confusion for the hyperfocal calculations, the autofocus
>> samples and tightness, etc.
>>
>> There is also a "stochastic" mode that allows the user to render
>> multiple frames (via the animation clock settings). The passes can
>> then be composited together later to produce an image with focal
>> blur. This mode turns POV's built-in focal blur off completely.
>>
>> There are also two debugging variables that can be set to show
>> the focal plane, and the autofocus samples respectively.
>>
>> Finally these macros output some detailed information about
>> the cameras being use.
>>
>>
>>
>> Camera Macros
>> -------------
>>
>> Camera35mm( cam_pos, look_pos, focal_length, fstop )
>>
>>      Creates a camera with the focal plane at the same point as
the
>>      "look_pos" point.
>>
>>      Related Options:
>>          Camera35mm_SetFocalSamples(
num_samples )
>>          Camera35mm_SetFocalVariance(
variance )
>>          Camera35mm_SetFocalConfidence(
confidence )
>>
>>
>> Camera35mm_Point( cam_pos, look_pos, focal_pos, focal_length, fstop )
>>
>>      Creates a camera with the focal plane at the same distance
as
>>      the "focal_pos" point.
>>
>>      Related Options:
>>          Camera35mm_SetFocalSamples(
num_samples )
>>          Camera35mm_SetFocalVariance(
variance )
>>          Camera35mm_SetFocalConfidence(
confidence )
>>
>> Camera35mm_Distance( cam_pos, look_pos, focal_distance, focal_length, 
>> fstop )
>>
>>      Creates a camera with the focal plane set at
"focal_distance"
>>      from the camera.
>>
>>      Related Options:
>>          Camera35mm_SetFocalSamples(
num_samples )
>>          Camera35mm_SetFocalVariance(
variance )
>>          Camera35mm_SetFocalConfidence(
confidence )
>>
>> Camera35mm_Hyperfocal( cam_pos, look_pos, focal_length, fstop )
>>
>>      Creates a camera with focal plane set to the maximal
>>      hyperfocal distance (i.e. such that infinity is the
>>      furthest distance to still be considered in focus).
>>
>>      Related Options:
>>          Camera35mm_SetCircleOfConfusion(
coc_size )
>>          Camera35mm_SetFocalSamples(
num_samples )
>>          Camera35mm_SetFocalVariance(
variance )
>>          Camera35mm_SetFocalConfidence(
confidence )
>>
>>
>> Camera35mm_Autofocus( cam_pos, look_pos, focal_length, fstop, obj )
>>
>>      Creates a camera with the focal plane set by shooting test
>>      rays at the object "obj".
>>
>>      The object needs to be declared and passed to the
>>      macro, as follows:
>>
>>      #declare ball = sphere { 0, 20 pigment { rgb <1,0,0> } };
>>      object { ball }
>>      Camera35mm_Autofocus( cam_pos, look_pos, 50, 2.8, ball )
>>
>>      Related Options:
>>          Camera35mm_SetAutofocusTightness(
fraction_of_screen )
>>          Camera35mm_SetAutofocusSamples(
num_samples )
>>          Camera35mm_SetFocalSamples(
num_samples )
>>          Camera35mm_SetFocalVariance(
variance )
>>          Camera35mm_SetFocalConfidence(
confidence )
>>
>>
>> Camera35mm_NoBlur( cam_pos, look_pos, focal_length, fstop )
>>
>>      Creates a camera with focal blur turned off. Useful for
>>      setting up or testing a scene.
>>
>>
>>
>> Camera Modes
>> ------------
>>
>> By deault, the camera macros all use POV's built-in focal blur, but
>> the mode can be changed to use a stochastic rendering technique
>> that renders multiple images (via the animation clock settings)
>> that can later be composited together to give a scene with focal
>> blur.
>>
>> Camera35mm_SetStochasticMode()
>>
>>      Turns the stochastic rendering mode on (instead of POV's
built-in
>>      focal blur).
>>
>>      Related Options:
>>          Camera35mm_SetIrisImage(
iris_image_png_filename )
>>
>>
>> Camera35mm_SetPovFocalBlurMode()
>>
>>      Turns on POV's built-in focal blur mode.
>>      This is the default setting.
>>
>>
>>
>> Camera Options
>> --------------
>>
>> The following options may be set by the user
>>
>>      Camera35mm_SetFocalSamples( n )
>>
>>          Set the number of focal blur
samples as per the standard
>>          POV camera feature.
>>
>>
>>      Camera35mm_SetFocalVariance( n )
>>
>>          Sets the focal blur variance as
per the standard
>>          POV camera feature.
>>
>>
>>      Camera35mm_SetFocalConfidence( n )
>>
>>          Sets the focal blur confidence as
per the standard
>>          POV camera featue.
>>
>>
>>      Camera35mm_SetFocalParameters( n_samples, n_variance,
n_confidence )
>>
>>          Sets the samples, variance and
confidence all in one call.
>>
>>
>>      Camera35mm_SetIrisImage( s )
>>
>>          Sets the iris image used for
setting up each pass of the
>>          stochastic render rig.
>>
>>          The image file has to be a
grayscale PNG file currently.
>>
>>          The system has a built-in iris
image that is used if
>>          this macro isn't called.
>>
>>
>>      Camera35mm_SetCircleOfConfusion( n )
>>
>>          Sets the circle of confusion for
use in the hpyerfocal
>>          macro.
>>
>>
>>      Camera35mm_SetAutofocusSamples( n )
>>
>>          Sets the number of samples shot
into the scene to determine
>>          the optimal focal distance given
an test object.
>>
>>          The default value is 500.
>>
>>
>>      Camera35mm_SetAutofocusTightness( n )
>>
>>          Sets the tightness of the
autofocus area. 1.0 means use a
>>          circle the width of the image, 0.5
is half the image, and
>>          0.1 is 10% of the image. The
circle is always centered
>>          in the image.
>>
>>          The default value is 0.7.
>>
>>          Wider values might be helped by
using more samples, and
>>          narrower values could use less
samples.
>>
>>
>>
>> Debugging Variables
>> -------------------
>>
>> There are two variables that can be set to debug a scene:
>>
>> Camera35mm_DebugFocalPlane
>>
>>      Draws a partially transparent plane through the focal
plane.
>>
>>
>> Camera35mm_DebugAutofocus
>>
>>      Draws spheres at every position where an autofocus sample
>>      hit the object being focused on.
>>
>>      The sphere are purple, except for the one choosen to focus
on,
>>      which is green.
>>
>>
>>
>> Example Output
>> --------------
>>
>> Autofocus Debug Output:
>>   Number of hits = 77 (out of 500)
>>   Autofocus tightness = 0.70
>>   Autofocus on = <14.769, 256.538, -37.084> (distance 1263.750mm)
>>
>> 35mm Camera Debug Output:
>>   Focal Length is 50mm
>>   Focal Ratio is f/1.4
>>   Focal Distance is 1259.1mm
>>   Field of View is 39.6 degrees
>>
>>   Sensor size is 36mm by 18mm
>>   Sensor size is 700 by 350 (pixels)
>>   Circle of confusion is 0.051mm
>>
>>   Hyperfocal distance is 34772.2mm
>>   Near Focus is 1216.7mm
>>   Far Focus is 1304.5mm
>>   Total distance in focus is 87.80mm
>>   In front of focal plane 42.37mm (48.3%)
>>   Behind focal plane 45.43mm (51.7%)
>>
>> Focal Blur Debug Output:
>>   Focal blur samples is 37
>>   Focal blur variance is (Default)
>>   Focal blur confidence is (Default)
>>
>>
> 
> 


Could the author please upload the macros to the Object Collection?


Mike

[Stephen] Re: 35mm Camera Macros [2841 days 17 hours and 10 minutes ago]

Tue, 26 Jun 2018 15:06:40 GMT

Bump post

On 16/03/2009 02:16, Edouard wrote:
> Hi all.
> 
> Here is version 1.0 of my camera macros.
> 
> 35mm Camera Macros Version 1.0
> ==============================
> 
> The 35mm Camera macros were created to allow POV users to place
> cameras in their scenes with the properties of a standard 35mm film
> (or full frame digital) camera.
> 
> The user can specify the lens (e.g. 50mm or 300mm) and the focal
> ratio (e.g. f/1.4 or f/8), and the macros set the field of view and
> amount of focal blur to approximate the effect seen in the real world.
> 
> The user can specify the focal plane in several ways:
>    - Setting it to the look_at point
>    - Specifying a seperate point in space that is in focus
>    - Specifying a distance to the focal plane
>    - Allowing the camera to autofocus on an object
>    - Setting the camera to the maximal hyperfocal point
> 
> Multiple options can be set, such as the standard samples, variance and
> confidence of POVs focal blur, as well as other options like the
> circle of confusion for the hyperfocal calculations, the autofocus
> samples and tightness, etc.
> 
> There is also a "stochastic" mode that allows the user to render
> multiple frames (via the animation clock settings). The passes can
> then be composited together later to produce an image with focal
> blur. This mode turns POV's built-in focal blur off completely.
> 
> There are also two debugging variables that can be set to show
> the focal plane, and the autofocus samples respectively.
> 
> Finally these macros output some detailed information about
> the cameras being use.
> 
> 
> 
> Camera Macros
> -------------
> 
> Camera35mm( cam_pos, look_pos, focal_length, fstop )
> 
>      Creates a camera with the focal plane at the same point as the
>      "look_pos" point.
> 
>      Related Options:
>          Camera35mm_SetFocalSamples( num_samples )
>          Camera35mm_SetFocalVariance( variance )
>          Camera35mm_SetFocalConfidence( confidence )
> 
> 
> Camera35mm_Point( cam_pos, look_pos, focal_pos, focal_length, fstop )
> 
>      Creates a camera with the focal plane at the same distance as
>      the "focal_pos" point.
> 
>      Related Options:
>          Camera35mm_SetFocalSamples( num_samples )
>          Camera35mm_SetFocalVariance( variance )
>          Camera35mm_SetFocalConfidence( confidence )
> 
> Camera35mm_Distance( cam_pos, look_pos, focal_distance, focal_length, fstop )
> 
>      Creates a camera with the focal plane set at "focal_distance"
>      from the camera.
> 
>      Related Options:
>          Camera35mm_SetFocalSamples( num_samples )
>          Camera35mm_SetFocalVariance( variance )
>          Camera35mm_SetFocalConfidence( confidence )
> 
> Camera35mm_Hyperfocal( cam_pos, look_pos, focal_length, fstop )
> 
>      Creates a camera with focal plane set to the maximal
>      hyperfocal distance (i.e. such that infinity is the
>      furthest distance to still be considered in focus).
> 
>      Related Options:
>          Camera35mm_SetCircleOfConfusion( coc_size )
>          Camera35mm_SetFocalSamples( num_samples )
>          Camera35mm_SetFocalVariance( variance )
>          Camera35mm_SetFocalConfidence( confidence )
> 
> 
> Camera35mm_Autofocus( cam_pos, look_pos, focal_length, fstop, obj )
> 
>      Creates a camera with the focal plane set by shooting test
>      rays at the object "obj".
> 
>      The object needs to be declared and passed to the
>      macro, as follows:
> 
>      #declare ball = sphere { 0, 20 pigment { rgb <1,0,0> } };
>      object { ball }
>      Camera35mm_Autofocus( cam_pos, look_pos, 50, 2.8, ball )
> 
>      Related Options:
>          Camera35mm_SetAutofocusTightness( fraction_of_screen )
>          Camera35mm_SetAutofocusSamples( num_samples )
>          Camera35mm_SetFocalSamples( num_samples )
>          Camera35mm_SetFocalVariance( variance )
>          Camera35mm_SetFocalConfidence( confidence )
> 
> 
> Camera35mm_NoBlur( cam_pos, look_pos, focal_length, fstop )
> 
>      Creates a camera with focal blur turned off. Useful for
>      setting up or testing a scene.
> 
> 
> 
> Camera Modes
> ------------
> 
> By deault, the camera macros all use POV's built-in focal blur, but
> the mode can be changed to use a stochastic rendering technique
> that renders multiple images (via the animation clock settings)
> that can later be composited together to give a scene with focal
> blur.
> 
> Camera35mm_SetStochasticMode()
> 
>      Turns the stochastic rendering mode on (instead of POV's built-in
>      focal blur).
> 
>      Related Options:
>          Camera35mm_SetIrisImage( iris_image_png_filename )
> 
> 
> Camera35mm_SetPovFocalBlurMode()
> 
>      Turns on POV's built-in focal blur mode.
>      This is the default setting.
> 
> 
> 
> Camera Options
> --------------
> 
> The following options may be set by the user
> 
>      Camera35mm_SetFocalSamples( n )
> 
>          Set the number of focal blur samples as per the standard
>          POV camera feature.
> 
> 
>      Camera35mm_SetFocalVariance( n )
> 
>          Sets the focal blur variance as per the standard
>          POV camera feature.
> 
> 
>      Camera35mm_SetFocalConfidence( n )
> 
>          Sets the focal blur confidence as per the standard
>          POV camera featue.
> 
> 
>      Camera35mm_SetFocalParameters( n_samples, n_variance, n_confidence )
> 
>          Sets the samples, variance and confidence all in one call.
> 
> 
>      Camera35mm_SetIrisImage( s )
> 
>          Sets the iris image used for setting up each pass of the
>          stochastic render rig.
> 
>          The image file has to be a grayscale PNG file currently.
> 
>          The system has a built-in iris image that is used if
>          this macro isn't called.
> 
> 
>      Camera35mm_SetCircleOfConfusion( n )
> 
>          Sets the circle of confusion for use in the hpyerfocal
>          macro.
> 
> 
>      Camera35mm_SetAutofocusSamples( n )
> 
>          Sets the number of samples shot into the scene to determine
>          the optimal focal distance given an test object.
> 
>          The default value is 500.
> 
> 
>      Camera35mm_SetAutofocusTightness( n )
> 
>          Sets the tightness of the autofocus area. 1.0 means use a
>          circle the width of the image, 0.5 is half the image, and
>          0.1 is 10% of the image. The circle is always centered
>          in the image.
> 
>          The default value is 0.7.
> 
>          Wider values might be helped by using more samples, and
>          narrower values could use less samples.
> 
> 
> 
> Debugging Variables
> -------------------
> 
> There are two variables that can be set to debug a scene:
> 
> Camera35mm_DebugFocalPlane
> 
>      Draws a partially transparent plane through the focal plane.
> 
> 
> Camera35mm_DebugAutofocus
> 
>      Draws spheres at every position where an autofocus sample
>      hit the object being focused on.
> 
>      The sphere are purple, except for the one choosen to focus on,
>      which is green.
> 
> 
> 
> Example Output
> --------------
> 
> Autofocus Debug Output:
>   Number of hits = 77 (out of 500)
>   Autofocus tightness = 0.70
>   Autofocus on = <14.769, 256.538, -37.084> (distance 1263.750mm)
> 
> 35mm Camera Debug Output:
>   Focal Length is 50mm
>   Focal Ratio is f/1.4
>   Focal Distance is 1259.1mm
>   Field of View is 39.6 degrees
> 
>   Sensor size is 36mm by 18mm
>   Sensor size is 700 by 350 (pixels)
>   Circle of confusion is 0.051mm
> 
>   Hyperfocal distance is 34772.2mm
>   Near Focus is 1216.7mm
>   Far Focus is 1304.5mm
>   Total distance in focus is 87.80mm
>   In front of focal plane 42.37mm (48.3%)
>   Behind focal plane 45.43mm (51.7%)
> 
> Focal Blur Debug Output:
>   Focal blur samples is 37
>   Focal blur variance is (Default)
>   Focal blur confidence is (Default)
> 
> 


-- 

Regards
     Stephen

[And] Re: Playing with media clouds [2842 days 21 hours and 57 minutes ago]

Mon, 25 Jun 2018 10:20:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Here is the scene and df3 files talked about in p.b.images.
>
> --
> Thomas

Good shape;

[And] Re: And's pattern blend playground [2843 days 1 hour and 32 minutes ago]

Mon, 25 Jun 2018 06:45:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> With thanks to And, a little playground when you have nothing better to
> do :-)
>
>
> /**********************************************************************************
>   Persistence of Vision Ray Tracer Scene Description File
>   File name   : And_Pattern blend.pov
>   Version     : 3.71
>   Description : Pattern blending of a photograph.
>
>   Date        : 2 March 2018
>   Author      : And
>   E-mail      : in p.b.i. pattern blend (by And):
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a996d03fe35f84f1c2f7e850%40news.povray.org%3E/
>   See also:
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a996d03fe35f84f1c2f7e850%40news.povray.org%3E/?mtop=4210
77&moff=20
>
> **********************************************************************************/
>
> // Render settings 3.7 (right-click on a line below):
> // Be sure to set the image width and height
> // for glasses.jpg:
> // +w1024 +h768 +a0.3 +am2 +bm2 +rp0 +bs8 +wt6
>
> #version 3.71;
> //#version unofficial patch 3.71; //UberPOV
>
> #include "stdinc.inc"
>
> #local Rad     = off;     // radiosity switch
>
> global_settings {
>    assumed_gamma 1.0
>    max_trace_level 5
>    noise_generator 2
>    #if (Rad)
>      radiosity {
>        pretrace_start   0.08
>        pretrace_end     0.004
>        count            100, 1000
>        nearest_count    10, 5
>        error_bound      1
>        recursion_limit  1
>        low_error_factor 0.3
>        gray_threshold   0.0
>        minimum_reuse    0.015
>        maximum_reuse    0.1
>        brightness       1
>
>        adc_bailout      0.01/2
>        normal           off
>        media            off
>        always_sample    off
>        //max_sample     1.0
>      }
>    #end
> }
>
> // ----------------------------------------
> camera {
>    orthographic
>    location  <0.0, 0.0, -10.0>
>    look_at   <0.0, 0.0,  0.0>
>    right     x*image_width
>    up        y*image_height
>    angle 5.8*1
> }
>
> background {color rgb 1}
>
>
//==============================================================================================
> // Controls:
> #local Mono    = off;    // monochrome/polychrome switch
> #local Gamma   = 5;      // play with this value for interesting results
> #local Pattern = 1;      // 1=crackle solid; 2=granite; 3=agate;
> 4=bumps; 5=quilted; 6=bozo;
> #local N       = 0.1;  // use N <= 1.0
> #local rotZ    = 40;     // rotation angle of the pattern around the z-axis
>
>
//==============================================================================================
> // Load here your image:
> #declare p_original =
> pigment {
>    image_map {
>      jpeg "glasses.jpg" gamma Gamma
>      map_type 0
>      interpolate 2
>    }
> }
>
>
//==============================================================================================
> #if (Mono)
>
> #declare p_modify =
> pigment{
>      pigment_pattern{p_original}
>      pigment_map {
>      #for(i,0,255)
>        [i/255  #switch (Pattern)
>                #case(1)
>                  crackle solid
>                #break #case(2)
>                  granite
>                #break #case(3)
>                  agate
>                #break #case(4)
>                  bumps
>                #break #case(5)
>                  quilted control0 0.5 control1 1
>                #break #case(6)
>                  bozo
>                #end
>                scale (1/<image_width, image_height, 1>)*N
>                rotate <0,0, rotZ>
>                color_map {
>                  [0.2+0.6*(1-pow(i/255,1/3)) rgbt<0,0,0,0.1>]
>                  [0.2+0.6*(1-pow(i/255,1/3)) rgbt<0,0,0,0.9>]
>                }
>        ]
>      #end
>      }
> }
>
> #else
>
> #declare f_original =
> function {pigment {p_original}}
>
> #declare f_o_R = function {f_original (x,y,z).red}
> #declare f_o_G = function {f_original (x,y,z).green}
> #declare f_o_B = function {f_original (x,y,z).blue}
>
> #declare f_modify =
> pigment {
>    average
>    pigment_map {
>      [1    function {f_o_R (x,y,z)}
>            pigment_map {
>              #for (i, 0, 255)
>                   [i/255  #switch (Pattern)
>                           #case(1)
>                             crackle solid
>                           #break #case(2)
>                             granite
>                           #break #case(3)
>                             agate
>                           #break #case(4)
>                             bumps
>                           #break #case(5)
>                             quilted control0 0.5 control1 1
>                           #break #case(6)
>                             bozo
>                           #end
>                           scale (1/<image_width, image_height, 1>)*N
>                           rotate <0,0, rotZ>
>                           color_map {
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <3,0,0,0.9>]
>                           }
>                   ]
>              #end
>            }
>          ]
>      [1    function {f_o_G (x,y,z)}
>            pigment_map {
>              #for (i, 0, 255)
>                   [i/255  #switch (Pattern)
>                           #case(1)
>                             crackle solid
>                           #break #case(2)
>                             granite
>                           #break #case(3)
>                             agate
>                           #break #case(4)
>                             bumps
>                           #break #case(5)
>                             quilted control0 0.5 control1 1
>                           #break #case(6)
>                             bozo
>                           #end
>                           scale (1/<image_width, image_height, 1>)*N
>                           rotate <0,0, rotZ>
>                           color_map {
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,3,0,0.9>]
>                           }
>                   ]
>              #end
>            }
>          ]
>      [1    function {f_o_B (x,y,z)}
>            pigment_map {
>              #for (i, 0, 255)
>                   [i/255  #switch (Pattern)
>                           #case(1)
>                             crackle solid
>                           #break #case(2)
>                             granite
>                           #break #case(3)
>                             agate
>                           #break #case(4)
>                             bumps
>                           #break #case(5)
>                             quilted control0 0.5 control1 1
>                           #break #case(6)
>                             bozo
>                           #end
>                           scale (1/<image_width, image_height, 1>)*N
>                           rotate <0,0, rotZ>
>                           color_map {
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
>                             [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,3,0.9>]
>                           }
>                   ]
>               #end
>             }
>           ]
>    }
> }
>
> #end
>
>
//==============================================================================================
> plane {
>    z, 0
>    #if (Mono)
>      pigment {p_modify
>    #else
>      pigment {f_modify
>    #end
>      translate -0.5
>      scale <image_width, image_height, 1>
>      scale 0.001
>    }
>    finish {emission 1 diffuse 0}
>    no_shadow
> }
>
>
//==============================================================================================
>
> --
> Thomas



Well, I didn't know you post an article here.

[clipka] Re: Cedeaq's semi-random landscape revisited [2844 days 15 hours and 21 minutes ago]

Sat, 23 Jun 2018 16:56:02 GMT

Am 23.06.2018 um 18:00 schrieb Alain:

>>> Beware that your font path is not for universal use! Users have to
>>> edit your code in order to use it properly. For demonstration
>>> purposes it is better to stick to the standard ttf's provided by
>>> POV-Ray.
...

> On a normally installed version of POV-Ray, the path to your fonts
> should already be in your input paths.
> That mean that you should not need to have that
> Â«#local textpath = "/home/Raytracing/Povscn/Fonts/";"Â»
> 
> In fact, under Windows, in the message pane, you can find this :
> Library paths:
> ....[some other paths]...
> C:\Windows\Fonts
> 
> Without having that path in any of the ini files.
> 
> On a Linux system, or a Mac, you should have something similar.

While on Windows fonts are handled by the operating system itself,
that's not the case on Unixoid systems like Linux or Mac OS X; AFAIK, on
these systems, font management is instead the job of whatever graphical
interface is installed - be it KDE, Gnome, or whatever. The
corresponding path(s) /may/ have been added by the POV-Ray package
manager of whatever distribution you're using, but to my knowledge
there's nothing similar in vanilla "out of the box" POV-Ray for Linux.

Besides, even if POV-Ray for a given platform knows /where/ to find
fonts installed on the system, there's no guarantee that a /particular/
font will be found there. For example, you shouldn't expect "arial.ttf"
to be installed on Unix machines.

[Alain] Re: Cedeaq's semi-random landscape revisited [2844 days 16 hours and 18 minutes ago]

Sat, 23 Jun 2018 15:58:51 GMT

Le 18-06-22 Ã  22:34, JÃ¶rg "Yadgar" Bleimann a
Ã©critÂ :
> Hi(gh)!
> 
> On 22.06.2018 09:36, Thomas de Groot wrote:
> 
>> Beware that your font path is not for universal use! Users have to 
>> edit your code in order to use it properly. For demonstration purposes 
>> it is better to stick to the standard ttf's provided by POV-Ray.
>>
> 
> Here is the cleaned-up code!
> 
> See you in Khyberspace!
> 
> Yadgar
> 

On a normally installed version of POV-Ray, the path to your fonts 
should already be in your input paths.
That mean that you should not need to have that
Â«#local textpath = "/home/Raytracing/Povscn/Fonts/";"Â»

In fact, under Windows, in the message pane, you can find this :
Library paths:
...[some other paths]...
C:\Windows\Fonts

Without having that path in any of the ini files.

On a Linux system, or a Mac, you should have something similar.

Alain

[Thomas de Groot] Re: Cedeaq's semi-random landscape revisited [2845 days 1 hour and 9 minutes ago]

Sat, 23 Jun 2018 07:07:55 GMT

On 23-6-2018 4:34, JÃ¶rg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> On 22.06.2018 09:36, Thomas de Groot wrote:
> 
>> Beware that your font path is not for universal use! Users have to 
>> edit your code in order to use it properly. For demonstration purposes 
>> it is better to stick to the standard ttf's provided by POV-Ray.
>>
> 
> Here is the cleaned-up code!
> 
> See you in Khyberspace!
> 
> Yadgar
> 

Neat!

One other thing: In F_SelfShine, change 'ambient' into 'emission'. Will 
give you one lengthy warning less ;-)

-- 
Thomas

[Jörg "Yadgar" Bleimann] Re: Cedeaq's semi-random landscape revisited [2845 days 5 hours and 42 minutes ago]

Sat, 23 Jun 2018 02:34:55 GMT

Hi(gh)!

On 22.06.2018 09:36, Thomas de Groot wrote:

> Beware that your font path is not for universal use! Users have to edit 
> your code in order to use it properly. For demonstration purposes it is 
> better to stick to the standard ttf's provided by POV-Ray.
> 

Here is the cleaned-up code!

See you in Khyberspace!

Yadgar

[Jörg "Yadgar" Bleimann] Re: Cedeaq's semi-random landscape revisited [2845 days 20 hours and 8 minutes ago]

Fri, 22 Jun 2018 12:08:07 GMT

Hi(gh)!

On 22.06.2018 09:36, Thomas de Groot wrote:

> Beware that your font path is not for universal use! Users have to edit 
> your code in order to use it properly. For demonstration purposes it is 
> better to stick to the standard ttf's provided by POV-Ray.

Yes, I know and initially planned to add a comment... but it was late 
and I wanted to get the thing online before laying down for sleep! I 
also will refine the code in the coming days, especially implementing 
arrays and loops for the depth/elevation levels and their arrangement in 
color_maps, and making the map legend parametrizeable for different map 
layouts...

And later on, I will do much modification on surface textures and 
vegetation, thus "Afghanizing" the whole scenery... but at the moment, 
it's still a pipe dream.

See you in Khyberspace (yes, it may turn out the become some sort of 
fictional Khyberspace!)

Yadgar

[Thomas de Groot] Re: Cedeaq's semi-random landscape revisited [2846 days and 40 minutes ago]

Fri, 22 Jun 2018 07:36:12 GMT

On 22-6-2018 3:30, JÃ¶rg "Yadgar" Bleimann wrote:
> Hi(gh)!
> 
> I added map functionality... see image on p.b.i!
> 
> See you in Khyberspace!
> 
> Yadgar

Beware that your font path is not for universal use! Users have to edit 
your code in order to use it properly. For demonstration purposes it is 
better to stick to the standard ttf's provided by POV-Ray.

-- 
Thomas

[Jörg "Yadgar" Bleimann] Re: Cedeaq's semi-random landscape revisited [2846 days 6 hours and 46 minutes ago]

Fri, 22 Jun 2018 01:31:01 GMT

Hi(gh)!

I added map functionality... see image on p.b.i!

See you in Khyberspace!

Yadgar

[Thomas de Groot] Cedeaq's semi-random landscape revisited [2847 days and 11 minutes ago]

Thu, 21 Jun 2018 08:05:50 GMT

See p.b.i. for an example image of the following code.


-- 
Thomas

[Stephen] Flowers for clipka [2875 days 12 hours and 25 minutes ago]

Wed, 23 May 2018 19:51:53 GMT

Attached is a scene with an image to use as a hightfield. Mentioned in 
the thread â€œRestructured Parser wants Testingâ€ in
povray.beta-test.
To spare my embarrassment it is a proof of concept and Iâ€™ve done
little 
to make it look pretty.
The code for the heightfield still has my original path. So that will 
need to be changed.
There is also a closing â€œ}â€ that I had to comment
out and donâ€™t 
understand why.
There is a workaround for exporting the trace code from Bishop3D that 
comments out an object called â€œDummy0â€.
The variable â€œDensityâ€ controls the density of the
grass blades (and 
flowers on the ground).

I would be more than pleased if anyone can improve the logic of planting 
the grass and flowers.

Credits and blame. ;)
The B3D workaround was devised by StephenS.
The ground texture was donated to the Moray community by Thomas DeG.
The sphere_sweep was made by using jrâ€™s  hilbert2d utility.
Thatâ€™s it. There is no one else I can blame. :)


-- 

Regards
     Stephen

[Thomas de Groot] Re: Playing with media clouds - update [2887 days and 40 minutes ago]

Sat, 12 May 2018 07:36:33 GMT

Absorption an emission media should also be compensated for media 
scaling. Here is an update for both cloud and atmosphere, to be replaced 
with originals.

//start code
//========================================================================
//Cloud layer:

#declare C_Cloud = <252, 252, 253>/255;
#declare C_Sky3  = <225, 225, 226>/255;

#declare C_Scattering = C_Cloud*10;
#declare C_Absorption = (1-C_Cloud)*800;
#declare C_Emission   = C_Cloud*0.1;//C_Sky3*0.01;

#declare C_Scale    = 200;
#declare Turbulence = 0.15; //0.15; // cloud turbulence
#declare Lambda     = 3; // cloud lambda
#declare Omega      = 0.6; // cloud omega

#declare Cloud1 =
box {
   <-0.5, 0, -0.5>, <0.5, 1.0, 0.5>
   texture {pigment {rgbt 1} finish {diffuse 0}}
   //texture {pigment {rgbt <1,0,0,0.9>} finish {diffuse 1}}
   hollow
   interior {
     media {
       scattering {1, rgb C_Scattering/C_Scale /*extinction 0.15*/}
       absorption rgb C_Absorption/C_Scale
       emission rgb C_Emission/C_Scale
       intervals 1
       samples 100
       density {
         density_file df3 "Scattered_03.df3"
         turbulence Turbulence
         lambda Lambda
         omega Omega
         interpolate 1
         translate <-0.5, 0.0, -0.5>
       }
     }
   }
   scale C_Scale
   scale <10, 0.5, 10>
   rotate y*0
   translate <0, 101, C_Scale*5>
}

Cloud1

//========================================================================
//Atmospheric haze under the cloud layer:

#declare C_Fog          = <250, 250, 250>/255;
#declare Fog_Scattering = C_Fog*0.1;
#declare Fog_absorption = (1-C_Fog)*2;
#declare Fog_Scale      = 200;

#declare Fog =
box {
   <-0.5, -1.0, -0.5>, <0.5, 0.0, 0.5>
   texture {pigment {rgbt 1} finish {diffuse 0}}
   hollow
   interior {
     media {
       scattering {1, rgb Fog_Scattering/Fog_Scale /*extinction 0.15*/}
       absorption rgb Fog_absorption/Fog_Scale
       intervals 1
       samples 100
     }
   }
   scale Fog_Scale
   scale <10, 1, 10>
   translate <0, 100, C_Scale*5>
}

Fog

//end code


-- 
Thomas

[Thomas de Groot] Playing with media clouds [2887 days 21 hours and 10 minutes ago]

Fri, 11 May 2018 11:06:24 GMT

Here is the scene and df3 files talked about in p.b.images.

-- 
Thomas

[Dave Blandston] Good Quality Digital Camouflage [2897 days 1 hour and 12 minutes ago]

Wed, 2 May 2018 07:05:01 GMT

Recently I had a need for digital camouflage in a scene. After researching the
topic, I learned that the algorithms used to generate digital camouflage are
fractal. That level of math is beyond my ability but after some careful
experimentation I have made a simple POV file to create digital camouflage that
appears indistinguishable (to me, anyway) from the example that I used. POV can
do anything! I will share it here in case anyone else ever has a use for it.

The attached .zip file also has a utility that can be used to generate POV code
defining an array of index values based on a bitmap image of the digital
camouflage.

Over the years I have found many useful items on this newsgroup and I always
want to share something that someone else may find useful as well.

Regards,
Dave Blandston

[Sven Littkowski] Re: Wood Texture Playground [2912 days 2 hours and 10 minutes ago]

Tue, 17 Apr 2018 06:06:07 GMT

A good wood semi gloss example is here:

https://ak9.picdn.net/shutterstock/videos/25010189/thumb/1.jpg?i10c=img.r
esize(height:160)

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Wood Texture Playground [2912 days 4 hours and 10 minutes ago]

Tue, 17 Apr 2018 04:06:40 GMT

I attached my "SL - Woods.inc" file, and the "1.pov" scene test file.

The magic of the wood seems to lay in line 179 of the INC file, if you
want to improve the realism of this dark, non-painted but a bit
varnished lumber.

I saw wood textures where you could see the grain influencing the
reflection.


---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Re: Helical Torus source - was "Help!" in pbi [2918 days 1 hour and 39 minutes ago]

Wed, 11 Apr 2018 06:37:22 GMT

Yes. Outsh.   :-(

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Paolo Gibellini] Seashell doodle [2919 days 18 hours and 48 minutes ago]

Mon, 9 Apr 2018 13:28:42 GMT

Seashell generated with Mediat software.
See image in p.b.i.
Paolo

[Alain] Re: Helical Torus source - was "Help!" in pbi [2920 days 5 hours and 43 minutes ago]

Mon, 9 Apr 2018 02:33:35 GMT

Le 18-04-08 Ã  20:02, Sven Littkowski a Ã©critÂ :
> Okay, good to know.
> My system (just for the next few weeks) is a Pentium II with 1.25GB
> RAM...   :-D
> 
> ---
> Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
> http://www.avg.com
> 
Ouch !

[Sven Littkowski] Re: Helical Torus source - was "Help!" in pbi [2920 days 8 hours and 14 minutes ago]

Mon, 9 Apr 2018 00:02:07 GMT

Okay, good to know.
My system (just for the next few weeks) is a Pentium II with 1.25GB
RAM...   :-D

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Thomas de Groot] Re: Helical Torus source - was "Help!" in pbi [2921 days 1 hour and 25 minutes ago]

Sun, 8 Apr 2018 06:51:32 GMT

On 8-4-2018 3:23, Sven Littkowski wrote:
> An illumination HDR file of half a gigabite..?!?????    :-(
> 
> Still downloading. POV-Ray will take eons...
> 

No.


-- 
Thomas

[Sven Littkowski] Re: Helical Torus source - was "Help!" in pbi [2921 days 6 hours and 53 minutes ago]

Sun, 8 Apr 2018 01:23:41 GMT

An illumination HDR file of half a gigabite..?!?????    :-(

Still downloading. POV-Ray will take eons...

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Re: Photons - Please Test [2921 days 7 hours and 46 minutes ago]

Sun, 8 Apr 2018 00:30:28 GMT

Giving now twice that attention each time I am posting...   :-)

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Re: INQUIRY: How Long Does Your PC take For The ... [2921 days 7 hours and 47 minutes ago]

Sun, 8 Apr 2018 00:29:17 GMT

Thanks. But on my system this is working - of course. You could change
the path but also disable all images with the SHIPTEX switch quite at
the top. After all, no water reflection would hit any of those areas of
the ship.

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[kurtz le pirate] Helical Torus source - was "Help!" in pbi [2921 days 22 hours and 35 minutes ago]

Sat, 7 Apr 2018 09:41:53 GMT

See attatched pov file.

HDRI file from VizPeople
<https://www.viz-people.com/portfolio/free-hdri-maps/>


Have fun !

-- 
Kurtz le pirate
Compagnie de la Banquise

[Alain] Re: Photons - Please Test [2927 days 12 hours and 52 minutes ago]

Sun, 1 Apr 2018 19:24:57 GMT

Le 18-03-31 Ã  21:41, Sven Littkowski a Ã©critÂ :
> Hi. No, I posted it again, because my newsgroup reader did not show me
> my first thread. I thought, it got lost or never submitted. I have that
> problem since just a relatively short time. It is a software-related
> problem. My apologies for the double-posting.
> 
> ---
> Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
> http://www.avg.com
> 

Any post can take some time to appear after you hit the send button.

Your reader query the server every few minutes to see if there are any 
new posts. If you sent something just after that query, that won't show 
up for some time.

You can set your reader to check for new posts more often. It may also 
be possible to manualy force the reader to check or refresh the list.

[Alain] Re: Photons - Please Test [2927 days 12 hours and 56 minutes ago]

Sun, 1 Apr 2018 19:20:54 GMT

Le 18-03-31 Ã  21:40, Sven Littkowski a Ã©critÂ :
> No, a software problem. my newsgroup reader has since a few days a
> problem: it does not show all my freshly-submitted threads or postings.
> I thought them to be lost or never submitted, and that is why I posted
> them again.
> 
> Trust me, I don't like to type everything twice or more times. I hope,
> that software problem won't endure.
> 
> ---
> Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
> http://www.avg.com
> 

In that case, you only need to wait 20 to 30 minutes longer, untill your 
post do appears.

[Le Forgeron] Re: INQUIRY: How Long Does Your PC take For The ... [2927 days 16 hours and 16 minutes ago]

Sun, 1 Apr 2018 16:00:05 GMT

Le 31/03/2018 Ã  13:28, Sven Littkowski a Ã©critÂ :
> Please test the attached scene, and tell me, how long your computer
> system requires to create and save the photon map file. Thanks.
> 
> 
> ---
> Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
> http://www.avg.com
> 


Possible Parse Error: Cannot find file 'C:\Documents
 and Settings\Sven\My Documents\My Pictures\POV-Ray Textures\The Long Wide
 River.png', even after trying to append file type extension.
File 'aa.pov' line 1597: Possible Parse Error: Cannot find image file.
Fatal error in parser: Cannot open file.
Render failed



Do not hard code paths in #include

[Sven Littkowski] Re: Photons - Please Test [2928 days 6 hours and 35 minutes ago]

Sun, 1 Apr 2018 01:41:43 GMT

Hi. No, I posted it again, because my newsgroup reader did not show me
my first thread. I thought, it got lost or never submitted. I have that
problem since just a relatively short time. It is a software-related
problem. My apologies for the double-posting.

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Re: Photons - Please Test [2928 days 6 hours and 36 minutes ago]

Sun, 1 Apr 2018 01:40:45 GMT

No, a software problem. my newsgroup reader has since a few days a
problem: it does not show all my freshly-submitted threads or postings.
I thought them to be lost or never submitted, and that is why I posted
them again.

Trust me, I don't like to type everything twice or more times. I hope,
that software problem won't endure.

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Stephen] Re: Photons - Please Test [2928 days 13 hours and 24 minutes ago]

Sat, 31 Mar 2018 18:52:25 GMT

On 31/03/2018 19:37, clipka wrote:
> if
> the problem is that you sometimes forget that you've already posted the
> message).


Maybe an echo effect due to the ganja. ;-)

-- 

Regards
     Stephen

[clipka] Re: Photons - Please Test [2928 days 13 hours and 39 minutes ago]

Sat, 31 Mar 2018 18:37:17 GMT

Am 31.03.2018 um 20:04 schrieb Sven Littkowski:
> How long do your computers take to create and save the photon map for
> the attached scene?

Sven, you have a tendency to double-post messages with just trivial
changes. I recommend taking more time to think before hitting the "post"
button, and/or embrace more of a "fire and forget" attitude towards the
posts you've already sent (or maybe a "fire and remember" attitude if
the problem is that you sometimes forget that you've already posted the
message).

[Sven Littkowski] Photons - Please Test [2928 days 14 hours and 12 minutes ago]

Sat, 31 Mar 2018 18:04:50 GMT

How long do your computers take to create and save the photon map for
the attached scene?


---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] INQUIRY: How Long Does Your PC take For The Phot... [2928 days 20 hours and 49 minutes ago]

Sat, 31 Mar 2018 11:28:02 GMT

Please test the attached scene, and tell me, how long your computer
system requires to create and save the photon map file. Thanks.


---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Sven Littkowski] Re: For Sven trace() [2929 days and 47 minutes ago]

Sat, 31 Mar 2018 07:29:33 GMT

And I don't want to stay behind in expressing my thanks, both of you! :-D

---
Diese E-Mail wurde von AVG auf Viren geprÃ¼ft.
http://www.avg.com

[Thomas de Groot] Re: For Sven trace() [2932 days 1 hour and 3 minutes ago]

Wed, 28 Mar 2018 07:13:10 GMT

On 28-3-2018 8:23, Stephen wrote:
> An example .....
> 

I could not stay behind, so a couple of test files here ;-)

-- 
Thomas

[Stephen] For Sven trace() [2932 days 1 hour and 53 minutes ago]

Wed, 28 Mar 2018 06:23:44 GMT

An example using trace to throw arrows at a mesh.
The script was exported by Bishop3D so it is not optimised. The trace 
code is at the end of the file.

-- 

Regards
     Stephen

[Sven Littkowski] Re: for Sven Littkowski - Algorithmus Wanted [2936 days 6 hours and 22 minutes ago]

Sat, 24 Mar 2018 01:54:18 GMT

Thanks everyone, seeing it just now, so belated.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

[Dave Blandston] Digital Camouflage [2937 days 20 hours and 47 minutes ago]

Thu, 22 Mar 2018 11:30:01 GMT

This file creates a simple digital camouflage pattern. Anyone who's interested
in improving it is welcome! I have commented the line that needs to be improved
by adding a fractal function.

Regards,
Dave Blandston

[Thomas de Groot] Re: shattered certainties demo [2946 days 20 hours and 7 minutes ago]

Tue, 13 Mar 2018 12:09:38 GMT

On 13-3-2018 12:38, Norbert Kern wrote:
> Original message in
>
http://news.povray.org/povray.binaries.images/thread/%3C5aa69f8c%40news.povray.org%3E/.
> 
> Here is a scene to show how sky and lighting were made.
> 
> Norbert
> 

That is really nice and knowledgeable. Thanks!

-- 
Thomas

[Norbert Kern] shattered certainties demo [2946 days 20 hours and 37 minutes ago]

Tue, 13 Mar 2018 11:40:01 GMT

Original message in
http://news.povray.org/povray.binaries.images/thread/%3C5aa69f8c%40news.povray.org%3E/.

Here is a scene to show how sky and lighting were made.

Norbert

[Alain] Re: Sky simulation [2948 days 10 hours and 6 minutes ago]

Sun, 11 Mar 2018 22:10:22 GMT

Le 18-03-10 à 20:53, Mike Horvath a écrit :
> Should this macro use srgb in its pigments or rgb?
> 
> 
> Mike

It looks like it's based on lightsys. That mean that you should use rgb.

Rule of thumb : If the colour is from some colour picker or a paint 
application, use srgb. If it's from a formula calculated within the SDL, 
use rgb unless the documentation for that code tells you to use srgb.


Alain

[Alain] Re: Sky simulation [2948 days 10 hours and 10 minutes ago]

Sun, 11 Mar 2018 22:06:37 GMT

Le 18-03-10 à 20:48, Mike Horvath a écrit :
> On 3/6/2018 9:48 PM, Alain wrote:
>>> Quick question:
>>>
>>> How do I convert the units of ExposureFactor to my scene?
>>>
>>> In my scene, 20 units = 1 foot.
>>>
>>> Thanks!!
>>>
>>>
>>> Mike
>>>
>>
>> The formula use meter, a meter = about 39 inches, or 3 feet and 3 
>> inches (3.25 feet in 1 m).
>> There are 10.5625 square feet in a square meter.
>>
> 
> I still don't know what the effect on the value of ExposureFactor should 
> be.
> 
> 
> //  ExposureFactor A conversion factor between the luminance of the
>
//                
sky calculated (in cd/m2) to POV values. As the sky
>
//                
luminance can be very high (around 10000 cd/m2)
>
//                
then an ExposureFactor around 1e-5 will be needed to
>
//                
get a correct exposure when looking at the sky
> 
> 
> Mike

Just start with 1/100000.
If it's to bright, use a lower value. If it's to dark, use a higher value.
Repeat until you get a pleasing result.

[Mike Horvath] Re: Sky simulation [2949 days 6 hours and 23 minutes ago]

Sun, 11 Mar 2018 01:53:22 GMT

Should this macro use srgb in its pigments or rgb?


Mike

[Mike Horvath] Re: Sky simulation [2949 days 6 hours and 28 minutes ago]

Sun, 11 Mar 2018 01:48:47 GMT

On 3/6/2018 9:48 PM, Alain wrote:
>> Quick question:
>>
>> How do I convert the units of ExposureFactor to my scene?
>>
>> In my scene, 20 units = 1 foot.
>>
>> Thanks!!
>>
>>
>> Mike
>>
> 
> The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches 
> (3.25 feet in 1 m).
> There are 10.5625 square feet in a square meter.
> 

I still don't know what the effect on the value of ExposureFactor should be.

//  ExposureFactor A conversion factor between the luminance of the
//                 sky calculated (in cd/m2) to POV values. As the sky
//                 luminance can be very high (around 10000 cd/m2)
//                 then an ExposureFactor around 1e-5 will be needed to
//                 get a correct exposure when looking at the sky

Mike

[omniverse] Re: And's pattern blend playground [2949 days 8 hours and 2 minutes ago]

Sun, 11 Mar 2018 00:15:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> With thanks to And, a little playground when you have nothing better to
> do :-)
Thanks to you too, I had just started looking at that a few days ago and thought
I would try layering images to combine them. Didn't get far but on a whim I
changed to interpolate 3 for the input image and got an interesting result.

Reading the docs to refresh my memory on that bicubic interpolation it says
there could be a sharpening effect on certain color boundaries. So that probably
explains the peculiar outlines seen in these pattern blend renderings if
interpolate 3 is used.

[Thomas de Groot] And's pattern blend playground [2950 days 19 hours and 56 minutes ago]

Fri, 9 Mar 2018 12:20:26 GMT

With thanks to And, a little playground when you have nothing better to 
do :-)


/**********************************************************************************
  Persistence of Vision Ray Tracer Scene Description File
  File name   : And_Pattern blend.pov
  Version     : 3.71
  Description : Pattern blending of a photograph.

  Date        : 2 March 2018
  Author      : And
  E-mail      : in p.b.i. pattern blend (by And):
 
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a996d03fe35f84f1c2f7e850%40news.povray.org%3E/
  See also:
 
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a996d03fe35f84f1c2f7e850%40news.povray.org%3E/?mtop=421077&moff=20

**********************************************************************************/

// Render settings 3.7 (right-click on a line below):
// Be sure to set the image width and height
// for glasses.jpg:
// +w1024 +h768 +a0.3 +am2 +bm2 +rp0 +bs8 +wt6

#version 3.71;
//#version unofficial patch 3.71; //UberPOV

#include "stdinc.inc"

#local Rad     = off;     // radiosity switch

global_settings {
   assumed_gamma 1.0
   max_trace_level 5
   noise_generator 2
   #if (Rad)
     radiosity {
       pretrace_start   0.08
       pretrace_end     0.004
       count            100, 1000
       nearest_count    10, 5
       error_bound      1
       recursion_limit  1
       low_error_factor 0.3
       gray_threshold   0.0
       minimum_reuse    0.015
       maximum_reuse    0.1		
       brightness       1

       adc_bailout      0.01/2
       normal           off
       media            off
       always_sample    off
       //max_sample     1.0
     }
   #end
}

// ----------------------------------------
camera {
   orthographic
   location  <0.0, 0.0, -10.0>
   look_at   <0.0, 0.0,  0.0>
   right     x*image_width
   up        y*image_height
   angle 5.8*1
}

background {color rgb 1}

//==============================================================================================
// Controls:
#local Mono    = off;    // monochrome/polychrome switch
#local Gamma   = 5;      // play with this value for interesting results
#local Pattern = 1;      // 1=crackle solid; 2=granite; 3=agate; 
4=bumps; 5=quilted; 6=bozo;
#local N       = 0.1;  // use N <= 1.0
#local rotZ    = 40;     // rotation angle of the pattern around the z-axis

//==============================================================================================
// Load here your image:
#declare p_original =
pigment {
   image_map {
     jpeg "glasses.jpg" gamma Gamma
     map_type 0
     interpolate 2
   }
}

//==============================================================================================
#if (Mono)

#declare p_modify =
pigment{
     pigment_pattern{p_original}
     pigment_map {
     #for(i,0,255)
       [i/255  #switch (Pattern)
               #case(1)
                 crackle solid
               #break #case(2)
                 granite
               #break #case(3)
                 agate
               #break #case(4)
                 bumps
               #break #case(5)
                 quilted control0 0.5 control1 1
               #break #case(6)
                 bozo
               #end
               scale (1/<image_width, image_height, 1>)*N
               rotate <0,0, rotZ>
               color_map {
                 [0.2+0.6*(1-pow(i/255,1/3)) rgbt<0,0,0,0.1>]
                 [0.2+0.6*(1-pow(i/255,1/3)) rgbt<0,0,0,0.9>]
               }
       ]
     #end
     }
}

#else

#declare f_original =
function {pigment {p_original}}

#declare f_o_R = function {f_original (x,y,z).red}
#declare f_o_G = function {f_original (x,y,z).green}
#declare f_o_B = function {f_original (x,y,z).blue}

#declare f_modify =
pigment {
   average
   pigment_map {
     [1    function {f_o_R (x,y,z)}
           pigment_map {
             #for (i, 0, 255)
                  [i/255  #switch (Pattern)
                          #case(1)
                            crackle solid
                          #break #case(2)
                            granite
                          #break #case(3)
                            agate
                          #break #case(4)
                            bumps
                          #break #case(5)
                            quilted control0 0.5 control1 1
                          #break #case(6)
                            bozo
                          #end
                          scale (1/<image_width, image_height, 1>)*N
                          rotate <0,0, rotZ>
                          color_map {
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <3,0,0,0.9>]
                          }
                  ]
             #end
           }
         ]
     [1    function {f_o_G (x,y,z)}
           pigment_map {
             #for (i, 0, 255)
                  [i/255  #switch (Pattern)
                          #case(1)
                            crackle solid
                          #break #case(2)
                            granite
                          #break #case(3)
                            agate
                          #break #case(4)
                            bumps
                          #break #case(5)
                            quilted control0 0.5 control1 1
                          #break #case(6)
                            bozo
                          #end
                          scale (1/<image_width, image_height, 1>)*N
                          rotate <0,0, rotZ>
                          color_map {
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,3,0,0.9>]
                          }
                  ]
             #end
           }
         ]
     [1    function {f_o_B (x,y,z)}
           pigment_map {
             #for (i, 0, 255)
                  [i/255  #switch (Pattern)
                          #case(1)
                            crackle solid
                          #break #case(2)
                            granite
                          #break #case(3)
                            agate
                          #break #case(4)
                            bumps
                          #break #case(5)
                            quilted control0 0.5 control1 1
                          #break #case(6)
                            bozo
                          #end
                          scale (1/<image_width, image_height, 1>)*N
                          rotate <0,0, rotZ>
                          color_map {
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,0,0.1>]
                            [0.2+0.6*(1-pow (i/255,1/3)) srgbt <0,0,3,0.9>]
                          }
                  ]
              #end
            }
          ]
   }
}

#end

//==============================================================================================
plane {
   z, 0
   #if (Mono)
     pigment {p_modify
   #else
     pigment {f_modify
   #end
     translate -0.5
     scale <image_width, image_height, 1>
     scale 0.001
   }
   finish {emission 1 diffuse 0}
   no_shadow
}

//==============================================================================================

-- 
Thomas

[Thomas de Groot] Re: Sky simulation [2951 days and 14 minutes ago]

Fri, 9 Mar 2018 08:02:32 GMT

On 8-3-2018 14:26, Stephen wrote:
> On 08/03/2018 12:23, Thomas de Groot wrote:
>> On 8-3-2018 10:34, Stephen wrote:
> 
>>>>>
>>>>
>>>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>>>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>>>
>>>
>>> More likely Pop. The materials used are designed to take the weight 
>>> and are over rated.
>>
>> Sad. I would like a bit of drama ;-)
>>
> 
> Your slightest wish is my command.
> 
> https://youtu.be/CjzykTQM-4w?t=78
> 
> A similar incident happened on the platform I was on. Unfortunately the 
> crane driver was not so lucky. He got trapped in the cabin for hours and 
> lost a foot and part of his lower leg.

Yes... I was joking but I am very aware of the dangers. At the Survey 
one day, we got a sampler stuck at the base of a borehole. The tension 
on the hoisting cable gradually increased until you saw it vibrate like 
a violin string. We rapidly backed away from the site as you can imagine.

> 
>>>
>>>
>>>> I am always surprised that we got to the Moon at all, or Mars for 
>>>> that matter, where we were able to crash at least once because of 
>>>> imperial/metrics confusion... ;-)
>>>>
>>>
>>> Big mistake mixing units. I may think in imperial but work in metric 
>>> when I can.
>>>
>>
>> smart. But then you grew up with imperial of course. I find it 
>> difficult (not that I need it).
>>
> 
> It is difficult and took years of repetition before it became second 
> nature. But after learning things like there are 5280 ft in a mile and 
> 60 mph is 88 ft/s. Not to mention the currency. The metric system is a 
> walk in the park.

Yes indeed. I struggled with the currency... In the bar, it got easier 
with the hour. :-]

> Also we oldies can add up in our head. Unlike the youth of today.
> 

Yep :-)


-- 
Thomas

[Thomas de Groot] Re: Sky simulation [2951 days and 23 minutes ago]

Fri, 9 Mar 2018 07:53:34 GMT

On 8-3-2018 14:38, Stephen wrote:
> On 08/03/2018 13:26, Stephen wrote:
>> Your slightest wish is my command.
>>
>> https://youtu.be/CjzykTQM-4w?t=78
> 
> I just noticed a follow up video.
> The cage the guys are in is galled a Billy Pugh and you are supposed to 
> stand on the outside so you don't get trapped if it goes into the sea. I 
> used them for my one trip on the Piper. A white knuckle job.
> 
> https://www.youtube.com/watch?v=ZD8y7Slx2ow
> 
> 

Wow... that is nasty. I guess the operator got a well-earned spanking.

I suppose that with high seas this can happen very easily all by itself...

-- 
Thomas

[Alain] Re: Sky simulation [2951 days 11 hours and 55 minutes ago]

Thu, 8 Mar 2018 20:21:06 GMT

Le 18-03-08 à 02:54, Thomas de Groot a écrit :
> On 7-3-2018 22:44, Stephen wrote:
>> On 07/03/2018 21:00, Alain wrote:
>>> Le 18-03-07 à 07:21, Stephen a écrit :
>>>
>>>> BTW has anyone heard or seen a ruler where feet are divided into 
>>>> tenths?
>>>> Giving the impression that there are 10 "X inches" to a foot.
>>>> I saw one once about 30 years ago.
>>>>
>>>>
>>>
>>> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 
>>> 1/6, 1/9 and 1/12.
>>> I've seen one with foot divided into 1/3 and 1/4.
>>
>> I think it might be industry specific rule.
>> About 30 years ago. My boss, offshore, took some measurements in the 
>> toolpusher's office using a rule he found there. After getting 
>> whatever it was made. It did not fit. He got a bit of a slagging for 
>> it. As you would. ;-)
>> He went back up to check only to find that there was 10 "inches" to 
>> the foot.
>> Drillers use some strange terms. The anchor chain tension is measured 
>> in Kilo-pound-inches. I had never heard of that measurement before I 
>> had to calibrate the load sensors.
>>
> 
> Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
> per inch'? the word kilo being used for the thousand's value?
> 

Very reasonable assumption. Values in pound per inches would require 
uselessly large values with some not very significant trailing zeros.

[Stephen] Re: Sky simulation [2951 days 18 hours and 3 minutes ago]

Thu, 8 Mar 2018 14:13:37 GMT

On 07/03/2018 23:29, Mike Horvath wrote:
> On 3/7/2018 7:21 AM, Stephen wrote:
>> Now, I would be surprised if people in the UK did not know that. I 
>> guess I was about 15 or 16 when I was taught it at school.
>> But as a rule of thumb that an inch is about the length of your 
>> thumb's distal phalanx. Is good enough for children as they more 
>> resemble the size of an adult of bygone years.
>>
>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>> Giving the impression that there are 10 "X inches" to a foot.
>> I saw one once about 30 years ago.
>>
>>
> 
> I have a triangular drafting ruler that is like that.
> 
> 


Hmm I got a set of drafting scale rulers, somewhere in storage. I must 
have a look at them. I think the one I saw was a folding yardstick. My 
great uncle gave them to me when I was at school.


-- 

Regards
     Stephen

[Stephen] Re: Sky simulation [2951 days 18 hours and 38 minutes ago]

Thu, 8 Mar 2018 13:38:18 GMT

On 08/03/2018 13:26, Stephen wrote:
> Your slightest wish is my command.
> 
> https://youtu.be/CjzykTQM-4w?t=78

I just noticed a follow up video.
The cage the guys are in is galled a Billy Pugh and you are supposed to 
stand on the outside so you don't get trapped if it goes into the sea. I 
used them for my one trip on the Piper. A white knuckle job.

https://www.youtube.com/watch?v=ZD8y7Slx2ow

-- 

Regards
     Stephen

[Stephen] Re: Sky simulation [2951 days 18 hours and 50 minutes ago]

Thu, 8 Mar 2018 13:26:33 GMT

On 08/03/2018 12:23, Thomas de Groot wrote:
> On 8-3-2018 10:34, Stephen wrote:

>>>>
>>>
>>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>>
>>
>> More likely Pop. The materials used are designed to take the weight 
>> and are over rated.
> 
> Sad. I would like a bit of drama ;-)
> 

Your slightest wish is my command.

https://youtu.be/CjzykTQM-4w?t=78

A similar incident happened on the platform I was on. Unfortunately the 
crane driver was not so lucky. He got trapped in the cabin for hours and 
lost a foot and part of his lower leg.

>>
>>
>>> I am always surprised that we got to the Moon at all, or Mars for 
>>> that matter, where we were able to crash at least once because of 
>>> imperial/metrics confusion... ;-)
>>>
>>
>> Big mistake mixing units. I may think in imperial but work in metric 
>> when I can.
>>
> 
> smart. But then you grew up with imperial of course. I find it difficult 
> (not that I need it).
> 

It is difficult and took years of repetition before it became second 
nature. But after learning things like there are 5280 ft in a mile and 
60 mph is 88 ft/s. Not to mention the currency. The metric system is a 
walk in the park.
Also we oldies can add up in our head. Unlike the youth of today.

-- 

Regards
     Stephen

[Thomas de Groot] Re: Sky simulation [2951 days 19 hours and 53 minutes ago]

Thu, 8 Mar 2018 12:23:21 GMT

On 8-3-2018 10:34, Stephen wrote:
> On 08/03/2018 09:04, Thomas de Groot wrote:
>> On 8-3-2018 9:25, Stephen wrote:
>>> On 08/03/2018 07:54, Thomas de Groot wrote:
>>>> On 7-3-2018 22:44, Stephen wrote:
>>>
>>>>> Drillers use some strange terms. The anchor chain tension is 
>>>>> measured in Kilo-pound-inches. I had never heard of that 
>>>>> measurement before I had to calibrate the load sensors.
>>>>>
>>>>
>>>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>>>> pounds per inch'? the word kilo being used for the thousand's value?
>>>>
>>>
>>> Yes kilo is a multiplier and since it is a unit of work it should 
>>> have been KIP, kilo inch pounds which is 112.98 Nm.
>>> I got kpi stuck in my head. :-)
>>>
>>> For something so important the transmitter was a simple op amp. Check 
>>> the zero and span against the supplied load cell manufacturers data 
>>> sheet. Easy peasy. :-)
>>>
>>
>> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
>> "Hey John! Lets give it a pound more!"  BANG!  ;-)
>>
> 
> More likely Pop. The materials used are designed to take the weight and 
> are over rated.

Sad. I would like a bit of drama ;-)

> 
> 
>> I am always surprised that we got to the Moon at all, or Mars for that 
>> matter, where we were able to crash at least once because of 
>> imperial/metrics confusion... ;-)
>>
> 
> Big mistake mixing units. I may think in imperial but work in metric 
> when I can.
> 

smart. But then you grew up with imperial of course. I find it difficult 
(not that I need it).

-- 
Thomas

[Stephen] Re: Sky simulation [2951 days 22 hours and 42 minutes ago]

Thu, 8 Mar 2018 09:34:24 GMT

On 08/03/2018 09:04, Thomas de Groot wrote:
> On 8-3-2018 9:25, Stephen wrote:
>> On 08/03/2018 07:54, Thomas de Groot wrote:
>>> On 7-3-2018 22:44, Stephen wrote:
>>
>>>> Drillers use some strange terms. The anchor chain tension is 
>>>> measured in Kilo-pound-inches. I had never heard of that measurement 
>>>> before I had to calibrate the load sensors.
>>>>
>>>
>>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>>> pounds per inch'? the word kilo being used for the thousand's value?
>>>
>>
>> Yes kilo is a multiplier and since it is a unit of work it should have 
>> been KIP, kilo inch pounds which is 112.98 Nm.
>> I got kpi stuck in my head. :-)
>>
>> For something so important the transmitter was a simple op amp. Check 
>> the zero and span against the supplied load cell manufacturers data 
>> sheet. Easy peasy. :-)
>>
> 
> Easy peasy indeed. I imagine the guys calibrating those data sheets: 
> "Hey John! Lets give it a pound more!"  BANG!  ;-)
> 

More likely Pop. The materials used are designed to take the weight and 
are over rated.


> I am always surprised that we got to the Moon at all, or Mars for that 
> matter, where we were able to crash at least once because of 
> imperial/metrics confusion... ;-)
> 

Big mistake mixing units. I may think in imperial but work in metric 
when I can.

-- 

Regards
     Stephen

[Thomas de Groot] Re: Sky simulation [2951 days 23 hours and 12 minutes ago]

Thu, 8 Mar 2018 09:04:27 GMT

On 8-3-2018 9:25, Stephen wrote:
> On 08/03/2018 07:54, Thomas de Groot wrote:
>> On 7-3-2018 22:44, Stephen wrote:
> 
>>> Drillers use some strange terms. The anchor chain tension is measured 
>>> in Kilo-pound-inches. I had never heard of that measurement before I 
>>> had to calibrate the load sensors.
>>>
>>
>> Interesting story. "kilo-pound-inches", could that mean 'thousand 
>> pounds per inch'? the word kilo being used for the thousand's value?
>>
> 
> Yes kilo is a multiplier and since it is a unit of work it should have 
> been KIP, kilo inch pounds which is 112.98 Nm.
> I got kpi stuck in my head. :-)
> 
> For something so important the transmitter was a simple op amp. Check 
> the zero and span against the supplied load cell manufacturers data 
> sheet. Easy peasy. :-)
> 

Easy peasy indeed. I imagine the guys calibrating those data sheets: 
"Hey John! Lets give it a pound more!"  BANG!  ;-)

I am always surprised that we got to the Moon at all, or Mars for that 
matter, where we were able to crash at least once because of 
imperial/metrics confusion... ;-)

-- 
Thomas

[Stephen] Re: Sky simulation [2951 days 23 hours and 51 minutes ago]

Thu, 8 Mar 2018 08:25:10 GMT

On 08/03/2018 07:54, Thomas de Groot wrote:
> On 7-3-2018 22:44, Stephen wrote:

>> Drillers use some strange terms. The anchor chain tension is measured 
>> in Kilo-pound-inches. I had never heard of that measurement before I 
>> had to calibrate the load sensors.
>>
> 
> Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
> per inch'? the word kilo being used for the thousand's value?
> 

Yes kilo is a multiplier and since it is a unit of work it should have 
been KIP, kilo inch pounds which is 112.98 Nm.
I got kpi stuck in my head. :-)

For something so important the transmitter was a simple op amp. Check 
the zero and span against the supplied load cell manufacturers data 
sheet. Easy peasy. :-)

-- 

Regards
     Stephen

[Thomas de Groot] Re: Sky simulation [2952 days and 22 minutes ago]

Thu, 8 Mar 2018 07:54:47 GMT

On 7-3-2018 22:44, Stephen wrote:
> On 07/03/2018 21:00, Alain wrote:
>> Le 18-03-07 à 07:21, Stephen a écrit :
>>
>>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>>> Giving the impression that there are 10 "X inches" to a foot.
>>> I saw one once about 30 years ago.
>>>
>>>
>>
>> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
>> 1/9 and 1/12.
>> I've seen one with foot divided into 1/3 and 1/4.
> 
> I think it might be industry specific rule.
> About 30 years ago. My boss, offshore, took some measurements in the 
> toolpusher's office using a rule he found there. After getting whatever 
> it was made. It did not fit. He got a bit of a slagging for it. As you 
> would. ;-)
> He went back up to check only to find that there was 10 "inches" to the 
> foot.
> Drillers use some strange terms. The anchor chain tension is measured in 
> Kilo-pound-inches. I had never heard of that measurement before I had to 
> calibrate the load sensors.
> 

Interesting story. "kilo-pound-inches", could that mean 'thousand pounds 
per inch'? the word kilo being used for the thousand's value?

-- 
Thomas

[Mike Horvath] Re: Sky simulation [2952 days 8 hours and 47 minutes ago]

Wed, 7 Mar 2018 23:29:09 GMT

On 3/7/2018 7:21 AM, Stephen wrote:
> Now, I would be surprised if people in the UK did not know that. I guess 
> I was about 15 or 16 when I was taught it at school.
> But as a rule of thumb that an inch is about the length of your thumb's 
> distal phalanx. Is good enough for children as they more resemble the 
> size of an adult of bygone years.
> 
> BTW has anyone heard or seen a ruler where feet are divided into tenths?
> Giving the impression that there are 10 "X inches" to a foot.
> I saw one once about 30 years ago.
> 
> 

I have a triangular drafting ruler that is like that.


Mike

[Stephen] Re: Sky simulation [2952 days 10 hours and 32 minutes ago]

Wed, 7 Mar 2018 21:44:16 GMT

On 07/03/2018 21:00, Alain wrote:
> Le 18-03-07 à 07:21, Stephen a écrit :
> 
>> BTW has anyone heard or seen a ruler where feet are divided into tenths?
>> Giving the impression that there are 10 "X inches" to a foot.
>> I saw one once about 30 years ago.
>>
>>
> 
> Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
> 1/9 and 1/12.
> I've seen one with foot divided into 1/3 and 1/4.

I think it might be industry specific rule.
About 30 years ago. My boss, offshore, took some measurements in the 
toolpusher's office using a rule he found there. After getting whatever 
it was made. It did not fit. He got a bit of a slagging for it. As you 
would. ;-)
He went back up to check only to find that there was 10 "inches" to the 
foot.
Drillers use some strange terms. The anchor chain tension is measured in 
Kilo-pound-inches. I had never heard of that measurement before I had to 
calibrate the load sensors.

-- 

Regards
     Stephen

[Alain] Re: Sky simulation [2952 days 11 hours and 18 minutes ago]

Wed, 7 Mar 2018 20:59:03 GMT

Le 18-03-07 à 07:21, Stephen a écrit :

> BTW has anyone heard or seen a ruler where feet are divided into tenths?
> Giving the impression that there are 10 "X inches" to a foot.
> I saw one once about 30 years ago.
> 
> 

Not feet into tenth, but with inches divided into 1/5, 1/10, 1/3, 1/6, 
1/9 and 1/12.
I've seen one with foot divided into 1/3 and 1/4.

[Stephen] sphere_sweep artifacts [2952 days 18 hours and 57 minutes ago]

Wed, 7 Mar 2018 13:19:49 GMT

Iâ€™ve run into a problem using a large sphere_sweep. I get a
horizontal, 
straight line artefact.
You can change the location of the artefact by raising or lowering 
either the camera location or look_at vector.
Happens in both ver 3.6 and 3.7
Iâ€™ll post an image in p.b.i


-- 

Regards
     Stephen

[Stephen] Re: Sky simulation [2952 days 19 hours and 55 minutes ago]

Wed, 7 Mar 2018 12:21:39 GMT

On 07/03/2018 11:44, clipka wrote:
> Sorry to be blunt, but with that many decimals, that number is a lie, as
> it implies a precision it doesn't have.
> 

You are right of course, if bluntly put.

> As a rule of thumb, whenever you're doing mathematical computations with
> approximate values, it is good practice to round the end result to the
> lowest number of significant digits of any of the "input" values.
> 
> Also, since the UK imperial and US customary units are defined in terms
> of the metric system (yes, you UK folks have been using the metric
> system ever since 1930, and you US folks even since 1893(*); it's just
> been hidden from you :P), that's what I'd recommend to start with:

Now, I would be surprised if people in the UK did not know that. I guess 
I was about 15 or 16 when I was taught it at school.
But as a rule of thumb that an inch is about the length of your thumb's 
distal phalanx. Is good enough for children as they more resemble the 
size of an adult of bygone years.

BTW has anyone heard or seen a ruler where feet are divided into tenths?
Giving the impression that there are 10 "X inches" to a foot.
I saw one once about 30 years ago.

-- 

Regards
     Stephen

[clipka] Re: Sky simulation [2952 days 20 hours and 33 minutes ago]

Wed, 7 Mar 2018 11:44:04 GMT

Am 07.03.2018 um 03:48 schrieb Alain:

> The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches
> (3.25 feet in 1 m).
> There are 10.5625 square feet in a square meter.

Sorry to be blunt, but with that many decimals, that number is a lie, as
it implies a precision it doesn't have.

As a rule of thumb, whenever you're doing mathematical computations with
approximate values, it is good practice to round the end result to the
lowest number of significant digits of any of the "input" values.

Also, since the UK imperial and US customary units are defined in terms
of the metric system (yes, you UK folks have been using the metric
system ever since 1930, and you US folks even since 1893(*); it's just
been hidden from you :P), that's what I'd recommend to start with:

(A) from the 1930 BSI (UK) / 1933 ASA (US) definition:

1 inch = 25.4 mm = 0.0254 m
1 foot = 12 inch = 0.3048 m

(B) from the 1959 International Yard and Pound Agreement:

1 yard = 0.9144 m
1 foot = 1/3 yard = 0.3048 m

Either way:

1 square foot = 0.09290303 m^2
1/0.09290303 square feet = 1 m^2

These numbers are exact, by virtue of definition of the UK imperial and
US customary units. Alternatively, here's a high-precision approximation:

10,7639104167097223083335055559 square feet = 1 m^2


(* The 1893 Mendenhall Order (US) definition had 1 yard = 3600/3937 m,
which gives slightly different results, and has remained the basis for
the survey foot.)

[Alain] Re: Sky simulation [2953 days 5 hours and 28 minutes ago]

Wed, 7 Mar 2018 02:48:20 GMT

Le 18-03-06 à 09:13, posfan12 a écrit :
> scott <sco### [at] scottcom> wrote:
>>> But I'm wondering: while you cite the Preetham paper you do use
>>> different values for the A to C parameters and also for the Perez
>>> formulation.
>>
>> I took the values that the Stellarium source code used rather than the
>> paper itself, I guess the authors of Stellarium tweaked them a bit. I
>> guess you can use whichever set look better for you.
>>
>>> Also I'm wondering about the multiplication factor of 1000 for the
>>> zenith luminance. As far as I understand it this formula return the
>>> luminance in cd/m2 therefore this additional multiplication just makes
>>> the exposure factor unnecessary small.
>>
>> The formula in the paper gives the luminance in K cd/m2, that's why the
>> 1000 factor is in there.
> 
> Quick question:
> 
> How do I convert the units of ExposureFactor to my scene?
> 
> In my scene, 20 units = 1 foot.
> 
> Thanks!!
> 
> 
> Mike
> 

The formula use meter, a meter = about 39 inches, or 3 feet and 3 inches 
(3.25 feet in 1 m).
There are 10.5625 square feet in a square meter.

[posfan12] Re: Sky simulation [2953 days 18 hours and 2 minutes ago]

Tue, 6 Mar 2018 14:15:01 GMT

scott <sco### [at] scottcom> wrote:
> > But I'm wondering: while you cite the Preetham paper you do use
> > different values for the A to C parameters and also for the Perez
> > formulation.
>
> I took the values that the Stellarium source code used rather than the
> paper itself, I guess the authors of Stellarium tweaked them a bit. I
> guess you can use whichever set look better for you.
>
> > Also I'm wondering about the multiplication factor of 1000 for the
> > zenith luminance. As far as I understand it this formula return the
> > luminance in cd/m2 therefore this additional multiplication just makes
> > the exposure factor unnecessary small.
>
> The formula in the paper gives the luminance in K cd/m2, that's why the
> 1000 factor is in there.

Quick question:

How do I convert the units of ExposureFactor to my scene?

In my scene, 20 units = 1 foot.

Thanks!!


Mike

[Alain] Re: for Sven Littkowski - Algorithmus Wanted [2956 days 11 hours and 33 minutes ago]

Sat, 3 Mar 2018 20:43:19 GMT

Le 18-03-01 à 03:15, Thomas de Groot a écrit :
> On 28-2-2018 15:37, Norbert Kern wrote:
>> Here is a new version - using splines genereted with the help of 
>> vturbulence...
>> For rendering you have to get a hdr file from here:
>> https://www.openfootage.net/hdri-360-cres-croatia/
>>
>> Norbert
>>
> 
> Interesting.
> 
> Note: a lot of warnings generated in transforms.inc (line 39: scale by 
> 0.0 in matrix column; and 187: normalizing zero-length vector) and 
> math.inc (lines243 and 275: normalizing zero-length vector). Some way to 
> avoid that? I do not see where those are generated.
> 

For the scale by zero, they come from constructs like scale Value*x.
When that appen, Value*x get promoted to <Value,0,0> generating two 
warnings because scale 0 is not allowed.
You need to edit the file to replace all scale Value*x by 
scale<Value,1,1>, all scale Value*y by scale <1,Value,1> and scale 
Value*z by scale<1,1,Value>

For the problem with math.inc, make sure that you don't pass nor 
generate any null vector.
A nul or zero-length vector don't have any direction and can't be 
normalised to an unit length vector.
You may try adding this:
#if(vlength(Vector)=0) #declare vector=<1,0,0>; #end

Alain

[Norbert Kern] Diamanted finish on metallic surface [2957 days 10 hours and 37 minutes ago]

Fri, 2 Mar 2018 21:40:01 GMT

see this thread in pbi with the same name -
http://news.povray.org/povray.binaries.images/thread/%3C5a995021%241%40news.povray.org%3E/
..

Here is an approach for such a material...

Norbert

[Thomas de Groot] Re: for Sven Littkowski - Algorithmus Wanted [2958 days 20 hours and 7 minutes ago]

Thu, 1 Mar 2018 12:09:53 GMT

On 1-3-2018 11:24, Norbert Kern wrote:
> "Norbert Kern" <nor### [at] t-onlinede> wrote:
> 
>> I think this is because he used an arbitrarily defined step factor in this line:
>> #local Length = Length+vlength (Point-(Last*1.0003));
>>
>> If you change 1.0003 to 1.00003, you avoid the matrix column warnings too.
> 
> 
> Command back - ABX didn't introduce this factor. I used his code once many years
> before and I forgot this little annoying thing.
> In his original post he simply wrote: #local Length = Length+vlength
> (Point-Last);
> My fault.
> 
> Norbert
> 
> 

Much better. Remains the zero-length vector... I shall ponder this a bit 
more.

-- 
Thomas

[Norbert Kern] Re: for Sven Littkowski - Algorithmus Wanted [2958 days 21 hours and 52 minutes ago]

Thu, 1 Mar 2018 10:25:00 GMT

"Norbert Kern" <nor### [at] t-onlinede> wrote:

> I think this is because he used an arbitrarily defined step factor in this line:
> #local Length = Length+vlength (Point-(Last*1.0003));
>
> If you change 1.0003 to 1.00003, you avoid the matrix column warnings too.

Command back - ABX didn't introduce this factor. I used his code once many years
before and I forgot this little annoying thing.
In his original post he simply wrote: #local Length = Length+vlength
(Point-Last);
My fault.

Norbert

[Norbert Kern] Re: for Sven Littkowski - Algorithmus Wanted [2958 days 22 hours and 7 minutes ago]

Thu, 1 Mar 2018 10:10:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Interesting.
>
> Note: a lot of warnings generated in transforms.inc (line 39: scale by
> 0.0 in matrix column; and 187: normalizing zero-length vector) and
> math.inc (lines243 and 275: normalizing zero-length vector). Some way to
> avoid that? I do not see where those are generated.

ABX used a variable called Accuracy in his Time_To_Lenght_Converter macro.
If you rise its value from 0.001 to 0.01 you get only one warning per spline and
not for every defined point.

I think this is because he used an arbitrarily defined step factor in this line:
#local Length = Length+vlength (Point-(Last*1.0003));

If you change 1.0003 to 1.00003, you avoid the matrix column warnings too.

But I really don't know why I get one zero length vector warning per spline.
My math skills...

Norbert

[Thomas de Groot] Re: for Sven Littkowski - Algorithmus Wanted [2959 days and 1 minute ago]

Thu, 1 Mar 2018 08:15:15 GMT

On 28-2-2018 15:37, Norbert Kern wrote:
> Here is a new version - using splines genereted with the help of vturbulence...
> For rendering you have to get a hdr file from here:
> https://www.openfootage.net/hdri-360-cres-croatia/
> 
> Norbert
> 

Interesting.

Note: a lot of warnings generated in transforms.inc (line 39: scale by 
0.0 in matrix column; and 187: normalizing zero-length vector) and 
math.inc (lines243 and 275: normalizing zero-length vector). Some way to 
avoid that? I do not see where those are generated.

-- 
Thomas

[Norbert Kern] Re: for Sven Littkowski - Algorithmus Wanted [2959 days 17 hours and 37 minutes ago]

Wed, 28 Feb 2018 14:40:00 GMT

Here is a new version - using splines genereted with the help of vturbulence...
For rendering you have to get a hdr file from here:
https://www.openfootage.net/hdri-360-cres-croatia/

Norbert

[Norbert Kern] Re: Algorithmus Wanted pics for animation [2964 days 16 hours and 27 minutes ago]

Fri, 23 Feb 2018 15:50:01 GMT

Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
> Big thanks, you helped me a lot! Well-appreciated!
>
> How long did it take on your computer?


About 9.5 min. on my 6 y old system (i7, 3.5 GHz, 8 threads)

Norbert

[Kenneth] Re: Algorithmus Wanted pics for animation [2964 days 22 hours and 32 minutes ago]

Fri, 23 Feb 2018 09:45:01 GMT

Nice.

What is inside those rings? It looks like 'cracked glass' ?

[Sven Littkowski] Re: Algorithmus Wanted pics for animation [2965 days 5 hours and 34 minutes ago]

Fri, 23 Feb 2018 02:42:18 GMT

Big thanks, you helped me a lot! Well-appreciated!

How long did it take on your computer?

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

[Norbert Kern] Re: Algorithmus Wanted pics for animation [2965 days 8 hours and 37 minutes ago]

Thu, 22 Feb 2018 23:40:03 GMT

here are the last 50 images.

have fun,
Norbert

[Norbert Kern] Algorithmus Wanted pics for animation [2965 days 8 hours and 47 minutes ago]

Thu, 22 Feb 2018 23:30:03 GMT

here are the first 50 images.

[Norbert Kern] for Sven Littkowski - Algorithmus Wanted [2967 days 12 hours and 7 minutes ago]

Tue, 20 Feb 2018 20:10:00 GMT

Here is an example for getting equidistant objects via splines.
Original source (ABX) is included.

Norbert

[Norbert Kern] creepy figures [2976 days 15 hours and 26 minutes ago]

Sun, 11 Feb 2018 16:50:07 GMT

Here is a test file for the thread in pbi
(http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a7f6d04f7f763caf8cfcbc0%40news.povray.org%3E/).


Norbert

[Mike Horvath] Re: Extension of screen.inc for orthographic cam... [2988 days 11 hours and 20 minutes ago]

Tue, 30 Jan 2018 20:56:11 GMT

There's some additional discussion and examples in this thread:

http://news.povray.org/povray.binaries.scene-files/thread/%3C590b15de%40news.povray.org%3E/


Mike

[Mike Horvath] Re: Extension of screen.inc for orthographic cam... [2988 days 11 hours and 23 minutes ago]

Tue, 30 Jan 2018 20:53:40 GMT

On 1/30/2018 3:50 PM, Mike Horvath wrote:
> Hi guys!
> 
> Note that the latest version of my screen.inc is located at my web page.
> 
>      http://isometricland.net/povray/povray.php
> 
> The main alteration IIRC is that
> 
>      Set_Camera(<+25,+15,-33,>, <+2,+2,+0,>, 060, on)
> 
> was changed to
> 
>      Set_Camera(<+25,+15,-33,>, <+2,+2,+0,>, 060)
>      Set_Camera_Orthographic(on)
> 
> This was in order to make the script backwards compatible with the 
> original screen.inc that is bundled with POV-Ray.
> 
> 
> Mike

I've attached the script and demo scene.


Mike

[Mike Horvath] Re: Extension of screen.inc for orthographic cam... [2988 days 11 hours and 26 minutes ago]

Tue, 30 Jan 2018 20:50:16 GMT

Hi guys!

Note that the latest version of my screen.inc is located at my web page.

     http://isometricland.net/povray/povray.php

The main alteration IIRC is that

     Set_Camera(<+25,+15,-33,>, <+2,+2,+0,>, 060, on)

was changed to

     Set_Camera(<+25,+15,-33,>, <+2,+2,+0,>, 060)
     Set_Camera_Orthographic(on)

This was in order to make the script backwards compatible with the 
original screen.inc that is bundled with POV-Ray.


Mike

[Alain] Re: Saturn [2993 days 4 hours and 8 minutes ago]

Fri, 26 Jan 2018 04:08:23 GMT

Le 18-01-25 à 16:53, HENON fabien a écrit :
> Paolo Gibellini <p.g### [at] gmailcom> wrote:
>> HENON fabien wrote on 22/01/2018 23:19:
>>> Newsgroups : povray.binaries.images
>>>
>>>
>>>
>> Interesting scenes. Saturn and Lamp are without sources.
>> Thank you,
>>     Paolo
> 
> 
> That's fixed
> Thank you Paolo
> 
Still missing for saturn.

[HENON fabien] Re: Lampe scene [2993 days 10 hours and 22 minutes ago]

Thu, 25 Jan 2018 21:55:01 GMT

"HENON fabien" <fab### [at] caramailcom> wrote:
> Newsgroups : povray.binaries.images

[HENON fabien] Re: Saturn [2993 days 10 hours and 22 minutes ago]

Thu, 25 Jan 2018 21:55:00 GMT

Paolo Gibellini <p.g### [at] gmailcom> wrote:
> HENON fabien wrote on 22/01/2018 23:19:
> > Newsgroups : povray.binaries.images
> >
> >
> >
> Interesting scenes. Saturn and Lamp are without sources.
> Thank you,
>    Paolo


That's fixed
Thank you Paolo

[Paolo Gibellini] Re: Saturn [2994 days 18 hours and 49 minutes ago]

Wed, 24 Jan 2018 13:27:32 GMT

HENON fabien wrote on 22/01/2018 23:19:
> Newsgroups : povray.binaries.images
> 
> 
> 
Interesting scenes. Saturn and Lamp are without sources.
Thank you,
   Paolo

[clipka] Re: Lighter scene [2995 days 11 hours and 47 minutes ago]

Tue, 23 Jan 2018 20:29:52 GMT

Am 22.01.2018 um 23:09 schrieb HENON fabien:
> Check Newsgroups : povray.binaries.images

Thanks a lot for sharing these old scenes!

[HENON fabien] Saturn [2996 days 9 hours and 52 minutes ago]

Mon, 22 Jan 2018 22:25:01 GMT

Newsgroups : povray.binaries.images

[HENON fabien] SAP Drug [2996 days 9 hours and 57 minutes ago]

Mon, 22 Jan 2018 22:20:02 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Watch scene - Awesome Rolex :) [2996 days 9 hours and 57 minutes ago]

Mon, 22 Jan 2018 22:20:02 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Microscope scene [2996 days 9 hours and 57 minutes ago]

Mon, 22 Jan 2018 22:20:01 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Lampe scene [2996 days 10 hours and 2 minutes ago]

Mon, 22 Jan 2018 22:15:04 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Cheating dice [2996 days 10 hours and 2 minutes ago]

Mon, 22 Jan 2018 22:15:03 GMT

Newsgroups : povray.binaries.images

[HENON fabien] cup scene [2996 days 10 hours and 2 minutes ago]

Mon, 22 Jan 2018 22:15:03 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Flying boats [2996 days 10 hours and 2 minutes ago]

Mon, 22 Jan 2018 22:15:01 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Compass [2996 days 10 hours and 2 minutes ago]

Mon, 22 Jan 2018 22:15:01 GMT

Newsgroups : povray.binaries.images

[HENON fabien] Lighter scene [2996 days 10 hours and 7 minutes ago]

Mon, 22 Jan 2018 22:10:01 GMT

Check Newsgroups : povray.binaries.images

[And] subsurface cloud(like snow) [3053 days 20 hours and 42 minutes ago]

Sun, 26 Nov 2017 11:35:01 GMT

The file:

[cbpypov] Re: New version screen.inc [3070 days 14 hours and 41 minutes ago]

Thu, 9 Nov 2017 17:35:05 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > "cbpypov" <nomail@nomail> wrote:
>
> >
> > 'Camera tracking' is very interesting to me; years ago, I modified Rune's
> > 'Illusion Inc' POV-Ray include file in order to match POV-Ray animation to video
> > (from my Sony camera). Unfortunately, the resulting animations (and the scene
> > files) are on a hard disk that failed-- which I hope to 'resurrect' at some
> > point.
> >
>
> I just remembered that I posted one of the animations to the newsgroups, years
> ago. (It was an old-style .AVI file, compressed using the 'Xvid'
> codec/compressor, so I don't know if will play on all machines.) Here's the
> link...
>
>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.52fd51fbee845476c2d977c20%40news.povray.org%3E/?ttop=
41
> 5656&toff=50

Hey Kenneth,

sorry for the delay! I now had the time to play back your video ... I was
surprised by the quality! Somehow it's stunning, taking into account that it is
made with mostly open source code and rather simple techniques.

I think there might be quite a number of code out there which could help you
with the tracking. At least any semi-professional video software nowadays has a
feature like that on board (you know, to stick text to the nose of someone or
similar things). Have you already taken such things into account? A quick look
at Google gave me this possibility in python:

    https://www.pyimagesearch.com/2015/09/14/ball-tracking-with-opencv/

But I am sure you'll find something in the language of your choice.

Still, I do not understand the role of screen.inc in this context :)

[clipka] Re: New version screen.inc [3072 days 17 hours and 11 minutes ago]

Tue, 7 Nov 2017 15:05:51 GMT

Am 07.11.2017 um 14:46 schrieb jr:

> also true, but not the point.  including an ISO date/time in the file
> name to "float" it to the top requires reversing the sort order to get
> descending dates (that's all I wrote).

Ah, sorry, misunderstanding on my part.

Yes, you can do that in Windows Explorer and Open File dialogs, too.
Presuming you're using the detailed view, it's just a matter of clicking
on the column header once more. Alternatively, there's a "view" menu
where you can pick the property to sort by and whether to do so in
ascending or descending order.

[jr] Re: New version screen.inc [3072 days 18 hours and 29 minutes ago]

Tue, 7 Nov 2017 13:47:06 GMT

hi,

On 07/11/2017 10:26, clipka wrote:
> Am 07.11.2017 um 09:05 schrieb jr:
>> On 06/11/2017 21:10, Bald Eagle wrote:
>>> True, I know the version AND date are redundant - I was just thinking about
>>> looking through a directory, and having the date "float" the filename to the
>>> top.   ...
>> not sure about Windows but if you want to have the most recent files
>> shown first, using the 'ls' command you'd need to use an option switch
>> to make it sort in reverse order.
> Nice idea, but there's a catch: All it can sort by is file creation or
> last modification time. ...

and last access, ie 'ls -lt' or 'ls -ltc' vs 'ls -ltu'.

> ... Which may happen to be the same as the time the
> file was originally conceived by the author, but it may just as well be
> something entirely different, depending on the toolchain that eventually
> placed it on your file system.

very true.  the onus (on *NIX like machines) is on the user to be
specific in their requests.  the relevant commands (cp, scp, rsync) all
require an explicit '-a' (archive) or '-p' (preserve) option to keep
dates and permissions straight.  (not a problem though since the BASH
provides an "alias" command, so one can forget about "not forgetting" :-))

not sure about Windows (again), whenever I save a file from an
attachment in a newsgroup, say, the date/time stamp is of the local
creation.  how do you work around this?

> Also, no operating system (well, none commonly used anyway) or file
> management tool can sort by file name first /and/ timestamp second.
> Because you can't have multiple files with the same name but different
> timestamps.

also true, but not the point.  including an ISO date/time in the file
name to "float" it to the top requires reversing the sort order to get
descending dates (that's all I wrote).

regards, jr.

[clipka] Re: New version screen.inc [3072 days 21 hours and 50 minutes ago]

Tue, 7 Nov 2017 10:26:31 GMT

Am 07.11.2017 um 09:05 schrieb jr:
> hi,
> 
> On 06/11/2017 21:10, Bald Eagle wrote:
>> True, I know the version AND date are redundant - I was just thinking about
>> looking through a directory, and having the date "float" the filename to the
>> top.   ...
> 
> not sure about Windows but if you want to have the most recent files
> shown first, using the 'ls' command you'd need to use an option switch
> to make it sort in reverse order.

Nice idea, but there's a catch: All it can sort by is file creation or
last modification time. Which may happen to be the same as the time the
file was originally conceived by the author, but it may just as well be
something entirely different, depending on the toolchain that eventually
placed it on your file system.

Also, no operating system (well, none commonly used anyway) or file
management tool can sort by file name first /and/ timestamp second.
Because you can't have multiple files with the same name but different
timestamps.

[jr] Re: New version screen.inc [3073 days and 11 minutes ago]

Tue, 7 Nov 2017 08:05:29 GMT

hi,

On 06/11/2017 21:10, Bald Eagle wrote:
> True, I know the version AND date are redundant - I was just thinking about
> looking through a directory, and having the date "float" the filename to the
> top.   ...

not sure about Windows but if you want to have the most recent files
shown first, using the 'ls' command you'd need to use an option switch
to make it sort in reverse order.

regards, jr.

[Alain] Re: Extension of screen.inc for orthographic cam... [3073 days 6 hours and 39 minutes ago]

Tue, 7 Nov 2017 01:37:25 GMT

Le 17-11-06 à 05:07, cbpypov a écrit :
> Find attached screen_ortho.inc, which extents the abilities of screen.inc in
> order to use the orthographic camera. This is related to the thread
> 
> 
>
http://news.povray.org/povray.binaries.scene-files/thread/%3C4afccd8a%241%40news.povray.org%3E/?mtop=406850
> 
> started by SharkD, who is the one that wrote almost the entire code. The
> attached version includes minor bug fixes and improved documentation.
> 
> Use
>      Set_Camera(Location, LookAt, Angle, Ortho)
> to define your camera instead of the traditional `camera { ... }`. The `Ortho`
> parameter accepts `On` or `Off` and gives the expected results. Use e.g.
> `Screen_Object` to add logos, watermarks, subtitles or any other object which is
> meant to stay fixed in front of the camera. (Validated to work with animations.)
> 
> Best,
> Carlo
> 

Now, make a version that will also work with cylindrical (all 4 
varieties), spherical, fisheye, omnimax, panoramic, and ultrawhide_angle 
cameras...

[Kenneth] Re: New version screen.inc [3073 days 10 hours and 12 minutes ago]

Mon, 6 Nov 2017 22:05:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "cbpypov" <nomail@nomail> wrote:

>
> 'Camera tracking' is very interesting to me; years ago, I modified Rune's
> 'Illusion Inc' POV-Ray include file in order to match POV-Ray animation to video
> (from my Sony camera). Unfortunately, the resulting animations (and the scene
> files) are on a hard disk that failed-- which I hope to 'resurrect' at some
> point.
>

I just remembered that I posted one of the animations to the newsgroups, years
ago. (It was an old-style .AVI file, compressed using the 'Xvid'
codec/compressor, so I don't know if will play on all machines.) Here's the
link...

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.52fd51fbee845476c2d977c20%40news.povray.org%3E/?ttop=41
5656&toff=50

[Kenneth] Re: New version screen.inc [3073 days 10 hours and 22 minutes ago]

Mon, 6 Nov 2017 21:55:00 GMT

"cbpypov" <nomail@nomail> wrote:

> ... I hope this does not sound arrogant in any way (sometimes
> its difficult to weigh such fragile phrases in a language which is foreign to
> me; but at least it is not meant to sound arrogant in any way :) ) ... but it is
> maybe because I am a physicist that this seems somehow natural to me.

No need to worry; your command of English is quite good!

'Camera tracking' is very interesting to me; years ago, I modified Rune's
'Illusion Inc' POV-Ray include file in order to match POV-Ray animation to video
(from my Sony camera). Unfortunately, the resulting animations (and the scene
files) are on a hard disk that failed-- which I hope to 'resurrect' at some
point.

Last night, I came across an interesting BBC news item, about Microsoft's
experiments with real-time camera-tracking and 'augmented reality.' It's really
fascinating...

http://www.bbc.com/news/av/technology-41747005/inside-microsoft-s-new-mixed-reality-capture-studio

[Bald Eagle] Re: New version screen.inc [3073 days 11 hours and 2 minutes ago]

Mon, 6 Nov 2017 21:15:00 GMT

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

> if the file is to be useful on platforms other than Windows, a file name
> without parentheses would be better, and the version number would
> presumably be specific to a given release date, so
.....

True, I know the version AND date are redundant - I was just thinking about
looking through a directory, and having the date "float" the filename to the
top.   But I suppose if they're sorted by date anyway...

I was just ruminating, and figured people would format their revisions however
they wanted anyway.   The key point was to vary the filename so all the
different revisions were differentiable.

[jr] Re: New version screen.inc [3073 days 12 hours and 6 minutes ago]

Mon, 6 Nov 2017 20:10:27 GMT

hi,

On 06/11/2017 17:42, Bald Eagle wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> When dates are to be sorted alphabetically, ISO format works best (YMD;
>> more precisely, YYYY-MM-DD).
> Ah.  I mistakenly thought "European format" was the ISO format.
> YYYY-MM-DD_(2.0.0)_Screen.inc
> might be a good format,> or maybe, since one is likely to search for screen*.inc,
then perhaps
> Screen_YYYY-MM-DD_(2.0.0)_.inc

if the file is to be useful on platforms other than Windows, a file name
without parentheses would be better, and the version number would
presumably be specific to a given release date, so

  screen-2.0.0.inc

would suffice, or, with a date instead

  screen-20171106.inc


regards, jr.

[cbpypov] Re: New version screen.inc [3073 days 12 hours and 27 minutes ago]

Mon, 6 Nov 2017 19:50:00 GMT

To all,

oh, I am so sorry I did not see all your replies ... I posted the file at

http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5a00344aecd2fa6f80db62550%40news.povray.org%3E/

and thought you might respond there. Now when I saw there is still no post of
anyone, I came back here and couldn't believe my eyes :D

So, to catch up a bit, thanks for all those nice words! It's a pleasure to help
with this minimum contribution, ... especially after I received so much of your
help. Since I will use this code now for a larger scene I'll see if I notice any
further bugs. Til now it is working out well.

I'm sorry that I, for the above reasons, missed some of your ideas of how to
format the file/filename. May I post it again with these corrections?

I'll post the final animation when it's done. But it may take time because I'll
do this after I handed in my dissertation (at 2017-11-30 [ISO-format :D]).

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
> animation with a moving camera is still just a series of discrete static images
> strung together, each with its own 'static' camera position for that frame-- and
> the code does work successfully on individual images with a 'static' camera
> (which is the *only* camera position being rendered at the moment.) So the code
> apparently doesn't need to know or even care about where the *camera* will be
> for the next frame.
>
> I need to take a closer look at your code and try it out; I didn't realize that
> it's camera-agnostic.
>
> Thanks for nudging me to think more clearly about this ;-)

Hey Kenneth,

I did not expect to receive this from you and especially not to make you really
think on this :D ... I hope this does not sound arrogant in any way (sometimes
its difficult to weigh such fragile phrases in a language which is foreign to
me; but at least it is not meant to sound arrogant in any way :) ) ... but it is
maybe because I am a physicist that this seems somehow natural to me. [<- this
sentence is far to long]. However, the way in which you reformulated what I said
appears just correct to me. I did not see anything in POV-Ray that could
distinguish between a `static` and an `animated` render. So POV-Ray itself is
agnostic for that in the first place. It follows that SharkD's code could only
deviate from this fact if it made any "assumption" on a -- say -- default camera
position. Which it does not :) --- q.e.d. :D

Best,
Carlo

[Bald Eagle] Re: New version screen.inc [3073 days 14 hours and 32 minutes ago]

Mon, 6 Nov 2017 17:45:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> Most European countries traditionally use DMY ordering for dates, which
> isn't any better for sorting than US format; the European format is just
> more self-consistent.
>
> When dates are to be sorted alphabetically, ISO format works best (YMD;
> more precisely, YYYY-MM-DD).

Ah.  I mistakenly thought "European format" was the ISO format.

YYYY-MM-DD_(2.0.0)_Screen.inc

might be a good format,

or maybe, since one is likely to search for screen*.inc, then perhaps

Screen_YYYY-MM-DD_(2.0.0)_.inc

[clipka] Re: New version screen.inc [3073 days 15 hours and 2 minutes ago]

Mon, 6 Nov 2017 17:15:00 GMT

Am 06.11.2017 um 15:35 schrieb Bald Eagle:

> Optionally, or in addition to that, include the date of the revision first, in
> European format - so that it's easily sorted and the latest revision "rises to
> the top".

Most European countries traditionally use DMY ordering for dates, which
isn't any better for sorting than US format; the European format is just
more self-consistent.

When dates are to be sorted alphabetically, ISO format works best (YMD;
more precisely, YYYY-MM-DD).

[Bald Eagle] Re: New version screen.inc [3073 days 16 hours and 57 minutes ago]

Mon, 6 Nov 2017 15:20:00 GMT

"cbpypov" <nomail@nomail> wrote:

> Here are some more fixes (attached). The scaling of Screen_Object was broken for
> ortho-cam.

Carlo,

Thanks very much for looking through the screen.inc code and finding those
problems and fixing them.

I think I had noticed some anomalies when I was working out the visible camera
view frustum

http://news.povray.org/povray.binaries.images/thread/%3Cweb.587ce3fc782d1af2c437ac910%40news.povray.org%3E/?mtop=415328

but I never got around to pursuing and identifying any bugs that might have been
in there.

We're always very appreciative of anyone who can make improvements and fixes to
the collection of tools that we have   :)

I hope the first few frames of your animation are coming out well, and the final
result makes a big impression!

[Bald Eagle] Re: New version screen.inc [3073 days 17 hours and 37 minutes ago]

Mon, 6 Nov 2017 14:40:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> For completeness sake I would suggest to add a comment line at the top,
> stating the different changes to the original screen.inc ....

And while you're at it, maybe make a note of a version number, and save the file
with that version number as a suffix or part of the filename after and
underscore or something - so that upon downloading into a directory, it's easily
distinguishable from the other 9 "screen.inc" files I have saved over the years.
Optionally, or in addition to that, include the date of the revision first, in
European format - so that it's easily sorted and the latest revision "rises to
the top".

:)

[Stephen] Re: New version screen.inc [3073 days 19 hours and 44 minutes ago]

Mon, 6 Nov 2017 12:32:43 GMT

On 06/11/2017 11:34, Kenneth wrote:
> "cbpypov" <nomail@nomail> wrote:
> 
>>
>> Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
>> small fixes SharkD's code works perfectly for me and it does just fine in
>> keeping e.g. text fixed in front of the camera while moving it. But somehow, I
>> do not see your point: (1) in a single POV-Ray render the camera is always
>> static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
>> position, so how should it *know* where the camera is? Since it is agnostic, it
>> _must_ work in an animation, too ... did I miss something?
> 
> Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
> animation with a moving camera is still just a series of discrete static images
> strung together, each with its own 'static' camera position for that frame-- and
> the code does work successfully on individual images with a 'static' camera
> (which is the *only* camera position being rendered at the moment.) So the code
> apparently doesn't need to know or even care about where the *camera* will be
> for the next frame.
> 

Going from memory. You are right. The parameters for the macro are 
calculated each frame.

StephenS devised a method to return them in Bishop3D. So they could be 
used in additional code.


-- 

Regards
     Stephen

[Kenneth] Re: New version screen.inc [3073 days 20 hours and 37 minutes ago]

Mon, 6 Nov 2017 11:40:00 GMT

"cbpypov" <nomail@nomail> wrote:

>
> Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
> small fixes SharkD's code works perfectly for me and it does just fine in
> keeping e.g. text fixed in front of the camera while moving it. But somehow, I
> do not see your point: (1) in a single POV-Ray render the camera is always
> static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
> position, so how should it *know* where the camera is? Since it is agnostic, it
> _must_ work in an animation, too ... did I miss something?

Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
animation with a moving camera is still just a series of discrete static images
strung together, each with its own 'static' camera position for that frame-- and
the code does work successfully on individual images with a 'static' camera
(which is the *only* camera position being rendered at the moment.) So the code
apparently doesn't need to know or even care about where the *camera* will be
for the next frame.

I need to take a closer look at your code and try it out; I didn't realize that
it's camera-agnostic.

Thanks for nudging me to think more clearly about this ;-)

[cbpypov] Extension of screen.inc for orthographic cameras [3073 days 22 hours and 7 minutes ago]

Mon, 6 Nov 2017 10:10:01 GMT

Find attached screen_ortho.inc, which extents the abilities of screen.inc in
order to use the orthographic camera. This is related to the thread


http://news.povray.org/povray.binaries.scene-files/thread/%3C4afccd8a%241%40news.povray.org%3E/?mtop=406850

started by SharkD, who is the one that wrote almost the entire code. The
attached version includes minor bug fixes and improved documentation.

Use
    Set_Camera(Location, LookAt, Angle, Ortho)
to define your camera instead of the traditional `camera { ... }`. The `Ortho`
parameter accepts `On` or `Off` and gives the expected results. Use e.g.
`Screen_Object` to add logos, watermarks, subtitles or any other object which is
meant to stay fixed in front of the camera. (Validated to work with animations.)

Best,
Carlo

[Stephen] Re: New version screen.inc [3073 days 23 hours and 32 minutes ago]

Mon, 6 Nov 2017 08:44:46 GMT

On 06/11/2017 08:03, Thomas de Groot wrote:
> On 5-11-2017 22:32, cbpypov wrote:
>> Stephen <mca### [at] aolcom> wrote:
>>>
>>> I would have to walk back almost 50 years to my last trig class.
>>>
>>
>> I see :) But in the end it wasn't as hard as expected...
>>
>> Here are some more fixes (attached). The scaling of Screen_Object was 
>> broken for
>> ortho-cam.
>>
>> Best,
>> Carlo
>>
> 
> Good work!
> 

Yes good work.


> For completeness sake I would suggest to add a comment line at the top, 
> stating the different changes to the original screen.inc made by SharkD 
> (with the tinkerer's name, date, and where to find eventual discussions 
> of the issues, where possible) and those made by yourself. Future 
> generations will thank you for that :-)
> 

And to add to what Thomas said. It might be a good idea to put it in its 
own thread. So it doesn't get lost in the depths of this one.


-- 

Regards
     Stephen

[Thomas de Groot] Re: New version screen.inc [3074 days and 13 minutes ago]

Mon, 6 Nov 2017 08:03:28 GMT

On 5-11-2017 22:32, cbpypov wrote:
> Stephen <mca### [at] aolcom> wrote:
>>
>> I would have to walk back almost 50 years to my last trig class.
>>
> 
> I see :) But in the end it wasn't as hard as expected...
> 
> Here are some more fixes (attached). The scaling of Screen_Object was broken for
> ortho-cam.
> 
> Best,
> Carlo
> 

Good work!

For completeness sake I would suggest to add a comment line at the top, 
stating the different changes to the original screen.inc made by SharkD 
(with the tinkerer's name, date, and where to find eventual discussions 
of the issues, where possible) and those made by yourself. Future 
generations will thank you for that :-)

-- 
Thomas

[cbpypov] Re: New version screen.inc [3074 days 10 hours and 42 minutes ago]

Sun, 5 Nov 2017 21:35:01 GMT

Stephen <mca### [at] aolcom> wrote:
>
> I would have to walk back almost 50 years to my last trig class.
>

I see :) But in the end it wasn't as hard as expected...

Here are some more fixes (attached). The scaling of Screen_Object was broken for
ortho-cam.

Best,
Carlo

[Stephen] Re: New version screen.inc [3074 days 11 hours and 10 minutes ago]

Sun, 5 Nov 2017 21:06:05 GMT

On 05/11/2017 18:07, cbpypov wrote:
> Stephen <mca### [at] aolcom> wrote:
>>
>> Hands up for posting without validating. :-(
>>
> 
> Sorry, I cannot really follow what you mean ... did I do something wrong? :(
> 

What I meant was that I posted without checking that it was correct.

>>
>> You are right. I imported a couple of the scenes into Bishop3D, to get a
>> visual representation of the cameras.
>> Adjusting the Up and Right Vectors of the orthogonal camera until the
>> "look at" areas coincided. The angle I read back was 66.67. Substituting
>> that into  minimal_ortho_screen.pov it was out by a factor of 2. an
>> angle of 66.67/2 gave me a very similar image to minimal_perspective.pov
>>
>>
>> I conclude that there is something not right with the way that
>> screen_ortho.inc converts angle into the the other vectors.
>>
>> Finding what is beyond me.I would be still at it when the cows came home.
>>
> 
> Glad we're talking about the same things now :) Cool that you can do such things
> with Bishop3D! I may have a look at what it is capable of.
> 

It is free and a bit limited. But it has its usages. I am sure Blender 
would be just as useful.

> However, maybe it was not really beyond you. 

I would have to walk back almost 50 years to my last trig class.




-- 

Regards
     Stephen

[cbpypov] Re: New version screen.inc [3074 days 12 hours and 17 minutes ago]

Sun, 5 Nov 2017 20:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> That Particle Illusion animation looks VERY good (I haven't gotten around to
> trying  out that particular Rune(?) code yet, though.) It makes me wonder if
> SharkD's original Get_Screen_XY macro (or any of its subsequent updates or
> fixes) can successfully track an object with the camera actually moving around--
> or maybe with just pan and tilt. (The animation example is with a fixed camera;
> and SharkD didn't specifically mention camera motion.)  I haven't yet tried out
> the macro or looked at his various code updates-- which apparently still have
> some problems, it seems-- but *if* it could, it would make a really nice
> camera-tracking package. Well, at least for tracking an animated moving-camera
> POV-Ray rendered scene.
>

Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
small fixes SharkD's code works perfectly for me and it does just fine in
keeping e.g. text fixed in front of the camera while moving it. But somehow, I
do not see your point: (1) in a single POV-Ray render the camera is always
static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
position, so how should it *know* where the camera is? Since it is agnostic, it
_must_ work in an animation, too ... did I miss something?

[Kenneth] Re: New version screen.inc [3074 days 12 hours and 42 minutes ago]

Sun, 5 Nov 2017 19:35:01 GMT

from SharkD originally...
> > Update:

> > ...Also includes a new macro called
> > "Get_Screen_XY" to return the 2D screen location of a set of 3D coordinates.

Captain Jack replied in 2009...
> Cool... I hadn't read through the Get_Screen_XY macro yet, but I did write a
> scene to test it, which I've attached. The macro worked exactly as expected,
> with no errors. The animation itself is of a group of three balls connected
> by springs that float around the screen. I had the program create a text
> file giving the screen coordinates for the center of one of the spheres in a
> format that can be read by Particle Illusion. I Rendered the scene in POV,
> then I imported the text file into PI, then composited the whole thing over
> a background picture, and everything lined up exactly right with no error
> message generated at any point.

That Particle Illusion animation looks VERY good (I haven't gotten around to
trying  out that particular Rune(?) code yet, though.) It makes me wonder if
SharkD's original Get_Screen_XY macro (or any of its subsequent updates or
fixes) can successfully track an object with the camera actually moving around--
or maybe with just pan and tilt. (The animation example is with a fixed camera;
and SharkD didn't specifically mention camera motion.)  I haven't yet tried out
the macro or looked at his various code updates-- which apparently still have
some problems, it seems-- but *if* it could, it would make a really nice
camera-tracking package. Well, at least for tracking an animated moving-camera
POV-Ray rendered scene.

[cbpypov] Re: New version screen.inc [3074 days 12 hours and 47 minutes ago]

Sun, 5 Nov 2017 19:30:00 GMT

"cbpypov" <nomail@nomail> wrote:
>
> JUST A SHORT question beyond that... using the screen.inc camera setting method
> it seems that I cannot rotate the camera anymore, but need to use the sky-vector
> instead. How do I do this? :)

Found it myself :) I have to use vaxis_rotate on the camera location instead of
the sky vector. In my case I have to rotate around the y axis by the desired
degrees.

So it seems that everything is working now for me...

[cbpypov] Re: New version screen.inc [3074 days 14 hours and 7 minutes ago]

Sun, 5 Nov 2017 18:10:01 GMT

Stephen <mca### [at] aolcom> wrote:
>
> Hands up for posting without validating. :-(
>

Sorry, I cannot really follow what you mean ... did I do something wrong? :(

>
> You are right. I imported a couple of the scenes into Bishop3D, to get a
> visual representation of the cameras.
> Adjusting the Up and Right Vectors of the orthogonal camera until the
> "look at" areas coincided. The angle I read back was 66.67. Substituting
> that into  minimal_ortho_screen.pov it was out by a factor of 2. an
> angle of 66.67/2 gave me a very similar image to minimal_perspective.pov
>
>
> I conclude that there is something not right with the way that
> screen_ortho.inc converts angle into the the other vectors.
>
> Finding what is beyond me.I would be still at it when the cows came home.
>

Glad we're talking about the same things now :) Cool that you can do such things
with Bishop3D! I may have a look at what it is capable of.

However, maybe it was not really beyond you. I just had a look at SharkD's code,
and (again without actually thinking very much) I just found two little bugs.
There was just a factor of 2 missing here and there :D It now works in gives
exactly the results without the screen.inc. Hope you like it :)

JUST A SHORT question beyond that... using the screen.inc camera setting method
it seems that I cannot rotate the camera anymore, but need to use the sky-vector
instead. How do I do this? :)

Thanks for your help.
Best,
Carlo

[Stephen] Re: New version screen.inc [3074 days 18 hours and 44 minutes ago]

Sun, 5 Nov 2017 13:32:33 GMT

On 05/11/2017 09:09, Stephen wrote:
> Reposting this so I can pick it up in thunderbird.
> 
> (It came through the first time blank.)
> 
> 
> "cbpypov" <nomail@nomail> wrote:
>> Stephen <mca### [at] aolcom> wrote:
>>
>>>
>>> Oops! I forgot the beginnings of this thread.
>>> That's what he said in the first post. But the third one with an
>>> attachment still says:
>>>
>>>> // You can only use screen.inc with the perspective camera. Screen.inc
>>>> // will automatically create the camera definition for you when it is
>>>> // included.
>>>
>>
>> No need to remember it: it's there, online, you can read it again ;) But I think
>> you copied these lines from its screen.inc attachment. BUT, these lines are
>> there because SharkD copied them from the original screen.inc and frogot to
>> delete them :D Maybe it's me: but I am sure this thread would not be here if
>> SharkD did not have tried to get ortho-cam to work. Moreover, his
>> reimplementation of Set_Camera would not have a new `orth` parameter:
>>
>>      #macro Set_Camera(Location, LookAt, Angle, Ortho)
>>
>> Right?
>>

Hands up for posting without validating. :-(


>> So, ... we are a bit at cross-purposes, i think. I attached examples of a
>> minimal scene. minimal_perspective.pov uses the normal camera, and using
>> screen.inc (minimal_screen.pov) gives identical results. When setting the
>> ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
>> However, when using SharkD's screen.inc and setting `ortho=on`), the result is
>> way different (minimal_ortho_screen.pov). I think this is not how it is supposed
>> to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
>> identical, but they are not.
>>

You are right. I imported a couple of the scenes into Bishop3D, to get a 
visual representation of the cameras.
Adjusting the Up and Right Vectors of the orthogonal camera until the 
"look at" areas coincided. The angle I read back was 66.67. Substituting 
that into  minimal_ortho_screen.pov it was out by a factor of 2. an 
angle of 66.67/2 gave me a very similar image to minimal_perspective.pov


I conclude that there is something not right with the way that 
screen_ortho.inc converts angle into the the other vectors.

Finding what is beyond me.I would be still at it when the cows came home.



>>>
>>> There will be a tangent in there some way.
>>>
>>>
https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
>>>
>>> All those hard quantum sums, eh? ;-)
>>>
>>
>> I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
>> still wrong :/
>>

I had a quick look at it and it is beyond me. I'm afraid.



-- 

Regards
     Stephen

[Stephen] Re: New version screen.inc [3074 days 23 hours and 7 minutes ago]

Sun, 5 Nov 2017 09:10:00 GMT

Reposting this so I can pick it up in thunderbird.

(It came through the first time blank.)


"cbpypov" <nomail@nomail> wrote:
> Stephen <mca### [at] aolcom> wrote:
>
> >
> > Oops! I forgot the beginnings of this thread.
> > That's what he said in the first post. But the third one with an
> > attachment still says:
> >
> > > // You can only use screen.inc with the perspective camera. Screen.inc
> > > // will automatically create the camera definition for you when it is
> > > // included.
> >
>
> No need to remember it: it's there, online, you can read it again ;) But I think
> you copied these lines from its screen.inc attachment. BUT, these lines are
> there because SharkD copied them from the original screen.inc and frogot to
> delete them :D Maybe it's me: but I am sure this thread would not be here if
> SharkD did not have tried to get ortho-cam to work. Moreover, his
> reimplementation of Set_Camera would not have a new `orth` parameter:
>
>     #macro Set_Camera(Location, LookAt, Angle, Ortho)
>
> Right?
>
> So, ... we are a bit at cross-purposes, i think. I attached examples of a
> minimal scene. minimal_perspective.pov uses the normal camera, and using
> screen.inc (minimal_screen.pov) gives identical results. When setting the
> ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
> However, when using SharkD's screen.inc and setting `ortho=on`), the result is
> way different (minimal_ortho_screen.pov). I think this is not how it is supposed
> to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
> identical, but they are not.
>
> >
> > There will be a tangent in there some way.
> >
> >
https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
> >
> > All those hard quantum sums, eh? ;-)
> >
>
> I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
> still wrong :/
>
> Does anyone see a fix for SharkD's approach? Or do you see where my mistake in
> the fake version is?
>
> Thanks :)

[cbpypov] Re: New version screen.inc [3075 days 10 hours and 27 minutes ago]

Sat, 4 Nov 2017 21:50:00 GMT

Stephen <mca### [at] aolcom> wrote:

>
> Oops! I forgot the beginnings of this thread.
> That's what he said in the first post. But the third one with an
> attachment still says:
>
> > // You can only use screen.inc with the perspective camera. Screen.inc
> > // will automatically create the camera definition for you when it is
> > // included.
>

No need to remember it: it's there, online, you can read it again ;) But I think
you copied these lines from its screen.inc attachment. BUT, these lines are
there because SharkD copied them from the original screen.inc and frogot to
delete them :D Maybe it's me: but I am sure this thread would not be here if
SharkD did not have tried to get ortho-cam to work. Moreover, his
reimplementation of Set_Camera would not have a new `orth` parameter:

    #macro Set_Camera(Location, LookAt, Angle, Ortho)

Right?

So, ... we are a bit at cross-purposes, i think. I attached examples of a
minimal scene. minimal_perspective.pov uses the normal camera, and using
screen.inc (minimal_screen.pov) gives identical results. When setting the
ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
However, when using SharkD's screen.inc and setting `ortho=on`), the result is
way different (minimal_ortho_screen.pov). I think this is not how it is supposed
to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
identical, but they are not.

>
> There will be a tangent in there some way.
>
> https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
>
> All those hard quantum sums, eh? ;-)
>

I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
still wrong :/

Does anyone see a fix for SharkD's approach? Or do you see where my mistake in
the fake version is?

Thanks :)

[Stephen] Re: New version screen.inc [3075 days 12 hours and 20 minutes ago]

Sat, 4 Nov 2017 19:56:44 GMT

On 04/11/2017 19:19, cbpypov wrote:
>>
>> You are right. You can only use screen.inc with the perspective camera.
>>
>>
>> Fake it. Move the camera further away and reduce the angle.
>>
>>
>> --
>>
>> Regards
>>       Stephen
> 
> 
> Wasn't it just the objective of SharkD's file to actually make screen.inc
> compatible with the orthographic camera? I.e. the issue of this thread?? A few
> posts before some people state that it behaves as expected, but I can't seem to
> get it to work.
> 

Oops! I forgot the beginnings of this thread.
That's what he said in the first post. But the third one with an 
attachment still says:

> // You can only use screen.inc with the perspective camera. Screen.inc
> // will automatically create the camera definition for you when it is
> // included.




> It would be nice to have this feature, because I already have all the camera
> positions of my animations and simply wanted to add a subtitle and some displays
> in front of the camera. Due to the scientific background of the animation I'd
> really prefer to have the orthographic cam.
> 
> Stephen, I tried your suggestion (without thinking, though) and just multiplied
> the camera location vector by 10, and divided the angle by 10. It did not work
> :) Is there a known mathematical way to fake the ortho-cam with my working
> camera settings (i.e. a simple transformation that I can apply in the end)?
> 

There will be a tangent in there some way.

https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula

All those hard quantum sums, eh? ;-)




> Thank you!
> 


-- 

Regards
     Stephen

[cbpypov] Re: New version screen.inc [3075 days 12 hours and 57 minutes ago]

Sat, 4 Nov 2017 19:20:00 GMT

>
> You are right. You can only use screen.inc with the perspective camera.
>
>
> Fake it. Move the camera further away and reduce the angle.
>
>
> --
>
> Regards
>      Stephen


Wasn't it just the objective of SharkD's file to actually make screen.inc
compatible with the orthographic camera? I.e. the issue of this thread?? A few
posts before some people state that it behaves as expected, but I can't seem to
get it to work.

It would be nice to have this feature, because I already have all the camera
positions of my animations and simply wanted to add a subtitle and some displays
in front of the camera. Due to the scientific background of the animation I'd
really prefer to have the orthographic cam.

Stephen, I tried your suggestion (without thinking, though) and just multiplied
the camera location vector by 10, and divided the angle by 10. It did not work
:) Is there a known mathematical way to fake the ortho-cam with my working
camera settings (i.e. a simple transformation that I can apply in the end)?

Thank you!

[Stephen] Re: New version screen.inc [3076 days 6 hours and 19 minutes ago]

Sat, 4 Nov 2017 01:57:17 GMT

On 03/11/2017 22:35, cbpypov wrote:
> This is a really cool feature which I'd like to use for an animation. Somehow it
> does not work for me: the camera "zooms in" much more than using the normal
> orthographic camera. The object positioning of text does not work either, as
> shown in the standard screen.inc example attached.
> 
> What am I doing wrong. Or did something change?
> 

You are right. You can only use screen.inc with the perspective camera.


Fake it. Move the camera further away and reduce the angle.


-- 

Regards
     Stephen

[cbpypov] Re: New version screen.inc [3076 days 9 hours and 37 minutes ago]

Fri, 3 Nov 2017 22:40:01 GMT

This is a really cool feature which I'd like to use for an animation. Somehow it
does not work for me: the camera "zooms in" much more than using the normal
orthographic camera. The object positioning of text does not work either, as
shown in the standard screen.inc example attached.

What am I doing wrong. Or did something change?

[Dave Blandston] Bordered Characters version 1.8 [3085 days 15 hours and 11 minutes ago]

Wed, 25 Oct 2017 17:05:05 GMT

Hey Everybody,

Here's the non-anticipated release of version 1.8 of the Bordered Characters
project. I'm done adding major features so this is just a minor update.

Some new characters have been added, which are angle brackets and a bullet
symbol. Adding the angle brackets required changing the embedded formatting code
for italics, so now curly brackets are used to start and stop italics. Since the
curly brackets used to enclose Font Style numbers, I changed the Font Style
embedded formatting code to tildes. I really preferred the original formatting
codes but I felt that adding the angle bracket characters was worth the changes.

I also added a couple arrays that you can access that provide a record of the
widths and heights of all the Paragraph objects created. I find this to be very
useful. These arrays are described in the documentation.

And of course there are some new Font Variations. In my opinion, numbers 36, 37,
and 38 are particularly interesting. In the BorderChars_FontVariations.inc file
I used the sine function to vary the border widths, although any function can be
used. These Font Variations alter the geometry of the characters in a manner
that will cause the automatic kerning feature to fail. For numbers 36 and 37,
the sine function is applied along the y axis. For number 38, the sine function
is applied along the y and z axes. A fun exercise would be to apply a function
along all three axes...

Font Variation 38 also required adding two more parameters to the SetFontStyle
(...) parameter list.

Regards,
Dave Blandston

PS - Renderings of some of the demonstration files are in the
povray.binaries.images area.

[Norbert Kern] Re: More materials based on proximity patterns [3104 days 15 hours and 26 minutes ago]

Fri, 6 Oct 2017 16:50:10 GMT

part 4 of 4 parts (just recognized the maximum attachment size of 5000 KB).
Part 2 to 4 are rar files.

Norbert

[Norbert Kern] Re: More materials based on proximity patterns [3104 days 15 hours and 31 minutes ago]

Fri, 6 Oct 2017 16:45:10 GMT

part 3 of 4 parts (just recognized the maximum attachment size of 5000 KB).
Part 2 to 4 are rar files.

Norbert

[Norbert Kern] Re: More materials based on proximity patterns [3104 days 15 hours and 36 minutes ago]

Fri, 6 Oct 2017 16:40:11 GMT

part 2 of 4 parts (just recognized the maximum attachment size of 5000 KB).
Part 2 to 4 are rar files.

Norbert

[Norbert Kern] More materials based on proximity patterns [3104 days 16 hours and 12 minutes ago]

Fri, 6 Oct 2017 16:05:03 GMT

Hi,

here is a demo file with some new proximity pattern materials.

It's a 3 part download because of some large meshes. Copy everything in one
single folder, render "prox_illusion.pov" first and copy image in the folder
before you render "more_proximity_materials.pov" as an animation (+kfi1 +kff25).

Have fun,
Norbert Kern

[Thomas de Groot] Re: A copy of Edouard Poor's DF3 Proximity Patte... [3128 days and 40 minutes ago]

Wed, 13 Sep 2017 07:36:09 GMT

On 12-9-2017 21:35, Kenneth wrote:
> Stephen <mca### [at] aolcom> wrote:
>> This include file was released by Edouard Poor of the Pov-Ray community,
>> in 2009. It is my personal copy that I am posting to the Pov-Ray
>> newsgroups as it is no longer available on the internet. All credit must
>> go to Edouard.
>> --
>>
>> Regards
>>       Stephen
> 
> Thanks, Stephen! I'm looking forward to checking this out, after so many years.
> 
> Now we await Thomas's contribution as well, ***coming soon*** (hint hint) ;-)
> 
> 
> 

A quick check: yes, these are the original files. Everything I did later 
is pure ballast. Best to play with these files.

-- 
Thomas

[Kenneth] Re: A copy of Edouard Poor's DF3 Proximity Patte... [3128 days 12 hours and 37 minutes ago]

Tue, 12 Sep 2017 19:40:00 GMT

Stephen <mca### [at] aolcom> wrote:
> This include file was released by Edouard Poor of the Pov-Ray community,
> in 2009. It is my personal copy that I am posting to the Pov-Ray
> newsgroups as it is no longer available on the internet. All credit must
> go to Edouard.
> --
>
> Regards
>      Stephen

Thanks, Stephen! I'm looking forward to checking this out, after so many years.

Now we await Thomas's contribution as well, ***coming soon*** (hint hint) ;-)

[Stephen] A copy of Edouard Poor's DF3 Proximity Pattern i... [3128 days 19 hours and 43 minutes ago]

Tue, 12 Sep 2017 12:33:08 GMT

This include file was released by Edouard Poor of the Pov-Ray community, 
in 2009. It is my personal copy that I am posting to the Pov-Ray 
newsgroups as it is no longer available on the internet. All credit must 
go to Edouard.
-- 

Regards
     Stephen

[omniverse] Re: POV-Ray 3.7 sometimes omits media photons [3194 days 1 hour and 52 minutes ago]

Sun, 9 Jul 2017 06:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> The reason your scene renders fine in v3.6 is that the symptoms were
> ever so slightly different: Instead of the last object, it was the first
> object that won the `hollow` flag war.
>
> Place the box after the light source, and it will render fine in v3.7
> but break in v3.6.

I'm surprised I hadn't noticed this problem before with it around all that time,
or maybe I just change the scenes until they work right... or give up on them.

> Can someone please open a GitHub issue for this one? It may need some
> work before it can be fixed.

Done, whether correct enough is another matter but I tried my best.  :)

Bob

[clipka] Re: POV-Ray 3.7 sometimes omits media photons [3195 days and 1 minute ago]

Sat, 8 Jul 2017 08:15:59 GMT

Am 08.07.2017 um 09:07 schrieb clipka:
> Am 07.07.2017 um 20:10 schrieb omniverse:
>> Cousin Ricky <ric### [at] yahoocom> wrote:
>>> See thread in p.b.i.  The scene uses two light sources, one to trace a
>>> cylindrical parallel beam through two prisms and across a room, and
>>> another, with media interaction turned off, to light the scene.  The
>>> latter light has a looks_like for what reason I don't remember.  (This
>>> was 12 years ago!)
>>>
>>> When the scene is rendered as an animation, the looks_like is omitted in
>>> frame 2.
>>
>> Don't know the reason behind it but simply making the looks_like sphere hollow
>> allows the photons to show.
> 
> Well, /I/ know the reason behind it now ;)
> 
> During refactoring for 3.7.0, a bug was introduced that may cause
> objects in the same CSG group to mess with each others' `hollow` flag,
> with the last object winning. In this case that happened to be the
> non-hollow `looks_like` object.

... actually, no: The bug wasn't introduced in v3.7; it was a
pre-existing condition.

The reason your scene renders fine in v3.6 is that the symptoms were
ever so slightly different: Instead of the last object, it was the first
object that won the `hollow` flag war.

Place the box after the light source, and it will render fine in v3.7
but break in v3.6.

Can someone please open a GitHub issue for this one? It may need some
work before it can be fixed.

[omniverse] Re: POV-Ray 3.7 sometimes omits media photons [3195 days and 17 minutes ago]

Sat, 8 Jul 2017 08:00:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 07.07.2017 um 20:10 schrieb omniverse:
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> See thread in p.b.i.  The scene uses two light sources, one to trace a
> >> cylindrical parallel beam through two prisms and across a room, and
> >> another, with media interaction turned off, to light the scene.  The
> >> latter light has a looks_like for what reason I don't remember.  (This
> >> was 12 years ago!)
> >>
> >> When the scene is rendered as an animation, the looks_like is omitted in
> >> frame 2.
> >
> > Don't know the reason behind it but simply making the looks_like sphere hollow
> > allows the photons to show.
>
> Well, /I/ know the reason behind it now ;)
>
> During refactoring for 3.7.0, a bug was introduced that may cause
> objects in the same CSG group to mess with each others' `hollow` flag,
> with the last object winning. In this case that happened to be the
> non-hollow `looks_like` object.

Much appreciation to you for finding that.

I hadn't thought of the looks_like being part of CSG if a lone object is used.

Wow, code reading is fun and confusing. Just before you answered to that I was
finally getting a look at both the 3.7 and 3.62 source for comparisons of what
might have changed, in particular the parse.cpp file, and I sure get lost fast.

I just wanted to see what parts looks_like dealt with, although I guessed it was
probably the object or hollow causing the trouble when conveyed to the parser
somewhere. I was thinking about the "children" parts and if that might be the
reason.
Please ignore me for my lack of certainty, clarity and definition there. I'm way
out of my league!

Anyway, thanks again for checking on that... both of you Christoph and Richard.

Bob

[clipka] Re: POV-Ray 3.7 sometimes omits media photons [3195 days 1 hour and 9 minutes ago]

Sat, 8 Jul 2017 07:07:34 GMT

Am 07.07.2017 um 20:10 schrieb omniverse:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> See thread in p.b.i.  The scene uses two light sources, one to trace a
>> cylindrical parallel beam through two prisms and across a room, and
>> another, with media interaction turned off, to light the scene.  The
>> latter light has a looks_like for what reason I don't remember.  (This
>> was 12 years ago!)
>>
>> When the scene is rendered as an animation, the looks_like is omitted in
>> frame 2.
> 
> Don't know the reason behind it but simply making the looks_like sphere hollow
> allows the photons to show.

Well, /I/ know the reason behind it now ;)

During refactoring for 3.7.0, a bug was introduced that may cause
objects in the same CSG group to mess with each others' `hollow` flag,
with the last object winning. In this case that happened to be the
non-hollow `looks_like` object.

[omniverse] Re: POV-Ray 3.7 sometimes omits media photons [3195 days 14 hours and 1 minute ago]

Fri, 7 Jul 2017 18:15:05 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> See thread in p.b.i.  The scene uses two light sources, one to trace a
> cylindrical parallel beam through two prisms and across a room, and
> another, with media interaction turned off, to light the scene.  The
> latter light has a looks_like for what reason I don't remember.  (This
> was 12 years ago!)
>
> When the scene is rendered as an animation, the looks_like is omitted in
> frame 2.

Don't know the reason behind it but simply making the looks_like sphere hollow
allows the photons to show.

[Cousin Ricky] POV-Ray 3.7 sometimes omits media photons [3195 days 20 hours and 2 minutes ago]

Fri, 7 Jul 2017 12:14:14 GMT

See thread in p.b.i.  The scene uses two light sources, one to trace a 
cylindrical parallel beam through two prisms and across a room, and 
another, with media interaction turned off, to light the scene.  The 
latter light has a looks_like for what reason I don't remember.  (This 
was 12 years ago!)

When the scene is rendered as an animation, the looks_like is omitted in 
frame 2.

File beam0-pared-by37.log is the statistics from a v3.7.0 run with 
+KFF2.  File beam0-pared-by36.log is the statistics from a v3.6.1 run 
with +KFF2 +EF1.

POV-Ray versions:
   3.6.1 (g++ 3.4.1 @ i686-pc-linux-gnu)
   This is an official version prepared by the POV-Ray Team.

   3.7.0.unofficial [no source code alterations]
   Compilation settings:
     Build architecture:  x86_64-unknown-linux-gnu
     Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
     Compiler vendor:     gnu
     Compiler version:    g++ 4.8
     Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread

OS: openSUSE 13.2 (GNU/Linux)

[Kenneth] Re: Mike Williams City7 macros here [3217 days 14 hours and 57 minutes ago]

Thu, 15 Jun 2017 17:20:00 GMT

Thanks, Thomas! Much appreciated.

[Bald Eagle] Re: Mike Williams City7 macros here [3217 days 15 hours and 42 minutes ago]

Thu, 15 Jun 2017 16:35:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> In the attached zip file you will find everything needed for City7 by
> Mike Williams. Year of origin 2005 I guess. I may have edited some of
> them over the years.
>
> Enjoy!
>
> --
> Thomas

Nice work with the POV-Ray Archaeology!  :)

I wish he still visited the forums - it's always fascinating to see the elegant
shapes and mathemagical scenes he'd come up with.

[Thomas de Groot] Mike Williams City7 macros here [3218 days 1 hour and 20 minutes ago]

Thu, 15 Jun 2017 06:56:16 GMT

In the attached zip file you will find everything needed for City7 by 
Mike Williams. Year of origin 2005 I guess. I may have edited some of 
them over the years.

Enjoy!

-- 
Thomas

[Stephen] Re: For Stephen: maths.inc [3226 days and 51 minutes ago]

Wed, 7 Jun 2017 07:25:35 GMT

On 6/7/2017 7:56 AM, Thomas de Groot wrote:
> On 7-6-2017 6:00, Stephen wrote:
>> On 6/6/2017 11:05 PM, Cousin Ricky wrote:
>>
>> ROTFLMAO
>>
>>> Let me know if I missed anything.  :)
>>
>> Thanks Cuz. Now explain why anyone would want to normalise a 5D vector?
>> What sense does it make in a 3D world?
>>
>
> It would help me to wrap my tentacles around my intended victims.
>
> Cthulhu
>

Fair point. Oh Great Old One. :)

-- 

Regards
     Stephen

[Thomas de Groot] Re: For Stephen: maths.inc [3226 days 1 hour and 20 minutes ago]

Wed, 7 Jun 2017 06:56:44 GMT

On 7-6-2017 6:00, Stephen wrote:
> On 6/6/2017 11:05 PM, Cousin Ricky wrote:
>
> ROTFLMAO
>
>> Let me know if I missed anything.  :)
>
> Thanks Cuz. Now explain why anyone would want to normalise a 5D vector?
> What sense does it make in a 3D world?
>

It would help me to wrap my tentacles around my intended victims.

Cthulhu

-- 
Thomas

[Stephen] Re: For Stephen: maths.inc [3226 days 4 hours and 16 minutes ago]

Wed, 7 Jun 2017 04:00:17 GMT

On 6/6/2017 11:05 PM, Cousin Ricky wrote:

ROTFLMAO

> Let me know if I missed anything.  :)

Thanks Cuz. Now explain why anyone would want to normalise a 5D vector? 
What sense does it make in a 3D world?

-- 

Regards
     Stephen

[Cousin Ricky] For Stephen: maths.inc [3226 days 10 hours and 12 minutes ago]

Tue, 6 Jun 2017 22:04:51 GMT

Let me know if I missed anything.  :)

[Mike Horvath] Re: Graphical projection comparison [3241 days 21 hours and 42 minutes ago]

Mon, 22 May 2017 10:34:19 GMT

Another update.

Mike

[Thomas de Groot] Re: 3dclouds include file [3242 days 1 hour and 10 minutes ago]

Mon, 22 May 2017 07:06:25 GMT

On 21-5-2017 15:29, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 21/05/2017 Ã  08:41, Thomas de Groot a Ã©crit :
>
>> I would rather like to call for a way to bring all those
>>> goodies produced over the years to the easy access of everybody
>>> interested, like the Objects Collection. I think it is a pity that so
>>> much has gone into oblivion.
>
> Indeed.   I have wondered if there were an "advanced civilization", would we
> have any [recognizable] record of/from them - everything could be on a chip the
> size, shape, and color of a grain of sand, and it could be protected / encrypted
> or otherwise obfucscated.
>
> I have seen a LOT of great ideas developed in the POV-Ray world, and it would be
> a wonderful thing to have as much of a record of that as we could.
>
>> there would be a need for some classification/keyword to help the
>> exploration, and I'm afraid that legal issue might block a bit.
>
>
https://www.ip-watch.org/2008/07/07/intellectual-property-regime-stifles-science-and-innovation-nobel-laureates-say/
>
https://www.fastcodesign.com/1669150/watch-how-ip-laws-destroy-creativity-instead-of-encouraging-it
>
>> Obviously, the Object Collection, due to licensing, is not suitable for
>> such second-hand utilities.
>> Moreover, it's outdated and hand-written.
>
>
>> I would think about something like wikimedia might be a possible
>> solution: one page per contributions, using [[category:Name]] in text to
>> put keyword.
>> And the page should provides the credit as well as much information as
>> possible.
>>
>> Protection against spamming is another problem to keep in mind.
>
> Along the same lines that I was thinking about the "monthly contest" - I might
> suggest that something along the lines of "document / rewrite and old concept"
> would be interesting.
> In a way, the fact that some things are lost / outdated / no longer work with
> 3.7.1-greek.number may be a benefit.
>
> A completely lost scene or include file could be reconstructed from scratch, by
> new authors, and give things a fresh start.
>
> Older scenes, include files, and code can be cleaned up, "adequately" commented,
> and written to work well with the newest stable version.
> https://en.wikipedia.org/wiki/Derivative_work
>
> Certainly it would be kind and "proper" to acknowledge work done by others,
> include historical notes about who made such a scene first, and other
> attributions.
>
> But, having thought about IP for a long time, it seems that there ought to be
> some sort of threshold that needs to be crossed before it may be invoked, and
> there certainly needs to be some limit to how long one may claim such a
> protection.
>
> IP is supposed to be a courtesy - not trammels and a straightjacket.
> Do we want people to USE POV-Ray, make new scenes, and contribute to community,
> inspiration, learning, and posting new renders?
> People can make whatever they want, and it can be "theirs", but one guy can't
> make a mirrored sphere on a blue checkered plane, and then say that the guy who
> makes a sphere on a RED checkered plane has in some way "injured" him.  Or
> worse, because he plugged in a certain arrangement of coefficients into the
> polynomial{} directive, that he may now lay claim to every subsequent instance
> of that - done by anyone, forever after.
>
> Imagine: "I own the exclusive RIGHT to ANY x^2+Y^2+z^2 = r^2 on an alternating
> <r,g,b, f, t> Ax+By+Cz+D !"
>
>
> I do think that a way of collecting and indexing such things ought to be found -
> it seems that something like GitHub would be a good way to do that.
> Only those registered could post code or commentary.
>
> Having some form of header that included robust version control would be an
> excellent thing, considering how much continuing work goes into such tools as
> the isosurface approximator, screen.inc, bordered characters, and many many
> others.
>
>

In calling this to the general attention, I was indeed fully aware of 
the different problems involved. They are not easy to solve I guess. 
Licensing is tricky. Many goodies were just brought to us out of 
courtesy without - I suppose - any idea of restricting their use within 
the limits of what is fair and proper like mentioning original author 
and subsequent changes, and/or a known use history, and some form of 
self-imposed use restriction. Still, there is an immense variety of 
things going from snippets of code to complete scenes and that is 
difficult to manage properly.

I am no expert on this but if knowledgeable people could assess the 
potentialities of wikimedia or github, I and many here would certainly 
be most grateful indeed.


-- 
Thomas

[Bald Eagle] Re: 3dclouds include file [3242 days 18 hours and 47 minutes ago]

Sun, 21 May 2017 13:30:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 21/05/2017 Ã  08:41, Thomas de Groot a Ã©crit :

> I would rather like to call for a way to bring all those
> > goodies produced over the years to the easy access of everybody
> > interested, like the Objects Collection. I think it is a pity that so
> > much has gone into oblivion.

Indeed.   I have wondered if there were an "advanced civilization", would we
have any [recognizable] record of/from them - everything could be on a chip the
size, shape, and color of a grain of sand, and it could be protected / encrypted
or otherwise obfucscated.

I have seen a LOT of great ideas developed in the POV-Ray world, and it would be
a wonderful thing to have as much of a record of that as we could.

> there would be a need for some classification/keyword to help the
> exploration, and I'm afraid that legal issue might block a bit.

https://www.ip-watch.org/2008/07/07/intellectual-property-regime-stifles-science-and-innovation-nobel-laureates-say/
https://www.fastcodesign.com/1669150/watch-how-ip-laws-destroy-creativity-instead-of-encouraging-it

> Obviously, the Object Collection, due to licensing, is not suitable for
> such second-hand utilities.
> Moreover, it's outdated and hand-written.

> I would think about something like wikimedia might be a possible
> solution: one page per contributions, using [[category:Name]] in text to
> put keyword.
> And the page should provides the credit as well as much information as
> possible.
>
> Protection against spamming is another problem to keep in mind.

Along the same lines that I was thinking about the "monthly contest" - I might
suggest that something along the lines of "document / rewrite and old concept"
would be interesting.
In a way, the fact that some things are lost / outdated / no longer work with
3.7.1-greek.number may be a benefit.

A completely lost scene or include file could be reconstructed from scratch, by
new authors, and give things a fresh start.

Older scenes, include files, and code can be cleaned up, "adequately" commented,
and written to work well with the newest stable version.
https://en.wikipedia.org/wiki/Derivative_work

Certainly it would be kind and "proper" to acknowledge work done by others,
include historical notes about who made such a scene first, and other
attributions.

But, having thought about IP for a long time, it seems that there ought to be
some sort of threshold that needs to be crossed before it may be invoked, and
there certainly needs to be some limit to how long one may claim such a
protection.

IP is supposed to be a courtesy - not trammels and a straightjacket.
Do we want people to USE POV-Ray, make new scenes, and contribute to community,
inspiration, learning, and posting new renders?
People can make whatever they want, and it can be "theirs", but one guy can't
make a mirrored sphere on a blue checkered plane, and then say that the guy who
makes a sphere on a RED checkered plane has in some way "injured" him.  Or
worse, because he plugged in a certain arrangement of coefficients into the
polynomial{} directive, that he may now lay claim to every subsequent instance
of that - done by anyone, forever after.

Imagine: "I own the exclusive RIGHT to ANY x^2+Y^2+z^2 = r^2 on an alternating
<r,g,b, f, t> Ax+By+Cz+D !"

I do think that a way of collecting and indexing such things ought to be found -
it seems that something like GitHub would be a good way to do that.
Only those registered could post code or commentary.

Having some form of header that included robust version control would be an
excellent thing, considering how much continuing work goes into such tools as
the isosurface approximator, screen.inc, bordered characters, and many many
others.

[pascal] Re: 3dclouds include file [3242 days 20 hours and 42 minutes ago]

Sun, 21 May 2017 11:34:14 GMT

On 21/05/2017 08:41, Thomas de Groot wrote:
> On 20-5-2017 12:45, Norbert Kern wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> Thanks too. That one was missing from my collection :-)
>>
>>
>>
>> Hi Thomas,
>>
>> perhaps we should exchange our collections (I'm living in Northrhine
>> Westphalia...)
>>
>> My main comps foresay for images and pov-related files about 1 to 2
>> TB, so why
>> not meet physically and excange (mobile) hard drives?
>>
>> Of course I'ld include all of my personal files too...
>>
>>
>> Norbert
>>
>
> Hmmm, that is more volume than I have memory to tell the truth :-) In
> all fairness, I only collect what I /think/ I may need one day, so I
> cannot boast to a very complete POV-Ray collection and much of it I have
> never used. I would rather like to call for a way to bring all those
> goodies produced over the years to the easy access of everybody
> interested, like the Objects Collection. I think it is a pity that so
> much has gone into oblivion.
>
I totally agree...
I used to play with povray about 15 years ago...and there were plenty of 
sites, tutos etc dedicated to this. The large majority of my saved pov's 
bookmark is dead now.
I lost the drive on which I saved all this stuff.
And by the way...If I'd dare...I ask if someone has the Ledensky's 
"3dclouds.pov" which came with the include file ?
Thanks in advance...
Pascal

[Le Forgeron] Re: 3dclouds include file [3242 days 21 hours and 30 minutes ago]

Sun, 21 May 2017 10:47:00 GMT

Le 21/05/2017 Ã  08:41, Thomas de Groot a Ã©crit :
> 
> Hmmm, that is more volume than I have memory to tell the truth :-) In
> all fairness, I only collect what I /think/ I may need one day, so I
> cannot boast to a very complete POV-Ray collection and much of it I have
> never used. I would rather like to call for a way to bring all those
> goodies produced over the years to the easy access of everybody
> interested, like the Objects Collection. I think it is a pity that so
> much has gone into oblivion.
> 

there would be a need for some classification/keyword to help the
exploration, and I'm afraid that legal issue might block a bit.

Obviously, the Object Collection, due to licensing, is not suitable for
such second-hand utilities.
Moreover, it's outdated and hand-written.

I would think about something like wikimedia might be a possible
solution: one page per contributions, using [[category:Name]] in text to
put keyword.
And the page should provides the credit as well as much information as
possible.

Protection against spamming is another problem to keep in mind.

[Thomas de Groot] Re: 3dclouds include file [3243 days 1 hour and 35 minutes ago]

Sun, 21 May 2017 06:41:17 GMT

On 20-5-2017 12:45, Norbert Kern wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> Thanks too. That one was missing from my collection :-)
>
>
>
> Hi Thomas,
>
> perhaps we should exchange our collections (I'm living in Northrhine
> Westphalia...)
>
> My main comps foresay for images and pov-related files about 1 to 2 TB, so why
> not meet physically and excange (mobile) hard drives?
>
> Of course I'ld include all of my personal files too...
>
>
> Norbert
>

Hmmm, that is more volume than I have memory to tell the truth :-) In 
all fairness, I only collect what I /think/ I may need one day, so I 
cannot boast to a very complete POV-Ray collection and much of it I have 
never used. I would rather like to call for a way to bring all those 
goodies produced over the years to the easy access of everybody 
interested, like the Objects Collection. I think it is a pity that so 
much has gone into oblivion.

-- 
Thomas

[Norbert Kern] Re: 3dclouds include file [3243 days 21 hours and 27 minutes ago]

Sat, 20 May 2017 10:50:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Thanks too. That one was missing from my collection :-)



Hi Thomas,

perhaps we should exchange our collections (I'm living in Northrhine
Westphalia...)

My main comps foresay for images and pov-related files about 1 to 2 TB, so why
not meet physically and excange (mobile) hard drives?

Of course I'ld include all of my personal files too...


Norbert

[Thomas de Groot] Re: 3dclouds include file [3244 days 1 hour and 14 minutes ago]

Sat, 20 May 2017 07:02:55 GMT

On 19-5-2017 16:18, Norbert Kern wrote:
> I meant I'll download it, if you really mean 3dclouds.inc instead of
> 3dscloud.inc.
>

Thanks too. That one was missing from my collection :-)

-- 
Thomas

[pascal] Re: 3dclouds include file [3244 days 17 hours and 46 minutes ago]

Fri, 19 May 2017 14:30:12 GMT

On 19/05/2017 16:18, Norbert Kern wrote:

>
> Oh I'm sorry,
>
> I meant I'll download it, if you really mean 3dclouds.inc instead of
> 3dscloud.inc.
>
> But anyway, here it is...
>
> Norbert
>
Thanks a lot for your fast upload !
Cheers

Have a nice day !
Pascal

[Norbert Kern] Re: 3dclouds include file [3244 days 17 hours and 57 minutes ago]

Fri, 19 May 2017 14:20:00 GMT

pascal <pas### [at] wanadoofr> wrote:
> To post the message to the right place...
> I looked for this file but was unable to find it : 3dclouds.inc.
> Is there a place where I can grab that piece of excellent work ?
> Thxs in advance !
> P.G.
> --
> Haut par-dessus leur tÃªte voguaient les blanches sculptures
> des nuages, comme en la cervelle de Michel-Ange des volutes
> de concept.
> M. Lowry

Oh I'm sorry,

I meant I'll download it, if you really mean 3dclouds.inc instead of
3dscloud.inc.

But anyway, here it is...

Norbert

[pascal] 3dclouds include file [3244 days 18 hours and 18 minutes ago]

Fri, 19 May 2017 13:58:21 GMT

To post the message to the right place...
I looked for this file but was unable to find it : 3dclouds.inc.
Is there a place where I can grab that piece of excellent work ?
Thxs in advance !
P.G.
-- 
Haut par-dessus leur tÃªte voguaient les blanches sculptures
des nuages, comme en la cervelle de Michel-Ange des volutes
de concept.
M. Lowry

[Bald Eagle] Re: Graphical projection comparison [3251 days 20 hours and 22 minutes ago]

Fri, 12 May 2017 11:55:00 GMT

Sorry for the delay  -  it's been a positively tumultuous week or two, and I
have to juggle files back and forth on a USB stick...

Here's a short scene that writes SVG objects directly to file.

[Stephen] Re: Earth Globe [3254 days 22 hours and 6 minutes ago]

Tue, 9 May 2017 10:10:11 GMT

On 5/9/2017 10:39 AM, dick balaska wrote:
> Am 2017-05-09 04:39, also sprach Stephen:
>> Attached is a Pov file for the Earth using a specular map.
>> The image maps are to be found on the Blue Marble site. They are large.
>> https://visibleearth.nasa.gov/view_cat.php?categoryID=1484
>
> Awesome! Thanks.
>
> Do you find any overall speed improvement using Render_Block_Size=8?  Or
> is it just more fun to watch it render? ;)
>

Yes a bit. Especially with media and lots of reflections.
But the real reason is for that last block that takes hours to render 
and there are cores lying idle. It annoys the bejasus out of me. :)
At least this way I can have 12 threads working on it.

> Interesting it is a 10,000 frame animation, yet the source doesn't use
> "clock" anywhere, so every frame is identical. :)
>

That's how the modellers, I've used, work to create an animation. They 
output one scene file for every frame and use the 
Subset_Start_Frame/End, ini commands to control it.

I generally write the animation code myself. After setting the scene up 
in Bishop3D. I prefer to use frame_number rather than clock. Clock is so 
analogue ;) You know where you are with frames.

-- 

Regards
     Stephen

[dick balaska] Re: Earth Globe [3254 days 22 hours and 37 minutes ago]

Tue, 9 May 2017 09:39:07 GMT

Am 2017-05-09 04:39, also sprach Stephen:
> Attached is a Pov file for the Earth using a specular map.
> The image maps are to be found on the Blue Marble site. They are large.
> https://visibleearth.nasa.gov/view_cat.php?categoryID=1484

Awesome! Thanks.

Do you find any overall speed improvement using Render_Block_Size=8?  Or 
is it just more fun to watch it render? ;)

Interesting it is a 10,000 frame animation, yet the source doesn't use 
"clock" anywhere, so every frame is identical. :)

-- 
dik

[Stephen] Re: Earth Globe [3254 days 23 hours and 15 minutes ago]

Tue, 9 May 2017 09:01:39 GMT

On 5/9/2017 9:39 AM, Stephen wrote:
> If you can't find any particular map from the names. Let me know and I
> will upload it

Oh! I changed some jpeg files to png.

-- 

Regards
     Stephen

[Stephen] Earth Globe [3254 days 23 hours and 37 minutes ago]

Tue, 9 May 2017 08:39:56 GMT

Attached is a Pov file for the Earth using a specular map.
The image maps are to be found on the Blue Marble site. They are large.
https://visibleearth.nasa.gov/view_cat.php?categoryID=1484


If you can't find any particular map from the names. Let me know and I 
will upload it.

The scene was created in Bishop3D so you might get a few warnings.

-- 

Regards
     Stephen

[Kenneth] Re: Graphical projection comparison [3258 days 15 hours and 47 minutes ago]

Fri, 5 May 2017 16:30:01 GMT

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

>
> It's not an internal POV-Ray thing - I write it into the macro or SDL myself.
>
> If I have a complicated scene, there may be a lot of
> #if (Verbose)
>      #debug blah blah blah value1 value2 vectorA, etc
> #end // end if Verbose
>
> sprinkled throughout the scene,
>

(***laughing out loud***)
OH, so *that's* what it means!! Thanks for clarifying. I haven't been so
thoroughly confused since I tried to understand the true nature of gravity. :-P

It just so happens that, right before I saw your post, I had been working with
POV-Ray's own "Verbose" command. So I naturally assumed... uh...

Had a good laugh over that one. :-)

[Bald Eagle] Re: Graphical projection comparison [3258 days 20 hours and 22 minutes ago]

Fri, 5 May 2017 11:55:01 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> That's a new trick to me; I thought Verbose was only for
> use in an .ini file (I'm running Windows.)

Ha!  And there's something _I_ was unaware of.   :O

> Could you explain how you use it or
> how you make it work? I tried simply sticking  #declare Verbose=on  in the
> middle of a scene file, but didn't see anything different(?) in the message
> stream after the render. I'm *obviously* not 'getting it'... :-(  Is it used in
> conjunction with #debug somehow? Do other .ini parameters need changing too?
>
> Thanks. This looks to be quite useful!

It's not an internal POV-Ray thing - I write it into the macro or SDL myself.

If I have a complicated scene, there may be a lot of
#if (Verbose)
     #debug blah blah blah value1 value2 vectorA, etc
#end // end if Verbose

sprinkled throughout the scene,

and if I write a macro, I'll spit out messages that it's been included, that
it's just gotten invoked, what variables it's working with, what their values
are, a help/man-page style usage example, end when the macro exits.

It's just a better and "more convenient" way for me to get documentation and see
what's going on without having to track down a separate ini or mcr file or open
a help page or search through the code to see what the heck I mis-coded (again)
THIS time.

Sorry for the confusion

[Kenneth] Re: Graphical projection comparison [3259 days 3 hours and 32 minutes ago]

Fri, 5 May 2017 04:45:00 GMT

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

>
> One thing that might be useful is to include some reminders and usage info for
> output to the debug stream.
> I often
> #declare Verbose = true;
> in my scene, and then any macros or parts of the scene where I want to get data
> from check for that variable and then I get everything I want with just one
> "switch".
>
> I do the same thing with any weird command syntax that I use - I just output or
> include in the comments a working line of code using that command.

That's a new trick to me; I thought Verbose was only for
use in an .ini file (I'm running Windows.) Could you explain how you use it or
how you make it work? I tried simply sticking  #declare Verbose=on  in the
middle of a scene file, but didn't see anything different(?) in the message
stream after the render. I'm *obviously* not 'getting it'... :-(  Is it used in
conjunction with #debug somehow? Do other .ini parameters need changing too?

Thanks. This looks to be quite useful!

[Mike Horvath] Re: Graphical projection comparison [3259 days 12 hours and 44 minutes ago]

Thu, 4 May 2017 19:32:40 GMT

Update in the attachment.


Mike

[Mike Horvath] Re: Graphical projection comparison [3259 days 14 hours and 50 minutes ago]

Thu, 4 May 2017 17:26:32 GMT

On 5/4/2017 12:44 PM, Bald Eagle wrote:
> I suppose if you're ambitious enough - you could flip those macros around and
> given a distance from the camera-right-up plane, you could return x,y,z
> coordinates to place an object into the scene, so that it would line up with a
> place on the screen or in the image.
>

I checked the code once again, an it may be already possible to do this 
by adjusting the "Scaling" parameter of the "Screen_Object" and 
"Screen_Plane" macros. I might be wrong though.

Mike

[Mike Horvath] Re: Graphical projection comparison [3259 days 14 hours and 58 minutes ago]

Thu, 4 May 2017 17:18:19 GMT

On 5/4/2017 12:44 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>
>> I forgot that in my version of "screen.inc" I added a macro called
>> "Get_Screen_XY" that takes any 3D scene coordinate as input and outputs
>> the 2D screen coordinate, normalized between 0 and 1. This makes things
>> super simple!
>
> Hmmm.  I recall that Screen.inc uses a -0.5 to +0.5 range.
> Might you want to edit "Get_Screen_XY" to output THAT range, so that it would be
> easy to align things on the screen with objects in the image,
> and then rename the "Get_Screen_XY" to "Get_Image_XY" - since that might
> disambiguate things a bit?
>

I just checked the code again and realized the output is not normalized 
to between 0 and 1. Instead, it outputs a fraction of whatever 
image_width and image_height are. Switching back to -0.5 to +0.5 should 
be easy.


> I suppose if you're ambitious enough - you could flip those macros around and
> given a distance from the camera-right-up plane, you could return x,y,z
> coordinates to place an object into the scene, so that it would line up with a
> place on the screen or in the image.
>

I can't really remember the details of how the code works. It's been so 
long since I looked at this code. If you want to take a crack at it, go 
ahead.


>> I just list whatever points I want to project, and then
>> write the 2D locations to a text file.
>
> Since the SVG is just a text file, and you can clearly follow the syntax - why
> not just write the SVG header, output an SVG line definition, and add some
> triangles or whatnot, and get your usable SVG straight from POV-Ray?
> It would cut out a lot from the workflow.
> Just a suggestion.
>

I would have to rewrite this code for every scene I create. What if I 
want to change the colors? What if I want to add some text? Angle or 
distance measurements? Buttons and check boxes? This all means extra 
work compared to GeoGebra, which is WYSIWYG.


>> I've attached "screen.inc" to this post.
>
> Thank you :)
>
> One thing that might be useful is to include some reminders and usage info for
> output to the debug stream.
> I often
> #declare Verbose = true;
> in my scene, and then any macros or parts of the scene where I want to get data
> from check for that variable and then I get everything I want with just one
> "switch".
>
> I do the same thing with any weird command syntax that I use - I just output or
> include in the comments a working line of code using that command.
>

I don't think I modified the debug text from the original. This is all I 
could find:

	#ifdef(View_POV_Include_Stack)	#debug "including screen.inc\n"		#end


Mike

[Bald Eagle] Re: Graphical projection comparison [3259 days 15 hours and 32 minutes ago]

Thu, 4 May 2017 16:45:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

> I forgot that in my version of "screen.inc" I added a macro called
> "Get_Screen_XY" that takes any 3D scene coordinate as input and outputs
> the 2D screen coordinate, normalized between 0 and 1. This makes things
> super simple!

Hmmm.  I recall that Screen.inc uses a -0.5 to +0.5 range.
Might you want to edit "Get_Screen_XY" to output THAT range, so that it would be
easy to align things on the screen with objects in the image,
and then rename the "Get_Screen_XY" to "Get_Image_XY" - since that might
disambiguate things a bit?

I suppose if you're ambitious enough - you could flip those macros around and
given a distance from the camera-right-up plane, you could return x,y,z
coordinates to place an object into the scene, so that it would line up with a
place on the screen or in the image.

> I just list whatever points I want to project, and then
> write the 2D locations to a text file.

Since the SVG is just a text file, and you can clearly follow the syntax - why
not just write the SVG header, output an SVG line definition, and add some
triangles or whatnot, and get your usable SVG straight from POV-Ray?
It would cut out a lot from the workflow.
Just a suggestion.

> I've attached "screen.inc" to this post.

Thank you :)

One thing that might be useful is to include some reminders and usage info for
output to the debug stream.
I often
#declare Verbose = true;
in my scene, and then any macros or parts of the scene where I want to get data
from check for that variable and then I get everything I want with just one
"switch".

I do the same thing with any weird command syntax that I use - I just output or
include in the comments a working line of code using that command.

[Kenneth] Re: Graphical projection comparison [3259 days 16 hours and 7 minutes ago]

Thu, 4 May 2017 16:10:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:

>
> I forgot that in my version of "screen.inc" I added a macro called
> "Get_Screen_XY" ...

Yeah, I was perplexed as to how the 'vanilla' version of screen.inc could do
that.

This looks interesting. Thanks for posting your modified version.

[Mike Horvath] Re: Graphical projection comparison [3259 days 16 hours and 39 minutes ago]

Thu, 4 May 2017 15:37:35 GMT

The instructions say:

> You can only use screen.inc with the perspective camera.

Note that this is no longer the case. I added a macro called 
"Set_Camera_Orthographic" that allows you to use a parallel camera as 
well. I will need to update the text to reflect this.


Mike

[Mike Horvath] Re: Graphical projection comparison [3259 days 16 hours and 47 minutes ago]

Thu, 4 May 2017 15:29:12 GMT

I used a similar strategy when creating this image:

https://commons.wikimedia.org/wiki/File:Graphical_projection_comparison.png

The main image was rendered in POV-Ray. I then converted the important 
coordinates from 3D to 2D, and built the arrows and text on top using 
GeoGebra.


Mike

[Mike Horvath] Re: Graphical projection comparison [3259 days 16 hours and 51 minutes ago]

Thu, 4 May 2017 15:25:36 GMT

On 5/4/2017 8:43 AM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I created four new scenes comparing different types of graphical
>> projection. You can see the results here:
>>
>> https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg
>>
>> What I did was this:
>>
>> 1. model the scenes in POV-Ray
>> 2. using "screen.inc" export the important points to a text file
>> 3. import the points into GeoGebra
>> 4. connect in GeoGebra the points using segments and polygons
>> 5. export to SVG
>
> eek.
> I think that some of us have worked out a few rudimentary tools for making SVG
> files that mimic some basic lines and shapes.
> If and when I have the time and motivation, I could probably pair that with what
> I've learned - and haven't forgotten - from the whole view frustum project, and
> then use trace() to get screen coordinates.
>
> Maybe a little macro could be worked out that - given the constants for defining
> the image plane, the camera, and the viewing vector, would project a set of
> given points onto that plane...
>
>> This was the easiest way I could think of for creating SVG files using
>> perspective projection.
>
> "... fastest way, using what I had, and what I already knew"
> Yep - I often have to do that as an expedient, just to _get it done._
>
> Nice little project though.  :)
>
>> Mike
>
>
>


I forgot that in my version of "screen.inc" I added a macro called 
"Get_Screen_XY" that takes any 3D scene coordinate as input and outputs 
the 2D screen coordinate, normalized between 0 and 1. This makes things 
super simple! I just list whatever points I want to project, and then 
write the 2D locations to a text file.

I've attached "screen.inc" to this post.

Mike

[Bald Eagle] Re: Graphical projection comparison [3259 days 19 hours and 32 minutes ago]

Thu, 4 May 2017 12:45:01 GMT

Mike Horvath <mik### [at] gmailcom> wrote:
> I created four new scenes comparing different types of graphical
> projection. You can see the results here:
>
> https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg
>
> What I did was this:
>
> 1. model the scenes in POV-Ray
> 2. using "screen.inc" export the important points to a text file
> 3. import the points into GeoGebra
> 4. connect in GeoGebra the points using segments and polygons
> 5. export to SVG

eek.
I think that some of us have worked out a few rudimentary tools for making SVG
files that mimic some basic lines and shapes.
If and when I have the time and motivation, I could probably pair that with what
I've learned - and haven't forgotten - from the whole view frustum project, and
then use trace() to get screen coordinates.

Maybe a little macro could be worked out that - given the constants for defining
the image plane, the camera, and the viewing vector, would project a set of
given points onto that plane...

> This was the easiest way I could think of for creating SVG files using
> perspective projection.

"... fastest way, using what I had, and what I already knew"
Yep - I often have to do that as an expedient, just to _get it done._

Nice little project though.  :)

> Mike

[Mike Horvath] Graphical projection comparison [3259 days 20 hours and 25 minutes ago]

Thu, 4 May 2017 11:51:58 GMT

I created four new scenes comparing different types of graphical 
projection. You can see the results here:

https://commons.wikimedia.org/wiki/File:Various_projections_of_cube_above_plane.svg

What I did was this:

1. model the scenes in POV-Ray
2. using "screen.inc" export the important points to a text file
3. import the points into GeoGebra
4. connect in GeoGebra the points using segments and polygons
5. export to SVG

This was the easiest way I could think of for creating SVG files using 
perspective projection.

Mike

[Mike Horvath] Re: CIE Shapes [3294 days 11 hours and 53 minutes ago]

Thu, 30 Mar 2017 20:23:51 GMT

On 3/30/2017 12:01 AM, Mike Horvath wrote:
> I decided to ditch the isosurfaces and go with meshes only. Now the
> scenes render in a few seconds instead of half a day.
>
>
> Mike

This makes making animations feasible, I should have added.


Mike

[Mike Horvath] Re: CIE Shapes [3295 days 4 hours and 15 minutes ago]

Thu, 30 Mar 2017 04:01:09 GMT

On 3/27/2017 11:45 PM, Mike Horvath wrote:
> Latest version modifies the cylinders to use the same horizontal
> dimensions as the boxes. This way, the figures in each diagram match up
> better.
>
> http://www.mediafire.com/file/8hbhlccdg2nuhhu/wp_cie_shapes_20170327.zip
>
>
> Mike


Latest versions:

http://www.mediafire.com/file/71haso9k6h5213x/wp_cie_color_solids_src_20170330.zip
http://www.mediafire.com/file/999o6uctj9zfsj9/wp_cie_color_solids_img_20170330.zip

I decided to ditch the isosurfaces and go with meshes only. Now the 
scenes render in a few seconds instead of half a day.


Mike

[Mike Horvath] Re: CIE Shapes [3297 days 4 hours and 31 minutes ago]

Tue, 28 Mar 2017 03:45:22 GMT

Latest version modifies the cylinders to use the same horizontal 
dimensions as the boxes. This way, the figures in each diagram match up 
better.

http://www.mediafire.com/file/8hbhlccdg2nuhhu/wp_cie_shapes_20170327.zip


Mike

[Mike Horvath] Re: CIE Shapes [3298 days 6 hours ago]

Mon, 27 Mar 2017 02:16:50 GMT

On 3/22/2017 9:50 PM, Mike Horvath wrote:
> Here are the final versions of my CIE color solid scripts:
>
> http://www.mediafire.com/file/13aikfkbqgtrgzs/wp_cie_shapes_20170322.zip
>
> Inside you'll find examples of the visible and sRGB gamuts plotted
> within different color spaces, such as CIExyY, CIEXYZ, CIELAB, CIELUV,
> CIELCHab and CIELCHuv. The D65 whitepoint is used in all these images.
>
> You can view the renders on my Wikimedia Commons user page:
>
> https://commons.wikimedia.org/wiki/User:SharkD
>
> I don't have any plans to continue further with this project. The
> scripts are licensed under the LGPL, just like the Object Collection.
>
> Enjoy!
>
>
> Mike

Update. I forgot the spherical versions needed a donut hole in the 
middle. Also, increased the coordinate axes scale for the CIELAB solids, 
since their corners were sometimes poking out the sides.

http://www.mediafire.com/file/9sn87h607x6zp8i/wp_cie_shapes_20170326.zip


Mike

[Thomas de Groot] Water-and-foam-fringe along a coastline [3298 days 20 hours and 33 minutes ago]

Sun, 26 Mar 2017 11:43:13 GMT

I used the attached code in my latest image version of /Stranger Moon/. 
See p.b.i.

To my knowledge, only Zeger Knaepen and Jaime Vives Piqueres have added 
this feature to their landscape scenes, both back in 2004 so I do not 
know who was first.

- I studied both their - admittedly - very complex /isosurface/ 
landscapes and extracted the relevant codes for my own designs.

- I changed the code for height_field use as I generally find 
isosurfaces too slow for regular use.

- I 'improved' the work flow somewhat and 'improved' the foam texture 
more in particular.

- I put the code inside a demo scene for better accessibility of the 
feature, so that more people will be tempted to use it in future.

By all means, feel free to change and improve upon the code

-- 
Thomas

[Dave Blandston] Re: Bordered Characters version 1.6 [3299 days 3 hours and 47 minutes ago]

Sun, 26 Mar 2017 04:30:00 GMT

dick balaska <dic### [at] buckosoftcom> wrote:
> I'd like to see another font. A serif font would be nice. ;)
>
> Also, you should put this in the Object Collection.
>
> --
> dik

Oh my, adding serifs would be a huge job. I'll add the scene files to the Object
Collection though when I'm certain the project is completely done.

Regards,
Dave Blandston

[Mike Horvath] CIE Shapes [3302 days 6 hours and 26 minutes ago]

Thu, 23 Mar 2017 01:50:32 GMT

Here are the final versions of my CIE color solid scripts:

http://www.mediafire.com/file/13aikfkbqgtrgzs/wp_cie_shapes_20170322.zip

Inside you'll find examples of the visible and sRGB gamuts plotted 
within different color spaces, such as CIExyY, CIEXYZ, CIELAB, CIELUV, 
CIELCHab and CIELCHuv. The D65 whitepoint is used in all these images.

You can view the renders on my Wikimedia Commons user page:

https://commons.wikimedia.org/wiki/User:SharkD

I don't have any plans to continue further with this project. The 
scripts are licensed under the LGPL, just like the Object Collection.

Enjoy!


Mike

[dick balaska] Re: Bordered Characters version 1.6 [3307 days 17 hours and 50 minutes ago]

Fri, 17 Mar 2017 14:26:33 GMT

Am 2017-03-17 07:18, also sprach Dave Blandston:
> Another minor update... Includes a couple obscure bug fixes, re-numbering of the
> last couple Font Variations, and a new star-shape character.
>
> I'm pretty certain this project is done.

I'd like to see another font. A serif font would be nice. ;)

Also, you should put this in the Object Collection.

-- 
dik

[Dave Blandston] Re: Bordered Characters version 1.6 [3307 days 20 hours and 57 minutes ago]

Fri, 17 Mar 2017 11:20:01 GMT

Another minor update... Includes a couple obscure bug fixes, re-numbering of the
last couple Font Variations, and a new star-shape character.

I'm pretty certain this project is done. I know I said that a long time ago but
I haven't added anything significant for quite a while and the things that
aren't perfect would take too long to fix. If I find any more bugs I'll post
fixes but that's probably about it.

Regards,
Dave Blandston

[William F Pokorny] Local density by functions ("proximity pattern")... [3320 days 14 hours and 5 minutes ago]

Sat, 4 Mar 2017 18:11:30 GMT

See attached:

[omniverse] Re: MegaPOV mountains lakes circa 2001 [3341 days 2 hours and 2 minutes ago]

Sun, 12 Feb 2017 06:15:00 GMT

Regarding current changes to this SDL, most recent file attached here.
Following is from the posting at binaries.animations:

New and improved, and maybe that's saying too much. LOL

Too large a file for here, almost 7 MB.

https://youtu.be/aLwYm9aBQ80

Still a wild ride because of a crumbling natural bridge fly-thru, and my sloppy
attempt at slowing the flight at that point in the animation. I messed up the
cubic spline path there, it was supposed to move slowly past the natural bridge.
Timed it wrong.

No worries, you can retry it yourself. Posting the updated scene file at
binaries.scene-files once again. Better clouds in motion and casting shadows.
Although parameters are minimal quality, for isosurface too, for faster frame
rendering.

At least I got rid of the annoying camera discontinuities caused by adding
different vectors together from one clock range to the next, see previous SDL.

This particular animation, 320X240 and 600 frames with default antialiasing,
took about 10 hours on a i5 processor @ 3.4GHz.

Bob

[Thomas de Groot] Re: MegaPOV mountains lakes circa 2001 [3342 days 20 hours and 1 minute ago]

Fri, 10 Feb 2017 12:15:48 GMT

I see what Christoph and you are meaning. I am busy with another POV 
scene at the moment but I need to test this out myself too...

-- 
Thomas

[omniverse] Re: MegaPOV mountains lakes circa 2001 [3342 days 20 hours and 27 minutes ago]

Fri, 10 Feb 2017 11:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 10.02.2017 um 11:15 schrieb omniverse:
>
> > This had me looking at slope pattern in the documentation and something I wasn't
> > aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
> > it.
> ...
> > Food for thought anyhow, because it seems like it would be what SunPosition is
> > made for.
>
> Only if the sun is supposed to be very close, so that its rays are
> supposed to be noticeably non-parallel. Otherwise the direction vector
> would probably be the better choice.

Hmm. I think I know what you're saying, which is direction vector easier and
that point_at is intended for more localized behavior of slope.
At least that's my guess.

I just tried something with point_at anyway, going by your saying 'sun very
close'.

Took the SunPosition numbers given by it's dot x y and z.
Divided those (less decimals) into the slope SunPosition for the point_at and it
resembled the direction vector method.
Not the same as direction only, but similar perhaps.

#declare pigment3 =
pigment {
  slope {
    point_at
    <SunPosition.x/818827576,SunPosition.y/163128554,SunPosition.z/550373032>/2
....

[clipka] Re: MegaPOV mountains lakes circa 2001 [3342 days 21 hours and 50 minutes ago]

Fri, 10 Feb 2017 10:26:09 GMT

Am 10.02.2017 um 11:15 schrieb omniverse:

> This had me looking at slope pattern in the documentation and something I wasn't
> aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
> it.
...
> Food for thought anyhow, because it seems like it would be what SunPosition is
> made for.

Only if the sun is supposed to be very close, so that its rays are
supposed to be noticeably non-parallel. Otherwise the direction vector
would probably be the better choice.

[omniverse] Re: MegaPOV mountains lakes circa 2001 [3342 days 21 hours and 57 minutes ago]

Fri, 10 Feb 2017 10:20:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 9-2-2017 14:40, omniverse wrote:
> > Maybe too slow for (quick) animation, I was surprised how long it took when trying
it
> > here. Maybe it's that radiosity, easily skipped.
>
> It is a slow process indeed. I still intend to study this scene more
> closely. I find the differential snow cover very tempting to use one way
> or another in a scene.

You're sure to get something interesting rendered.

This had me looking at slope pattern in the documentation and something I wasn't
aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
it.

http://wiki.povray.org/content/Reference:Slope_Pattern

Since point_at isn't used in the snow slope pattern I'm guessing a change to
that might need adjustment, since the doc says altitude can't be used in
conjunction with point_at.
Although, looking again at the scene file altitude is not used anyway!

Food for thought anyhow, because it seems like it would be what SunPosition is
made for.

Bob

[Thomas de Groot] Re: MegaPOV mountains lakes circa 2001 [3343 days and 21 minutes ago]

Fri, 10 Feb 2017 07:55:08 GMT

On 9-2-2017 14:40, omniverse wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 9-2-2017 2:02, omniverse wrote:
>>
>> Could this attached file help? It is from Bob Hughes (2003). It is not
>> an animation but I think the scene's purpose is identical.
>
> Wow Thomas! Another oldie (also from me BTW).

Hi Bob, I had not immediately made the connection :-)

> Maybe too slow for animation, I was surprised how long it took when trying it
> here. Maybe it's that radiosity, easily skipped.

It is a slow process indeed. I still intend to study this scene more 
closely. I find the differential snow cover very tempting to use one way 
or another in a scene.

>
> I was able to get that old MegaPOV animation to render. What was stopping me
> before was the old style slope pattern, only needed newer syntax.
>
> And the animation started below the landscape so I changed the noise type
> (actually didn't have one before) for the isosurface f_ridged_mf function.
>
> That modified scene file is attached here, despite needing much more done to it.
>
> Bob
>


-- 
Thomas

[omniverse] Re: MegaPOV mountains lakes circa 2001 [3343 days 14 hours and 17 minutes ago]

Thu, 9 Feb 2017 18:00:01 GMT

In my rush to post that 3.7-renderable file I neglected to notice the viewpoint
changes abruptly during animation. Apparently made to be like camera changes or
a look right and left, so not just ahead in flight path. Very confusing in a
very short animation.
Not only that, but the clocked splines are cubic and don't seem to have correct
beginning or ends. Of course I can only guess what was originally done without a
long time going over it again.

Suffice to say, replacing with the following seems better than it was, if you
would like to try this:

#declare CamSpos=
spline {
        cubic_spline
        -0.1,<.05,.1,-9.5>*CamDist // added
        0,<.1,.167,-9>*CamDist
        .1,<.15,.29,-8.75>*CamDist
        .175,<.225,.33,-8.5>*CamDist
        .225,<.5,.425,-8.125>*CamDist
        .5,<0,.4125,-7>*CamDist
        .775,<-.5,.425,-6>*CamDist
        .875,<-.2,.3,-5.5>*CamDist
        .925,<-.125,.125,-5.25>*CamDist
        1,<-.05,.02,-5>*CamDist
        //1.1,<-.025,0,-4.5>*CamDist // added, not used
}

#declare CamSpnt=
spline {
        cubic_spline
        -0.1,<0,.1,-9> // added
        0,<.1,.2,-8.5>
        .1,<.15,.35,-8>
        .225,<.475,.275,-7.5>
        .33,<.225,.225,-7>
        .5,<0,.25,-6.75>
        .775,<-.475,.275,-5.5>
        .9,<-.133,.2,-5>
        .95,<-.1,.125,-4.75>
        1,<-.05,.02,-4.5>
       // 1.1,<-.025,0,-4> // added, not used
}

And I haven't tried anything with the flying car portion. I think Part=2 was
supposed to be for that. Not sure.

Bob

[omniverse] Re: MegaPOV mountains lakes circa 2001 [3343 days 18 hours and 32 minutes ago]

Thu, 9 Feb 2017 13:45:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 9-2-2017 2:02, omniverse wrote:
>
> Could this attached file help? It is from Bob Hughes (2003). It is not
> an animation but I think the scene's purpose is identical.

Wow Thomas! Another oldie (also from me BTW).
Maybe too slow for animation, I was surprised how long it took when trying it
here. Maybe it's that radiosity, easily skipped.

I was able to get that old MegaPOV animation to render. What was stopping me
before was the old style slope pattern, only needed newer syntax.

And the animation started below the landscape so I changed the noise type
(actually didn't have one before) for the isosurface f_ridged_mf function.

That modified scene file is attached here, despite needing much more done to it.

Bob

[Thomas de Groot] Re: MegaPOV mountains lakes circa 2001 [3343 days 23 hours and 46 minutes ago]

Thu, 9 Feb 2017 08:30:29 GMT

On 9-2-2017 2:02, omniverse wrote:
> This scene file isn't getting any younger! By that I mean it doesn't work with
> current version of MegaPOV (1.2.1) and I don't know how to correct for that yet.
>
> Posting this anyhow since I couldn't locate another SDL of it here at the
> newsgroups, and in response to animation of something very similar done almost
> 17 years ago:
>
>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.589bbb51d99c5e6b9c5d6c810%40news.povray.org%3E/
>
> Bob
>

Could this attached file help? It is from Bob Hugues (2003). It is not 
an animation but I think the scene's purpose is identical.

-- 
Thomas

[omniverse] MegaPOV mountains lakes circa 2001 [3344 days 7 hours and 12 minutes ago]

Thu, 9 Feb 2017 01:05:00 GMT

This scene file isn't getting any younger! By that I mean it doesn't work with
current version of MegaPOV (1.2.1) and I don't know how to correct for that yet.

Posting this anyhow since I couldn't locate another SDL of it here at the
newsgroups, and in response to animation of something very similar done almost
17 years ago:

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.589bbb51d99c5e6b9c5d6c810%40news.povray.org%3E/

Bob

[Dave Blandston] Re: Bordered Characters version 1.6 [3365 days 14 hours and 22 minutes ago]

Wed, 18 Jan 2017 17:55:00 GMT

This is a minuscule update that contains an animated demo of Font Variation #28
(which can be viewed here: youtube.com/watch?v=y02WPaJKuGI), as well as a minor
tweak to the Font Variation code.

Regards,
Dave Blandston

[Dave Blandston] Bordered Characters version 1.6 [3370 days 10 hours and 37 minutes ago]

Fri, 13 Jan 2017 21:40:01 GMT

This is a minor update. It contains a bug fix and a few new font variations. One
of them (#28) is particularly interesting and unique in that it allows any
object to fill the interior of the characters. Animating the interior object
would be a fun effect.

There are also two new characters: a dollar sign and an underscore.

Regards,
Dave Blandston

[Dave Blandston] Re: Bordered Characters version 1.5 [3370 days 23 hours and 47 minutes ago]

Fri, 13 Jan 2017 08:30:01 GMT

dick balaska <dic### [at] buckosoftcom> wrote:
> It is on my todo list to play with this. I'm looking forward to it.
> (My movie's opening credits need more pizazz.
>
> --
> dik

The next version (1.6) will have a font variation that's particularly suited to
animations. It will be #28. It allows the interior of the characters to be
filled with any object, so the interior object can be animated.

Regards,
Dave Blandston

[dick balaska] Re: Bordered Characters version 1.5 [3387 days 1 hour and 5 minutes ago]

Wed, 28 Dec 2016 07:11:12 GMT

Am 2016-11-20 17:27, also sprach Dave Blandston:
> Darn it! Use this one!
>
> Regards,
> Dave Blandston
>

:)

It is on my todo list to play with this. I'm looking forward to it.
(My movie's opening credits need more pizazz.

-- 
dik

[omniverse] Re: old chess scene modified again [3409 days 5 hours and 42 minutes ago]

Tue, 6 Dec 2016 02:35:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 05.12.2016 um 19:43 schrieb omniverse:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Try positive emission with a negative pigment ;)
> >
> > Except that wouldn't allow for a dark, yet positive value, color to likewise
> > darken its surroundings.
>
> If that's what you absolutely positively need, there's always the option
> to hide your proper object from radiosity using "no_radiosity", and
> setting up a menacingly dark radiosity stunt double using "no_image
> no_reflection no_shadow".
>
>
> > Of course, the more I think it over I don't know how much this would be
> > deviating from real world. Something I haven't checked into.
>
> Emit darkness? Why, yes - I guess that may need /some/ degree of
> deviating from real world :P

heh-heh-heh! Mmmm. Perhaps, perhaps. Did think about a stunt double thing,
although I would probably be the one doing the stunts trying to get that right.

Bob

[clipka] Re: old chess scene modified again [3409 days 11 hours and 14 minutes ago]

Mon, 5 Dec 2016 21:02:30 GMT

Am 05.12.2016 um 19:43 schrieb omniverse:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 05.12.2016 um 17:14 schrieb omniverse:
>>
>>> A test of 2 spheres, rgb 1 and rgb 0 both with emission -1, caused only a
>>> darkened area for the white (now black) sphere on a white plane.
>>> Black sphere with emission -1 made no change to the white plane below it.
>>>
>>> I take from this that color > 0 is required for emission to do anything. This in
>>> turn makes me think there should be some way to get a black or dark object to
>>> enhance the darkness around it.
>>
>> Try positive emission with a negative pigment ;)
> 
> Except that wouldn't allow for a dark, yet positive value, color to likewise
> darken its surroundings.

If that's what you absolutely positively need, there's always the option
to hide your proper object from radiosity using "no_radiosity", and
setting up a menacingly dark radiosity stunt double using "no_image
no_reflection no_shadow".


> Of course, the more I think it over I don't know how much this would be
> deviating from real world. Something I haven't checked into.

Emit darkness? Why, yes - I guess that may need /some/ degree of
deviating from real world :P

[omniverse] Re: old chess scene modified again [3409 days 13 hours and 7 minutes ago]

Mon, 5 Dec 2016 19:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
>
> > > I take from this that color > 0 is required for emission to do anything.
>
> I'd predict that based on 0 * -1 = 0.
>
> > This in
> > > turn makes me think there should be some way to get a black or dark object to
> > > enhance the darkness around it.
>
> Have it run for public office.  ;)  :D
>
> > Try positive emission with a negative pigment ;)
>
> :O  You'll blow something up for sure!

LOL Heck, I haven't had anything to do with politics since turning 18 years old
a few days before a presidential election. The only time (almost) I was ever
compelled to vote.

[omniverse] Re: old chess scene modified again [3409 days 13 hours and 32 minutes ago]

Mon, 5 Dec 2016 18:45:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 05.12.2016 um 17:14 schrieb omniverse:
>
> > A test of 2 spheres, rgb 1 and rgb 0 both with emission -1, caused only a
> > darkened area for the white (now black) sphere on a white plane.
> > Black sphere with emission -1 made no change to the white plane below it.
> >
> > I take from this that color > 0 is required for emission to do anything. This in
> > turn makes me think there should be some way to get a black or dark object to
> > enhance the darkness around it.
>
> Try positive emission with a negative pigment ;)

Except that wouldn't allow for a dark, yet positive value, color to likewise
darken its surroundings.

Of course, the more I think it over I don't know how much this would be
deviating from real world. Something I haven't checked into.

[Bald Eagle] Re: old chess scene modified again [3409 days 14 hours and 22 minutes ago]

Mon, 5 Dec 2016 17:55:01 GMT

clipka <ano### [at] anonymousorg> wrote:


> > I take from this that color > 0 is required for emission to do anything.

I'd predict that based on 0 * -1 = 0.

> This in
> > turn makes me think there should be some way to get a black or dark object to
> > enhance the darkness around it.

Have it run for public office.  ;)  :D

> Try positive emission with a negative pigment ;)

:O  You'll blow something up for sure!

[clipka] Re: old chess scene modified again [3409 days 15 hours and 16 minutes ago]

Mon, 5 Dec 2016 17:00:52 GMT

Am 05.12.2016 um 17:14 schrieb omniverse:

> A test of 2 spheres, rgb 1 and rgb 0 both with emission -1, caused only a
> darkened area for the white (now black) sphere on a white plane.
> Black sphere with emission -1 made no change to the white plane below it.
> 
> I take from this that color > 0 is required for emission to do anything. This in
> turn makes me think there should be some way to get a black or dark object to
> enhance the darkness around it.

Try positive emission with a negative pigment ;)

[Stephen] Re: old chess scene modified again [3409 days 15 hours and 51 minutes ago]

Mon, 5 Dec 2016 16:25:10 GMT

On 12/5/2016 4:14 PM, omniverse wrote:
> And as Stephen suggested, negative light color doesn't seem to adversely affect
> radiosity, as in uncontrollable way, so maybe there are possibilities with that.

You can use a non reflecting diffuse thin box as a fill in like they do 
in photography. If you make its colour negative it sucks the light out. 
Or so it seemed to me when I tried it.

-- 

Regards
     Stephen

[omniverse] Re: old chess scene modified again [3409 days 16 hours and 2 minutes ago]

Mon, 5 Dec 2016 16:15:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 05.12.2016 um 13:33 schrieb omniverse:
>
> > Sounds like I was under the wrong impression, thinking already dark areas would
> > get darker still.
> >
> > So this means the current way radiosity works is only to brighten upward from a
> > certain threshold (the actual pigment color, or lack of any) and never go lower?
>
> The lower threshold is actually the direct brightness from conventional
> light sources. In full shadow, that would be zero.
>
> But normally there's barely a crevice where radiosity-based illumination
> doesn't find a way in.

Okay. Wrapping my head around this, I believe. I had been thinking in terms of a
dual effect, namely illumination and anti-illumination.

And as Stephen suggested, negative light color doesn't seem to adversely affect
radiosity, as in uncontrollable way, so maybe there are possibilities with that.

This had me trying negative emission and I was surprised by the result, although
perhaps I shouldn't be based on what you've been saying.

A test of 2 spheres, rgb 1 and rgb 0 both with emission -1, caused only a
darkened area for the white (now black) sphere on a white plane.
Black sphere with emission -1 made no change to the white plane below it.

I take from this that color > 0 is required for emission to do anything. This in
turn makes me think there should be some way to get a black or dark object to
enhance the darkness around it.

[clipka] Re: old chess scene modified again [3409 days 17 hours and 57 minutes ago]

Mon, 5 Dec 2016 14:19:48 GMT

Am 05.12.2016 um 13:33 schrieb omniverse:

> Sounds like I was under the wrong impression, thinking already dark areas would
> get darker still. I just figured that would be how it would be, as though
> illumination drops. Ultimately to zero. I had thought in terms of a light fade
> for radiosity, of sorts. Like a shadow + dark color = darker shadow, or
> something along those lines of thinking.
> 
> So this means the current way radiosity works is only to brighten upward from a
> certain threshold (the actual pigment color, or lack of any) and never go lower?

The lower threshold is actually the direct brightness from conventional
light sources. In full shadow, that would be zero.

But normally there's barely a crevice where radiosity-based illumination
doesn't find a way in.

[Stephen] Re: old chess scene modified again [3409 days 18 hours and 35 minutes ago]

Mon, 5 Dec 2016 13:41:42 GMT

On 12/5/2016 12:33 PM, omniverse wrote:
> So this means the current way radiosity works is only to brighten upward from a
> certain threshold (the actual pigment color, or lack of any) and never go lower?


You could try negative light for darkening.

-- 

Regards
     Stephen

[omniverse] Re: old chess scene modified again [3409 days 19 hours and 42 minutes ago]

Mon, 5 Dec 2016 12:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 05.12.2016 um 06:42 schrieb omniverse:
> > Alain <kua### [at] videotronca> wrote:
> >> Le 16-12-04 à 15:29, omniverse a écrit :
> >>> "omniverse" <omn### [at] charternet> wrote:
> >>>
> >>> Specular highlights used for Ivory_M and Ebony_M material/texture/finish are
> >>> probably too bright unless used in conjunction with fresnel, a feature of
> >>> current unofficial 3.7.1.1-alpha versions.
> >>>
> >>
> >> Why does those finishes have any emission at all? Emission is only if
> >> you want a texture to actually glow, even if it's a very dim glow.
> >> Beter remove all emission everywhere, or set it at zero everywhere.
> >
> > Well, considering radiosity eliminates ambient lighting I just use a tiny bit of
> > emission to try and avoid any totally black areas. And also for a while now I've
> > been keeping ambient to much lower levels than the default 0.1 for non-radiosity
> > scenes, sometimes ambient 0 in lieu of a very low emission for the kind of
> > ambient lighting.
>
> But avoiding completely black areas _is_ radiosity's _job_ (when it is
> enabled).
>
> In this manner it differs fundamentally from ambient occlusion, which
> reduces the brightness of an image, especially where surfaces are close
> together. Radiosity, in contrast, brightens up things, especially where
> surfaces are far apart -- but it also does add some brightness to nooks
> and crannies.
>
> If you still see completely black areas, this can mean one of two (well,
> maybe three) things:
>
> (A) You have set `recursion_limit` too low. I'd recommend 1 or 2 for
> wide open outdoor scenes, but 2 or 3 for indoor scenes. Add another
> level if your scene has no conventional light sources and is illuminated
> exclusively from sky spheres, emissive materials or emissive media.
>
> (B) Your light sources are too bright and your materials too dark.
> Without radiosity this cancels out and you'll never be able to notice,
> but when radiosity enters the picture this makes nooks and crannies darker.
>
> (C Using a high assumed_gamma will also cause nooks and crannies to look
> darker, because the gamma's overall darkening effect is most pronounced
> for very dark tones.)
>
>
> An additional note to (A): When reaching the recursion limit, the
> radiosity algorithm currently presumes everything to be pitch black;
> i.e. if `recursion_limit 2` is set, the algorithm will pretend that
> light rays can't bounce around between diffuse surfaces more than twice.
> This has the effect that using a low recustion limit makes the entire
> image a tad darker than would be realistic (the most realistic setting
> would be infinity, but that's not realistically computable... pun intended).
>
> I have plans in my drawer to extend the radiosity algorithm, and make it
> respect "ambient" again -- but only once it reaches the recursion limit.
> This should have the effect of brightening up the scene just enough to
> approximately compensate for the lack of infinite recursion (provided
> "ambient" is set to a reasonable value).
>
> I might also add an ambient occlusion mode to the mix: If enabled, an
> incomplete recursion step would be made, querying only distance
> information, and using that to simply darken the effective "ambient"
> component.
>
> But that's future plans, so nobody hold their breath please...

I can hold my breath forever... as long as no one is looking.  ;)

I never use more than a recursion of 2 (of course I would be lying there),
mostly 1 or not set. So I still shy away from 3, from past experiences with
render time shock. Especially when impatiently experimenting on a scene.

Sounds like I was under the wrong impression, thinking already dark areas would
get darker still. I just figured that would be how it would be, as though
illumination drops. Ultimately to zero. I had thought in terms of a light fade
for radiosity, of sorts. Like a shadow + dark color = darker shadow, or
something along those lines of thinking.

So this means the current way radiosity works is only to brighten upward from a
certain threshold (the actual pigment color, or lack of any) and never go lower?

I always feel like the kid in school class who was daydreaming and not paying
attention. Oh yeah, I was that kid.  LOL

Bob

[clipka] Re: old chess scene modified again [3410 days 1 hour and 36 minutes ago]

Mon, 5 Dec 2016 06:40:58 GMT

Am 05.12.2016 um 06:42 schrieb omniverse:
> Alain <kua### [at] videotronca> wrote:
>> Le 16-12-04 à 15:29, omniverse a écrit :
>>> "omniverse" <omn### [at] charternet> wrote:
>>>
>>> Specular highlights used for Ivory_M and Ebony_M material/texture/finish are
>>> probably too bright unless used in conjunction with fresnel, a feature of
>>> current unofficial 3.7.1.1-alpha versions.
>>>
>>
>> Why does those finishes have any emission at all? Emission is only if
>> you want a texture to actually glow, even if it's a very dim glow.
>> Beter remove all emission everywhere, or set it at zero everywhere.
> 
> Well, considering radiosity eliminates ambient lighting I just use a tiny bit of
> emission to try and avoid any totally black areas. And also for a while now I've
> been keeping ambient to much lower levels than the default 0.1 for non-radiosity
> scenes, sometimes ambient 0 in lieu of a very low emission for the kind of
> ambient lighting.

But avoiding completely black areas _is_ radiosity's _job_ (when it is
enabled).

In this manner it differs fundamentally from ambient occlusion, which
reduces the brightness of an image, especially where surfaces are close
together. Radiosity, in contrast, brightens up things, especially where
surfaces are far apart -- but it also does add some brightness to nooks
and crannies.

If you still see completely black areas, this can mean one of two (well,
maybe three) things:

(A) You have set `recursion_limit` too low. I'd recommend 1 or 2 for
wide open outdoor scenes, but 2 or 3 for indoor scenes. Add another
level if your scene has no conventional light sources and is illuminated
exclusively from sky spheres, emissive materials or emissive media.

(B) Your light sources are too bright and your materials too dark.
Without radiosity this cancels out and you'll never be able to notice,
but when radiosity enters the picture this makes nooks and crannies darker.

(C Using a high assumed_gamma will also cause nooks and crannies to look
darker, because the gamma's overall darkening effect is most pronounced
for very dark tones.)

An additional note to (A): When reaching the recursion limit, the
radiosity algorithm currently presumes everything to be pitch black;
i.e. if `recursion_limit 2` is set, the algorithm will pretend that
light rays can't bounce around between diffuse surfaces more than twice.
This has the effect that using a low recustion limit makes the entire
image a tad darker than would be realistic (the most realistic setting
would be infinity, but that's not realistically computable... pun intended).

I have plans in my drawer to extend the radiosity algorithm, and make it
respect "ambient" again -- but only once it reaches the recursion limit.
This should have the effect of brightening up the scene just enough to
approximately compensate for the lack of infinite recursion (provided
"ambient" is set to a reasonable value).

I might also add an ambient occlusion mode to the mix: If enabled, an
incomplete recursion step would be made, querying only distance
information, and using that to simply darken the effective "ambient"
component.

But that's future plans, so nobody hold their breath please...

[omniverse] Re: old chess scene modified again [3410 days 2 hours and 32 minutes ago]

Mon, 5 Dec 2016 05:45:00 GMT

Alain <kua### [at] videotronca> wrote:
> Le 16-12-04 à 15:29, omniverse a écrit :
> > "omniverse" <omn### [at] charternet> wrote:
> >
> > Specular highlights used for Ivory_M and Ebony_M material/texture/finish are
> > probably too bright unless used in conjunction with fresnel, a feature of
> > current unofficial 3.7.1.1-alpha versions.
> >
>
> Why does those finishes have any emission at all? Emission is only if
> you want a texture to actually glow, even if it's a very dim glow.
> Beter remove all emission everywhere, or set it at zero everywhere.

Well, considering radiosity eliminates ambient lighting I just use a tiny bit of
emission to try and avoid any totally black areas. And also for a while now I've
been keeping ambient to much lower levels than the default 0.1 for non-radiosity
scenes, sometimes ambient 0 in lieu of a very low emission for the kind of
ambient lighting.

I'm used to the idea nothing is completely black unless in space or a cave, or
deep ocean. All of which could still have a very small amount of illumination
depending on the actual environs (glowing fish, phosphorescence) or perceived
unreal light at the eye. In other words I don't believe in total blackness.  :)

I don't expect anyone to use the exact scene as-is without making their own
changes too. I found the old scene warns about 'unusually high ambient' because
the original chess board uses ambient 0.35, and not only that they were using
assumed_gamma 2.2 so POV-Ray 3.7 really made them dark. Changing to
assumed_gamma 1.0 washes out the board.

Your question is very relevant, especially if considering this chess scene to
replace the current file in a new release of POV-Ray. And I did think that might
be a worthwhile thing to do later, but I wasn't going to ask yet. So for anyone
interested be my guest to discuss this further.

Bob

[Alain] Re: old chess scene modified again [3410 days 9 hours and 44 minutes ago]

Sun, 4 Dec 2016 22:32:43 GMT

Le 16-12-04 à 15:29, omniverse a écrit :
> "omniverse" <omn### [at] charternet> wrote:
>> Please note that I was trying
>> features from the latest releases of 3.7.1.1-alpha and UberPOV but it should be
>> suitable for rendering with official 3.7. They are commented out.
>
> Specular highlights used for Ivory_M and Ebony_M material/texture/finish are
> probably too bright unless used in conjunction with fresnel, a feature of
> current unofficial 3.7.1.1-alpha versions.
>
> Bob
>

Why does those finishes have any emission at all? Emission is only if 
you want a texture to actually glow, even if it's a very dim glow.
Beter remove all emission everywhere, or set it at zero everywhere.

[omniverse] Re: old chess scene modified again [3410 days 11 hours and 47 minutes ago]

Sun, 4 Dec 2016 20:30:00 GMT

"omniverse" <omn### [at] charternet> wrote:
> Please note that I was trying
> features from the latest releases of 3.7.1.1-alpha and UberPOV but it should be
> suitable for rendering with official 3.7. They are commented out.

Specular highlights used for Ivory_M and Ebony_M material/texture/finish are
probably too bright unless used in conjunction with fresnel, a feature of
current unofficial 3.7.1.1-alpha versions.

Bob

[omniverse] old chess scene modified again [3410 days 11 hours and 57 minutes ago]

Sun, 4 Dec 2016 20:20:01 GMT

I put together renders of that sample chess scene file that I has been around
since at least POV-Ray 2.2, compared with the chess2.pov of version 3.1g and
later.
Realized I must have added the missing(?) 2nd ear on the knight/horse before the
release of version 3.5. Never can remember if the single ear was intentional by
chess.pov scene creator Ville Saari.

Been slowly making changes to that scene file the past several months, turning
the chess set into an include file trimmed down for inclusion with any other
scene. Finally have both the inc and pov files able to render both ways, the
original and modified.

Made changes and additions to the chess pieces so that they more closely match
sizes with a contemporary Staunton set. Most changes done to the knight/horse to
add a mane, mouth and eyes; along with tweaking the overall shape.

Main thing besides was to get rid of the quadric-based shapes from the now-named
shapes_old.inc file so that it could be bypassed entirely. I replaced them with
isosurfaces (have I mentioned how bad I am with those?) and conventional
primitives instead.

It's not mathematical perfection, or clean considering the rescaling and
translate changes I had to do, but it seems to have worked okay.

I will post the files to p.b.s-f. for your review. Please note that I was trying
features from the latest releases of 3.7.1.1-alpha and UberPOV but it should be
suitable for rendering with official 3.7. They are commented out.

The needed chess-set_mod.inc to follow this message.

Bob

[Dave Blandston] Re: Bordered Characters version 1.5 [3424 days 9 hours and 47 minutes ago]

Sun, 20 Nov 2016 22:30:00 GMT

Darn it! Use this one!

Regards,
Dave Blandston

[Dave Blandston] Re: Bordered Characters version 1.5 [3424 days 9 hours and 57 minutes ago]

Sun, 20 Nov 2016 22:20:01 GMT

Oops, minor bug fix for new feature MinJustifiedParagraphWidth

Regards,
Dave Blandston

[Dave Blandston] Bordered Characters version 1.5 [3425 days 20 hours and 57 minutes ago]

Sat, 19 Nov 2016 11:20:00 GMT

Hello Folks,

Here's another version of the Bordered Characters project. Changes for this
version include significantly improved parsing speed for almost all scenes,
elimination of an unnecessary user setting, improvements to the upper-case "I"
and "J," improved kerning for normal-to-italic and italic-to-normal transitions,
fixed the bug that prevented reduced stroke widths from being compatible with
the scaled micro-justification method (bone-head move on my part), added a
workaround to the problem of some character widths being re-computed incorrectly
after stroke width reduction, and the addition of a new feature to match the
width of a Paragraph object with another scene element (probably another
Paragraph object). There are also some minor improvements to the sample scenes.

I've been having a lot of fun making bumper sticker designs with the bordered
characters. With a little effort I can always get the results I want.

Regards,
Dave Blandston

[Alain] Re: Fade in a complex mesh [3448 days 8 hours and 13 minutes ago]

Fri, 28 Oct 2016 00:04:04 GMT

Le 16-10-27 à 19:37, SecondCup a écrit :
> Hi,
>
> Any idea where I'm going wrong with this fade in? I want the CGL_band to be
> transparent then fade in gradually with each animated shot. Ive got it to fade
> to the gray un-textured solid, or Ive got it to fade into the texture from a
> black silhouette but cant figure out how to fade in the whole thing from
> transparent to fully visible...
>
> Here is the code and the "CGL_solid.inc" is attached
>
> #declare Sandy = color rgbt <1, .9, .35>;
>
> #declare Transmit = .8;
> #declare CM_Sandstone =
>
> colour_map{
>   [0.3 rgbt <1, 1, 1, 1.2*Transmit*(clock)>]
>   [0.4 rgbt <1, 0, 0, Transmit*(clock)>]
>   [0.41 rgbt <0.5, 0.3, 0.1, .5*Transmit*(clock)>]
>   [0.42 rgbt <1, 0, 0, .75*Transmit*(clock)>]
>   [0.6 rgbt <1, 0.5, 0, Transmit*(clock)>]
>   [0.7 rgbt <1, 1, 1, .5*Transmit*(clock)>]
>
>
> }
>
You want everything to have transmit 1 when clock reatch the value of 1. 
In your actual code, this can NEVER appen. At most, it tops at 0.96 for 
the first entry of your colour_map, and as low as 0.4 in the worst case.

Your «Sandy» don't have any transparency. It get expanded to rgbt<1, 
0.9, 0.35, 0>

You need your transmit to go from zero to one, or from one to zero.
This may work beter for a fade out:
colour_map{
   [0.3 rgbt <1, 1, 1, clock>]
   [0.4 rgbt <1, 0, 0, clock>]
   [0.41 rgbt <0.5, 0.3, 0.1, clock>]
   [0.42 rgbt <1, 0, 0, clock>]
   [0.6 rgbt <1, 0.5, 0, clock>]
   [0.7 rgbt <1, 1, 1, clock>]
}

For a fade in, try this:
colour_map{
   [0.3 rgbt <1, 1, 1, 1-clock>]
   [0.4 rgbt <1, 0, 0, 1-clock>]
   [0.41 rgbt <0.5, 0.3, 0.1, 1-clock>]
   [0.42 rgbt <1, 0, 0, 1-clock>]
   [0.6 rgbt <1, 0.5, 0, 1-clock>]
   [0.7 rgbt <1, 1, 1, 1-clock>]
}

If any texture need to have any transmiting transparency when fully 
visible, you need to restrict the range of your transmit accordingly.
Like this:
rgbt<1, 1, 1, 0.5+ 0.5*Transmit*clock>

If you have a filtering pigment, the filter need to drop to zero as the 
transmit reatch one.
Sample:
rgbft<1, 0.5, 0.12, 1*(1-clock), clock>
This is the only case where you need the parantesis.


Alain

[SecondCup] Fade in a complex mesh [3448 days 8 hours and 37 minutes ago]

Thu, 27 Oct 2016 23:40:01 GMT

Hi,

Any idea where I'm going wrong with this fade in? I want the CGL_band to be
transparent then fade in gradually with each animated shot. Ive got it to fade
to the gray un-textured solid, or Ive got it to fade into the texture from a
black silhouette but cant figure out how to fade in the whole thing from
transparent to fully visible...

Here is the code and the "CGL_solid.inc" is attached

#declare Sandy = color rgbt <1, .9, .35>;

#declare Transmit = .8;
#declare CM_Sandstone =

colour_map{
  [0.3 rgbt <1, 1, 1, 1.2*Transmit*(clock)>]
  [0.4 rgbt <1, 0, 0, Transmit*(clock)>]
  [0.41 rgbt <0.5, 0.3, 0.1, .5*Transmit*(clock)>]
  [0.42 rgbt <1, 0, 0, .75*Transmit*(clock)>]
  [0.6 rgbt <1, 0.5, 0, Transmit*(clock)>]
  [0.7 rgbt <1, 1, 1, .5*Transmit*(clock)>]


}

#declare FSandstone =
finish{
  diffuse 0.35 ambient 0.05
}

#declare TSandstone =
texture{
  pigment {Sandy
  turbulence 0.99}
  finish{FSandstone}
  normal {granite 5 scale 500}
}

#declare TStain = texture{
  pigment{
    //agate
    gradient <.3, 2, .1>//2
    turbulence 0.15
    colour_map{CM_Sandstone}
    scale 1000
  }
  finish{FSandstone}
}

#declare TSandstone1 =
texture{TSandstone}
texture{TStain}


//*********************************************
//
//               Include the solid from an external file
//
//*********************************************

#include "CGL_solid.inc"

object {CGLband
        texture {TSandstone1}
        translate <-723750,-422.035,-9092750>}

[Dave Blandston] Automatic Kerning [3455 days 20 hours and 7 minutes ago]

Thu, 20 Oct 2016 12:10:00 GMT

Hi Folks,

For anyone interested in kerning (I love kerning!) here's a demo file that uses
the trace () feature to compute kerning values. The demo uses the characters
from my "Bordered Characters" project, but it's pretty simple and can be adapted
for your use easily. The file of interest in the .zip archive is
"AutomaticKerningDemo.pov."

The method used was suggested by Bald Eagle. Thank you Bald Eagle!

Regards,
Dave Blandston

[omniverse] Re: test blob media for potential pattern [3462 days 1 hour and 47 minutes ago]

Fri, 14 Oct 2016 06:30:01 GMT

sorry again, there's another thing I noticed looking at the scene file I have
and had put here.
sturm keyword was left by itself in the first blob statement. Sturm was intended
to also have the #if directive line same as those for the pigment and density
statements.
Please be aware sturm needs to be left out for a cleaner render, otherwise you
will see bad artifacts.

On another note, I am trying a pre-declared instance of the blob statement and
using it as:

object
{
 Blob
}

to replace each full statement. You can easily do the same by cutting and
pasting the first blob {...} portion and #declare Blob= blob {...}

This will work like before, no problem here with:

potential {object{Blob}}

[omniverse] Re: test blob media for potential pattern [3462 days 6 hours and 7 minutes ago]

Fri, 14 Oct 2016 02:10:00 GMT

Sorry about the double post! Text of scene file was meant for the appropriate
group, not this one.

This file has Sturm=on and is to show bad artifacts, use Sturm=off to render
cleaner.

For version 3.71.

Bob

[omniverse] test blob media for potential pattern [3462 days 11 hours and 37 minutes ago]

Thu, 13 Oct 2016 20:40:01 GMT

Simple test of blob media using potential pattern of version 3.71.

[omniverse] test blob media for potential pattern [3462 days 11 hours and 42 minutes ago]

Thu, 13 Oct 2016 20:35:00 GMT

/* testing 'potential' pattern for blob object
 reason for patch was to attempt using reflection blur
 didn't realize potential pattern was not part of unofficial (yet?) */

// cmd: +w320 +h240 +a +ki0 +kf1 +kfi1 +kff50 +sf14 +ef14

#version 3.71;

//#version unofficial patch 3.71;
//#patch "upov-reflection-roughness" 0.9;

global_settings
{
 assumed_gamma on
 max_trace_level 9
}

#declare Blur=no; // camera focus/defocus

#declare CutOut=no; // cut away part of blob with box

#declare Sturm=on;

/*
background
{
 rgb 0
}
*/

sky_sphere
{
 pigment
 {
  function
  {
   abs(y)
  }
  color_map
  {
   [0 rgb <0.9,0.4,0.1>/2]
   [0.3 rgb <0.3,0.5,1>/2]
   [0.9 rgb <0.2,0.4,0.9>/2]
  }
  //turbulence 0.8
 }
}

light_source
{
 -99*z, 1
 media_interaction on
 media_attenuation off
 rotate <60,-30,0>
}

camera
{
 location -9*z
 look_at <0.75,0.5,0>
 angle 50
 #if (Blur=yes)
 focal_point 0
 aperture 0.6
 blur_samples 30,60
 variance 0.005
 #end
 rotate <22.5,22.5,0>
}

// floor
box
{
 <-9,-4,-9>,<9,-3,9>
 pigment
 {
  checker rgb 1 rgb 0
 }
}

// reflective ball
sphere
{
 0,3
 scale <1,1,0.25>
 rotate <0,60,0>
 translate <4,0,1>
 material
 {
  texture
  {
   pigment
   {
    rgb 0.4
   }
   finish
   {
    diffuse 0.1
    reflection
    {
     0.2,0.8
     //roughness 0.05
    }
   }
  }
 }
}

// blob with media
#if (CutOut=yes)
difference
{
 #end
blob
{
 sphere
 {
  <-1,-1,0>,1,2
 }
 sphere
 {
  <-1,1,0>,1,2
 }
 sphere
 {
  <1,1,0>,1,2
 }
 sphere
 {
  <1,-1,0>,1,2
 }
 sphere
 {
  0,1.5,1
 }
 cylinder
 {
  -x*(1+sin(clock*2*pi)),x*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -y*(1+sin(clock*2*pi)),y*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -z*(1+sin(clock*2*pi)),z*(1+sin(clock*2*pi)),0.75,2
 }
 sturm

#if (CutOut=yes)
}

box
{
 <-1.75,-1.75,-1.5>,<1.75,1.75,0>
}
#end

material
{
 texture
 {
  pigment
  {
   potential
   {
    blob
    {
     sphere
     {
      <-1,-1,0>,1,2
     }
     sphere
     {
      <-1,1,0>,1,2
     }
     sphere
     {
      <1,1,0>,1,2
     }
     sphere
     {
      <1,-1,0>,1,2
     }
     sphere // center
     {
      0,1.5,1
     }
 cylinder
 {
  -x*(1+sin(clock*2*pi)),x*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -y*(1+sin(clock*2*pi)),y*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -z*(1+sin(clock*2*pi)),z*(1+sin(clock*2*pi)),0.75,2
 }
 #if (Sturm=on) sturm #end
    } // blob
   } // potential
   threshold on
   color_map
   {
    [0 red 1 transmit 0.99] [0.5 green 1 transmit 0.99] [1 blue 1 transmit 0.99]
   }
  } // pigment
 } // texture
 interior
 {
  media
  {
   method 3
   samples 33
   jitter 0.9
   emission 0.4
   absorption 0.1
   scattering
   {
    1, 0.6
   }
  density
  {
   potential
   {
    blob
    {
     sphere
     {
      <-1,-1,0>,1,2
     }
     sphere
     {
      <-1,1,0>,1,2
     }
     sphere
     {
      <1,1,0>,1,2
     }
     sphere
     {
      <1,-1,0>,1,2
     }
     sphere
     {
      0,1.5,1
     }
 cylinder
 {
  -x*(1+sin(clock*2*pi)),x*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -y*(1+sin(clock*2*pi)),y*(1+sin(clock*2*pi)),0.75,2
 }
 cylinder
 {
  -z*(1+sin(clock*2*pi)),z*(1+sin(clock*2*pi)),0.75,2
 }
 #if (Sturm=on) sturm #end
    } // blob
   } // potential
   threshold on
   density_map
   {
    [0 red 1] [0.5 green 1] [1 blue 1]
   }

  } // density
  } // media
 } // interior
} // material
rotate <0,clock*360,0>
hollow on
} // difference or blob

[Thomas de Groot] Re: Treat a mesh as an isofunction [3475 days 1 hour and 26 minutes ago]

Sat, 1 Oct 2016 06:51:04 GMT

On 30-9-2016 20:39, SecondCup wrote:
> Thank you for the advice Thomas, it's really appreciated.
>
> I scaled it to 500 and added some turbulence. It looks pretty good. Now to fine
> tune the lighting :)
>

You are welcome :-)

To my remark concerning Poseray's Subdivision and Displacement, I must 
add that the quality of the original object is crucial of course. I 
noticed that the pancakes were rather simple meshes so the above would 
not change much at all. A better initial mesh should be preferred. and 
would give more interesting results.

-- 
Thomas

[SecondCup] Re: Treat a mesh as an isofunction [3475 days 13 hours and 37 minutes ago]

Fri, 30 Sep 2016 18:40:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 29-9-2016 21:25, SecondCup wrote:
> > Hi,
> >
> > I'm wondering if there is a way to treat a mesh2 as an isosurface. I'm pretty
> > new to pov-ray (some will notice my regular contribution to the 'newusers'
> > forum) so still figuring out a lot of the stuff. This one might be straight
> > forward.
>
> As far as I know: no.
>
> >
> > I have a mesh2 file of something that looks like a few pancakes layered on top
> > of one another. This was created using Accutrans that converted my
> > wireframe/solid/whatever-ya-wanna-call-it.dxf into a .pov file (version 3.5).
> > I want to make these pancake type surfaces look like they are stone, or a
> > roughly chiseled piece of rock.
> >
> > Looking around online, I found an excellent rendering of a sandstone by PM 2Ring
> > on this site. The wrinkly patterns and depth of the bumps are perfect for what I
> > am looking for. Is it possible to make my pancake-type-thingy.pov have the same
> > texture as the sandstone in PM 2Ring's code?
>
> Yes. Although the pancakes are very smooth, to get a stone-like effect
> you need to add a normal to the texture and play with scale and rotation
> to get the effect you desire.
>
> The isosurface PM2Ring is using is sufficiently rough by itself to just
> use the texture without a normal. The pancakes on the other hand are too
> smooth and you have to adapt to get a similar effect. Note that my
> example is only one of many. You should play with all the possibilities
> offered by POV-Ray to get what you want.
>
> One thing I would like to suggest, if you want to go along with these
> pancakes, is to try and use 'Subdivision' and then 'Displacement' in
> Poseray. That way you would make the pancakes much more interesting.
>
> >
> > He uses functions and isosurfaces that I'm still trying to get my head around,
> > is there someone out there who can tell me if they are mergeable?
>
> As said above, no.
>
> >
> > Attached are both codes...You'll notice I have been able to incorporate the
> > colours into my file.
> >
>
> I re-attach the file with a couple of additions/corrections. Switch off
> most of the fill-in lights. Set to version 3.7 and standard assumed_gamma 1.
>
> --
> Thomas

Thank you for the advice Thomas, it's really appreciated.

I scaled it to 500 and added some turbulence. It looks pretty good. Now to fine
tune the lighting :)

[Thomas de Groot] Re: Treat a mesh as an isofunction [3476 days and 58 minutes ago]

Fri, 30 Sep 2016 07:18:33 GMT

On 29-9-2016 21:25, SecondCup wrote:
> Hi,
>
> I'm wondering if there is a way to treat a mesh2 as an isosurface. I'm pretty
> new to pov-ray (some will notice my regular contribution to the 'newusers'
> forum) so still figuring out a lot of the stuff. This one might be straight
> forward.

As far as I know: no.

>
> I have a mesh2 file of something that looks like a few pancakes layered on top
> of one another. This was created using Accutrans that converted my
> wireframe/solid/whatever-ya-wanna-call-it.dxf into a .pov file (version 3.5).
> I want to make these pancake type surfaces look like they are stone, or a
> roughly chiseled piece of rock.
>
> Looking around online, I found an excellent rendering of a sandstone by PM 2Ring
> on this site. The wrinkly patterns and depth of the bumps are perfect for what I
> am looking for. Is it possible to make my pancake-type-thingy.pov have the same
> texture as the sandstone in PM 2Ring's code?

Yes. Although the pancakes are very smooth, to get a stone-like effect 
you need to add a normal to the texture and play with scale and rotation 
to get the effect you desire.

The isosurface PM2Ring is using is sufficiently rough by itself to just 
use the texture without a normal. The pancakes on the other hand are too 
smooth and you have to adapt to get a similar effect. Note that my 
example is only one of many. You should play with all the possibilities 
offered by POV-Ray to get what you want.

One thing I would like to suggest, if you want to go along with these 
pancakes, is to try and use 'Subdivision' and then 'Displacement' in 
Poseray. That way you would make the pancakes much more interesting.

>
> He uses functions and isosurfaces that I'm still trying to get my head around,
> is there someone out there who can tell me if they are mergeable?

As said above, no.

>
> Attached are both codes...You'll notice I have been able to incorporate the
> colours into my file.
>

I re-attach the file with a couple of additions/corrections. Switch off 
most of the fill-in lights. Set to version 3.7 and standard assumed_gamma 1.

-- 
Thomas

[SecondCup] Re: Treat a mesh as an isofunction [3476 days 12 hours and 27 minutes ago]

Thu, 29 Sep 2016 19:50:01 GMT

Sorry the title should read "Treat a mesh2 as an isosurface"

[SecondCup] Treat a mesh as an isofunction [3476 days 12 hours and 47 minutes ago]

Thu, 29 Sep 2016 19:30:01 GMT

Hi,

I'm wondering if there is a way to treat a mesh2 as an isosurface. I'm pretty
new to pov-ray (some will notice my regular contribution to the 'newusers'
forum) so still figuring out a lot of the stuff. This one might be straight
forward.

I have a mesh2 file of something that looks like a few pancakes layered on top
of one another. This was created using Accutrans that converted my
wireframe/solid/whatever-ya-wanna-call-it.dxf into a .pov file (version 3.5).
I want to make these pancake type surfaces look like they are stone, or a
roughly chiseled piece of rock.

Looking around online, I found an excellent rendering of a sandstone by PM 2Ring
on this site. The wrinkly patterns and depth of the bumps are perfect for what I
am looking for. Is it possible to make my pancake-type-thingy.pov have the same
texture as the sandstone in PM 2Ring's code?

He uses functions and isosurfaces that I'm still trying to get my head around,
is there someone out there who can tell me if they are mergeable?

Attached are both codes...You'll notice I have been able to incorporate the
colours into my file.

[Dave Blandston] Bordered Characters version 1.4 [3480 days 1 hour and 17 minutes ago]

Mon, 26 Sep 2016 07:00:01 GMT

Hi Folks,

I know that I said I was done working on this project a long time ago and yet
here's another version. I guess I have zero credibility around here by now.

This version has some great improvements though. I fine-tuned the lowercase
letters "a," "h," "n," "s," and "u," and corrected a glitch in the uppercase
"G."

A new feature called "Font Styles" allows embedded formatting codes that make it
easy to use multiple styles of characters in the same line.

Another exciting new feature is a micro-justification method called "SCALED."
I'll post a sample in the images forum to demonstrate it.

There is one new font variation available (#22) that can be used to create a
"drop shadow" effect. It's also somewhat interesting as a stand-alone variation.

As usual, the new version also includes some minor bug fixes, increased
ease-of-use, and improvements to the documentation. The sample demonstration
files have been updated to illustrate the new features, and there are two new
sample scenes. One of them is even interactive (somewhat) to demonstrate another
new feature.

As always, I hope some people find this useful!

Regards,
Dave Blandston

[AQ] Harmonagraph [3482 days 16 hours ago]

Fri, 23 Sep 2016 16:16:25 GMT

This is the scene file for the Harmonagraph

AQ
// Persistence of Vision Ray Tracer Scene Description File
// File: Harmonograph xx.pov
// Vers: 3.7 

// Desc: Simulation of a 2 pendulum harmonograph
// Date: September 2016
// Auth: John Cranmer

#version 3.7;

global_settings { 
  assumed_gamma 1.0
} 

#declare Single_Col     = rgb <1.0, 0.5, 0.2>;   // single colour pattern 
#declare Rainbow        = true;                  // rainbow coloured trace. Single
colours do not work well
#declare Rand_Col       = false;                 // randomised colour map
#declare R              = seed (99);             // seed for random number generation

#declare Radius         = 0.02;                  // radius of the cylinders used to
draw the pattern (0.01 to 0.05)
#declare Number         = 250000;                // Number of points to draw  (100,000
to 250,000 work)
#declare r              = 1.5/Number;      
#declare S              = 12;                    // scale factor for drawing 
#declare Front_to_Back  = true;                  // draw front to back or back to
front - as cylinders are offset in z makes a considerable difference
#declare xScale         = 1.3;

#declare f1             = 1.25;                   // frequency
#declare f2             = 7.5;
#declare f3             = 8;
#declare f4             = 5;

#declare a1             = 180;                    // initial offset
#declare a2             = 90;
#declare a3             = 0;
#declare a4             = 45;

#declare e              = 2.71828183;

// ******************************************************************************** 
camera {
  location < 0, 0,-80>
  look_at  < 0, 0,  0> 
  right x * image_width / image_height
  angle 50
}

light_source { 
  -z * 200
  color 1
  shadowless
}

background { rgb 0.5 }                                                

// ********************************************************************************
// Load colour values into the array
#declare Col = array[7][4]
#for (j,0,6,1)
  #for (k,1,3,1)
    #declare Col[j][k] = int(2*rand(R));
  #end
#end  


// Calculate initial start point
#declare n = 0;    
#declare xnew = S * pow(e,-r*n) * (sin(radians(f1 * 2*n + a1)) + sin(radians(f2 * n +
a2)));     // NB THE CHANGE IN THIS LINE
#declare ynew = S * pow(e,-r*n) * (sin(radians(f3 * n + a3)) + sin(radians(f4 * n +
a4)));

#declare n = 1;
#if (Front_to_Back = true)
  #declare FB =  1; 
#else
  #declare FB = -1;
#end
 
#declare Harmonograph = union {
  #while  ( n < Number )
    #declare xold = xnew;
    #declare yold = ynew;
    #declare xnew = S * pow(e,-r*n) * (sin(radians(f1 * 2*n + a1)) + sin(radians((f2 *
n + a2))));       // NB THE CHANGE IN THIS LINE as well 
    #declare ynew = S * pow(e,-r*n) * (sin(radians(f3 * n + a3)) + sin(radians((f4 * n
+ a4))));
    cylinder { <xold, yold, FB*n*0.02/Number> <xnew, ynew, FB*n*0.02/Number> Radius 
      texture {
        #if ( Rainbow = true)
          #if (Rand_Col = true)
            pigment {
              function { n / Number }                  // change colour for each
cylinder
              colour_map {
                [0.0/6  rgb < Col[0][1], Col[0][2], Col[0][3] >]        
                [1.5/6  rgb < Col[1][1], Col[1][2], Col[1][3] >] 
                [2.0/6  rgb < Col[2][1], Col[2][2], Col[2][3] >] 
                [3.0/6  rgb < Col[3][1], Col[3][2], Col[3][3] >] 
                [4.0/6  rgb < Col[4][1], Col[4][2], Col[4][3] >] 
                [5.0/6  rgb < Col[5][1], Col[5][2], Col[5][3] >] 
                [6.0/6  rgb < Col[6][1], Col[6][2], Col[6][3] >]
              }
            }
          #else
            pigment {
              function { n / Number }                 
              colour_map {
                [0.0/6  rgb < 0, 0, 1 >]        
                [1.5/6  rgb < 1, 0, 1 >] 
                [2.0/6  rgb < 1, 0, 0 >] 
                [3.0/6  rgb < 1, 1, 0 >] 
                [4.0/6  rgb < 0, 1, 0 >] 
                [5.0/6  rgb < 0, 1, 1 >] 
                [6.0/6  rgb < 0, 0, 1 >]
              }
            }
          #end  
        #else
          pigment { Single_Col }
        #end
      } 
    }
    #declare n = n + 1;
  #end 
}

// Draw the pattern
object { Harmonograph
  scale x * xScale 
  translate x * 0 
  rotate z * 0  
}

[Stephen] Re: Wrong normal direction on triangle{ }s [3515 days 11 hours and 42 minutes ago]

Sun, 21 Aug 2016 20:34:11 GMT

Ooo! Barley Sugar twists. Lovely :)


On 8/21/2016 8:10 PM, architype wrote:
> BTW is it possible to make a mesh solid and CSG subtract it from a box for
> instance?

If the mesh is closed and has an inside vector, yes.


-- 

Regards
     Stephen

[architype] Re: Wrong normal direction on triangle{ }s [3515 days 13 hours and 2 minutes ago]

Sun, 21 Aug 2016 19:15:01 GMT

I think a low res version, preferably with some slight scrambling of the
surface,
will be very useful for all sorts of stuff. For instance a spiral column, I have
done some quick testing, see the image. (I was supposed to be working... :p)

I used multiple objects inside the mesh command so that I could form a section
of
the column, ie a spiral. Which I then reused to make the column.
The columns are not smooth, and they are not supposed to be.
A scrambling/randomizing will make the surface uneven and remove the "pattern".
(I havent figured out how to add some random noise yet, only how to translate
the
"sphere" structure inside the mesh.)

Of course a smoother version will be useful for making a mesh of several
spheres,
that must be useful for doing architecture. (Ie saving loads of objects that
would require resources.)

Also, I think this should be faster than a blob for making a spiral. And the
blob
would have a smooth surface that would not be so easy to scramble/make uneven.

BTW is it possible to make a mesh solid and CSG subtract it from a box for
instance?
Best wishes, /A

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3515 days 21 hours and 17 minutes ago]

Sun, 21 Aug 2016 11:00:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> Then you must be using a different code than the one you posted. (Note
> that the posted code doesn't actually show the icosahedron at all, only
> the subdivided result.)

<banging head>
Looking the two over, that must be true.
I've been squeezing in new work and edits as I can, and it's been hot as blazes,
and I can see how I might have lost track of what got edited and fixed.  I
probably saw your correction and implemented it immediately afterwards as I was
coding the rest of the expansion macro.
Sorry. :O
I need better archiving and version control.

> It gives you the same set of vertices, but ordered differently, thus
> giving you a different set of triangles.

Yes, that makes sense.
That was a hard one to "see" and get ordered correctly without losing track.
I think I either need even _more_ practice at being able to see it all and keep
track of it in my head, or come up with a better way to rapidly visualize what I
need to do.  But this was definitely a valuable experiment.

> No, the smooth_triangles issue is also present in (smooth) meshes.

But to a far lesser extent?  Those few green pixels are present on the basis
array icosahedron.  The smooth_triangle objects have a LOT more green present
even in the first two subdivisions.  Only the third iteration seems to finally
get it smooth enough to be all red, since I guess the edges are finely divided
enough to overcome that effect.

Quite a nice demonstration of how simple it is to just instantiate a sphere{}
primitive and be done with!  ;)

[architype] Re: Wrong normal direction on triangle{ }s [3515 days 22 hours and 42 minutes ago]

Sun, 21 Aug 2016 09:35:01 GMT

>These would make a very nice basis for anyone who wanted crystals, 3D
>snowflakes, etc.

I like the idea of a 3D snowflake. :)

[clipka] Re: Wrong normal direction on triangle{ }s [3516 days 10 hours and 22 minutes ago]

Sat, 20 Aug 2016 21:54:13 GMT

Am 20.08.2016 um 23:22 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>> One thing is for sure: You've seriously screwed up on the icosahedron.
>>
>> Apparently you misinterpreted the positions of the individual points,
>> probably thinking that Phi<1, but in fact Phi>1.
>>
>> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
>> regular icosahedron.
> 
> Are you just pulling my leg now?
> Because my definition of Phi is in the code, and when I comment out ALL of the
> vnormalize() directives, I get ... an icosahedron.

Then you must be using a different code than the one you posted. (Note
that the posted code doesn't actually show the icosahedron at all, only
the subdivided result.)

> And considering that the vertices are defined by ALL of the permutations of
> +/-1, 0, and +/-Phi, I don't see how "swapping" those values in any given vertex
> doesn't just give me ... another one of the points I already have.

It gives you the same set of vertices, but ordered differently, thus
giving you a different set of triangles.

> I'm going to add a little bit to my code to visualize the vertex normals of the
> smooth_triangles, because I'm having a devil of a time visualizing your
> description of how that all works at the moment.  Your explanation of the
> situation is perfectly clear - the 3D result of that is just [for me] less so.
> 
> Please also notice that there are a few green pixels in/on the lower left MESH
> icosahdron - the rotate y*180 degree instance.  A small, but seemingly important
> detail, if using mesh{} is supposed to eliminate that problem.

No, the smooth_triangles issue is also present in (smooth) meshes.

> I haven't declared an inside_vector  -  could it be related in some way to that?

Nope, that's unrelated.

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3516 days 10 hours and 37 minutes ago]

Sat, 20 Aug 2016 21:40:01 GMT

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

> Also, if only _some_ of the vertices are normalized to the unit sphere radius,
> some very nice stellated / fractal shapes are produced.


Here they are - the basis array vertices are normalized, the face-edge midpoints
are not.

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3516 days 10 hours and 52 minutes ago]

Sat, 20 Aug 2016 21:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> One thing is for sure: You've seriously screwed up on the icosahedron.
>
> Apparently you misinterpreted the positions of the individual points,
> probably thinking that Phi<1, but in fact Phi>1.
>
> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.

Are you just pulling my leg now?
Because my definition of Phi is in the code, and when I comment out ALL of the
vnormalize() directives, I get ... an icosahedron.

And considering that the vertices are defined by ALL of the permutations of
+/-1, 0, and +/-Phi, I don't see how "swapping" those values in any given vertex
doesn't just give me ... another one of the points I already have.

When I added the y-rotated 90 and 180 instances, the lighting made it _look_
strange, like one triangle was rotated and skewed at a weird angle, but I added
a granite surface normal and moved the light source, and it's --- just an
icosahedron.   Were you seeing the same optical illusion I did?

> You also got the front top cap's ordering of points wrong. Fixing that
> will give you a nicely textured mesh.

Correct.   I've fixed that, and thank you.

I'm going to add a little bit to my code to visualize the vertex normals of the
smooth_triangles, because I'm having a devil of a time visualizing your
description of how that all works at the moment.  Your explanation of the
situation is perfectly clear - the 3D result of that is just [for me] less so.

Please also notice that there are a few green pixels in/on the lower left MESH
icosahdron - the rotate y*180 degree instance.  A small, but seemingly important
detail, if using mesh{} is supposed to eliminate that problem.
I haven't declared an inside_vector  -  could it be related in some way to that?

Also, if only _some_ of the vertices are normalized to the unit sphere radius,
some very nice stellated / fractal shapes are produced.

These would make a very nice basis for anyone who wanted crystals, 3D
snowflakes, etc.

Further deviations from the unit radius upon each facial subdivision would
likely produce some more interesting results.

All of these experiments - just give rise to more experiments  :)

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3518 days 5 hours and 37 minutes ago]

Fri, 19 Aug 2016 02:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> Hrrmpf... When it comes to error reports, I prefer precision. "not much"
> != "absolutely nothing".

Indeed.
I'm currently RE-taking inventory because the first time was inadequate and
questionable.  :|

From one to another - "precision" is the clustering of results, not necessarily
the intended goal.

"Accuracy" is hitting your mark.

One can be WAY off target and still be precise if they consistenly hit in the
same place.

One is "accurate" if the target is approached closely.

Just an observation from a rifle instructor, and a scientist schooled in
statistics by a statistician.  ;)

What hidden wonders POV-ray offers, eh?

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3518 days 8 hours and 37 minutes ago]

Thu, 18 Aug 2016 23:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.

From : https://en.wikipedia.org/wiki/Regular_icosahedron

The vertices of an icosahedron with edge-length 2, centered at the origin, are
described by all the cyclic permutations of: (0, ±1, ±ϕ)

where ϕ = (1 + √5) / 2  is the golden ratio (also written τ).

Note that these vertices form five sets of three concentric, mutually orthogonal
golden rectangles, whose edges form Borromean rings.

But I tend to be able to misread things rather well.   ;)

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 9 hours and 45 minutes ago]

Thu, 18 Aug 2016 22:31:29 GMT

Am 18.08.2016 um 22:30 schrieb Le_Forgeron:

> Nicely spotted, and it applies only to triangle outside a mesh.

Evidently, since meshes don't manipulate their data for transformations;
they just store a transformation matrix.

> Nevertheless, aside from passing the swapped status during computation of data, do
we really need to store that bit in each triangle ?
> (moreover, in something not "unsigned int :1", which might actually extend the size
of the Triangle structure)

I could have chosen from a host of approaches:

(A) Keep the original order of the points, and store the potentially
rearranged points as separate variables. This probably qualifies as the
most straightforward solution, and would be virtually(*) neutral to
rendering speed, but would require 24 extra bytes of data.

(*The only mechanism that could lead to a slight decrease in rendering
performance would be an increase in cache misses due to the larger
memory footprint.)

(B) Keep the original order of the points, and modify the intersection
test to cope with arbitrary ordering of the points. This undoubtedly
qualifies as one of the most memory-efficient solutions, but would also
undoubtedly be the heaviest on rendering performance. It would also
require some thought to be put into the intersection testing.

(C) Allow the order of points to be rearranged, but keep track of this
fact with a single flag, and fix the surface normal computation
accordingly. This is also a relatively straightforward to implement,
virtually neutral to rendering speed, and in theory costs only a single
bit of memory.

(D) Allow the order of points to be rearranged, identifying this fact
from /some/ properties of the underlying data wherever it is relevant.
This also undoubtedly qualifies as one of the most memory-efficient
solutions, and it can probably be implemented in a performance-neutral
manner (as far as rendering is concerned; parsing would be slowed down a
bit), but it would require some thought and care to be put into the
implementation, to make sure the properties we're basing the test on
actually hold true. It may also turn out to require either non-trivial
changes to the architecture of the Triangle's pre-computation mechanism,
hence resulting in a comparatively high implementation effort; or
changes spread across various methods, that would make the solution
non-trivial to understand, thereby degrading maintainability.

Weighing all the pros and cons, I decided that (C) was a reasonable
solution.


As for chosing a `bool:1`, I am a passionate advocate of storing data in
adequate data types, and booleans /are not integers/, period. I'm using
a `bool:1` as oppsoed to a regular `bool` in hopes that some modern
compilers make use of the freedom given by the C++ standard and cram it
into the same byte as the preceding `unsigned int:2` fields, but if they
don't -- well, too bad. I won't sacrifice clean programming for such a
tiny bit of memory.

As a matter of fact...

- On Linux systems, http://stackoverflow.com/a/308393 suggests that at
least GCC 4.2.4 will indeed pack `[unsigned] int` and `bool` bit fields
snugly together, so no memory lost there.

- On Windows systems, my own tests indicate that Visual Studio 2010 will
refuse to pack the two bit fields together. However, thanks to the
preceding `double` field the `unsigned int` bit field will be aligned to
an 8-byte boundary, and effectively occupy a multiple of 8 bytes in
memory; and since `int` is only 4 bytes on Windows machines, that still
leaves enough room afzer the `unsigned int` bit field to accomodate the
`bool:1` without any loss.

Also, if you were that worried about memory consumption, you should be
more bothered by the `unsigned int:2` where `unsigned char:2` would
suffice; while the difference is only 3 bytes on Windows or 32-bit Linux
machines, on 64-bit Linux machines it is a waste of 7 bytes. (BTW, it so
happens that Visual Studio 2010 apparently /will/ happily pack `unsigned
char` and `bool` bit fields together.)


> And did you check the SmoothTriangle::Compute_Triangle ?
> Similar code with extra swapping of normal at vertices, yet the Normal_Vector is the
same old way as Triangle::Compute_Triangle.

For `SmoothTriangle`, the direction of `Normal_Vector` is irrelevant,
since it is only used in the intersection computations, where a
distinction between front and back side is of no concern. The only
important thing is that the direction of `Normal_Vector` matches the
sign of `Distance`.

[Le Forgeron] Re: Wrong normal direction on triangle{ }s [3518 days 11 hours and 47 minutes ago]

Thu, 18 Aug 2016 20:30:02 GMT

Le 18/08/2016 Ã  18:49, clipka a Ã©crit :
> Am 18.08.2016 um 18:13 schrieb clipka:
>> As for the union of individual triangles, I'm still working on that one;
>> I must confess that so far I don't really have a clue where things go wrong.
> 
> Yikes!
> 
> I've found the culprit.
> 
> 
> You see, after parsing the triangle vertices, POV-Ray invokes a piece of
> code that precomputes certain values for the triangle that will be
> required in each and every intersection test.
> 
> That code first computes the surface normal from the vertices, as well
> as the distance between the coordinate origin and the plane in which the
> triangle lies.
> 
> The code then goes on to enforce a certain ordering of vertices that
> allows for certain shortcuts in intersection testing. You may note that
> this shouldn't be a problem for the interior/exterior texture test,
> since the surface normal has already been computed at this point.
> 
> 
> It /does/ become a problem, however, as soon as you invoke any
> transformation on the triangle -- because such an operation changes the
> position of the vertices, and therefore requires a re-computation of the
> precomputed stuff.
> 
> And this time the precomputation will operate on potentially rearranged
> vertices.
> 
> 
> As I said: Yikes!
> 

Nicely spotted, and it applies only to triangle outside a mesh.

Nevertheless, aside from passing the swapped status during computation of data, do we
really need to store that bit in each triangle ?
(moreover, in something not "unsigned int :1", which might actually extend the size of
the Triangle structure)

And did you check the SmoothTriangle::Compute_Triangle ?
Similar code with extra swapping of normal at vertices, yet the Normal_Vector is the
same old way as Triangle::Compute_Triangle.

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 15 hours and 25 minutes ago]

Thu, 18 Aug 2016 16:51:20 GMT

Am 18.08.2016 um 18:40 schrieb Bald Eagle:

> Thanks for looking that over and spotting the errors.
> "Do not correct a fool - or he will hate you; correct a wise man, and he will
> appreciate you."
> 
>> As for the union of individual triangles, I'm still working on that one;
>> I must confess that so far I don't really have a clue where things go wrong.
> 
> I'm actually surprised that such a thing hasn't come to anyone's attention until
> now.
> 
> While you work on that, I'll start working on breaking something else.   :D

Be my guest -- I'm in a wise mood :)

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 15 hours and 27 minutes ago]

Thu, 18 Aug 2016 16:49:31 GMT

Am 18.08.2016 um 18:13 schrieb clipka:
> As for the union of individual triangles, I'm still working on that one;
> I must confess that so far I don't really have a clue where things go wrong.

Yikes!

I've found the culprit.


You see, after parsing the triangle vertices, POV-Ray invokes a piece of
code that precomputes certain values for the triangle that will be
required in each and every intersection test.

That code first computes the surface normal from the vertices, as well
as the distance between the coordinate origin and the plane in which the
triangle lies.

The code then goes on to enforce a certain ordering of vertices that
allows for certain shortcuts in intersection testing. You may note that
this shouldn't be a problem for the interior/exterior texture test,
since the surface normal has already been computed at this point.


It /does/ become a problem, however, as soon as you invoke any
transformation on the triangle -- because such an operation changes the
position of the vertices, and therefore requires a re-computation of the
precomputed stuff.

And this time the precomputation will operate on potentially rearranged
vertices.


As I said: Yikes!

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3518 days 15 hours and 32 minutes ago]

Thu, 18 Aug 2016 16:45:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> One thing is for sure: You've seriously screwed up on the icosahedron.

It's indeed probable.
When I rendered it the first time around, it was a heinously grotesque form.
Then when I saw that Phi equals approx 1.618, I thought that maybe that was the
problem and vnormalize( )ed all the vertices and it just _looked_ like it was
ok.
Such are the dangers of "massaging the data".

The interesting thing is how well the macro outputs looked - it wasn't obvious
that the basis array of points was wrong.

> Apparently you misinterpreted the positions of the individual points,
> probably thinking that Phi<1, but in fact Phi>1.
>
> Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
> regular icosahedron.
>
> You also got the front top cap's ordering of points wrong. Fixing that
> will give you a nicely textured mesh.

Thanks for looking that over and spotting the errors.
"Do not correct a fool - or he will hate you; correct a wise man, and he will
appreciate you."

> As for the union of individual triangles, I'm still working on that one;
> I must confess that so far I don't really have a clue where things go wrong.

I'm actually surprised that such a thing hasn't come to anyone's attention until
now.

While you work on that, I'll start working on breaking something else.   :D

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 16 hours and 3 minutes ago]

Thu, 18 Aug 2016 16:13:28 GMT

One thing is for sure: You've seriously screwed up on the icosahedron.

Apparently you misinterpreted the positions of the individual points,
probably thinking that Phi<1, but in fact Phi>1.

Swapping the 1's and Phi's in the TwentyHedron definition gives a nice
regular icosahedron.

You also got the front top cap's ordering of points wrong. Fixing that
will give you a nicely textured mesh.


As for the union of individual triangles, I'm still working on that one;
I must confess that so far I don't really have a clue where things go wrong.

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 17 hours and 2 minutes ago]

Thu, 18 Aug 2016 15:14:39 GMT

Am 18.08.2016 um 16:11 schrieb Bald Eagle:
> I just flipped ALL the triangles in the scene.
> 
> Lines 248 & 249 determine the loop order of the triangle vertices.
> I switched from 0 to 2, to 2 to 0 step -1.
> The results are identical.
> 
> This troubles me.

Don't let it trouble you any longer; let it trouble me from now on.

In the meantime, you can work around it by using meshes instead of
unions of triangles.

[Bald Eagle] Re: Wrong normal direction on triangle{ }s [3518 days 18 hours and 2 minutes ago]

Thu, 18 Aug 2016 14:15:00 GMT

I just flipped ALL the triangles in the scene.

Lines 248 & 249 determine the loop order of the triangle vertices.
I switched from 0 to 2, to 2 to 0 step -1.
The results are identical.

This troubles me.

[clipka] Re: Wrong normal direction on triangle{ }s [3518 days 18 hours and 16 minutes ago]

Thu, 18 Aug 2016 14:01:00 GMT

Am 18.08.2016 um 13:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> - Can you be more specific what playing around with the order of the
>> vertices /did/ accomplish, and what it /didn't/?
> 
> I'll try again and see if I can get a more structured experiment and post
> results.
> I worked most of this out in 15 min bursts.
> I probably won't get to that until later, but it certainly appeared to me that
> changing the ordering of the vertices did - absolutely nothing.

Hrrmpf... When it comes to error reports, I prefer precision. "not much"
!= "absolutely nothing".

> (If I have a triangle, and swap 2 vertices, then that should flip the triangle.
>  I'm pretty sure I didn't just reorder them and accidentally maintain the
> original handedness)

I've just done a bit of toying around myself, and it seems that you may
be onto /something/. Here's the kicker: If you replace the "union"
around the flat triangles with "mesh", and leave everything else
uncganged, the octahedron version gives you a nice consistent texture
(though it's the inside texture, but that's easy to fix by flipping the
basic vertices at the z axis). That shouldn't happen -- the texturing of
triangles in a union should be the same as in a mesh.

(Even when using a mesh, the icosahedron is still textured
inconsistently, so my guess is that you have some individual basic
vertices wrong there.)

>> - With smooth triangles, the surface normal is instead interpolated from
>> the normal vectors given for the vertices. If we see the triangle almost
>> edge-on, it may happen that the normal vectors of one or more vertices
>> point away from us even though we see what would normally be considered
>> the front side of the triangle. In such a case, parts of the smooth
>> triangle will show the exterior texture while others will show the
>> interior texture, and unfortunately there is nothing you can do to fix this.
> 
> "it may happen that the normal vectors of one or more vertices 'point away from
> us'  "
> 
> I would have thought that since the sphere/polygon is convex on all faces, that
> everything would always be "out".
> All I did was use the [normalized] vertex coordinate as the normal, since
> Vertex-<0, 0, 0> = Vertex .

Of course everything is always "out" in a sphere or a convex polygon,
but how is POV-Ray supposed to know that you're trying to model such an
object?