povray.advanced-users message digest

[Bald Eagle] A specific layered texture [21 days 19 hours and 34 minutes ago]

Wed, 25 Mar 2026 18:40:00 GMT

Some background on the issue that I'm looking for a workaround to:

From: https://www.povray.org/documentation/view/3.60/356/
"A patterned texture cannot be used as a layer in a layered texture"

I'm wondering why.

So, what are "patterned textures?
https://www.povray.org/documentation/view/3.6.1/352/

"Patterned textures are complex textures made up of multiple textures. The
component textures may be plain textures or may be made up of patterned
textures. A plain texture has just one pigment, normal and finish statement.
Even a pigment with a pigment map is still one pigment and thus considered a
plain texture as are normals with normal map statements."

What I'm aiming to accomplish:
I have several uv_mapped bicubic_patch objects that obviously have their own
individual textures.
What I'm trying to do is apply a single normal to all the patches that is not
controlled by the patch <u, v> vectors, but the global <x, y, z> vectors of
POV-space.

So although the pigment/texture coloring may differ on each patch, the normal
needs to be continuous, rather than cycling over <0, 0> to <1, 1> at the edge of
every patch.

Any examples / ideas?

- BE

[Francois LE COAT] Re: Optical Inertia [91 days 23 hours and 59 minutes ago]

Wed, 14 Jan 2026 14:15:03 GMT

Hi,

Francois LE COAT writes:
> This is a sequence of images from a drone in the forest:
> 
> <https://www.youtube.com/watch?v=Kt0mkFYX45A> Drone
> 
> The drone flies very slowly compared to the acquisition rate of 30
> frames per second. This makes it much easier to observe the trajectory
> and visible depth. The successive images in the sequence are highly
> correlated. It is not necessary to frequently reset the reference image

> selection over time, as the correlation between this image and
> subsequent images remains well above the 60% threshold chosen for
> resetting.

Here's a sequence of images from a drone in the forest:

<https://www.youtube.com/watch?v=hFcDUU626po> Swedish woods

This image computing called 3D Optical Inertia looks like SLAM
(Simultaneous Localization and Mapping) method. We obtain both
the location (trajectory) and the visible relief (3D depth map).
However, we're dealing with a monocular (single camera) image
sequence, not a stereoscopic (human vision) one.

Here is the spline trajectory in space: <https://skfb.ly/pFx6u>

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [127 days 23 hours and 44 minutes ago]

Tue, 9 Dec 2025 14:30:01 GMT

Hi,

Francois LE COAT writes:
> This is a large sequence of images from a drone in the forest:
> 
> <https://www.youtube.com/watch?v=22QoxEwMBQA> The forest
> 
> This image computing looks like SLAM (Simultaneous Localization and
> Mapping) method. We obtain both the location (trajectory) and the
> visible relief (3D depth map). However, we're dealing with a monocular
> (single camera) image sequence, not a stereoscopic (human vision) one.
> 
> The sequence is constituted of 10 000 images at 60 frames per second.
> It is both large and high-resolution.
> 
> Here's the drone's trajectory in space: <https://skfb.ly/pDCwR>

This is a sequence of images from a drone in the forest:

<https://www.youtube.com/watch?v=Kt0mkFYX45A> Drone

The drone flies very slowly compared to the acquisition rate of 30
frames per second. This makes it much easier to observe the trajectory
and visible depth. The successive images in the sequence are highly
correlated. It is not necessary to frequently reset the reference image
selection over time, as the correlation between this image and
subsequent images remains well above the 60% threshold chosen for
resetting.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Using only POV-Ray keywords to make an equat... [128 days 12 hours and 44 minutes ago]

Tue, 9 Dec 2025 01:30:00 GMT

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

> I'll likely follow this up with some other examples and explanatory text,

Not there yet, but just going put a few links here before they get lost.

https://people.richland.edu/james/lecture/m116/matrices/applications.html

https://math.stackexchange.com/questions/3067779/geometric-proof-evidence-for-the-3x3-matrix-determinants-formula

https://www.themathdoctors.org/how-can-3x3-determinants-give-both-area-and-volume/

https://www.tandfonline.com/doi/full/10.1080/0020739X.2023.2233513#d1e117

https://math.stackexchange.com/questions/313526/intersection-between-two-lines

https://blogs.sas.com/content/iml/2018/07/09/intersection-line-segments.html


Also an interesting link:
https://shipbrook.net/jeff/raytrace/matrix.html

- BE

[Leroy] Re: Using only POV-Ray keywords to make an equat... [130 days 20 hours and 24 minutes ago]

Sat, 6 Dec 2025 17:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Round and round we go.
> IIRC, I wrote a solution for generating a parabola passing through 3 points for
> jr at one point.
> Recently I went through the solver code for the sor {} Catmull-Rom splines
> And again I touched on the parabola solution while discussing math with my son.
>
> I was looking a few things over to review the math and methods, and I said to
> myself, "Hey - this all looks awfully familiar."
>
> Why should I write code to solve a set of linear equations when the code already
> exists in source and is exposed to the user through matrix transforms?
>
> I'll likely follow this up with some other examples and explanatory text, but
> for right now behold:  Solving a system of linear equation with 3 unknowns using
> only keywords.  No "math" to speak of.
>
> POV-Ray black magic.   :)
>
> Go ahead: change P0, P1, or P2.
>
> Enjoy,
>
> - BE
>

 Cool! Works for me! Did a few little changes for 3.7.

Having Fun!

[Bald Eagle] Using only POV-Ray keywords to make an equation ... [131 days 11 hours and 9 minutes ago]

Sat, 6 Dec 2025 03:05:00 GMT

Round and round we go.
IIRC, I wrote a solution for generating a parabola passing through 3 points for
jr at one point.
Recently I went through the solver code for the sor {} Catmull-Rom splines
And again I touched on the parabola solution while discussing math with my son.

I was looking a few things over to review the math and methods, and I said to
myself, "Hey - this all looks awfully familiar."

Why should I write code to solve a set of linear equations when the code already
exists in source and is exposed to the user through matrix transforms?

I'll likely follow this up with some other examples and explanatory text, but
for right now behold:  Solving a system of linear equation with 3 unknowns using
only keywords.  No "math" to speak of.

POV-Ray black magic.   :)

Go ahead: change P0, P1, or P2.

Enjoy,

- BE


#version version;
global_settings {assumed_gamma 1.0}


camera {
 location  <0, 0, -40>
 right  x*image_width/image_height
 up   y
 look_at  <0, 0, 0>
}

light_source {<0, 0, -50> rgb 1}

sky_sphere {pigment {rgb 0.2}}

plane {z, 0 pigment {checker rgb 0.15 rgb 0.2}}


#declare E = 0.000001;
#declare Line = 0.05;

cylinder {-x*100, x*100 Line pigment {rgb x}}
cylinder {-y*100, y*100 Line pigment {rgb y}}



#declare P0 = <0, 6>;
#declare P1 = <3, 3>;
#declare P2 = <-2, -3>;

#declare PointArray = array {P0, P1, P2}

#macro SolveParabola (P)
 // Just some setup stuff to keep later notation short
 #local X02 = P[0].x*P[0].x;
 #local X0  = P[0].x;
 #local Y0  = P[0].y;

 #local X12 = P[1].x*P[1].x;
 #local X1  = P[1].x;
 #local Y1  = P[1].y;

 #local X22 = P[2].x*P[2].x;
 #local X2  = P[2].x;
 #local Y2  = P[2].y;

 // Here's where we do the equation solving

 #local EquationMatrix =
 transform {
  matrix <
   X02, X12, X22,
   X0 , X1 , X2 ,
   1  , 1  , 1  ,
   0  , 0  , 0
  >
 }

 #local Inv = function {transform {EquationMatrix inverse}}

 #local Coeff = Inv (Y0, Y1, Y2);

 #local (a, b, c) = (Coeff.x, Coeff.y, Coeff.z);

 // And we're done.

 //#debug concat ("a = ", str(a, 0, 3),  " b = ", str(b, 0, 3), " c = ", str(c,
0, 3), "\n")


 #local ParabolaMatrix =
 transform {
  matrix <
   0, a, 0,
   1, b, 0
   0, c, 0
   0, 0, 0
  >
 }

 ParabolaMatrix

#end

// Now we can use a matrix transform again to make the function
#declare Parabola = function {transform {SolveParabola (PointArray)}}

#for (i, 0, 2)
 sphere {PointArray[i], Line*5 pigment {rgb y}}
#end

union {
 #for (i, 0, 20, 0.1)
  #local X = i-10;
  #local Xterms = <X*X, X, 1>;
  #local P = Parabola (Xterms.x, Xterms.y, Xterms.z)-z; // -z compensates for
POV-Ray's auto-fix of <0, 0, 0> scaling
  //#debug concat ("P = ", vstr(3, P, ", ", 0, 3), " \n")
  sphere {P, Line}
  #if (i>0)
   cylinder {LastP, P, Line}
  #end
  #local LastP = P;
 #end
 pigment {rgb 1}
}

[Bald Eagle] Re: Calculating normals and perturbing them. [135 days 22 hours and 24 minutes ago]

Mon, 1 Dec 2025 15:50:00 GMT

Desmos 3d Calculator

https://www.desmos.com/3d/m5lelysfl1

Use lines 19 & 20 to change Theta and Phi

- BW

[Cousin Ricky] Re: Macro and parameters [136 days 19 hours and 19 minutes ago]

Sun, 30 Nov 2025 18:54:52 GMT

On 2025-11-29 05:05 (-4), kurtz le pirate wrote:
> 
> Effectively, it's not a bug, I agree, but it's confusing when you're
> switching between C and POV. My code wasn't working, and I had a lot of
> trouble figuring out why.

Kinda like switching from English to Spanish, and saying "vacunar la
carpeta" when you want to say "vacuum the carpet"; or saying "Estoy
embarazada" when you want to say "I'm embarrassed"; and then having a
lot of trouble figuring out why the locals are looking at you strange.

[Cousin Ricky] Re: Macro and parameters [137 days 22 hours and 16 minutes ago]

Sat, 29 Nov 2025 15:57:56 GMT

On 2025-11-29 11:09 (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> and the author of colors.inc::CH2RGB().
> 
> Story time!  :)

https://news.povray.org/povray.general/thread/%3Cweb.4fb9a70082db4bf885de7b680%40news.povray.org%3E/

[Bald Eagle] Re: Macro and parameters [137 days 23 hours and 4 minutes ago]

Sat, 29 Nov 2025 15:10:00 GMT

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

> Saw it coming!  This feature (not a bug!) has zapped some veterans,
> including BE, Ive,

It's an easy thing to forget about.
There has been some discussion about "wrapping" the feature, using a flag/switch
for enabling/protecting against the feature, or issuing a warning "argument
valued altered".

> and the author of colors.inc::CH2RGB().

Story time!  :)

> The particulars are explained here:
>
>
https://wiki.povray.org/content/Reference:User_Defined_Macros#Returning_Values_Via_Parameters

Yes, I had that tab open in my browser just in case.
You beat me to it.
I would like that whole section to moved the the top of the page,

"This mistake is more likely to be made with float identifiers versus float
expressions. Consider these examples.

#declare Value=5.0;
MyMacro(Value)     //MyMacro can change the value of Value but...
MyMacro(+Value)    //This version and the rest are not lone
MyMacro(Value+0.0) // identifiers. They are float expressions
MyMacro(Value*1.0) // which cannot be changed.
Although all four invocations of MyMacro are passed the value 5.0, only the
first may modify the value of the identifier."

and for the example preceding to be a little clearer.  The box {} example is a
bit too strange to lead in with.

The numerical examples are good, but a full-fledged .pov file with extended
commentary and output would be best - either as a downloadable file or just
cut-n-paste SDL right there on the wiki page.

- BE

[kurtz le pirate] Re: Macro and parameters [138 days 5 hours and 8 minutes ago]

Sat, 29 Nov 2025 09:05:40 GMT

On 29/11/2025 02:05, Cousin Ricky wrote:
> 
> Saw it coming!  This feature (not a bug!) has zapped some veterans,
> including BE, Ive, and the author of colors.inc::CH2RGB().
> 

Effectively, it's not a bug, I agree, but it's confusing when you're 
switching between C and POV. My code wasn't working, and I had a lot of 
trouble figuring out why.

Now I will pay much more attention to this situation.

-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Macro and parameters [138 days 13 hours and 8 minutes ago]

Sat, 29 Nov 2025 01:05:46 GMT

On 2025-11-28 12:07 (-4), kurtz le pirate wrote:
> 
> I just spent a long, long time debugging my code.
> 
> For example, this macro :
> 
> [snip]
> 
> At first glance, nothing special, but there is a problem, a big problem,
> that I hadn't noticed :(

I think I see where this is going.

> Can you see it too? Well done.
> 
> 
> I also program in C, so perhaps that's where the confusion comes from.

Now I'm sure of it!

> But I'll explain it anyway.
> 
> 
> The annoying part is this one :
> 
> Â Â Â  #if ( k > n-k )
> Â Â Â Â Â  #local k = n - k;
> Â Â Â  #end
> 
> ... and so, the "#local k =" led me to believe I was using a local
> variable. Well, not at all. "k" represents the variable passed as a
> parameter and its value is modified in the part that called this macro.

Saw it coming!  This feature (not a bug!) has zapped some veterans,
including BE, Ive, and the author of colors.inc::CH2RGB().

The particulars are explained here:

https://wiki.povray.org/content/Reference:User_Defined_Macros#Returning_Values_Via_Parameters

[Bald Eagle] Re: Macro and parameters [138 days 18 hours and 29 minutes ago]

Fri, 28 Nov 2025 19:45:00 GMT

You can pass by value or pass by reference.

https://news.povray.org/povray.advanced-users/thread/%3Cweb.63dd8ba6afaac3401f9dae3025979125%40news.povray.org%3E/

It's a recurring trap.

[Leroy] Re: Macro and parameters [138 days 20 hours and 29 minutes ago]

Fri, 28 Nov 2025 17:45:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
>
> I just spent a long, long time debugging my code.
>
> For example, this macro :
>
> #macro binomial_coefficient(n, k)
>
>    #local result = 0.0;
>
>    #if ( k<0 | k>n)
>      #local result = 0.0;
>
>    #elseif (k=0 | k=n)
>      #local result = 1.0;
>
>    #else
>      #local result = 1.0;
>      #if ( k > n-k )
>        #local k = n - k;
>      #end
>      #local i = 0;
>      #while ( i < k )
>        #local result = result*(n-i);
>        #local result = result/(i+1);
>        #local i = i + 1;
>      #end
>    #end
>
>    // return scalar value
>    result
> #end
>
>
>
> At first glance, nothing special, but there is a problem, a big problem,
> that I hadn't noticed :(
>
>
> Can you see it too? Well done.
>
>
> I also program in C, so perhaps that's where the confusion comes from.
> But I'll explain it anyway.
>
>
> The annoying part is this one :
>
>      #if ( k > n-k )
>        #local k = n - k;
>      #end
>
> ... and so, the "#local k =" led me to believe I was using a local
> variable. Well, not at all. "k" represents the variable passed as a
> parameter and its value is modified in the part that called this macro.
>
> By simplifying :
>
> #declare n = 5;
> #declare k = 3;
> #declare r = binomial_coefficient(n,k);
> ...and here k = 2, not 3 !
>
>
> Therefore, be careful not to use a macro parameter in an assignment.
>
> Do you agree with me, or have I misunderstood something again?
> --
> kurtz le pirate
> compagnie de la banquise


I agree! I program in C++ and POV macros and variables are very different!

Try this macro.

#macro ts(R)
 #local R=sphere{0,1 pigment{Gold}}
#end
#declare P=5; ts(P)
object{P}

Have Fun!

[kurtz le pirate] Macro and parameters [138 days 22 hours and 6 minutes ago]

Fri, 28 Nov 2025 16:07:13 GMT

Hello,


I just spent a long, long time debugging my code.

For example, this macro :

#macro binomial_coefficient(n, k)

   #local result = 0.0;

   #if ( k<0 | k>n)
     #local result = 0.0;

   #elseif (k=0 | k=n)
     #local result = 1.0;

   #else
     #local result = 1.0;
     #if ( k > n-k )
       #local k = n - k;
     #end
     #local i = 0;
     #while ( i < k )
       #local result = result*(n-i);
       #local result = result/(i+1);
       #local i = i + 1;
     #end
   #end

   // return scalar value
   result
#end



At first glance, nothing special, but there is a problem, a big problem, 
that I hadn't noticed :(


Can you see it too? Well done.


I also program in C, so perhaps that's where the confusion comes from.
But I'll explain it anyway.


The annoying part is this one :

     #if ( k > n-k )
       #local k = n - k;
     #end

... and so, the "#local k =" led me to believe I was using a local 
variable. Well, not at all. "k" represents the variable passed as a 
parameter and its value is modified in the part that called this macro.

By simplifying :

#declare n = 5;
#declare k = 3;
#declare r = binomial_coefficient(n,k);
...and here k = 2, not 3 !


Therefore, be careful not to use a macro parameter in an assignment.

Do you agree with me, or have I misunderstood something again?



-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Calculating normals and perturbing them. [140 days 13 hours and 29 minutes ago]

Thu, 27 Nov 2025 00:45:00 GMT

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

> I may or may not get the opportunity to try this, but it would be useful to plot
> expected normal scalar values as an overlay, and also render the potential
> vector-promoted scalar values to see if they give the same results.

Well I did.  And it was as (unnecessarily) annoying, confusing, frustrating, and
difficult as these things always are.

I'm very interested in what the/your expected result is.

(very cool version statement - you have a lot of clever little things in your
scenes)


#version max (3.5, min (3.8, version));

global_settings { assumed_gamma 1 }

light_source { <(frame_number = 2? 1: -1), 1, -1.4> * 1000, rgb 1 }

camera
{ location -6 * z
   right x
   angle 30
}

#declare OriginalFunction =
function
{ max
 ( select (x - 1, 1, select (x - 2, 0, 1)),
   select (y - 1, 1, select (y - 2, 0, 1))
 )
}

#declare Pattern = function {
 spline {
  0, <0, 0, 0>,
  1, <1, 1 ,1>
 }
}

#declare VectorValues =
normal {
 average
 normal_map {
  [function { Pattern (OriginalFunction(x, y, z)).red}]
  [function { Pattern (OriginalFunction(x, y, z)).green}]
  [function { Pattern (OriginalFunction(x, y, z)).blue}]
 }
}


#declare Function = 1;

#switch (Function)

 #case (0)
  box
  { 0, 3
     pigment { rgb <1, 0.5, 0.5> }
     normal
     {
      function {OriginalFunction (x, y, z)}
       accuracy 0.1
     }
     translate <-1.5, -1.5, 0>
  }
 #break

 #case (1)
  box
  { 0, 3
     pigment { rgb <1, 0.5, 0.5> }
     normal
     {
      VectorValues
       accuracy 0.1
     }
     translate <-1.5, -1.5, 0>
  }
 #break

#end

#declare Ext = 5;
#for (Y, -Ext, Ext)
 #for (X, -Ext, Ext)
  text { ttf "arial.ttf", str (OriginalFunction (X, Y, 0), 0, 0), 0.02, 0.0
translate <-0.25, -0.25, 0> scale 0.5 translate <X, Y, -0.01> pigment {rgb
z*0.5} no_shadow}
 #end
#end

[Bald Eagle] Re: Calculating normals and perturbing them. [140 days 14 hours and 59 minutes ago]

Wed, 26 Nov 2025 23:15:00 GMT

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

> So far as I understand, the scalar is an offset from the surface, and as
> such, a vector perpendicular to the unperturbed surface is implied.

I mean, that sounds great.
But as far as I am presently aware, POV-Ray enters the Perturb_Normal() function
in normal.cpp with no geometric information other than the "EPoint".
So in what direction do we offset from that point?  The normal?
I believe that the whole reason for using the pyramid vectors is to compute the
normal in the first place so that it can then be perturbed by a vector-valued
function of amplitude bump_size or scale <x, y, z>.

I could very well be missing some key point, which is why I've been digging into
this when I have the time / remember to.

> POV-Ray then computes a normal vector by comparing adjacent
> perturbations, "adjacent" being defined by the 'accuracy' attribute.

It uses the pyramid vectors to define the sampling points offset from the EPoint
by a value "Delta" which Nathan Kopp hard-codes to 0.02.

> I haven't examined the source code, so I could be wrong, but I would
> expect "adjacent" samples to be free from bias, at least from opposite
> directions.

Yes, it's taken me some time, but I believe that the tetrahedral arrangement of
the sample points ensures exactly that, no matter the orientation.

> > I believe one would need to use a spline function, a pigment function, or some
> > other vector-valued function to properly use a function {} in a normal statement
> > to get meaningful if not proper results.
>
> This actually sounds like an excellent way to *introduce* directional
> bias if you're not careful with the function.  ISTR some of POV-Ray's
> built-in normals already have that problem.

But directional bias is exactly how we are creating the normal pattern to begin
with.  If we just multiplied all of the pyramid vectors by a scalar, they would
all cancel out.  Because there's no inherent directional bias.   In order to
"apply a normal" to a surface, we have to introduce some sort of _directional
bias_ in the form of a vector.

That vector comes from the normal pattern functions, and so I think that in
order to create a real and meaningful normal pattern like we think of them, it
needs to be a 3-dimensional vector.  Otherwise, I think that "1" gets
transformed to <1, 1, 1>, "-1" gets transformed to <-1, -1, -1>, etc.

I may or may not get the opportunity to try this, but it would be useful to plot
expected normal scalar values as an overlay, and also render the potential
vector-promoted scalar values to see if they give the same results.

Definitely a lot to be learned here, on several fronts.

- BW

[Cousin Ricky] Re: Calculating normals and perturbing them. [140 days 17 hours and 23 minutes ago]

Wed, 26 Nov 2025 20:50:54 GMT

On 2025-11-26 10:53 (-4), Bald Eagle wrote:
> 
> I was also trying to re-code an old scene where I was initially trying to
> replicate source-code methods in SDL, and I believe I was trying to do what
> Cousin Ricky was doing - which is trying to use a scalar value to create a
> "normal".
> 
> A surface normal is, by definition, a vector perpendicular to the surface at
> that point.   It's a vector, not a scalar, so using the scalar result from an
> SDL function as a normal really doesn't make any sense.

So far as I understand, the scalar is an offset from the surface, and as
such, a vector perpendicular to the unperturbed surface is implied.
POV-Ray then computes a normal vector by comparing adjacent
perturbations, "adjacent" being defined by the 'accuracy' attribute.

I haven't examined the source code, so I could be wrong, but I would
expect "adjacent" samples to be free from bias, at least from opposite
directions.

> I believe one would need to use a spline function, a pigment function, or some
> other vector-valued function to properly use a function {} in a normal statement
> to get meaningful if not proper results.

This actually sounds like an excellent way to *introduce* directional
bias if you're not careful with the function.  ISTR some of POV-Ray's
built-in normals already have that problem.

[Bald Eagle] Calculating normals and perturbing them. [140 days 23 hours and 19 minutes ago]

Wed, 26 Nov 2025 14:55:00 GMT

I've been digging down to the foundations of computing normals, and I was
re-reading the following threads with fresh eyes.

https://news.povray.org/povray.binaries.images/thread/%3C609265e2%40news.povray.org%3E/?mtop=434022

http://news.povray.org/povray.binaries.images/thread/%3C5ff4b8da%241%40news.povray.org%3E/

https://iquilezles.org/articles/normalsSDF/
(Original pouet.net link: https://www.pouet.net/topic.php?which=5604 )

This thread recently got updated due to my inquiries, with no explanations, thus
the pyramid vectors straight from POV-Ray's normals.cpp

https://rodolphe-vaillant.fr/entry/87/normal-to-an-implicit-surface

I was also trying to re-code an old scene where I was initially trying to
replicate source-code methods in SDL, and I believe I was trying to do what
Cousin Ricky was doing - which is trying to use a scalar value to create a
"normal".

A surface normal is, by definition, a vector perpendicular to the surface at
that point.   It's a vector, not a scalar, so using the scalar result from an
SDL function as a normal really doesn't make any sense.

I believe one would need to use a spline function, a pigment function, or some
other vector-valued function to properly use a function {} in a normal statement
to get meaningful if not proper results.

Perhaps what Richard is seeing is the result of vector promotion or some other
under-the-hood modification of the scalar function, and that' why the raytraced
result is wrong.

I myself am currently trying to unravel the requirements and limitations of
trying to create normals in sdf using the pyramid vector method.

All I can say is that there is no inherent bias introduced by the pyramid vector
method, since everything cancels out to give straightforward central differences
in any orientation.

- BE

[Francois LE COAT] Re: Optical Inertia [149 days and 3 minutes ago]

Tue, 18 Nov 2025 14:10:15 GMT

Hi,

This is a large sequence of images from a drone in the forest:

<https://www.youtube.com/watch?v=22QoxEwMBQA> The forest

This image computing looks like SLAM (Simultaneous Localization and
Mapping) method. We obtain both the location (trajectory) and the
visible relief (3D depth map). However, we're dealing with a monocular
(single camera) image sequence, not a stereoscopic (human vision) one.

The sequence is constituted of 10 000 images at 60 frames per second.
It is both large and high-resolution.

Here's the drone's trajectory in space: <https://skfb.ly/pDCwR>

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[yesbird] Re: 3.8.0-beta.2 - illegal instruction [152 days 9 hours and 48 minutes ago]

Sat, 15 Nov 2025 04:25:56 GMT

On 14/11/2025 20:32, William F Pokorny wrote:

> (*) - Eventually, I plan to move 'yuqk' to github as I am already using 
> git for it locally. At that change I'll be coming up to speed with 
> github for yuqk - and sorting base POV-Ray github issues then, should be 
> easier.

Good luck with it - Github is a _very_ useful and now "must have"
service. I can suggest desktop version with excellent GUI:
https://desktop.github.com/download/

There is also a Linux fork, which I am using too, but you will need some
googling to find it.
--
YB

[William F Pokorny] Re: 3.8.0-beta.2 - illegal instruction [152 days 20 hours and 41 minutes ago]

Fri, 14 Nov 2025 17:32:24 GMT

On 11/10/25 06:44, William F Pokorny wrote:
> It's true I did some github things a year or so ago to get bumped to a 
> developer with the idea I might do a few quick commits like this, but my 
> github upgrade from contributor to developer didn't go well. Best I 
> could tell, I ended up with developer permission to one hidden / 
> developer only fork / branch about which I know nothing.

I recently got an email from a friend on this subject. I want to make 
clear I am the one who has not pursued fixing the situation above.

It might be something I could fix myself with some time and focus. If 
not, others - like Chris - would certainly try and help me, but I don't 
want others burning time for something I'm currently unlikely to much 
use(*).

Aside:

Thinking about the patch, it's safer to remove the -ffast-math flag, I 
think. I'm unsure how pervasive the -fno-finite-math-only flag is... 
(clang ?)

Bill P.

(*) - Eventually, I plan to move 'yuqk' to github as I am already using 
git for it locally. At that change I'll be coming up to speed with 
github for yuqk - and sorting base POV-Ray github issues then, should be 
easier.

[William F Pokorny] Re: 3.8.0-beta.2 - illegal instruction [157 days 2 hours and 29 minutes ago]

Mon, 10 Nov 2025 11:44:30 GMT

On 11/10/25 04:52, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> 2) Both the default unix build and the build script jr provided use
>> -ffast-math. There are a number of flaky fails due recent compiler
>> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
>> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.
> 
> in light of yesbird asking whether optimisation should be turned off perhaps, I
> think it would be beneficial if (at least) the build flags for default *NIX were
> appended / updated to include the '-fno-finite-math-only'.  can do ?
> 

No(*), not easily.

---

It's true I did some github things a year or so ago to get bumped to a 
developer with the idea I might do a few quick commits like this, but my 
github upgrade from contributor to developer didn't go well. Best I 
could tell, I ended up with developer permission to one hidden / 
developer only fork / branch about which I know nothing.

None of the automated, github, build, check and release stuff is 
currently working. I never understood that set up beyond checking 
results of the auto-build-check fails. I have now not used github 
itself, except for occasionally commenting on issues posted there, for 
more than 5 years.

I cannot help with or support any windows specific development.

The suggested change should be made in at least 3 github branches. The 
github support infrastructure is really nice when it's all working - but 
even then, the simplest change takes non-trivial 'git / github' time.

---

My Unix/Linux only yuqk fork is different. The Unix build system itself 
is substantially different. I don't even have the --disable-optimiz 
configure option YB used(**) to build on his machine, for example.

---

Lastly, of late, real life is leaving me with much less time for my 
POV-Ray hobby :-(.

Bill P.

(*) - You're likely guessing correctly that YB's core issue comes down 
to the -ffast-math changes. The --disable-optimize option almost 
certainly turns off fast math.

(**) - Completely non-optimized POV-Ray builds are slow. (Though, it is 
a workaround for the gnu compiler optimizations breaking the dynamic cpu 
detection code issue (fixed in yuqk no matter the compiler optimization 
level))

[jr] Re: 3.8.0-beta.2 - illegal instruction [157 days 4 hours and 19 minutes ago]

Mon, 10 Nov 2025 09:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> 2) Both the default unix build and the build script jr provided use
> -ffast-math. There are a number of flaky fails due recent compiler
> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

in light of yesbird asking whether optimisation should be turned off perhaps, I
think it would be beneficial if (at least) the build flags for default *NIX were
appended / updated to include the '-fno-finite-math-only'.  can do ?

regards, jr.

[yesbird] Re: 3.8.0-beta.2 - illegal instruction [157 days 13 hours ago]

Mon, 10 Nov 2025 01:13:51 GMT

On 08/11/2025 16:58, jr wrote:
> good that you found a work-around.

Yes, I did with the help of the community, but don't you think that
it would be better to turn off this optimization by default to
preserve other users from similar issues in future ?
--
YB

[yesbird] Re: Getting the most from CPU [157 days 23 hours and 29 minutes ago]

Sun, 9 Nov 2025 14:44:39 GMT

On 09/11/2025 15:47, jr wrote:
> strange.  on my "elderly" i5, the help option reports CPU Intel (with
> SSE2,AVX,AVX2,FMA3) and noise generator 'avx2fma3-intel'.
> 
> fwiw, when the correct CPU is detected, find out which "chipset" ('Haswell' for
> this machine), and check if the compiler "knows" that, ie I can use the
> '-march=haswell -mtune=haswell' GCC options.  unsure about "performance boost"
> :-).

Nothing strange - at home I have Intel, but now building version for
hosting provider's server that works under "AMD EPYC 7763 64-Core" and
want to make optimal configuration.

I will be happy if you suggest me the best options for this
hardware.
-- 
YB

[jr] Re: Getting the most from CPU [158 days 1 hour and 24 minutes ago]

Sun, 9 Nov 2025 12:50:00 GMT

hi,

yesbird wrote:
> Now, after successfully build of 3.8.0-beta2 for my home dated
> Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, ...
> Now I see in the following, when asking 'povray --help':
> Dynamic optimizations:
> CPU detected: AMD,FMA4
> Noise generator: generic (portable)

strange.  on my "elderly" i5, the help option reports CPU Intel (with
SSE2,AVX,AVX2,FMA3) and noise generator 'avx2fma3-intel'.

fwiw, when the correct CPU is detected, find out which "chipset" ('Haswell' for
this machine), and check if the compiler "knows" that, ie I can use the
'-march=haswell -mtune=haswell' GCC options.  unsure about "performance boost"
:-).

regards, jr.

[yesbird] Getting the most from CPU [158 days 2 hours and 30 minutes ago]

Sun, 9 Nov 2025 11:43:18 GMT

Now, after successfully build of 3.8.0-beta2 for my home dated
Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz, I would like to ask you how to
make a build for powerful architecture which supports more advanced
instructions set.

If I understand well, CPU optimization is switched on by default. The
question is: how to get the most from a particular CPU - are there any
options or defines to turn on support of particular architecture
features ?

Now I see in the following, when asking 'povray --help':
Dynamic optimizations:
CPU detected: AMD,FMA4
Noise generator: generic (portable)
--
YB

[jr] Re: 3.8.0-beta.2 - illegal instruction [159 days and 14 minutes ago]

Sat, 8 Nov 2025 14:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> 2) Both the default unix build and the build script jr provided use
> -ffast-math. There are a number of flaky fails due recent compiler
> changes to what -ffast-math does. Change that flag to: -fno-fast-math or
> add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

thanks !


@yesbird
> The .configure option that helps was '-disable-optimiz'.

good that you found a work-around.


regards, jr.

[yesbird] Re: 3.8.0-beta.2 - illegal instruction [159 days 1 hour and 8 minutes ago]

Sat, 8 Nov 2025 13:05:26 GMT

On 08/11/2025 14:59, William F Pokorny wrote:
> There can be many causes for what you are seeing. Things you might try:
> ... 

Many thanks for such a detailed response, I will put these tips to my
'internal storage' ).

The .configure option that helps was '-disable-optimiz'.
Probably I was too lazy to run:
./configure --help

and examine output, instead of disturbing the community, sorry for
inconvenience.
-- 
YB

[William F Pokorny] Re: 3.8.0-beta.2 - illegal instruction [159 days 2 hours and 14 minutes ago]

Sat, 8 Nov 2025 11:59:11 GMT

On 11/8/25 02:55, yesbird wrote:
> On 08/11/2025 12:32, jr wrote:
>> unsure even what you mean.Â  there are some bits of the source which are
>> "hand-optimised" for specific CPU types, but the detection & inclusion is
>> automatic.
>>
>> either way, I've attached another "hack"[*] </grin>, a beta.2 build 
>> script.
>>
>> [*] anyway, works.Â  </shrug>
> 
> 
> Unfortunately results is the same: "no result".
> ---------------------------------------------------------------------
> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
> +a0.3 +L./include
> make: *** [Makefile:1089: check] Illegal instruction (core dumped)
> ---------------------------------------------------------------------
> YB
> 

There can be many causes for what you are seeing. Things you might try:

1) Download the latest yuqk tarball at:

https://news.povray.org/povray.binaries.programming/thread/%3C67eba626%40news.povray.org%3E/

Unpack it and run:

./configure -q COMPILED_BY="YB_yuqk" CXXFLAGS="-std=c++17"
make -j4
make check

The yuqk fork ships without any compiler optimizations during 
./configure - aside from the cpu specific noise code where it has fixed 
some 'gnu compiler broken' cpu detection code.

2) Both the default unix build and the build script jr provided use 
-ffast-math. There are a number of flaky fails due recent compiler 
changes to what -ffast-math does. Change that flag to: -fno-fast-math or 
add the flag -fno-finite-math-only to your CXXFLAGS and try another build.

3) You can try a configure with the defines:

-DDISABLE_OPTIMIZED_NOISE_AVXFMA4 -DDISABLE_OPTIMIZED_NOISE_AVX2FMA3 
-DISABLE_OPTIMIZED_NOISE_AVX

Which 'should' turn off any use of the cpu target specific hand 
optimized code - but they might not turn off the dynamic cpu detection 
code which runs ahead of the hand optimized code (I don't remember).

There is too a -DDISABLE_OPTIMIZED_NOISE_AVX_PORTABLE, but my memory is 
fuzzy as to what that means - probably harmless to add it to those above.

4) At a terminal after a illegal instruction problem build, are you able 
to run:

./unix/povray --help

If so, try each of:

touch bogus.pov; ./unix/povray bogus.pov -d +p

touch bogus.pov; ./unix/povray bogus.pov -d -p

touch bogus.pov; ./unix/povray bogus.pov -d +p -fn

Bill P.

[yesbird] Re: 3.8.0-beta.2 - illegal instruction [159 days 3 hours and 18 minutes ago]

Sat, 8 Nov 2025 10:55:34 GMT

On 08/11/2025 12:32, jr wrote:
> unsure even what you mean.  there are some bits of the source which are
> "hand-optimised" for specific CPU types, but the detection & inclusion is
> automatic.
> 
> either way, I've attached another "hack"[*] </grin>, a beta.2 build script.
> 
> [*] anyway, works.  </shrug>


Unfortunately results is the same: "no result".
---------------------------------------------------------------------
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
+a0.3 +L./include
make: *** [Makefile:1089: check] Illegal instruction (core dumped)
---------------------------------------------------------------------
YB

[jr] Re: 3.8.0-beta.2 - illegal instruction [159 days 4 hours and 39 minutes ago]

Sat, 8 Nov 2025 09:35:00 GMT

yesbird wrote:
> ...
> Thanks, jr, for the fast reply, I will try it, but this solution looks
> like, a hack.

well, it is for WFP's "yuqk" fork :-).

> I'd prefer 'official' method to control usage of advanced
> CPU instructions, via config parameters.
> Don't you know, if it's possible ?

unsure even what you mean.  there are some bits of the source which are
"hand-optimised" for specific CPU types, but the detection & inclusion is
automatic.

either way, I've attached another "hack"[*] </grin>, a beta.2 build script.

[*] anyway, works.  </shrug>

regards, jr.

[yesbird] Re: 3.8.0-beta.2 - illegal instruction [159 days 5 hours and 3 minutes ago]

Sat, 8 Nov 2025 09:10:57 GMT

On 08/11/2025 10:11, jr wrote:
> I published build scripts once or twice, see link.  write if further problems.
> <news.povray.org/web.660c3b34a01057ea1686e436cde94f1%40news.povray.org>

Thanks, jr, for the fast reply, I will try it, but this solution looks
like, a hack. I'd prefer 'official' method to control usage of advanced
CPU instructions, via config parameters.

Don't you know, if it's possible ?
-- 
YB

[jr] Re: 3.8.0-beta.2 - illegal instruction [159 days 6 hours and 59 minutes ago]

Sat, 8 Nov 2025 07:15:00 GMT

hi,

yesbird wrote:
> Greetings !
>
> I am trying to build official beta from this tarball:
> povunix-v3.8.0-beta.2-src.tar.gz.
>
> Build is successful, but on runtime I am getting following error:
> Illegal instruction (core dumped).
>
> I guess that by default 'configure' turns on support for modern
> instructions, that my CPU is not supported, so what is the best way
> to control them and avoid this error ?
>
> My present environment is following:
> Intel(R) Core(TM) i5 CPU  750  @ 2.67GHz
> Ubuntu 24.04.3 LTS
> --
> YB

I published build scripts once or twice, see link.  write if further problems.
<news.povray.org/web.660c3b34a01057ea1686e436cde94f1%40news.povray.org>


regards, jr.

[yesbird] 3.8.0-beta.2 - illegal instruction [159 days 13 hours and 36 minutes ago]

Sat, 8 Nov 2025 00:37:17 GMT

Greetings !

I am trying to build official beta from this tarball:
povunix-v3.8.0-beta.2-src.tar.gz.

Build is successful, but on runtime I am getting following error:
Illegal instruction (core dumped).

I guess that by default 'configure' turns on support for modern
instructions, that my CPU is not supported, so what is the best way
to control them and avoid this error ?

My present environment is following:
Intel(R) Core(TM) i5 CPU  750  @ 2.67GHz
Ubuntu 24.04.3 LTS
-- 
YB

[Francois LE COAT] Re: Optical Inertia [162 days 22 hours and 59 minutes ago]

Tue, 4 Nov 2025 15:15:04 GMT

Hi,

Francois LE COAT writes:
>> Here's a drone's long flight through the forest in France...
>>
>>      <https://www.youtube.com/watch?v=f_Zi811qWFI>
>>
>> We're in rather complicated lighting conditions, with shadows and
>> clouds. Hence the significant noise in the video. The optical-flow
>> (DIS - OpenCV) that allows the determination of monocular depth
>> performs rather well. Mathematicians refer to this determination
>> as an "ill-posed problem". But statistically, for the large images
>> we're dealing with, it works well :-)
> 
> Here's a sequence of images from a drone in the forest.
> 
>      <https://www.youtube.com/watch?v=gOAwt0I7GNE>
> 
> These image computing looks like SLAM (Simultaneous Localization and
> Mapping) method. We obtain both the location (trajectory) and the
> visible relief (3D depth map). However, we're dealing with a monocular
> (single camera) image sequence, not a stereoscopic (human vision) one.
> 
> Here's the drone's trajectory in space: <https://skfb.ly/pCyBy>

Here's a sequence of images from a drone in the forest:

	<https://www.youtube.com/watch?v=ToRk-o1cD_4>

This image computing looks like SLAM (Simultaneous Localization and
Mapping) method. We obtain both the location (trajectory) and the
visible relief (3D depth map). However, we're dealing with a monocular
(single camera) image sequence, not a stereoscopic (human vision) one.

The question that arises, then, is why do highly accurate inertial
navigation systems drift? Why are loop-closing methods, used with the
SLAM algorithm? Would an optical inertial navigation system be subject
to drift in the trajectory it estimates? That's debatable, isn't it?

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [176 days 23 hours and 39 minutes ago]

Tue, 21 Oct 2025 14:35:05 GMT

Hi,

Francois LE COAT wrote:
> Here's a drone's long flight through the forest in France...
> 
>      <https://www.youtube.com/watch?v=f_Zi811qWFI>
> 
> We're in rather complicated lighting conditions, with shadows and
> clouds. Hence the significant noise in the video. The optical-flow
> (DIS - OpenCV) that allows the determination of monocular depth
> performs rather well. Mathematicians refer to this determination
> as an "ill-posed problem". But statistically, for the large images
> we're dealing with, it works well :-)

Here's a sequence of images from a drone in the forest.

	<https://www.youtube.com/watch?v=gOAwt0I7GNE>

These image computing looks like SLAM (Simultaneous Localization and
Mapping) method. We obtain both the location (trajectory) and the
visible relief (3D depth map). However, we're dealing with a monocular
(single camera) image sequence, not a stereoscopic (human vision) one.

Here's the drone's trajectory in space: <https://skfb.ly/pCyBy>

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Cross products in different coordinate syste... [177 days 18 hours and 14 minutes ago]

Mon, 20 Oct 2025 20:00:00 GMT

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

> the latter (imo), re-order the components.


Actually, the answer is:  do nothing.

If we were importing/converting the DATA from one system to the other, then we
would need to change the vector components to reflect this and make everything
work properly.

When we're using the RH data in the RH coordinate space, or using the LH data in
the LH coordinate space, the code and vector functions remain unchanged.

(As mentioned in another thread, things got derailed when I had R instead of r,
so the normals were pointing every which way, and my isosurface wasn't behaving
properly either, so that just added to the confusion.)

- BW

[jr] Re: Cross products in different coordinate syste... [178 days 20 hours and 59 minutes ago]

Sun, 19 Oct 2025 17:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Let's suppose that I have code that uses vector cross products in a z-up
> y-forward system.
>
> Now I want replicate the code in our y-up, z-forward system to accomplish the
> same task.
>
>             What is the best / most efficient way to do this?
>
> Do I need to re-order the vectors in the vcross (A, B) function?
>
> or
>
> do I actually need to change the vector coordinates that I'm using
> so that z-up <X, Y, Z> = y-up <X, Z, -Y>
>
> I want something sane, ...

the latter (imo), re-order the components.


regards, jr.

[Bald Eagle] Cross products in different coordinate systems. [179 days 14 hours and 39 minutes ago]

Sat, 18 Oct 2025 23:35:00 GMT

Let's suppose that I have code that uses vector cross products in a z-up
y-forward system.

Now I want replicate the code in our y-up, z-forward system to accomplish the
same task.

            What is the best / most efficient way to do this?

Do I need to re-order the vectors in the vcross (A, B) function?

or

do I actually need to change the vector coordinates that I'm using
so that z-up <X, Y, Z> = y-up <X, Z, -Y>

I want something sane, for production code.  Not something hacktastic.

- BE

[yesbird] Re: mesh_camera [186 days 23 hours and 12 minutes ago]

Sat, 11 Oct 2025 15:01:08 GMT

On 11/10/2025 14:18, yesbird wrote:
> If you want to finish it finally, try Three.js and I will share my
> project as template :).

Or just use this viewer, as PB do:
https://krpano.com/download/
-- 
YB

[yesbird] Re: mesh_camera [186 days 23 hours and 55 minutes ago]

Sat, 11 Oct 2025 14:18:18 GMT

On 11/10/2025 16:54, ingo wrote:
> yesbird wrote:
>> On 11/10/2025 07:02, Paul Bourke wrote:
>>> A closing remark ... all working. user_defined camera is BRILLIANT!
>>> More details here
>>>      https://paulbourke.net/stereoscopy/pov_odsp/
>>>
>>>
>>
>> Many thanks for sharing results of your investigation,
>> here is a live illustration to your paper:
>> https://povlab.yesbird.online/pb/odsp/
>> --
>> YB
> 
> Nice. Next, render it as tiles and use a tile server to zoom in
> https://leafletjs.com/index.html

Thanks, I was working with 'leafletjs', but it designed for flat maps,
while Three.js, which I am using now, for 3D and XR. The more zooming
can be achieved by scaling texture, if necessary.

> 
> I tried that with an udcBox camera that shows the six sides of a box from
> within. It failed, running a simple animation for all the frames was easier. The
> project never finished ...

If you want to finish it finally, try Three.js and I will share my
project as template :).
-- 
YB

[ingo] Re: mesh_camera [187 days and 19 minutes ago]

Sat, 11 Oct 2025 13:55:00 GMT

yesbird wrote:
> On 11/10/2025 07:02, Paul Bourke wrote:
> > A closing remark ... all working. user_defined camera is BRILLIANT!
> > More details here
> >     https://paulbourke.net/stereoscopy/pov_odsp/
> >
> >
>
> Many thanks for sharing results of your investigation,
> here is a live illustration to your paper:
> https://povlab.yesbird.online/pb/odsp/
> --
> YB

Nice. Next, render it as tiles and use a tile server to zoom in
https://leafletjs.com/index.html

I tried that with an udcBox camera that shows the six sides of a box from
within. It failed, running a simple animation for all the frames was easier. The
project never finished ...

ingo

[yesbird] Re: mesh_camera [187 days and 48 minutes ago]

Sat, 11 Oct 2025 13:25:44 GMT

On 11/10/2025 07:02, Paul Bourke wrote:
> A closing remark ... all working. user_defined camera is BRILLIANT!
> More details here
>     https://paulbourke.net/stereoscopy/pov_odsp/
> 
> 

Many thanks for sharing results of your investigation,
here is a live illustration to your paper:
https://povlab.yesbird.online/pb/odsp/
--
YB

[ingo] Re: mesh_camera [187 days 9 hours and 9 minutes ago]

Sat, 11 Oct 2025 05:05:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:

>    https://paulbourke.net/stereoscopy/pov_odsp/

Nice. It's a powerful thing the user defined camera.

ingo

[Paul Bourke] Re: mesh_camera [187 days 10 hours and 9 minutes ago]

Sat, 11 Oct 2025 04:05:00 GMT

> Actually while I had no luck with HgPovray38, Povray version 3.8 built easily.
> Now to try the user-defined camera.

A closing remark ... all working. user_defined camera is BRILLIANT!
More details here
   https://paulbourke.net/stereoscopy/pov_odsp/

[Paul Bourke] Re: mesh_camera [188 days 15 hours and 19 minutes ago]

Thu, 9 Oct 2025 22:55:00 GMT

> But now back to building 3.8 on MacOS, preferably without the GUI. Anyone with
> more skills than I have done this? I didn't succeed with HgPovray38 but perhaps
> the base 3.8 version?

Actually while I had no luck with HgPovray38, Povray version 3.8 built easily.
Now to try the user-defined camera.

[Paul Bourke] Re: mesh_camera [189 days 5 hours and 14 minutes ago]

Thu, 9 Oct 2025 09:00:00 GMT

> Have you looked at the "User defined projection" in POV-Ray 3.8?
> https://wiki.povray.org/content/Reference:Camera#User_defined_projection
> An ODS camera has been built with it:
> https://www.clodo.it/blog/omnidirectional-stereo-ods-with-pov-ray/

Ahhhh, that would be PEFECT. Easy to modify that example to create cylindrical
rather than equirectangular ODSP.

But now back to building 3.8 on MacOS, preferably without the GUI. Anyone with
more skills than I have done this? I didn't succeed with HgPovray38 but perhaps
the base 3.8 version?

[yesbird] Re: mesh_camera [189 days 5 hours and 40 minutes ago]

Thu, 9 Oct 2025 08:33:12 GMT

On 09/10/2025 06:30, Paul Bourke wrote:
> Yes, the "Omni Directional Stereo camera" in HGPOVRAY38 is what I'm looking for,
> but while building version 3.7 works out of the box on MacOS, I haven't been
> able to build HGPOVRAY38 yet. Anyone done this? Preferably just the command line
> version, no gui.

I've built it for Windows and Ubuntu 24.04, if you have some issues
building for MacOS, please send details and I will try to help,
although, unfortunately, I have no MacOS platform.
--
YB

[ingo] Re: mesh_camera [189 days 8 hours and 34 minutes ago]

Thu, 9 Oct 2025 05:40:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:

> "Omni Directional Stereo camera"

Have you looked at the "User defined projection" in POV-Ray 3.8?

https://wiki.povray.org/content/Reference:Camera#User_defined_projection

An ODS camera has been built with it:

https://www.clodo.it/blog/omnidirectional-stereo-ods-with-pov-ray/

ingo

[Paul Bourke] Re: mesh_camera [189 days 10 hours and 39 minutes ago]

Thu, 9 Oct 2025 03:35:00 GMT

> In my Mesh Camera experiments I stole some code from Jaime Vives
> Piqueres on how to save the meshes to files once I had generated them so
> subsequent renders went faster.

I saw your work and examples, it was useful when I started exploring the
mesh_camera, so thanks.

I'm creating them as an inc file also, except I'm creating them from C/C++.

But the issue remains, for high resolution images reading the mesh data is slow.
But without (efficient) antialiasing I've decided to drop this as an option.

[Paul Bourke] Re: mesh_camera [189 days 10 hours and 39 minutes ago]

Thu, 9 Oct 2025 03:35:00 GMT

yesbird wrote:
> On 06/10/2025 10:01, Paul Bourke wrote:
> > I have the need for a custom camera, specifically an omni directional
> > stereoscopic panorama (cylindrical, not equirectangular). ...
> I remember your 'Market' project:
> https://povlab.yesbird.online/pb/
>
> For rendering this animation I used HgPovray38:
> https://github.com/LeForgeron/povray
> with Omni Directional Stereo camera:
> https://wiki.povray.org/content/User:Le_Forgeron/cameras
> and then, applied video to cylinders with Three.js.
>
> I guess the projection is fine and without noticeable distortions.
> After exploring mesh cameras I switched to HgPovray, as a more reliable
> solution.

Yes, the "Omni Directional Stereo camera" in HGPOVRAY38 is what I'm looking for,
but while building version 3.7 works out of the box on MacOS, I haven't been
able to build HGPOVRAY38 yet. Anyone done this? Preferably just the command line
version, no gui.

[Paul Bourke] Re: mesh_camera [189 days 10 hours and 44 minutes ago]

Thu, 9 Oct 2025 03:30:00 GMT

> Hi! Wouldn't using stochastic sampling ("AM3") with zero value for aa but a tiny
> camera depth of field "aperture" so that you can keep its sample count minimal
> between 3 and 5, the whole thing focused at the distance of your cylinder's
> surface do the trick for you ? (I often ended uo using no aa and using only
> aperture instead in the cases where I wanted some really photographic look
> anyway. and it ended being a better trade off.

Antialiasing is not about depth of field.
The distance to the cylinder is related to where zero parallax in the ODSP.

> Otherwise, Le Forgeron's branch (HGPOVRAY38) has many additional camera types,
> (among which a stereo one) does none suit your use?

Yes, the "Omni Directional Stereo camera" in HGPOVRAY38 is what I'm looking for,
but while building version 3.7 works out of the box on MacOS, I haven't been
able to build HGPOVRAY38 yet. Anyone done this? Preferably just the command line
version, no gui.

[yesbird] Re: Vertex colors rendering [190 days 10 hours and 40 minutes ago]

Wed, 8 Oct 2025 03:33:36 GMT

On 30/09/2025 03:39, yesbird wrote:
> Working on file converter, I am importing vertex colors from FBX,
> but cant figure out why POV-Ray rendering is so much different from
> ZBrush. Maybe there is a way to control color distribution and
> smoothness ?
The reason was in gamma setting, attached image was rendered with
'assumed_gamma = 3'.
-- 
YB

[Josh English] Re: mesh_camera [191 days 22 hours and 54 minutes ago]

Mon, 6 Oct 2025 15:19:41 GMT

On 10/6/2025 12:01 AM, Paul Bourke wrote:
> I have the need for a custom camera, specifically an omni directional
> stereoscopic panorama (cylindrical, not equirectangular). I've done this in the
> long distant past by modifying the source and building my own version.
> 
> I thought I would try the mesh_camera but it seems not as useful as I imagined.
> I can readily create the meshes and am getting the right results but ...
> 
> 1. Loading the mesh takes a very long time for high resolution images. The LED
> cylinder I'm creating for is 12816x2048 pixels, even for 1/4 resolution tests
> the mesh loading takes longer than the rendering and it's probably 16x longer
> for the full resolution.
> 
> 2. Is there there still no efficient/clean way to do antialising.
> 
> Am I missing something?
> 
> 
In my Mesh Camera experiments I stole some code from Jaime Vives 
Piqueres on how to save the meshes to files once I had generated them so 
subsequent renders went faster.

The only way I've found to anti-alias is to use multiple copies of the 
mesh moved along the view plane. This also allowed for focal blur and 
motion blur. Since meshes are quick to copy this doesn't add a lot of 
overload.

I've started to experiment with the user-defined camera but I'm not 
getting results yet. The user-defined camera supposedly supports 
anti-aliasing.

Josh

[yesbird] Re: mesh_camera [192 days and 55 minutes ago]

Mon, 6 Oct 2025 13:18:14 GMT

On 06/10/2025 10:01, Paul Bourke wrote:
> I have the need for a custom camera, specifically an omni directional
> stereoscopic panorama (cylindrical, not equirectangular). ...
I remember your 'Market' project:
https://povlab.yesbird.online/pb/

For rendering this animation I used HgPovray38:
https://github.com/LeForgeron/povray
with Omni Directional Stereo camera:
https://wiki.povray.org/content/User:Le_Forgeron/cameras
and then, applied video to cylinders with Three.js.

I guess the projection is fine and without noticeable distortions.
After exploring mesh cameras I switched to HgPovray, as a more reliable
solution.
-- 
YB

[Mr] Re: mesh_camera [192 days 2 hours and 34 minutes ago]

Mon, 6 Oct 2025 11:40:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:
> I have the need for a custom camera, specifically an omni directional
> stereoscopic panorama (cylindrical, not equirectangular). I've done this in the
> long distant past by modifying the source and building my own version.
>
> I thought I would try the mesh_camera but it seems not as useful as I imagined.
> I can readily create the meshes and am getting the right results but ...
>
> 1. Loading the mesh takes a very long time for high resolution images. The LED
> cylinder I'm creating for is 12816x2048 pixels, even for 1/4 resolution tests
> the mesh loading takes longer than the rendering and it's probably 16x longer
> for the full resolution.
>
> 2. Is there there still no efficient/clean way to do antialising.
>
> Am I missing something?

Hi! Wouldn't using stochastic sampling ("AM3") with zero value for aa but a tiny
camera depth of field "aperture" so that you can keep its sample count minimal
between 3 and 5, the whole thing focused at the distance of your cylinder's
surface do the trick for you ? (I often ended uo using no aa and using only
aperture instead in the cases where I wanted some really photographic look
anyway. and it ended being a better trade off.

Otherwise, Le Forgeron's branch (HGPOVRAY38) has many additional camera types,
(among which a stereo one) does none suit your use?

[Paul Bourke] mesh_camera [192 days 7 hours and 9 minutes ago]

Mon, 6 Oct 2025 07:05:00 GMT

I have the need for a custom camera, specifically an omni directional
stereoscopic panorama (cylindrical, not equirectangular). I've done this in the
long distant past by modifying the source and building my own version.

I thought I would try the mesh_camera but it seems not as useful as I imagined.
I can readily create the meshes and am getting the right results but ...

1. Loading the mesh takes a very long time for high resolution images. The LED
cylinder I'm creating for is 12816x2048 pixels, even for 1/4 resolution tests
the mesh loading takes longer than the rendering and it's probably 16x longer
for the full resolution.

2. Is there there still no efficient/clean way to do antialising.

Am I missing something?

[yesbird] Re: Vertex colors rendering [198 days 11 hours and 39 minutes ago]

Tue, 30 Sep 2025 02:34:34 GMT

On 30/09/2025 04:54, Bald Eagle wrote:
> 
> OK - I think that also maybe the colors for your vertices are done wrong.
> 

No, now I see that the problem is not in POV-Ray - 3js renders this
cube the same way (attached). Sorry for inconvenience.
-- 
YB

[yesbird] Re: Vertex colors rendering [198 days 12 hours ago]

Tue, 30 Sep 2025 02:14:00 GMT

On 30/09/2025 04:54, Bald Eagle wrote:
> OK - I think that also maybe the colors for your vertices are done wrong.
> 
> Make your top left and bottom right four vertices white
> top right two vertices blue
> bottom left two vertices green
> 
Thanks, it looks much better !
I've checked it already, but see now any errors, will try again.
-- 
YB

[yesbird] Re: Vertex colors rendering [198 days 12 hours and 3 minutes ago]

Tue, 30 Sep 2025 02:10:31 GMT

On 30/09/2025 04:21, Bald Eagle wrote:
> You might not want to color by vertex.
> ...

Thanks for the suggestion, but I would like to keep vertex colors for
more complicated paintings, then trivial gradients.

Increasing number of polygons solves this problem and it looks fine
now, but don't you know how to make colors more saturated ?

Please, look at attachments.
-- 
YB

[Bald Eagle] Re: Vertex colors rendering [198 days 12 hours and 19 minutes ago]

Tue, 30 Sep 2025 01:55:00 GMT

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

> That's all I have - for the moment.

OK - I think that also maybe the colors for your vertices are done wrong.

Make your top left and bottom right four vertices white
top right two vertices blue
bottom left two vertices green


#declare model = mesh2 {
vertex_vectors {
  8,
  <-0.20000000298023224,0.20000000298023224,0.20000000298023224>, // 0 Left Top
Rear
  <0.20000000298023224,0.20000000298023224,0.20000000298023224>,  // 1 Right Top
Rear
  <0.20000000298023224,0.20000000298023224,-0.20000000298023224>, // 2 Right Top
Front
  <-0.20000000298023224,0.20000000298023224,-0.20000000298023224>, // 3 Left Top
Front
  <-0.20000000298023224,-0.20000000298023224,0.20000000298023224>, // 4 Left
Bottom Rear
  <0.20000000298023224,-0.20000000298023224,0.20000000298023224>, // 5 Right
Bottom Rear
  <0.20000000298023224,-0.20000000298023224,-0.20000000298023224>, // 6 Right
Bottom Front
  <-0.20000000298023224,-0.20000000298023224,-0.20000000298023224>, // 7 Left
Bottom Front
  }

texture_list {
 8,
 texture{pigment{rgb 1}}
 texture{pigment{rgb z}}
 texture{pigment{rgb z}}
 texture{pigment{rgb 1}}
 texture{pigment{rgb y}}
 texture{pigment{rgb 1}}
 texture{pigment{rgb 1}}
 texture{pigment{rgb y}}
}

face_indices {
  12,
  <0,1,2>, 0,1,2,
  <2,3,0>, 2,3,0,
  <4,5,1>, 4,5,1,
  <1,0,4>, 1,0,4,
  <5,6,2>, 5,6,2,
  <2,1,5>, 2,1,5,
  <6,7,3>, 6,7,3,
  <3,2,6>, 3,2,6,
  <7,4,0>, 7,4,0,
  <0,3,7>, 0,3,7,
  <7,6,5>, 7,6,5,
  <5,4,7>, 5,4,7,
  }
}

[Bald Eagle] Re: Vertex colors rendering [198 days 12 hours and 34 minutes ago]

Tue, 30 Sep 2025 01:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> yesbird wrote:
> > Working on file converter, I am importing vertex colors from FBX,
> > but cant figure out why POV-Ray rendering is so much different from
> > ZBrush. Maybe there is a way to control color distribution and
> > smoothness ?
> >
> > Please find images and scene in attachment.
> > --
> > YB
>
> You might not want to color by vertex.
> Maybe color the entire cube with a gradient and use blend_mode.
>
> https://wiki.povray.org/content/Reference:Pigment_Map
>
> That's all I have - for the moment.
>
> - BW

#version 3.8;

global_settings {assumed_gamma 1.0}

#include "functions.inc"

camera {
 location <0, 0, -20>
 look_at <0, 0, 0>
 right x*image_width/image_height
 up y
 sky y
}

sky_sphere {pigment {rgb 1}}

light_source {<0, 50, -50> rgb 1}


box {-5, 5
 pigment {
  gradient x
  pigment_map {
   blend_mode 0 // or 3
   [0, rgb y]
   [0.5, rgb 1]
   [1, rgb z]
  }
  scale sqrt (200)
  translate x*sqrt (200)/2
  rotate z*45
 }
}

[Bald Eagle] Re: Vertex colors rendering [198 days 12 hours and 49 minutes ago]

Tue, 30 Sep 2025 01:25:00 GMT

yesbird wrote:
> Working on file converter, I am importing vertex colors from FBX,
> but cant figure out why POV-Ray rendering is so much different from
> ZBrush. Maybe there is a way to control color distribution and
> smoothness ?
>
> Please find images and scene in attachment.
> --
> YB

You might not want to color by vertex.
Maybe color the entire cube with a gradient and use blend_mode.

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

That's all I have - for the moment.

- BW

[yesbird] Vertex colors rendering [198 days 13 hours and 34 minutes ago]

Tue, 30 Sep 2025 00:39:08 GMT

Working on file converter, I am importing vertex colors from FBX,
but cant figure out why POV-Ray rendering is so much different from
ZBrush. Maybe there is a way to control color distribution and
smoothness ?

Please find images and scene in attachment.
-- 
YB

[Francois LE COAT] Re: Optical Inertia [212 days and 44 minutes ago]

Tue, 16 Sep 2025 13:30:04 GMT

Hi,

Here's a drone's long flight through the forest in France...

	<https://www.youtube.com/watch?v=f_Zi811qWFI>

We're in rather complicated lighting conditions, with shadows and
clouds. Hence the significant noise in the video. The optical-flow
(DIS - OpenCV) that allows the determination of monocular depth
performs rather well. Mathematicians refer to this determination
as an "ill-posed problem". But statistically, for the large images
we're dealing with, it works well :-)

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [302 days and 59 minutes ago]

Wed, 18 Jun 2025 13:15:02 GMT

Hi,

Francois LE COAT writes:
>>> Here is another example of drone in the forest, outside from France:
>>>
>>> <https://www.youtube.com/watch?v=BO_OUFHFzTY> Forest
>>>
>>> We also obtained the trajectory in the X-Z plane, of the flight:
>>>
>>> <https://sketchfab.com/3d-models/forest-e253ebd61e2a4bd6abcd21ac56f25
bae> 
>>>
>>>
>>> These are filtered measurements and it's not ideal computer graphics.

>>
>> Here is a sequence of images of a ballad in the forest. This scene
>> is observed by a tracking drone...
>>
>>      <https://www.youtube.com/watch?v=46VWJ6-YqtY>
>>
>> The camera's movement is estimated in the images using a projective
>> dominant motion measurement. The presence of a man in the image sequen
ce
>> does not interfere with trajectory estimation, because the character
>> occupies a position in the field of vision that is not dominant. The
>> dominant motion corresponds to the scrolling of the scenery, that is
>> the movement of the forest relative to an observing camera.
> 
> Here is a drone in the forest...
> 
> <https://www.youtube.com/watch?v=h3vhlRBB9tg> Forest
> 
> We also obtain the trajectory in space: <https://skfb.ly/pxGqL>
> 
> It's interesting to note that this trajectory loops. That is to say,
> the drone passes over the professional pilot's location, and is in
> the same place at the end of the video.
> 
> This proves the quality of the trajectory estimation in space. :-)

Here's a long drone flight through a Swedish forest...

<https://www.youtube.com/watch?v=ppW5BbDPFHc> Swedish forest

We obtain the estimated trajectory in space: <https://skfb.ly/pxZHy>

The image matching algorithm doesn't incorporate any prior knowledge
about what the camera is observing. This might look like a SLAM
(Simultaneous Localization And Mapping) method, which is a sparse
method, but what is presented is a global and dense method based
on optical-flow measurement (Dense Inverse Search - DIS).

This is an algorithm, i.e. a numerical recipe, that does not use
artificial neural networks. We obtain a filtered measurement (by
a Kalman filter) of physical data.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Vector handling [310 days 12 hours and 24 minutes ago]

Tue, 10 Jun 2025 01:50:00 GMT

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

> In the absence of a vector triggering a misidentification, I'm going to call
> this 30+ year stumbling block solved.

OK, I spoke too soon - I was lazy and was leaving out the testing of the
scalars.
Somehow _1_ broke it.
I modified, then _0_ broke it.

I modified again, looked good, tested with sizes 1-5, and all looked well.

IIRC, what brought me back to this was an annoyance with needing to test all
vector sizes separately with size-dependent macros.  And I think I needed a
general solution for . . . something.

I also vaguely recall that sometimes I wanted to compare vectors of unequal
sizes - only comparing the number of components of the smallest vector.
So I added a Boolean flag to do a partial comparison.

And this is what I have so far.  Ugly development code, warts and all.

Needs more testing, since there's probably something else lurking in there.

- BW

[Bald Eagle] Re: Vector handling [310 days 14 hours and 49 minutes ago]

Mon, 9 Jun 2025 23:25:00 GMT

Looped PermuteVectorComponents (5) fifty times.
Commented out the fopen-write-fclose since I don't need the output in the
absence of misindentifications.

run time
4m 42s

843196 vectors written to TestedValues.txt.
843196 identified correctly.
0 misidentified.

In the absence of a vector triggering a misidentification, I'm going to call
this 30+ year stumbling block solved.

It would be great if I didn't clog the warning stream with 843,000+ "suspicious
expression after rgb" messages . . .      :\

- BW

P.S. I'm also thinking that maybe the folks over on one of the math / statistics
fora could come up with a better / more efficient way.

[Bald Eagle] Re: Vector handling [310 days 15 hours and 4 minutes ago]

Mon, 9 Jun 2025 23:10:01 GMT

I added 2 more bracketing values to be randomized between -100 and 100, then ran
it again.

19604 identified correctly.
0 misidentified.

Then I ran everything again plus had the the macro generate 5-component vectors
(the former problem) 5 times in a row (randomized).

86836 vectors written to TestedValues.txt.
86836 identified correctly.
0 misidentified.

It's looking good.   :)

-BW

[Bald Eagle] Re: Vector handling [310 days 15 hours and 44 minutes ago]

Mon, 9 Jun 2025 22:30:00 GMT

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

> 3904 vectors written to TestedValues.txt.
> 3204 identified correctly.
> 700 misidentified.

> I will modify to output the offending vectors to a separate file, and then get
> on with seeing if there's a way to "win".

And there seems to be (at the moment)!

3904 vectors written to TestedValues.txt.
3904 identified correctly.
0 misidentified.

CPU time used: kernel 2.59 seconds, user 1.34 seconds, total 3.93 seconds.
Elapsed time 3.98 seconds.

NOW see if you can break it!

- BW

[Bald Eagle] Re: Vector handling [315 days 13 hours and 54 minutes ago]

Thu, 5 Jun 2025 00:20:00 GMT

Ugggggggh.

I got the vector-creating to work, plugged that into the permutation macro, and
got everything written to a file.

Got an error in my scalar part of the #if block, which led me to believe that
there was a misidentification.

So I made a few modifications, and this is what I presently have:

3904 vectors written to TestedValues.txt.
3204 identified correctly.
700 misidentified.

So there is some combination of values that sabotage my algorithm (which is
exactly why I wanted to test 3904 vectors).

I will modify to output the offending vectors to a separate file, and then get
on with seeing if there's a way to "win".

- BW

[Bald Eagle] Re: Vector handling [316 days 1 hour and 49 minutes ago]

Wed, 4 Jun 2025 12:25:00 GMT

OK, there was nary a drop of coffee in my veins, my eyes were blurry, and I was
fielding questions about an interstate flight while trying to process this.

After re-reading after Second Coffee, I can probably use a #for loop to plug the
appropriate number of array elements into a vector to get what I want.

Will try that after I get home 8h from now ... <eyeroll>

Anyway, try the type-identifying macro and see what you think.

Sorry for the confusion.

- BW

[Bald Eagle] Re: Vector handling [316 days 3 hours and 29 minutes ago]

Wed, 4 Jun 2025 10:45:00 GMT

Long time, no see, Mr. K   :)
I hope you are personally well, and professionally successful.

Now with
https://news.povray.org/povray.general/message/%3Cweb.682bc388985098ff1f9dae3025979125%40news.povray.org%3E/#%3Cweb.682
bc388985098ff1f9dae3025979125%40news.povray.org%3E

You don't need the whole #switch block below to handle individual vector sizes.

just
#declare SV = VectorDimTest (v0);
#debug concat("<", vstr(2, SV, ", ", 0, -1), ">")

>
> #macro PrintSCalarOrVector(Dim, SV)
>
>     #switch (Dim)
>         #case (1)
>             #debug str(SV, 0, -1)
>             #break
>         #case (2)
>             #debug concat("<", vstr(2, SV, ", ", 0, -1), ">")
>             #break
>         #case (3)
>             #debug concat("<", vstr(3, SV, ", ", 0, -1), ">")
>             #break
>         #case (4)
>             #debug concat("<", vstr(4, SV, ", ", 0, -1), ">")
>             #break
>         #case (5)
>             #debug concat("<", vstr(5, SV, ", ", 0, -1), ">")
>             #break
>         #else
>             #error "Not a valid vector dimension"
>     #end // switch
>
> #end // macro PrintSCalarOrVector


Also, when I stated that i couldn't change Vector.z, I meant by directly
addressing it, like you're doing below with array elements.
I can't say #declare Vector.z = NewValue.
And the awkwardness really kicks in when I'm trying to create a macro like
#macro PermuteVector (SV)

where I just want to make any size vector on the fly and have the result of the
macro be a vector of size SV.   Because it is NOT like working with arrays.

I started off by doing
#local V = array {<1, 0, 0, 0, 0>, <0, 1, 0, 0, 0>, <0, 0, 1, 0, 0>, <0, 0, 0,
1, 0>, <0, 0, 0, 0, 1>};
#local Vector = <0, 0, 0, 0, 0>;

to "address" the individual components (in)directly, but now I'm stuck not
knowing how to take <1, 2, 3, 0, 0> and convert it to <1, 2, 3>.

I would like a simple method to MAKE vectors of an arbitrary (allowed) size,
just like vstr () PRINTS vectors of an arbitrary size.
#declare MyVector = mstr (...)

This sort of hearkens back to the epic dot notation thread where I suggested
vec.n where n = 1...5 as a valid syntax (though that still wouldn't solve the
problem, given the inability to use those as an LValue)

Making a vector from array elements requires a lot of hands-on, fussy, one-off
coding for specially constructing each individual size of vector.  POV-Ray
should be better than that.

- BW

> #macro CreateScalarOrVector(ValueArray)
>
>     #local Dim = dimension_size(ValueArray, 1);
>     #switch (Dim)
>         #case (1)
>             #local SV =
>                 ValueArray[0]
>             ;
>             #break
>         #case (2)
>             #local SV =
>                 <
>                     ValueArray[0],
>                     ValueArray[1]
>                 >
>              ;
>             #break
>         #case (3)
>             #local SV =
>                 <
>                     ValueArray[0],
>                     ValueArray[1],
>                     ValueArray[2]
>                 >
>             ;
>             #break
>         #case (4)
>             #local SV =
>                 <
>                     ValueArray[0],
>                     ValueArray[1],
>                     ValueArray[2],
>                     ValueArray[3]
>                 >
>             ;
>             #break
>         #case (5)
>             #local SV =
>                 <
>                     ValueArray[0],
>                     ValueArray[1],
>                     ValueArray[2],
>                     ValueArray[3],
>                     ValueArray[4]
>                 >
>             ;
>             #break
>         #else
>             #error "Not a valid vector dimension"
>     #end // switch
>
>     SV
>
> #end // macro CreateScalarOrVector

[Tor Olav Kristensen] Re: Vector handling [316 days 9 hours and 54 minutes ago]

Wed, 4 Jun 2025 04:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> There's no way to really assign a value to the individual vector component
> Vector.z, ...

I'm not sure if I understand what you mean.

I just tried this - and it seems to work like I expected.


#declare v2D = <2, 3>;
#declare NewV = -33;

#declare v2D = <v2D.u, NewV>;
PrintSCalarOrVector(2, v2D)
#debug "\n"

#declare v2D = v2D*u + NewV*v;
PrintSCalarOrVector(2, v2D)
#debug "\n"

#declare v2D = v2D*<1, 0> + <0, NewV>;
PrintSCalarOrVector(2, v2D)
#debug "\n"


#declare v3D = <3, 4, 5>;
#declare NewZ = -55;

#declare v3D = <v3D.x, v3D.y, NewZ>;
PrintSCalarOrVector(3, v3D)
#debug "\n"

#declare v3D = v3D*(x + y) + NewZ*z;
PrintSCalarOrVector(3, v3D)
#debug "\n"

#declare v3D = v3D*<1, 1, 0> + <0, 0, NewZ>;
PrintSCalarOrVector(3, v3D)
#debug "\n"


#declare v4D = <4, 5, 6, 7>;
#declare NewT = -77;

#declare v4D = <v4D.x, v4D.y, v4D.z, NewT>;
PrintSCalarOrVector(4, v4D)
#debug "\n"

#declare v4D = v4D*(x + y + z) + NewT*t;
PrintSCalarOrVector(4, v4D)
#debug "\n"

#declare v4D = v4D*<1, 1, 1, 0> + <0, 0, 0, NewT>;
PrintSCalarOrVector(4, v4D)
#debug "\n"


#declare v5D = <5, 6, 7, 8, 9>;
#declare NewTransmit = -99;

#declare v5D = <v5D.red, v5D.green, v5D.blue, v5D.filter, NewTransmit>;
PrintSCalarOrVector(5, v5D)
#debug "\n"

#declare v5D = v5D*<1, 1, 1, 1, 0> + <0, 0, 0, 0, NewTransmit>;
PrintSCalarOrVector(5, v5D)
#debug "\n"

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

[Tor Olav Kristensen] Re: Vector handling [316 days 10 hours and 44 minutes ago]

Wed, 4 Jun 2025 03:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> In light of the fact that I was able to solve the scalar / vector typing
> problem,  I wanted to do a test of the macro with a full complement of vectors
> that are composed of all permutations of negative, zero, and positive values, so
> that I can test anything that might trigger some edge case and cause the macro
> to fail and misidentify an argument.
>
> To do that, I wrote a macro to generate all of the permutations for any given
> vector size, however it quickly became apparent that actually outputting vectors
> of any given size is a challenge.
>
> There's no way to really assign a value to the individual vector component
> Vector.z, so I'm coming up against an interesting limitation of SDL.  It's not a
> trivial task to take an array of values and convert it to a vector.
> Nor can I (that I know) diminish the size of a vector from 5 to 3.
>
> (Can we have 1-component vectors?)
>
> I don't want to use ParseString () to generate 4,000 vectors.
> I also don't want to individually verify every test case, so I'll probably make
> the output of the macro a scalar/vector plus the type (1, 2, 3, 4, 5) and have
> the identification macro compare, and sum any errors.
>
> Can anyone suggest a robust method for composing vectors of sizes 2 through 5
> with a single, general purpose macro?

Hi Bill

Could this be something to work with?

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#macro PrintSCalarOrVector(Dim, SV)

    #switch (Dim)
        #case (1)
            #debug str(SV, 0, -1)
            #break
        #case (2)
            #debug concat("<", vstr(2, SV, ", ", 0, -1), ">")
            #break
        #case (3)
            #debug concat("<", vstr(3, SV, ", ", 0, -1), ">")
            #break
        #case (4)
            #debug concat("<", vstr(4, SV, ", ", 0, -1), ">")
            #break
        #case (5)
            #debug concat("<", vstr(5, SV, ", ", 0, -1), ">")
            #break
        #else
            #error "Not a valid vector dimension"
    #end // switch

#end // macro PrintSCalarOrVector


#debug "\n"

PrintSCalarOrVector(1, 1.0)
#debug "\n"

PrintSCalarOrVector(2, <2.0, 3.0>)
#debug "\n"

PrintSCalarOrVector(3, <3.0, 4.0, 5.0>)
#debug "\n"

PrintSCalarOrVector(4, <4.0, 5.0, 6.0, 7.0>)
#debug "\n"

PrintSCalarOrVector(5, <5.0, 6.0, 7.0, 8.0, 9.0>)
#debug "\n"


#macro CreateScalarOrVector(ValueArray)

    #local Dim = dimension_size(ValueArray, 1);
    #switch (Dim)
        #case (1)
            #local SV =
                ValueArray[0]
            ;
            #break
        #case (2)
            #local SV =
                <
                    ValueArray[0],
                    ValueArray[1]
                >
             ;
            #break
        #case (3)
            #local SV =
                <
                    ValueArray[0],
                    ValueArray[1],
                    ValueArray[2]
                >
            ;
            #break
        #case (4)
            #local SV =
                <
                    ValueArray[0],
                    ValueArray[1],
                    ValueArray[2],
                    ValueArray[3]
                >
            ;
            #break
        #case (5)
            #local SV =
                <
                    ValueArray[0],
                    ValueArray[1],
                    ValueArray[2],
                    ValueArray[3],
                    ValueArray[4]
                >
            ;
            #break
        #else
            #error "Not a valid vector dimension"
    #end // switch

    SV

#end // macro CreateScalarOrVector


#debug "\n"

#declare VS =
    CreateScalarOrVector(
        array[1] { 1.0 }
    )
;
PrintSCalarOrVector(1, VS)
#debug "\n"

#declare VS =
    CreateScalarOrVector(
        array[2] { 2.0, 3.0 }
    )
;
PrintSCalarOrVector(2, VS)
#debug "\n"

#declare VS =
    CreateScalarOrVector(
        array[3] { 3.0, 4.0, 5.0 }
    )
;
PrintSCalarOrVector(3, VS)
#debug "\n"

#declare VS =
    CreateScalarOrVector(
        array[4] { 4.0, 5.0, 6.0, 7.0 }
    )
;
PrintSCalarOrVector(4, VS)
#debug "\n"

#declare VS =
    CreateScalarOrVector(
        array[5] { 5.0, 6.0, 7.0, 8.0, 9.0 }
    )
;
PrintSCalarOrVector(5, VS)
#debug "\n"

#debug "\n"
#error "No error, just finished"


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

[Bald Eagle] Vector handling [316 days 13 hours and 9 minutes ago]

Wed, 4 Jun 2025 01:05:00 GMT

In light of the fact that I was able to solve the scalar / vector typing
problem,  I wanted to do a test of the macro with a full complement of vectors
that are composed of all permutations of negative, zero, and positive values, so
that I can test anything that might trigger some edge case and cause the macro
to fail and misidentify an argument.

To do that, I wrote a macro to generate all of the permutations for any given
vector size, however it quickly became apparent that actually outputting vectors
of any given size is a challenge.

There's no way to really assign a value to the individual vector component
Vector.z, so I'm coming up against an interesting limitation of SDL.  It's not a
trivial task to take an array of values and convert it to a vector.
Nor can I (that I know) diminish the size of a vector from 5 to 3.

(Can we have 1-component vectors?)

I don't want to use ParseString () to generate 4,000 vectors.
I also don't want to individually verify every test case, so I'll probably make
the output of the macro a scalar/vector plus the type (1, 2, 3, 4, 5) and have
the identification macro compare, and sum any errors.

Can anyone suggest a robust method for composing vectors of sizes 2 through 5
with a single, general purpose macro?


Thanks

- BE

[Francois LE COAT] Re: Optical Inertia [321 days and 23 minutes ago]

Fri, 30 May 2025 13:51:05 GMT

Hi,

Francois LE COAT writes:
>> Here is another example of drone in the forest, outside from France:
>>
>> <https://www.youtube.com/watch?v=BO_OUFHFzTY> Forest
>>
>> We also obtained the trajectory in the X-Z plane, of the flight:
>>
>> <https://sketchfab.com/3d-models/forest-e253ebd61e2a4bd6abcd21ac56f25b
ae>
>>
>> These are filtered measurements and it's not ideal computer graphics.
> 
> Here is a sequence of images of a ballad in the forest. This scene
> is observed by a tracking drone...
> 
>      <https://www.youtube.com/watch?v=46VWJ6-YqtY>
> 
> The camera's movement is estimated in the images using a projective
> dominant motion measurement. The presence of a man in the image sequenc
e
> does not interfere with trajectory estimation, because the character
> occupies a position in the field of vision that is not dominant. The
> dominant motion corresponds to the scrolling of the scenery, that is
> the movement of the forest relative to an observing camera.

Here is a drone in the forest...

<https://www.youtube.com/watch?v=h3vhlRBB9tg> Forest

We also obtain the trajectory in space: <https://skfb.ly/pxGqL>

It's interesting to note that this trajectory loops. That is to say,
the drone passes over the professional pilot's location, and is in
the same place at the end of the video.

This proves the quality of the trajectory estimation in space. :-)

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [336 days 1 hour and 29 minutes ago]

Thu, 15 May 2025 12:45:01 GMT

Hi,

Francois LE COAT writes:
> Here is another example of drone in the forest, outside from France:
> 
> <https://www.youtube.com/watch?v=BO_OUFHFzTY> Forest
> 
> We also obtained the trajectory in the X-Z plane, of the flight:
> 
> <https://sketchfab.com/3d-models/forest-e253ebd61e2a4bd6abcd21ac56f25ba
e>
> 
> These are filtered measurements and it's not ideal computer graphics.

Here is a sequence of images of a ballad in the forest. This scene
is observed by a tracking drone...

	<https://www.youtube.com/watch?v=46VWJ6-YqtY>

The camera's movement is estimated in the images using a projective
dominant motion measurement. The presence of a man in the image sequence
does not interfere with trajectory estimation, because the character
occupies a position in the field of vision that is not dominant. The
dominant motion corresponds to the scrolling of the scenery, that is
the movement of the forest relative to an observing camera.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Doyle Spiral [345 days 16 hours and 54 minutes ago]

Mon, 5 May 2025 21:20:01 GMT

While working on several projects, I've wanted/needed to implement various
spiral patterns, and the Doyle Spiral is an especially interesting one.

Luckily, I was able to find a good write-up on a Mathematica implementation, as
well as a basic implementation in POV-Ray.

The POV-Ray implementation, although somewhat recent, seemed to have been coded
by someone who hadn't used POV-Ray in a long while, and so used some (what I'd
consider) deprecated code, and bad coding methods (some global identifiers
caused me some debugging grief).  The exponentiation of the complex numbers was
awkwardly (and unnecessarily) split into two parts, where a single general
method works just fine for all exponents.

Adding the lines ("linear spirals" as opposed to the "circular spirals") was a
long, bumpy ride on the struggle bus, due to simultaneously trying to understand
the fundamentals of what was going on, trying to make that happen with complex
numbers, and being interrupted all day by RL things.

I still need to convert a bunch of stuff that's in macro form to functions,
finish the last bit of complex interpolation, create a prism macro, and then
finally apply a Möbius transform before actually rendering the spiral.

Enjoy.

- BE

[Francois LE COAT] Re: Optical Inertia [364 days and 59 minutes ago]

Thu, 17 Apr 2025 13:15:04 GMT

Hi,

Francois LE COAT writes:
>>> Monocular Depth:
>>>
>>> <https://www.youtube.com/watch?v=34zUDqEzHos>
>>>
>>> A drone flies between the trees of a forest. Thanks to the optical-fl
ow
>>> measured on successive images, the temporal disparity reveals the
>>> forest of trees... We take a reference image, the optical-flow is
>>> measured on two rectified images. Then we change the reference when
>>> the inter-correlation drops below 60%. We can perceive the relief in
>>> depth with a single camera, over time.
>>>
>>> In fact, when we watch images captured by a drone, although there is
>>> only one camera, we often see the relief. This is particularly marked

>>> for trees in a forest. The goal here is to evaluate this relief, with
 a
>>> measurement of "optical-flow", which allows one image to be matched w
ith
>>> another, when they seem to be close (we say they are "correlated").
>>>
>>> We have two eyes, and the methods for measuring visible relief by 
>>> stereoscopy are very developed. Since the beginning of photography,
>>> there were devices like the â€œstereoscopeâ€ which
allow
s you to see the
>>> relief with two pictures, naturally. It is possible to measure relief
,
>>> thanks to epipolar geometry, and well-known mathematics. There are ma
ny
>>> measurement methods, very effective and based on human vision.
>>>
>>> When it comes to measuring relief with a single camera, knowledge is
>>> less established. There are 3D cameras, called "RGBD" with a "D" for 

>>> "depth". But how do they work? Is it possible to improve those? What
>>> I am showing here does not require the use of any â€œartificial
 neural
>>> networkâ€. It is a physical measurement, with a classic algori
thm,
>>> which does not come from A.I. nor a big computer :-)
>>
>> A WEB page was made to illustrate Monocular Depth...
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/monocul
ar_depth.html> 
>>
>>
>> This is about measuring monocular depth, just as stereoscopic disparit
y
>> is measured. It means quantifying the depth, with images from a single

>> camera. We can see this relief naturally, but it is a matter of
>> measuring it with the optical-flow :-)
> 
> Until now, drone images came from forests in France. The first images
> were obtained in the French Vosges.
> 
> <https://www.youtube.com/watch?v=245yJJrwMQ0> Drone in the forest
> 
> We are now seeing more and more drones in forests outside of France.
> The available image sources are diversifying...

Here is another example of drone in the forest, outside from France:

	<https://www.youtube.com/watch?v=BO_OUFHFzTY> Forest

We also obtained the trajectory in the X-Z plane, of the flight:

<https://sketchfab.com/3d-models/forest-e253ebd61e2a4bd6abcd21ac56f25bae>


These are filtered measurements and it's not ideal computer graphics.

Best regards,

-- 
FranÃ§ois LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [379 days 20 hours and 59 minutes ago]

Tue, 1 Apr 2025 17:15:03 GMT

Hi,

Francois LE COAT writes:
>> Monocular Depth:
>>
>> <https://www.youtube.com/watch?v=34zUDqEzHos>
>>
>> A drone flies between the trees of a forest. Thanks to the optical-flo
w
>> measured on successive images, the temporal disparity reveals the
>> forest of trees... We take a reference image, the optical-flow is
>> measured on two rectified images. Then we change the reference when
>> the inter-correlation drops below 60%. We can perceive the relief in
>> depth with a single camera, over time.
>>
>> In fact, when we watch images captured by a drone, although there is
>> only one camera, we often see the relief. This is particularly marked
>> for trees in a forest. The goal here is to evaluate this relief, with 
a
>> measurement of "optical-flow", which allows one image to be matched wi
th
>> another, when they seem to be close (we say they are "correlated").
>>
>> We have two eyes, and the methods for measuring visible relief by 
>> stereoscopy are very developed. Since the beginning of photography,
>> there were devices like the â€œstereoscopeâ€ which
allows
 you to see the
>> relief with two pictures, naturally. It is possible to measure relief,

>> thanks to epipolar geometry, and well-known mathematics. There are man
y
>> measurement methods, very effective and based on human vision.
>>
>> When it comes to measuring relief with a single camera, knowledge is
>> less established. There are 3D cameras, called "RGBD" with a "D" for 
>> "depth". But how do they work? Is it possible to improve those? What
>> I am showing here does not require the use of any â€œartificial 
neural
>> networkâ€. It is a physical measurement, with a classic algorit
hm,
>> which does not come from A.I. nor a big computer :-)
> 
> A WEB page was made to illustrate Monocular Depth...
> 
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/monocula
r_depth.html> 
> 
> 
> This is about measuring monocular depth, just as stereoscopic disparity

> is measured. It means quantifying the depth, with images from a single
> camera. We can see this relief naturally, but it is a matter of
> measuring it with the optical-flow :-)

Until now, drone images came from forests in France. The first images
were obtained in the French Vosges.

<https://www.youtube.com/watch?v=245yJJrwMQ0> Drone in the forest

We are now seeing more and more drones in forests outside of France.
The available image sources are diversifying...

Best regards,

-- 
FranÃ§ois LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Apparent circular pattern of scratches [392 days 23 hours and 24 minutes ago]

Wed, 19 Mar 2025 14:50:00 GMT

Resurrecting an old thread, since I'm digging around with a search engine to
find old scenes / files/ etc. for the organized archive project.

> When you look at a light source's reflection on a smooth piece of glass or metal
> or plastic, the scratches all tend to appear as a series of arcs and lines
> roughly in a circular pattern centered around the "hotspot".

https://blenderartists.org/t/scratches-around-relflection/614851/16

https://web.archive.org/web/20180201063002/http://viscorbel.com/microscratches-swirl-marks-spiderwebbing-vray-tutorial/


- BW

[yesbird] Getting the most from hardware [396 days 1 hour and 47 minutes ago]

Sun, 16 Mar 2025 12:26:11 GMT

I want to compile POV-Ray with maximum support of hardware features,
including AVX2, for example. Could you tell me please, how to do that ?

And how can I know what features already supported by present binary ?
All I can see running the binary is:
---------------------------------------------------------------------
Dynamic optimizations:
   CPU detected: Intel,FMA3,FMA4
   Noise generator: generic (portable)
---------------------------------------------------------------------

I tried to configure it the following way:
---------------------------------------------------------------------
user@ruby3:~/projects/povray$ ./configure --enable-avx2 --without-x 
--prefix=/home/user/povray  COMPILED_BY="Yesbird <yes### [at] gmailcom>" 
| grep -i avx

configure: WARNING: unrecognized options: --enable-avx2
checking whether C++ compiler accepts -mavx... yes
checking whether C++ compiler accepts -mavx2... yes
---------------------------------------------------------------------
but as you can see without success.

My CPU support following flags:
---------------------------------------------------------------------
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
abm 3dnowprefetch cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow
flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2
erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec
xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window
hwp_epp vnmi md_clear flush_l1d arch_capabilities
---------------------------------------------------------------------
--
YB

[yesbird] Re: Calculating normal vectors for meshes [396 days 19 hours and 55 minutes ago]

Sat, 15 Mar 2025 18:18:42 GMT

On 15/03/2025 20:44, GioSeregni wrote:
> This is my easy code for the normals
> easy to translate to any language
> ...

Many thanks, it looks very simple, I will implement it without a
problem.
--
YB

[GioSeregni] Re: Calculating normal vectors for meshes [396 days 20 hours and 29 minutes ago]

Sat, 15 Mar 2025 17:45:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 15/03/2025 11:57, Thomas de Groot wrote:
> > That mesh looks definitely to be corrupt and needs repairing first!
>
> Maybe, but POV-Ray renders it without problems and I don't see any
> issues in syntax. Moreover, I found alternative solution already.
> --
> YB

This is my easy code for the normals
easy to translate to any language

xVD=(FACE.y1-FACE.y0)*(FACE.z2-FACE.z0)-(FACE.z1-FACE.z0)*(FACE.y2-FACE.y0)
yVD=(FACE.z1-FACE.z0)*(FACE.x2-FACE.x0)-(FACE.x1-FACE.x0)*(FACE.z2-FACE.z0)
zVD=(FACE.x1-FACE.x0)*(FACE.y2-FACE.y0)-(FACE.y1-FACE.y0)*(FACE.x2-FACE.x0)
NoDivBy0=xVD*xVD+yVD*yVD+zVD*zVD
IF NoDivBy0=0 THEN NoDivBy0=0.000000000001
xND=xVD/sqr(NoDivBy0)
yND=yVD/sqr(NoDivBy0)
zND=zVD/sqr(NoDivBy0)

[yesbird] Re: Calculating normal vectors for meshes [397 days 2 hours and 24 minutes ago]

Sat, 15 Mar 2025 11:49:29 GMT

On 15/03/2025 11:57, Thomas de Groot wrote:
> That mesh looks definitely to be corrupt and needs repairing first!

Maybe, but POV-Ray renders it without problems and I don't see any
issues in syntax. Moreover, I found alternative solution already.
--
YB

[Thomas de Groot] Re: Calculating normal vectors for meshes [397 days 5 hours and 16 minutes ago]

Sat, 15 Mar 2025 08:57:44 GMT

Op 14/03/2025 om 15:17 schreef yesbird:
> On 14/03/2025 14:59, yesbird wrote:
>> Working on a data converter from ZBrush's GoZ to Povray's mesh2 format
>> ...
> 
> Thanks for your suggestions, I have Poseray, but for unknown reasons
> it doesn't like my mesh (please, see attached image). Looks like the
> the best solution will be to calculate normals myself in the converter's
> code.
> 
That mesh looks definitely to be corrupt and needs repairing first!

> Bill, I will be glad to look at your code for reference.
> -- 
> YB


-- 
Thomas

[yesbird] Re: Calculating normal vectors for meshes [397 days 19 hours and 40 minutes ago]

Fri, 14 Mar 2025 18:33:08 GMT

On 14/03/2025 18:36, Bald Eagle wrote:
> Hmm.  That's interesting.
> Maybe there's a hole in the mesh, and it needs to get repaired?
> ...

Yes, the mesh produced by my converter, but a workaround with Blender
solved all the problems. Thank you for your assistance.
--
YB

[Bald Eagle] Re: Calculating normal vectors for meshes [397 days 22 hours and 34 minutes ago]

Fri, 14 Mar 2025 15:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> Thanks for your suggestions, I have Poseray, but for unknown reasons
> it doesn't like my mesh (please, see attached image).

Hmm.  That's interesting.
Maybe there's a hole in the mesh, and it needs to get repaired?

Perhaps try:
https://www.meshlab.net/

and see if that, or another similar tool helps after a round of fixing?

- BW

Are you generating your mesh programmatically?
Are you using an implicit or parametric equation to define the surface?

[yesbird] Re: Calculating normal vectors for meshes [397 days 23 hours and 56 minutes ago]

Fri, 14 Mar 2025 14:17:46 GMT

On 14/03/2025 14:59, yesbird wrote:
> Working on a data converter from ZBrush's GoZ to Povray's mesh2 format
> ...

Thanks for your suggestions, I have Poseray, but for unknown reasons
it doesn't like my mesh (please, see attached image). Looks like the
the best solution will be to calculate normals myself in the converter's
code.

Bill, I will be glad to look at your code for reference.
--
YB

[Thomas de Groot] Re: Calculating normal vectors for meshes [398 days 1 hour and 6 minutes ago]

Fri, 14 Mar 2025 13:07:42 GMT

Op 14/03/2025 om 13:52 schreef Bald Eagle:
> yesbird <sya### [at] gmailcom> wrote:
> 
>> Is there some ready-to-use code or utility for normal vectors
>> calculation for meshes ?
> 
> You'd think there was.  And I suppose that there really ought to be some
> existing under-the-hood calculation of normals for smooth_triangles.
> 
> (Maybe Pose-Ray does it?  Silo?   TdG would know)
> 
Yes indeed: Poseray does the job and is easy to use.

https://sites.google.com/site/poseray/

Not sure about Silo. It can manipulate them though, and it is a complex 
program. However, it is not free software as Poseray is.

-- 
Thomas

[Bald Eagle] Re: Calculating normal vectors for meshes [398 days 1 hour and 19 minutes ago]

Fri, 14 Mar 2025 12:55:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> Is there some ready-to-use code or utility for normal vectors
> calculation for meshes ?

You'd think there was.  And I suppose that there really ought to be some
existing under-the-hood calculation of normals for smooth_triangles.

(Maybe Pose-Ray does it?  Silo?   TdG would know)

I'd say that what you're going to have to do is take all of your triangle data
and put it into an array, and then cycle through the array to make your smooth
triangles and calculate normals manually.

I'm at work for the next 7 hours, but I can post working code from one of my
mesh / mesh2 scenes if no one beats me to it.

- BW

[Mr] Re: Calculating normal vectors for meshes [398 days 1 hour and 44 minutes ago]

Fri, 14 Mar 2025 12:30:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Working on a data converter from ZBrush's GoZ to Povray's mesh2 format
> I found that GoZ does not contain normal vectors, so all mesh renderings
> are flat. Is there some ready-to-use code or utility for normal vectors
> calculation for meshes ?
>
> Present mesh2 example is attached.
> --
> YB

Interested if there is one, but meanwhile you could import your pov file into
Blender using POV@Ble (https://extensions.blender.org/add-ons/povable) and
re-export pov file after using the shade smooth command from Object menu
(https://docs.blender.org/manual/en/2.91/scene_layout/object/editing/shading.html).
If anything goes wrong it now has its own issue tracker, and reporting any
trouble may help these to get priority over other issues or regressions.

[yesbird] Calculating normal vectors for meshes [398 days 2 hours and 14 minutes ago]

Fri, 14 Mar 2025 11:59:51 GMT

Working on a data converter from ZBrush's GoZ to Povray's mesh2 format
I found that GoZ does not contain normal vectors, so all mesh renderings
are flat. Is there some ready-to-use code or utility for normal vectors
calculation for meshes ?

Present mesh2 example is attached.
--
YB

[William F Pokorny] Re: Spherical Heightfields [401 days 4 hours and 36 minutes ago]

Tue, 11 Mar 2025 09:37:26 GMT

On 3/10/25 22:36, Maetes wrote:
> On my blog I have uploaded some results that are quite impressive.
> Several images, some in stereo, and a video.
> More is in the works, publication maybe next week.
> 
> Blog:
> https://www.maetes.com/en/astro/moon-renderings-first-results

Those look pretty good!

A long time ago - 20yrs maybe - I did a bunch of renders of the moon and 
doubt any as were good as those you've posted. :-)

One thing I saw on your first post in this thread 'I think', but I 
didn't mention is that you were not using any interpolation with your 
image_map{} (people often us 2 or 3).

This can help smooth things out with isosurfaces using images for 
offsets when your rendered image resolution nears the resolution of the 
displacement image. At some magnification the limits of the actual image 
information will show - and first away from the poles in a spherical image.

Blurring the image with an image processing tool an option too.

Blurring and interpolation come with the price of distortion, but more 
or less we are always approximating things to some degree.

Bill P.

[Maetes] Re: Spherical Heightfields [401 days 11 hours and 34 minutes ago]

Tue, 11 Mar 2025 02:40:00 GMT

Hi William,
thanks for your textfile.

I had to struggle with artifacts like in the left column of your picture, they
are now gone.
Looks good so far, only at high magnifications I have to deal with vertical
lines, see picture.
I want to work on it again in the next few days and see if I can improve it.
Will try the hints in your article, especially change accuracy settings.

On my blog I have uploaded some results that are quite impressive.
Several images, some in stereo, and a video.
More is in the works, publication maybe next week.

Blog:
https://www.maetes.com/en/astro/moon-renderings-first-results

Youtube (Bad Quality, dont know why):
https://youtu.be/WbDMOhXn8FI

Adios,
M

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [410 days 14 hours and 34 minutes ago]

Sat, 1 Mar 2025 23:40:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> It is interesting to see the discontinuities visualized like this.
>
> Have you also made similar tools for working with curved surfaces?

That was what the whole Gaussian curvature project was about.
Iterating over a surface and showing the curvature combs would be - messy.

I also covered the various production methods of visualizing curvature and
discontinuities using zebra stripes, dots, isophotes, etc.

There is, of course, always so much more to do with this stuff.

- BW

[Tor Olav Kristensen] Re: Smooth, continuous Bezier splines (again) [410 days 21 hours and 34 minutes ago]

Sat, 1 Mar 2025 16:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> That approach was also close to what I was doing, however it doesn't match the
> curvature of the spline segments at the endpoints.
>
> Visually, it still looked too flat-then rounded-then flat-then rounded....
>
> Although I didn't pore over your code yet, I quickly skimmed it to see where the
> control points were calculated, and then bolted on my curvature comb code to
> visualize the curvature over all of the spline segments.
>
> You can see where the mismatches are.
>
> So I still think I have to degree elevate and then I can mirror the additional
> control points to get the curvature to match.
>
> (Also, FYI: the point/tip is actually a hard point.  So 2 separate composite
> splines - 1 on the left and 1 on the right)
>
> I'll see if I have enough time to patch in my degree elevation code and extend
> the control-point mirroring that one extra "level" into the splines.

It is interesting to see the discontinuities visualized like this.

Have you also made similar tools for working with curved surfaces?

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

[Tor Olav Kristensen] Re: Making Patterns with functions [410 days 22 hours and 34 minutes ago]

Sat, 1 Mar 2025 15:40:00 GMT

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

I like this pattern.

It's lovely!

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

[William F Pokorny] Re: Spherical Heightfields [410 days 23 hours and 39 minutes ago]

Sat, 1 Mar 2025 14:35:01 GMT

On 2/26/25 02:01, Maetes wrote:
> One suspicion is: Size does matter.
> So far I have used radii between 1 and 10 for the sphere, Lunex uses > 1000.

Your "Size does matter" comment got me thinking about adding a short 
article and image to my yuqk documentation. Initial versions of both 
attached; Perhaps of some help.

Bill P.

[Maetes] Re: Spherical Heightfields [414 days 7 hours and 9 minutes ago]

Wed, 26 Feb 2025 07:05:00 GMT

Hmmm... maybe I just see light at the end of a very long tunnel.

I picked out the most important lines from Lunex, cut them down to the bare
minimum, and now it seems to work.

One suspicion is: Size does matter.
So far I have used radii between 1 and 10 for the sphere, Lunex uses > 1000.

I'll continue to play around with it, it's far from perfect, but it looks better
than before, see picture.

Thanks again for the tips.

Martin

[Maetes] Re: Spherical Heightfields [414 days 11 hours and 24 minutes ago]

Wed, 26 Feb 2025 02:50:00 GMT

Sorry for the long response-time, was a "strange" week here in Germany.

Thanks for the answers so far, but still I dont get it.


>Do you get any messages about a max gradient and/or your isosurface may have
holes?

=> no, none.

> and yes, your contained by object needs to be large enough to hold the entire
displaced surface, else it will get clipped.

=> I tried with various diameters, with strange effects and new errors

> (just curious: try adding the sqrt() around the x y z parts and see if that
helps any)

=> no effect

>
https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/

=> hard stuff, but I will try to understand it.

> The moon... very good subject. Have you looked at LUNEX ?

=> Good tip, thanks for that. I didn't know it before, I played around a bit.
Maybe I can learn something from that, because the results look better and
error-free after the first tests.

I will set up a new test environment in the next days/weeks, try to incorporate
Lunex's approach there. Maybe I'll get ahead with it. I can't use Lunex
completely for my purposes, but maybe I can learn from it.

Martin

[William F Pokorny] Re: Making Patterns with functions [414 days 14 hours and 51 minutes ago]

Tue, 25 Feb 2025 23:22:52 GMT

On 2/25/25 06:34, Bald Eagle wrote:
> Super.  Maybe you can help me understand why I always have to go through a NEW
> form of calisthenics when I cross zero.
> (and as you can see, the pattern function is dirt simple)

If you are working with an equation you wish to use as a pattern, and 
the value of y, say, crossing through 0.0 flips or changes the 
function's behavior, one must deal with it in some way.

In your particular function there is a flip in behavior due internal 
value changes away from zero and another due y changing sign.

Below a yuqk fork scene showing some typical ways for dealing with value 
transitions causing unwanted change with your function based pattern. 
Some work with official POV-Ray releases too. To reproduce your result, 
however, we might need to do something pretty close to what you did! I 
didn't try to exactly match your posted result.

     // Sample scene. 'yuqk y_cross_0.pov +w1024 +h768 +p +mv3.8'
     global_settings { assumed_gamma 1.0 }
     #declare VarOrthoMult =
        20.0/max(image_width/image_height,image_height/image_width);
     #declare Camera01z = camera {
         orthographic
         location <0,0,-2>
         direction z
         right VarOrthoMult*x*max(1,image_width/image_height)
         up VarOrthoMult*y*max(1,image_height/image_width)
     }

     // 'odd()' is one of the fake keywords shipped with official
     // POV-Ray which the yuqk fork removed.
     #include "functions.inc"
     #include "munctions.inc"
     #local Dummy   = M_odd(0.5); // compiling F_odd()
     #local EvenOdd = M_odd(0);   // Later calls run F_odd internally
     #local EvenOdd = F_odd(2);   // = 0
     #local EvenOdd = F_odd(3);   // = 1

     #declare Formula1 = function { (y-sin(x))*(y-cos(x)) }

     // When y moving through zero flips results, it's typical to use
     // pattern value modifiers or similar inbuilt functions.

#if     (1)  // Call as FnY(0,y/2,0)
     #declare FnY = function {
         pattern { gradient y triangle_wave }
     }
#elseif (0)  // Call as FnY(0,y/4,0)
     #declare FnY = function {
         pattern { gradient y function_interval triangle_wave }
     }
#elseif (0)  // Call as FnY(0,y/2,0)
     #declare FnY = function {
         f_triangle_wave(y,0)
     }
#elseif (0)  // Call as FnY(0,y/4,0)
     #declare FnY = function {
         f_triangle_wave(y,1)
     }
#else
     #error "Must pick a definition of function Fny()\n"
#end

     #declare Formula2 = function {
         pattern {
             function { Formula1(x,y,z) }
             triangle_wave
             frequency 4
         }
     }
     #declare Formula3 = function { // Push y positive
         Formula1(x,
             select(
                 F_odd(f_round(y+100+0.5)),
                 0,
                 mod(y+100,1),
                 1-mod(y+100,1)),0)
     }
     #declare FnLine = function {
         select(((Formula2(x,y,z)>-0.1) & (Formula2(x,y,z)<0.1)),
             0, 0, 1)
     }

     plane { -z 0
         pigment {
           //function { Formula1(x,y,z) }
           //function { Formula1(x,FnY(0,y/2,0),z) }
           //function { Formula2(x,FnY(0,y/2,0),z) }
             function { FnLine(  x,FnY(0,y/2,0),z) }
           //function { Formula3(x,           y,z) }
           //raw_wave
             color_map {
                 [-2 rgb <1,0,0>]
                 [-0.01 rgb 0]
                 [+0.01 rgb 0]
                 [+2 rgb <0,1,0>]
             }
         }
         finish { emission 1 }
     }
     camera { Camera01z }

#if (0)
     union {
         sphere {<0, 0,0> , 0.1 }
         sphere {<0,+1,0> , 0.1 }
         sphere {<0,+2,0> , 0.1 }
         sphere {<0,-1,0> , 0.1 }
         sphere {<0,-2,0> , 0.1 }
         pigment { rgb <1,0,0>} finish { emission 1 }
     }
#end


Image attached.

Bill P.

[Bald Eagle] Re: Making Patterns with functions [415 days 2 hours and 34 minutes ago]

Tue, 25 Feb 2025 11:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/24/25 21:02, Bald Eagle wrote:
> > Was setting up a basic scene for a completely unrelated pattern, and came up
> > with this.
>
> I really like this one!
>
> Bill P.

Super.  Maybe you can help me understand why I always have to go through a NEW
form of calisthenics when I cross zero.
(and as you can see, the pattern function is dirt simple)


#version 3.8;
global_settings {assumed_gamma 1}
default {finish {diffuse 1}}
//#include "colors.inc"
#include "functions.inc"
#include "math.inc"
#declare E = 0.000001;

#declare Zoom = 20;
camera {
 orthographic
 location <0, 0, -50>
 right x*image_width/Zoom
 up y*image_height/Zoom
 look_at <0, 0, 0>
 rotate y*0
}

sky_sphere {pigment {rgb 1}}

light_source {<0, 0, -50> rgb 1}

#declare fmod = function (Value, Modulo) {select (Value, 1 - mod (abs (Value),
Modulo), mod (abs (Value), Modulo))}  // this gives a mod function that remains
consistant across the origin


#declare Formula1 = function {(y-sin(x))*(y-cos(x))}  // graphs 2 functions
simultaneously
#declare Formula2 = function {
 select (y,
 select (odd(floor(y/2)), 0, (fmod(y, 2)-sin(x))*(fmod(y, 2)-cos(x)), (fmod(y,
2)+sin(x))*(fmod(y, 2)+cos(x)) ),
 select (odd(floor(y/2)), 0, (fmod(y, 2)-1-sin(x))*(fmod(y, 2)-1-cos(x)),
(fmod(y, 2)-1+sin(x))*(fmod(y, 2)-1+cos(x)) ) // why?
 )
}


// debugging loop
#for (Y, -10, 10)
 #declare Value = odd(floor(Y/2));
 #declare Value2 = fmod(Y,2);
 #debug concat (" Y = ", str(Y, 0, 0),  "     Value = ", str(Value, 0, 0), "
Value2 = ", str(Value, 0, 0), "\n")

#end

#declare Formula = function {Formula2 (x, y, z)}

#declare RawPattern = pigment {function {Formula (x, y, z)}}

#declare Thickness = 0.1;

#declare LinePattern = pigment {function {select (abs (Formula (x, y, z)) -
Thickness, 0, 1)}}    // Once (<=1)
#declare LinePattern2 = pigment {function {select (abs (mod (Formula (x, y, z),
1)) - Thickness, 0, 1)}}




plane {z, 0 texture {pigment {LinePattern} finish {diffuse 1}} translate -z*0.1}

[William F Pokorny] Re: Making Patterns with functions [415 days 4 hours and 10 minutes ago]

Tue, 25 Feb 2025 10:03:17 GMT

On 2/24/25 21:02, Bald Eagle wrote:
> Was setting up a basic scene for a completely unrelated pattern, and came up
> with this.

I really like this one!

Bill P.

[Ilya Razmanov] Re: Making Patterns with functions [415 days 4 hours and 19 minutes ago]

Tue, 25 Feb 2025 09:54:19 GMT

On 25.02.2025 10:34, kurtz le pirate wrote:
> Just for a french reader, what PITA meens ?

Pain in the ass.

-- 
Ilyich the Toad
https://dnyarri.github.io/

[kurtz le pirate] Re: Making Patterns with functions [415 days 6 hours and 40 minutes ago]

Tue, 25 Feb 2025 07:34:01 GMT

On 25/02/2025 03:02, Bald Eagle wrote:
> Was setting up a basic scene for a completely unrelated pattern, and came up
> with this.
> 
> Trying to consistently get functions to behave consistently across N=0 is a
> giant PITA in POV-Ray, when I don't think it ought to be.


Really impressive patterns. What a good job.
Just for a french reader, what PITA meens ?



-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Making Patterns with functions [415 days 12 hours and 9 minutes ago]

Tue, 25 Feb 2025 02:05:00 GMT

Was setting up a basic scene for a completely unrelated pattern, and came up
with this.

Trying to consistently get functions to behave consistently across N=0 is a
giant PITA in POV-Ray, when I don't think it ought to be.


- BW

[kurtz le pirate] Re: Spherical Heightfields [421 days 22 hours and 10 minutes ago]

Tue, 18 Feb 2025 16:03:52 GMT

On 18/02/2025 13:25, Maetes wrote:
> I'm currently trying my hand at spherical heightfields, but I'm running into
> strange problems.
> I put a height map (DEM) of the moon around a sphere, based on these forum
> posts:
>
https://news.povray.org/povray.binaries.images/thread/%3C38a2dc5b%40news.povray.org%3E
>
https://news.povray.org/povray.text.scene-files/thread/%3C38A037EB.504C1A6%40inapg.inra.fr%3E/?ttop=444549&toff=750
> 
> Everything looks good in the global view, but when I zoom in closer, radial
> errors appear at the day-night boundary.
> A higher resolution of the DEM does not change anything, and it works fine when
> using bump_map.
> But the larger the sphere (contained_by), the finer the disturbances?!
> 
> Unfortunately, I have no idea what the functions in the script do.
> This one in particular puzzles me:
> x*x+y*y+z*z + 0.1 - hftext(x,y,z).y * 0.03
> 
> Can someone help me with that?
> Is there a reasonable tutorial that explains the working of user-defined
> functions well?
> Or does anyone find the bug in the script that causes the glitches?
> 

The moon... very good subject. Have you looked at LUNEX ?
Lots of examples and code :

<https://www.phpsciencelabs.com/lunex-for-pov-ray/>




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Spherical Heightfields [421 days 23 hours and 14 minutes ago]

Tue, 18 Feb 2025 15:00:00 GMT

"Maetes" <nomail@nomail> wrote:

> Unfortunately, I have no idea what the functions in the script do.
> This one in particular puzzles me:
> x*x+y*y+z*z + 0.1 - hftext(x,y,z).y * 0.03
>
> Can someone help me with that?
> Is there a reasonable tutorial that explains the working of user-defined
> functions well?
> Or does anyone find the bug in the script that causes the glitches?

Do you get any messages about a max gradient and/or your isosurface may have
holes?

x*x+y*y+z*z + 0.1 - hftext(x,y,z).y * 0.03

So, the standard equation for a sphere is sqrt (x*x + y*y + z*z) - Radius = 0
What you're doing with the above equation is using the elevation of the
heightfield to modify the radius at any given point on the sphere.

and yes, your contained by object needs to be large enough to hold the entire
displaced surface, else it will get clipped.

(just curious: try adding the sqrt() around the x y z parts and see if that
helps any)


> My code used, greatly simplified:
>
>  #declare hftext = function {
>   pigment {
>    image_map {
>     png "moon_dem.png"
>     map_type 1
>    }
>   }
>  }
>  #local mResult = isosurface {
>   function {
>    x*x+y*y+z*z + 0.1 -
>    hftext(x,y,z).y * 0.03
>   }
>   contained_by {
>    sphere {0,1}
>   }
>   max_gradient 10
>   threshold 0.95
>   //threshold 2
>   texture {
>     pigment {
>      color rgb <0.3, 0.3, 0.3>
>     }
>   }
>  }
>
> Thanks,
> Martin

Also look at:

https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/


- BE

[Maetes] Spherical Heightfields [422 days 1 hour and 44 minutes ago]

Tue, 18 Feb 2025 12:30:00 GMT

I'm currently trying my hand at spherical heightfields, but I'm running into
strange problems.
I put a height map (DEM) of the moon around a sphere, based on these forum
posts:
https://news.povray.org/povray.binaries.images/thread/%3C38a2dc5b%40news.povray.org%3E
https://news.povray.org/povray.text.scene-files/thread/%3C38A037EB.504C1A6%40inapg.inra.fr%3E/?ttop=444549&toff=750

Everything looks good in the global view, but when I zoom in closer, radial
errors appear at the day-night boundary.
A higher resolution of the DEM does not change anything, and it works fine when
using bump_map.
But the larger the sphere (contained_by), the finer the disturbances?!

Unfortunately, I have no idea what the functions in the script do.
This one in particular puzzles me:
x*x+y*y+z*z + 0.1 - hftext(x,y,z).y * 0.03

Can someone help me with that?
Is there a reasonable tutorial that explains the working of user-defined
functions well?
Or does anyone find the bug in the script that causes the glitches?

doesnt helps me to understand the stuff:
https://www.povray.org/documentation/view/3.6.2/231/


My code used, greatly simplified:

 #declare hftext = function {
  pigment {
   image_map {
    png "moon_dem.png"
    map_type 1
   }
  }
 }
 #local mResult = isosurface {
  function {
   x*x+y*y+z*z + 0.1 -
   hftext(x,y,z).y * 0.03
  }
  contained_by {
   sphere {0,1}
  }
  max_gradient 10
  threshold 0.95
  //threshold 2
  texture {
    pigment {
     color rgb <0.3, 0.3, 0.3>
    }
  }
 }

Thanks,
Martin

[Thomas] Re: Photon mapping calculation limited to 8 thre... [422 days 14 hours and 44 minutes ago]

Mon, 17 Feb 2025 23:30:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> So, you have one light and 8 target objects, or 2 lights and 4 target
> objects, or 4 lights and 2 target objects or 8 lights and 1 target object.
>
> The maximum number of threads used while photon mapping is the product
> of the number of light_source by the number of objects with a target block.
> To the best of my knowledge : Currently, it is not possible to divide
> that process between several threads. The algorithm used is strictly
> linear and can't get split between multiple threads.

Makes sense, thanks for clarifying.

However, POV-Ray 3.7 seems to log this incorrectly. With 16 CPU cores, 1 light
source and 3 target objects, I can clearly see 300% CPU usage during photon
mapping (so 3 cores are used), however, 19 threads instead of 3 threads are
logged.

Render Time:
  Photon Time:      0 hours  2 minutes 53 seconds (173.948 seconds)
              using 19 thread(s) with 456.834 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours 11 minutes 12 seconds (672.855 seconds)
              using 16 thread(s) with 10100.757 CPU-seconds total


Regards,
Thomas.

[Tor Olav Kristensen] Re: Using vectors in functions [422 days 14 hours and 54 minutes ago]

Mon, 17 Feb 2025 23:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I was going to spend some time converting some cool Shadertoy code into SDL,
> and I was annoyed (as usual) that I couldn't do certain things.
> I specifically wanted to create a function that performed a rotational matrix
> transform on a vector given a variable angle.
>
> Well, the function VM doesn't allow transform functions to take user-defined
> arguments ("parameter names").
> And we all "know" that you can't use vectors in functions.
> Hell you can't even use vector dot-notation in functions.
>
> 2.2.1.6.4 Declaring User-Defined Vector Functions
> Right now you may only declare vector functions using one of the special
> function types. Supported types are transform and spline functions. For example:
>
>  #declare foo = function {
>    transform {
>      rotate <90, 0, 0>
>      scale 4
>    }
>  }
>
>  #declare myvector = foo(4, 3, 7);
>
>  #declare foo2 = function {
>    spline {
>      linear_spline
>      0.0, <0,0,0>
>      0.5, <1,0,0>
>      1.0, <0,0,0>
>    }
>  }
>
>  #declare myvector2 = foo2(0.7);
>
> Function splines take the vector size into account. That is, a function
> containing a spline with five components will also return a five component
> vector (aka a color), a function containing a spline with two components will
> only return a two component vector and so on.
>
> Note: the number of parameters of special function types is determined
> automatically, so you do not need to specify parameter names.
>
>
> But, me being ME, that got a few things wiggling up in the ole' brain, and I
> started to follow a few tenuous ides.
> Round and round I went in circles, trying to make vector functions work, and
> trying to bridge the gap between the SDL parser and the function VM.
>
> And I have mostly done that as you'll see in the attached file.
>
> The only thing that would make this FULLY functional would be to find a way to
> shoehorn the actual vector into an argument allowable by some sort of special
> function syntax.
>
> But I hope that this inspires people to start playing around with the functions,
> macros, reading the docs, exploring the various include files in the
> distribution, and doing some experiments that reveal things that we can do (but
> were told we couldn't).

Hi Bill

I once did some work on something similar. See this thread:

From: Tor Olav Kristensen
Subject: Visualizing vector fields with a single isosurface
Date: 2010-01-30 08:35:01
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4b6434d658c2698ed6291f840%40news.povray.org%3E/

Here's my (not so good) try at an explanation of what is going on:

In this isosurface, a grid of rounded boxes are created with a function.
And each of the x, y and z arguments to this function are processed by
other functions that does inverse transformations to them. I.e.: For each
points (x, y, z) in space these "preprosessing functions" calculates a
transform to apply to the x, y, z values that are fed to the function
that creates the the grid of rounded boxes.

Also have a look at how the function created by the RotateXYZ_Function()
macro is used in these SDL files:

https://dataduppedings.no/subcube/POV-Ray/Isosurface-Rotated_Noise.txt
https://dataduppedings.no/subcube/POV-Ray/Isosurface-Cubic_Space_Division.txt

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

[Bald Eagle] Using vectors in functions [422 days 18 hours and 39 minutes ago]

Mon, 17 Feb 2025 19:35:00 GMT

So, I was going to spend some time converting some cool Shadertoy code into SDL,
and I was annoyed (as usual) that I couldn't do certain things.
I specifically wanted to create a function that performed a rotational matrix
transform on a vector given a variable angle.

Well, the function VM doesn't allow transform functions to take user-defined
arguments ("parameter names").
And we all "know" that you can't use vectors in functions.
Hell you can't even use vector dot-notation in functions.

2.2.1.6.4 Declaring User-Defined Vector Functions
Right now you may only declare vector functions using one of the special
function types. Supported types are transform and spline functions. For example:

 #declare foo = function {
   transform {
     rotate <90, 0, 0>
     scale 4
   }
 }

 #declare myvector = foo(4, 3, 7);

 #declare foo2 = function {
   spline {
     linear_spline
     0.0, <0,0,0>
     0.5, <1,0,0>
     1.0, <0,0,0>
   }
 }

 #declare myvector2 = foo2(0.7);

Function splines take the vector size into account. That is, a function
containing a spline with five components will also return a five component
vector (aka a color), a function containing a spline with two components will
only return a two component vector and so on.

Note: the number of parameters of special function types is determined
automatically, so you do not need to specify parameter names.


But, me being ME, that got a few things wiggling up in the ole' brain, and I
started to follow a few tenuous ides.
Round and round I went in circles, trying to make vector functions work, and
trying to bridge the gap between the SDL parser and the function VM.

And I have mostly done that as you'll see in the attached file.

The only thing that would make this FULLY functional would be to find a way to
shoehorn the actual vector into an argument allowable by some sort of special
function syntax.

But I hope that this inspires people to start playing around with the functions,
macros, reading the docs, exploring the various include files in the
distribution, and doing some experiments that reveal things that we can do (but
were told we couldn't).

- Bill "Bald Eagle" Walker

[Francois LE COAT] Re: Optical Inertia [436 days 22 hours and 14 minutes ago]

Mon, 3 Feb 2025 16:00:01 GMT

Hi,

Francois LE COAT writes:
> Monocular Depth :
> 
> <https://www.youtube.com/watch?v=34zUDqEzHos>
> 
> A drone flies between the trees of a forest. Thanks to the optical-flow

> measured on successive images, the temporal disparity reveals the
> forest of trees... We take a reference image, the optical-flow is
> measured on two rectified images. Then we change the reference when
> the inter-correlation drops below 60%. We can perceive the relief in
> depth with a single camera, over time.
> 
> In fact, when we watch images captured by a drone, although there is
> only one camera, we often see the relief. This is particularly marked
> for trees in a forest. The goal here is to evaluate this relief, with a

> measurement of "optical-flow", which allows one image to be matched wit
h
> another, when they seem to be close (we say they are "correlated").
> 
> We have two eyes, and the methods for measuring visible relief by 
> stereoscopy are very developed. Since the beginning of photography,
> there were devices like the â€œstereoscopeâ€ which
allows 
you to see the
> relief with two pictures, naturally. It is possible to measure relief,
> thanks to epipolar geometry, and well-known mathematics. There are many

> measurement methods, very effective and based on human vision.
> 
> When it comes to measuring relief with a single camera, knowledge is
> less established. There are 3D cameras, called "RGBD" with a "D" for 
> "depth". But how do they work? Is it possible to improve those? What
> I am showing here does not require the use of any â€œartificial n
eural
> networkâ€. It is a physical measurement, with a classic algorith
m,
> which does not come from A.I. nor a big computer :-)

A WEB page was made to illustrate Monocular Depth...

<https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/monocular_
depth.html>

This is about measuring monocular depth, just as stereoscopic disparity
is measured. It means quantifying the depth, with images from a single
camera. We can see this relief naturally, but it is a matter of
measuring it with the optical-flow :-)

Best regards,

-- 
FranÃ§ois LE COAT
<https://eureka.atari.org/>

[Leroy] Re: Smooth, continuous Bezier splines (again) [438 days 18 hours and 24 minutes ago]

Sat, 1 Feb 2025 19:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've got a diagram of where measured points should be along a CURVE that
> describes the profile of a solid edge.

 I came late to this, After I reading all the other inputs, I thought I'd throw
my two cents in. I wrote a win program a long time ago to make prisms and
polygons for POV. PolPrm.exe it's at http://leroyw.byethost15.com with the rest
of my window program I wrote for POV.

I wrote in mainly so I could switch the between different types of prisms and
polygons as needed. It started as a simple project with limited options and a
small working area. After using for it awhile I started adding things to make
life easier. I put in a few predefined shapes, set it so I could dump the data
into an array file, and a bunch of little things.
 The last time I upgraded, it started because someone in this forum wanted to
know how to make a circle out of a prism. I'd like to have that in PolPrm. So
after figuring out how to make the circle, I went on a building spree. I add
more curve shapes, made it where can split a shape in two, combine two shapes
into one,and finally made the long over due undo function. I swore that this was
the last upgrade.
 When I saw your shape I said 'that would fit nicely in PolPrm'. You see PolPrm
still has a small working area 2*2 pov units square. Then reading all the
messages it seamed that what you wanted is the math or a least the conversation
went that way. But I went ahead and put a shape similar to yours in PolPrm and
play around with it. That's when I realize PolPrm wasn't really made for
precision. It make custom shapes very well.
 Another thing I learned after reading all this forum messages is that the real
reason I wrote PolPrm is that I didn't want to the math every time  I made a
prism.

Have Fun!

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [440 days 15 hours and 39 minutes ago]

Thu, 30 Jan 2025 22:35:00 GMT

That approach was also close to what I was doing, however it doesn't match the
curvature of the spline segments at the endpoints.

Visually, it still looked too flat-then rounded-then flat-then rounded....

Although I didn't pore over your code yet, I quickly skimmed it to see where the
control points were calculated, and then bolted on my curvature comb code to
visualize the curvature over all of the spline segments.

You can see where the mismatches are.

So I still think I have to degree elevate and then I can mirror the additional
control points to get the curvature to match.

(Also, FYI: the point/tip is actually a hard point.  So 2 separate composite
splines - 1 on the left and 1 on the right)

I'll see if I have enough time to patch in my degree elevation code and extend
the control-point mirroring that one extra "level" into the splines.

- BW

[ingo] Re: Smooth, continuous Bezier splines (again) [440 days 23 hours and 4 minutes ago]

Thu, 30 Jan 2025 15:10:00 GMT

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

>
> "What does Fn_RabbitHole () do?  I can't find it in the docs . . ."

Dig. Dig deeper.

Yes, SDL is slow when one cannot use functions. This is why I implemented the
meshmakermacros and the curves in Nim, but have not married them.

https://gist.github.com/ingoogni/490d2d50710bab4fe5e689714e9ef287

for mesh it is easy, generate and use, for splines it realy depends on the use,

ingo

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [440 days 23 hours and 44 minutes ago]

Thu, 30 Jan 2025 14:30:00 GMT

"ingo" <nomail@nomail> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > Rabbit hole...
>
> good place to hord obscure POV-Ray include files ;)
>
> ingo

"What does Fn_RabbitHole () do?  I can't find it in the docs . . ."

[ingo] Re: Smooth, continuous Bezier splines (again) [440 days 23 hours and 59 minutes ago]

Thu, 30 Jan 2025 14:15:00 GMT

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

> Rabbit hole...

good place to hord obscure POV-Ray include files ;)

ingo

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [441 days and 4 minutes ago]

Thu, 30 Jan 2025 14:10:00 GMT

"ingo" <nomail@nomail> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:

> > The question too is whether some of this 'spline stuff' better fits in
> > spline{} like SDL feature -

> interpolate{} always seemed a more fitting keyword to me, even dough I didn't
> use it in my curves.inc ( https://ingoogni.nl/download/Curve.zip )

Well - I'm of two minds on this.
1. Yes, I suppose that formally, all of this would conceptually best be grouped
into the spline {} portions of the code.

however:

2. Using a spline in a user-defined SDL function would kill speed, would it not?
(I can also envision that if <x, y, z> were able to be plugged into splines at
render time, someone, somewhere would come up with some amazing thing to do with
that.)

However gets it done faster, or at all, is fine with me.

(This topic also suggests that looking into making array elements available to
functions might be something to look at as well.  After all, if splines can be
used in functions, why can't arrays be used - assuming that the element is of a
type able to be processed by a function {} )

[William F Pokorny] Re: Smooth, continuous Bezier splines (again) [441 days 1 hour and 15 minutes ago]

Thu, 30 Jan 2025 12:58:30 GMT

On 1/30/25 01:07, ingo wrote:
> interpolate{} always seemed a more fitting keyword to me, even dough I didn't
> use it in my curves.inc (https://ingoogni.nl/download/Curve.zip )

Thanks for the reminder - should be useful. I see, for example, you have 
the quadratic bezier. When I checked I had a copy of your latest 
Curve.zip already stored locally in my Ingo directory.

Some of what you have in there does look more like interpolation within 
the constraints of a curve segment's form. I'll have to play those end 
point velocity control settings.

Rabbit hole...

Bill P.

[ingo] Re: Smooth, continuous Bezier splines (again) [441 days 8 hours and 4 minutes ago]

Thu, 30 Jan 2025 06:10:00 GMT

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

> The question too is whether some of this 'spline stuff' better fits in
> spline{} like SDL feature -

ABX has added several splines / curves in the past to MegaPov, Akima, x_spline,
TCB (Kochanek/Bartels), SOR spline and maybe even circle spline based on Ron
Parker's torus spline include file.

interpolate{} always seemed a more fitting keyword to me, even dough I didn't
use it in my curves.inc ( https://ingoogni.nl/download/Curve.zip )

ingo

[Tor Olav Kristensen] Re: Smooth, continuous Bezier splines (again) [441 days 14 hours and 4 minutes ago]

Thu, 30 Jan 2025 00:10:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>...
> You have probably noticed that I have only provided a 2D solution, with all the
> points within a XY-plane.
>
> Now, if you like a little extra challenge, you can rewrite the code so that it
> can provide a full 3D solution.

That is actually not a simple challenge: There are difficult decisions to
be made if 3 of the given points lies on a line.

A simpler challenge is to change the code so that your endpoints are joined
smoothly too.

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

[Tor Olav Kristensen] Re: Smooth, continuous Bezier splines (again) [441 days 16 hours and 44 minutes ago]

Wed, 29 Jan 2025 21:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > The code below shows the results of what I think Ingo suggested.
>
> Thank you.  I thought this would grab your attention - however I was hoping to
> get some free time to do something with it before you submitted the solution!
> :D
> Too late.  You win.
>
> I'll take a look when I get home in an hour.

  ;)

Ingo is guilty too..

You are aware that you do not HAVE to look at my code, or?

You have probably noticed that I have only provided a 2D solution, with all the
points within a XY-plane.

Now, if you like a little extra challenge, you can rewrite the code so that it
can provide a full 3D solution.

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

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [441 days 17 hours and 24 minutes ago]

Wed, 29 Jan 2025 20:50:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> The code below shows the results of what I think Ingo suggested.

Thank you.  I thought this would grab your attention - however I was hoping to
get some free time to do something with it before you submitted the solution!
:D
Too late.  You win.

I'll take a look when I get home in an hour.

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [441 days 17 hours and 44 minutes ago]

Wed, 29 Jan 2025 20:30:00 GMT

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

> I've grabbed code over time for some 2D functions I planned to call
> f_bezier_2d_quartic() and f_bezier_2d_quintic().
>
> Do you have - or know of - 3D code for either of these?
>
> Or for a 3D quadratic?

Maybe I'm misunderstanding, but:
They're not dimensional - they're parametric.
Take any N-D point and the spline just interpolates ALL of the dimensions with
the same equations.
Right?

[William F Pokorny] Re: Smooth, continuous Bezier splines (again) [441 days 18 hours and 11 minutes ago]

Wed, 29 Jan 2025 20:02:39 GMT

On 1/29/25 13:27, Tor Olav Kristensen wrote:
>> Perhaps time to add an inbuilt f_bezier_cubic() to yuqk too.
ðŸ™‚
> Yes, that would be nice.
> 
> Then comes the question if adding f_bezier_quadratic() and f_bezier_quartic()
> also is a good idea.
> 
> And then if the various derivative functions of them should be added...

I've grabbed code over time for some 2D functions I planned to call 
f_bezier_2d_quartic() and f_bezier_2d_quintic().

Do you have - or know of - 3D code for either of these?

Or for a 3D quadratic?  I might have the quadratic 3D form in my notes 
notes somewhere or in my TCL wrapper script (where I'd coded up some 
simpler spline by segment types maybe 15 years ago). I wonder if 
quadratic that useful excepting having better performance?

FYI. As yuqk inbuilt functions the convenient versions (packed vectors) 
for 3D forms would be limited to a -10 to +10 box and single float 
accuracy rather than double for the any 2D forms.

As for the derivative forms, if you have code in hand, maybe we do a few 
  near term? I don't have anything ready to go.

The question too is whether some of this 'spline stuff' better fits in 
spline{} like SDL feature - one supporting the Bezier segment control 
point forms. We can describe many segment curves, function wrap, but 
what we can do dynamically from the render time VM is limited.

Aside: Jerome coded up a bunch of spline extensions in his hgpovray38 
fork (which 'maybe' came from megapov?). I don't recall any additional 
Bezier support, but my memory is not great these days.

Bill P.

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [441 days 18 hours and 54 minutes ago]

Wed, 29 Jan 2025 19:20:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:

> > Perhaps time to add an inbuilt f_bezier_cubic() to yuqk too. :-)
>
> Yes, that would be nice.
>
> Then comes the question if adding f_bezier_quadratic() and f_bezier_quartic()
> also is a good idea.
>
> And then if the various derivative functions of them should be added...

I thought there was already some kind of Bezier spline function - but maybe not
as a proper function.  We have that spline in prism {}.  Unless we consider
user-defined spline functions "good enough".

Might it not be "easier", more useful, and more general to have a single
Bezier/Bernstein function that takes the number of control points as an
argument, and can just assemble the spline on the fly? Then you wouldn't need
multiple functions.

And aren't the derivatives just other Bezier splines?

I'm just thinking that if it was done that way, people could really begin to
harness the power of these splines without having to ascend the steep learning
curve.

Also having a feature where the user could just switch over to a linear spline
would allow looping through the control points - perhaps to draw out the control
points and polygon - without having to write another whole block of code to do
so.

Degree elevation and reduction would be super sweet to have as well.

And, if you want, I can provide the curvature functions - which are useful for
designing function-driven textures, examining how splines fit together, etc.

Big rabbit hole to go down, but IMHO, in 2025, a computer graphics program
really ought to have an entire in-built Bezier spline library.

- BW

[Tor Olav Kristensen] Re: Smooth, continuous Bezier splines (again) [441 days 19 hours and 44 minutes ago]

Wed, 29 Jan 2025 18:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/29/25 10:51, Tor Olav Kristensen wrote:
> > #macro CubicBezierFn(c0, c1, c2, c3)
> >
> >      function(s) {
> >          0
> >          + pow(1 - s, 3)*c0
> >          + 3*pow(1 - s, 2)*s*c1
> >          + 3*(1 - s)*pow(s, 2)*c2
> >          + pow(s, 3)*c3
> >      }
> >
> > #end // macro CubicBezierFn
>
> Perhaps time to add an inbuilt f_bezier_cubic() to yuqk too. :-)

Yes, that would be nice.

Then comes the question if adding f_bezier_quadratic() and f_bezier_quartic()
also is a good idea.

And then if the various derivative functions of them should be added...

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

[William F Pokorny] Re: Smooth, continuous Bezier splines (again) [441 days 20 hours and 39 minutes ago]

Wed, 29 Jan 2025 17:34:11 GMT

On 1/29/25 10:51, Tor Olav Kristensen wrote:
> #macro CubicBezierFn(c0, c1, c2, c3)
> 
>      function(s) {
>          0
>          + pow(1 - s, 3)*c0
>          + 3*pow(1 - s, 2)*s*c1
>          + 3*(1 - s)*pow(s, 2)*c2
>          + pow(s, 3)*c3
>      }
> 
> #end // macro CubicBezierFn

Perhaps time to add an inbuilt f_bezier_cubic() to yuqk too. :-)

Bill P.

[Tor Olav Kristensen] Re: Smooth, continuous Bezier splines (again) [441 days 22 hours and 19 minutes ago]

Wed, 29 Jan 2025 15:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
> > The bisect of the angles in the current lines are the normals to the handles in
> > that point. The handles should be equally long to get C1/G1 (?) continuity.
> >
> > I think, without testing,
>
> Yes, excellent idea.
>...

Hi Bill

The code below shows the results of what I think Ingo suggested.

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


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

#include "colors.inc"

default {
    texture {
        pigment { color White }
        finish {
            diffuse 0
            emission color White
        }
    }
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#macro CubicBezierFn(c0, c1, c2, c3)

    function(s) {
        0
        + pow(1 - s, 3)*c0
        + 3*pow(1 - s, 2)*s*c1
        + 3*(1 - s)*pow(s, 2)*c2
        + pow(s, 3)*c3
    }

#end // macro CubicBezierFn


#macro Plot(FnX, FnY, FnZ, NoOfSegments, Radius)

    #local dS = 1/NoOfSegments;

    union {
        #local S0 = 0;
        #local p0 = <FnX(S0), FnY(S0), FnZ(S0)>;
        // sphere { p0, Radius }
        #for (I, 0, NoOfSegments - 2)
            #local S1 = S0 + dS;
            #local p1 = <FnX(S1), FnY(S1), FnZ(S1)>;
            cylinder { p0, p1, Radius }
            sphere { p1, Radius }
            #local S0 = S1;
            #local p0 = p1;
        #end // for
        #local S1 = S0 + dS;
        #local p1 = <FnX(S1), FnY(S1), FnZ(S1)>;
        cylinder { p0, p1, Radius }
        // sphere { p1, Radius }
    }

#end // macro Plot

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare Debug = false;


#declare NoOfPoints = 9;
#declare Points =
    array[NoOfPoints] {
        <-0.297/2, -1.000, 0.000>,
        <-0.203/2, -0.500, 0.000>,
        <-0.115/2, -0.250, 0.000>,
        <-0.069/2, -0.125, 0.000>,
        < 0.000/2,  0.000, 0.000>
        <+0.069/2, -0.125, 0.000>,
        <+0.115/2, -0.250, 0.000>,
        <+0.203/2, -0.500, 0.000>,
        <+0.297/2, -1.000, 0.000>,
    }
;

#declare R = 0.006;

#if (true)
    union {
        #for (I, 0, NoOfPoints - 1)
            sphere { Points[I], R }
        #end // for
        pigment { color White }
    }
#end // if


#declare NoOfOrthogonalVectors = NoOfPoints - 1;
#declare OrthogonalVectors = array[NoOfOrthogonalVectors];
#for (I, 0, NoOfOrthogonalVectors - 1)
    #declare OrthogonalVectors[I] = vnormalize(vcross(Points[I+1] - Points[I],
z));
#end // for

#if (Debug)
    union {
        #for (I, 0, NoOfOrthogonalVectors - 1)
            cylinder {
                0*z, OrthogonalVectors[I], R/4
                translate (Points[I] + Points[I+1])/2
            }
        #end // for
        pigment { color Red }
    }
#end // if


#declare NoOfBisectingVectors = NoOfPoints;
#declare BisectingVectors = array[NoOfBisectingVectors];
#declare BisectingVectors[0] = OrthogonalVectors[0];
#for (I, 1, NoOfBisectingVectors - 2)
    #declare BisectingVectors[I] = vnormalize(OrthogonalVectors[I-1] +
OrthogonalVectors[I]);
#end // for
#declare BisectingVectors[NoOfBisectingVectors-1] =
OrthogonalVectors[NoOfOrthogonalVectors-1];

#if (Debug)
    union {
        #for (I, 0, NoOfBisectingVectors - 1)
            cylinder {
                0*z, BisectingVectors[I], R/4
                translate Points[I]
            }
        #end // for
        pigment { color Magenta }
    }
#end // if


#declare NoOfTangentVectors = NoOfBisectingVectors;
#declare TangentLengths =
    array[NoOfTangentVectors] {
        0.10,
        0.10,
        0.08,
        0.04,
        0.01,
        0.04,
        0.08,
        0.10,
        0.10
    }
;
#declare TangentVectors = array[NoOfTangentVectors];
#for (I, 0, NoOfTangentVectors - 1)
    #declare TangentVectors[I] = TangentLengths[I]*vcross(+z,
BisectingVectors[I]);
#end // for

#if (Debug)
    union {
        #for (I, 0, NoOfTangentVectors - 1)
            cylinder {
                0*z, +TangentVectors[I], R/4
                translate Points[I]
            }
            cylinder {
                0*z, -TangentVectors[I], R/4
                translate Points[I]
            }
        #end // for
        pigment { color Blue }
    }
#end // if


#declare NoOfSegments = 16;
#for (I, 0, NoOfPoints - 2)
    #declare pA = Points[I  ];
    #declare pB = Points[I  ] + TangentVectors[I  ];
    #declare pC = Points[I+1] - TangentVectors[I+1];
    #declare pD = Points[I+1];
    #if (Debug)
        union {
            // sphere { pA, R }
            sphere { pB, R }
            sphere { pC, R }
            // sphere { pD, R }
            pigment { color Blue }
        }
    #end // if
    object {
        Plot(
            CubicBezierFn(pA.x, pB.x, pC.x, pD.x),
            CubicBezierFn(pA.y, pB.y, pC.y, pD.y),
            CubicBezierFn(pA.z, pB.z, pC.z, pD.z),
            NoOfSegments,
            R/4
        )
        pigment { color Black }
        translate -1.0*z
    }
#end // for

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

background { color Gray40 }

#declare AR = image_width/image_height;

camera {
    orthographic
    location < 0.0, -0.5, -2.0>
    right AR*x
    up y
    direction z
    angle 30
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [442 days 17 hours and 19 minutes ago]

Tue, 28 Jan 2025 20:55:00 GMT

> but then I need to figure out how to solve for sets of control point coordinates
> that give me matching curvatures.

.. . . and this must be just the thing:

https://ntrs.nasa.gov/api/citations/19900012238/downloads/19900012238.pdf

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [442 days 17 hours and 49 minutes ago]

Tue, 28 Jan 2025 20:25:00 GMT

Putting this link here for reference.

https://pomax.github.io/bezierinfo/#curvature

Holy 70-page comprehensive review article! :O

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [442 days 18 hours and 54 minutes ago]

Tue, 28 Jan 2025 19:20:00 GMT

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

> There are still "bumps", so I think I still need to somehow account for the
> varying curvature along the splines.

So, I guess what I'm going to have to do is work out the first and second
derivatives of the Bernstein polynomials and calculate the curvature K (okay, I
already know how to do this, and have done it, and have code)

K = (x' y'' - x'' y') / (x' x' + y' y') ^ (3/2)

but then I need to figure out how to solve for sets of control point coordinates
that give me matching curvatures.

The task of fairing these curves to match "smoothly" is a conceptually
straightforward thing - hammering out the details of how to do that appears to
be a bit more mathematically involved than most would first imagine.

- BW

[Bald Eagle] Re: Smooth, continuous Bezier splines (again) [442 days 19 hours and 29 minutes ago]

Tue, 28 Jan 2025 18:45:00 GMT

"ingo" <nomail@nomail> wrote:
> The bisect of the angles in the current lines are the normals to the handles in
> that point. The handles should be equally long to get C1/G1 (?) continuity.
>
> I think, without testing,

Yes, excellent idea.

I was futzing around with something along those lines yesterday, but I'm stuck
doing it in M$ Office 365 Copilot web version - which is painful enough - but I
was working on it piecemeal, so I only had so much time in one stretch to focus.

At present, I take 3 control points, bisect the angle, find the perpendicular
slope (negative reciprocal), use the equation of that line to sub in 1/3 of the
shorter vector, and solve for the control point y-values on either side of the
endpoint.

I have the Bezier splines charted using the Bernstein polynomials, and
concatenated together using "helper cells".

There are still "bumps", so I think I still need to somehow account for the
varying curvature along the splines.

[ingo] Re: Smooth, continuous Bezier splines (again) [443 days 7 hours and 49 minutes ago]

Tue, 28 Jan 2025 06:25:00 GMT

The bisect of the angles in the current lines are the normals to the handles in
that point. The handles should be equally long to get C1/G1 (?) continuity.

I think, without testing,

ingo

[Bald Eagle] Smooth, continuous Bezier splines (again) [443 days 18 hours and 19 minutes ago]

Mon, 27 Jan 2025 19:55:00 GMT

I've got a diagram of where measured points should be along a CURVE that
describes the profile of a solid edge.

You can see from the diagram, that a linear connection of the points would give
me a shape where the measured dimension points would be at the vertices of
concave angles, and so the appropriately shaped object {} would touch the lines
rather than the dimension points.

What I'd like to do is use those dimension points as the endpoints of Bezier
splines, such that the resulting curve was smooth and continuous.

I feel like, after all of the Bezier spline research that I've done, that I
really _ought_ to be able to just do this off the top of my head; however,
although I can make a continuous spline that's "smooth" and intersects the
dimension points, I don't get an "adequately" smooth curve - it has "wiggles".

This leads me to believe that either need to degree elevate the spline in order
to match the _curvature_ of the segments

OR

I need to degree reduce the cubic splines to quadratic splines so that I only
have a single intermediate control point.

I tried to quickly test that out by just making the 2 internal control points
the same, however since the control points to either side of the endpoints need
to be colinear with the control point, and preferably offset by a vector of the
same magnitude, that's a problem when the spline segments are different lengths.

So I'm leaning toward degree elevation.
But that seems like it would open things up to even MORE wiggle, and I have no
idea at the moment how to calculate the position of that extra control point.

I'm just stuck trying to figure out / remember how to calculate the positions of
the internal control points.

- BE

[Bald Eagle] Re: Making Patterns with functions [470 days 21 hours and 14 minutes ago]

Tue, 31 Dec 2024 17:00:00 GMT

I was trying to track down something completely unrelated, and came across this
page:

National Curve Bank
A Collection of Famous Plane Curves
created in POVRAY (Persistence Of Vision RAY tracing)

https://old.nationalcurvebank.org/povray/povray.htm

[Francois LE COAT] Re: Optical Inertia [472 days 21 hours and 13 minutes ago]

Sun, 29 Dec 2024 17:00:58 GMT

Hi,

Monocular Depth :

<https://www.youtube.com/watch?v=34zUDqEzHos>

A drone flies between the trees of a forest. Thanks to the optical-flow
measured on successive images, the temporal disparity reveals the
forest of trees... We take a reference image, the optical-flow is
measured on two rectified images. Then we change the reference when
the inter-correlation drops below 60%. We can perceive the relief in
depth with a single camera, over time.

In fact, when we watch images captured by a drone, although there is
only one camera, we often see the relief. This is particularly marked
for trees in a forest. The goal here is to evaluate this relief, with a
measurement of "optical-flow", which allows one image to be matched with
another, when they seem to be close (we say they are "correlated").

We have two eyes, and the methods for measuring visible relief by 
stereoscopy are very developed. Since the beginning of photography,
there were devices like the â€œstereoscopeâ€ which
allows yo
u to see the
relief with two pictures, naturally. It is possible to measure relief,
thanks to epipolar geometry, and well-known mathematics. There are many
measurement methods, very effective and based on human vision.

When it comes to measuring relief with a single camera, knowledge is
less established. There are 3D cameras, called "RGBD" with a "D" for 
"depth". But how do they work? Is it possible to improve those? What
I am showing here does not require the use of any â€œartificial neu
ral
networkâ€. It is a physical measurement, with a classic algorithm,

which does not come from A.I. nor a big computer :-)

Best regards,

-- 
FranÃ§ois LE COAT
<https://eureka.atari.org/>

[MichaelJF] Re: Condition in functions [482 days 21 hours and 33 minutes ago]

Thu, 19 Dec 2024 16:40:16 GMT

Am 19.12.2024 um 17:00 schrieb kurtz le pirate:
> On 17/12/2024 12:16, Bald Eagle wrote:
>>
>> Have you simply tried adding "open" to your isosurface block, so you 
>> don't see
>> the containing sphere?
>>
>>
> 
> I also tried it. It fixes the problem.
> 
> I've never seen/used this option, which is still not very clear to me :(
> 
> 
> 
> 
> 
> 
As I understand it, all points below the threshold value of the 
isosurface are considered as inside the surface and all above as 
outside. All points on the surface of the containing box or sphere of an 
isosurface considered as part of the interior of the isosurface are 
closed. The open keyword removes this coating.

This explains the behavior here. But I my be wrong again.

Best regards
Michael

[kurtz le pirate] Re: Condition in functions [482 days 22 hours and 14 minutes ago]

Thu, 19 Dec 2024 16:00:02 GMT

On 17/12/2024 12:16, Bald Eagle wrote:
> 
> Have you simply tried adding "open" to your isosurface block, so you don't see
> the containing sphere?
> 
> 

I also tried it. It fixes the problem.

I've never seen/used this option, which is still not very clear to me :(






-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Condition in functions [484 days 16 hours and 59 minutes ago]

Tue, 17 Dec 2024 21:15:00 GMT

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

> In a way, you have to look at the
> surface from the "inside" of the object.

Sorta.
I think it has more to do with the extent of the visible surface:

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

"When the isosurface is not fully contained within the contained_by object,
there will be a cross section. When this happens, you will see the surface of
the container. Using the open keyword, these cross section surfaces are removed,
and the inside of the isosurface becomes visible."

[MichaelJF] Re: Condition in functions [484 days 23 hours and 39 minutes ago]

Tue, 17 Dec 2024 14:34:10 GMT

Am 17.12.2024 um 12:16 schrieb Bald Eagle:
> MichaelJF <fri### [at] t-onlinede> wrote:
> 
>>      contained_by { sphere { 0,L-0.1 } }
> 
> Have you simply tried adding "open" to your isosurface block, so you don't see
> the containing sphere?
> 
> 
Thanks, that solves the riddle. In a way, you have to look at the 
surface from the "inside" of the object. I can't remember ever having 
consciously used this option.

[Bald Eagle] Re: Condition in functions [485 days 2 hours and 54 minutes ago]

Tue, 17 Dec 2024 11:20:00 GMT

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

>     contained_by { sphere { 0,L-0.1 } }

Have you simply tried adding "open" to your isosurface block, so you don't see
the containing sphere?

[MichaelJF] Re: Condition in functions [485 days 9 hours and 48 minutes ago]

Tue, 17 Dec 2024 04:25:47 GMT

Am 16.12.2024 um 23:36 schrieb Bald Eagle:
> MichaelJF <fri### [at] t-onlinede> wrote:
> 
> Hmmm.   It looks like maybe it's a sign issue?
> Inside and outside are switched?
> 
> Try just negating the function and see what happens.
> 
> I'm not sure if that might have to do with the left-handed coordinate system, or
> what.
> 
> - BW
> 
> 
Sorry, I mixed up the image yesterday. Here is the corrected version. 
It's even worse. Yesterday is was one of my tests to solve the riddle, 
in which I had commented out the exponential term as a test:

#declare GyroidLatice_1 = function (x,y,z) {
    select(isoCondition(x,y,z),Iso2(x,y,z),1) - //exp(isoCondition(x,y,z)/5)
}

The actual version depicts the full expression without the comment.

The difference between the functions Iso2 and Iso3 is just a change of 
signs and in GyroidLatice_1 the exponential term is subtracted whereas 
in GyroidLatice_2 it is added.

Below you can find the POV-part of the code with the MathMod-Code within 
the comments. Maybe someone else can spot the difference. The parameter 
t from MathMod is not used in this examnple.

Best regards
Michael

#declare L=23/2;
#declare c=1/10000;
#declare Th1=5/10;
#declare Th2=-8/10;


/* isoCondition=(x^N+y^N+z^N-(L-1/10)^N)  (N=2)*/
#declare isoCondition = function(x,y,z) { x*x+y*y+z*z-(L-1/10)*(L-1/10) }

/* Iso =
    cos(x)*sin(y)+cos(y)*sin(z)+cos(z)*sin(x) */
#declare Iso = function(x,y,z) {
    cos(x)*sin(y)+cos(y)*sin(z)+cos(z)*sin(x)
}


/* DFx=((Iso(x+c,y,z,t)-Iso(x,y,z,t))/c)
    DFy=((Iso(x,y+c,z,t)-Iso(x,y,z,t))/c)
    DFz=((Iso(x,y,z+c,t)-Iso(x,y,z,t))/c) */
#declare DFx = function(x,y,z) { (Iso(x+c,y,z)-Iso(x,y,z))/c }
#declare DFy = function(x,y,z) { (Iso(x,y+c,z)-Iso(x,y,z))/c }
#declare DFz = function(x,y,z) { (Iso(x,y,z+c)-Iso(x,y,z))/c }

/* Rapp=(x/sqrt(x*x+y*y+z*z)) */
#declare Rapp = function(x,y,z) {x/sqrt(x*x+y*y+z*z) }

/* "Iso2 =
    Iso(x+Th2*Rapp(DFx(x,y,z,t),DFy(x,y,z,t),DFz(x,y,z,t),t),
        y+Th2*Rapp(DFy(x,y,z,t),DFz(x,y,z,t),DFx(x,y,z,t),t),
        z+Th2*Rapp(DFz(x,y,z,t),DFx(x,y,z,t),DFy(x,y,z,t),t),t)
    ) */
#declare Iso2 = function(x,y,z) {
    Iso(x+Th2*Rapp(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
        y+Th2*Rapp(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
        z+Th2*Rapp(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z))
    )
}

/* Iso3 =
    Iso(x-Th2*Rapp(DFx(x,y,z,t),DFy(x,y,z,t),DFz(x,y,z,t),t),
        y-Th2*Rapp(DFy(x,y,z,t),DFz(x,y,z,t),DFx(x,y,z,t),t),
        z-Th2*Rapp(DFz(x,y,z,t),DFx(x,y,z,t),DFy(x,y,z,t),t),t)
    )*/
#declare Iso3 = function(x,y,z) {
    Iso(x-Th2*Rapp(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
        y-Th2*Rapp(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
        z-Th2*Rapp(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z))
    )
}

/* Iso4 =
    Iso(x+Th1*Rapp(DFx(x,y,z,t),DFy(x,y,z,t),DFz(x,y,z,t),t),
        y+Th1*Rapp(DFy(x,y,z,t),DFz(x,y,z,t),DFx(x,y,z,t),t),
        z+Th1*Rapp(DFz(x,y,z,t),DFx(x,y,z,t),DFy(x,y,z,t),t),t)
    ) */
#declare Iso4 = function(x,y,z) {
    Iso(x+Th1*Rapp(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
        y+Th1*Rapp(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
        z+Th1*Rapp(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z))
    )
}

/* Iso5 =
    Iso(x-Th1*Rapp(DFx(x,y,z,t),DFy(x,y,z,t),DFz(x,y,z,t),t),
        y-Th1*Rapp(DFy(x,y,z,t),DFz(x,y,z,t),DFx(x,y,z,t),t),
        z-Th1*Rapp(DFz(x,y,z,t),DFx(x,y,z,t),DFy(x,y,z,t),t),t)
    )*/
#declare Iso5 = function(x,y,z) {
    Iso(x-Th1*Rapp(DFx(x,y,z),DFy(x,y,z),DFz(x,y,z)),
        y-Th1*Rapp(DFy(x,y,z),DFz(x,y,z),DFx(x,y,z)),
        z-Th1*Rapp(DFz(x,y,z),DFx(x,y,z),DFy(x,y,z))
    )
}

/* ThickIso2=(Iso4(x,y,z,t)*Iso5(x,y,z,t)) */
#declare ThickIso2 = function(x,y,z) { Iso4(x,y,z) * Iso5(x,y,z) }


/* 
GyroidLatice_1=if(isoCondition(x,y,z,t)<(0),Iso2(x,y,z,t),1)-exp(isoCondition(x,y,z,t)/5)

*/

#declare GyroidLatice_1 = function (x,y,z) {
    select(isoCondition(x,y,z),Iso2(x,y,z),1) - exp(isoCondition(x,y,z)/5)
}

/* 
GyroidLatice_2=if(isoCondition(x,y,z,t)<(0),Iso3(x,y,z,t),1)+exp(isoCondition(x,y,z,t)/5)

*/
#declare GyroidLatice_2 = function (x,y,z) {
    select(isoCondition(x,y,z),Iso3(x,y,z),1) + exp(isoCondition(x,y,z)/5)
}

/* 
GyroidLatice_3=if(isoCondition(x,y,z,t)<(0),ThickIso2(x,y,z,t),1)+exp(isoCondition(x,y,z,t)/5)

*/
#declare GyroidLatice_3 = function (x,y,z) {
    select(isoCondition(x,y,z),ThickIso2(x,y,z),1) + 
exp(isoCondition(x,y,z)/5)
}

#declare G1 = isosurface {
    function {
       GyroidLatice_1(x,y,z)
    }
    contained_by { sphere { 0,L-0.1} }
    threshold 0
    max_gradient 1000

    pigment { colour Yellow }
}

#declare G2 = isosurface {
    function {
       GyroidLatice_2(x,y,z)
    }
    contained_by { sphere { 0,L-0.1 } }
    threshold 0
    max_gradient 1000

    pigment { colour Orange }
}

#declare G3 = isosurface {
    function {
       GyroidLatice_3(x,y,z)
    }
    contained_by { sphere { 0,L-0.1 } }
    threshold 0
    max_gradient 1000

    pigment { colour Red }
}

[Bald Eagle] Re: Condition in functions [485 days 15 hours and 34 minutes ago]

Mon, 16 Dec 2024 22:40:00 GMT

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

Hmmm.   It looks like maybe it's a sign issue?
Inside and outside are switched?

Try just negating the function and see what happens.

I'm not sure if that might have to do with the left-handed coordinate system, or
what.

- BW

[MichaelJF] Re: Condition in functions [485 days 22 hours and 3 minutes ago]

Mon, 16 Dec 2024 16:10:57 GMT

Am 08.12.2024 um 17:25 schrieb kurtz le pirate:

> 
> I also have problems with PrettyBall_1. 3 isosurfaces. Two are ok. The 
> third really doesn't match. Yet the code is/looks ok.
> 
> 
Indeed, this is actually a very strange difference between POV and 
MathMod. In the top row are the three objects as isosurfaces in POV, 
below are the objects exported from MathMod with the same formulae. The 
second and third objects match quite well, while the first one is 
completely different. I cannot judge whether the error is in POV or in 
MathMod.

If you compare the two objects on the right and in the centre in the 
bottom row (MathMod), you may get the impression that the one on the 
right could be created from the middle one as a point reflection at the 
origin (scale <-1,-1,-1>) and in fact both are largely congruent after 
this operation. You will get the correct result with POV if you create 
the first object from the centre one with the mentioned scaling or 
change the definition of GyroidLatice_1 as follows:

#declare GyroidLatice_1 = function {
    select(isoCondition(x,y,z),Iso3(-x,-y,-z),1) + 
exp(isoCondition(x,y,z)/5)
//   select(isoCondition(x,y,z),Iso2(x,y,z),1)// - 
exp(isoCondition(x,y,z)/5)
}


Best regards
Michael

[jr] Re: Condition in functions [492 days 9 hours and 19 minutes ago]

Tue, 10 Dec 2024 04:55:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> ...
> I put an image of the result in p.b.i.
> I can ost functions if someone is interested.

the vase looks pretty cool.  the functions as such would not be much use to me,
I guess, but how about creating a macro ?  perhaps with options to supply one's
own material and for scaling (making the vase taller/shorter, slimmer/more
bulge), and such ?

regards, jr.

[kurtz le pirate] Re: Condition in functions [492 days 22 hours and 21 minutes ago]

Mon, 9 Dec 2024 15:52:49 GMT

Following Tor's advice, I corrected my 'select()'.

I've also put the 't' parameter back into the functions. I mistakenly 
thought that this parameter was only used for animation and morphing. 
This is not the case at all.


I put an image of the result in p.b.i.


I can ost functions if someone is interested.



-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Condition in functions [493 days 21 hours and 48 minutes ago]

Sun, 8 Dec 2024 16:25:16 GMT

On 07/12/2024 19:54, Tor Olav Kristensen wrote:

> Hi Kurtz
> 
> That's an interesting project.
> 
> I found some MathMod documentation here:
>
https://fossies.org/linux/mathmod/documentation/index.html#SupportedOperatorsFunctions

Hi Tor,

I also found the doc in the MathMod package.


> 
> ...
> ...
> ...
> 
> One of its mathematical functions:
> 
> if(A, B, C)
> if A differs from 0, the return value of this function is B, else C
> 
> 
> In POV-Ray 0 = 0.0, so I have removed the all the int() calls in the
> expressions above.
> 
>  From this documentation I understand that any value equal to 0 is treated
> as a logical False and any other numerical value is treated as logical True.
> (I think this convention makes expressions harder to understand, so I will
> not use it further in my simplified expressions, even if POV-Ray also uses it.
> Writing readable expressions is more important than writing compact
> expressions.)
> 
Yes, indeed, difficult to understand.
MathMod's language is, on certain points, obscure ... at least for me.

I also have problems with PrettyBall_1. 3 isosurfaces. Two are ok. The 
third really doesn't match. Yet the code is/looks ok.



> To make it easier to get an overview, I rename the MathMod functions in your
> post, remove their parameter lists and arguments, insert some white space
> and finally simplify them a bit.
> 
> isoTransform_2(): IT2()
> isoTransform_6(): IT6()
> CarvinCondition(): CC()
> ThickIsoExterior(): TIE()
> ThickIso2(): TI2()
> Iso6(): I6()
> 
> 
> IT2() =
>      if(
>          CC() = 0,
>          TIE(),
>          1
>      )
> 
> IT2() =
>      if(
>          CC(),
>          1,
>          TIE()
>      )
> 
> IT6() =
>      if(
>          CC() & (TIE() < 0),
>          -TI2()*I6()*I6(),
>          1
>      )
> 
> IT6() =
>      if(
>          TIE() < 0,
>          if(
>              CC(),
>              -TI2()*I6()*I6(),
>              1
>          ),
>          1
>      )
> 
> The nested ifs above has the same effect as the & operator.
> 
> Now a rewrite to POV-Ray expressions is not so difficult:
> 
> IT2():
>      select(
>          CC(),
>          1,
>          TIE(),
>          1
>      )
> 
> IT6():
>      select(
>          TIE(),
>          select(
>              CC(),
>              -TI2()*I6()*I6(),
>              1,
>              -TI2()*I6()*I6()
>          ),
>          1
>      )
> 
> The nested selects above has the same effect as the & operator.
> 
> Now you can fill in the parameter lists, the arguments, give back functions
> their original names and give them a proper POV-Ray function syntax.
> 

Ingenious approach. I'm going to look into it very closely.




Thanks+



-- 
kurtz le pirate
compagnie de la banquise

[Tor Olav Kristensen] Re: Condition in functions [494 days 19 hours and 19 minutes ago]

Sat, 7 Dec 2024 18:55:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
> This exemple come from MathMod, "Vase_3 by Abderrahman Taha 31/10/2019"
>
> Several isosurfaces and functions including these two :
>
> isoTransform_2 =
> if(CarvinCondition(x,y,z,t)=(0),ThickIsoExterior(x,y,z,t),1)"
>
>
isoTransform_6=if(CarvinCondition(x,y,z,t)&ThickIsoExterior(x,y,z,t)<(0),-ThickIso2((6*x),(6*y),(6*z),t)*Iso6((x*6),(
y*6),(z*6),-1)
> *(Iso6((x*6),(y*6),(z*6),1)),1)"
>
> CarvinCondition, ThickIsoExterior, ThickIso2, Iso6 are others functions.
>
>
>
> The (my) transcription for POV gives :
>
> #declare isoTransform_2 = function(x,y,z,T) {
>    select (
>   // A (condition)
>     CarvinCondition(x,y,z,T),
>   // B : A < 0
>      ThickIsoExterior(x,y,z,T),
>     // C : A = 0
>     1,
>     // D : A > 0
>      ThickIsoExterior(x,y,z,T)
>      )
>     }
>
> #declare isoTransform_6 = function(x,y,z,T) {
>  select (
>   // A (condition)
>   (CarvinCondition(x,y,z,T) & ThickIsoExterior(x,y,z,T)),
>   // B : A <0
>   -ThickIso2((6*x),(6*y),(6*z),T) * Iso6((x*6),(y*6),(z*6),-1) *
> (Iso6((x*6),(y*6),(z*6),1)),
>   // C : A >= 0
>     1
>     )
>    }
>
>
> Do you agree with the use of select() to replace if() ?
> I'm struggling a bit and I would like to check this option already.
>
>
>
> On the left is MathMod, on the right where I am.
>...

Hi Kurtz

That's an interesting project.

I found some MathMod documentation here:
https://fossies.org/linux/mathmod/documentation/index.html#SupportedOperatorsFunctions

Some of its mathematical operators in order of precedence:

! A
unary logical not (result is 1 if A is 0, else 0)

A = B    A < B    A <= B    A != B    A > B    A >= B
comparison between A and B (result is either 0 or 1)

A & B
result is 1 if A and B differ from 0, else 0

A | B
result is 1 if A or B differ from 0, else 0

One of its mathematical functions:

if(A, B, C)
if A differs from 0, the return value of this function is B, else C

In POV-Ray 0 = 0.0, so I have removed the all the int() calls in the
expressions above.

From this documentation I understand that any value equal to 0 is treated
as a logical False and any other numerical value is treated as logical True.
(I think this convention makes expressions harder to understand, so I will
not use it further in my simplified expressions, even if POV-Ray also uses it.
Writing readable expressions is more important than writing compact
expressions.)

To make it easier to get an overview, I rename the MathMod functions in your
post, remove their parameter lists and arguments, insert some white space
and finally simplify them a bit.

isoTransform_2(): IT2()
isoTransform_6(): IT6()
CarvinCondition(): CC()
ThickIsoExterior(): TIE()
ThickIso2(): TI2()
Iso6(): I6()

IT2() =
    if(
        CC() = 0,
        TIE(),
        1
    )

IT2() =
    if(
        CC(),
        1,
        TIE()
    )

IT6() =
    if(
        CC() & (TIE() < 0),
        -TI2()*I6()*I6(),
        1
    )

IT6() =
    if(
        TIE() < 0,
        if(
            CC(),
            -TI2()*I6()*I6(),
            1
        ),
        1
    )

The nested ifs above has the same effect as the & operator.

Now a rewrite to POV-Ray expressions is not so difficult:

IT2():
    select(
        CC(),
        1,
        TIE(),
        1
    )

IT6():
    select(
        TIE(),
        select(
            CC(),
            -TI2()*I6()*I6(),
            1,
            -TI2()*I6()*I6()
        ),
        1
    )

The nested selects above has the same effect as the & operator.

Now you can fill in the parameter lists, the arguments, give back functions
their original names and give them a proper POV-Ray function syntax.

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

[Bald Eagle] Re: Condition in functions [495 days 17 hours and 49 minutes ago]

Fri, 6 Dec 2024 20:25:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> select() is
> >> pretty much the only option.

> > Well, I don't think that's entirely true.

What I meant is that select() is not the ONLY option.

It will be a while before I can check and confirm, but I think that one can
embed conditional statements into a function such as (Theta < pi/2) which will
be evaluated to true (1) or false (0).

Plus all of the other methods I referred to.

- BW

[Alain Martel] Re: Condition in functions [495 days 18 hours and 39 minutes ago]

Fri, 6 Dec 2024 19:34:59 GMT

Le 2024-12-06 Ã  13:44, Bald Eagle a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
> 
>> As if() can't be used in the function of an isosurface, select() is
>> pretty much the only option.
> 
> Well, I don't think that's entirely true.
> 
> If you take advantage of the fact that expressions inside of parentheses get
> evaluated, and make use of functions like sgn, min, max, etc, then you can
> multiply terms in an equation by values that select them (multiply by 1 or -1)
> or cancel them out (multiply by 0).
> 
> So if you wanted to alternate signs, you could use a sine wave and take the sign
> of that:  sgn(sin(N))
> 
> - BW
> 

According to what I remember from a discussion here a while back :
The if() is normally evaluated at parse time. That makes it unsuitable 
to be used in an isosurface that need to evaluate it at render time.

[Bald Eagle] Re: Condition in functions [495 days 19 hours and 29 minutes ago]

Fri, 6 Dec 2024 18:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> As if() can't be used in the function of an isosurface, select() is
> pretty much the only option.

Well, I don't think that's entirely true.

If you take advantage of the fact that expressions inside of parentheses get
evaluated, and make use of functions like sgn, min, max, etc, then you can
multiply terms in an equation by values that select them (multiply by 1 or -1)
or cancel them out (multiply by 0).

So if you wanted to alternate signs, you could use a sine wave and take the sign
of that:  sgn(sin(N))

- BW

[Alain Martel] Re: Condition in functions [496 days and 35 minutes ago]

Fri, 6 Dec 2024 13:38:22 GMT

Le 2024-12-06 Ã  06:15, kurtz le pirate a Ã©critÂ :
> 
> 
> Do you agree with the use of select() to replace if() ?
> I'm struggling a bit and I would like to check this option already.

As if() can't be used in the function of an isosurface, select() is 
pretty much the only option.

> 
> 
> 
> On the left is MathMod, on the right where I am.
> I'm trying to figure out why the â€œlacesâ€ are
missing.
> 
> 
> 
> 
> 
> Thanks
> 
> 
>

[Bald Eagle] Re: Condition in functions [496 days 2 hours and 9 minutes ago]

Fri, 6 Dec 2024 12:05:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> This exemple come from MathMod, "Vase_3 by Abderrahman Taha 31/10/2019"

Nice.  There have been a lot of MathMod shapes that I'd like to replicate in
POV-Ray.

> Do you agree with the use of select() to replace if() ?
Yes - there are few other options to do that, if any.

> On the left is MathMod, on the right where I am.
> I'm trying to figure out why the “laces” are missing.

No time for me to investigate this in detail right now but:

Isosurfaces of complex things can be tricky - especially if you're trying to use
certain "forms" of equations.

First thing is to check messages and see what the gradient is.

Then I'd try to take the abs () of the equation and subtract a tiny amount to
see if anything shows up.

Then I might see if subtracting the equation from the r (x,y,z) function gets
you anywhere.

- BW

[kurtz le pirate] Condition in functions [496 days 2 hours and 58 minutes ago]

Fri, 6 Dec 2024 11:15:08 GMT

Hello,

This exemple come from MathMod, "Vase_3 by Abderrahman Taha 31/10/2019"

Several isosurfaces and functions including these two :

isoTransform_2 = 
if(CarvinCondition(x,y,z,t)=(0),ThickIsoExterior(x,y,z,t),1)"

isoTransform_6=if(CarvinCondition(x,y,z,t)&ThickIsoExterior(x,y,z,t)<(0),-ThickIso2((6*x),(6*y),(6*z),t)*Iso6((x*6),(y*6),(z*6),-1)

*(Iso6((x*6),(y*6),(z*6),1)),1)"

CarvinCondition, ThickIsoExterior, ThickIso2, Iso6 are others functions.



The (my) transcription for POV gives :

#declare isoTransform_2 = function(x,y,z,T) {
  	select (
		// A (condition)
  		CarvinCondition(x,y,z,T),
		// B : A < 0
   		ThickIsoExterior(x,y,z,T),
  		// C : A = 0
  		1,
  		// D : A > 0
   		ThickIsoExterior(x,y,z,T)
   		)
   	}

#declare isoTransform_6 = function(x,y,z,T) {
	select (
		// A (condition)
		(CarvinCondition(x,y,z,T) & ThickIsoExterior(x,y,z,T)),
		// B : A <0
		-ThickIso2((6*x),(6*y),(6*z),T) * Iso6((x*6),(y*6),(z*6),-1) * 
(Iso6((x*6),(y*6),(z*6),1)),
		// C : A >= 0
  		1
  		)
  	}


Do you agree with the use of select() to replace if() ?
I'm struggling a bit and I would like to check this option already.



On the left is MathMod, on the right where I am.
I'm trying to figure out why the â€œlacesâ€ are
missing.





Thanks



-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Making Patterns with functions [497 days 15 hours and 39 minutes ago]

Wed, 4 Dec 2024 22:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Finally had a moment of clarity, and figured out a fish-scale pattern that I
> wanted to make.

And here's a modification to make it less semi-circular.

[Bald Eagle] Re: Making Patterns with functions [497 days 15 hours and 44 minutes ago]

Wed, 4 Dec 2024 22:30:00 GMT

Finally had a moment of clarity, and figured out a fish-scale pattern that I
wanted to make.

[Francois LE COAT] Re: Optical Inertia [510 days 22 hours and 58 minutes ago]

Thu, 21 Nov 2024 15:15:42 GMT

Hi,

Here is another result...

> Bald Eagle writes:
>> Even if I were to simply use a POV-Ray scene, where I rendered two ima
ges with
>> different camera locations - then I'm assuming that I could calculate 
a vector
>> field and a projection matrix. (something simple like cubes, spheres, 
and cylinders)
>>
>> Given The projection matrix and one of the two renders, would I then h
ave the
>> necessary and sufficient information to write a .pov scene to recreate
 the
>> render from scratch?
>>
>> - BW
> 
> For the moment, the work with depth from monocular vision is not enough

> advanced that we can recreate the visible scene. Vision with two camera
s
> or more, gives a much advanced result for 3D reconstruction of scenes.
> 
> Let remind us the starting point from this thread... We've redone the
> experiment from Hernan Badino, who is walking with a camera on his head
:
> 
>      <https://www.youtube.com/watch?v=MmFJwGVwJG8>
> 
> Hernan determines his 2D ego-motion in the x-y plane, from correspondin
g
> interest points that persist in the video stream. That means he is
> calculating the projection matrix of the movement to deduce translation
s
> in the ground plane. With time integration, it gives him the trajectory
.
> 
> We're doing almost the same, but I work with OpenCV's optical-flow, and

> not interest points. And my motion model is 3D, to obtain 8 parameters
> in rotation and translation, that I can use in Persistence Of Vision.
> 
> I hope you're understanding... I'm reconstituting the 3D movement, and 
I
> discover it's giving "temporal disparity", that is depth from motion.

An instrumented motorcycle rolls on the track of a speed circuit. Thanks
to the approximation of optical flow (DIS - OpenCV) by the dominant
projective movement, we determine translations on the ground plane,
roll and yaw. That is to say the trajectory by projective parameters
(Tx,Tz,Ry,Rz).

<https://www.youtube.com/watch?v=-QLJ2ke9mN8>

Image data comes from the publication:

Bastien Vincke, Pauline Michel, Abdelhafid El Ouardi, Bruno Larnaudie,
Flavien Delgehier, Rabah Sadoun, Samir Bouaziz, Stéphane Espié, Sergi
o
Rodriguez, Abderrahmane Boubezoul. (Dec. 2024). Real Track Experiment
Dataset for Motorcycle Rider Behavior and Trajectory Reconstruction.
Data in Brief, Vol. 57, 111026.

The instrumented motorcycle makes a complete lap of the track. The
correlation threshold is set at 90% between successive images, to
reset the calculation of the projective dynamic model.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Francois LE COAT] Re: Optical Inertia [533 days 22 hours and 57 minutes ago]

Tue, 29 Oct 2024 15:16:58 GMT

Hi,

Bald Eagle writes:
> Even if I were to simply use a POV-Ray scene, where I rendered two imag
es with
> different camera locations - then I'm assuming that I could calculate a
 vector
> field and a projection matrix. (something simple like cubes, spheres, a
nd
> cylinders)
> 
> Given The projection matrix and one of the two renders, would I then ha
ve the
> necessary and sufficient information to write a .pov scene to recreate 
the
> render from scratch?
> 
> - BW

For the moment, the work with depth from monocular vision is not enough
advanced that we can recreate the visible scene. Vision with two cameras
or more, gives a much advanced result for 3D reconstruction of scenes.

Let's remind us the starting point from this thread... We've redone the
experiment from Hernan Badino, who is walking with a camera on his head:

	<https://www.youtube.com/watch?v=GeVJMamDFXE>

Hernan determines his 2D ego-motion in the x-y plane, from corresponding
interest points that persist in the video stream. That means he is
calculating the projection matrix of the movement to deduce translations
in the ground plane. With time integration, it gives him the trajectory.

We're doing almost the same, but I work with OpenCV's optical-flow, and
not interest points. And my motion model is 3D, to obtain 8 parameters
in rotation and translation, that I can use in Persistence Of Vision.

I hope you're understanding... I'm reconstituting the 3D movement, and I
discover it's giving "temporal disparity", that is depth from motion.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Optical Inertia [544 days 2 hours and 4 minutes ago]

Sat, 19 Oct 2024 12:10:00 GMT

Francois LE COAT <lec### [at] atariorg> wrote:

> I have the first reference image, and the second one, from which I
> determine the optical-flow. That means every pixel integer displacement
> between an image, to the other. That gives a vector field that can
> be approximated by a global projective transformation. That means eight
> parameters in rotation and translation, that match the two images the
> best. The quality of the images' matching is measured with correlation,
> between the first image and the second (projectively) transformed.

So, you have this vector field that - sort of maps the pixels in the second
frame to the pixels in the first frame.
And then somehow the projection matrix is calculated from that.

> Disparity field which is an integer displacement between images, is
> linked to depth in the image (3rd dimension) with an inverse relation
> (depth=base/disparity). That means we can evaluate image's depth from
> a continuous video stream.

Presumably when an object gets closer, the image gets "scaled up" in the frame,
and you use that to calculate the distance of the object from the camera.

> > I'm also wondering if you could create a 3D rendering with the data you
> 're
> > extracting, and maybe a 2D orthographic overhead map of the scene that
> the
> > drones are flying through, mapping the position of the drones in the fo
> rest.

> All is not so perfect, that we can imagine what
> you're wishing, from the state of the art...

Well, I'm just thinking that you must have an approximate idea of where each
tree is, given that you calculate a projection matrix and know something about
the depth.  So I was just wondering if, given that information, you could simply
place a cylinder of the approximate diameter and at the right depth.

> It's a long work since I can show some promising results. Now I'm
> happy to share it with a larger audience. Unfortunately all the
> good people that worked with me, are not here to appreciate. That's
> why I'm surprised with your interest =)

Well, I have been interested in the fundamentals of photogrammetry for quite
some time.  And I have been following your work for the last several years,
hoping to learn how to create such projection matrices and apply them.

https://news.povray.org/povray.advanced-users/thread/%3C5be592ea%241%40news.povray.org%3E/

I don't work in academia or the graphics industry, so I only have what free time
that I can devote to independently learning this stuff on my own.

Even if I were to simply use a POV-Ray scene, where I rendered two images with
different camera locations - then I'm assuming that I could calculate a vector
field and a projection matrix. (something simple like cubes, spheres, and
cylinders)

Given The projection matrix and one of the two renders, would I then have the
necessary and sufficient information to write a .pov scene to recreate the
render from scratch?

- BW

[Francois LE COAT] Re: Optical Inertia [544 days 13 hours and 53 minutes ago]

Sat, 19 Oct 2024 00:20:12 GMT

Hi,

Bald Eagle writes:
> Francois LE COAT wrote:
>> I have the first reference image, and the second one, from which I
>> determine the optical-flow. That means every pixel integer displacemen
t
>> between an image, to the other. That gives a vector field that can
>> be approximated by a global projective transformation. That means eigh
t
>> parameters in rotation and translation, that match the two images the
>> best. The quality of the images' matching is measured with correlation
,
>> between the first image and the second (projectively) transformed.
> 
> So, you have this vector field that - sort of maps the pixels in the se
cond
> frame to the pixels in the first frame.
> And then somehow the projection matrix is calculated from that.
> 
>> Disparity field which is an integer displacement between images, is
>> linked to depth in the image (3rd dimension) with an inverse relation
>> (depth=base/disparity). That means we can evaluate image's depth fro
m
>> a continuous video stream.
> 
> Presumably when an object gets closer, the image gets "scaled up" in th
e frame,
> and you use that to calculate the distance of the object from the camer
a.
> 
>>> I'm also wondering if you could create a 3D rendering with the data y
ou're
>>> extracting, and maybe a 2D orthographic overhead map of the scene tha
t the
>>> drones are flying through, mapping the position of the drones in the 
forest.
> 
>> All is not so perfect, that we can imagine what
>> you're wishing, from the state of the art...
> 
> Well, I'm just thinking that you must have an approximate idea of where
 each
> tree is, given that you calculate a projection matrix and know somethin
g about
> the depth.  So I was just wondering if, given that information, you cou
ld simply
> place a cylinder of the approximate diameter and at the right depth.
> 
>> It's a long work since I can show some promising results. Now I'm
>> happy to share it with a larger audience. Unfortunately all the
>> good people that worked with me, are not here to appreciate. That's
>> why I'm surprised with your interest =)
> 
> Well, I have been interested in the fundamentals of photogrammetry for 
quite
> some time.  And I have been following your work for the last several ye
ars,
> hoping to learn how to create such projection matrices and apply them.
> 
> https://news.povray.org/povray.advanced-users/thread/%3C5be592ea%241%40
news.povray.org%3E/
> 
> I don't work in academia or the graphics industry, so I only have what 
free time
> that I can devote to independently learning this stuff on my own.
> 
> Even if I were to simply use a POV-Ray scene, where I rendered two imag
es with
> different camera locations - then I'm assuming that I could calculate a
 vector
> field and a projection matrix. (something simple like cubes, spheres, a
nd
> cylinders)
> 
> Given The projection matrix and one of the two renders, would I then ha
ve the
> necessary and sufficient information to write a .pov scene to recreate 
the
> render from scratch?
> 
> - BW

I understand your question. The problem is I'm far from reconstituting
a 3D scene from the monocular information I have at the moment. I know
a company which is doing this sort of application, called Stereolabs...

	<https://www.stereolabs.com/>

I'm far from their perfect 3D acquisition process. And it is obtained
with two cameras. I only have one camera, and a video stream that I
didn't acquired myself. Is there an interest, and applications? I'm
not at this step in my work.

I know that similar monocular image processing have been used on planet
Mars, because the helicopter only had one piloting camera, for weight
and embedding reasons.

The main goal at this point of the work, is to show that we could
eventually do the same job, using many cameras, or with only one.
But I'm far from obtaining a similar result, as elaborated systems,
like with Stereolabs camera ZED, for instance.

That is already being done perfectly with a stereoscopic system...

Do you understand? Thanks for your attention.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Optical Inertia [544 days 16 hours and 29 minutes ago]

Fri, 18 Oct 2024 21:45:00 GMT

Francois LE COAT <lec### [at] atariorg> wrote:

> I have the first reference image, and the second one, from which I
> determine the optical-flow. That means every pixel integer displacement
> between an image, to the other. That gives a vector field that can
> be approximated by a global projective transformation. That means eight
> parameters in rotation and translation, that match the two images the
> best. The quality of the images' matching is measured with correlation,
> between the first image and the second (projectively) transformed.

So, you have this vector field that - sort of maps the pixels in the second
frame to the pixels in the first frame.
And then somehow the projection matrix is calculated from that.

> Disparity field which is an integer displacement between images, is
> linked to depth in the image (3rd dimension) with an inverse relation
> (depth=base/disparity). That means we can evaluate image's depth from
> a continuous video stream.

Presumably when an object gets closer, the image gets "scaled up" in the frame,
and you use that to calculate the distance of the object from the camera.

> > I'm also wondering if you could create a 3D rendering with the data you
> 're
> > extracting, and maybe a 2D orthographic overhead map of the scene that
> the
> > drones are flying through, mapping the position of the drones in the fo
> rest.

> All is not so perfect, that we can imagine what
> you're wishing, from the state of the art...

Well, I'm just thinking that you must have an approximate idea of where each
tree is, given that you calculate a projection matrix and know something about
the depth.  So I was just wondering if, given that information, you could simply
place a cylinder of the approximate diameter and at the right depth.

> It's a long work since I can show some promising results. Now I'm
> happy to share it with a larger audience. Unfortunately all the
> good people that worked with me, are not here to appreciate. That's
> why I'm surprised with your interest =)

Well, I have been interested in the fundamentals of photogrammetry for quite
some time.  And I have been following your work for the last several years,
hoping to learn how to create such projection matrices and apply them.

https://news.povray.org/povray.advanced-users/thread/%3C5be592ea%241%40news.povray.org%3E/

I don't work in academia or the graphics industry, so I only have what free time
that I can devote to independently learning this stuff on my own.

Even if I were to simply use a POV-Ray scene, where I rendered two images with
different camera locations - then I'm assuming that I could calculate a vector
field and a projection matrix. (something simple like cubes, spheres, and
cylinders)

Given The projection matrix and one of the two renders, would I then have the
necessary and sufficient information to write a .pov scene to recreate the
render from scratch?

- BW

[Francois LE COAT] Re: Optical Inertia [544 days 17 hours and 58 minutes ago]

Fri, 18 Oct 2024 20:15:38 GMT

Hi,

Bald Eagle writes:
> Francois LE COAT wrote:
>> It is possible to perceive the relief (in depth) of a scene, when we
>> have at least two different viewpoints of it. Here is a new example wi
th
>> a drone flying in the middle of a forest of trees, and from which we
>> process the video stream from the embedded camera...
>>
>> <https://www.youtube.com/watch?v=WJ20EBM3PTc>
>>
>> When the two views of the same scene are distant in space, we speak
>> of "spatial disparity". In the present case, the two viewpoints are
>> distant in time, and we then speak of "temporal disparity". This
>> involves knowing whether the two images of the same scene are acquired

>> simultaneously, or delayed in time. We can perceive the relief in dept
h
>> in this case, with a single camera and its continuous video stream.
> 
> Francois,
> 
> Although I believe that I understand the general idea of what you're do
ing in
> your work, it's a bit difficult to fully grasp the details from the vid
eo.
> 
> I'm assuming that you're taking the first frame as a reference image, a
nd then
> reorienting the second frame to optimize the registration.
> Then you're using the OpenCV to do some sort of photogrammetry to gener
ate a
> projection matrix from the 2D image, and extract/back-calculate 3D data
 from
> that matrix for everything in the frame.
> 
> Then you move to the pair of 2nd frame + 3rd frame and repeat the proce
ss.
> 
> Is this correct?

I have the first reference image, and the second one, from which I
determine the optical-flow. That means every pixel integer displacement
between an image, to the other. That gives a vector field that can
be approximated by a global projective transformation. That means eight
parameters in rotation and translation, that match the two images the
best. The quality of the images' matching is measured with correlation,
between the first image and the second (projectively) transformed.

I repeat the treatments with the third, the fourth that gives me a
decreasing correlation value... Until correlation drops below 60%.

Then when correlation is too low, I take a new reference image (the
last good matching) let's admit fourth, and continue to determine
good matching (>60% correlation) with fifth, sixth, and so forth ...

That gives me reliable 8 projective transform parameters between 1st
and 4th images, because of the good correlation. That also gives me
the reliable vector field of the optical-flow, that can be named
"temporal disparity" horizontal and vertical. That's what you're seeing
in grey levels images.

Disparity field which is an integer displacement between images, is
linked to depth in the image (3rd dimension) with an inverse relation
(depth=base/disparity). That means we can evaluate image's depth from
a continuous video stream.

> I'm also wondering if you could create a 3D rendering with the data you
're
> extracting, and maybe a 2D orthographic overhead map of the scene that 
the
> drones are flying through, mapping the position of the drones in the fo
rest.

The disparity measurements are a physical approximation (optical
flow) that is imperfect, and is constantly improved with science
researches. I'm always interested in the progress with this domain.
But for the moment we must have a compromise between quality and
computing time. All is not so perfect, that we can imagine what
you're wishing, from the state of the art...

> As always, I am very interested in understanding the details of what yo
u're
> doing.

I hope you understood it better. I may be a little confuse...

> This is great work, and I hope you are properly recognized for your
> achievements.
> 
> - BW

It's a long work since I can show some promising results. Now I'm
happy to share it with a larger audience. Unfortunately all the
good people that worked with me, are not here to appreciate. That's
why I'm surprised with your interest =)

Thanks for your attention.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: Optical Inertia [545 days and 39 minutes ago]

Fri, 18 Oct 2024 13:35:00 GMT

Francois LE COAT <lec### [at] atariorg> wrote:

> It is possible to perceive the relief (in depth) of a scene, when we
> have at least two different viewpoints of it. Here is a new example with
> a drone flying in the middle of a forest of trees, and from which we
> process the video stream from the embedded camera...
>
> <https://www.youtube.com/watch?v=WJ20EBM3PTc>
>
> When the two views of the same scene are distant in space, we speak
> of "spatial disparity". In the present case, the two viewpoints are
> distant in time, and we then speak of "temporal disparity". This
> involves knowing whether the two images of the same scene are acquired
> simultaneously, or delayed in time. We can perceive the relief in depth
> in this case, with a single camera and its continuous video stream.

Francois,

Although I believe that I understand the general idea of what you're doing in
your work, it's a bit difficult to fully grasp the details from the video.

I'm assuming that you're taking the first frame as a reference image, and then
reorienting the second frame to optimize the registration.
Then you're using the OpenCV to do some sort of photogrammetry to generate a
projection matrix from the 2D image, and extract/back-calculate 3D data from
that matrix for everything in the frame.

Then you move to the pair of 2nd frame + 3rd frame and repeat the process.

Is this correct?

I'm also wondering if you could create a 3D rendering with the data you're
extracting, and maybe a 2D orthographic overhead map of the scene that the
drones are flying through, mapping the position of the drones in the forest.

As always, I am very interested in understanding the details of what you're
doing.

This is great work, and I hope you are properly recognized for your
achievements.

- BW

[Francois LE COAT] Re: Optical Inertia [546 days and 38 minutes ago]

Thu, 17 Oct 2024 13:35:47 GMT

Hi,

Francois LE COAT writes:
>> The experiment from Hernan Badino was redone. You can see it there...
>>
>>      <https://www.youtube.com/watch?v=fqWdSfN9FiA> Source
>>
>> The main interest is that video is looping, and the result is almost:
>>
>>      <https://www.youtube.com/watch?v=0ZPJmnBh03M> Reworke
d
>>
>> Well, Hernan Badino is moving his head when he is walking, so the
>> reconstructed trajectory is not perfectly looping at the end. But
>> we can reconstruct the movement almost perfectly. We use OpenCV
>> for image processing, and POV-Ray for 3D representation. We have
>> to determine projective dominant motion in the video with a
>> reference image, and change it when correlation drops below 80%.
>>
>> We have a 3D inertial model of motion, that's why POV-Ray helps =)
> 
> Three drones are flying between forests of trees. Thanks to the
> optical-flow (DIS OpenCV) measured on successive images, the
> "temporal disparity" reveals the forest of trees (3rd dimension)...
> 
> <https://www.youtube.com/watch?v=QP75EeFVyOI> 1st drone
> <https://www.youtube.com/watch?v=fp5Z1Nu4Hko> 2nd drone
> <https://www.youtube.com/watch?v=fLxE8iS7fPI> 3rd drone
> 
> The interest with the forest is that trajectories are curved, in
> order to avoid obstacles. It is measured thanks to a projective
> transform, and represented with <Ry,Rz,Tx,Tz> thanks to POV-Ray.
> The evolution of the drone is shown in front-view with its camera.

It is possible to perceive the relief (in depth) of a scene, when we
have at least two different viewpoints of it. Here is a new example with
a drone flying in the middle of a forest of trees, and from which we
process the video stream from the embedded camera...

<https://www.youtube.com/watch?v=WJ20EBM3PTc>

When the two views of the same scene are distant in space, we speak
of "spatial disparity". In the present case, the two viewpoints are
distant in time, and we then speak of "temporal disparity". This
involves knowing whether the two images of the same scene are acquired
simultaneously, or delayed in time. We can perceive the relief in depth
in this case, with a single camera and its continuous video stream.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[jr] Re: Slicing media - is it possible ? [565 days and 24 minutes ago]

Sat, 28 Sep 2024 13:50:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 24/09/2024 20:40, yesbird wrote:
> Can't resist to share a pair of beautiful slices produced by simple
> box resizing.

agree, nice, dicom_3 in particular.  thanks.


regards, jr.

[yesbird] Re: Slicing media - is it possible ? [565 days 12 hours ago]

Sat, 28 Sep 2024 02:13:46 GMT

On 24/09/2024 20:40, yesbird wrote:
Can't resist to share a pair of beautiful slices produced by simple
box resizing.
--
YB

[Alain Martel] Re: Slicing media - is it possible ? [565 days 23 hours and 56 minutes ago]

Fri, 27 Sep 2024 14:17:23 GMT

Le 2024-09-26 Ã  16:35, yesbird a Ã©critÂ :
> Alain, sorry for mixing you name, I need a better glasses...
> -- 
> YB
ðŸ˜ŽðŸ¤£

[yesbird] Re: Slicing media - is it possible ? [566 days 17 hours and 38 minutes ago]

Thu, 26 Sep 2024 20:35:53 GMT

Alain, sorry for mixing you name, I need a better glasses...
--
YB

[yesbird] Re: Slicing media - is it possible ? [566 days 17 hours and 42 minutes ago]

Thu, 26 Sep 2024 20:31:24 GMT

On 25/09/2024 23:54, MichaelJF wrote:
> Sorry, yesterday I addressed the general question of the possibility of 
> CSG operations with media and not your special example.
> ...

No problem - in any case thanks for participating in solving this
sophisticated problem :). Thanks to Alan I have a serious progress now.
--
YB

[yesbird] Re: Slicing media - is it possible ? [566 days 17 hours and 48 minutes ago]

Thu, 26 Sep 2024 20:25:51 GMT

On 25/09/2024 18:58, Alain Martel wrote:
> I see that your code use intervals 60.
> That's REAL bad.
> This will render faster with better results :
>  
> #declare themedia = interior{
> media{
>  Â Â Â Â samples 100
>  Â Â Â Â // stating method 3 is not needed
as it's the default
>  Â Â Â Â // ratio is not used with method 3
>  Â Â Â Â // confidence and variance are also
not used
>  Â Â Â Â emission 1/20 //OK
>  Â Â Â Â absorption 1/1000 //OK
>  Â Â Â Â scattering {1, -0.3} //OK
>  Â Â Â Â density{
> 
Â Â Â Â Â Â Â 
<density items>
> 
Â Â Â Â Â Â Â 
// As interpolate 0 mean no interpolation,
> 
Â Â Â Â Â Â Â 
// you can omit it
> 
Â Â Â Â Â Â Â  }
>  Â Â Â Â }
> }

Alan !
Many, many thanks for this correction - rendering now is really faster
with better quality. All your information about parameter's
interference is also very valuable - you saved a lot of time for me.
I like your deep and serious  approach.

> Then. Change your container as follow :
> difference{
> 
Â Â Â Â box{Â Â Â 
0, 1
> 
Â Â Â Â Â Â Â 
translate -0.5
> 
Â Â Â Â Â Â Â 
scale 200
>  Â Â Â Â }// NO pigment
> 
Â Â Â Â box{Â Â Â 
0, 1
> 
Â Â Â Â Â Â Â 
translate -0.5
> 
Â Â Â Â Â Â Â 
scale <100, 100, 201>//400 is uselessly large
>  Â Â Â Â }//still no pigment
>  Â Â Â Â hollow //apply to the difference as
a whole
>  Â Â Â Â pigment{rgbf 1}
>  Â Â Â Â interior{ theinterior}
>  Â Â Â Â }
> 

Unfortunately here still no success (please see 1st attached image).
It looks like scaling / translation issue - I will try to fix it.

In any case slicing by orthogonal planes by changing the box size
(as on 2nd image) will be enough - CSG operations was only exercise for
me. And now I believe - the media is really tricky :)
--
YB

[MichaelJF] Re: Slicing media - is it possible ? [567 days 17 hours and 19 minutes ago]

Wed, 25 Sep 2024 20:54:24 GMT

Sorry, yesterday I addressed the general question of the possibility of 
CSG operations with media and not your special example. Now reading 
Alains post, I think your actual problem has nothing to do with media at 
all, but with the way POV handles textures in case of a CSG difference. 
May be sections 3.6.1.9 and 3.6.1.10 in the docs about interior and 
cutaway textures solve your special riddle since the default of an 
undefined texture is black as is your background. In your case the 
texture of the subtracted second box is undefined as well as the 
interior/cutaway texture of the first with the df3-interior. Anyway, 
Alains remedies shuld help.

Best regards
Michael

[Alain Martel] Re: Slicing media - is it possible ? [567 days 22 hours and 15 minutes ago]

Wed, 25 Sep 2024 15:58:57 GMT

Le 2024-09-24 Ã  13:40, yesbird a Ã©critÂ :
> Hi,
> I am trying to apply CSG operations to objects filled with media without
> any success (results also attached):
> https://povlab.online/?scene=dicom.pov
> 
> Who knows if it's really possible or I am only wasting the time trying
> to force it to work ?
> 
> Thanks in advance.
> -- 
> YB

I see that your code use intervals 60.
That's REAL bad.
This will render faster with better results :

#declare themedia = interior{
media{
	samples 100
	// stating method 3 is not needed as it's the default
	// ratio is not used with method 3
	// confidence and variance are also not used
	emission 1/20 //OK
	absorption 1/1000 //OK
	scattering {1, -0.3} //OK
	density{
		<density items>
		// As interpolate 0 mean no interpolation,
		// you can omit it
		}
	}
}

Using intervals with any value >1 massively increase the rendering time 
and can introduce artifacts and glitches.

Then. Change your container as follow :
difference{
	box{	0, 1
		translate -0.5
		scale 200
	}// NO pigment
	box{	0, 1
		translate -0.5
		scale <100, 100, 201>//400 is uselessly large
	}//still no pigment
	hollow //apply to the difference as a whole
	pigment{rgbf 1}
	interior{ theinterior}
	}


Using the default method 3, you need to avoid using intervals 
altogether. Using intervals is a huge performance killer.
Then, the parameters ratio, confidence and variance are specific to 
method 1 and 2 and are used to control how many samples are to be used 
for each intervals. As you work with only 1 intervals, they have no effect.

[Alain Martel] Re: Slicing media - is it possible ? [567 days 22 hours and 38 minutes ago]

Wed, 25 Sep 2024 15:35:56 GMT

Le 2024-09-24 Ã  13:40, yesbird a Ã©critÂ :
> Hi,
> I am trying to apply CSG operations to objects filled with media without
> any success (results also attached):
> https://povlab.online/?scene=dicom.pov
> 
> Who knows if it's really possible or I am only wasting the time trying
> to force it to work ?
> 
> Thanks in advance.
> -- 
> YB
Looks like that box is opaque.

If you start by applying the media THEN cut away, you need to make sure 
that the other object also have rgbt 1 as it's pigment.

The best approach here is to do all of your CSG before adding your 
media, add the transparent pigment at once to the totality of the 
composite object, then add the media.

DO NOT use union. You can use merge, intersection and difference. As 
union don't remove any internal surface, it'll wreak havoc with your media.

[yesbird] Re: Slicing media - is it possible ? [568 days 17 hours and 40 minutes ago]

Tue, 24 Sep 2024 20:33:56 GMT

On 24/09/2024 22:37, MichaelJF wrote:
> The section "Multiple Density vs. Multiple Media" may be of help. One 
> can simulate intersections and unions of media with this approach.
> 
> Most freedom you can achieve with user defined functions to control the 
> density. But it can be very time-consuming to find the right parameters.

Thanks a lot, I will explore it !
--
YB

[MichaelJF] Re: Slicing media - is it possible ? [568 days 18 hours and 36 minutes ago]

Tue, 24 Sep 2024 19:37:31 GMT

Am 24.09.2024 um 20:14 schrieb Bald Eagle:
> yesbird <sya### [at] gmailcom> wrote:
>> Hi,
>> I am trying to apply CSG operations to objects filled with media without
>> any success (results also attached):
>> https://povlab.online/?scene=dicom.pov
>>
>> Who knows if it's really possible or I am only wasting the time trying
>> to force it to work ?
>>
>> Thanks in advance.
>> --
>> YB
> 
> Media is . . . tricky.

Indeed!

> (Thus why I haven't used it a lot)
> 
> Just curious:
> Have you tried the reverse - applying CSG operations to a container and THEN
> filling it with media?
> 
> I think that if you read the documentation on the details of how media works, it
> might help - or it may not.  It's so very dependent on what you're trying to do
> and how you're going about doing it.
> 
The section "Multiple Density vs. Multiple Media" may be of help. One 
can simulate intersections and unions of media with this approach.

Most freedom you can achieve with user defined functions to control the 
density. But it can be very time-consuming to find the right parameters.



Best regards
Michael

[yesbird] Re: Slicing media - is it possible ? [568 days 19 hours and 39 minutes ago]

Tue, 24 Sep 2024 18:34:21 GMT

On 24/09/2024 21:14, Bald Eagle wrote:
> Just curious:
> Have you tried the reverse - applying CSG operations to a container and THEN
> filling it with media?

Hmm, interesting - I will try ...
--
YB

[Bald Eagle] Re: Slicing media - is it possible ? [568 days 19 hours and 59 minutes ago]

Tue, 24 Sep 2024 18:15:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi,
> I am trying to apply CSG operations to objects filled with media without
> any success (results also attached):
> https://povlab.online/?scene=dicom.pov
>
> Who knows if it's really possible or I am only wasting the time trying
> to force it to work ?
>
> Thanks in advance.
> --
> YB

Media is . . . tricky.
(Thus why I haven't used it a lot)

Just curious:
Have you tried the reverse - applying CSG operations to a container and THEN
filling it with media?

I think that if you read the documentation on the details of how media works, it
might help - or it may not.  It's so very dependent on what you're trying to do
and how you're going about doing it.

- BW

[yesbird] Re: Slicing media - is it possible ? [568 days 20 hours and 22 minutes ago]

Tue, 24 Sep 2024 17:51:58 GMT

On 24/09/2024 20:40, yesbird wrote:

PS: I know, that by changing the cube size this effect can be achieved,
but applying CSG operations is still mystery to me.
--
YB

[yesbird] Slicing media - is it possible ? [568 days 20 hours and 33 minutes ago]

Tue, 24 Sep 2024 17:40:22 GMT

Hi,
I am trying to apply CSG operations to objects filled with media without
any success (results also attached):
https://povlab.online/?scene=dicom.pov

Who knows if it's really possible or I am only wasting the time trying
to force it to work ?

Thanks in advance.
--
YB

[yesbird] Re: Fast volume rendering [569 days 22 hours and 37 minutes ago]

Mon, 23 Sep 2024 15:36:41 GMT

On 23/09/2024 18:21, Alain Martel wrote:
> The type of media used have a lot of effect. A media can be emissive, 
> ...

Thank you very much for detailed explanation and useful suggestions -
you saved me a lot of time, while I am still have a space for
interesting experiments with media :).
--
YB

[Alain Martel] Re: Fast volume rendering [569 days 22 hours and 53 minutes ago]

Mon, 23 Sep 2024 15:21:05 GMT

Le 2024-09-23 Ã  09:26, yesbird a Ã©critÂ :
> Hi all !
> 
> I am workingÂ on web GUI to Povray for volume visualization
> applications,Â using 'media' and 'df3' format. The main ideaÂ is
providing
> the user with some fast WebGL-based gizmos (bounding box, grid,light
> version of volume data) for fast camera positioning like here:
> https://threejs.org/examples/?q=volume#webgl_volume_perlin
> 
> and then making server-side high-quality renderingÂ like here:
> https://povlab.online/?scene=dicom.pov
> 
> Can anyone suggestÂ how to make volume rendering faster, but without
> losing a quality ?
> 
> Thanks in advance.
> -- 
> YB
> 
> 
The type of media used have a lot of effect. A media can be emissive, 
absorbing or scattering.
Emissive media renders the fastest. They work better against a dark 
background. They add to the background. They never cast any shadow and 
never interact with any light_source.

Absorbing media is a close second. Work better against a light 
background. They subtract from the background. They do cast shadows when 
there is some light_source present. Lights never illuminate them.

Scattering media are the slowest. They need a light source that interact 
with them. They subtract from the background, when there is a light, 
they also add to the background.

Use the default sampling method 3. NEVER use an intervals value larger 
than the default of 1, increase the sample value instead. More intervals 
can cause glitches and is MUCH slower. intervals 10 samples 10 is at 
least 5 times slower than just samples 200 for half the samples.

[yesbird] Re: Fast volume rendering [569 days 22 hours and 59 minutes ago]

Mon, 23 Sep 2024 15:14:23 GMT

On 23/09/2024 17:21, Bald Eagle wrote:
> Or are you looking to find a way to render 3D volumes in POV-Ray faster than
> whatever methods you're currently using?
Yes, this one.
I see the following workflow:

User is playing with the scene using three.js and then by
clicking "Render" button (or by releasing the mouse button) sends an SDL
scene, generated on-the-fly, to the server, getting a rendered image.
(Assuming that 'df3' data is already on the server).

The main goal is to make this cycle as fast as possible, ideally
achieving near-real-time performance. I am investigating 'media' with
'df3' deeply now, maybe there are some hidden tricks and/or parameters
will help ...

General idea is building the bridge between theÂ WebGL/WebXR (three.js)
and Povray for different applications, like this future  math-museum:
https://math.povlab.online/
(inspired by https://virtualmathmuseum.org/)

BTW,Â behindÂ the povlab.online now 128 virtual cores of:
--------------------------------------------------
AMD EPYC 7763 64-Core Processor
CPU MHz Â  Â  Â  Â  : 2599.927
--------------------------------------------------
YB

[Bald Eagle] Re: Fast volume rendering [569 days 23 hours and 49 minutes ago]

Mon, 23 Sep 2024 14:25:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi all !
>
> I am working on web GUI to Povray for volume visualization
> applications, using 'media' and 'df3' format. The main idea is providing
> the user with some fast WebGL-based gizmos (bounding box, grid,light
> version of volume data) for fast camera positioning like here:
> https://threejs.org/examples/?q=volume#webgl_volume_perlin
>
> and then making server-side high-quality rendering like here:
> https://povlab.online/?scene=dicom.pov
>
> Can anyone suggest how to make volume rendering faster, but without
> losing a quality ?
>
> Thanks in advance.
> --
> YB

Off the top of my head, POV-Ray's media would get approximated by a procedural
function that governed the rgb values based on the <x, y, z> coordinates, and so
whatever method that threejs uses, or Shadertoy ought to give decent results.

Reading in a df3 file would seem to be the only bottleneck.

Are you looking to make it faster than the examples you linked to?
Or are you looking to find a way to render 3D volumes in POV-Ray faster than
whatever methods you're currently using?

- BW

[yesbird] Fast volume rendering [570 days and 47 minutes ago]

Mon, 23 Sep 2024 13:26:27 GMT

Hi all !

I am workingÂ on web GUI to Povray for volume visualization
applications,Â using 'media' and 'df3' format. The main ideaÂ is
providing
the user with some fast WebGL-based gizmos (bounding box, grid,light
version of volume data) for fast camera positioning like here:
https://threejs.org/examples/?q=volume#webgl_volume_perlin

and then making server-side high-quality renderingÂ like here:
https://povlab.online/?scene=dicom.pov

Can anyone suggestÂ how to make volume rendering faster, but without
losing a quality ?

Thanks in advance.
--
YB

[jr] Re: Making Patterns with functions [577 days 1 hour and 39 minutes ago]

Mon, 16 Sep 2024 12:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > #declare S2P = function (V) {sin (tau*V/L)}
> > #declare C2P = function (V) {cos (tau*V/L)}
> > #declare T = 0.5;
> > #declare N = 1;
> > #declare Honeycomb = function (X, Y, Z) {pow(S2P(X)*C2P(Z) + S2P(Z) + C2P(X), N)
> > - pow(T, N)}
>
> plane with "Honeycomb" pattern, seen through "kaleidoscope".

a loop-able animation of the pattern.  warning -- weird ;-).

<https://drive.google.com/file/d/1Aet9noapf8SBgX2u62TTYMFYx5NfbckT/view?usp=sharing>

enjoy, jr.

[yesbird] Re: Location changing while scaling [591 days 3 hours and 7 minutes ago]

Mon, 2 Sep 2024 11:06:34 GMT

On 02/09/2024 13:48, ingo wrote:
> You should create and scale the sphere at the origin and then move it to the
> mesh vertex vector.
> 
> 
> // Spheres
> #local len = dimension_size(VertexVectors,1) - 1;
> #for (i, 0, len)
>     sphere { <0,0,0>, 0.04
>              texture { pigment {rgb <0.1, 0.3, 0.1>} }
>              scale y * 1.2 // Why they moves ?
>              translate VertexVectors[i]
>    }

Thanks a lot, now it works fine !
--
YB

[yesbird] Re: Location changing while scaling [591 days 3 hours and 9 minutes ago]

Mon, 2 Sep 2024 11:04:37 GMT

On 02/09/2024 13:43, Alain Martel wrote:
> You need to scale your spheres when they are at <0,0,0> then translate 
> them to the desired location.
> 
> Use this instead :
> // Spheres
> #local len = dimension_size(VertexVectors,1) - 1;
> #for (i, 0, len)
>  Â  sphere { 0, 0.04 scale y * 1.2 // No longer move
> 
Â Â Â Â Â Â Â Â Â Â 
texture { pigment {rgb <0.1, 0.3, 0.1>} }
> 
>  Â Â Â Â translate VertexVectors[i]
>  Â  }

Many thanks for elegant solution !
--
YB

[ingo] Re: Location changing while scaling [591 days 3 hours and 24 minutes ago]

Mon, 2 Sep 2024 10:50:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi, all !
>
> While playing with meshes I've encountered strange behavior of spheres,
> positioned at mesh vertices - after changing the scale they are moving
> from previous locations (see images). [...]
>
> // Spheres
> #local len = dimension_size(VertexVectors,1) - 1;
> #for (i, 0, len)
>    sphere { VertexVectors[i], 0.04
>             texture { pigment {rgb <0.1, 0.3, 0.1>} }
>             scale y * 1.2 // Why they moves ?
>    }
> #end
> // ------------------------------------------------------------------

You should create and scale the sphere at the origin and then move it to the
mesh vertex vector.


// Spheres
#local len = dimension_size(VertexVectors,1) - 1;
#for (i, 0, len)
   sphere { <0,0,0>, 0.04
            texture { pigment {rgb <0.1, 0.3, 0.1>} }
            scale y * 1.2 // Why they moves ?
            translate VertexVectors[i]
  }

ingo

[Alain Martel] Re: Location changing while scaling [591 days 3 hours and 30 minutes ago]

Mon, 2 Sep 2024 10:43:39 GMT

Le 2024-09-02 Ã  05:39, yesbird a Ã©critÂ :
> Hi, all !
> 
> While playing with meshes I've encountered strange behaviorÂ of spheres, 
> positioned at mesh vertices - after changing the scale they move from 
> previous location (see images). LooksÂ like the scale 
> operationÂ appliedÂ to a whole array of spheres, produced by
loop, but the 
> scale operator is inside the sphere object. I expected they would stay 
> in place and only change the size.
> 
> What I'm missing ? Any suggestions please ...
> -- 
> YB
> 
> // ------------------------------------------------------------------
> #version 3.8;
> global_settings { assumed_gamma 1 }
> 
> camera {
>  Â  perspective
>  Â  angle 25
>  Â  location Â <20,15,20> * 0.2
>  Â  look_at Â  <0.5,0.5,0>
>  Â  right x * image_width / image_height
> }
> 
> light_source{<-500,0,0> rgb 1} light_source{<500,0,0> rgb 1}
> light_source{<0,0,-500> rgb 1} light_source{<0,0,500> rgb 1}
> light_source{<20,15,20> rgb 0.4}
> 
> 
> #declare VertexVectors= array[24] {
>  Â  <0,0,0>, <0.5,0,0>, <0.5,0.5,0>, //1
>  Â  <0.5,0,0>, <1,0,0>, <0.5,0.5,0>, //2
>  Â  <1,0,0>, <1,0.5,0>, <0.5,0.5,0>, //3
>  Â  <1,0.5,0>, <1,1,0>, <0.5,0.5,0>, //4
>  Â  <1,1,0>, <0.5,1,0>, <0.5,0.5,0>, //5
>  Â  <0.5,1,0>, <0,1,0>, <0.5,0.5,0>, //6
>  Â  <0,1,0>, <0,0.5,0>, <0.5,0.5,0>, //7
>  Â  <0,0.5,0>, <0,0,0>, <0.5,0.5,0> Â //8
> }
> 
> // Mesh
> mesh2 {
> 
>  Â  Â #local len = dimension_size(VertexVectors,1);
>  Â  Â vertex_vectors {
>  Â  Â  Â  len,
> 
Â Â Â Â Â Â Â Â Â 
#for (i, 0, len-1)
>  Â 
Â Â Â Â Â Â Â Â Â 
VertexVectors[i]
> 
Â Â Â Â Â Â Â Â Â 
#end
>  Â  Â }
> 
>  Â  Â face_indices {
>  Â  Â  Â  8,
>  Â  Â  Â  <0,1,2>, Â  Â <3,4,5>,
Â  Â  Â  //1 2
>  Â  Â  Â  <6,7,8>, Â  Â <9,10,11>,
Â  Â  //3 4
>  Â  Â  Â  <12,13,14>, <15,16,17>, Â 
Â //5 6
>  Â  Â  Â  <18,19,20>, <21,22,23> Â 
Â  //7 8
>  Â  Â }
> 
>  Â  Â pigment {rgb 1}
> }
> 
> 
> // Spheres
> #local len = dimension_size(VertexVectors,1) - 1;
> #for (i, 0, len)
>  Â  sphere { VertexVectors[i], 0.04
>  Â  Â  Â  Â  Â 
Â texture { pigment {rgb <0.1, 0.3, 0.1>} }
>  Â  Â  Â  Â  Â  Â scale
y * 1.2 // Why they moves ?
>  Â  }
> #end
> // ------------------------------------------------------------------
The scale is applied relative to the origin of the coordinate system, 
not to the centre of the object.
That mean that the centre of your spheres are scaled.
You need to scale your spheres when they are at <0,0,0> then translate 
them to the desired location.

Use this instead :
// Spheres
#local len = dimension_size(VertexVectors,1) - 1;
#for (i, 0, len)
   sphere { 0, 0.04 scale y * 1.2 // No longer move
            texture { pigment {rgb <0.1, 0.3, 0.1>} }

	translate VertexVectors[i]
   }

[yesbird] Location changing while scaling [591 days 4 hours and 28 minutes ago]

Mon, 2 Sep 2024 09:46:05 GMT

Hi, all !

While playing with meshes I've encountered strange behavior of spheres,
positioned at mesh vertices - after changing the scale they are moving
from previous locations (see images). Looks like the scale operation
applied to a whole array of spheres, produced by loop, but the scale
operator is inside the sphere object. I expected they would stay in
place and only change the size.

What I'm missing ? Any suggestions please ...
-- 
YB

// ------------------------------------------------------------------
#version 3.8;
global_settings { assumed_gamma 1 }

camera {
   perspective
   angle 25
   location  <20,15,20> * 0.2
   look_at   <0.5,0.5,0>
   right x * image_width / image_height
}

light_source{<-500,0,0> rgb 1} light_source{<500,0,0> rgb 1}
light_source{<0,0,-500> rgb 1} light_source{<0,0,500> rgb 1}
light_source{<20,15,20> rgb 0.4}

#declare VertexVectors= array[24] {
   <0,0,0>, <0.5,0,0>, <0.5,0.5,0>, //1
   <0.5,0,0>, <1,0,0>, <0.5,0.5,0>, //2
   <1,0,0>, <1,0.5,0>, <0.5,0.5,0>, //3
   <1,0.5,0>, <1,1,0>, <0.5,0.5,0>, //4
   <1,1,0>, <0.5,1,0>, <0.5,0.5,0>, //5
   <0.5,1,0>, <0,1,0>, <0.5,0.5,0>, //6
   <0,1,0>, <0,0.5,0>, <0.5,0.5,0>, //7
   <0,0.5,0>, <0,0,0>, <0.5,0.5,0>  //8
}

// Mesh
mesh2 {
    #local len = dimension_size(VertexVectors,1);
    vertex_vectors {
       len,
           #for (i, 0, len-1)
             VertexVectors[i]
           #end
    }

    face_indices {
       8,
       <0,1,2>,    <3,4,5>,       //1 2
       <6,7,8>,    <9,10,11>,     //3 4
       <12,13,14>, <15,16,17>,    //5 6
       <18,19,20>, <21,22,23>     //7 8
    }

    pigment {rgb 1}
}

// Spheres
#local len = dimension_size(VertexVectors,1) - 1;
#for (i, 0, len)
   sphere { VertexVectors[i], 0.04
            texture { pigment {rgb <0.1, 0.3, 0.1>} }
            scale y * 1.2 // Why they moves ?
   }
#end
// ------------------------------------------------------------------

[yesbird] Location changing while scaling [591 days 4 hours and 32 minutes ago]

Mon, 2 Sep 2024 09:41:48 GMT

Hi, all !

While playing with meshes I've encountered strange behavior of spheres,
positioned at mesh vertices - after changing the scale they move from
previous location (see images). Looks like the scale operation applied
to a whole array of spheres, produced by loop, but the scale operator is
inside the sphere object. I expected they would stay in place and only
change the size.

What I'm missing ? Any suggestions please ...
--
YB

// ------------------------------------------------------------------
#version 3.8;
global_settings { assumed_gamma 1 }

camera {
   perspective
   angle 25
   location  <20,15,20> * 0.2
   look_at   <0.5,0.5,0>
   right x * image_width / image_height
}

light_source{<-500,0,0> rgb 1} light_source{<500,0,0> rgb 1}
light_source{<0,0,-500> rgb 1} light_source{<0,0,500> rgb 1}
light_source{<20,15,20> rgb 0.4}

#declare VertexVectors= array[24] {
   <0,0,0>, <0.5,0,0>, <0.5,0.5,0>, //1
   <0.5,0,0>, <1,0,0>, <0.5,0.5,0>, //2
   <1,0,0>, <1,0.5,0>, <0.5,0.5,0>, //3
   <1,0.5,0>, <1,1,0>, <0.5,0.5,0>, //4
   <1,1,0>, <0.5,1,0>, <0.5,0.5,0>, //5
   <0.5,1,0>, <0,1,0>, <0.5,0.5,0>, //6
   <0,1,0>, <0,0.5,0>, <0.5,0.5,0>, //7
   <0,0.5,0>, <0,0,0>, <0.5,0.5,0>  //8
}

// Mesh
mesh2 {
    #local len = dimension_size(VertexVectors,1);
    vertex_vectors {
       len,
           #for (i, 0, len-1)
             VertexVectors[i]
           #end
    }

    face_indices {
       8,
       <0,1,2>,    <3,4,5>,       //1 2
       <6,7,8>,    <9,10,11>,     //3 4
       <12,13,14>, <15,16,17>,    //5 6
       <18,19,20>, <21,22,23>     //7 8
    }

    pigment {rgb 1}
}

// Spheres
#local len = dimension_size(VertexVectors,1) - 1;
#for (i, 0, len)
   sphere { VertexVectors[i], 0.04
            texture { pigment {rgb <0.1, 0.3, 0.1>} }
            scale y * 1.2 // Why they moves ?
   }
#end
// ------------------------------------------------------------------

[yesbird] Location changing while scaling [591 days 4 hours and 34 minutes ago]

Mon, 2 Sep 2024 09:39:26 GMT

Hi, all !

While playing with meshes I've encountered strange behaviorÂ of spheres, 
positioned at mesh vertices - after changing the scale they move from 
previous location (see images). LooksÂ like the scale 
operationÂ appliedÂ to a whole array of spheres, produced by loop,
but the 
scale operator is inside the sphere object. I expected they would stay 
in place and only change the size.

What I'm missing ? Any suggestions please ...
--
YB

// ------------------------------------------------------------------
#version 3.8;
global_settings { assumed_gamma 1 }

camera {
 Â  perspective
 Â  angle 25
 Â  location Â <20,15,20> * 0.2
 Â  look_at Â  <0.5,0.5,0>
 Â  right x * image_width / image_height
}

light_source{<-500,0,0> rgb 1} light_source{<500,0,0> rgb 1}
light_source{<0,0,-500> rgb 1} light_source{<0,0,500> rgb 1}
light_source{<20,15,20> rgb 0.4}


#declare VertexVectors= array[24] {
 Â  <0,0,0>, <0.5,0,0>, <0.5,0.5,0>, //1
 Â  <0.5,0,0>, <1,0,0>, <0.5,0.5,0>, //2
 Â  <1,0,0>, <1,0.5,0>, <0.5,0.5,0>, //3
 Â  <1,0.5,0>, <1,1,0>, <0.5,0.5,0>, //4
 Â  <1,1,0>, <0.5,1,0>, <0.5,0.5,0>, //5
 Â  <0.5,1,0>, <0,1,0>, <0.5,0.5,0>, //6
 Â  <0,1,0>, <0,0.5,0>, <0.5,0.5,0>, //7
 Â  <0,0.5,0>, <0,0,0>, <0.5,0.5,0> Â //8
}

// Mesh
mesh2 {

 Â  Â #local len = dimension_size(VertexVectors,1);
 Â  Â vertex_vectors {
 Â  Â  Â  len,
 Â  		#for (i, 0, len-1)
 Â  Â  		VertexVectors[i]
 Â  		#end
 Â  Â }

 Â  Â face_indices {
 Â  Â  Â  8,
 Â  Â  Â  <0,1,2>, Â  Â <3,4,5>,
Â  Â  Â  //1 2
 Â  Â  Â  <6,7,8>, Â  Â <9,10,11>,
Â  Â  //3 4
 Â  Â  Â  <12,13,14>, <15,16,17>, Â 
Â //5 6
 Â  Â  Â  <18,19,20>, <21,22,23> Â 
Â  //7 8
 Â  Â }

 Â  Â pigment {rgb 1}
}


// Spheres
#local len = dimension_size(VertexVectors,1) - 1;
#for (i, 0, len)
 Â  sphere { VertexVectors[i], 0.04
 Â  Â  Â  Â  Â  Â texture
{ pigment {rgb <0.1, 0.3, 0.1>} }
 Â  Â  Â  Â  Â  Â scale y
* 1.2 // Why they moves ?
 Â  }
#end
// ------------------------------------------------------------------

[yesbird] Re: Making Patterns with functions [595 days 4 hours and 38 minutes ago]

Thu, 29 Aug 2024 09:35:15 GMT

On 28/08/2024 22:06, Bald Eagle wrote:
> An interesting approach that I'll have to look into further.
> 
> https://gcboore.com/pages/trigonometric-functions.html
> 
> Might be able to do the same thing with pigment patterns and homebrew function
> patterns.
> 

Really interesting, looking forward to the results of your experiments !
--
YB

[Bald Eagle] Re: Making Patterns with functions [595 days 19 hours and 4 minutes ago]

Wed, 28 Aug 2024 19:10:00 GMT

An interesting approach that I'll have to look into further.

https://gcboore.com/pages/trigonometric-functions.html

Might be able to do the same thing with pigment patterns and homebrew function
patterns.

[Bald Eagle] Re: Making Patterns with functions [596 days 13 hours and 19 minutes ago]

Wed, 28 Aug 2024 00:55:00 GMT

This one looks like sliced pita bread or hot dogs buns or something.

#declare Pattern3 = function {tan (3*x) * sin (5*x/2) * sin (z) - 0.1}

[jr] Re: Making Patterns with functions [598 days 21 hours and 54 minutes ago]

Sun, 25 Aug 2024 16:20:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Wheee!   Nice job.  :)

start on.  :-)


> Can you adjust the symmetry?  Have 6-fold, or 7?
> After playing with this stuff a bit, it seems like that whole sin*cos xy yz zx
> thing has a lot of potential as a base pattern to do all sorts of interesting
> things with.  Even just the threshold can change the apparent look quite a bit.

yes, I just discovered that replacing "tau" with "pi * scale_factor" and using
slightly different factors, things get real .. interesting.

re your question, I answer with an Obama quote: "Yes, we can" :-)  below is
excerpted from my WIP code:

/* added bailout & max_trace */
global_settings {adc_bailout (1/254) assumed_gamma 1 max_trace_level 255}

/* #mirrors */
#declare n_ = 3;

#declare angle_ = 360 / n_;

/* epsilon */
#declare eps_ = 1e-3;

/* length of tube */
#declare len_ = 10;

/* prism with hole */
#declare pi_ = <.99,0,0>;
#declare po_ = <1.01,0,0>;

#declare pts_ = array [n_][2];

#for (i_, 0, n_-1)
  #local ta_ = vrotate(po_, <0,(angle_*i_),0>);
  #local tb_ = vrotate(pi_, <0,(angle_*i_),0>);
  #local pts_[i_][0] = <ta_.x,ta_.z>;
  #local pts_[i_][1] = <tb_.x,tb_.z>;
#end

/* rotate to centre on -z */
prism {
  linear_spline eps_, len_, 2*(1+n_),
  #for (i_,n_-1,0,-1) pts_[i_][0], #end pts_[n_-1][0],
  #for (i_,0,n_-1) pts_[i_][1], #end pts_[0][1]
  open
  sturm on
  no_shadow
  finish {ambient 0 reflection {1} specular 0}
  rotate <270,0,0>
}


regards, jr.

[Bald Eagle] Re: Making Patterns with functions [598 days 22 hours and 29 minutes ago]

Sun, 25 Aug 2024 15:45:00 GMT

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

> plane with "Honeycomb" pattern, seen through "kaleidoscope".

Wheee!   Nice job.  :)

Can you adjust the symmetry?  Have 6-fold, or 7?

After playing with this stuff a bit, it seems like that whole sin*cos xy yz zx
thing has a lot of potential as a base pattern to do all sorts of interesting
things with.  Even just the threshold can change the apparent look quite a bit.
And then you have the orthogonal plane value/slice to vary.

We can square the whole sum, square the terms, take the root, etc.

- BW

[jr] Re: Making Patterns with functions [599 days 7 hours and 24 minutes ago]

Sun, 25 Aug 2024 06:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> > Kinda looks like a "dog bone" wood patch that alternates in directions like a
> > checkerboard.
>
> Sometimes these things are a little easier to write using some helper functions.
>
> #declare S2P = function (V) {sin (tau*V/L)}
> #declare C2P = function (V) {cos (tau*V/L)}
> #declare T = 0.5;
> #declare N = 1;
> #declare Honeycomb = function (X, Y, Z) {pow(S2P(X)*C2P(Z) + S2P(Z) + C2P(X), N)
> - pow(T, N)}

plane with "Honeycomb" pattern, seen through "kaleidoscope".


regards, jr.

[Bald Eagle] Re: Making Patterns with functions [600 days 12 hours and 54 minutes ago]

Sat, 24 Aug 2024 01:20:00 GMT

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

> Also of interest would be a metal diamond-plate pattern - the "honeycomb"
> pattern that I posted for jr has that alternating direction / row attribute that
> might be a good starting point for modification.

#declare YY = 0.625;
#declare Plate1 = function {select (1-pow(sin(2*pi*x)*cos(2*pi*YY) +
sin(2*pi*YY)*cos(2*pi*z) + sin(2*pi*z)*cos(2*pi*x), 2), 0, 0, 1)}

[Bald Eagle] Re: Making Patterns with functions [600 days 18 hours and 39 minutes ago]

Fri, 23 Aug 2024 19:35:00 GMT

I've also been interested in making this pattern:

http://sambrunacini.com/wp-content/uploads/2020/10/pursuit.png

and I could have sworn it has an actual NAME that I found once, and now I of
course can't find again.

Also of interest would be a metal diamond-plate pattern - the "honeycomb"
pattern that I posted for jr has that alternating direction / row attribute that
might be a good starting point for modification.

[Bald Eagle] Re: Making Patterns with functions [601 days 3 hours and 34 minutes ago]

Fri, 23 Aug 2024 10:40:00 GMT

Ha!
I think I have one of his "curles" patterns printed out somewhere here in a
pile.
I was just sifting through the archives and pulling out anything that seemed to
pop out.

Hopefully you know a few more - as you can tell, I love this stuff.

[ingo] Re: Making Patterns with functions [601 days 8 hours and 34 minutes ago]

Fri, 23 Aug 2024 05:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Over the last 2 days, I've fallen down the mathematical pattern rabbit hole, and
> have been experimenting with all manner of what can be done with a simple
> pigment {function {}}
> statement.

An old one by Alex Kluchikov, not a simple function though:

---%<------%<---

// Alex Kluchikov, 2003
// mailto: klk### [at] ukrnet, akl### [at] mailru
// Feel free to modify/use in any form
include "functions.inc"

camera{
 location -5*z
 look_at 0
 }

// we can get angle from gradient
#declare frad=function{
 pattern{radial}
 }

#declare fboz1=function{
 pattern{crackle form <1,0,0> scale 1}
 }

#declare fboz2=function{
 pattern{bumps noise_generator 3 rotate 60 scale 1.2}
 }

#declare fboz3=function{
 (sin(x+23)*sin(y+2)+sin(x*2.33443+11)*sin(y*2.4332+76)+sin(x*1.133443+32)*sin(y*1.234332+8)+3)*1/6
 }

#declare f1=function(x,y,z){
  (sin(fboz1(x,y,z)*24*pi
   +frad(fboz1(x,y,z)-fboz1(x,y-.07,z),0,fboz1(x,y,z)-fboz1(x+.07,y,z))
//gradient calculation
   *2*pi
//   +clock*pi*2 // uncomment to animate
   )+1)*(1/2)
   *(1-fboz1(x,y,z))
 }

#declare f2=function(x,y,z){
  (sin(fboz2(x,y,z)*24*pi
   +frad(fboz2(x,y,z)-fboz2(x,y-.07,z),0,fboz2(x,y,z)-fboz2(x+.07,y,z))
//gradient calculation
   *2*pi
//   +clock*pi*2 // uncomment to animate
   )+1)*(1/2)
 }

#declare f3=function(x,y,z){
  (sin(fboz3(x,y,z)*24*pi
   +frad(fboz3(x,y,z)-fboz3(x,y-.07,z),0,fboz3(x,y,z)-fboz3(x+.07,y,z))
//gradient calculation
   *2*pi
//   +clock*pi*2 // uncomment to animate
   )+1)*(1/2)
 }

#declare curles_1=texture{pigment{
  function{f1(x,y,z)}
  scale .25}
  finish{ambient 1}
  }

#declare curles_2=texture{pigment{
  function{f2(x,y,z)}
  color_map{[.45,color rgb 0][.55,color rgb 1]}
  scale .25}
  finish{ambient 1}
  }

#declare curles_3=texture{pigment{
  function{f3(x,y,z)}
  color_map{[.45,color rgb 0][.55,color rgb 1]}
  scale .25}
  finish{ambient 1}
  }

plane{
 -z,1
  //use curles_1, curles_2 or curles_2
  texture{curles_1}
 }
---%<------%<------
ingo

[ingo] Re: Making Patterns with functions [601 days 8 hours and 34 minutes ago]

Fri, 23 Aug 2024 05:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Over the last 2 days, I've fallen down the mathematical pattern rabbit hole, and
> have been experimenting with all manner of what can be done with a simple
> pigment {function {}}
> statement.
>

Two older ones for your collection. Thing I found on the web years ago:

---%<------%<---
// Persistence of Vision Ray Tracer Scene Description File
// File: contour.pov
// Vers: 3.5
// Desc: contour plots Idea: Eric Weeks
// http://www.physics.emory.edu/~weeks/ideas/tplot.html
// Date: 2003
// Auth: Ingo Janssen

#version 3.5;

#include "gradients.inc"
//https://news.povray.org/povray.binaries.scene-files/message/%3CXnsA9D7C1F3776F3seed7%40news.povray.org%3E/#%3CXnsA9D7
C1F3776F3seed7%40news.povray.org%3E

global_settings {assumed_gamma 1.0}
camera {location <0,0,-25> look_at 0}

#declare Contour = function(x,y,z,A,B,C,D,E,F,I,J,K,L) {
  E*sin(A*sin(I*x)+ B*cos(J*y))+F*cos(C*cos(K*x)+D*sin(L*y))
}

#declare A =1;
#declare B =1;
#declare C =1;
#declare D =1;
#declare E =1;
#declare F =1;

#declare I =1;
#declare J =1;
#declare K =1;
#declare L =1;

#declare Test  = function(Pf){
   (G_smoothstep(Pf,0.1,0.15)-G_smoothstep(Pf,0.15,0.2))
  +(G_smoothstep(Pf,0.4,0.6)-G_smoothstep(Pf,0.7,.9))
};

plane {
  -z, 0
  pigment {
    function{Contour(x,y,z,A,B,C,D,E,F,I,J,K,L)}

    //function{G_Blinn_Wyvill(Contour(x,y,z,A,B,C,D,E,F,I,J,K,L))}

    //function{Test(Contour(x,y,z,A,B,C,D,E,F,I,J,K,L))}

    //function{abs(Contour(x,y,z,A,B,C,D,E,F,I,J,K,L))}

    //sine_wave
    colour_map {
      [0 rgb 0]
      [1 rgb 1]
    }
  }
  finish {ambient 1}
}
---%<------%<---

---%<------%<---
// POV-Ray 3.7
// Ingo
// found on a Japanese site
// +w1280 +h480 +a0.05 +am3 +ac0.90 +r3
#version 3.7;
global_settings{assumed_gamma 1}
#default{ finish{ambient 0 diffuse 1}}
camera {
  orthographic
  location <0,0,1>
  look_at 0
  right x*image_width/image_height
}
#declare PHI = 1.61803399;

// Shuhei Kawachi
// A>0
#declare ShuheiKawachi = function (x,y,z,A,B){
  ((cos(x)*cos(y)+cos((sqrt(A)*x-y)/B)*
  cos((x+sqrt(A)*y)/B)+cos((sqrt(A)*x+y)/B)*
  cos((x-sqrt(A)*y)/B)))/3///6 + 0.5
}


plane{ <0,0,-1>, 0
  texture {
    pigment {
      //function{(ShuheiKawachi(x,y,z,pi,1.5))}
      function{abs(ShuheiKawachi(x,y,z,pi,1.5))}
      sine_wave
      scale 0.02
    }
    finish {ambient 1 diffuse 0}
  }
}
---%<------%<---

ingo

[Bald Eagle] Re: Making Patterns with functions [601 days 12 hours and 34 minutes ago]

Fri, 23 Aug 2024 01:40:00 GMT

I cannot possibly imagine how they came up with this one.

[Bald Eagle] Re: Making Patterns with functions [601 days 13 hours and 39 minutes ago]

Fri, 23 Aug 2024 00:35:00 GMT

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

> I also needed to alter my fmod function, and I still need to add another level
> of select () to fix the doubling of the lines across N=0.

I fixed that, and then added an averaged texture to throw some color into the
mix, and by using both functions and scaling the original pattern, you can see
how one relates to the other.

Bet you can even see the cubes and hexagons hidden in there...

[Bald Eagle] Re: Making Patterns with functions [601 days 15 hours and 4 minutes ago]

Thu, 22 Aug 2024 23:10:00 GMT

I think I was playing around with the AI again, and the simplest function caught
my eye.

Slumbering neurons were roused, and I realized that although I didn't have
access to POV-Ray, I _did_ have access to Desmos.

Graphing cos(x) * sin (y) revealed a very surprising pattern, and I did a little
bit of follow-up development from there.  Subtracting a constant in between 0
and 1 changes the pattern from circles, to squircles, to squares.

So then, I had to transition between simple graphing, and mapping equations to a
plane with functions.  I had a surprisingly difficult time getting the lines to
match the dots at the proper slopes, and I had to introduce fudge factors to get
the lines to accurately match the frequency of the dots.

Blah blah blah - here's the original basic pattern and the triangular grid that
I made based on that.

I also needed to alter my fmod function, and I still need to add another level
of select () to fix the doubling of the lines across N=0.

[Bald Eagle] Re: Making Patterns with functions [602 days 13 hours and 9 minutes ago]

Thu, 22 Aug 2024 01:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > v nice.  I bet it would be "lush" as a woven fabric/cloth.
>
> There's a better one for that, I think - the "Honeycomb" that I found in a
> paper.
> Kinda looks like a "dog bone" wood patch that alternates in directions like a
> checkerboard.

Sometimes these things are a little easier to write using some helper functions.

#declare S2P = function (V) {sin (tau*V/L)}
#declare C2P = function (V) {cos (tau*V/L)}
#declare T = 0.5;
#declare N = 1;
#declare Honeycomb = function (X, Y, Z) {pow(S2P(X)*C2P(Z) + S2P(Z) + C2P(X), N)
- pow(T, N)}

[Bald Eagle] Re: Making Patterns with functions [604 days 1 hour and 59 minutes ago]

Tue, 20 Aug 2024 12:15:00 GMT

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

> v nice.  I bet it would be "lush" as a woven fabric/cloth.

There's a better one for that, I think - the "Honeycomb" that I found in a
paper.
Kinda looks like a "dog bone" wood patch that alternates in directions like a
checkerboard.

A lot of these are, incidentally, used for support-fill for 3D printing
applications - so Kenneth may have a very practical interest.

Since they can partition space into 2 parts acting as a membrane in between,
when they are given thickness and made of metal, they are being evaluated as
heat-transfer devices, very much like a car radiator works.
The key factor being the very high surface area able to be contained in a very
small space.

> (light-green with envy :-))

You shouldn't be.  You can copy-paste equations as well as I can.  :P

- BW

[jr] Re: Making Patterns with functions [604 days 8 hours and 34 minutes ago]

Tue, 20 Aug 2024 05:40:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> plane - pigment {function {TPMS}}

v nice.  I bet it would be "lush" as a woven fabric/cloth.

(light-green with envy :-))


regards, jr.

[Bald Eagle] Re: Making Patterns with functions [604 days 14 hours and 29 minutes ago]

Mon, 19 Aug 2024 23:45:00 GMT

Triply Periodic Minimal Surface

left - open
right - closed
plane - pigment {function {TPMS}}

This one is called "SplitP"

[Bald Eagle] Dupin cyclide by inversion [621 days 13 hours and 59 minutes ago]

Sat, 3 Aug 2024 00:15:00 GMT

So, I was exploring various ideas, and came back around to my Dupin cyclide work
(with much help from Jerome Grimbert).

Now that I have a better understanding of inversion through a sphere, and some
working code to make that happen, I wanted to make further progress on
parameterizing the process so that given any two 3D points, a Dupin cyclide
would pass through those two points, with exactly specified cross-sectional
circle radii.

http://news.povray.org/povray.binaries.images/thread/%3C591b0d34%40news.povray.org%3E/

I have the "forward inversion" working well - turning a torus into a cyclide.

I can calculate the centers and radii of the cross-sectional circles, and verify
that the calculated cyclide's center is equidistant from those two centers.

Now I just need to reverse-engineer all of that to create the appropriate torus
from the design parameters of the cyclide.  Then when that gets inverted through
the sphere, I get the desired cyclide.  I might also be able to do this using a
cylinder or a cone.

One thing I did notice while doing development was that I was unable to
(consistently) properly render a torus using an isosurface of the equation
#declare Torus = function (X, Y, Z, R, r) {pow (sqrt((pow(X,2)+pow(Y,2)) - R),
2) + pow (Z,2) - pow (r,2)}
And the result changed when I simply included the grid-textured plane!  :O

So something is amiss there.

One thing of note:  I initially was trying to invert the coordinates fed into
the isosurface, but that obviously won;t work, because what I actually need to
do is invert the surface coordinates where the function equals zero.

Maybe there's still some tricky way to get that to work, but using parametric
equations and making a mesh was easier and faster.

Also of note (again) - the Dupin cyclide function in functions.inc actually
works by inverting a torus!  :O

#declare f_dupin_cyclid = function { internal(16) }
// Parameters: x, y, z
    // Six extra parameters required:
    // 1. Field Strength
    // 2. Major radius of torus
    // 3. Minor radius of torus
    // 4. X displacement of torus
    // 5. Y displacement of torus
    // 6. Radius of inversion

- BE

[Bald Eagle] Re: Pappus Chain [622 days 21 hours and 54 minutes ago]

Thu, 1 Aug 2024 16:20:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:
> In my opinion, a special case was still missing here...
>
> Blue is an osculatory sphere packing with an asymmetric start
> configuration, red is a classical apollonian sphere packing with a
> symmetric start configuration.
>
> Best regards,
> MIchael

https://www.josleys.com/articles/Sphere_inversion_Article.pdf

[Bald Eagle] Re: Pappus Chain [627 days 21 hours and 49 minutes ago]

Sat, 27 Jul 2024 16:25:00 GMT

I plugged a prompt into the AI at work, just to see what sort of quality the
code and algorithms the thing spit out - and they're not all that terrible.

So I got some Ford Circles worked out (not using inversion).


Now, even this small experiment taught me some things.

spherical warp requires "orientation" and "dist_exp" to work properly,
especially as an interior_texture - otherwise you just get bad results.


And somehow, there may be a bug somewhere, or I'm just picking up some oddity in
the way the scene elements interact with each other - because I'm getting odd
"checkering" on that left-hand large sphere.   The crackle normal gets
flattened/canceled out.

If I remove the large, enclosing checkered sphere, it goes away.

Enjoy.

// ------------------------------------------------------------------------


#version 3.8;
global_settings {
 assumed_gamma 1.0
}
//#default {finish {emission 1}}
#declare E = 0.00001;

camera {
 location <0.5, 0.5, -1.75>
 right x*image_width/image_height
 up y
 look_at <0.5, 0.5, 0>
}

//sky_sphere {pigment {rgb 1}}
#declare BW = pigment_map
{
 [0 rgb 0]
 [1 rgb 1]
}

sphere {0, 1000 texture {pigment {checker rgb 0 rgb 1 scale x*0.5 warp
{spherical orientation y dist_exp 0.75} scale 1 }} } //interior_texture {pigment
{checker  scale 1 }} }

light_source {<5, 5, -50> rgb 1}

#declare Line = 0.001;

#declare Seed1 = seed (123);
#declare Seed2 = seed (456123);
#declare Seed3 = seed (456123789);

#macro FordCircle (p, q, mode)
 #local R1 = rand (Seed1);
 #local R2 = rand (Seed2);
 #local R3 = rand (Seed3);
 #local Color = <R1, R2, R3>;

 #local Radius = 1 / (2*pow(q,2));
 #local Center = <p/q, Radius, 0>;

 #switch (mode)
 #case (0)
  torus {Radius, Line pigment {rgb y} rotate x*90 translate Center}
  torus {Radius, Line pigment {rgb y} rotate x*90 translate <1, -1, 1>*Center
translate y*1}
 #break
 #case (1)
  disc {Center, z, Radius, 0 pigment {rgb Color}}
  disc {Center, z, Radius, 0 pigment {rgb Color} translate <0, 1-Radius*2, 0>}
 #break
 #case (2)
  sphere {Center, Radius texture {pigment {rgb Color} normal {crackle scale 0.01
bump_size 2} finish {specular 0.4}} }
  sphere {Center, Radius texture {pigment {rgb Color} normal {crackle scale
0.01} finish {specular 0.4}} translate <0, 1-Radius*2, 0>}
 #break
 #end
#end

#macro gcd (a, b)
 #if (b = 0)
  #local Result = a;
 #else
  #local Result = gcd (b, mod (a, b));
 #end
 Result
#end

#declare max_q = 10;

#for (q, 1, max_q)
 #for (p, 0, q)
  #if (gcd (p, q) = 1)
   FordCircle (p, q, 2)
  #end
 #end
#end

[Bald Eagle] Re: Pappus Chain [627 days 21 hours and 59 minutes ago]

Sat, 27 Jul 2024 16:15:00 GMT

MichaelJF <fri### [at] t-onlinede> wrote:
> In my opinion, a special case was still missing here...
>
> Blue is an osculatory sphere packing with an asymmetric start
> configuration, red is a classical apollonian sphere packing with a
> symmetric start configuration.
>
> Best regards,
> MIchael

Yes, eventually we had to do the 3D version!
I had some papers on my pile (Well, _one_ of my piles) related to this.

How much more difficult was it to do the spherical space-filling version?

I'm also curious if this can be massaged into a macro that is capable of filling
any given arbitrary shape.

Then we could use it to build stone walls, layered geologic strata, sandstone
sculptures, etc.

Do a test scene with smooth spheres, and then enhance it by replacing them all
with isosurface rocks, pebbles, and sand.

A bowl of grapes.   That sort of thing.   :)

Excellent work - you ought to be proud.

- BW

[kurtz le pirate] Re: Pappus Chain [629 days 7 hours and 35 minutes ago]

Fri, 26 Jul 2024 06:38:48 GMT

On 24/07/2024 20:31, MichaelJF wrote:
> In my opinion, a special case was still missing here...
> 
> Blue is an osculatory sphere packing with an asymmetric start 
> configuration, red is a classical apollonian sphere packing with a 
> symmetric start configuration.
> 
> Best regards,
> MIchael
> 

Waouh ! I'm always amazed by these kind of images.

Personally, I've never really understood the transition from plane work
to sphere work.


Excellent



-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Gauss-Laguerre quadrature [629 days 13 hours and 44 minutes ago]

Fri, 26 Jul 2024 00:30:00 GMT

I somehow got off on a tangent graphing some orthogonal polynomials, and then
went the rest of the way and implemented the Gauss-Laguerre integration method.

Amazingly, it "works", and I get a ballpark answer for all of the equations that
I've found exact answers for the integrations - however I feel like I ought to
be getting far more accurate answers.  Like, to 6 decimal places or more.

https://thoughts-on-coding.com/2019/04/25/numerical-methods-in-cpp-part-2-gauss-legendre-integration/

Using Laguerre polynomial level 5

Integral of (5/(pow(e, pi)-2)) * exp(2*_X) * cos(_X) dx      from: [0.000] to:
[1.571]      = 0.9914612      Actual answer = 1.0000000

Integral of pow(x,2) + 1 dx      from: [0.000] to: [2.000]      = 4.6207326
Actual answer = 4.6666667

Integral of pow(x,2) + pow(x,-2) dx      from: [1.000] to: [2.000]      =
2.8064163      Actual answer = 2.8333333

Integral of 6*pow(x,2) - 5*x + 2 dx      from: [-3.000] to: [1.000]      =
83.1007807      Actual answer = 84.0000000

Integral of sqrt (x) * (x-2) dx      from: [4.000] to: [0.000]      = -2.0968530
     Actual answer = 2.1333333

Integral of (2*pow(x,5) - x + 3) / pow(x,2) dx      from: [1.000] to: [2.000]
  = 8.2261864      Actual answer = 8.3068528

Integral of 4*x - 6*pow(pow(x,2), 1/3) dx      from: [0.000] to: [1.000]      =
-1.5870838      Actual answer = -1.6000000

Integral of 2*sin(x) - 5*cos(x) dx      from: [0.000] to: [1.047]      =
-3.2996419      Actual answer = -3.3301270

Integral of 3/exp(-x) - 1/3*x dx      from: [-20.000] to: [-1.000]      =
2.0601572      Actual answer = 2.1022157

Integral of abs(3x-5) dx      from: [0.000] to: [3.000]      = 6.7223530
Actual answer = 6.8333333

Integral of 4*pow(x,4) - pow(x,2) + 1 dx      from: [-2.000] to: [2.000]      =
41.3601713      Actual answer = 49.8666667

[MichaelJF] Re: Pappus Chain [630 days 19 hours and 42 minutes ago]

Wed, 24 Jul 2024 18:31:53 GMT

In my opinion, a special case was still missing here...

Blue is an osculatory sphere packing with an asymmetric start 
configuration, red is a classical apollonian sphere packing with a 
symmetric start configuration.

Best regards,
MIchael

[jr] Re: Gaussian 2F1 Hypergeometric function [659 days 22 hours and 19 minutes ago]

Tue, 25 Jun 2024 15:55:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 2nd update:
> ...
> The shapes are triangular, but they have that weird wiggle.

maybe it's just me, but I think the "wiggle" makes all the difference.  (think
"serendipity" </grin>)


regards, jr.

[Bald Eagle] Re: Gaussian 2F1 Hypergeometric function [661 days 13 hours and 49 minutes ago]

Mon, 24 Jun 2024 00:25:00 GMT

2nd update:

I hacked my way through the 500+ lines of code, and left a trail of debugging
statements and "fixes".

zw is a complex variable that gets used but never assigned a value.   :|
Psi is a function that gets called, but the return value is never used.
Converting all of the #locals to #declares in the entire file doesn't alter any
global variables when Psi is called.
The argument to a certain Gamma function always winds up being negative, and
Gamma doesn't take negative arguments.

I tracked my values and finally restricted everything to +/- 10, and got 3
radial lines - - - that I recognized when implementing a "cheap" little gamma
approximation.

https://cplusplus.com/forum/general/255896/#msg1120994

So, having absorbed more know-how and with the necessary macros in hand, I
slightly altered it to take a complex Z argument, and got the same pattern.
Then I added a lot more points, and got my triangles!
Mostly.

The shapes are triangular, but they have that weird wiggle.

Anyway, it's a heck of a lot farther than I thought I'd make it for a weekend of
coding.

- BE

[Bald Eagle] Re: Gaussian 2F1 Hypergeometric function [661 days 20 hours and 39 minutes ago]

Sun, 23 Jun 2024 17:35:00 GMT

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

> Hey, at least it's not Fortran IV.

I don't recall seeing any of that - what year was that?

The last thing I tried to convert was Fortran90,  This, I believe is Fortran77.

> Although, DO WHILE was already part of the Fortran standard when this
> code was written, so I'm a little surprised to see GO TO in there.

Update:
Although we've played a bit recently with some complex number math with regard
to the Apollonian gasket, I needed quite a few more functions to do everything
required for this algorithm.  So I now have 19 macros to do +, -, *, /, ^, =, as
well as mixed complex / real operations, and stuff like conjugate, abs, log,
sqrt, and argument.

The macro runs from lines 517 to 1044, and although Fortran had inbuilt complex
number handling back in 1977, we don't have that in POV-Ray (yet).  So I had to
go through and replace all of the simple / naive operators with a few extra
lines of code calling the aforementioned complex number macros.

I still have to pick through to make sure my indenting is correct (all of the
#end directives ought to be intact, though not properly indent-aligned) and then
code my way out of the handful of GO TO statements.

Then I'll probably "just" need to clean up some floating mixed-number type
operations and whatever else trips the parser.

Then I can see if it does anything proper and useful.

I do believe that all of this somehow started with some of the mathematical
greats trying to compute the perimeter of an ellipse.  Which gave us elliptic
integrals, and then elliptic functions, and then hypergeometric functions....

- BE

[Cousin Ricky] Re: Gaussian 2F1 Hypergeometric function [661 days 21 hours and 44 minutes ago]

Sun, 23 Jun 2024 16:29:40 GMT

On 2024-06-22 20:37 (-4), Bald Eagle wrote:
> 
> Oh, the forgotten joys of porting ancient FORTRAN code to SDL.
> 
> "go to 10"   (ouch.)
> 
> I feel like I'm 12 years old using a school TRS-80 again.
> 
> 
> It will be a minor miracle if I can get this to work in the next week.

Hey, at least it's not Fortran IV.

Although, DO WHILE was already part of the Fortran standard when this
code was written, so I'm a little surprised to see GO TO in there.

[Bald Eagle] Gaussian 2F1 Hypergeometric function [662 days 13 hours and 34 minutes ago]

Sun, 23 Jun 2024 00:40:00 GMT

Oh, the forgotten joys of porting ancient FORTRAN code to SDL.

"go to 10"   (ouch.)

I feel like I'm 12 years old using a school TRS-80 again.


It will be a minor miracle if I can get this to work in the next week.

[Bald Eagle] Re: Pappus Chain [664 days 17 hours and 59 minutes ago]

Thu, 20 Jun 2024 20:15:00 GMT

Any python coders capable of converting this to SDL?

https://people.sc.fsu.edu/~jburkardt/py_src/hyper_2f1/hyper_2f1.py

#! /usr/bin/env python3
#
def hyper_2f1_test ( ):

#*****************************************************************************80
#
## hyper_2f1_test() tests hyper_2f1().
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    21 December 2023
#
#  Author:
#
#    John Burkardt
#
  import platform

  print ( '' )
  print ( 'hyper_2f1_test():' )
  print ( '  Python version: %s' % ( platform.python_version ( ) ) )
  print ( '  Test hyper_2f1().' )

  hyper_2f1_real_test ( )
  hyper_2f1_complex_test ( )
#
#  Terminate.
#
  print ( '' )
  print ( 'hyper_2f1_test():' )
  print ( '  Normal end of execution.' )
  return

def hyper_2f1 ( a, b, c, x ):

#*****************************************************************************80
#
## hyper_2f1() evaluates the hypergeometric 2F1 function.
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    21 December 2023
#
#  Author:
#
#    John Burkardt
#
#  Input:
#
#    real A, B, C: the parameters.
#
#    real or complex X: the argument.
#
#  Output:
#
#    real or complex F: the value of the function.
#
  from scipy.special import hyp2f1

  f = hyp2f1 ( a, b, c, x )

  return f

def hyper_2f1_real_values ( n_data ):

#*****************************************************************************80
#
## hyper_2f1_real_values() returns some values of the hypergeometric 2F1
function.
#
#  Discussion:
#
#    In Mathematica, the function can be evaluated by:
#
#      fx = Hypergeometric2F1 [ a, b, c, x ]
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    13 February 2015
#
#  Author:
#
#    John Burkardt
#
#  Reference:
#
#    Milton Abramowitz, Irene Stegun,
#    Handbook of Mathematical Functions,
#    National Bureau of Standards, 1964,
#    ISBN: 0-486-61272-4,
#    LC: QA47.A34.
#
#    Shanjie Zhang, Jianming Jin,
#    Computation of Special Functions,
#    Wiley, 1996,
#    ISBN: 0-471-11963-6,
#    LC: QA351.C45
#
#    Stephen Wolfram,
#    The Mathematica Book,
#    Fourth Edition,
#    Cambridge University Press, 1999,
#    ISBN: 0-521-64314-7,
#    LC: QA76.95.W65.
#
#    Daniel Zwillinger, editor,
#    CRC Standard Mathematical Tables and Formulae,
#    30th Edition,
#    CRC Press, 1996,
#    ISBN: 0-8493-2479-3,
#    LC: QA47.M315.
#
#  Input:
#
#    integer n_data.  The user sets n_data to 0 before the first call.
#
#  Output:
#
#    integer n_data.  On each call, the routine increments n_data by 1, and
#    returns the corresponding data; when there is no more data, the
#    output value of n_data will be 0 again.
#
#    real A, B, C, X, the parameters.
#
#    real F, the value of the function.
#
  import numpy as np

  n_max = 24

  a_vec = np.array ( ( \
   -2.5, \
   -0.5, \
    0.5, \
    2.5, \
   -2.5, \
   -0.5, \
    0.5, \
    2.5, \
   -2.5, \
   -0.5, \
    0.5, \
    2.5, \
    3.3, \
    1.1, \
    1.1, \
    3.3, \
    3.3, \
    1.1, \
    1.1, \
    3.3, \
    3.3, \
    1.1, \
    1.1, \
    3.3 ))

  b_vec = np.array ( ( \
    3.3, \
    1.1, \
    1.1, \
    3.3, \
    3.3, \
    1.1, \
    1.1, \
    3.3, \
    3.3, \
    1.1, \
    1.1, \
    3.3, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7 ))

  c_vec = np.array ( ( \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
    6.7, \
   -5.5, \
   -0.5, \
    0.5, \
    4.5, \
   -5.5, \
   -0.5, \
    0.5, \
    4.5, \
   -5.5, \
   -0.5, \
    0.5, \
    4.5 ))

  f_vec = np.array ( ( \
    0.72356129348997784913, \
    0.97911109345277961340, \
    1.0216578140088564160, \
    1.4051563200112126405, \
    0.46961431639821611095, \
    0.95296194977446325454, \
    1.0512814213947987916, \
    2.3999062904777858999, \
    0.29106095928414718320, \
    0.92536967910373175753, \
    1.0865504094806997287, \
    5.7381565526189046578, \
    15090.669748704606754, \
   -104.31170067364349677, \
    21.175050707768812938, \
    4.1946915819031922850, \
    1.0170777974048815592E+10, \
   -24708.635322489155868, \
    1372.2304548384989560, \
    58.092728706394652211, \
    5.8682087615124176162E+18, \
   -4.4635010147295996680E+08, \
    5.3835057561295731310E+06, \
    20396.913776019659426 ))

  x_vec = np.array ( ( \
    0.25, \
    0.25, \
    0.25, \
    0.25, \
    0.55, \
    0.55, \
    0.55, \
    0.55, \
    0.85, \
    0.85, \
    0.85, \
    0.85, \
    0.25, \
    0.25, \
    0.25, \
    0.25, \
    0.55, \
    0.55, \
    0.55, \
    0.55, \
    0.85, \
    0.85, \
    0.85, \
    0.85 ))

  if ( n_data < 0 ):
    n_data = 0

  if ( n_max <= n_data ):
    n_data = 0
    a = 0
    b = 0
    c = 0.0
    x = 0.0
    f = 0.0
  else:
    a = a_vec[n_data]
    b = b_vec[n_data]
    c = c_vec[n_data]
    x = x_vec[n_data]
    f = f_vec[n_data]
    n_data = n_data + 1

  return n_data, a, b, c, x, f

def hyper_2f1_real_test ( ):

#*****************************************************************************80
#
## hyper_2f1_real_test() tests hyper_2f1() for real arguments.
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    21 December 2023
#
#  Author:
#
#    John Burkardt
#
  print ( '' )
  print ( 'hyper_2f1_real_test():' )
  print ( '  hyper_2f1() evaluates the hypergeometric function 2F1(A,B,C;X)' )
  print ( '  Check the computation for real arguments X.' )

  n_data = 0

  while ( True ):

    n_data, a, b, c, x, f1 = hyper_2f1_real_values ( n_data )

    if ( n_data == 0 ):
      break

    f2 = hyper_2f1 ( a, b, c, x )

    print ( '' )
    print ( '  (a,b,c,x):   %4d  %4d  %12f  %12f' % ( a, b, c, x ) )
    print ( '  (exact):     %24.16g' % ( f1 ) )
    print ( '  (computed):  %24.16g' % ( f2 ) )
    print ( '  (error):     %24.16g' % ( abs ( f1 - f2 ) ) )

  return

def hyper_2f1_complex_values ( n_data ):

#*****************************************************************************80
#
## hyper_2f1_complex_values() returns some values of the hypergeometric 2F1
function.
#
#  Discussion:
#
#    In Mathematica, the function can be evaluated by:
#
#      fz = Hypergeometric2F1 [ a, b, c, z ]
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    19 December 2023
#
#  Author:
#
#    John Burkardt
#
#  Reference:
#
#    Shanjie Zhang, Jianming Jin,
#    Computation of Special Functions,
#    Wiley, 1996,
#    ISBN: 0-471-11963-6,
#    LC: QA351.C45
#
#  Input:
#
#    integer n_data.  The user sets n_data to 0 before the first call.
#
#  Output:
#
#    integer n_data.  On each call, the routine increments n_data by 1, and
#    returns the corresponding data; when there is no more data, the
#    output value of n_data will be 0 again.
#
#    real A, B, C: the parameters.
#
#    complex Z: the argument.
#
#    complex FZ: the value of the function.
#
  import numpy as np

  n_max = 15

  a_vec = np.array ( ( \
    3.2, \
    3.2, \
   -5.0, \
    3.3, \
   -7.0, \
    4.3, \
    3.3, \
    3.5, \
    3.3, \
    7.0, \
    5.0, \
    3.5, \
    2.1, \
    8.7, \
    8.7 ))

  b_vec = np.array ( ( \
   1.8, \
  -1.8, \
   3.3, \
  -6.0, \
   3.3, \
  -8.0, \
   5.8, \
  -2.4, \
   4.3, \
   5.0, \
   7.0, \
   1.2, \
   5.4, \
   3.2, \
   2.7 ))

  c_vec = np.array ( ( \
   6.7, \
   6.7, \
   6.7, \
   3.7, \
  -3.7, \
  -3.7, \
   6.7, \
   6.7, \
   6.7, \
   4.1, \
   4.1, \
   9.7, \
   9.7, \
   6.7, \
   6.7 ))

  fz_vec = np.array ( ( \
    5.468999154361234+0.00000000j, \
    0.3375063477462785+0.00000000j, \
    116.8274991533609+603.8909562709345j, \
    17620.41819334182+38293.80901310932j, \
   -11772775115.27448-14382285977.20268j, \
    1316118577866.058-101298889382.4362j, \
    1.733055678355656+0.6340102904953357j, \
    0.6476224071999852-0.5211050690999773j, \
   -1.483008322270093+8.374426179451589j, \
   -0.004037609523971226-0.002956632645480181j, \
   -0.004037609523971226-0.002956632645480181j, \
    1.034313610729953+0.5447389238499308j, \
    0.6885043978280027+1.227418679098749j, \
   -0.9004649679297319-1.11988994714304j, \
   -0.4608388640599718-0.5457569650549665j ))

  z_vec = np.array ( ( \
   1.0+0.0j, \
   1.0+0.0j, \
   5.2+4.8j, \
   5.2-4.8j, \
   5.2-4.8j, \
   5.2+4.8j, \
   0.2+0.1j, \
   0.2+0.5j, \
   0.8+0.3j, \
   3.0-1.0j, \
   3.0-1.0j, \
   0.6+0.9j, \
   0.5+0.7j, \
   0.5+0.7j, \
   0.6+0.9j ))

  if ( n_data < 0 ):
    n_data = 0

  if ( n_max <= n_data ):
    n_data = 0
    a = 0
    b = 0
    c = 0.0
    z = 0.0
    fz = 0.0
  else:
    a = a_vec[n_data]
    b = b_vec[n_data]
    c = c_vec[n_data]
    z = z_vec[n_data]
    fz = fz_vec[n_data]
    n_data = n_data + 1

  return n_data, a, b, c, z, fz

def hyper_2f1_complex_test ( ):

#*****************************************************************************80
#
## hyper_2f1_complex_test() tests hyper_2f1() for complex arguments.
#
#  Licensing:
#
#    This code is distributed under the MIT license.
#
#  Modified:
#
#    21 December 2023
#
#  Author:
#
#    John Burkardt

[ remainder of message truncated in this digest view due to length ]

[Bald Eagle] Re: Pappus Chain [665 days 2 hours and 59 minutes ago]

Thu, 20 Jun 2024 11:15:00 GMT

And of course we needed so good old fashioned crop circles.
(WIP)

[Bald Eagle] Re: Pappus Chain [666 days and 19 minutes ago]

Wed, 19 Jun 2024 13:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just posting this here for reference.
>
> https://www.johndcook.com/blog/2023/12/19/conformal-map-disk-triangle/
>
> Would be cool to apply this to the gasket to see what pops out - probably a
> Sierpinski Triangle.
>
> Search: conformal mapping of circle to a triangle
>
> - BE

https://www.mathworks.com/matlabcentral/fileexchange/35008-generation-of-random-variates

https://www.mathworks.com/matlabcentral/fileexchange/1844-gaussian-hypergeometric-function

function z=hypergeometric2f1(a,b,c,x,n)
% HYPERGEOMETRIC2F1 Computes the hypergeometric function
% using a series expansion:
%
%    f(a,b;c;x)=
%
%    1 + [ab/1!c]x + [a(a+1)b(b+1)/2!c(c+1)]x^2 +
%    [a(a+1)(a+2)b(b+1)(b+2)/3!c(c+1)(c+2)]x^3 + ...
%
% The series is expanded to n terms
%
% This function solves the Gaussian Hypergeometric Differential Equation:
%
%     x(1-x)y'' + {c-(a+b+1)x}y' - aby = 0
%
% The Hypergeometric function converges only for:
% |x| < 1
% c != 0, -1, -2, -3, ...
%
%
% Comments to:
% Diego Garcia   - d.g### [at] ieeeorg
% Chuck Mongiovi - mon### [at] fastnet
% June 14, 2002
if nargin ~= 5
    error('Usage: hypergeometric2f1(a,b,c,x,n) --> Wrong number of arguments')
end
if (n <= 0 | n ~= floor(n))
    error('Usage: hypergeometric2f1(a,b,c,x,n) --> n has to be a positive
integer')
end
if (abs(x) > 1)
    error('Usage: hypergeometric2f1(a,b,c,x,n) --> |x| has to be less than 1')
end
if (c <= 0 & c == floor(c))
    error('Usage: hypergeometric2f1(a,b,c,x,n) --> c != 0, -1, -2, -3, ...')
end
z = 0;
m = 0;
while (m<n)
    if (m == 0)
        delta = 1;
    else
        delta = delta .* x .* (a + (m - 1)) .* (b + (m-1)) ./ m ./ (c + (m-1));
   end
   z = z + delta;
   m = m + 1;
end

[William F Pokorny] Re: Pappus Chain [666 days and 37 minutes ago]

Wed, 19 Jun 2024 13:36:14 GMT

On 6/19/24 09:17, Bald Eagle wrote:
> MichaelJF <fri### [at] t-onlinede> wrote:
> 
>> somewhat crazy, but very interesting;)
> 
> Aw, thanks Michael!
> 
> But what about the render?    :D
> 

You have too much free times... :-) Very cool.

Bill P.

[Bald Eagle] Re: Pappus Chain [666 days and 54 minutes ago]

Wed, 19 Jun 2024 13:20:00 GMT

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

> somewhat crazy, but very interesting;)

Aw, thanks Michael!

But what about the render?    :D

[MichaelJF] Re: Pappus Chain [666 days 2 hours and 24 minutes ago]

Wed, 19 Jun 2024 11:49:27 GMT

Am 19.06.2024 um 02:36 schrieb Bald Eagle:
> Now with lenses!
somewhat crazy, but very interesting;)

Best regards
Michael

[Bald Eagle] Re: Pappus Chain [666 days 13 hours and 34 minutes ago]

Wed, 19 Jun 2024 00:40:00 GMT

Now with lenses!

[Bald Eagle] Re: Pappus Chain [666 days 18 hours and 9 minutes ago]

Tue, 18 Jun 2024 20:05:00 GMT

Just posting this here for reference.

https://www.johndcook.com/blog/2023/12/19/conformal-map-disk-triangle/

Would be cool to apply this to the gasket to see what pops out - probably a
Sierpinski Triangle.

Search: conformal mapping of circle to a triangle

- BE

[kurtz le pirate] Re: Pappus Chain [666 days 22 hours and 45 minutes ago]

Tue, 18 Jun 2024 15:29:05 GMT

On 18/06/2024 00:50, Bald Eagle wrote:
> And of course, because the Appollonian gasket is a foam, . . .
> 
> bubbles!
> 


GREAT Bubbles. Very good job.


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Pappus Chain [666 days 22 hours and 45 minutes ago]

Tue, 18 Jun 2024 15:28:16 GMT

On 17/06/2024 23:49, Bald Eagle wrote:
> Excellent!
> Now that there's some working SDL, I can try to understand where things went off
> the rails, and try to make some variations.

I've updated my page and published the code (at the very bottom).
<http://louisbel.free.fr/scenes/scene038.shtml>

Sorry, still in French
-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Pappus Chain [667 days 14 hours and 9 minutes ago]

Tue, 18 Jun 2024 00:05:00 GMT

and with a nested gasket, we could do a sort of Sierpinski triangle.

There's some kind of transformation that makes them isomorphic.

[Bald Eagle] Re: Pappus Chain [667 days 15 hours and 19 minutes ago]

Mon, 17 Jun 2024 22:55:00 GMT

And of course, because the Appollonian gasket is a foam, . . .

bubbles!

[Bald Eagle] Re: Pappus Chain [667 days 15 hours and 39 minutes ago]

Mon, 17 Jun 2024 22:35:00 GMT

And


#macro DrawCircle (C, PigmNr)

 //#debug concat( "C = ", vstr(3, C, ", ", 0, 3), " \n")
 //torus {abs(C.z), Line texture {pigment {colour Colours[PigmNr]} finish
{emission 1}} rotate x*90 translate <C.x, C.y, 0>}
 #if (C.z > 0 & C.z < 0.6)
 sphere {0, abs(C.z) scale <1, 1, 1+pow(abs(C.z), 0.001)> texture {pigment
{colour Colours[PigmNr]} finish {specular 0.4}} translate <C.x, C.y, 0>}
 #end
#end

[Bald Eagle] Re: Pappus Chain [667 days 15 hours and 39 minutes ago]

Mon, 17 Jun 2024 22:35:00 GMT

But for now...

[Bald Eagle] Re: Pappus Chain [667 days 16 hours and 24 minutes ago]

Mon, 17 Jun 2024 21:50:00 GMT

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

> It took me a while to understand this weird javascript recursion and I
> mixed up some - with + or vice versa:

Excellent!
Now that there's some working SDL, I can try to understand where things went off
the rails, and try to make some variations.

Maybe a nested Appolonian gasket, but also one with circles in between 2
straight lines (circles with infinite radius, curvature of zero, resulting in
"Ford circles)

Thanks so much, Michael!

- BW

[MichaelJF] Re: Pappus Chain [667 days 18 hours and 20 minutes ago]

Mon, 17 Jun 2024 19:53:19 GMT

Am 16.06.2024 um 13:44 schrieb Bald Eagle:
> Ugh.
> 
> I tried rewriting from scratch (porting the Javascript code from
> https://en.wikibooks.org/wiki/Fractals/Apollonian_fractals to SDL)
> and I'm still stuck with that upper left hand portion not being right.
> 
> I thought maybe some of the quadratic solution checking in that could would fix
> things, because saving that code as an SVG file and opening it in a browser
> works beautifully (and it's FAST!).
> 
> So, still sitting here with my dunce cap on until I figure out how to wrap my
> head around what's going wrong with the center coordinates and the recursion
> queue.
> 
> - BW
> 
It took me a while to understand this weird javascript recursion and I 
mixed up some - with + or vice versa:

global_settings {assumed_gamma 1.0 }

#include "colors.inc"

#declare S3 = sqrt(3);

#declare M = 3;
#declare C1 = < 1,  0,  1>+M*(x+y);
#declare C2 = <-1,  0,  1>+M*(x+y);
#declare C3 = < 0, S3,  1>+M*(x+y);


camera {
  location M*<0,0,-2.25>//M*<1, S3/2, -2.25>
  right x*image_width/image_height
  up y
  look_at <0,0,0>//M*<1, S3/2, 0>
  //rotate y*15
}
sky_sphere {pigment {rgb 1}}
light_source {< 0, 0, -150> rgb 1}

#declare Line = 0.005;

cylinder {-x*100, x*100, Line pigment {rgb x}}
cylinder {-y*100, y*100, Line pigment {rgb y}}

#declare k4curvature1 = function (k1, k2, k3) {k1 + k2 + k3 + 2 * sqrt 
(k1*k2 +
k2*k3 + k3*k1)}
#declare k4curvature2 = function (k1, k2, k3) {k1 + k2 + k3 - 2 * sqrt 
(k1*k2 +
k2*k3 + k3*k1)}

#macro Re(Z) Z.x #end
#macro Im(Z) Z.y #end
#macro Cmul(z1, z2)
    <Re(z1)*Re(z2) - Im(z1)*Im(z2), Re(z1)*Im(z2) + Im(z1)*Re(z2)>
#end
#macro Cadd(a,b)
    <Re(a)+Re(b),Im(a)+Im(b)>
#end
#macro Csub(a,b)
    <Re(a)-Re(b),Im(a)-Im(b)>
#end

#macro Csqrt (Z)
  #local m = sqrt ( Re(Z)*Re(Z) + Im(Z)*Im(Z) );
  #local Angle = atan2 (Im(Z), Re(Z)) / 2;
  #local NewZ = sqrt(m)*<cos(Angle), sin(Angle)>;
  NewZ
#end
/*#macro Csqrt(Z)
    #local m = sqrt ( Re(Z)*Re(Z) + Im(Z)*Im(Z) );
    <sqrt((m+Re(Z))/2),abs(Im(Z))/Im(Z)*sqrt((m-Re(Z))/2)>
#end*/


#declare Colours=array[7]{Violet,Blue,Cyan,Green,Yellow,Orange,Red}

#macro DrawCircle (C,PigmNr)
    torus {abs(C.z), Line pigment {colour Colours[PigmNr]} rotate x*90 
translate <C.x, C.y, 0>}
#end


/***********************************************
Edit the seed for other circles or run an animation
#declare Zufall=seed(36730+frame_number);
************************************************/

#declare Zufall=seed(36730+17);

// unit circle
#declare b=<0,0,-1>;

// insert two raqndomly positioned touching circles
#declare tr = 1-rand(Zufall)/2;
#declare pa = pi/2 - asin(rand(Zufall)*(1-tr)/tr);
#declare px = tr * cos(pa);
#declare py = tr * sin(pa);
#declare pr = 1 - tr;
#declare qr = (1 - pr) * (1 - cos(pa + pi/2))  / (1 + pr - (1 - pr) 
*cos(pa + pi/2));
#declare qx = 0;
#declare qy = qr - 1;

#declare p=<px,py,pr>;
#declare q=<qx,qy,qr>;

#declare MinRadius=0.1;

#declare MaxDepth=7;

#macro Kiss(a,b,c,initial,Depth)
    #if (Depth <= MaxDepth)
       #local k1 = 1/a.z; // real
       #local z1 = <a.x,a.y>; // complex
       #local kz1 = Cmul(<k1,0>,z1); // complex

       #local k2 = 1/b.z; // real
       #local z2 = <b.x,b.y>; // complex
       #local kz2 = Cmul(<k2,0>,z2); // complex

       #local k3 = 1/c.z; // real
       #local z3 = <c.x,c.y>; // complex
       #local kz3 = Cmul(<k3,0>,z3); // complex

       #local k4p = k1 + k2 + k3 + 2*sqrt(k1*k2 + k2*k3 + k3*k1); // real
       #local k4m = k1 + k2 + k3 - 2*sqrt(k1*k2 + k2*k3 + k3*k1); // real

       #local kz4p = 
Cadd(Cadd(Cadd(kz1,kz2),kz3),Cmul(<2,0>,Csqrt(Cadd(Cadd(Cmul(kz1,kz2),Cmul(kz2,kz3)),Cmul(kz3,kz1)))));

// complex
       #local kz4m = 
Csub(Cadd(Cadd(kz1,kz2),kz3),Cmul(<2,0>,Csqrt(Cadd(Cadd(Cmul(kz1,kz2),Cmul(kz2,kz3)),Cmul(kz3,kz1)))));

// complex

       #if (k4p > k4m)
          #local k4 = k4p; // real
          #local kz4 = kz4p; // complex
          #local k4b = k4m; // real
          #local kz4b = kz4m; // complex
       #else
          #local k4 = k4m; // real
          #local kz4 = kz4m; // complex
          #local k4b = k4p; // real
          #local kz4b = kz4p; // complex
       #end

       #local cc = <kz4.x/k4 , kz4.y/k4 , abs(1/k4)>; // Circle

       #local dx = a.x - cc.x;
       #local dy = a.y - cc.y;
       #local dr = a.z + cc.z;

       #local dtest=abs(dx*dx + dy*dy - dr*dr);

       #if ( abs(dx*dx + dy*dy - dr*dr) > 0.0001 )
          #local cc = <kz4b.x/k4 , kz4b.y/k4 , abs(1/k4)>;
       #end

       #if (initial)
          #local cc=<kz4b.x/k4b,kz4b.y/k4b,abs(1/k4b)>;
       #end

       DrawCircle(cc,mod(Depth,7))

       Kiss(a,b,cc,false,Depth+1)
       Kiss(a,cc,c,false,Depth+1)
       Kiss(cc,b,c,false,Depth+1)
    #end
#end


DrawCircle(b,0)
DrawCircle(p,0)
DrawCircle(q,0)


Kiss(b,p,q,true,1)
Kiss(b,p,q,false,1)

[Bald Eagle] Re: Pappus Chain [669 days 2 hours and 29 minutes ago]

Sun, 16 Jun 2024 11:45:00 GMT

Ugh.

I tried rewriting from scratch (porting the Javascript code from
https://en.wikibooks.org/wiki/Fractals/Apollonian_fractals to SDL)
and I'm still stuck with that upper left hand portion not being right.

I thought maybe some of the quadratic solution checking in that could would fix
things, because saving that code as an SVG file and opening it in a browser
works beautifully (and it's FAST!).

So, still sitting here with my dunce cap on until I figure out how to wrap my
head around what's going wrong with the center coordinates and the recursion
queue.

- BW

[kurtz le pirate] Re: Pappus Chain [670 days 4 hours and 39 minutes ago]

Sat, 15 Jun 2024 09:35:03 GMT

On 12/06/2024 17:52, Bald Eagle wrote:
> I'll bet that would amazing done in glass with caustics.
> Or as stone spheres in a field of grass.
> 

After grass and stones, glass.




-- 
Kurtz le pirate
Compagnie de la Banquise

[yesbird] Re: Pappus Chain [670 days 21 hours and 42 minutes ago]

Fri, 14 Jun 2024 16:31:56 GMT

On 14/06/2024 19:30, yesbird wrote:
> This guy is working on similar things and making interactive toys:
> https://observablehq.com/@esperanc/3d-apollonian-sphere-packings

Also this paper may be of interest:
https://arxiv.org/pdf/1609.03811
--
YB

[yesbird] Re: Pappus Chain [670 days 21 hours and 43 minutes ago]

Fri, 14 Jun 2024 16:30:26 GMT

On 14/06/2024 16:30, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> https://en.wikibooks.org/wiki/Fractals/Apollonian_fractals

This guy is working on similar things and making interactive toys:
https://observablehq.com/@esperanc/3d-apollonian-sphere-packings
--
YB

[kurtz le pirate] Re: Pappus Chain [670 days 22 hours and 41 minutes ago]

Fri, 14 Jun 2024 15:32:43 GMT

A few quick explanations for those interested.
(I'd probably do a page on my site... but I'm so far behind ;) )


I haven't used Bald Eagle's inversion method, which looks very
interesting and promising.


The reference being the WIKIPEDIA page
<https://en.wikipedia.org/wiki/Pappus_chain>



-- The two basic radii :
#declare BigRadius = SIZE; // AB/2
#declare SmallRadius = SIZE*3/4; // AC/2


-- For the first circle (CB):
#declare cx = SmallRadius*2 + BigRadius - SmallRadius;
#declare r = BigRadius - SmallRadius;
DrawCircle(cx, 0, r)


-- Next, a simple loop :
#declare r = SmallRadius/BigRadius;
#declare NthRadius = r;

#declare n = 1;
#while ( NthRadius > MIN_RADIUS )
  #declare divisor = n*n*(1-r)*(1-r)+r;
  #declare xx = 2*BigRadius*r*(1+r)/(2*divisor);
  #declare yy = 2*BigRadius*n*r*(1-r)/divisor;
  #declare NthRadius = 2*BigRadius*r*(1-r)/(2*divisor);

  DrawCircle(xx, +yy, NthRadius)
  DrawCircle(xx, -yy, NthRadius) // symmetrically

  #declare n = n + 1;
#end


The first tests were in 2D. So I made a macro that drew circles :
#macro DrawCircle(X,Y,R,C)
 torus { R, rLine pigment { color C } rotate 90*x translate <X,Y,0> }
#end


Transformed for 3d :
#macro DrawCircle(X,Y,R,C)
 sphere { <X,R,Y>, R pigment { color C } }
#end



A yes, I forgot! The end of the loop is controlled by the constancy
MIN_RADIUS. If the radius is "too" small, we stop.

#declare MIN_RADIUS = 0.50; for the stone spheres





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Pappus Chain [671 days and 39 minutes ago]

Fri, 14 Jun 2024 13:35:00 GMT

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

> I recall in one of the sites that I stumbled across, there was a method for
> calculating how many circles there were for any given level of recursion.
> That might be a nice addition to the debug stream, as well as warning/sanity
> check before a render is attempted to be started with too high a level of
> recursion for the system it's being run on.

https://en.wikibooks.org/wiki/Fractals/Apollonian_fractals

[Bald Eagle] Re: Pappus Chain [671 days 3 hours and 14 minutes ago]

Fri, 14 Jun 2024 11:00:00 GMT

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

> Well, I got partway there.
> I'm botching _something_ up (as usual).

I almost got it.
Removing one of the circle solutions cleaned up a bunch of unnecessary circles,
but the circles for the top right area are in the wrong place.
I'm wondering if there's some sign or floating point thing going on.

This is 5 levels of recursion.

Minor changes to recursion macro:
(mostly just 2 changes to an array index, restoring them to my initial values)

#macro Gasket (RecursionLevels)
 #for (L, 0, RecursionLevels)
  #local Triplets = dimension_size (Queue, 1)-1;
  #for (T, 0, Triplets)
   DrawCircles (Queue [T])
  #end

  #declare NextQueue = array;
  #local QIndex = 0;
  #for (T, 0, Triplets)
   #local triplet = Queue [T];
   #local c1 = triplet [0];
   #local c2 = triplet [1];
   #local c3 = triplet [2];
   #local k41 = k4curvature1 (1/c1.z, 1/c2.z, 1/c3.z);
   #local k42 = k4curvature2 (1/c1.z, 1/c2.z, 1/c3.z);
   #declare new1 = ComplexDescartes (c1, c2, c3, k41);
   #declare new2 = ComplexDescartes (c1, c2, c3, k42);

   #local T1 = array [3] {c1, c2, new1[0]};
   #local T2 = array [3] {c2, c3, new1[0]};//
   #local T3 = array [3] {c3, c1, new1[0]};//
   #local T4 = array [3] {c1, c2, new2[1]};
   #local T5 = array [3] {c2, c3, new2[1]};
   #local T6 = array [3] {c3, c1, new2[1]};
   //#local T6 = array [3] {c2, c3, new1[1]};

   #declare NextQueue [QIndex] = T1;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T2;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T3;

   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T4;
   //#local QIndex = QIndex + 1;
   //#declare NextQueue [QIndex] = T5;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T6;

  #end // end for T

  #declare Queue = NextQueue;
 #end // end for L
#end

[Bald Eagle] Re: Pappus Chain [671 days 12 hours and 4 minutes ago]

Fri, 14 Jun 2024 02:10:00 GMT

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

> I just started watching Daniel Schiffman's video this morning - I was hoping to
> start writing some code based on it after work.

Well, I got partway there.
I'm botching _something_ up (as usual).

I need to stop blindly hacking and do some more thinking and learning.


#version 3.8;
global_settings {assumed_gamma 1.0 }

#declare S3 = sqrt(3);

#declare M = 3;
#declare C1 = < 1,  0,  1>+M*(x+y);
#declare C2 = <-1,  0,  1>+M*(x+y);
#declare C3 = < 0, S3,  1>+M*(x+y);


camera {
 location M*<1, S3/2, -2.25>
 right x*image_width/image_height
 up y
 look_at M*<1, S3/2, 0>
 //rotate y*15
}
sky_sphere {pigment {rgb 1}}
light_source {< 0, 0, -150> rgb 1}

#declare Line = 0.005;

cylinder {-x*100, x*100, Line pigment {rgb x}}
cylinder {-y*100, y*100, Line pigment {rgb y}}

#declare k4curvature1 = function (k1, k2, k3) {k1 + k2 + k3 + 2 * sqrt (k1*k2 +
k2*k3 + k3*k1)}
#declare k4curvature2 = function (k1, k2, k3) {k1 + k2 + k3 - 2 * sqrt (k1*k2 +
k2*k3 + k3*k1)}



// Make every circle a vector: <Real, Imaginary, Radius>
// Start out with <R, I, 0> to do math, and then tack on radius in last step
// That way add, subtract, and scalar multiplication are all just operations on
a vector

#macro Re(Z) Z.x #end
#macro Im(Z) Z.y #end
#macro Mult(z1, z2) <Re(z1)*Re(z2) - Im(z1)*Im(z2), Re(z1)*Im(z2) +
Im(z1)*Re(z2)> #end

#macro Sqrt (Z)
 #local m = sqrt ( Re(Z)*Re(Z) + Im(Z)*Im(Z) );
 #local Angle = atan2 (Im(Z), Re(Z)) / 2;
 #local NewZ = sqrt(m)*<cos(Angle), sin(Angle)>;
 NewZ
#end

#macro ComplexDescartes (C1, C2, C3, k4)
 // z41 = (z1*k1 + z2*k2 + z3*k3 + 2 * sqrt (z1*k1*z2*k2 + z2*k2*z3*k3 +
z3*k3*z1*k1)) / k4
 // z42 = (z1*k1 + z2*k2 + z3*k3 - 2 * sqrt (z1*k1*z2*k2 + z2*k2*z3*k3 +
z3*k3*z1*k1)) / k4
 #local k1 = 1/C1.z;
 #local k2 = 1/C2.z;
 #local k3 = 1/C3.z;

 #local z1 = <C1.x, C1.y>;
 #local z2 = <C2.x, C2.y>;
 #local z3 = <C3.x, C3.y>;

 #local zk1 = z1*k1;
 #local zk2 = z2*k2;
 #local zk3 = z3*k3;

 #local Sum = zk1 + zk2 + zk3;
 #local Square = Mult (zk1, zk2) + Mult (zk2, zk3) + Mult (zk3, zk1);
 #local Root = Sqrt (Square);

 #local z41 = (Sum + 2*Root) / k4;
 #local z42 = (Sum - 2*Root) / k4;

 #local Z41 = z41 + <0, 0, 1/k4>;
 #local Z42 = z42 + <0, 0, 1/k4>;

 #local Result = array [2] {Z41, Z42};

 Result
#end

#macro Circle (C)
 torus {abs(C.z), Line pigment {rgb 0} rotate x*90 translate <C.x, C.y, 0>}
#end








#declare k41 = k4curvature1 (1/C1.z, 1/C2.z, 1/C3.z);
#declare k42 = k4curvature2 (1/C1.z, 1/C2.z, 1/C3.z);

#declare C41 = ComplexDescartes (C1, C2, C3, k41);
#declare C42 = ComplexDescartes (C1, C2, C3, k42);

#if (0)
Circle (C1)
Circle (C2)
Circle (C3)
Circle (C41[0])
Circle (C42[1])
#end

#macro DrawCircles (Array)
 #local Circles = dimension_size (Array, 1)-1;
 #for (C, 0, Circles)
  Circle (Array [C])
 #end
#end

#declare AllCircles = array;
#declare AllCircles [0] = C1;
#declare AllCircles [1] = C2;
#declare AllCircles [2] = C3;

#declare Queue = array;
#declare Queue [0] = array [3] {C1, C2, C3};

//#declare Queue [0] = C1;
//#declare Queue [1] = C2;
//#declare Queue [2] = C3;

#declare Levels = 3;

#macro Gasket (RecursionLevels)
 #for (L, 0, RecursionLevels)
  #local Triplets = dimension_size (Queue, 1)-1;
  #for (T, 0, Triplets)
   DrawCircles (Queue [T])
  #end

  #declare NextQueue = array;
  #local QIndex = 0;
  #for (T, 0, Triplets)
   #local triplet = Queue [T];
   #local c1 = triplet [0];
   #local c2 = triplet [1];
   #local c3 = triplet [2];
   #local k41 = k4curvature1 (1/c1.z, 1/c2.z, 1/c3.z);
   #local k42 = k4curvature2 (1/c1.z, 1/c2.z, 1/c3.z);
   #declare new1 = ComplexDescartes (c1, c2, c3, k41);
   #declare new2 = ComplexDescartes (c1, c2, c3, k42);

   #local T1 = array [3] {c1, c2, new1[0]};
   #local T2 = array [3] {c2, c3, new1[1]};
   #local T3 = array [3] {c3, c1, new1[1]};
   #local T4 = array [3] {c1, c2, new2[1]};
   #local T5 = array [3] {c2, c3, new2[1]};
   #local T6 = array [3] {c3, c1, new2[1]};
   //#local T6 = array [3] {c2, c3, new1[1]};

   #declare NextQueue [QIndex] = T1;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T2;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T3;

   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T4;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T5;
   #local QIndex = QIndex + 1;
   #declare NextQueue [QIndex] = T6;

  #end // end for T

  #declare Queue = NextQueue;
 #end // end for L
#end

Gasket (Levels)

[William F Pokorny] Re: Pappus Chain [671 days 14 hours and 38 minutes ago]

Thu, 13 Jun 2024 23:35:26 GMT

On 6/13/24 10:17, kurtz le pirate wrote:
> wip here :<http://louisbel.free.fr/scenes/scene038.shtml>

Cool!

Bill P.

[yesbird] Re: Pappus Chain [671 days 20 hours and 30 minutes ago]

Thu, 13 Jun 2024 17:44:05 GMT

On 13/06/2024 17:17, kurtz le pirate wrote:
> I'm working on it too.
> wip here : <http://louisbel.free.fr/scenes/scene038.shtml>

Really nice !
Especially metal-like construction on black.
Also math surfaces in Scenes menu attracted my attention - I love them
also.
--
YB

[Bald Eagle] Re: Pappus Chain [671 days 20 hours and 49 minutes ago]

Thu, 13 Jun 2024 17:25:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> I'm working on it too.
>
> wip here : <http://louisbel.free.fr/scenes/scene038.shtml>
> (in french for the moment)

Very nice.  Excellent work as always!
I see you've been going over the same references as I have.

I just started watching Daniel Schiffman's video this morning - I was hoping to
start writing some code based on it after work.

I'm still amazed that "Beyond the Descartes Circle Theorem" was only published
in 2001!  :O

I recall in one of the sites that I stumbled across, there was a method for
calculating how many circles there were for any given level of recursion.
That might be a nice addition to the debug stream, as well as warning/sanity
check before a render is attempted to be started with too high a level of
recursion for the system it's being run on.

It would also be nice to have a few ways to generate the output, so that the
gasket could be further used in a more complex scene.

1. Someone might want the tori to overlap such that the centers of their minor
radii are coincident/tangent, OR they might want the outside surfaces of the
tori to be tangent.

2. The coloration of each level of recursion ought to be able to be specified by
something like an array.  That way different textures and normals, etc can be
applied.  Also, it could then be rendered and subsequently used as a
heightfield.

3. There might be a desire to texture the circles based on their radius, or from
the distance from the center of the outer circle.

I've also found PDF and djvu copies of "Indra's Pearls" on the web, and they
have some very interesting algorithms to render a wide variety of variations on
this theme.

The authors even mention that some madman might be able to do this in Excel -
which is what I'm currently working on, since it's the only tool I have
available during the day.  :D

- BW

[jr] Re: Pappus Chain [671 days 21 hours and 29 minutes ago]

Thu, 13 Jun 2024 16:45:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> wip here : {...}

the "l'image en noir et blanc" does it for me, v nice.


regards, jr.

[kurtz le pirate] Re: Pappus Chain [671 days 23 hours and 3 minutes ago]

Thu, 13 Jun 2024 15:10:29 GMT

On 12/06/2024 17:52, Bald Eagle wrote:

> That's a beauty.
Thanks

> I'll bet that would amazing done in glass with caustics.

Hum.. hum... lot of work.
I have to think about it

> Or as stone spheres in a field of grass.

Easier and faster. First test attached.
Does it match your idea ?


Note :
- Random textures from "stones.inc" without optimization
- Makegrass macro from Gilles Tran


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Pappus Chain [671 days 23 hours and 56 minutes ago]

Thu, 13 Jun 2024 14:17:12 GMT

On 12/06/2024 17:52, Bald Eagle wrote:
> I still need to work out some good code for an Appolonian gasket.
> (Unless you beat me to it  ;)  )



I'm working on it too.

wip here : <http://louisbel.free.fr/scenes/scene038.shtml>
(in french for the moment)





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Pappus Chain [672 days 20 hours and 59 minutes ago]

Wed, 12 Jun 2024 17:15:00 GMT

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

> I'll bet that would amazing done in glass with caustics.

Check out:

https://www.dumas.io/limset3d/

[Bald Eagle] Re: Pappus Chain [672 days 22 hours and 19 minutes ago]

Wed, 12 Jun 2024 15:55:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> On 12/06/2024 03:03, Bald Eagle wrote:
> > Ever inspired by the talented Francesco De Comite, I made a 3D version as a
> > little doodle.
> >
>
> You have contaminated me ;)

You spelled "inspired" wrong.   :P

That's a beauty.
I'll bet that would amazing done in glass with caustics.
Or as stone spheres in a field of grass.

I still need to work out some good code for an Appolonian gasket.
(Unless you beat me to it  ;)  )

- BW

[kurtz le pirate] Re: Pappus Chain [672 days 23 hours and 39 minutes ago]

Wed, 12 Jun 2024 14:34:36 GMT

On 12/06/2024 03:03, Bald Eagle wrote:
> Ever inspired by the talented Francesco De Comite, I made a 3D version as a
> little doodle.
> 

You have contaminated me ;)





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Pappus Chain [673 days 13 hours and 9 minutes ago]

Wed, 12 Jun 2024 01:05:00 GMT

Ever inspired by the talented Francesco De Comite, I made a 3D version as a
little doodle.

[Bald Eagle] Re: Pappus Chain [686 days 12 hours and 19 minutes ago]

Thu, 30 May 2024 01:55:00 GMT

So that's very cool, and I wondered what it would look like if rendered as a
whole sphere, maybe with a glass texture and some sort of variation of the color
- perhaps determined by the Manhattan distance from the center.

I just used a quick, textured box, and the larger the inversion circle, the
smaller / more compact the pattern.   Patterns jump out at different scales.

[Bald Eagle] Appolonian Gasket [686 days 12 hours and 24 minutes ago]

Thu, 30 May 2024 01:50:00 GMT

I was playing with the code found here:

https://gist.github.com/stla/6fcc3ab559d1a9e491a47f1ec6199d3f

And came up with a fun variation.

[William F Pokorny] Re: Pappus Chain [686 days 18 hours and 50 minutes ago]

Wed, 29 May 2024 19:23:51 GMT

On 5/29/24 06:54, Bald Eagle wrote:
> You can invert anything, even whole patterns, like so:

Thanks for posting more detailed code. I played a little - and it's cool 
- though the results kinda twist my head around at times. :-)

Attached is a slice of a sphere to the -z side of the x,y plane where 
the radius of a f_sphere() is getting 'inverted / chopped' with your 
'Checker_Inv()' (I also clamped the maximum Inversion() value to 15). 
The sides sliced at the inversions don't render cleanly with the 
isosurface, but we still end up with an interesting looking shape.

A little surprised it worked as well as it did...

Bill P.

FYI. I did get a few divisions by zero from Inversion() until I added 
some off grid, anti-directional, numerical fuzz to CenterX, CenterY and 
CenterZ. This might be due how my yuqk AA works compared to the 
officially released AA.

[Bald Eagle] Re: Pappus Chain [687 days 3 hours and 19 minutes ago]

Wed, 29 May 2024 10:55:00 GMT

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

> Cool!

Isn't it?

You can invert anything, even whole patterns, like so:

#declare Inversion = function {Radius*Radius / ( pow (x-CenterX, 2) + pow
(y-CenterY, 2) + pow (z-CenterZ, 2))}

#declare Checker_Inv = function {
 Checker (
  x*Inversion (x, y, z),
  y*Inversion (x, y, z),
  z*Inversion (x, y, z)
 ).red
}

plane {z, 0 pigment {function {Checker_Inv (x, y, z)}}}

I was trying to figure out a way to plug this into a matrix transform, but
POV-Ray doesn't allow that kind of thing.

/*
#declare M_Inversion =
function {
 transform {
  matrix <
   Inversion (x, y, z), 0, 0,
   0, Inversion (x, y, z), 0,
   0, 0, Inversion (x, y, z),
   0, 0, 0
  >
 }
}
*/

[William F Pokorny] Re: Pappus Chain [687 days 5 hours and 49 minutes ago]

Wed, 29 May 2024 08:24:33 GMT

On 5/28/24 19:41, Bald Eagle wrote:
> And out pops a Pappus chain.
Cool!

Bill P.

[Bald Eagle] Pappus Chain [687 days 14 hours and 29 minutes ago]

Tue, 28 May 2024 23:45:00 GMT

I threw together this little inversive geometry doodle last night to just make
something fun after a long while.

I might do some Steiner porisms and Appolonian gasket type stuff at some point.
Hoping some hyperbolic geometry on a Poisson disk.

I think a plane-filling Appolonian gasket pattern would be super cool, with an
inversion iteration level as a pattern argument.

Anyway, what's going on here is that things that are defined IN the gray circle,
get inverted to the outside of the circle.  Circles not passing through the
center of the inversion circle stay circles, and circles passing through the
center get inverted to lines (circles of infinite radius).  Tangency is
preserved.

Likewise, objects defined outside of the circle get inverted to the inside of
the gray circle.

The closer things are to the circle, the closer they are inverted, and the
closer they are to the center, the farther away they are, and the center maps to
"a point at infinity".

Rather than doing several pages of Euclidean geometry like Pappus, we use Felix
Klein's inversive geometry to leverage the special properties mentioned above.

We make 2 circles that pass through the center, and so get mapped to lines.
A circle tangent to both of those circles (blue) gets mapped to a circle outside
the inversion circle, and is tangent to the 2 lines from the inverted circles.
Then, since all of the subsequent circles are tangent to both of the circles and
the small circle next to it, they are easily made as circles outside the
inversion circle that are all just stacked circles of the same radius - they are
tangent to both lines and the circles next to them.
So when they get inverted to the inside of the circle, they preserve those
properties of tangency.

And out pops a Pappus chain.  Easy peasy.

- BE

[yesbird] Re: Photon mapping calculation limited to 8 thre... [709 days 22 hours and 56 minutes ago]

Mon, 6 May 2024 15:17:46 GMT

On 06/05/2024 18:05, Alain Martel wrote:
> To the best of my knowledge : Currently, it is not possible to divide 
> that process between several threads. The algorithm used is strictly 
> linear and can't get split between multiple threads.

Thanks, Alan, I will take it into account.
--
YB

[Alain Martel] Re: Photon mapping calculation limited to 8 thre... [709 days 23 hours and 8 minutes ago]

Mon, 6 May 2024 15:05:42 GMT

Le 2024-05-06 Ã  07:54, yesbird a Ã©critÂ :
> Hi, all !
> 
> While rendering large number of images on server with photon mapping
> techniques I discovered, that only 8 kernels are used in time of
> photons calculation step, while on tracing step all 40 kernels are
> loaded.
> 
> Is there a way to use more threads for photon calculation to improve
> performance ?
> 
> Thanks in advance.
> -- 
> YB.
> 
> 
> 
> 
> 
So, you have one light and 8 target objects, or 2 lights and 4 target 
objects, or 4 lights and 2 target objects or 8 lights and 1 target object.

The maximum number of threads used while photon mapping is the product 
of the number of light_source by the number of objects with a target block.
To the best of my knowledge : Currently, it is not possible to divide 
that process between several threads. The algorithm used is strictly 
linear and can't get split between multiple threads.

[yesbird] Photon mapping calculation limited to 8 threads [710 days 2 hours and 19 minutes ago]

Mon, 6 May 2024 11:54:42 GMT

Hi, all !

While rendering large number of images on server with photon mapping
techniques I discovered, that only 8 kernels are used in time of
photons calculation step, while on tracing step all 40 kernels are
loaded.

Is there a way to use more threads for photon calculation to improve
performance ?

Thanks in advance.
--
YB.

[Leroy] Re: Comparing colors specified by byte-value usi... [714 days 19 hours and 59 minutes ago]

Wed, 1 May 2024 18:15:00 GMT

When I was playing with palettes this is  what I use to gather the colors

#declare Imagemap=pigment{image_map{tga "EarthTopography.tga" gamma 1}}
#declare FnA = function {pigment {Imagemap scale<Imagewidth,Imageheight,1>}}

   a&b are integers 0<= a <Imagewidth 0<= b <Imageheight
    #declare FV=FnA(a,b,1);
    #declare C1=int(FV.x*255+.5);//red
    #declare C2=int(FV.y*255+.5);//green
    #declare C3=int(FV.z*255+.5);//blue

 These integers was used to sort colors into a 256 element palette.


  You may notice that I scale the image function very large and that I rounded
up the fraction that the function returned.

Hope this helps.

Have Fun!

[Bald Eagle] Re: Comparing colors specified by byte-value usi... [714 days 20 hours and 39 minutes ago]

Wed, 1 May 2024 17:35:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> I quickly coded a test. The result (of little interest) is attached, but
> I think the problem lies in the precision/tolerance of the calculations.

Yes, that's what I was thinking as well.

> I created this macro, which compares the source color with the chosen
> color, introducing a "tolerance" variable :

That's indeed the kind of thing I was looking for.

> If the color is close to the one defined, I make a higher box:

So you are definitely recognizing the peach color separately from the other
colors.

I'm wondering what it would look like if you took Ricky's advice and expressed
the eval_pigment results as both rgb and srgb-converted values and used those
for your comparison, and output the results to the #debug stream.

(And I still like your HSV idea - I definitely think it's more intuitive and
versatile for how I'll be using color coded information)

- BW

[kurtz le pirate] Re: Comparing colors specified by byte-value usi... [714 days 21 hours and 11 minutes ago]

Wed, 1 May 2024 17:02:40 GMT

On 01/05/2024 16:05, Bald Eagle wrote:

> When I try it with that last peach color, using if(EvalPigmentColor =
> ExcelByteColor/255), it doesn't work.

ok, ok, I understand better the problem.

I quickly coded a test. The result (of little interest) is attached, but
I think the problem lies in the precision/tolerance of the calculations.

I defined the pigment like this (but you know this) :

#declare pigmentSize = 5;
#declare myPigment = pigment {
 image_map {
  png "excel rgb colors"
  map_type 0
  interpolate 2
  }
 scale pigmentSize
 }

The purpose of the test is to give a greater height for pixels whose
color is peach. Several tries and it didn't work.

I created this macro, which compares the source color with the chosen
color, introducing a "tolerance" variable :

#macro CheckColor(thisCol, targetCol, tol)
 ((abs(thisCol.red*255-targetCol.red)<=tol) &
  (abs(thisCol.green*255-targetCol.green)<=tol) &
  (abs(thisCol.blue*255-targetCol.blue)<=tol) )
#end

Two variables:
#declare TargetColor = rgb <248, 203, 173>; // peach color
#declare Tolerance = 16; // this parameter is very very sensitive

In the image constitution, I retrieve the color of the source image:
 #declare myRGB = eval_pigment(myPigment, <xIndex, zIndex, 0>);

If the color is close to the one defined, I make a higher box:
 box {
  <2*xIndex-steep, 0, 2*zIndex-steep>, <2*xIndex + steep,
0.05*(CheckColor(myRGB, TargetColor ,Tolerance)?10:1), 2*zIndex + steep>
 pigment { color myRGB }
 }

This is where the value of the tolerance variable is important !
With value lower than 16 (about 6%) here, there's no higher box.
The code looks bad :(

This "large" tolerance value causes artifacts to appear elsewhere in the
image.

Maybe it's the wrong way...
Can any of this help you?

-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] Re: Comparing colors specified by byte-value usi... [714 days 21 hours and 56 minutes ago]

Wed, 1 May 2024 16:17:26 GMT

On 2024-05-01 10:05 (-4), Bald Eagle wrote:
> 
> So I fill cells in Excel, copy-paste them into IrfanView to make an image file,
> and then POV-Ray looks at those pixels with eval_pigment.
> 
> When I'm looking for specific colors to determine if something is floor, wall,
> door, etc, it's easy to use the 255 or 0 values and just divide by 255.
> 
> When I try it with that last peach color, using if(EvalPigmentColor =
> ExcelByteColor/255), it doesn't work.

I can tell from that last peach color that there is no sRGB conversion
going on.  <248, 203, 173> is the literal byte value of the swatch
encoded as sRGB, and <0.97, 0.8, 0.68> is straight division by 255.  In
POV-Ray, srgb <248, 203, 173> / 255 should give you the same value as
eval_pigment(), which I predict will be rgb <0.939, 0.597, 0.418>.  Try:

#local Tmp = srgb ExcelByteColor/255;
if(EvalPigmentColor = Tmp)

POV-Ray does not provide conversion back to sRGB, but if you need that,
I have some tools at https://github.com/CousinRicky/RC3-POV-Tools

[Bald Eagle] Re: Comparing colors specified by byte-value usi... [715 days and 4 minutes ago]

Wed, 1 May 2024 14:10:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> Not sure i understand your problem, but yes, eval_pigment does return a
> color triplet <red, green, blue> in [0..1] range.

So I fill cells in Excel, copy-paste them into IrfanView to make an image file,
and then POV-Ray looks at those pixels with eval_pigment.

When I'm looking for specific colors to determine if something is floor, wall,
door, etc, it's easy to use the 255 or 0 values and just divide by 255.

When I try it with that last peach color, using if(EvalPigmentColor =
ExcelByteColor/255), it doesn't work.

> An idea for your comparisons: turn your color into HSV.
> - Compare the wanted color with the H value plus/minus intervale (degrees).
> - Reject colors that are below a threshold of S and V.

It's an unwanted extra layer, but a good idea - I think the clarity of doing the
HSV way would simplify things.

Hopefully I'll have some time to try it all out tonight.

Thanks!

- BW

[kurtz le pirate] Re: Comparing colors specified by byte-value usi... [715 days 6 hours and 21 minutes ago]

Wed, 1 May 2024 07:52:18 GMT

On 28/04/2024 15:15, Bald Eagle wrote:

> I have an image that I generate by color-filling M$ Excel cells, and
> copy-pasting that into IrfanView, and saving to .png
> 
> I then want to look at certain colors to determine if it's a walkable path, or
> an obstacle.
> 
> This works well when I specify colors with all 255's or all 0's, but when I have
> intermediate shades, I'm trying to use the <0-255, 0-255, 0-255>/255 value as a
> comparison, but the algorithm is just recognizing it all as unwalkable.
> 
> I'll probably have to go back on run some tests to see what eval_pigment returns
> as an rgb triplet.
> I'm wondering if I'm going to have to have to use srgb.
> I also was thinking about specifying a narrow _range_ of values to give me a
> +/-1 wiggle room in byte values when converted to 0-1, so that'll probably
> involve math.inc and a special use of VEq and a threshold.
> 
> Has anyone ever come across a situation like this?

Not sure i understand your problem, but yes, eval_pigment does return a
color triplet <red, green, blue> in [0..1] range.

An idea for your comparisons: turn your color into HSV.
- Compare the wanted color with the H value plus/minus intervale (degrees).
- Reject colors that are below a threshold of S and V.



IMHO about srgb (and the current discussion in p.b.tutorials) :
This model is useful for calculating the final pixel color value as a
function of object pigment, light and gamma. But not the other way around...




-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Comparing colors specified by byte-value using P... [718 days and 54 minutes ago]

Sun, 28 Apr 2024 13:20:00 GMT

Continuing with the A* pathfinding project,

(AND perhaps the srgb - rgb thread)

I have an image that I generate by color-filling M$ Excel cells, and
copy-pasting that into IrfanView, and saving to .png

I then want to look at certain colors to determine if it's a walkable path, or
an obstacle.

This works well when I specify colors with all 255's or all 0's, but when I have
intermediate shades, I'm trying to use the <0-255, 0-255, 0-255>/255 value as a
comparison, but the algorithm is just recognizing it all as unwalkable.

I'll probably have to go back on run some tests to see what eval_pigment returns
as an rgb triplet.
I'm wondering if I'm going to have to have to use srgb.
I also was thinking about specifying a narrow _range_ of values to give me a
+/-1 wiggle room in byte values when converted to 0-1, so that'll probably
involve math.inc and a special use of VEq and a threshold.

Has anyone ever come across a situation like this?





I currently have enough worked out where I can randomly place 100 people in the
building and sequentially solve the "maze" to generate a shortest exit-path for
all 100 people.  I'm skipping over 5 pixels of the map at every step to generate
a much smaller "graph" to search, but it still takes about 5 min.

- BE

[Cousin Ricky] Re: Is an AOI function possible? [731 days 16 hours and 39 minutes ago]

Sun, 14 Apr 2024 21:34:28 GMT

On 2024-04-14 14:50 (-4), William F Pokorny wrote:
> On 4/13/24 13:18, Cousin Ricky wrote:
>> Is it possible to vary a texture by AOI according to a function, rather
>> than by a texture list?Â  I don't see anything in the aoi syntax diagrams
>> that allows this, but it would be nice to know if I missed something.
> 
> The 'texture list' wording confuses me. Did you mean texture map?

Yes, that is what I meant.  I was thinking the list of textures that go
into a texture_map.

> I believe the short answer is no and that you see the situation correctly.

Thanks.

> There is the slope pattern which might help depending on what you want
> to do, but it too has function usage constraints.

No, the slope pattern is definitely not what I'm looking for.

[William F Pokorny] Re: Is an AOI function possible? [731 days 19 hours and 23 minutes ago]

Sun, 14 Apr 2024 18:50:38 GMT

On 4/13/24 13:18, Cousin Ricky wrote:
> Is it possible to vary a texture by AOI according to a function, rather
> than by a texture list?  I don't see anything in the aoi syntax diagrams
> that allows this, but it would be nice to know if I missed something.

The 'texture list' wording confuses me. Did you mean texture map?

I believe the short answer is no and that you see the situation correctly.

Bill P.

---
A longer answer is that you can get past the parser's checks which 
prevent the usual direct pattern{} wrap of the aoi pattern.

The parser prevents:

//  #declare Fn02 = function { pattern { aoi } }  // Illegal

The following or, a similar non-yuqk form of it for official POV-Ray, 
slips by the parser checks and runs:

     #declare Pg03 = pigment {
         aoi function_interval
         color_map { [-1 color 0] [+1 color +1] }
     }
     #declare Fn03 = function {
         pigment {
             pigment_pattern { Pg03 }
         }
     }
     #declare Pg99 = pigment { function { Fn03(x,y,z).red } }

However, it does no good because the ray and perturbed normals are not
available via the function route - and so a 0.0 value is always returned 
(.red is always 0.5 above).

FWIW. It is on the yuqk fork's todo list to implement an 'information' 
pattern which, rather than being a true scalar value pattern, will 
return 21 bit float encoded, 3 component vectors for things like ray 
direction, raw and perturbed normals. With this information you'd be 
able to build up user 'aoi' functions of your own for surfaces.

The yuqk fork today has an inbuilt f_normal() function which can be 
employed to determine the raw normal in a value field in a way matching 
that done for isosurfaces. So in limited situations where you might know 
the ray direction (orthographic camera, parallel light rays, ...) and 
have well behaved isosurface shapes or pattern value fields (media), you 
might be able to implement certain 'aoi' like functions today in the 
yuqk fork.

There is the slope pattern which might help depending on what you want 
to do, but it too has function usage constraints.

[Cousin Ricky] Is an AOI function possible? [732 days 20 hours and 55 minutes ago]

Sat, 13 Apr 2024 17:18:32 GMT

Is it possible to vary a texture by AOI according to a function, rather
than by a texture list?  I don't see anything in the aoi syntax diagrams
that allows this, but it would be nice to know if I missed something.

[Francois LE COAT] Re: Optical Inertia [742 days 22 hours and 43 minutes ago]

Wed, 3 Apr 2024 15:30:35 GMT

Hi,

Francois LE COAT writes:
> The experiment from Hernan Badino was redone. You can see it there...
> 
>      <https://www.youtube.com/watch?v=fqWdSfN9FiA> Source
> 
> The main interest is that video is looping, and the result is almost:
> 
>      <https://www.youtube.com/watch?v=0ZPJmnBh03M> Reworked
> 
> Well, Hernan Badino is moving his head when he is walking, so the
> reconstructed trajectory is not perfectly looping at the end. But
> we can reconstruct the movement almost perfectly. We use OpenCV
> for image processing, and POV-Ray for 3D representation. We have
> to determine projective dominant motion in the video with a
> reference image, and change it when correlation drops below 80%.
> 
> We have a 3D inertial model of motion, that's why POV-Ray helps =)

Three drones are flying between forests of trees. Thanks to the
optical-flow (DIS OpenCV) measured on successive images, the
"temporal disparity" reveals the forest of trees (3rd dimension)...

<https://www.youtube.com/watch?v=QP75EeFVyOI> 1st drone
<https://www.youtube.com/watch?v=fp5Z1Nu4Hko> 2nd drone
<https://www.youtube.com/watch?v=fLxE8iS7fPI> 3rd drone

The interest with the forest is that trajectories are curved, in
order to avoid obstacles. It is measured thanks to a projective
transform, and represented with <Ry,Rz,Tx,Tz> thanks to POV-Ray.
The evolution of the drone is shown in front-view with its camera.

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[William F Pokorny] Re: image mapping [774 days 23 hours and 28 minutes ago]

Sat, 2 Mar 2024 14:45:18 GMT

On 3/1/24 13:47, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> In yuqk, generally, I've been pushing the code toward more ways to paint
> shapes - often using other shapes.
> 
> Check out:
>
https://developer.nvidia.com/gpugems/gpugems/part-iii-materials/chapter-20-texture-bombing
> 
> Seems simple enough to do, and ought to be fast if implemented in source.
> 
> - BW
> 

Thanks for the pointer! Added it to my notes.

I think, maybe, Sam did something like this a long time ago in SDL. I 
vaguely remember an image of tree leaves on the ground...?

Bill P.

[Bald Eagle] Re: image mapping [775 days 19 hours and 24 minutes ago]

Fri, 1 Mar 2024 18:50:00 GMT

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

>In yuqk, generally, I've been pushing the code toward more ways to paint
shapes - often using other shapes.

Check out:
https://developer.nvidia.com/gpugems/gpugems/part-iii-materials/chapter-20-texture-bombing

Seems simple enough to do, and ought to be fast if implemented in source.

- BW

[William F Pokorny] Re: image mapping [775 days 22 hours and 5 minutes ago]

Fri, 1 Mar 2024 16:08:38 GMT

On 2/29/24 13:36, Bald Eagle wrote:
>> after two days of absence, I find your example... and what example !
>> on first reading, I understood nothing, but I'm going to peel it back a
>> bit more.
> He's just got the uv-mapping data hardwired into the object definition.

:-)

I'm always overwhelmed on initially seeing more than the simplest code 
from others! My own old code too, truth be told.

I'm aiming for the scene I posted to be a shipped example in the next 
release. As I've added more comments, I picked up a couple more typos 
(*)... None affected the result, but they certainly hurt the clarity of 
the example. The next release of yuqk will have this code with 
additional comments - and I hope no remaining mistakes - should you want 
to wait to 'peel'.

(*) - f_elliptical_sphrswp(...,-90,-90...) should have read '+90,-90'. 
The first value is an initial starting position for the sphere sweep and 
the only values allowed are left handed rotations of [0.0...360.0) so 
the implementation took the -90 as abs(-90) or +90, despite what I typed...

---

What Bill W says is true. Conceptually, it's just user directed, 
piecemeal, uv mapping in play here - another form of what you were 
trying in fact.

In yuqk, generally, I've been pushing the code toward more ways to paint 
shapes - often using other shapes. The inbuilt f_path() function in yuqk 
is as much about painting CSG shapes, as it is about having a new way to 
set up isosurface shapes (which can also paint themselves).

The 'list_object' pattern new to yuqk is conceptually an internal 
implementation of Matthew Goulet's / Blue Herring's 'multiobj.inc' from 
the currently offline, but being worked upon, object-collection 
(lib.povray.org).

Yuqk's inbuilt f_elliptical_sphrswp() is conceptually similar to Bruno 
Cabasson's elliptic_torus.pov.

Some of yuqk's density_file interpolation extensions are for playing 
with 3D painting of objects. Ideas related to SDL proximity pattern 
implementations of years past (Edouard Poor?).

Yuqk's new 'pattern_modifiers' keyword is about capturing complex 
spatial manipulations which can then be accessed to keep textures, 
function defined shapes, and CSG-shapes aligned / matched. The aim is 
texturing in simpler 3D space and shapes ahead of spacial changes / 
deformations - and having it all track correctly for a final result. 
This an extension of capturing transforms in the same manner.

Anyhow. It's true a lot of what looks new / complicated in yuqk is just 
what others have taken runs at long ago in a different, perhaps 
extended, form.

(The user_defined{} bit is, of course, clipka's work already in v3.8 
beta 2 / v4.0)

Bill P.

[Bald Eagle] Re: image mapping [776 days 19 hours and 34 minutes ago]

Thu, 29 Feb 2024 18:40:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> after two days of absence, I find your example... and what example !
> on first reading, I understood nothing, but I'm going to peel it back a
> bit more.

He's just got the uv-mapping data hardwired into the object definition.
So, if you were going to map a sphere, you'd use theta and phi to describe the
surface.
remapping theta and phi from radians to a 0-1 domain, you can grab the pixel
from the image.

So you just write a function to do that "inverse uv mapping", and apply it to an
average texture that combines the r, g, and b values from the image map.

- BW

[kurtz le pirate] Re: image mapping [776 days 22 hours and 37 minutes ago]

Thu, 29 Feb 2024 15:36:18 GMT

On 28/02/2024 17:57, William F Pokorny wrote:
> On 2/28/24 05:13, William F Pokorny wrote:
>> Attached is a method using new v3.8 and yuqk features.
> 
> Yep. In the scene where I wrote ObjLeftL and ObjLeftR, those should have 
> been ObjLegL and ObjLegR, respectively.
> 
> (The definition of Pink is also extraneous)
> 
> Bill P.
> 

after two days of absence, I find your example... and what example !
on first reading, I understood nothing, but I'm going to peel it back a
bit more.

and I need the yuqk fork, which I don't have and which isn't (yet?)
available for my platform.

It's an excellent proofreading exercise.
What a job! Hats off to you!

-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: image mapping [777 days 21 hours and 16 minutes ago]

Wed, 28 Feb 2024 16:57:16 GMT

On 2/28/24 05:13, William F Pokorny wrote:
> Attached is a method using new v3.8 and yuqk features.

Yep. In the scene where I wrote ObjLeftL and ObjLeftR, those should have 
been ObjLegL and ObjLegR, respectively.

(The definition of Pink is also extraneous)

Bill P.

[William F Pokorny] Re: image mapping [778 days 4 hours ago]

Wed, 28 Feb 2024 10:13:58 GMT

On 2/26/24 12:05, kurtz le pirate wrote:
> How would you do it ?

Attached is a method using new v3.8 and yuqk features. While working up 
new inbuilt functions for yuqk, I've tried to implement them with the 
ability to return 't' or indexes for maps when that's possible.

The shapes I left as isosurfaces. Better render performance could be had 
by using using more basic CSG for the shapes and still the function set 
up for applying the image_map.

Bill P.

[Francois LE COAT] Optical Inertia [778 days 23 hours and 43 minutes ago]

Tue, 27 Feb 2024 14:30:29 GMT

Hi,

The experiment from Hernan Badino was redone. You can see it there ...

	<https://www.youtube.com/watch?v=fqWdSfN9FiA> Source

The main interest is that video is looping, and the result is almost :

	<https://www.youtube.com/watch?v=0ZPJmnBh03M> Reworked

Well, Hernan Badino is moving his head when he is walking, so the
reconstructed trajectory is not perfectly looping at the end. But
we can reconstruct the movement almost perfectly. We use OpenCV
for image processing, and POV-Ray for 3D representation. We have
to determine projective dominant motion in the video with a
reference image, and change it when correlation drops below 80%.

We have a 3D inertial model of motion, that's why POV-Ray helps =)

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[Bald Eagle] Re: image mapping [779 days 17 hours and 49 minutes ago]

Mon, 26 Feb 2024 20:25:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> How would you do it ?

Use a parametric function, so that you could make the geometry of the curve, and
then use that to uv-map it manually in SDL by applying the function as a 1:1
mapping function from <x, y> to the <u, v> of the shape.

I have to head out, but can elaborate on that if you need me to.

- BW

[kurtz le pirate] image mapping [779 days 21 hours and 9 minutes ago]

Mon, 26 Feb 2024 17:05:02 GMT

Hello,


The problem of the day :
I'm trying to project an image onto the rounded corner.


I've tried a lot of try with image_map and uv_mapping without success.
Here is my "best" (less bad) result for now.

Do you think it's possible to map the image directly onto the object?

The joined image is the result of three parts with two planar and one
cylindrical projection, but the joints don't stick :(


How would you do it ?




The geometry of the rounded corner is simple and I can post the code
with my tests using image_map{}.

The image used is here : <https://shorturl.at/mnqz2> on which I added
red marks.





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Reorient_Trans macro details [789 days and 4 minutes ago]

Sat, 17 Feb 2024 14:10:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> I changed the video format from .mov to .mp4
> Can you tell me if it's better?


Very Nice.  Works perfectly and the colors and lighting are beautiful.

Well done.

- BW

[kurtz le pirate] Re: Reorient_Trans macro details [789 days 3 hours and 23 minutes ago]

Sat, 17 Feb 2024 10:50:21 GMT

On 16/02/2024 23:04, Bald Eagle wrote:
> The animations "played", but were just black - no images.

Sorry for the inconvenience. I've tested with Fitrefox, Chrome and
Safari on Mac and Edge on Windows and it works fine.

I changed the video format from .mov to .mp4
Can you tell me if it's better?



-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: Reorient_Trans macro details [789 days 6 hours and 44 minutes ago]

Sat, 17 Feb 2024 07:29:27 GMT

Op 16/02/2024 om 17:54 schreef kurtz le pirate:
> On 09/02/2024 08:20, Thomas de Groot wrote:
> 
>> Before I go further in reading: This is a very welcome exercise you have
>> started here, Bill! I am a very regular user of the macro and I confess
>> that I have had a lot of misunderstandings about its working in the past.
> 
> bonjour,
> 
> 
> Following your comment, I made this page about rotations in 3d space.
> Could this kind of literature be useful for POV user or no one is
> interested or even be annoying ?
> 
> 
> <http://louisbel.free.fr/scenes/scene036.shtml>
> It's on my website and in English ;)
> 

Note: Contrary To Bald Eagle, the animations played correctly on my 
system (Win11) not black.

I think these kind of simple and clear visual explanations can be very 
useful, certainly for starting (POV-Ray) modellers, but also for old 
hands who have temporarily lost their way in confusion and need a little 
reminder. :-) I am certainly one of those from time to time.

I would suggest that you label the x-, y-, z-axis in the first 
animation, and/or add the usual red, green, and blue colours to them.

Well done and keep on!

-- 
Thomas

[Bald Eagle] Re: Reorient_Trans macro details [789 days 16 hours and 9 minutes ago]

Fri, 16 Feb 2024 22:05:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> Following your comment, I made this page about rotations in 3d space.

> <http://louisbel.free.fr/scenes/scene036.shtml>

The animations "played", but were just black - no images.

- BW

[kurtz le pirate] Re: Reorient_Trans macro details [789 days 21 hours and 19 minutes ago]

Fri, 16 Feb 2024 16:54:47 GMT

On 09/02/2024 08:20, Thomas de Groot wrote:

> Before I go further in reading: This is a very welcome exercise you have 
> started here, Bill! I am a very regular user of the macro and I confess 
> that I have had a lot of misunderstandings about its working in the past.

bonjour,

Following your comment, I made this page about rotations in 3d space.
Could this kind of literature be useful for POV user or no one is
interested or even be annoying ?

<http://louisbel.free.fr/scenes/scene036.shtml>
It's on my website and in English ;)

-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Making Patterns with functions [791 days 12 hours and 24 minutes ago]

Thu, 15 Feb 2024 01:50:00 GMT

This is very similar in concept to the Voronoi pattern, and indeed, if the
"annular rings" are fine enough, one gets the visual impression of Voronoi cells
filled with a concentric ring pattern.

I just did this for fun, to illustrate a practical pattern to use for ripples in
water, malachite, rhodochrosite, wood, "jawbreaker" candies, etc, and to
implement an example that makes use of splines, loops, pseudorandom numbers, and
a discrete set of "basis functions" that are evaluated "en-masse".

Enjoy the "bubbles".

(Speaking of which, this could be a fun one to apply iridescence to...)

I'd have to think about how to vary the "radius" of each seed point, and then
apply the true bubble intersection formula to get a nice foam cross-section.
Foam isosurface, anyone?

- BE

[Alain Martel] Re: Making Patterns with functions [791 days 23 hours and 25 minutes ago]

Wed, 14 Feb 2024 14:48:33 GMT

Le 2024-02-13 Ã  22:24, Bald Eagle a Ã©critÂ :
> This one's sort of like dice.
> 
> mod (floor(x)+floor(y), 2) somehow is NOT the same as even (floor(x)+floor(y))
> 
> IIRC, Bill Pokorny mentioned something about how floor isn't quite "right".
> 
> anyway, this is the last one for the night.
> 
> - BW
Another that play tricks with your eyes...

[Alain Martel] Re: Making Patterns with functions [791 days 23 hours and 26 minutes ago]

Wed, 14 Feb 2024 14:47:19 GMT

Le 2024-02-13 Ã  21:03, Bald Eagle a Ã©critÂ :
> Here's one to torture your eyes.  :P
It moves.
There are colour spots popping everywhere.
It shakes.

[William F Pokorny] Re: Making Patterns with functions [792 days 1 hour and 44 minutes ago]

Wed, 14 Feb 2024 12:29:09 GMT

On 2/13/24 22:24, Bald Eagle wrote:
> IIRC, Bill Pokorny mentioned something about how floor isn't quite "right".

IICRC... Rings a bell.

With yuqk, I do remember changing the code which creates the 0-1 ramp 
wave - in official POV-Ray there is some hard coded magic which 
sometimes causes trouble if one hits the right (wrong) values.

There is too some hard code clamping of values coming from functions 
into the pattern mechanism that I removed. However, this bit, from your 
results, I would say you are already avoiding. (That you are limiting 
your function() values into the pattern mechanism to 0-1 or >0.0 ranges)

Bill P.

[William F Pokorny] Re: Making Patterns with functions [792 days 1 hour and 54 minutes ago]

Wed, 14 Feb 2024 12:19:14 GMT

On 2/13/24 21:03, Bald Eagle wrote:
> Here's one to torture your eyes.  :P

It does dance around! :-)

Bill P.

[kurtz le pirate] Re: Making Patterns with functions [792 days 5 hours and 15 minutes ago]

Wed, 14 Feb 2024 08:59:04 GMT

On 13/02/2024 00:46, Bald Eagle wrote:
> Hopefully we can get a few new patterns posted in this thread, and I'm going to
> try to post at least one new pattern a week, to keep some momentum going.



Excellent work! Congratulations

-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Making Patterns with functions [792 days 10 hours and 49 minutes ago]

Wed, 14 Feb 2024 03:25:00 GMT

This one's sort of like dice.

mod (floor(x)+floor(y), 2) somehow is NOT the same as even (floor(x)+floor(y))

IIRC, Bill Pokorny mentioned something about how floor isn't quite "right".

anyway, this is the last one for the night.

- BW

[Bald Eagle] Re: Making Patterns with functions [792 days 12 hours and 9 minutes ago]

Wed, 14 Feb 2024 02:05:00 GMT

Here's one to torture your eyes.  :P

[Bald Eagle] Re: Making Patterns with functions [792 days 12 hours and 19 minutes ago]

Wed, 14 Feb 2024 01:55:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> I like this one.

I do too, which is why I posted it.
It brought to mind the vintage Corelle plate rim pattern. (attached)

> It seems like you're getting pretty good at this.

I'm getting a bit better at finding interesting patterns and translating them
from other languages/syntaxes.

I still have a devil of a time with some of them.
Some I can't get to work at all, especially if I have to make lines, use x and y
at the same time, or try to make a parametric function based on atan2(y, x).

I'm also trying to figure out why sometimes I only get a partial pattern.
But they _are_ more than formless grayscale vomit, so there is definitely some
progress.

When I understand WHY things work or don't, and know enough to fix them, then I
will be lots better.

When I can invent such functions on my own, then I will be good.

But that was half of the goal of this - to try implementing so many functions
that eventually I found changes that worked, and could be applied to others that
failed, and iteratively get better.

I'm almost at 200 functions, and at some point I'll have (temporarily) run out
of patterns to copy, and can start investigating variations and combinations.

There also seems to be various common methods for making patterns, and perhaps I
can distill them all down into several macros to make rendering each method a
little easier.

Thank you as always for your interest, tutelage, and encouragement.  :)
- BW

[Tor Olav Kristensen] Re: Making Patterns with functions [792 days 13 hours and 14 minutes ago]

Wed, 14 Feb 2024 01:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > I'm going to try to post at least one new pattern a week, to keep some momentum
going.

I like this one.

It seems like you're getting pretty good at this.

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

[Bald Eagle] Re: Making Patterns with functions [792 days 14 hours and 54 minutes ago]

Tue, 13 Feb 2024 23:20:00 GMT

Neat grid pattern.

[Bald Eagle] Re: Making Patterns with functions [792 days 14 hours and 59 minutes ago]

Tue, 13 Feb 2024 23:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm going to try to post at least one new pattern a week, to keep some momentum
going.

[Bald Eagle] Re: Making Patterns with functions [793 days 14 hours and 24 minutes ago]

Mon, 12 Feb 2024 23:50:00 GMT

I played with a few more functions - I think I'm up to about 189 in the
collection, and still have many more to implement.

This one I liked because it was "simple", and would probably find use in any
number of scenes, for different purposes.

Like the ultra-impressive Greek frieze pattern, this one got adapted from
Desmos, and it takes a lot of reading and thinking to grasp Desmos' syntax /
expression structure, unravel what is meant, and discard the superfluous parts.

I got it wrong about a dozen times, but in the process found that sometimes the
mistakes yield some pretty amazing and complex pattern in and of themselves.
So, when experimenting with new patterns, don't give up, and don't be surprised
when the raw pattern seems to bear absolutely no relation to the pattern that
you're trying to code.  The raw vs "thickened" pattern can differ - starkly - in
appearance.

Hopefully we can get a few new patterns posted in this thread, and I'm going to
try to post at least one new pattern a week, to keep some momentum going.

Hope you like.

- BE

[kurtz le pirate] Re: Reorient_Trans macro details [793 days 22 hours and 10 minutes ago]

Mon, 12 Feb 2024 16:03:52 GMT

On 08/02/2024 21:43, Tor Olav Kristensen wrote:
> And for axis rotate, this is relevant:
> 
> https://github.com/t-o-k/Rodrigues-rotation-formula


Exactly, that's right and don't forget : vaxis_rotate() bult in ;)



-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: Reorient_Trans macro details [797 days 6 hours and 53 minutes ago]

Fri, 9 Feb 2024 07:20:34 GMT

Op 08/02/2024 om 18:54 schreef Bald Eagle:
> 
> So, since my whole Reorient_Triangle macro relies on the Reorient_Trans macro,
> which was a bit of a black box operation,  I decided to take a deeper look into
> what goes on there, and unravel it all until I understood how it works.
> 
Before I go further in reading: This is a very welcome exercise you have 
started here, Bill! I am a very regular user of the macro and I confess 
that I have had a lot of misunderstandings about its working in the past.

Keep on the good work!

-- 
Thomas

[Tor Olav Kristensen] Re: Reorient_Trans macro details [797 days 12 hours and 54 minutes ago]

Fri, 9 Feb 2024 01:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thanks Tor!
>
> You've got an endless library of really useful macros, as usual.

Yes, I've written a lot of macros, some more useful than others.
My problem is to remember that I wrote them and were I've put them.

> With regard to matrix methods, would you happen to have any words of wisdom
> about how to go about the following with matrices as opposed to my vector math
> way?
>
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.65c027a941c066f01f9dae3025979125%40news.povray.org%3E/#%
3C
> web.65c027a941c066f01f9dae3025979125%40news.povray.org%3E

I just had a quick peek at your code.
It seems healthy, although it can probably be slimmed down a bit.

I'll see of can find some spare time for commenting it in the coming days.

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

[Tor Olav Kristensen] Re: Reorient_Trans macro details [797 days 13 hours and 39 minutes ago]

Fri, 9 Feb 2024 00:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
>   // This makes no sense to me, since Vec_1 and Vec_2 are both normalized
> vectors,
>   // so the length of one unit vector minus another unit vector will ALWAYS be
> zero
>   #if (vlength (Vec_1-Vec_2) = 0)
>    transform {}
>   #else
>    // Which means that this part NEVER gets executed
>    #local vZ = VPerp_To_Vector (Vec_2);
>    transform {Axis_Rotate_Trans (vZ, 180)}
>...

IIRC it was me that added those two if-then-else parts to John VanSickle's
reorient macro.

Note that we are subtracting the normalized vectors, not their lengths.
And then we check if the resulting vector has zero length.

So no, one unit vector minus another unit vector will NOT ALWAYS be zero, only
if they are pointing the same direction, in which case no transformation is
necessary.

After the last else statement we can be sure that the two vectors are pointing
in opposite directions. In this case the math for calculating the components of
the reorient matrix breaks down.

In this case we can not know what the user actually want to achieve. (And
perhaps she/he does not know this her/him-selves.)

We can (and perhaps we should) now give up and use the #error statement.

But in some cases we can choose one of infinitely many possible solutions and
the result will be the same (e.g. if the reoriented object is symmetric around a
line in the same direction as the the "reorient from" vector, like a cylinder.)

Now note that the reorient transform is very similar to the axis rotate
transform. If we take the cross product between the vector to reorient from and
the vector to reorient to, we get a rotation axis for the axis rotate transform.
And if we find the angle between those two vectors, (e.g. by acos of their dot
product, or arcsin of the length of their cross product, or both combined with
atan2, or a more numerical stable formula), we have the rotation angle for the
axis transform.

I choose one vector (from infinitely many vectors), that is perpendicular to
both the "rotate from" vector and the "rotate to" vector, to use for the axis in
the axis rotate transform. The rotation angle is 180 degrees.

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

[Bald Eagle] Re: Reorient_Trans macro details [797 days 16 hours and 49 minutes ago]

Thu, 8 Feb 2024 21:25:00 GMT

Thanks Tor!

You've got an endless library of really useful macros, as usual.

With regard to matrix methods, would you happen to have any words of wisdom
about how to go about the following with matrices as opposed to my vector math
way?

http://news.povray.org/povray.binaries.images/message/%3Cweb.65c027a941c066f01f9dae3025979125%40news.povray.org%3E/#%3C
web.65c027a941c066f01f9dae3025979125%40news.povray.org%3E

[Tor Olav Kristensen] Re: Reorient_Trans macro details [797 days 17 hours and 19 minutes ago]

Thu, 8 Feb 2024 20:55:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> >...
> >
> > Hi Bill
> >
> > It's a useful exercise you've started here.
> >
> > You may also want to have a look at the ReorientTransform() macro here:
> > https://github.com/t-o-k/Useful-POV-Ray-macros/blob/main/vectors.inc
>
>
> And for axis rotate, this is relevant:
>
> https://github.com/t-o-k/Rodrigues-rotation-formula
>

Some more here:

From: Tor Olav Kristensen
Subject: Rotation around an arbitrary axis
Date: 2001-11-29 19:23:16
https://news.povray.org/povray.advanced-users/thread/%3C3C06D0B8.9DE747A0%40hotmail.com%3E/

- and here:

https://github.com/t-o-k/scikit-vectors/blob/master/skvectors/cartesian_3d_vectors.py

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

[Tor Olav Kristensen] Re: Reorient_Trans macro details [797 days 17 hours and 29 minutes ago]

Thu, 8 Feb 2024 20:45:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>...
>
> Hi Bill
>
> It's a useful exercise you've started here.
>
> You may also want to have a look at the ReorientTransform() macro here:
> https://github.com/t-o-k/Useful-POV-Ray-macros/blob/main/vectors.inc


And for axis rotate, this is relevant:

https://github.com/t-o-k/Rodrigues-rotation-formula


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

[Tor Olav Kristensen] Re: Reorient_Trans macro details [797 days 17 hours and 34 minutes ago]

Thu, 8 Feb 2024 20:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, since my whole Reorient_Triangle macro relies on the Reorient_Trans macro,
> which was a bit of a black box operation,  I decided to take a deeper look into
> what goes on there, and unravel it all until I understood how it works.
>
> The best I can describe it, briefly, is that we can look at POV-space as a
> common reference frame that both Axis1 and Axis 2 exist in relation to.
> Then we construct localized orthonormal (perpendicular) spaces using each Axis
> argument as the x-axis of its frame.
>
> We apply the Axis1 frame as a matrix transform to align it with POV-space.
> Then we apply the _inverse_ of the matrix for Axis2 to do a reverse form of what
> we just did for Axis1.
> We align POV-space with the Axis2 frame by applying its matrix transpose.
> (Which, since it's essentially a rotation matrix, is the same as the inverse)
>
> Here's the original macro with some of the variables renamed, and plenty of
> commentary.
>
> I did note that half of the macro doesn't seem to even need to be there.
>
> I'm gonna write an alternate form of the macro that uses the inverse keyword
> just to make sure it does exactly the same thing.
>
> In the render, the left cube shows Axis1 in yellow, Axis2 in purple, and the
> POV-space reference frame in white.  The two perpendicular axes of the Axis1
> frame are in green and blue.
>
> At the center, we can see that the Axis 1 frame has been aligned with POV-space.
> (I know it looks weird, and I spent a few hours working through a lot of
> experiments, but since we're essentially applying a rotation transformation in
> the negative direction around x, the first transform winds up doing that wild
> flip to invert the shape.  Look at the relationship between the perpendiculars
> and the cube, and it ought to make sense)
>
> Now we need to align the x-vector with Axis2, and you can imagine a rotation
> aroind -x, followed by a rotation around -z to get there.  And that aligns
> everything.
>
> If you picture the shortest-path rotation from Axis1 to Axis2, you'll see that
> the colored corner markers end up in the right place, which was one of the
> things I was concerned about, and spurred this whole venture.
>
> //############################################################################
>
>
> #macro Reorient_Trans (Axis1, Axis2)
>  // Edited and commented by Bill Walker "Bald Eagle" Feb 2024
>  #local Vec_1 = vnormalize (Axis1);
>  #local Vec_2 = vnormalize (Axis2);
>  // vcross returns a perpendicular vector
>  // if vectors are parallel or antiparallel, then vcross = 0
>  #local Perp = vcross (Vec_1, Vec_2);
>  #if (vlength (Perp) > 0)
>   #local Pboth = vnormalize (Perp);
>   // so now we have normalized vectors with a common
>   // perpendicular to both vectors "Perp"
>   // We generate a third perpendicular vector for each
>   // reference frame, "Perp1" and "Perp2"
>   #local Perp1 = vnormalize (vcross (Vec_1, Pboth));
>   #local Perp2 = vnormalize (vcross (Vec_2, Pboth));
>
>   transform {
>    // Now we transform the basis vectors.
>    // Notice that the standard matrix is composed of COLUMN vectors
>    // All of the vectors are normalized, and they
>    // are all orthonormal (perpendicular to each other)
>    // so this constitutes a rigid body transformation
>    // which only performs rotations
>    // former x vector gets aligned to Vec_1 (Axis1)
>    // former y vector gets aligned with the common perpendicular Pboth
>    // former z vector gets aligned to Perp1
>
>    matrix <
>    Vec_1.x, Pboth.x, Perp1.x,
>    Vec_1.y, Pboth.y, Perp1.y,
>    Vec_1.z, Pboth.z, Perp1.z,
>      0,    0,    0    >
>
>    // Notice that the following matrix is composed of ROW vectors
>    // So this is a transpose matrix
>    // We know it's an orthonormal rotation matrix (with a determinant of 1)
>    // so the matrix transpose is actually the same as the matrix inverse
>
>    // Let's consider what the untransposed matrix would have done:
>    // former x vector gets aligned to Vec_2 (Axis2)
>    // former y vector gets aligned with the common perpendicular Pboth
>    // former z vector gets aligned to Perp2
>    // (Just like the first matrix)
>
>    // So we would have taken the result we're aiming toward - an alignment with
> Axis2,
>    // and aligning it to the same place as we have just moved our starting Axis1
> to.
>    // And since the transpose matrix is the INVERSE, we are just UNDOING that
> transform
>    // to move the common reference frame to that of Axis2
>
>    // Presumably we could have accomplished the same operation with the standard
> column
>    // major form using a separate "transform { matrix <> inverse}" statement
>
>    matrix <
>    Vec_2.x, Vec_2.y, Vec_2.z,
>    Pboth.x, Pboth.y, Pboth.z,
>    Perp2.x, Perp2.y, Perp2.z,
>      0,     0,     0  >
>   }
>  #else
>   // This makes no sense to me, since Vec_1 and Vec_2 are both normalized
> vectors,
>   // so the length of one unit vector minus another unit vector will ALWAYS be
> zero
>   #if (vlength (Vec_1-Vec_2) = 0)
>    transform {}
>   #else
>    // Which means that this part NEVER gets executed
>    #local vZ = VPerp_To_Vector (Vec_2);
>    transform {Axis_Rotate_Trans (vZ, 180)}
>   #end
>  #end
> #end

Hi Bill

It's a useful exercise you've started here.

You may also want to have a look at the ReorientTransform() macro here:
https://github.com/t-o-k/Useful-POV-Ray-macros/blob/main/vectors.inc

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

[Bald Eagle] Re: Reorient_Trans macro details [797 days 17 hours and 59 minutes ago]

Thu, 8 Feb 2024 20:15:00 GMT

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

> (Which, since it's essentially a rotation matrix, is the same as the inverse)

I reworked my old rotation matrices scene to give a bit more of a visual
interpretation.

I wasn't sure if I'd need to animate this, and have changing values on a
readout, or the transformed vector rendered alongside its inverse and
transpose...

Hopefully it's clear, if it's not, then let me know what would really help
illustrate the concept(s) more clearly.

- BW

[Bald Eagle] Re: Reorient_Trans macro details [797 days 19 hours and 49 minutes ago]

Thu, 8 Feb 2024 18:25:00 GMT

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

> I'm gonna write an alternate form of the macro that uses the inverse keyword
> just to make sure it does exactly the same thing.

And indeed, using the following gives the same results.
Note that you have to enclose the second matrix in its own transform {}, else
the inverse gets applied to the whole 2-matrix transform instead of just the
second matrix.

transform {
 matrix <
 Vec_1.x, Pboth.x, Perp1.x,
 Vec_1.y, Pboth.y, Perp1.y,
 Vec_1.z, Pboth.z, Perp1.z,
   0,    0,    0    >

 transform {
  // Column vectors like above
  matrix <
  Vec_2.x, Pboth.x, Perp2.x,
  Vec_2.y, Pboth.y, Perp2.y,
  Vec_2.z, Pboth.z, Perp2.z,
    0,     0,     0  >
  inverse // <--- Inverse
 }
}

[Bald Eagle] Reorient_Trans macro details [797 days 20 hours and 19 minutes ago]

Thu, 8 Feb 2024 17:55:00 GMT

So, since my whole Reorient_Triangle macro relies on the Reorient_Trans macro,
which was a bit of a black box operation,  I decided to take a deeper look into
what goes on there, and unravel it all until I understood how it works.

The best I can describe it, briefly, is that we can look at POV-space as a
common reference frame that both Axis1 and Axis 2 exist in relation to.
Then we construct localized orthonormal (perpendicular) spaces using each Axis
argument as the x-axis of its frame.

We apply the Axis1 frame as a matrix transform to align it with POV-space.
Then we apply the _inverse_ of the matrix for Axis2 to do a reverse form of what
we just did for Axis1.
We align POV-space with the Axis2 frame by applying its matrix transpose.
(Which, since it's essentially a rotation matrix, is the same as the inverse)

Here's the original macro with some of the variables renamed, and plenty of
commentary.

I did note that half of the macro doesn't seem to even need to be there.

I'm gonna write an alternate form of the macro that uses the inverse keyword
just to make sure it does exactly the same thing.

In the render, the left cube shows Axis1 in yellow, Axis2 in purple, and the
POV-space reference frame in white.  The two perpendicular axes of the Axis1
frame are in green and blue.

At the center, we can see that the Axis 1 frame has been aligned with POV-space.
(I know it looks weird, and I spent a few hours working through a lot of
experiments, but since we're essentially applying a rotation transformation in
the negative direction around x, the first transform winds up doing that wild
flip to invert the shape.  Look at the relationship between the perpendiculars
and the cube, and it ought to make sense)

Now we need to align the x-vector with Axis2, and you can imagine a rotation
aroind -x, followed by a rotation around -z to get there.  And that aligns
everything.

If you picture the shortest-path rotation from Axis1 to Axis2, you'll see that
the colored corner markers end up in the right place, which was one of the
things I was concerned about, and spurred this whole venture.

//############################################################################


#macro Reorient_Trans (Axis1, Axis2)
 // Edited and commented by Bill Walker "Bald Eagle" Feb 2024
 #local Vec_1 = vnormalize (Axis1);
 #local Vec_2 = vnormalize (Axis2);
 // vcross returns a perpendicular vector
 // if vectors are parallel or antiparallel, then vcross = 0
 #local Perp = vcross (Vec_1, Vec_2);
 #if (vlength (Perp) > 0)
  #local Pboth = vnormalize (Perp);
  // so now we have normalized vectors with a common
  // perpendicular to both vectors "Perp"
  // We generate a third perpendicular vector for each
  // reference frame, "Perp1" and "Perp2"
  #local Perp1 = vnormalize (vcross (Vec_1, Pboth));
  #local Perp2 = vnormalize (vcross (Vec_2, Pboth));

  transform {
   // Now we transform the basis vectors.
   // Notice that the standard matrix is composed of COLUMN vectors
   // All of the vectors are normalized, and they
   // are all orthonormal (perpendicular to each other)
   // so this constitutes a rigid body transformation
   // which only performs rotations
   // former x vector gets aligned to Vec_1 (Axis1)
   // former y vector gets aligned with the common perpendicular Pboth
   // former z vector gets aligned to Perp1

   matrix <
   Vec_1.x, Pboth.x, Perp1.x,
   Vec_1.y, Pboth.y, Perp1.y,
   Vec_1.z, Pboth.z, Perp1.z,
     0,    0,    0    >

   // Notice that the following matrix is composed of ROW vectors
   // So this is a transpose matrix
   // We know it's an orthonormal rotation matrix (with a determinant of 1)
   // so the matrix transpose is actually the same as the matrix inverse

   // Let's consider what the untransposed matrix would have done:
   // former x vector gets aligned to Vec_2 (Axis2)
   // former y vector gets aligned with the common perpendicular Pboth
   // former z vector gets aligned to Perp2
   // (Just like the first matrix)

   // So we would have taken the result we're aiming toward - an alignment with
Axis2,
   // and aligning it to the same place as we have just moved our starting Axis1
to.
   // And since the transpose matrix is the INVERSE, we are just UNDOING that
transform
   // to move the common reference frame to that of Axis2

   // Presumably we could have accomplished the same operation with the standard
column
   // major form using a separate "transform { matrix <> inverse}" statement

   matrix <
   Vec_2.x, Vec_2.y, Vec_2.z,
   Pboth.x, Pboth.y, Pboth.z,
   Perp2.x, Perp2.y, Perp2.z,
     0,     0,     0  >
  }
 #else
  // This makes no sense to me, since Vec_1 and Vec_2 are both normalized
vectors,
  // so the length of one unit vector minus another unit vector will ALWAYS be
zero
  #if (vlength (Vec_1-Vec_2) = 0)
   transform {}
  #else
   // Which means that this part NEVER gets executed
   #local vZ = VPerp_To_Vector (Vec_2);
   transform {Axis_Rotate_Trans (vZ, 180)}
  #end
 #end
#end

[Kenneth] Re: Making Patterns with functions [812 days 23 hours and 44 minutes ago]

Wed, 24 Jan 2024 14:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Is the technique you refer to here
> > the same as Mike's 'thickening' trick using 2 parallel surfaces (page 18 of
> > 149)? Or is it something different?
>
> It is the same - yet with a slight difference.
>
> If you're trying to make a black pattern on a white background, you're going to
> want a solid black pattern, not a small gradient from -C to 0 to +C.
>
> So you just use select to make a discontinuous function.
>
> #declare Pattern = function {select (abs(F(x,y,z)-C, 0, 0, 1)}
>
> And then when you do plane {z, 0, pigment {function {Pattern (x, y, z)}}}, you
> get what you're probably expecting.
>
Great, thanks. Yes, you were reading my mind, ha. (Actually, my own use would be
the reverse-- a white pattern on a black background.) I'll test it and play...

[Bald Eagle] Re: Making Patterns with functions [813 days 2 hours and 34 minutes ago]

Wed, 24 Jan 2024 11:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Is the technique you refer to here
> the same as Mike's 'thickening' trick using 2 parallel surfaces (page 18 of
> 149)? Or is it something different?

It is the same - yet with a slight difference.

If you're trying to make a black pattern on a white background, you're going to
want a solid black pattern, not a small gradient from -C to 0 to +C.

So you just use select to make a discontinuous function.

#declare Pattern = function {select (abs(F(x,y,z)-C, 0, 0, 1)}

And then when you do plane {z, 0, pigment {function {Pattern (x, y, z)}}}, you
get what you're probably expecting.

- BW

[Kenneth] Re: Making Patterns with functions [813 days 7 hours and 14 minutes ago]

Wed, 24 Jan 2024 07:00:01 GMT

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

>
> > Use Mike Williams' "shell" trick for isosurfaces to give an infinitely
> > thin line a visible thickness
>
>
> Do you have a link to this trick, or a short explanation? (--keeping my fingers
> crossed--)

I just took a look at the Mike Williams 'isosurface tutorial' that you packaged
and sent to me as a .pdf file some years ago. Is the technique you refer to here
the same as Mike's 'thickening' trick using 2 parallel surfaces (page 18 of
149)? Or is it something different?

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.

[example:]
#declare F = function {y + f_noise3d (x*2, 0, z*2)}
isosurface {
function {abs (F(x, y, z))-0.1}
......

[Kenneth] Re: Making Patterns with functions [813 days 8 hours and 9 minutes ago]

Wed, 24 Jan 2024 06:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> (Still experimenting and struggling with various aspects of getting patterns
> from other platforms to play well with SDL.)
>
> Important tips to generate quality patterns from equations
> ----------------------------------------------------------

> Use Mike Williams' "shell" trick for isosurfaces to give an infinitely thin line
> a visible thickness

Say what??!!
That would be really useful.

Do you have a link to this trick, or a short explanation? (--keeping my fingers
crossed--)

[Bald Eagle] Re: Making Patterns with functions [814 days 18 hours and 24 minutes ago]

Mon, 22 Jan 2024 19:50:00 GMT

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

(Still experimenting and struggling with various aspects of getting patterns
from other platforms to play well with SDL.)

> Hammering out that many equations one after the other ... has allowed me to learn
some new things and gain valuable i
nsights ...



OK, just to list the ones that I've written down so far:
(Questions, comments, and constructive criticism welcome as always)

Important tips to generate quality patterns from equations
----------------------------------------------------------
Be very careful with the use of parentheses - especially when + or - is in an
equation.  Group terms.
 You may want to declare different parts of a complex equation as separate
functions, then combine them in the final function
Use fmod instead of mod to get a regular repetition of a pattern across the
origin
 HOWEVER, sometimes using mod in certain functions gives a better (more
expected) result - so try both
Use Mike Williams' "shell" trick for isosurfaces to give an infinitely thin line
a visible thickness
Change the line thickness to give definition to patterns that may not show up
with smaller values.
Some equations don't cross the zero/integer/mod threshold often enough to show
finer details.  Multiply the
WHOLE equation (use parentheses) by a factor to increase the number of
lines/levels.
Zoom in or out to see pattern attributes that may not be visible or clearly
rendered.
If you're graphing y as a function of x, then you must write it in the form of:
function {y - formula} since when y=formula, the value is 0
If you're graphing a 2-argument function of both x and y, then you must write it
in the form of: function {(x - x_formula) + (y - y_formula)}

If you're graphing a polar equation, then write it in the form of: function {r -
formula}

POV-Ray's internal method of wrapping function values winds up hiding negative
vs positive parts,
 and won't be revealed until made as an isosurface, or the function is shifted
by + 0.5 and visualized with a color map

If you're using functions that return values in the 0-255 range, you're going to
have to divide the result by 255

If the function repeats over a range of 0-255, then you're going to have to use
mod (Function (x, y, z), 256)/255

You're going to need function versions of HSV to RGB to perform color
calculations

For full-color patterns, you're going to separate functions for r, g, and b,
plus an average texture using all 3 functions

There are common functions and operations that the function parser doesn't
recognize, and you'll have to write your own versions of

identifiers previously declared in a scene (even for loop iterators!) cannot
then be used in a function

If you're experiencing a blank pattern (all black/white/gray) then you have
likely forgotten to explicitly include x, y, and z into your function
argument list.  If your function takes some value N as an argument, but also
uses x, y, or z, then you must #declare F = function (x, y, z, N) {}

If your pattern only appears in the first quadrant (upper right, both x and y
are positive), then you will likely need to use abs(X) and abs(y) in your
equation

[Francois LE COAT] Re: Head Pose [823 days 21 hours and 29 minutes ago]

Sat, 13 Jan 2024 16:45:02 GMT

Hi,

> William F Pokorny writes:
>> Francois LE COAT wrote:
>>> I have a webcam on my Vaio ... I've moved my head in front of the
>>> camera, extracted the pose of the head with projective transform
>>> parameters, and re-injected those parameters in POV-ray in order to
>>> move a "virtual head" rendered with it. This give the video :
>>>
>>> <http://hebergement.u-psud.fr/lecoat/camera_fixe.mp4>
>>>
>>> Does somebody already seen that kind of demonstration results ?
>>>
>> Neat! I do not recall seeing this sort of camera to model coupling bei
ng
>> accomplished with POV-Ray.
> 
> The processing is only based on computer vision and image processing,
> with one webcam. I obtained the parameters of the movement with image
> registration and an original projective model. I don't think this
> result can be obtained without the POV-Ray scripting capabilities.

A WEB page was made to illustrate the Head Pose experiment...

When we want to determine the movement, there are two simplifying
hypotheses. Either the camera is fixed, and the observed scene is
moving. Or the camera moves, and the scene is static. In the general
case, the camera and the scene are moving, and it is necessary to
segment static and dynamic elements of what is observed. In this case
the camera is fixed, and it observes the person who is located in front
of the computer and moving. The goal of the experiment is to reconstruct
the visible relief, by "monocular depth"...

<https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/profondeur
.html>

That is to say we obtain the depth (inversely proportional to the
disparity) by measuring the optical-flow, with a single camera, tough
this measurement is classically made by binocular vision (for disparity)

Best regards,

-- 
François LE COAT
<https://hebergement.universite-paris-saclay.fr/lecoat>

[And] Re: Making Patterns with functions [826 days 10 hours and 49 minutes ago]

Thu, 11 Jan 2024 03:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Over the last 2 days, I've fallen down the mathematical pattern rabbit hole, and
> have been experimenting with all manner of what can be done with a simple
> pigment {function {}}
> statement.
>
> I currently have a list of 155 different patterns, including simple y = f(x)
> style functions, implicit equations (some combination of x&y) = (some other
> combination of x&y), and even some parametric polar equations and what I believe
> are parametric Cartesian equations.
>
> Hammering out that many equations one after the other and using different
> methods to visualize the "raw" results has allowed me to learn some new things
> and gain valuable insights into how best achieve a good, aesthetically pleasing
> result, and why some patterns might be difficult to implement in the absence of
> various "tricks".
>
> At this junction, I would like to thank everyone in the POV-Ray community, and
> especially Tor Olav Kristensen, Sam Benge, jr, William Pokorny, Jerome Grimbert,
> as well as the vast Shadertoy community - most notably Inigo Quilez, Martijn
> Steinrucken, and FabriceNeyret2, for inspiring me, and setting me on the path of
> discovery with regard to using functions to make amazing patterns.
>
> With that, I'll just leave here a most amazing Greek frieze pattern, produced by
> an astonishingly small amount of code, adapted to SDL from a shader by
> FabriceNeyret2.
>
> While this is probably one of the most complex patterns I've adapted, simply due
> to some specialized and highly technical methods that make its visibility even
> possible, I'd love to see people experimenting with simple equations to produce
> interesting patterns that we can build a library of.
>
> After progressively trimming down the amount of code I need to make a simple
> grid on a plane, I'd love to see such patterns code-golfed down to the bare
> minimum, and then parameterized to increase their variation and versatility.
>
> Happy New Year, everyone.
>
> - Bald Eagle

Wow, this one looks not easy and beautiful.

[Thomas de Groot] Re: Making Patterns with functions [827 days 7 hours and 5 minutes ago]

Wed, 10 Jan 2024 07:08:36 GMT

Op 09/01/2024 om 21:07 schreef Bald Eagle:
> Enjoy the eye and mind candy.
> 

Oh LOL! Well done :-)

-- 
Thomas

[Bald Eagle] Re: Making Patterns with functions [827 days 18 hours and 4 minutes ago]

Tue, 9 Jan 2024 20:10:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Very nice. Well done!
>
> I'm glad to see that you are advancing your math and coding skills Bill.

Well, I'm moving forward bit by bit, but all the credit for that pattern
definitely goes to the author.

There's a function or two that I need to puzzle out to understand what they do
and how they are so essential to creating the pattern.

Just as a reminder to myself, I may have to branch out into the 3rd dimension to
see if I can work some of the same "magic" with media density by incorporating
z.

However, along those lines, I was admiring another nice little piece of work
that I stumbled across, and it prompted me to work out the gory details of
Euler's formula, Taylor series, and all of that "e to the power of" stuff that
seems to creep into all manner of interesting topics.

I edited the poem a bit, but shamelessly stole the idea (even though I had to
painfully work out the implementation from first principles).  I didn't realize
I'd need about 20 terms in the Taylor series to get a good enough approximation.
 :O

Enjoy the eye and mind candy.

- BW

[Tor Olav Kristensen] Re: Making Patterns with functions [829 days 14 hours and 4 minutes ago]

Mon, 8 Jan 2024 00:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> With that, I'll just leave here a most amazing Greek frieze pattern, produced by
> an astonishingly small amount of code, adapted to SDL from a shader by
> FabriceNeyret2.
>...

Very nice. Well done!

I'm glad to see that you are advancing your math and coding skills Bill.

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

[Kenneth] Re: Making Patterns with functions [830 days 12 hours and 34 minutes ago]

Sun, 7 Jan 2024 01:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> With that, I'll just leave here a most amazing Greek frieze pattern, produced by
> an astonishingly small amount of code, adapted to SDL from a shader by
> FabriceNeyret2.
>

That is spectacularly beautiful! I'm dumbfounded, and amazed that your got
POV-ray to render such a fantastical pattern.

Keep at it, by all means; I can't wait to see what else you come up with.

[Bald Eagle] Re: Making Patterns with functions [830 days 22 hours and 29 minutes ago]

Sat, 6 Jan 2024 15:45:00 GMT

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

> First of all: a Happy (and POV-Productive) New Year.

Thanks Thomas, I hope to see some more excellent landscapes, textures, or even
just doodles with no particular point behind them.

> I am literally speechless.

Ha!  So was I.  :D  The shader is literally only 6 lines of code.
It still took me a fair amount of time to grope in the pitch black towards a
solution.

The funny thing is, earlier in the day I had been struggling (once more) to make
a simple spiral pattern, and here is a spiral, evenly divided into cells by
spiral arc-length, with different animated spirals in each cell!
I was also really happy that the solution relied on using the fwidth function,
as that lit a fire under my lazy butt to actually implement that in SDL as well.

So now I think I actually have all of the tools to push  forward on coding the
knots in the wood texture, along with the spiral interpolation thing... all
because I was doing something completely unrelated, and juts serendipitously
stumbled upon a shader that was linked from a page I found through an image
search.

> You did an awesome bit of work and I wouldn't
> know where to begin, especially as my mathematical skills are rather
> rudimentary.

You, and Kenneth, and jr have all expressed as much, but I will tell you that
it's less about "knowing" the math, than simply acquiring a "feel" for it - a
sense of what types of things are related to what you're trying to accomplish,
or recognizing what terms in an equation are likely to be related to what parts
of the graph's shape.
Playing with an existing equation can rapidly sort all of that out, even if
initially it's all as opaque as obsidian.

> Are you going to provide us with some basic guide lines on
> how to start such experimentation? I guess that would be needed for
> several of us, setting us on our way.

Yes, I started summarizing the things I discovered in a comment section of my
patterns scene, and I'm hoping at some point to make further progress on a
function monograph that I started, specifically with jr and Kenneth in mind.

I think there are several things that have prevented me from successfully coding
some of the patterns that I've tried to reproduce in the past - and that makes
me think that I was probably tantalizingly close, but either I fell into the
trap of convincing myself that "it just couldn't be done", or there were some
finer points of how to visualize what was going on that I was missing.
I'm sure I must have threw away a few equations here & there in this last coding
frenzy, simply because I forgot to subtract the whole thing from y, and so it
just looked like a lot of random static.

I'm finishing up an extended family visit, and have an event to attend later
this evening, but after I get everything settled after that, I ought to have
some uninterrupted hours to devote to doing some more experiments, writing some
educational code, and hopefully finding ways to create some example scenes and
explain things clearly enough so that it's easy enough to follow.

It would actually help a lot to just write out a big list of things that you've
always wondered about, want to do, tried but were confused by, or any other
curiosities and speculations - so that I have a target to aim for.
It's not so much that "you don't know math / were never taught it / don't have
the skills", but WHY certain things are confusing or unknown to you.

Then I can think about what needs explaining, how best to explain it, and what
examples I can code to best illustrate the concepts.  And to be honest, I'm
still at the stage where I don't clearly understand exactly how half of the
stuff I code actually works - so I may do a lot of hand-waving until some of the
smarter people (TOK, Jerome, WFP, Ingo) chime in with explanations or links that
lead me by the nose hairs to enlightenment.

All the best,

- BW

[ingo] Re: Making Patterns with functions [831 days 4 hours and 14 minutes ago]

Sat, 6 Jan 2024 10:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Over the last 2 days, I've fallen down the mathematical pattern rabbit hole, and
> have been experimenting with all manner of what can be done with a simple
> pigment {function {}}
> statement.
>

Excellent!!

I always had/have hoped that at some time the function language would grow a bit
in the direction of shaders by making more/all internal data available to
functions. Colour and normals are obvious, but just think of having also data on
radiosity, photons and what else there is inside POV-Ray that can be (ab)used.
These internal data do not even have to have any relation to textures or
objects. It's up to the artist to do something with them.

Photon data based displacement mapping for re-modeling meshes ...

A texture dependent on the number of times the light ray bounced before
intersection. Or normals based on the total length of a ray.

"Geluk in' tuk" (good luck in your pocket) for 2024,

ingo

[Thomas de Groot] Re: Making Patterns with functions [831 days 6 hours and 55 minutes ago]

Sat, 6 Jan 2024 07:18:12 GMT

Op 05/01/2024 om 22:50 schreef Bald Eagle:
> 
> [snip]
> 
> While this is probably one of the most complex patterns I've adapted, simply due
> to some specialized and highly technical methods that make its visibility even
> possible, I'd love to see people experimenting with simple equations to produce
> interesting patterns that we can build a library of.
> 
> After progressively trimming down the amount of code I need to make a simple
> grid on a plane, I'd love to see such patterns code-golfed down to the bare
> minimum, and then parameterized to increase their variation and versatility.
> 
> Happy New Year, everyone.
> 

First of all: a Happy (and POV-Productive) New Year.

I am literally speechless. You did an awesome bit of work and I wouldn't 
know where to begin, especially as my mathematical skills are rather 
rudimentary. Are you going to provide us with some basic guide lines on 
how to start such experimentation? I guess that would be needed for 
several of us, setting us on our way.

Thanks indeed for your - and all those others - great work!

-- 
Thomas

[Bald Eagle] Making Patterns with functions [831 days 16 hours and 19 minutes ago]

Fri, 5 Jan 2024 21:55:00 GMT

Over the last 2 days, I've fallen down the mathematical pattern rabbit hole, and
have been experimenting with all manner of what can be done with a simple
pigment {function {}}
statement.

I currently have a list of 155 different patterns, including simple y = f(x)
style functions, implicit equations (some combination of x&y) = (some other
combination of x&y), and even some parametric polar equations and what I believe
are parametric Cartesian equations.

Hammering out that many equations one after the other and using different
methods to visualize the "raw" results has allowed me to learn some new things
and gain valuable insights into how best achieve a good, aesthetically pleasing
result, and why some patterns might be difficult to implement in the absence of
various "tricks".

At this junction, I would like to thank everyone in the POV-Ray community, and
especially Tor Olav Kristensen, Sam Benge, jr, William Pokorny, Jerome Grimbert,
as well as the vast Shadertoy community - most notably Inigo Quilez, Martijn
Steinrucken, and FabriceNeyret2, for inspiring me, and setting me on the path of
discovery with regard to using functions to make amazing patterns.

With that, I'll just leave here a most amazing Greek frieze pattern, produced by
an astonishingly small amount of code, adapted to SDL from a shader by
FabriceNeyret2.

While this is probably one of the most complex patterns I've adapted, simply due
to some specialized and highly technical methods that make its visibility even
possible, I'd love to see people experimenting with simple equations to produce
interesting patterns that we can build a library of.

After progressively trimming down the amount of code I need to make a simple
grid on a plane, I'd love to see such patterns code-golfed down to the bare
minimum, and then parameterized to increase their variation and versatility.

Happy New Year, everyone.

- Bald Eagle

[Bald Eagle] Re: user_defined camera intermittent / threshold... [834 days 10 hours and 49 minutes ago]

Wed, 3 Jan 2024 03:25:00 GMT

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

> On the actual issue, unsure.

Well here's the thing.   the scene was rendering just fine for several renders
before I made a radical change to the functions (just adding a scalar), and then
even when i changed everything back to the original functions - the weird
behaviour persisted.

I'm not redefining any apparent keywords, however I am using the image
dimensions to adjust the aspect ratio in the user_defined block. Maybe I'll
define a right vector just to mix things up and see what happens.

In any event, the Cartesian forms are easy enough to implement, and calculating
the partial derivatives is 1000 times easier than in polar coordinates.

- BW

[William F Pokorny] Re: user_defined camera intermittent / threshold... [834 days 14 hours and 50 minutes ago]

Tue, 2 Jan 2024 23:23:31 GMT

On 1/2/24 14:27, Kenneth wrote:
> Well, the rendered image IS called "astigmatism.png". Maybe POV-ray's new
> artificial-intelligence engine is at work, digesting your code and comparing it
> to millions of human vision tests that it scraped for free from private medical
> records around the world. Then it responded accordingly. Check your messages
> pane, to see if the following is there:  "Hey, if this image looks blocky to
> you, you definitely have astigmatism! Everyone else sees a perfectly normal
> image."
> 
> 

:-)

On the actual issue, unsure.

Looks render block related. Does using a single thread (+wt1) make a 
difference?

I vaguely recall setting all three directional components to 0 in a user 
defined camera, renders black - or transparent if using +ua. However, I 
didn't test my recollection.

Only other thought is that some apparent POV-Ray keywords are in fact 
declared as identifiers (IDs) at start up(a). Two such identifiers are 
'image_width' and 'image_height'. Keywords that are in fact IDs can be 
whacked by users in their SDL.

Bill P.

(a) - Most such 'apparent keyword' IDs are animation related.

[Kenneth] Re: user_defined camera intermittent / threshold... [834 days 18 hours and 44 minutes ago]

Tue, 2 Jan 2024 19:30:00 GMT

Well, the rendered image IS called "astigmatism.png". Maybe POV-ray's new
artificial-intelligence engine is at work, digesting your code and comparing it
to millions of human vision tests that it scraped for free from private medical
records around the world. Then it responded accordingly. Check your messages
pane, to see if the following is there:  "Hey, if this image looks blocky to
you, you definitely have astigmatism! Everyone else sees a perfectly normal
image."

[Bald Eagle] user_defined camera intermittent / threshold ren... [834 days 19 hours and 54 minutes ago]

Tue, 2 Jan 2024 18:20:00 GMT

So, I managed to muster enough motivation to doggedly pursue implementing the
user_defined camera approach to modeling lens aberrations with Zernike
polynomials.

At present, I'm attempting to do that using --- derivatives of the polar
equations.  (Not at all sure I'm doing it right)

Anyway, the point is, that after fiddling a bit with the location and direction
parametric equations, POV-Ray suddenly decided to start partial-rendering my
scene with some bad 8-bit blocky censorship.
Sometimes it's fairly evenly distributed across the whole image, other times
it's only in the top half....

This leads to speculate that:
1. There's something wrong with my build (3.8 beta windows executable)
2. There's potentially something wrong with my (computer) memory  :P
3. There exists some sort of state-dependent bug in the user_defined camera code

I'm going to try to work everything out in Cartesian coordinates and see if
maybe that might behave better, plus I'll be a lot more confident about the
derivatives and the resulting normal vector I'll be using for the direction {}

If that fails, I'll try re-starting POV-Ray, and perhaps shutting down until I
get back in from this evening's exciting warehouse work adventure.

- BW

[Bald Eagle] Bubbles [847 days 10 hours and 9 minutes ago]

Thu, 21 Dec 2023 04:05:00 GMT

So, I've been way off my usual schedule, and so haven't had a lot of time to
focus on some of my other projects.

But I was watching a video about soap bubbles
https://www.youtube.com/watch?v=Dk0dB4HYnu0
and I found the bit about the film separating the two bubbles interesting.

For 2 bubbles, the radius of curvature of the film is ridiculously simple to
calculate, but then when I actually tried to sketch it out, I found that all of
the things that I needed to do were remarkably complex.  And that was just
sticking to 2D circles in the xy plane with "axis-aligned" circle centers.

It was certainly a lot trickier than it seemed at first glance.

It would be an interesting set of macros to calculate all this in 3D so as to
make some nice actual bubbles with iridescence, but thinking about what would be
necessary to make large bubble clusters makes my head hurt.

- BW

[Francois LE COAT] Re: Optical Pendulum [877 days 4 hours and 43 minutes ago]

Tue, 21 Nov 2023 09:30:11 GMT

Hi,

>> ingo writes:
>>> Francois LE COAT wrote:
>>>> A WEB page was made to illustrate the "optical pendulum" experiment:

>>>>
>>>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/optic
al_pendulum.html> 
>>>>
>>>
>>> Nice!
>>
>> Thanks. I don't know anyone else working on such an experiment. It onl
y
>> requires a computer and a camera. This is so simple, but interesting!
>> Many people are trying to match images the best way, but there's no
>> real experiment like this "optical pendulum", so far as I know about i
t?
> 
> The planar perspective transformation used for modelling the camera
> motion, was added to the "optical pendulum" WEB page. Some of the
> transforms are present in Persistence of Vision, like 3 translations
> and 3 rotations. But the "skew" or "shear" angles <Sx,Sy> are not
> directly. Thanks for the POV-Ray advance users to have helped on that.

Here is the experimentation of the optical pendulum at its true rhythm
on a Dell Precision T3400 computer, Intel Core2 Quad Q6600 (2.4 GHz,
FSB 1066 MHz, 8 MB L2 cache, four cores)...

	<https://www.youtube.com/watch?v=3HnVTz1BPsU>

It is a machine which hosts GNU/Linux Mageia 8 in its 32-bits version,
and that is used to the maximum performances, thanks to multi-processing
and charge load balancing on the four cores. The calculation rate of the
eight movement parameters is at the time order of a second. Hardware
acceleration of algorithmic processing is envisaged.

Regards,

-- 
François LE COAT
<https://eureka.atari.org/>

[And] Re: Direct stochastic tiling [883 days 2 hours and 14 minutes ago]

Wed, 15 Nov 2023 12:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Trying to work out the "growth rings" part of the the paper, and while the words
> sound reasonable, translating that into equations and code is --- less
> straightforward.
>
> Thankfully, due to the lessons of the past million projects, I can at least come
> up with workable POV-Ray equivalents that serve the same purposes.
>
> At least the pattern looks like wood, although the texture and finish are
> obviously not even close - since that will rely heavily on later work.
>
> hdr light probes really change the colors compared to a point light source and
> sky_sphere!   :O
>
> At least it looks somewhat like a cheap 4x4 post I might see at a big box store.
>
> - BW

Wow, this looks interesting.

The paper you posted: ?
https://arxiv.org/pdf/1511.04224.pdf

When I saw it again, it looks more valuable.

[Bald Eagle] Re: Direct stochastic tiling [893 days 18 hours and 29 minutes ago]

Sat, 4 Nov 2023 19:45:00 GMT

After a few more hours of feeling my way through the math of the patterns I
wanted,  I was able to apply the pores to the wood, and then add the rays.

I only partially know what I'm doing, and don't have very good control over how
all of the parameters in the functions work.

Basically what I'm doing is creating a grid of circles, but radially, using
cylindrical coordinates.

Then it's just adding some randomness and scaling to get the desired effects.

No idea if at this point adding SSLT to the finish would really boost it.

- BW

[Bald Eagle] Re: Direct stochastic tiling [893 days 21 hours and 49 minutes ago]

Sat, 4 Nov 2023 16:25:00 GMT

Trying to work out the "growth rings" part of the the paper, and while the words
sound reasonable, translating that into equations and code is --- less
straightforward.

Thankfully, due to the lessons of the past million projects, I can at least come
up with workable POV-Ray equivalents that serve the same purposes.

At least the pattern looks like wood, although the texture and finish are
obviously not even close - since that will rely heavily on later work.

hdr light probes really change the colors compared to a point light source and
sky_sphere!   :O

At least it looks somewhat like a cheap 4x4 post I might see at a big box store.

- BW

[Bald Eagle] Re: Direct stochastic tiling [894 days 13 hours and 24 minutes ago]

Sat, 4 Nov 2023 00:50:00 GMT

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

> On the "bah" comment. One of the things our current spiral capability
> doesn't do well is start and stop exactly where we want it to - in a
> clean way. We have hard starts and stops on numerical limits or by
> fading the effect in or out. The piecemeal assembly of spirals does fill
> a need for clean, limited duration, spirals - admittedly by default! :-)

Humbug.

The spiral equations are analytical, and therefore ought to lend themselves to
directly limiting the radius or arc length of the generated spiral.

It would be a simple matter of experimenting, asking a shadertoy coder, or
posting a request on stackoverflow or similar smarty-pants site for a way to
limit the rendered spiral's domain.

I have wide-ranging interests, a fertile and sometimes overactive imagination,
usually shallow pockets, and a disdain for people telling me what I can't or
especially am not allowed to do.

Which means that somehow, some way, eventually, _I'll find a way_.
I've done it with making a commercial database using only an open source
spreadsheet, and I've done it will full-color (almost) tileable Voronoi using
only functions.

Spirals ought to be easy.
I haven't even investigated implementing a SDF for the spiral, but I know it's
possible.

- BW

It would be nice to have a wish-list that operated something like a c++ list -
where things could be added onto the list and then removed (or marked as done),
so that people could scroll through it if they were bored and looking for
something to do.  ;)
Maybe enable tags to assign priority or difficulty levels, etc.
(Similar to bug-reporting 3rd party services like FlySpray, do they have
feature-request maintaining services?)
[Oh, right, I guess they do - it's called "SaaS"]

[William F Pokorny] Re: Direct stochastic tiling [894 days 14 hours and 53 minutes ago]

Fri, 3 Nov 2023 23:20:38 GMT

On 11/3/23 15:31, Bald Eagle wrote:
> Plenty of other spirals out there to code up and experiment with, once I get
> some of this other heavy-lifting out of the way.

:-) Indeed. Somewhere, I've got a book on nothing but spirals.

I guess I see a practical need for some basic capability for vortex 
effects and a few of the more basic spirals. Beyond that, not sure.

Thanks for the additional ideas and especially the spiral code with 
which I play. I've got some of your earlier work on spirals stashed away 
too for when I can really get after the topic.

Heck, I've got a LOT of your general ideas stashed away! I can't keep up 
with you - or jr - truth be told.

On the "bah" comment. One of the things our current spiral capability 
doesn't do well is start and stop exactly where we want it to - in a 
clean way. We have hard starts and stops on numerical limits or by 
fading the effect in or out. The piecemeal assembly of spirals does fill 
a need for clean, limited duration, spirals - admittedly by default! :-)

Thanks for the thought to add the isosurface inside test comment to 
documentation. It's done in the documentation I'm shipping with the yuqk 
fork.

These days, I'm less a fan of massive popularity for POV-Ray than I 
expect you and others are. I'm becoming more and more averse to noise - 
and kids playing on my lawn.

Bill P.

[Bald Eagle] Re: Direct stochastic tiling [894 days 18 hours and 39 minutes ago]

Fri, 3 Nov 2023 19:35:00 GMT

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

> One thing I'd like to do in yuqk is dump the two inbuilt spiral patterns
> for more general, tapered spiral warping as one or more additional
> options of the warp{} mechanism.

Just search "shadertoy spiral" and you'll be there for hours.  ;)
https://www.shadertoy.com/user/FabriceNeyret2     is your guy.
Maybe if we reached out to him, he might have some interest in seeing what we do
here...

> We have too f_spiral() - which has issues - as you well know. The
> solutions to which, I believe, sit more with some sort of general
> tapered warping capability.

Well, f_spiral, I think - was just something to make an isosurface type thing.
I think we could probably use some general spiral equations and implement the
tubular function approach for things like that.

Speaking of functions, it would probably be a good idea if you're implementing
inbuilt functions to have some mechanism by which to get the 1st and 2nd
derivatives, or a tangent to a point using a numerical approach --- useful
things to have that make coding a scene & orienting shapes a thousand times
easier for people.

With regard to warps and spirals, I finally got that spiral warp worked out,
which is just a rotation matrix with a falloff function.

Perhaps you could play with a general warp mechanism which takes a
transformation matrix and a falloff function and pairs them up to make a warp.
You could have 2D warps, 3D warps (like my tornado), etc.

I also absolutely think that we need to have a geometric inversion function,
since I think it's something that would inspire a LOT of experimentation, cool
scenes, novel approaches, animations, and all manner of things I can't possibly
predict.

Ditto FFT.  Have it take a start, stop, and function (especially spline), and
have it output an array.

> Aside: We can today implement a limited form of the sort of spiral - I
> think you're implementing - with a series of half arc functions (there
> is too the new-ish list_object pattern in yuqk which could use the torus
> or functions via coded isosurfaces(a) (inside tests)). This approach,
> however, slows down significantly on the addition of each half arc.

Bah.  No need to do any such thing when doing it analytically it so
straightforward.

> (a) The inside test of 'isosurface shapes' is relatively fast when used
> for object based patterns. It's just whether the function returns a
> negative value or not at a given location. In fact, 'isosurface shapes
> for inside test purposes' do not need to be good isosurfaces with
> respect to being render-able as actual shapes!

True.  That might be a good point to make in the documentation.

- BW

The basic Archimedean spiral is just:

#declare Distance = function (X, Y, Z) {sqrt (X*X+Y*Y+Z*Z)}
#declare fmod = function (Value, Modulo) {select (Value, 1 - mod (abs (Value),
Modulo), mod (abs (Value), Modulo))}  // this gives a mod function that remains
consistant across the origin
#declare Sqr = function (N) {N*N}

#declare ArmSpacing = 0.004;
#declare LineThickness = 0.0004;

#declare Aspect = image_width/image_height;
#declare U = function {x/image_width*Aspect}
#declare V = function {y/image_height}

#declare Angle = function {atan2 (V(x,y,z), U(x,y,z))}
#declare l = function {Distance (U(x,y,z), V(x,y,z), 0)}

#declare Offset = function {l(x,y,z) + ArmSpacing * (Angle(x,y,z)/(tau))}
#declare circles = function {fmod (Offset(x,y,z), ArmSpacing)}

#declare FracTurn = function {abs (l(x,y,z)/ArmSpacing - Angle(x,y,z)/(tau))}
#declare ArcLength = function (b, _Theta) {b/2 * (_Theta * sqrt (1 +
_Theta*_Theta) + ln (_Theta + sqrt (1 + _Theta*_Theta)))}

#declare f_Spiral = function {select (circles (x,y,z) - LineThickness, 0, 1)}

Plenty of other spirals out there to code up and experiment with, once I get
some of this other heavy-lifting out of the way.

Maybe we could/should have a website topic every month / quarter, and solicit
submissions for algorithms, functions, patterns, renders, etc. and have
something new and fresh on the POV-Ray homepage.

(I still think that getting out there on social media, and promoting POV-Ray is
the way forward wrt to finding new talent, and new people to help write source
so that we can fix bugs, add new features, and brainstorm a workable fresh start
with 4.0.)

- BW

[William F Pokorny] Re: Direct stochastic tiling [895 days 1 hour and 38 minutes ago]

Fri, 3 Nov 2023 12:35:39 GMT

On 11/2/23 18:19, Bald Eagle wrote:
> I think this would be a nice basic stock pattern for POV-Ray.
> I set the spiral turn spacing to twice the line thickness to get a "maximally
> dense" spiral.

I'm interested - FWIW. :-)

Maybe 5-6 weeks back I started to dig more into our warp{} code. I'd 
like to rework it all, including a bunch of hacks I have in that code. 
Then stuff, and more stuff, and it's on the back burner of the stove 
again...

One thing I'd like to do in yuqk is dump the two inbuilt spiral patterns 
for more general, tapered spiral warping as one or more additional 
options of the warp{} mechanism.

We have too f_spiral() - which has issues - as you well know. The 
solutions to which, I believe, sit more with some sort of general 
tapered warping capability.

Aside: We can today implement a limited form of the sort of spiral - I 
think you're implementing - with a series of half arc functions (there 
is too the new-ish list_object pattern in yuqk which could use the torus 
or functions via coded isosurfaces(a) (inside tests)). This approach, 
however, slows down significantly on the addition of each half arc.

(a) The inside test of 'isosurface shapes' is relatively fast when used 
for object based patterns. It's just whether the function returns a 
negative value or not at a given location. In fact, 'isosurface shapes 
for inside test purposes' do not need to be good isosurfaces with 
respect to being render-able as actual shapes!

Anyhow, I'm interested in seeing what code you work up.

Bill P.

[Bald Eagle] Re: Direct stochastic tiling [895 days 14 hours and 14 minutes ago]

Fri, 3 Nov 2023 00:00:00 GMT

It also seems to me that in addition to knowing if I'm on of off/in-between the
spiral, I'll need to somehow be able to know how far along the arc length of the
spiral I am at any given point.

Varying the r, g, and b values by different multiples of the arc length formula,
and changing the thickness of the lines as a function of arc length gives me the
attached.

- BW

[Bald Eagle] Re: Direct stochastic tiling [895 days 15 hours and 54 minutes ago]

Thu, 2 Nov 2023 22:20:00 GMT

Slowing working through things.

To help me work through understanding how to use the end result of all of the
daisy-chained algorithms in an actual texture, I needed to understand how to
remap <x, y> into <r, theta>

So here's a nice pigment {function {}} to make an infinite spiral in the xy
plane.

(Thanks again, ShaderToy coders!)

I think this would be a nice basic stock pattern for POV-Ray.
I set the spiral turn spacing to twice the line thickness to get a "maximally
dense" spiral.

- BW

[William F Pokorny] Re: No semicolon allowed in Tuple-style assignme... [896 days 4 hours and 9 minutes ago]

Thu, 2 Nov 2023 10:05:05 GMT

On 11/1/23 09:51, William F Pokorny wrote:
> The short of what I wrote is I just ran across some buggy tuple behavior 
> trying to assign results from a macro.

Fixed in my yuqk fork. The error was in code I added to better handle 
empty parentheses in certain situations. The return state was wrong 
which confused the parser at the tuple assignment.

In official v3.8 parsers the test case generates unbalanced parentheses 
errors on some sets of balanced ones - where the inner most pair is empty.

Bill P.

[Bald Eagle] Re: Direct stochastic tiling [896 days 14 hours and 9 minutes ago]

Thu, 2 Nov 2023 00:05:00 GMT

Working through the spiral part of:

http://flycooler.com/download/Wood_SIGAsia2016.pdf

And struggling to understand

1) how the texture actually gets mapped/tiled onto the spiral

and

2) what points then, am I interpolating?

I'm guessing that either the 2D texture get mapped once onto each successive
turn of the spiral,
or it gets mapped linearly onto the nonlinear arc-length of the spiral arms, and
so there are then spaces between the x-dimension points?

Maybe someone could look at this and offer some ideas?
Even if you're just shooting in the dark, whatever you suggest might trigger an
idea for a solution.

Thanks!

- BW

[Bald Eagle] Re: Direct stochastic tiling [896 days 14 hours and 19 minutes ago]

Wed, 1 Nov 2023 23:55:00 GMT

Made some progress sorting out the whole "sparse convolution noise".

Probably don't need to pursue this part any further until i see how it works in
the whole texture-generating chain of algorithms.

[William F Pokorny] Re: No semicolon allowed in Tuple-style assignme... [897 days and 22 minutes ago]

Wed, 1 Nov 2023 13:51:27 GMT

On 5/3/23 15:36, Bald Eagle wrote:
> I am back at it, and still experiencing a lot of weird behaviour with 
> regard to assigning tuple-style values via macros.

Well, another longer post just went poof...

The short of what I wrote is I just ran across some buggy tuple behavior 
trying to assign results from a macro.

[jr] Re: Direct stochastic tiling [906 days 18 hours and 29 minutes ago]

Sun, 22 Oct 2023 19:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Re: Voronoi Furtune algorithm
> ...
> Update here - jr has been leading me by the nose-hairs ...

_that's_ what they were, eh ?!  </grin>


> to get the binary tree / Red-Black tree coded up, and hopefully we (mostly he) will
have some code we can
> start to play with soon.

to tease..


regards, jr.

[Bald Eagle] Re: Direct stochastic tiling [913 days 13 hours and 39 minutes ago]

Mon, 16 Oct 2023 00:35:00 GMT

Re: Voronoi Furtune algorithm

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I played around with starting to implement the Fortune algorithm for the
> Voronoi diagram, but I also need a DCEL and a red-black tree data structure, a
> balanced binary tree, or similar.

Update here - jr has been leading me by the nose-hairs to get the binary tree /
Red-Black tree coded up, and hopefully we (mostly he) will have some code we can
start to play with soon.

> Someone said it was easier to code the Bowyer-Watson algorithm, so I might try
> to code both in parallel and see which one (if any) I get to work first.

Admittedly, I have not started on that one yet.

The RB-tree and the DCEL are used for storing the data for/from the Fortune
algorithm, and that seems to be mostly the results of "site events" and "circle
events".

The site event seems trivial (scanline is the same height as a voronoi seed),
and so I worked out the detection of a circle event (the intersection of 3
parabolas)  to the best of my meager ability.

Shown is the point where the scanline generates a circle event, where the seeds
are all equidistant from each other and the scanline, and so all lie on a
circumcircle, with the Voronoi vertex at the center.

- BW

[Bald Eagle] Re: Direct stochastic tiling [934 days 14 hours and 34 minutes ago]

Sun, 24 Sep 2023 23:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
So, I played around with starting to implement the Fortune algorithm for the
Voronoi diagram, but I also need a DCEL and a red-black tree data structure, a
balanced binary tree, or similar.

I got a bunch of points and a scan line, and managed to plot all of the
parabolas and kind of draw some of the Voronoi edges by looping all the way down
the screen and plotting all of the intersection points.
It took a long time to spot a pair of missing parentheses that I should have
had.
Repeat after me: -b +/- sqrt (b*b -4*a*c)    ***ALL*** over 2*a
which makes it (-b +/- sqrt (b*b -4*a*c)) / 2*a

Someone said it was easier to code the Bowyer-Watson algorithm, so I might try
to code both in parallel and see which one (if any) I get to work first.

For that, I need to test if a point lay inside of a triangle's circumcircle, and
luckily someone had a nice little simple compact method for doing so.

I always find it fascinating how many geometric questions can be answered just
by simple arithmetic of point coordinates, be it sum, difference,
multiplication, vdot, vcross, or a matrix determinant.

We would be served well by compiling a list of such useful tricks and
maintaining that on a wiki page, or in the documentation, or as a periodically
updated (with version number and date) include file.

I also find these simple inside/outside test renders to be unusually visually
appealing for some reason.  Attached is the testing of 5000 points against a
triangle's circumcircle.

If there was a band named POV-Ray (a college friend had a band named Man Ray)
this would make a good album cover.   :D

- BE

[kurtz le pirate] Re: Direct stochastic tiling [936 days 5 hours and 27 minutes ago]

Sat, 23 Sep 2023 08:47:00 GMT

On 23/09/2023 01:30, Bald Eagle wrote:

> 
> One thing that I did notice is that I'm splicing out array entries until I have
> an empty array.
> 
> That was triggering an invalid array size error, which I fixed / worked around
> by doing:
> 
> #if (newSize <= 0)
>   #local tmpArray = array;
>  #else
>   #local tmpArray = array[newSize]
>  #end
> 
> and
> 
> #if (newSize <= 0)
>   #declare thisArray = array;
>  #else
>   #declare thisArray = array[newSize]
>  #end
> 
> 
> Maybe do some further testing and see what you think, then update that last
> macro.
> 


AAs always, that's a very good remark on your part.

I've never thought about the cases where the arrays are empty.

I'm going to apply your suggestions, correct my macros and
run more in-depth tests.







-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Direct stochastic tiling [936 days 14 hours and 19 minutes ago]

Fri, 22 Sep 2023 23:55:00 GMT

Alrighty.

I managed to work through a bunch of the code and twiddle this and that until I
got it to "work" and pretty much fill the screen with selected points.

The first issue that I ran into was that I was doing some kind of "screen size
math" which was just messing everything up, so I'm just using the whole image
resolution.

Then I managed to get a bunch of cycles to function, but the algorithm would
exit early - sometimes after only 7 cycles.

I added some logic to break out of the nested loops, and then I expanded the
neighbor search to a 5x5 grid, as suggested/explained/illustrated by Sebastian
Lague.

It still runs forever without a bailout value set, instead of exhausting the
Active array and properly exiting the macro.

Finally, the points are clustered much too closely - I ought to be able to draw
circles with radius R that don't overlap, and the attached image is using
circles that are only R/4.

Clearly POV-Ray is very different than Javascript or C#, or I'm really in a long
stretch of brain-fry or code blindness and am missing something very simple but
utterly crucial.

- BW

[Bald Eagle] Re: Direct stochastic tiling [936 days 14 hours and 39 minutes ago]

Fri, 22 Sep 2023 23:35:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> maybe this inc file can help you?

One thing that I did notice is that I'm splicing out array entries until I have
an empty array.

That was triggering an invalid array size error, which I fixed / worked around
by doing:

#if (newSize <= 0)
  #local tmpArray = array;
 #else
  #local tmpArray = array[newSize]
 #end

and

#if (newSize <= 0)
  #declare thisArray = array;
 #else
  #declare thisArray = array[newSize]
 #end


Maybe do some further testing and see what you think, then update that last
macro.

- BW

[Bald Eagle] Re: Direct stochastic tiling [936 days 20 hours and 9 minutes ago]

Fri, 22 Sep 2023 18:05:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> maybe this inc file can help you?

Yes Sir, that would probably help me avoid debugging THAT part, and see what
else I've buggered up.

Thanks - that's very nice little collection of very useful macros!   :)


- BW

[kurtz le pirate] Re: Direct stochastic tiling [936 days 22 hours and 48 minutes ago]

Fri, 22 Sep 2023 15:25:49 GMT

On 22/09/2023 02:37, Bald Eagle wrote:

> I have coded the first one, but it doesn't work, because I probably messed up my
> push/splice macros, and I have to work out the array indices, because those are
> going awry as always.   :/

maybe this inc file can help you?





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Direct stochastic tiling [937 days 3 hours and 44 minutes ago]

Fri, 22 Sep 2023 10:30:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > These "computer science" papers are all shit
>
> Have you tried a search engine lately? Top 20 lists ... Stupid AI's ....
>
> ingo <ducks and hides>

Yeah - they're all changing - for the worst.
https://www.youtube.com/watch?v=48AOOynnmqU

I used to used duck duck go for a bit - until they sold out.
Then I switched primarily to Brave, but they stopped having useful search
results.
I find myself using Yandex a lot.

It's painful to have lived through "the golden age of the internet" and know
that all that stuff is out there  ---- somewhere.

The other thing that I find strange is that I'll get a list of search results,
and when I click on one of the top ones, the site is nonexistent.  So then
what's the result doing in the list?  How do I have an image thumbnail that goes
along with it, but can't get anywhere to see the image???

It's getting really weird.

[ingo] Re: Direct stochastic tiling [937 days 8 hours and 39 minutes ago]

Fri, 22 Sep 2023 05:35:00 GMT

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

> These "computer science" papers are all shit

Have you tried a search engine lately? Top 20 lists ... Stupid AI's ....

ingo <ducks and hides>

[Bald Eagle] Re: Direct stochastic tiling [937 days 13 hours and 34 minutes ago]

Fri, 22 Sep 2023 00:40:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > Not sure I'm looking forward to the Poisson disk part of this....
>
> There is a poisson distribution in rand.inc, if it helps.
>
> ingo

Thanks, but I went over that several times, and can't for the life of me figure
out what that does or how to implement / visualize it.  I think that somehow
that's a "different" Poisson distribution.

"The number of point in an area A is Poisson-distributed with mean equal to the
area times the density. For this reason, the distribution is often called a
Poisson distribution.  This unfortunate terminology should not be confused with
the univariate discrete Poisson distribution."
http://www.dgp.toronto.edu/~elf/.misc/poissondisk.pdf (bottom of pg 3)

I think that basically what I need is:

https://www.youtube.com/watch?v=flQgnCUxHlw
https://editor.p5js.org/codingtrain/sketches/4N78DFCXN

https://www.youtube.com/watch?v=7WcmyxyFO7o
https://github.com/SebLague/Poisson-Disc-Sampling/tree/master/Poisson%20Disc%20Sampling%20E01

I have coded the first one, but it doesn't work, because I probably messed up my
push/splice macros, and I have to work out the array indices, because those are
going awry as always.   :/

These "computer science" papers are all shit - since there's no code, and
therefore no way to verify/reproduce their work.  As a chemist, I had to give a
full, detailed experimental procedure, plus physical characteristics, spectral
data, etc.

"Find the center of gravity of the Voronoi region...."
Oh yeah, buddy.   Go cut down the tallest tree in the forest with .... A
HERRING!

- BW

[ingo] Re: Direct stochastic tiling [938 days 1 hour and 34 minutes ago]

Thu, 21 Sep 2023 12:40:00 GMT

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

> Not sure I'm looking forward to the Poisson disk part of this....

There is a poisson distribution in rand.inc, if it helps.

ingo

[Bald Eagle] Re: Direct stochastic tiling [938 days 3 hours and 44 minutes ago]

Thu, 21 Sep 2023 10:30:00 GMT

Also, here's a zoomed-in version, with thicker borders, and some rgb 0 cylinders
to separate the unit squares so that the tile structure is a lot more evident.

Not sure I'm looking forward to the Poisson disk part of this....

[Bald Eagle] Re: Direct stochastic tiling [938 days 3 hours and 49 minutes ago]

Thu, 21 Sep 2023 10:25:00 GMT

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

> Would you like to not lose your mind trying to figure out why patterns don't do
> what you think they're supposed to do?

After I posted this, I was looking at the rendered pattern, and noticed that
there was a lot of red, and very very little yellow, and since there's been
commentary on just how improbably it is to get an actual 1 or 0 from the PRNG, I
wondered what the spread of f_noise3d in functions.inc was.

It sucks.

After a few failed attempts to coax the output to cover a greater range, I took
5 noise samples at scales increasing by powers of 10, and did 1+2-3+4-5, and
then folded any out of range results back in with 2 nested select () functions.
That seemed to give a much more uniformly distributed random result, and a much
more varied coloration to the pattern.

- BE

[Bald Eagle] Direct stochastic tiling [938 days 12 hours and 9 minutes ago]

Thu, 21 Sep 2023 02:05:00 GMT

Following through a long train of papers and references therein, I picked a part
of one that looked "simple" to implement.

The attached is a "Direct stochastic tiling" pattern that assigns any unit
square a random, but calculable Wang tile.  The edge color of any Wang tile
matches the edge of any adjacent Wang tile.

https://graphics.cs.kuleuven.be/publications/LD05PODF/LD05PODF_paper.pdf

Since it's a pattern, it's all functions.

Would you like to not lose your mind trying to figure out why patterns don't do
what you think they're supposed to do?  Especially across the origin?
Stop using mod (), and use the user-defined function:

#declare fmod = function (N, Modulo) {select (N, 1-mod(abs(N), Modulo), mod
(abs(N), Modulo))}

And use that wherever you need x, y, or z in a repeating unit-square pattern.

- BE

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [945 days 1 hour and 10 minutes ago]

Thu, 14 Sep 2023 13:04:02 GMT

Op 13-9-2023 om 19:33 schreef ingo:
> An other option, if you want to shape an island, in the insert menu/special
> shapes/meshmaker.inc/p_cylinder_crackle2 shows how to do displacement of mesh
> vertices. This in principle works for all things one can make with the mesh
> macros. You could extrude the island shape and then deform the mesh or build the
> island shape with multiple splines.
> 

I correctly remembered I had played some with meshmaker. I used in the 
example included, a granite pattern, heavily scaled up in the horizontal 
directions. Not a sedimentary pattern but I see where to go from here.

-- 
Thomas

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [945 days 1 hour and 16 minutes ago]

Thu, 14 Sep 2023 12:57:08 GMT

Op 14-9-2023 om 12:49 schreef Bald Eagle:
> Excellent.
> Here's another one where I just rendered the faces of the boxes as meshes and
> added in a function to give some tectonic sqooshing of the lateral layers of the
> strata.
> 
> Very quick, buggy early morning WIP.

For a quick buggy, it is a ride I would not have missed! ;-)

Very good indeed; it is development full of promises.

-- 
Thomas

[Bald Eagle] Re: Editing or creating an image or heightfield ... [945 days 3 hours and 24 minutes ago]

Thu, 14 Sep 2023 10:50:00 GMT

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

> Yes indeed. Thanks Bill. My main problem at the moment is that I have so
> little time to do some significant experiments, and I fail to come
> across those things I did already in the past on this very same chapter.

That is indeed the ebb and flow of what we do here.
A long, prolonged and eerie silence, followed by a sudden flurry of frenetic
activity.

> Patience! I shall tackle all this asap and see where it brings me; there
> are a couple of ideas you and ingo have reawakened that I want to pursue.

Excellent.
Here's another one where I just rendered the faces of the boxes as meshes and
added in a function to give some tectonic sqooshing of the lateral layers of the
strata.

Very quick, buggy early morning WIP.

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [945 days 7 hours and 32 minutes ago]

Thu, 14 Sep 2023 06:42:02 GMT

Op 13/09/2023 om 22:00 schreef Bald Eagle:
> So, this is just boxes with a granite texture, nothing fancy yet.

Yes indeed. Thanks Bill. My main problem at the moment is that I have so 
little time to do some significant experiments, and I fail to come 
across those things I did already in the past on this very same chapter. 
Patience! I shall tackle all this asap and see where it brings me; there 
are a couple of ideas you and ingo have reawakened that I want to pursue.

-- 
Thomas

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [945 days 7 hours and 38 minutes ago]

Thu, 14 Sep 2023 06:35:18 GMT

Op 13/09/2023 om 19:33 schreef ingo:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Thanks for the pointer, Ingo!
>>
> 
> Here's an other version, using a patter function for the structure. First a
> union{hf box} then the intersection.
> 
> An other option, if you want to shape an island, in the insert menu/special
> shapes/meshmaker.inc/p_cylinder_crackle2 shows how to do displacement of mesh
> vertices. This in principle works for all things one can make with the mesh
> macros. You could extrude the island shape and then deform the mesh or build the
> island shape with multiple splines.
> 
> ---%<------%<------%<---
> 
> // PoVRay 3.7 Scene File " hf_intersection_2.pov"
> // author:  ingo
> // date:    2023-09-13
> //--------------------------------------------------------------------------
> 
> #version 3.7;
> global_settings{ assumed_gamma 1.0 }
> #default{ finish{ ambient 0.1 diffuse 0.7 }}
> 
> camera {
>    perspective angle 5               // front view
>    location  <20.0 , 0.0 ,-40.0>
>    right     x*image_width/image_height
>    look_at   <0.0 , 0.0 , 0.0>
> }
> 
> light_source{< 3000, 3000,-6000> rgb 1}
> 
> sky_sphere {
>    pigment {
>      gradient <0,1,0>
>      color_map {
>        [0.00 rgb <0.6,0.7,1.0>]
>        [0.35 rgb <0.1,0.0,0.8>]
>        [0.65 rgb <0.1,0.0,0.8>]
>        [1.00 rgb <0.6,0.7,1.0>]
>      }
>      scale 2
>    }
> }
> 
> 
> #declare Rock = union {
>    intersection{
>      height_field {
>        function 1000,1000 {
>          pattern {
>            gradient -y
>            scale .1
>            turbulence 0.7
>            octaves 12
>            lambda 1.5
>            omega 0.3
>          }
>        }
>      }
>      box{0,1.001}
>      scale <1,0.05,1>
>    }
>    box{<0,0,0>,<1,-1,1>}
>    translate <-0.5,0.5,-0.5>
> }
> 
> intersection{
>    object{
>      Rock
>      translate <0,-0.1,0>
>      pigment{rgb 1}
>    }
> 
>    object{
>      Rock
>      rotate <-90,0,0>
>      translate <0,0,0.1>
>      pigment{rgb 1}
>    }
> 
>    object{
>      Rock
>      rotate <90,90,0>
>      translate <-0.1,0,0>
>      pigment{rgb 1}
>    }
> 
>    rotate <-45,0,0>
> }
> 
> ---%<------%<------%<---
> 
> You can modify the patterns in the HF_function with the functions in
> https://ingoogni.nl/download/Gradients.zip
> 
> 
> ingo
> 
Thanks for all this ingo, very much appreciated indeed. I need to review 
all this at leisure.

I used displacement mapping a couple of years ago for stoneworks, using 
Poseray:

https://news.povray.org/povray.binaries.images/thread/%3C60e02637%40news.povray.org%3E/

And (I think) I tackled Meshmaker too somewhere/-time in a similar 
manner. I really /need/ to delve deeper in my archives (and my hazy 
memory).... :-/

-- 
Thomas

[Bald Eagle] Re: Editing or creating an image or heightfield ... [945 days 18 hours and 9 minutes ago]

Wed, 13 Sep 2023 20:05:00 GMT

So, this is just boxes with a granite texture, nothing fancy yet.

[Bald Eagle] Re: Editing or creating an image or heightfield ... [945 days 20 hours and 34 minutes ago]

Wed, 13 Sep 2023 17:40:00 GMT

I think that if you did something like make a brick wall out of mesh blocks, in
the manner of building a wood floor, then you could "erode" the faces ad
abutting edges of all the blocks according to hardness assigned by a noise
function, and you could vary the height of the lateral strata, and govern the
shape of the protruding layer by using something like an x=pow(y, N) type
function that gets more square with higher powers (superellipsoid).

For that matter, you could even try just stacking superellipsoids to see how
that works.

Building the cliff with individual blocks would allow you to govern the size and
width of each piece, and allow indexing of any individual block.  You could also
remove or fracture out the majority of an individual block.

Also, going with the heightfield thing, you could just use a base heightfield
image for the basic clock, and then perturb it with a noise function, but rotate
it on its side, and scale it be a "block".

- BW

[ingo] Re: Editing or creating an image or heightfield ... [945 days 20 hours and 39 minutes ago]

Wed, 13 Sep 2023 17:35:00 GMT

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

> Thanks for the pointer, Ingo!
>

Here's an other version, using a patter function for the structure. First a
union{hf box} then the intersection.

An other option, if you want to shape an island, in the insert menu/special
shapes/meshmaker.inc/p_cylinder_crackle2 shows how to do displacement of mesh
vertices. This in principle works for all things one can make with the mesh
macros. You could extrude the island shape and then deform the mesh or build the
island shape with multiple splines.

---%<------%<------%<---

// PoVRay 3.7 Scene File " hf_intersection_2.pov"
// author:  ingo
// date:    2023-09-13
//--------------------------------------------------------------------------

#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.7 }}

camera {
  perspective angle 5               // front view
  location  <20.0 , 0.0 ,-40.0>
  right     x*image_width/image_height
  look_at   <0.0 , 0.0 , 0.0>
}

light_source{< 3000, 3000,-6000> rgb 1}

sky_sphere {
  pigment {
    gradient <0,1,0>
    color_map {
      [0.00 rgb <0.6,0.7,1.0>]
      [0.35 rgb <0.1,0.0,0.8>]
      [0.65 rgb <0.1,0.0,0.8>]
      [1.00 rgb <0.6,0.7,1.0>]
    }
    scale 2
  }
}


#declare Rock = union {
  intersection{
    height_field {
      function 1000,1000 {
        pattern {
          gradient -y
          scale .1
          turbulence 0.7
          octaves 12
          lambda 1.5
          omega 0.3
        }
      }
    }
    box{0,1.001}
    scale <1,0.05,1>
  }
  box{<0,0,0>,<1,-1,1>}
  translate <-0.5,0.5,-0.5>
}

intersection{
  object{
    Rock
    translate <0,-0.1,0>
    pigment{rgb 1}
  }

  object{
    Rock
    rotate <-90,0,0>
    translate <0,0,0.1>
    pigment{rgb 1}
  }

  object{
    Rock
    rotate <90,90,0>
    translate <-0.1,0,0>
    pigment{rgb 1}
  }

  rotate <-45,0,0>
}

---%<------%<------%<---

You can modify the patterns in the HF_function with the functions in
https://ingoogni.nl/download/Gradients.zip


ingo

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [945 days 23 hours and 10 minutes ago]

Wed, 13 Sep 2023 15:03:31 GMT

Op 13-9-2023 om 13:45 schreef ingo:
> 
> simple quick example of HF intersection (the Mount2.png is in the 3.7
> distribution):
> 
> ---%<------%<------%<---
> // PoVRay 3.7 Scene File " hf_intersection.pov"
> // author:  ingo
> // date:    2023-09-13
> //--------------------------------------------------------------------------
> #version 3.7;
> global_settings{ assumed_gamma 1.0 }
> #default{ finish{ ambient 0.1 diffuse 0.9 }}
> 
> camera {
>    perspective angle 75               // front view
>    location  <0.0 , 4.0 ,-10.0>
>    right     x*image_width/image_height
>    look_at   <0.0 , 1.0 , 0.0>
> }
> 
> light_source{< 3000,3000,-3000> rgb 1}
> 
> sky_sphere {
>    pigment {
>      gradient <0,1,0>
>      color_map {
>        [0.00 rgb <0.6,0.7,1.0>]
>        [0.35 rgb <0.1,0.0,0.8>]
>        [0.65 rgb <0.1,0.0,0.8>]
>        [1.00 rgb <0.6,0.7,1.0>]
>      }
>      scale 2
>    }
> }
> 
> 
> #declare Rock = height_field{
>    png "Mount2.png" smooth double_illuminate
>    translate<-0.5,-0.0,-0.5>
>    scale<9, 2.5, 9>*2
>    texture{
>      pigment { color rgb <0.82,0.6,0.4>}
>    }
>    rotate<0,-110,0>
>    translate<1,0,11>
> }
> 
> intersection{
> 
>    object{Rock}
> 
>    object {
>      Rock
>      scale 1.5
>      rotate <-33,0,-90>
>      translate <-4,-1,0>
>    }
> 
>    object {
>      Rock
>      rotate <0,0,90>
>    }
> 
> 
> ---%<------%<------%<---
> 
> ingo
> 
> 

Right! I had been briefly wondering about something like this, but 
thought it would not really do. However, your example makes me think 
again more seriously. I need to think some more and - above all - play. 
Potential solutions are certainly there indeed.

Thanks for the pointer, Ingo!

-- 
Thomas

[ingo] Re: Editing or creating an image or heightfield ... [946 days 2 hours and 24 minutes ago]

Wed, 13 Sep 2023 11:50:00 GMT

"ingo" <nomail@nomail> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > Could we somehow achieve something similar using functions in POV-Ray,
> > without the help of isosurfaces? That would be my question.
> >
>
> Create hight-fields using functions. Then rotate the one with the 'lines' and
> intersect it with the one with the horizontal landscape.
>
> ingo

simple quick example of HF intersection (the Mount2.png is in the 3.7
distribution):

---%<------%<------%<---
// PoVRay 3.7 Scene File " hf_intersection.pov"
// author:  ingo
// date:    2023-09-13
//--------------------------------------------------------------------------
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}

camera {
  perspective angle 75               // front view
  location  <0.0 , 4.0 ,-10.0>
  right     x*image_width/image_height
  look_at   <0.0 , 1.0 , 0.0>
}

light_source{< 3000,3000,-3000> rgb 1}

sky_sphere {
  pigment {
    gradient <0,1,0>
    color_map {
      [0.00 rgb <0.6,0.7,1.0>]
      [0.35 rgb <0.1,0.0,0.8>]
      [0.65 rgb <0.1,0.0,0.8>]
      [1.00 rgb <0.6,0.7,1.0>]
    }
    scale 2
  }
}


#declare Rock = height_field{
  png "Mount2.png" smooth double_illuminate
  translate<-0.5,-0.0,-0.5>
  scale<9, 2.5, 9>*2
  texture{
    pigment { color rgb <0.82,0.6,0.4>}
  }
  rotate<0,-110,0>
  translate<1,0,11>
}

intersection{

  object{Rock}

  object {
    Rock
    scale 1.5
    rotate <-33,0,-90>
    translate <-4,-1,0>
  }

  object {
    Rock
    rotate <0,0,90>
  }


---%<------%<------%<---

ingo

[ingo] Re: Editing or creating an image or heightfield ... [946 days 4 hours and 29 minutes ago]

Wed, 13 Sep 2023 09:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Could we somehow achieve something similar using functions in POV-Ray,
> without the help of isosurfaces? That would be my question.
>

Create hight-fields using functions. Then rotate the one with the 'lines' and
intersect it with the one with the horizontal landscape.

ingo

[Thomas de Groot] Re: Editing or creating an image or heightfield ... [946 days 7 hours and 38 minutes ago]

Wed, 13 Sep 2023 06:35:33 GMT

Op 10/09/2023 om 18:01 schreef Bald Eagle:
> 
> With regard to TdG's interest in erosion, I was thinking about doing a quick
> test with an image map converted to a height_field.
> 
> The only problem here is that I don't recall if there was a way to edit the
> pixel data in the image_map, or in the height_field, or to somehow use a
> function {} or a 2D array to create an image or heightfield...
> 
> Or maybe a way to add/subtract / overlay onto the base image.
> I can't use arrays in functions, otherwise I could do image_map {function
> {array}}
> 
> It would be useful to not have to load an image, convert that to an array, use
> that array to create a mesh, then use the algorithm I'm experimenting with to
> edit the mesh.....
> 
> Does anyone have any ideas?
> 
> - BW
> 

Real Time is binding me hands and feet, so a belated comment so far.

What I am personally looking for / interested in is not so much the 
generation of natural-looking heightfields in terms of erosional 
patterns like mountains and valleys which is provided by e.g. World 
Machine. In itself it is an interesting topic and I remember (but cannot 
find again) a series of tests some years ago where the drainage patterns 
on in the heightfields were used to generate down-flowing rivers using a 
trace function. I must have a whole collection of examples somewhere 
under the dust but to date I have not been able to find those.

What I am /really/ interested in is the rockface erosion in cliffs and 
such which enhance the natural aspect of any mountain or landscape. As 
an example I attach a photograph of the Faroe Islands showing a cliff 
face, but what you can see are those (sub-)horizontal layers of more or 
less "competent" (= hard/soft) rocks, in the cliff and in the overlying 
landscape. They account for regions where the rock faces are more or 
less overhanging. This is impossible in classical heightfields but easy 
to achieve with isosurfaces of course.

Could we somehow achieve something similar using functions in POV-Ray, 
without the help of isosurfaces? That would be my question.

-- 
Thomas

[Bald Eagle] Re: Editing or creating an image or heightfield ... [946 days 18 hours and 54 minutes ago]

Tue, 12 Sep 2023 19:20:00 GMT

"ingo" <nomail@nomail> wrote:

> Tor Olav has, or at least some inspiration:

Hmmmm.... Very interesting.  I'm gonna need a bit of time to dissect that and
see how all the different parts work.
Knowing TOK, I'll probably walk away with some new lessons well worth learning,
which might give rise to some new inspirations and experiments.

Thanks for the links - I would have never made the connection and thought to
look there. (although I did, of course, suspect that he would have some ideas...
;) )

[Now of course, what we need to do is get him some _free time_ to POV!  :D ]

- BW

[Bald Eagle] Re: Recursive Backtracker Maze Algorithm [947 days 11 hours and 44 minutes ago]

Tue, 12 Sep 2023 02:30:00 GMT

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

> Here's 100 by 100.

"Maybe I'll solve this tomorrow..."
Pffft.  We all know better than that, right?

A* solver took 4 min 5 sec to solve the maze.

- BW

[Bald Eagle] Re: Recursive Backtracker Maze Algorithm [947 days 12 hours and 24 minutes ago]

Tue, 12 Sep 2023 01:50:00 GMT

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

> 5. I'm still not sure how the algorithm "erases" walls, and if that's the issue
> I'm having with the "islands" in the maze - drawing on a canvas and
> instantiating primitives in 3D space are fundamentally different operations.

Because I'm STOOOOPID.
It's really easy to invert the meaning of things, and look at the inverse of a
maze.
After watching the relevant portion and paying very careful attention to the all
to brief explanation, I did a few experiments that highlighted the issue, and
let me unravel everything so that I now have proper, algorithm-correct,
fully-internally-connected mazes.

Here's 100 by 100.  I've already tried a 500 x 500, which is 250,000 cells, and
it works, but I'd have to render it a bit bigger than usual to have it show up
clearly.

[Bald Eagle] Recursive Backtracker Maze Algorithm [947 days 17 hours and 14 minutes ago]

Mon, 11 Sep 2023 21:00:00 GMT

So, since I got the A* pathfinding algorithm to function, I figured that I ought
to have a maze generator to go along with it.

I got most of the thing coded and sort of working by last night, and then spent
~3h today after work trying to puzzle out where the rest of it was going wrong.

1. The &'s and |'s in POV-Ray's #if statements ALL get evaluated, so if you want
#if something
(then)
#if something else

then it needs to be coded that way instead of #if (S & SE)

2. I think I missed a few lines of code, because the guy's live-coding screen
real estate sucks, and he's really loosey-goosey with RT explanations, and
moving forward at a pretty good clip with the copy-paste

3. I believe that maybe the bitwise_and and bitwise_or may work differently in
POV-Ray than in c++, since I seemed to be getting cross-talk in the logic he was
using with the values 1, 2, 4, 8, and 10.
So I switched the last to 16 and all was well.

AFAIK, we don't have any base-conversion functions, keywords, or macros in the
distribution, and I could swear that I wrote some decimal to binary and back
conversion macros - but I can't find them and had to write another one from
scratch to verify the behaviours of the bitwise operators.

4. I had to write my own stack to push and pop from, and thankfully there wasn't
any dynamic resizing of the c++ "vector" he was using.
I also had trouble with the modulo method he was using to select a random
element of the vector, so I used RRand from rand.inc.

5. I'm still not sure how the algorithm "erases" walls, and if that's the issue
I'm having with the "islands" in the maze - drawing on a canvas and
instantiating primitives in 3D space are fundamentally different operations.

https://www.youtube.com/watch?v=Y37-gB83HKE
https://github.com/OneLoneCoder/Javidx9/blob/master/ConsoleGameEngine/SmallerProjects/OneLoneCoder_Mazes.cpp

Anyway, here's a maze in a 50 x 50 grid. Enjoy.

- BW

Could be cool to do some movie/video scenes featuring mazes
Labyrinth
Harry Potter and the Goblet of Fire
Hellbound: HellRaiser II
Katy Perry - Wide Awake
The Shining
Pan's Labyrinth

etc.

[ingo] Re: Editing or creating an image or heightfield ... [948 days 4 hours and 29 minutes ago]

Mon, 11 Sep 2023 09:45:00 GMT

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

> Does anyone have any ideas?

Tor Olav has, or at least some inspiration:

https://github.com/t-o-k/POV-Ray-gaussian-blur/blob/master/Examples/Blur_Image_Region.png

https://github.com/t-o-k/POV-Ray-gaussian-blur/blob/master/Examples/Blur_Image_Region.pov

ingo

[kurtz le pirate] Re: Editing or creating an image or heightfield ... [948 days 4 hours and 38 minutes ago]

Mon, 11 Sep 2023 09:35:24 GMT

On 10/09/2023 18:01, Bald Eagle wrote:
> 
> With regard to TdG's interest in erosion, I was thinking about doing a quick
> test with an image map converted to a height_field.
> 
> The only problem here is that I don't recall if there was a way to edit the
> pixel data in the image_map, or in the height_field, or to somehow use a
> function {} or a 2D array to create an image or heightfield...
> 
> Or maybe a way to add/subtract / overlay onto the base image.
> I can't use arrays in functions, otherwise I could do image_map {function
> {array}}
> 
> It would be useful to not have to load an image, convert that to an array, use
> that array to create a mesh, then use the algorithm I'm experimenting with to
> edit the mesh.....
> 
> Does anyone have any ideas?
> 
> - BW
> 



Long time ago, I made a code that, given a png image, would plot for
each pixel a box of the original color and store this value in a 2d array.
ï»¿ï»¿
Code attached


Maybe it can give you some ideas for your problem ?




-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Editing or creating an image or heightfield ... [948 days 16 hours and 44 minutes ago]

Sun, 10 Sep 2023 21:30:00 GMT

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

> I guess I'll just bite the bullet and remember how to make a mesh, calculate the
> normals, make smooth triangles..... {sigh}.

I abandoned an A* driven method in favor of using existing algorithms instead of
starting from scratch with no real idea what I'm doing.  (A* might be useful for
filling in the terrain with water cascading downhill via the erosion paths.)

So, I made the meshes, calculated the normals, made the smooth_triangles, edited
a small erosion algorithm, ran it a few times (which took longer that it should
have), and then added some elapsed time code.
Had to hack the algorithm to get rid of the deep pitting.

My meshes look terrible, my color_map is all off, etc.

I'm using a tiny 358 x 358 image for my terrain.  That's 128164 pixels or 256328
triangles (maybe a few less).

I then drop 20,000 raindrops that undergo a max of 50 erosion/deposition cycles.

No idea what the parameter values ought to be.

Building HeightField array ...
Took 2.47 sec to build the HeightField array.
Making starting mesh ...
Took 59.70 sec to build the starting mesh.
Took 1.43 min to erode starting mesh.
Making eroded mesh ...
Took 1.08 min to make the Eroded mesh.

Parser Time
  Parse Time:       0 hours  3 minutes 32 seconds (212.499 seconds)
Elapsed time 215.84 seconds.

That's an awful damned long time to build a stinking mesh, especially since the
array gets populated in 2.47 sec.

Anyway, it's a start, and I'm sure there are improvements to be made, for those
interested in having a go at it.

- BW

[Bald Eagle] Re: Editing or creating an image or heightfield ... [948 days 20 hours and 4 minutes ago]

Sun, 10 Sep 2023 18:10:00 GMT

"ingo" <nomail@nomail> wrote:

> Does the starting point have to be an image? You can use a function in a HF.
> https://wiki.povray.org/content/Reference:Function_Pattern#Function_Image

Good to know, sorry that you lost your archive.

I've (ab)used splines in functions, but I don't know if I could do that in 2D to
get a heightfield.

I could use a function to make the HF, but I'm still presently at a loss for how
I'd modify the values at each <x, y> position, since I still can't make discrete
modifications, due to the nature of functions, etc.  Going around in circles.

It seems like we _should_ have a way to "write" to the <x,y> pixel data stored
in memory after POV-Ray loads an image file, but we don't.
It also seems like we _should_ have a way to make images and HF's from a 2D
array, but we don't.

I guess I'll just bite the bullet and remember how to make a mesh, calculate the
normals, make smooth triangles..... {sigh}.

I was just hoping for an easier, lazier way.

- BW

[ingo] Re: Editing or creating an image or heightfield ... [948 days 20 hours and 29 minutes ago]

Sun, 10 Sep 2023 17:45:00 GMT

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

> Does anyone have any ideas?
>
> - BW

Does the starting point have to be an image? You can use a function in a HF.
https://wiki.povray.org/content/Reference:Function_Pattern#Function_Image

ingo

[ingo] Re: Editing or creating an image or heightfield ... [948 days 21 hours and 4 minutes ago]

Sun, 10 Sep 2023 17:10:00 GMT

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

> Does anyone have any ideas?
>
> - BW

Not elegant, but you can abuse splines as arrays in functions.

In a distant past we've had several discussions on erosion. I had a look but
can't find it (my archive is lost). I then made an animation or images using
DF3's. Not in POV-Ray it self but in Python.

I randomly dropped rain drops on the DF3. Every rain drop had a strength. The
density of the DF3 was the density/hardness of the stone. When eroding the
raindrop lost some strength and the stone lost some density. The harder the rock
the more costly it was for the drop.

Then, if there was still some 'life' in it, the raindrop would move to the
nearest neighbor with the lowest density and repeat the process until the drops
strength was zero.

I also did it with a combination of Hf and DF3, the HF was the landscape and the
DF3 the rock/soil. Then I eroded the HF away.

Christoph Hormann, ABX were also working on this, i.i.r.c.

ingo

[Bald Eagle] Editing or creating an image or heightfield in P... [948 days 22 hours and 9 minutes ago]

Sun, 10 Sep 2023 16:05:00 GMT

With regard to TdG's interest in erosion, I was thinking about doing a quick
test with an image map converted to a height_field.

The only problem here is that I don't recall if there was a way to edit the
pixel data in the image_map, or in the height_field, or to somehow use a
function {} or a 2D array to create an image or heightfield...

Or maybe a way to add/subtract / overlay onto the base image.
I can't use arrays in functions, otherwise I could do image_map {function
{array}}

It would be useful to not have to load an image, convert that to an array, use
that array to create a mesh, then use the algorithm I'm experimenting with to
edit the mesh.....

Does anyone have any ideas?

- BW

[kurtz le pirate] Re: A-Star algorithm Image Test [949 days and 32 minutes ago]

Sun, 10 Sep 2023 13:42:04 GMT

On 09/09/2023 19:19, Bald Eagle wrote:
> So, I grabbed some code off the wayback machine for the A* algorithm in visual
> c++, and converted all of that to POV-Ray SDL.
> 
> Although I still probably need to go back in and fix some the
> late-night/early-morning edits/hacks that I did in order to get it to run to
> completion without errors, it looks like it works.
> 
> After hand-coding some obstacles in the map array, I figured that I ought to try
> it with a real maze, and the easiest thing to do there was use an image (plus
> that would move me in the direction of applying this to meshes)
> 
> So after a few false starts, I got everything nicely framed on the page, and it
> took this implementation 2 min 20 sec to solve a 500*500 pixel maze image (parse
> & render).
> 
> Enjoy.
> 
> - BE
> 


How brave ! Very good job Bill


-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: A-Star algorithm Image Test [949 days 3 hours and 27 minutes ago]

Sun, 10 Sep 2023 10:46:25 GMT

On 9/9/23 13:19, Bald Eagle wrote:
> After hand-coding some obstacles in the map array, I figured that I ought to try
> it with a real maze, and the easiest thing to do there was use an image (plus
> that would move me in the direction of applying this to meshes)

Cool! :-)

Bill P.

[Bald Eagle] Re: A-Star algorithm Image Test [949 days 17 hours and 59 minutes ago]

Sat, 9 Sep 2023 20:15:00 GMT

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

> wow.  _v_ cool.  (I'm turning that shade of green again.. :-))

Hi jr,
I just took a stab at it, and had a few moments where I was feeling like I had
bit off more than I could chew. As you can imagine, I get that feeling often.

I kinda get how it works - the gist - but there are a few things that I haven't
cleared up, and I haven't looked at the binary heap optimization part.
I basically just edited the code and kept running it and hacking it until it ran
without errors.

> hope you'll publish "a tutorial" on the topic.

I will not, until I have something significantly different from the code I
copied.

https://web.archive.org/web/20051230122239/http://www.policyalmanac.org/games/aStarTutorial.htm
code:
https://web.archive.org/web/20051230122239/http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=turtle17
7604062002002208&comments=no

Other stuff at:

http://theory.stanford.edu/~amitp/GameProgramming/

Sebastian Lague:  https://www.youtube.com/watch?v=mZfyt03LDH4

Daniel Schiffman: https://www.youtube.com/watch?v=EaZxUCWAjb0

Now with regard to TdG's desire to erode terrain, I wanted to find a heightfield
that I could use to run a height-driven A* algorithm on, and wouldn't you know
it - I found a bunch of interesting links.

https://ranmantaru.com/blog/2011/10/08/water-erosion-on-heightmap-terrain/

https://github.com/dandrino/terrain-erosion-3-ways

Sebastian Lague:  https://www.youtube.com/watch?v=eaXk97ujbPQ

https://github.com/LanLou123/Webgl-Erosion

https://jobtalle.com/simulating_hydraulic_erosion.html

https://perso.liris.cnrs.fr/aparis/public_html/posts/terrain_erosion.html

and lots more, I'm sure.

Since this is essentially a cost-optimization algorithm, I was also thinking
that maybe this kind of thing could be used to trace electrical circuits, or
something like that.

Also, conducting erosion on a 3D objects could give more interesting clouds if
rendered as a df3.

- BW

[jr] Re: A-Star algorithm Image Test [949 days 20 hours and 34 minutes ago]

Sat, 9 Sep 2023 17:40:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, ... Enjoy.

wow.  _v_ cool.  (I'm turning that shade of green again.. :-))

hope you'll publish "a tutorial" on the topic.


regards, jr.

[Bald Eagle] A-Star algorithm Image Test [949 days 20 hours and 54 minutes ago]

Sat, 9 Sep 2023 17:20:00 GMT

So, I grabbed some code off the wayback machine for the A* algorithm in visual
c++, and converted all of that to POV-Ray SDL.

Although I still probably need to go back in and fix some the
late-night/early-morning edits/hacks that I did in order to get it to run to
completion without errors, it looks like it works.

After hand-coding some obstacles in the map array, I figured that I ought to try
it with a real maze, and the easiest thing to do there was use an image (plus
that would move me in the direction of applying this to meshes)

So after a few false starts, I got everything nicely framed on the page, and it
took this implementation 2 min 20 sec to solve a 500*500 pixel maze image (parse
& render).

Enjoy.

- BE

[kurtz le pirate] Re: New random distribution macros [951 days 23 hours and 28 minutes ago]

Thu, 7 Sep 2023 14:45:48 GMT

On 03/09/2023 02:44, Bald Eagle wrote:
> It's kind of scary when so many seemingly disparate topics that I've dipped my
> toes into all get brought together into one pretty cool video.
> 
> Enjoy:
> 
> "The BEST Way to Find a Random Point in a Circle"
> https://www.youtube.com/watch?v=4y_nmpv-9lI
> 

This is really a great find !!!!

The result is truly stunning.

For a small number of points, the difference is not obvious. Above about
200 points, there's a really big difference which becomes more and more
apparent as the population increases.

Thanks for the link Bill.

-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: New random distribution macros [956 days 13 hours and 29 minutes ago]

Sun, 3 Sep 2023 00:45:00 GMT

It's kind of scary when so many seemingly disparate topics that I've dipped my
toes into all get brought together into one pretty cool video.

Enjoy:

"The BEST Way to Find a Random Point in a Circle"
https://www.youtube.com/watch?v=4y_nmpv-9lI

[Bald Eagle] Re: [1010 days 14 hours and 44 minutes ago]

Mon, 10 Jul 2023 23:30:00 GMT

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

> (I'm trying to replicate Shadertoy's / GLSL's fwidth () function):

> Forward I plod....

Well, I didn't really get that to work as well as I planned, since it may only
work with (x, y, z) functions and not my (px, py) functions.

I did manage to daisy-chain a massive pile of functions, follow the daisy-chain
of propagated parser errors, "fix" everything to the point where the code runs
without errors, and gives me --- something.
Not really at all what it's supposed to look like, but it's really square one of
translating a lot of complicated Shadertoy code with lots of magic numbers,
ridiculous equations, and very little in the way of explanatory documentation.

But I have hope that fixing it will be easier than that painful first step of
translating the raw code.  I'm sure I've failed to properly daisy-chain some
functions, so I'll go looking there first.

- BW

[Bald Eagle] Re: [1016 days 18 hours and 19 minutes ago]

Tue, 4 Jul 2023 19:55:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Try this:
>
>
> #macro MakeFunction(Fn)
>
>     function(N) { Fn(0) + 1 }
>
> #end // macro MakeFunction

Ah, yes.   I omitted the function parameters, so it was expecting x, y, z or
something.

That works, thanks.

Of course, when trying to debug some other scene doodle, because math.inc was
squawking at me about VEq, I saw that you already wrote probably exactly what i
needed in the form of fn_Gradient_Directional.

(I'm trying to replicate Shadertoy's / GLSL's fwidth () function):

// fwidth is simply the sum of the absolute values of dfdx and dfdy,
// which signifies the window-space rate of change of the parameter in the x and
y axes, respectively.
// You can determine these by using finite differences

Forward I plod....

- BW

[Leroy] Re: [1016 days 19 hours and 54 minutes ago]

Tue, 4 Jul 2023 18:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I had some experiments I wanted to try, but I need to make some functions
> that are based on other functions.
> In order to vary what base function I use, I have to do that with a macro, which
> seems to work fine, but I seem to be missing something, either in the creation
> syntax or the invocation syntax.
>
>
> #declare Zero = function (N) {0}
> #declare One = function (N) {1}
>
>
> #macro MakeFunction (Function)
>  function {Function (0) + 1}
> #end
>
> #declare Two = MakeFunction (One);
>
> #debug concat( "Zero = ", str (Zero (10), 0, 3), "\n")
> #debug concat( "One = ", str (One (10), 0, 3), "\n")
>
> #declare Val = Two (10);
>
> #debug concat( "Two = ", str (Val, 0, 3), "\n")
>
> That gets me:
>
> Parse Error: Expected 'numeric expression', ) found instead
>
> I have yet to find a way around that.  Though I could swear that I've done
> something similar to this before....
>
Here's a macro that will do what you want maybe.
It returns a function of a function

#macro Sf_Inv(F1) //inverse ground values
  function(x,z){1-F1(x,z)}
#end

use like this:

#declare F1=function(x,z){what ever}
#declare FncA=function(x,z){Sf_Inv(F1)}
#declare B=FncA(6,7);

I took this off a whole list of functions I was playing with a while back.
With this basic syntax you can put togather several functions and values to get
some interesting and hopeful useful functions.
Have Fun!

[Tor Olav Kristensen] Re: [1017 days 13 hours and 24 minutes ago]

Tue, 4 Jul 2023 00:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I had some experiments I wanted to try, but I need to make some functions
> that are based on other functions.
> In order to vary what base function I use, I have to do that with a macro, which
> seems to work fine, but I seem to be missing something, either in the creation
> syntax or the invocation syntax.
>
>
> #declare Zero = function (N) {0}
> #declare One = function (N) {1}
>
>
> #macro MakeFunction (Function)
>  function {Function (0) + 1}
> #end
>
> #declare Two = MakeFunction (One);
>
> #debug concat( "Zero = ", str (Zero (10), 0, 3), "\n")
> #debug concat( "One = ", str (One (10), 0, 3), "\n")
>
> #declare Val = Two (10);
>
> #debug concat( "Two = ", str (Val, 0, 3), "\n")
>
> That gets me:
>
> Parse Error: Expected 'numeric expression', ) found instead
>
> I have yet to find a way around that.  Though I could swear that I've done
> something similar to this before....
>
>
> Does anyone have any ideas?

Try this:


#macro MakeFunction(Fn)

    function(N) { Fn(0) + 1 }

#end // macro MakeFunction


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

[Bald Eagle] [1017 days 14 hours and 29 minutes ago]

Mon, 3 Jul 2023 23:45:00 GMT

So, I had some experiments I wanted to try, but I need to make some functions
that are based on other functions.
In order to vary what base function I use, I have to do that with a macro, which
seems to work fine, but I seem to be missing something, either in the creation
syntax or the invocation syntax.


#declare Zero = function (N) {0}
#declare One = function (N) {1}


#macro MakeFunction (Function)
 function {Function (0) + 1}
#end

#declare Two = MakeFunction (One);

#debug concat( "Zero = ", str (Zero (10), 0, 3), "\n")
#debug concat( "One = ", str (One (10), 0, 3), "\n")

#declare Val = Two (10);

#debug concat( "Two = ", str (Val, 0, 3), "\n")

That gets me:

Parse Error: Expected 'numeric expression', ) found instead

I have yet to find a way around that.  Though I could swear that I've done
something similar to this before....


Does anyone have any ideas?



- BW

[William F Pokorny] Re: Speeding up (or faking) scattering media [1021 days 15 hours and 16 minutes ago]

Thu, 29 Jun 2023 22:58:06 GMT

On 6/25/23 17:56, Juergen wrote:
> Hi,
> 
> I made a few attempts over the weekend. I followed the variant "transparent
> cylinder". The result looks quite usable, but there are a few restrictions and
> things to consider.
> 
> In the core I use a (vertical) cylinder. On this cylinder is a gradient texture
> to avoid sharp edges. Finally, the cylinder is rotated so that it is parallel to
> the light rays.
> 
> The constraints are:
> 1. there must be no visible intersection of a cylinder with another object in
> the scene, here you would have sharp, unnatural edges.
> 2. the gradient texture must be aligned with the camera, otherwise the advantage
> of having no sharp edges is lost,
> 3. not too many of these cylinders should be used (about 150), otherwise the
> render time will increase again to the point where you can use the right media.
> 
> JÃ¼rgen

Hi. It does look like a workable solution.

Real life has me busy these days, but I'll mention a couple additional 
things.

Norbert Kern, perhaps a couple years ago (and IIRC), worked out a scheme 
where he created a high field containing media (emitting?) in front of 
his actual scene for light rays through media effects.

Second and FWIW, when I reworked the fog feature in the povr fork, I 
added an 'inverse' feature which creates the densest fog closer to the 
camera rather than at greatest depth. The idea is to make it easier to 
fake media effects with fog{} using special near-camera, otherwise 
invisible/null for ray depth only, shapes. The sad bit is aside from a 
few quick experiments, I've never gotten to really playing with the new 
feature myself...

Bill P.

[Juergen] Re: Speeding up (or faking) scattering media [1025 days 16 hours and 14 minutes ago]

Sun, 25 Jun 2023 22:00:00 GMT

Hi,

I made a few attempts over the weekend. I followed the variant "transparent
cylinder". The result looks quite usable, but there are a few restrictions and
things to consider.

In the core I use a (vertical) cylinder. On this cylinder is a gradient texture
to avoid sharp edges. Finally, the cylinder is rotated so that it is parallel to
the light rays.

The constraints are:
1. there must be no visible intersection of a cylinder with another object in
the scene, here you would have sharp, unnatural edges.
2. the gradient texture must be aligned with the camera, otherwise the advantage
of having no sharp edges is lost,
3. not too many of these cylinders should be used (about 150), otherwise the
render time will increase again to the point where you can use the right media.

Jürgen

[jr] Re: Speeding up (or faking) scattering media [1029 days 8 hours and 9 minutes ago]

Thu, 22 Jun 2023 06:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Short 5 second animation attached.   500 frames at 10 frames/sec.
>
> I guess it looks ok.

agree, better than "ok" even, fwiw :-).  reminds me (a little) of "Art Nouveau"
style.  cheers.


regards, jr.

[Bald Eagle] Re: Speeding up (or faking) scattering media [1029 days 19 hours and 24 minutes ago]

Wed, 21 Jun 2023 18:50:00 GMT

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

> yes :-)

tl;dr


Short 5 second animation attached.   500 frames at 10 frames/sec.

I guess it looks ok.  No idea why it looks so different from the beautiful
Shadertoy result.

[jr] Re: Speeding up (or faking) scattering media [1030 days 6 hours and 54 minutes ago]

Wed, 21 Jun 2023 07:20:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I suppose I ought to animate it to see what that looks like....

yes :-)


regards, jr.

[Bald Eagle] Re: Speeding up (or faking) scattering media [1030 days 14 hours and 54 minutes ago]

Tue, 20 Jun 2023 23:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I found this:
> https://www.shadertoy.com/view/lljGDt
>
> which seems to be the best of a 10-15 min search.

Since it's a shader, it all needs to be converted into functions, and then
rendered as a pigment pattern that controls an average texture.

That took a little bit to make a little 200-line scene, and winnow out all the
stupid trivial mistakes.

I suppose I ought to animate it to see what that looks like....

[Bald Eagle] Re: Speeding up (or faking) scattering media [1030 days 18 hours and 54 minutes ago]

Tue, 20 Jun 2023 19:20:00 GMT

I found this:
https://www.shadertoy.com/view/lljGDt

which seems to be the best of a 10-15 min search.

Other stuff I found (and there's tons):




https://lesterbanks.com/2016/11/underwater-light-rays-volumetrics-c4d/

Also, here's an article with some background on caustics, which may or may not
help trigger some ideas for faking/approximating a faster way.
https://developer.nvidia.com/gpugems/gpugems/part-i-natural-effects/chapter-2-rendering-water-caustics

It also provides search keywords "crepuscular rays" and "God's rays".

https://www.shadertoy.com/view/llXfRs

https://www.shadertoy.com/view/Xtcfzj

https://www.shadertoy.com/view/lldcDf

https://github.com/miloyip/light2d

http://web.archive.org/web/20221207134737/https://www.genericgamedev.com/effects/localised-crepuscular-rays/

https://developer.nvidia.com/gpugems/gpugems3/part-ii-light-and-shadows/chapter-13-volumetric-light-scattering-post-pro
cess

https://github.com/Erkaman/glsl-godrays

https://fabiensanglard.net/lightScattering/

https://www.ventuz.com/support/help/V4_05/HowTo/HowToCreateGodRayShader.html

The following seems to imply (to me) that a simple convolution kernel might be
able to achieve the effect:
https://web.archive.org/web/20210503152629/https://anderskruger.com/opengl-god-rays/


- BW

[jr] Re: Speeding up (or faking) scattering media [1031 days and 34 minutes ago]

Tue, 20 Jun 2023 13:40:00 GMT

hi,

"Juergen" <nomail@nomail> wrote:
> ...
> Is there a way to fake this (similar to what I did with the caustics), but for
> the scattering media I have no idea at the moment.

wondering, could you use a density pattern, suitably rotated etc, to 'fake' the
shafts of light ?  (just a thought, no idea if it would "buy" you time)

regards, jr.

[Bald Eagle] Re: Speeding up (or faking) scattering media [1031 days 15 hours and 54 minutes ago]

Mon, 19 Jun 2023 22:20:00 GMT

Have you tried just using a loop to make a bunch of thin cylinders radiating
from a distant point and having an rgbf pigment?

Maybe there's a way to use your caustics method and have that control the
placement of the cylinders?

Or use an isosurface, or bezier surface with a pattern simulating streaks
(gradient).

- BW

[Juergen] Speeding up (or faking) scattering media [1031 days 16 hours and 34 minutes ago]

Mon, 19 Jun 2023 21:40:00 GMT

HelloI would like to extend my scene with the fake caustic to see the light rays
under water. With a scattered media this works, but the computation time
increases indisputably from 0.5 to almost 70s per frame (should become an
animation later).
In the concrete scene the samples have to be at least 50,100 for this to look
usable - so I can't turn the screw anymore.
What possibilities are there to speed up the process (I think that the
calculation time/image should not be more than double or triple, but not by a
factor of 100)?
Is there a way to fake this (similar to what I did with the caustics), but for
the scattering media I have no idea at the moment.


---------------------the scene----------------
// Testscene mit einer gefakten Caustik,
// indem eine helle light_source mit einer Kugel und entspr teiltransparenten
Textur umgeben wird
// Renderzeit: 1sek
#version 3.7;
global_settings {
  assumed_gamma 1.0
}

#declare InclMedia = 1;

#declare CausAdd    = 0.0;
#declare ScatterCol = 0.0004;

#include "colors.inc"
#include "textures.inc"

#declare PSize = 300;

//////// Caustics-Texture START /////////
#declare TxtS4b =
texture {  // "DunkelTextur"
  pigment { rgbf <1.0, 1.0, 1.0, 1*CausAdd> }
}
#declare TxtS4a1 =
texture { // "Helltextur"
  pigment { color rgbf <1.0, 1.0, 1.0, 1.0> }
  finish { diffuse 0.5 ambient 1 }
}
#declare TxtS4a2 =
texture {
  pigment { color rgbf <1.0, 1.0, 1.0, 0.2+0.8*CausAdd> }
}
#declare TxtS4c =
texture { // Textur für die "Fläche"
  bozo
  scale 1.5
  translate <752,74,62343>
  texture_map {
    [ 0.25 pigment { rgbf <1.0,1.0,1.0,0.0+CausAdd> } ]
    [ 0.5  pigment { rgbf <1.0,1.0,1.0,0.1+0.9*CausAdd> } ]
    [ 0.75 pigment { rgbf <1.0,1.0,1.0,0.0+CausAdd> } ]
  }
  //pigment { color rgbf <0.6, 0.6, 1.0, 1.0> }
}
#declare TxtS4a =
texture {  // 1. Layer mit Bozo (Hell-Dunke-Effekte innerbalb der Textur)
  bozo
  scale 0.5
  translate <1223,455,121>
  texture_map {
    [ 0.15 TxtS4b ]
    [ 0.4  TxtS4a2 ]
    [ 0.5  TxtS4a1 ]
    [ 0.6  TxtS4a2 ]
    [ 0.85 TxtS4b ]
  }
}
#declare CausticsTxt =
texture { // die eigentliche Caustic-Textur
  crackle
  turbulence 0.25
  omega 0
  scale 5
  texture_map {
    [ 0.0 TxtS4a ]
    [ 0.12 TxtS4c ]
    [ 0.5 TxtS4b ]
  }
  scale 0.075
}
//////// Caustics-Texture ENDE /////////


// Boden
difference {
  plane { y,0 }
  box { <-PSize,-250,-PSize><PSize,1,PSize> } // Pool

  pigment { Gray50 }
  //pigment { bozo scale 30}
}

// Trübung/Nebel
//#declare adsasdas =
#ifdef(InclMedia)
  box { <-PSize,-250,-PSize><PSize,-50,PSize>
    pigment { rgbt 1 } // clear
    hollow
    interior{
      media{
        scattering{ 1, ScatterCol extinction 0.01 }
        //scattering{ 1, 0.17 extinction 0.01}
        samples 50, 100 // min, max
      } // end media
    } // end interior
  }
#end


// #declare adadas =
cylinder {
  <-25,0,0><25,0,0> 10
  pigment { Red }
  translate <100,-200,-50>
}
cylinder {
  <0,-300,0><0,100,0> 50
  pigment { Blue }
  translate <120,-200,70>
}
sphere {
  0,20
  pigment { Yellow }
  translate <120,-200,-150>
}


// Sonne
light_source {
  <-50,200, 0>
  color 5
}

// Caustics-sphere
#declare CausticsSpr =
sphere {
  0,10
  texture {
    CausticsTxt
    translate <clock*0.02  ,clock*0.1,  -clock*0.005>
  }
}

object {
  CausticsSpr
  translate <-50,200,0>
}


#declare Cam =
camera {
  location 0
  direction <0.0, 0.0, 1>
  up <0.0, 1.0, 0.0>
  right <4/3, 0.0, 0.0>
  look_at <0,0,1>
}
camera {
  Cam
  rotate 30*x
  rotate 30*y
  translate -70*y
  translate -PSize*z+10
}

[jr] Re: Gaussian curvature of a surface [1045 days 16 hours and 54 minutes ago]

Mon, 5 Jun 2023 21:20:00 GMT

hi,

(very nearly forgot, sorry)


"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > no idea what it might be "good for" but looks intriguing.  ...
> So, this is a video with information pertaining to Blender, but aside from the
> general workflow and texture mapping/layering tricks, what caught my interest
> was the "curvature map".

that part of the Blender i/f where the "flow" got "stitched together" very much
made me think of MS Access + ERDs.  re curvature map and all -- whooosh..  :-)


> I think that addresses the question "what can it be used for?" with regard to
> the mean and Gaussian curvature of Bezier surfaces.
>
> I'd still have to work out the numerical method for calculating the curvature of
> ANY given surface, and that might be a bit slower, but the final results sure do
> look promising.

some (visual) example I could (with luck) relate to ?


regards, jr.

[Bald Eagle] Re: Gaussian curvature of a surface [1048 days 20 hours and 49 minutes ago]

Fri, 2 Jun 2023 17:25:00 GMT

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

> no idea what it might be "good for" but looks intriguing.  (the 2nd image made
> me wonder, could the data be used to simulate something like a marble run :-))

So, this is a video with information pertaining to Blender, but aside from the
general workflow and texture mapping/layering tricks, what caught my interest
was the "curvature map".

https://www.youtube.com/watch?v=-x-b2U-MSgc

I think that addresses the question "what can it be used for?" with regard to
the mean and Gaussian curvature of Bezier surfaces.

I'd still have to work out the numerical method for calculating the curvature of
ANY given surface, and that might be a bit slower, but the final results sure do
look promising.

- BE

[Chris R] Re: Applying noise to geometry [1065 days 17 hours and 34 minutes ago]

Tue, 16 May 2023 20:40:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi,
> while working on Yes-project, I am trying to find the way of making
> the objects less 'geometrical', giving them more natural and 'noisy'
> shapes (like in this attachment, for example). The only way I found in
> manual is to play with normals, but I'd like to have an influence on
> geometry, to apply more relief.
>
> It's possible to pass a noisy hi-res mesh from ZBrush, as I'm doing now,
> but this is not 'pure' POV-way and import takes some 'non-zero' time.
>
> Maybe anyone can advise something about such arbitrary geometry
> modifications ?
> Thanks in advance.
> --
> YB
My preferred method for doing this, albeit introducing some longer render times,
is to use isosurface objects.  I usually start with a function that defines the
non-perturbed shape of the object, e.g.:

#local _shape_fn = function(x,y,z) {
   sqrt(x*x+y*y+z*z) - 1
}

for a 1-unit radius sphere.

I then use one of several techniques to do the perturbations.  For example,

#local _shape_fn = function(x,y,z) {
   sqrt(x*x+y*y+z*z) - (1+0.1*f_snoise3d(x,y,z))
}

or
#local _pattern_fn = function {
   pigment {
      bozo
      color_map {
         [0.0 rgb 0]
         [1.0 rgb 1]
      }
   }
}
#local _shape_fn = function(x,y,z) {
   sqrt(x*x+y*y+z*z) - (1 + 0.1*_pattern_fn(x,y,z).gray)
}

or, if your shape function is well-behaved, (i.e. returns a value representing
the distance from a point to the surface of your object), you could do it this
way instead:

#local _shape2_fn = function(x,y,z) {
   _shape_fn(x,y,z) - 0.1*_pattern_fn(x,y,z).gray
}

The attached image is a pretty complex example, where the basic shape of the
wood-part of the blocks is basically f_rounded_box, but patterns are applied for
the wood grain, dents in the wood, cracks in the wood, etc.

-- Chris R.

[Bald Eagle] Re: No semicolon allowed in Tuple-style assignme... [1078 days 18 hours and 34 minutes ago]

Wed, 3 May 2023 19:40:00 GMT

I am back at it, and still experiencing a lot of weird behaviour with regard to
assigning tuple-style values via macros.

And that somehow seems to be a subset of just generally weird parser behaviour
overall.

I have a scene that I've run dozens of times.
I've let it sit while I've pursued other projects and IRL stuff.
I added some fairly inconsequential code WAY at the end of the .pov file.

Now the parser is complaining about semicolons and undeclared Lvalues.

So I fiddled and restructured the macro it was complaining about, and now I'm
getting a totally inexplicable "all #declares..... require a semicolon..." error
in a macro where _everything has a semicolon_.

Okay - maybe I'm mid-parse on some other #declare or #local  and I need to fix
something upstream of the macro call.  So I add in all my macro calls that track
what level in the nesting of things I'm in, and that all seems fine ---

EXCEPT

that the parser tells me that my error occurs on line 205.

My macro calls that output the debugging stack, and current position in the
stack, both execute to completion --- but those are AFTER the cited error line,
at lines 207 and 208.

I honestly have no idea what's going on.

Either something is very weirdly wrong with my code
or
I am losing my mind
or
there is a problem in the source code for the parser
and/or
there is a problem with the parsing of tuple-style assignments

Parsing a scene should not be this - fussy.
Nor should debugging the problem be so cryptic and mysterious.


I think there needs to be a better mechanism to structure code, and follow the
flow when parse errors are triggered.
If the parser thinks that I need a semicolon to close a #local or #declare, then
it should give me the line number of the opening #local or #declare statement
that it's expecting the semicolon to finalize.

For some reason, this particular pov/inc scene pairing has been nothing but
trouble, and I'm not really sure why.  I've written vastly more complex code.

I can use all the help and advice I can get as to how to proceed.

This is very frustrating, annoying, and angering.

Trying to run previously working code shouldn't result in a failed 2-day
debugging odyssey.

[jr] Re: No semicolon allowed in Tuple-style assignme... [1100 days 21 hours and 39 minutes ago]

Tue, 11 Apr 2023 16:35:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > (I also run into the same kind of thing when I'm putting commas into a cylinder
> > {} and use an extra comma in between the second endpoint and the cylinder
> > radious - POV-Ray no likey.)
>
> In v3.8xx in Windows, the extra comma works OK for me. I had always assumed it
> was necessary anyway, as per docs (using the cylinder syntax there):
>
> cylinder{-.5*x,.5*x,.1 texture{...}}
>
> Leaving out the 2nd comma works as well, but that seems to be undocumented
> 'shorthand' behavior, IMHO.

agree.  fwiw, here both self-compiled beta.2 and (WFP's) povr, on Linux, are
perfectly ok with all three forms:
  #declare a_ = cylinder {0 1 .1 open};
  #declare b_ = cylinder {0,1 .1 open};
  #declare c_ = cylinder {0,1,.1 open};


regards, jr.

[Kenneth] Re: No semicolon allowed in Tuple-style assignme... [1101 days 3 hours and 9 minutes ago]

Tue, 11 Apr 2023 11:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> (I also run into the same kind of thing when I'm putting commas into a cylinder
> {} and use an extra comma in between the second endpoint and the cylinder
> radious - POV-Ray no likey.)

In v3.8xx in Windows, the extra comma works OK for me. I had always assumed it
was necessary anyway, as per docs (using the cylinder syntax there):

cylinder{-.5*x,.5*x,.1 texture{...}}

Leaving out the 2nd comma works as well, but that seems to be undocumented
'shorthand' behavior, IMHO.

[yesbird] Re: Finding object's bounding box [1110 days and 2 minutes ago]

Sun, 2 Apr 2023 14:11:37 GMT

On 02/04/2023 10:52, jr wrote:
> sometimes a simple rotation will affect the bbox.  :-)  I wrote a macro to help
> me with those.
> <https://drive.google.com/file/d/1-ak9jRR7B6iNoQfchF_XMupNL6Wop5Oq/view?usp=sharing>

Thanks, another pitfall avoided.
--
YB

[jr] Re: Finding object's bounding box [1110 days 6 hours and 19 minutes ago]

Sun, 2 Apr 2023 07:55:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 02/04/2023 01:52, Alain Martel wrote:
> > Remember that, when dealing with differences and intersections, the
> > bounding box can be larger than the object.
>
> Thanks, your comment will help me to avoid unpleasant surprises ).

sometimes a simple rotation will affect the bbox.  :-)  I wrote a macro to help
me with those.

<https://drive.google.com/file/d/1-ak9jRR7B6iNoQfchF_XMupNL6Wop5Oq/view?usp=sharing>


regards, jr.

[yesbird] Re: Finding object's bounding box [1110 days 15 hours and 13 minutes ago]

Sat, 1 Apr 2023 23:00:47 GMT

On 02/04/2023 01:52, Alain Martel wrote:
> Remember that, when dealing with differences and intersections, the 
> bounding box can be larger than the object.

Thanks, your comment will help me to avoid unpleasant surprises ).
--
YB

[Alain Martel] Re: Finding object's bounding box [1110 days 15 hours and 21 minutes ago]

Sat, 1 Apr 2023 22:52:22 GMT

Le 2023-04-01 Ã  13:56, yesbird a Ã©critÂ :
> On 01/04/2023 20:48, ingo wrote:
>> from the docs on functions:
>>
>> min_extent(OBJECT_IDENTIFIER), max_extent(OBJECT_IDENTIFIER). The 
>> min_extent and
>> max_extent return the minimum and maximum coordinates of a declared 
>> object's
>> bounding box (Corner1 and Corner2), in effect allowing you to find the
>> dimensions and location of the object.
> 
> Thanks, ingo, this is exactly what I was expecting.
> -- 
> YB
> 
> 
Remember that, when dealing with differences and intersections, the 
bounding box can be larger than the object.

[yesbird] Re: Finding object's bounding box [1110 days 20 hours and 17 minutes ago]

Sat, 1 Apr 2023 17:56:20 GMT

On 01/04/2023 20:48, ingo wrote:
> from the docs on functions:
> 
> min_extent(OBJECT_IDENTIFIER), max_extent(OBJECT_IDENTIFIER). The min_extent and
> max_extent return the minimum and maximum coordinates of a declared object's
> bounding box (Corner1 and Corner2), in effect allowing you to find the
> dimensions and location of the object.

Thanks, ingo, this is exactly what I was expecting.
--
YB

[ingo] Re: Finding object's bounding box [1110 days 20 hours and 24 minutes ago]

Sat, 1 Apr 2023 17:50:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> I can draw a BB box approximately, but if someone will show me the
> way to calculate BB of arbitrary objects, I will be able to set up
> lighting more accurately.

from the docs on functions:

min_extent(OBJECT_IDENTIFIER), max_extent(OBJECT_IDENTIFIER). The min_extent and
max_extent return the minimum and maximum coordinates of a declared object's
bounding box (Corner1 and Corner2), in effect allowing you to find the
dimensions and location of the object.

ingo

[yesbird] Finding object's bounding box [1110 days 22 hours and 8 minutes ago]

Sat, 1 Apr 2023 16:05:10 GMT

Hi,
I am working on Mike's fly lighting and animation now.
To simplify and To speed up this task, I am using my C4D->POV converter
for lights exporting, but I need some reference object in the C4D scene
to replace a fly (see attachments).

I can draw a BB box approximately, but if someone will show me the
way to calculate BB of arbitrary objects, I will be able to set up
lighting more accurately.

Thanks in advance.
--
YB

[jr] Re: No semicolon allowed in Tuple-style assignme... [1116 days 11 hours and 44 minutes ago]

Mon, 27 Mar 2023 02:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ....
> I got the ole' can't assign an unidentified something or other to Lvalue...
>
> The macro has 2 lines.
> #local Result = array {Val1, Val2};
>
> Result
>
> But somehow it thinks Result hasn't been defined.
>
> So I deleted the #local and the Result, and just left the array.
> Works fine now.
>
> I don't get it.

eg:
#version 3.8;
global_settings {assumed_gamma 1}
box {0,1}

#macro has2lines ()
  #local Result = array {1234,5678};
  (Result[0], Result[1])
#end

#declare (first,second) = has2lines();
#debug concat("first ",str(first,0,0)," second ",str(second,0,0),"\n")
#warning "end-of-scene"


note (a) you need to provide two return values if you want to assign two values
from the call, and (b) nothing doing w/out parentheses.  (and coffee !! :-))


regards, jr.

[Bald Eagle] Re: No semicolon allowed in Tuple-style assignme... [1116 days 14 hours and 34 minutes ago]

Sun, 26 Mar 2023 23:40:00 GMT

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

> Tried a few things quickly and v3.8 behavior I think OK. Test scene below:

Yeah, I don't know.
It seems like these things happen only sometimes, and in hard-to replicate
manners.

For instance, I just did a macro call on a macro that returns a 2 element array.
I got the ole' can't assign an unidentified something or other to Lvalue...

The macro has 2 lines.
#local Result = array {Val1, Val2};

Result

But somehow it thinks Result hasn't been defined.

So I deleted the #local and the Result, and just left the array.
Works fine now.

I don't get it.

[William F Pokorny] Re: No semicolon allowed in Tuple-style assignme... [1116 days 15 hours and 35 minutes ago]

Sun, 26 Mar 2023 22:38:46 GMT

On 3/26/23 15:32, Bald Eagle wrote:
> After checking that there wasn't some { that got put somewhere by accident, I
> took one of the tuple assignments
> #declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
> and deleted the trailing semicolon - and BEHOLD!  the error vanishes.
> 
> That makes for coding awkwardness and confusion.
> 
> (I also run into the same kind of thing when I'm putting commas into a cylinder
> {} and use an extra comma in between the second endpoint and the cylinder
> radious - POV-Ray no likey.)

Tried a few things quickly and v3.8 behavior I think OK. Test scene below:

//---
#version 3.8;

#macro Mac00()
     (1,2)
#end

#declare (V1,V2) = Mac00();
#debug concat(str(V1,-1,-1)," ",str(V2,-1,-1),"\n")

#declare (V1,V2) = Mac00()
#debug concat(str(V1,-1,-1)," ",str(V2,-1,-1),"\n")

#declare Cyl00 = cylinder { 0 1 0.1 }
#declare Cyl01 = cylinder { 0, 1 0.1 }
#declare Cyl02 = cylinder { 0, 1, 0.1 }
#declare Cyl03 = cylinder { 0 1, 0.1 }
// #declare Cyl04 = cylinder { 0 1,, 0.1 }  // Valid complaint
// #declare Cyl05 = cylinder { 0 1, 0.1, }  // Valid complaint
// #declare Cyl06 = cylinder { 0, 1,, 0.1 } // Valid complaint

#error "stopping early"
//---

Bill P.

[jr] Re: No semicolon allowed in Tuple-style assignme... [1116 days 18 hours and 19 minutes ago]

Sun, 26 Mar 2023 19:55:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> After checking that there wasn't some { that got put somewhere by accident, I
> took one of the tuple assignments
> #declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
> and deleted the trailing semicolon - and BEHOLD!  the error vanishes.
>
> That makes for coding awkwardness and confusion.

had a quick look at some code where I use tuple assignments, all are '#local'
rather than '#declare', but I think your example should work.  (see my
'pvars.inc')

regards, jr.

[Bald Eagle] No semicolon allowed in Tuple-style assignments? [1116 days 18 hours and 39 minutes ago]

Sun, 26 Mar 2023 19:35:00 GMT

So, I was just coding a few more macros, and I wanted to return a few vectors.

Pre-3.8, I'd normally handle this using a small array, but the nested macro call
that I was copy-paste-editing had the output that I needed as arguments, and I
figured I'd just use the tuple-style #declare.

I got a weird error about "expecting } found ; instead" and as all of my other
bits of code in the scene were working, with #declare LValue = value; inside of
union {}s, I was puzzled and confused.

After checking that there wasn't some { that got put somewhere by accident, I
took one of the tuple assignments
#declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
and deleted the trailing semicolon - and BEHOLD!  the error vanishes.

That makes for coding awkwardness and confusion.

(I also run into the same kind of thing when I'm putting commas into a cylinder
{} and use an extra comma in between the second endpoint and the cylinder
radious - POV-Ray no likey.)

[Bald Eagle] Re: Bezier spline deformation [1120 days 3 hours and 44 minutes ago]

Thu, 23 Mar 2023 10:30:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> As I see your plot also not matching to POV version - vertical size is
> less.

Well, your first data set is 1/10th the size of what you later posted as a
prism.  Here's my shape based on your most recent dataset post, and your
original prism simply scaled by 10.

So, I mean, to my eye, they "match" close enough for what we're talking about
here.

> Here I've posted Matlab version - it matches to C4D:
> news://news.povray.org:119/b44b0560-ea7d-f389-12d8-47cbc7d21017@gmail.com

linky no worky.  But I did see your past pasts, and the other one is indeed
rounder.

Puzzling indeed.  Troubling as well.

[yesbird] Re: Bezier spline deformation [1120 days 7 hours and 24 minutes ago]

Thu, 23 Mar 2023 06:49:56 GMT

On 23/03/2023 01:53, Bald Eagle wrote:
> So --- it looks to me like
> the other software package is doing something strange?
As I see your plot also not matching to POV version - vertical size is
less.
> 
> Maybe try another program, or an online tool to see what kinds of results you
> get?
Here I've posted Matlab version - it matches to C4D:
news://news.povray.org:119/b44b0560-ea7d-f389-12d8-47cbc7d21017@gmail.com
--
YB

[Bald Eagle] Re: Bezier spline deformation [1120 days 15 hours and 19 minutes ago]

Wed, 22 Mar 2023 22:55:00 GMT

I plotted out the points following the standard cubic equations described by the
Bernstein polynomials and got the attached shape.   So --- it looks to me like
the other software package is doing something strange?

Maybe try another program, or an online tool to see what kinds of results you
get?

- BW

[yesbird] Re: Bezier spline deformation [1121 days and 13 minutes ago]

Wed, 22 Mar 2023 14:00:50 GMT

On 22/03/2023 16:07, William F Pokorny wrote:
> I get the attached image using an orthographic camera and if not a match 
> for what c4d is showing in your last post, it looks to me to be in the 
> ballpark.

Thanks a lot for this experiment, the shape becomes much closer to
original and I see that POV gives a lot of space for 'hoodoo'.

As I expected before, to achieve exact matching, I need to do some
adjustments of original data. Not much of a fun, but this is reality ...
--
YB

[William F Pokorny] Re: Bezier spline deformation [1121 days 1 hour and 6 minutes ago]

Wed, 22 Mar 2023 13:07:31 GMT

On 3/22/23 05:05, yesbird wrote:
> The problem is in different results of splines rendering in C4D and POV, 
> I can't even imagine how it could be.

A bit of wild guessing. In looking some at font rendering code years 
back, I noticed what looked like bezier spline p1-c1-c2-p2 incoming 
point sets being converted to p1-p1_2((c1+c2)/2)-p3 and then the 
duplicate end points getting compressed. The resulting point list was 
then rendered with via cubic_spline.

The why of all it then, I do not know. But, if I do that conversion on 
your bezier_spline point list and create an equivalent cubic_spline of:

#declare Extrude2 = prism { linear_sweep cubic_spline 0, 1.000000, 11
    <0.975347, -0.725347>
    <1.500000, 0.000000>
    <0.975347, 0.725347>
    <0.000000, 1.000000>
    <-0.975347, 0.725347>
    <-1.500000, 0.000000>
    <-0.975347, -0.725347>
    <0.000000, -1.000000>
    <0.975347, -0.725347>
    <1.500000, 0.000000>
    <0.975347, 0.725347>

I get the attached image using an orthographic camera and if not a match 
for what c4d is showing in your last post, it looks to me to be in the 
ballpark.

Bill P.

[yesbird] Re: Bezier spline deformation [1121 days 5 hours and 8 minutes ago]

Wed, 22 Mar 2023 09:05:30 GMT

On 22/03/2023 04:54, Bald Eagle wrote:
> The control points should transfer seamlessly, since they are just numerical
> coordinates.  Although with a cubic, you need those "extra" control points which
> don't show up but that affect the shape of the curve - so maybe that's where the
> problem lies?

Thanks, Bill, fortunately I'm familiar with splines from my school years 
:). The problem is in different results of splines rendering in C4D and 
POV, I can't even imagine how it could be.

Data is following:
//-------------------------------------------------------------------
#declare Extrude = prism { linear_sweep bezier_spline 0, 3.000000, 16

   // -----------
   <15.000000, 0.000000>   // P1
   <15.000000, 3.750000>   // T2
   <5.625000, 10.000000>   // T3
   <0.000000, 10.000000>   // P2
   // -----------
   <0.000000, 10.000000>   // P2
   <-5.625000, 10.000000>  // T4
   <-15.000000, 3.750000>  // T5
   <-15.000000, 0.000000>  // P3
   // -----------
   <-15.000000, 0.000000>  // P3
   <-15.000000, -3.750000> // T6
   <-5.625000, -10.000000> // T7
   <0.000000, -10.000000>  // P4
   // -----------
   <0.000000, -10.000000>  // P4
   <5.625000, -10.000000>  // T8
   <15.000000, -3.750000>  // T1
   <15.000000, 0.000000>   // P1
   // -----------

   matrix
  <0.100000, 0.000000, 0.000000,
   0.000000, 0.100000, 0.000000,
   0.000000, 0.000000, 0.100000,
   -0.005274, 0.030602, -0.017559>

   material { texture {pigment {rgb <1,1,1> }}}
}

object{ Extrude }
//-------------------------------------------------------------------

Results attached.
--
YB

[Bald Eagle] Re: Bezier spline deformation [1121 days 12 hours and 19 minutes ago]

Wed, 22 Mar 2023 01:55:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 21/03/2023 23:21, Leroy wrote:
> > Do you have access to the C4D and POV source code ?
> > I know it's complicated but you might get an idea of where they differ.
>
> Thanks for suggestion, yes, I have POV sources, but can only dream about
> sources of C4D :)
>
> And even I will find the reason of difference (position of control
> points) in sources, I will not be able to control them in POV's 'prism':
> https://wiki.povray.org/content/Reference:Prism
>
> So the problem still exists ...
> --
> YB

So, years ago, when I still didn't have any real clue what was going on with
Bezier splines and patches, I thought that maybe different softwares might have
different equations for computing the cubic Bezier spline.

I don't see how that's that case, as Bezier curves all seem to be calculated the
same way, with the same, meaningful, purposeful equations, derived from the same
principles and adhering to the same behaviour and exhibiting the same properties
- such as partition of unity.  I'm not seeing how that could be done multiple
ways - without messing up things like True Type fonts, and the myriad other
applications of Bezier curves across different software packages and operating
systems.

So I am presuming that C4D uses the same equations that POV-Ray uses, which I've
at some point read the source code for, and matches the equations that I write
to make them myself.

The control points should transfer seamlessly, since they are just numerical
coordinates.  Although with a cubic, you need those "extra" control points which
don't show up but that affect the shape of the curve - so maybe that's where the
problem lies?

- BW

[yesbird] Re: Bezier spline deformation [1121 days 16 hours and 29 minutes ago]

Tue, 21 Mar 2023 21:44:14 GMT

On 21/03/2023 23:21, Leroy wrote:
> Do you have access to the C4D and POV source code ?
> I know it's complicated but you might get an idea of where they differ.

Thanks for suggestion, yes, I have POV sources, but can only dream about
sources of C4D :)

And even I will find the reason of difference (position of control
points) in sources, I will not be able to control them in POV's 'prism':
https://wiki.povray.org/content/Reference:Prism

So the problem still exists ...
--
YB

[Leroy] Re: Bezier spline deformation [1121 days 17 hours and 49 minutes ago]

Tue, 21 Mar 2023 20:25:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 15/03/2023 17:46, ingo wrote:
> > Thanks Alain, I'm aware of that, just tried to show that the POV-Ray
> > implementation of the Bezier spline is not wrong using yesbird's data and
> > various implementations.
>
> Yes, it's not wrong, but the question still exists: how to match it to
> C4D's produces shape in POV's 'prism' object (see first post).
> Unfortunately, manual states, that only two control points can be set:
> https://wiki.povray.org/content/Reference:Prism
>
> Experiments with them gives nothing.
> --
> YB

Do you have access to the C4D and POV source code ?
I know it's complicated but you might get an idea of where they differ.

 A while back I wrote a win program to make polygons and prisms for POV.
The first try I got the code straight from the internet.But it had little errors
like the one you showed. Then I went right to POV source. Now it is a lot
better.
 Of course you can do some trial an error by changing the control points by some
magic number. I would use a vector to move the control points either from the
other control point in a bezier_spline or the start point for other splines.
 Hope this helps.

Have Fun!

[Francois LE COAT] Re: Optical Pendulum [1121 days 23 hours and 23 minutes ago]

Tue, 21 Mar 2023 14:51:07 GMT

Hi,

> ingo writes:
>> Francois LE COAT wrote:
>>> A WEB page was made to illustrate the "optical pendulum" experiment:
>>>
>>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/optica
l_pendulum.html> 
>>>
>>
>> Nice!
> 
> Thanks. I don't know anyone else working on such an experiment. It only

> requires a computer and a camera. This is so simple, but interesting!
> Many people are trying to match images the best way, but there's no
> real experiment like this "optical pendulum", so far as I know about it
?

The planar perspective transformation used for modelling the camera
motion, was added to the "optical pendulum" WEB page. Some of the
transforms are present in Persistence of Vision, like 3 translations
and 3 rotations. But the "skew" or "shear" angles <Sx,Sy> are not
directly. Thanks for the POV-Ray advance users to have helped on that.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

[Bald Eagle] Re: Least Squares fitting [1126 days 16 hours and 14 minutes ago]

Thu, 16 Mar 2023 22:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Those stackexchange links are proving to be fascinating and really informative;
> thanks! Yes, I see now that 'squaring' has many purposes (and Pythagorean
> antecedents) regarding the 'sum of squares' method. Lots to absorb!

Apparently, Grant has been closely monitoring our conversations, and made a
video to explain the basics:

But what is the Central Limit Theorem?

3Blue1Brown

https://www.youtube.com/watch?v=zeJD6dqJ5lo

[yesbird] Re: Bezier spline deformation [1127 days 22 hours and 52 minutes ago]

Wed, 15 Mar 2023 15:21:22 GMT

On 15/03/2023 17:46, ingo wrote:
> Thanks Alain, I'm aware of that, just tried to show that the POV-Ray
> implementation of the Bezier spline is not wrong using yesbird's data and
> various implementations.

Yes, it's not wrong, but the question still exists: how to match it to
C4D's produces shape in POV's 'prism' object (see first post).
Unfortunately, manual states, that only two control points can be set:
https://wiki.povray.org/content/Reference:Prism

Experiments with them gives nothing.
--
YB

[ingo] Re: Bezier spline deformation [1127 days 23 hours and 24 minutes ago]

Wed, 15 Mar 2023 14:50:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-03-15 à 03:30, ingo a écrit :
> > "ingo" <nomail@nomail> wrote:
> >
> >
> >
> I see the problem. Your spline is not «stiff» enough.
> Try pushing the control points back. That'll make the spline flatter at
> the placement points.

Thanks Alain, I'm aware of that, just tried to show that the POV-Ray
implementation of the Bezier spline is not wrong using yesbird's data and
various implementations.

ingo

[Alain Martel] Re: Bezier spline deformation [1128 days and 46 minutes ago]

Wed, 15 Mar 2023 13:27:50 GMT

Le 2023-03-15 Ã  03:30, ingo a Ã©critÂ :
> "ingo" <nomail@nomail> wrote:
> 
> 
> 
I see the problem. Your spline is not Â«stiffÂ» enough.
Try pushing the control points back. That'll make the spline flatter at 
the placement points.

Try this :
#declare vC = array[13]{
    <1.500000, 0.000000, 0>,//P
    <1.500000, 0.6, 0>,//C
    <0.47, 1.000000, 0>,//C
    <0.000000, 1.000000, 0>,//P
    <-0.47, 1.000000, 0>,//C
    <-1.500000, 0.6, 0>,//C
    <-1.500000, 0.000000, 0>,//P
    <-1.500000, -0.6, 0>,//C
    <-0.47, -1.000000, 0>,//C
    <0.000000, -1.000000, 0>,//P
    <0.47, -1.000000, 0>,//C
    <1.500000, -0.6, 0>,//C
    <1.500000, 0.000000, 0>//P
}

[yesbird] Re: Bezier spline deformation [1128 days 1 hour and 49 minutes ago]

Wed, 15 Mar 2023 12:24:40 GMT

On 15/03/2023 14:29, ingo wrote:
>> Cubic splines are hard to compare. What cubic is used by whom?

As I was expected, looks like the reason is default location of control
points, no any magic here.
--
YB

[ingo] Re: Bezier spline deformation [1128 days 2 hours and 44 minutes ago]

Wed, 15 Mar 2023 11:30:00 GMT

"ingo" <nomail@nomail> wrote:
> yesbird <sya### [at] gmailcom> wrote:
> > On 15/03/2023 10:47, yesbird wrote:
>
> Cubic splines are hard to compare. What cubic is used by whom?

Cubic B-spline using my curve macros

---%<------%<------%<---

#version 3.7;

#include "curve.inc"  //https://ingoogni.nl/download/Curve.zip

#global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 emission 0}}

#declare Bspl3 = CIbspline3(
    array[7]{
        <0.000000, -1.000000,0>
        <1.500000, 0.000000,0>
        <0.000000, 1.000000,0>
        <-1.500000, 0.000000,0>
        <0.000000, -1.000000,0>
        <1.500000, 0.000000,0>
        <0.000000, 1.000000,0>
    }
)

//get the points on the curve
#for(T, 0, 1, 0.005)
  sphere{CIget(Bspl3, T), 0.02 pigment{rgb 1}}
#end

//control points
sphere{Bspl3[1][0] 0.03 pigment{rgb <1,0,0>}}
#for(i, 1, dimension_size(Bspl3[1],1) - 1)
  sphere{Bspl3[1][i] 0.03 pigment{rgb <1,0,0>}}
  cylinder{Bspl3[1][i-1], Bspl3[1][i], 0.01 pigment{rgb <1,0,0>}}
#end

camera {
  perspective angle 45
  location  <0, 0, -6>
  right     x*image_width/image_height
  look_at   <0, 0, 0.0>
}

light_source{<0, 0,-3000> color rgb 1}

---%,------%<------%<---

[ingo] Re: Bezier spline deformation [1128 days 2 hours and 59 minutes ago]

Wed, 15 Mar 2023 11:15:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 15/03/2023 10:47, yesbird wrote:

Cubic splines are hard to compare. What cubic is used by whom?

Inkscape bezier:

[yesbird] Re: Bezier spline deformation [1128 days 4 hours and 18 minutes ago]

Wed, 15 Mar 2023 09:55:55 GMT

On 15/03/2023 10:47, yesbird wrote:
> It seems that C4D has some hidden spline rendering magic.

This is a Matlab version of cubic spline (attached):
------------------------------------
fnplt(cscvn( [1.5 0 -1.5 0 1.5; ...
               0 1 0 -1 0] ))
------------------------------------

details are here:
https://www.mathworks.com/help/curvefit/cscvn.html?searchHighlight=cscvn&s_tid=srchtitle_cscvn_1

Score is 2:2 now ...
--
YB

[yesbird] Re: Bezier spline deformation [1128 days 6 hours and 10 minutes ago]

Wed, 15 Mar 2023 08:03:48 GMT

On 15/03/2023 07:11, Mike Miller wrote:
> I'll take a look. Have you tried plotting those same points in another package?
> ...like AutoCAD or FreeCAD. Did you try adding a tolerance? I doubt it would
> matter.

No, I have no them, maybe some online tools...
Also will try to ask MAXON support - they answer very quickly.
--
YB

[yesbird] Re: Bezier spline deformation [1128 days 6 hours and 26 minutes ago]

Wed, 15 Mar 2023 07:47:23 GMT

On 15/03/2023 10:13, ingo wrote:
> Using my curves macro:

Thank you for this test, POV leads 2:0 now. It seems that C4D has some
hidden spline rendering magic. I will ask MAXON support now...
--
YB

[ingo] Re: Bezier spline deformation [1128 days 6 hours and 39 minutes ago]

Wed, 15 Mar 2023 07:35:00 GMT

"ingo" <nomail@nomail> wrote:

[ingo] Re: Bezier spline deformation [1128 days 6 hours and 59 minutes ago]

Wed, 15 Mar 2023 07:15:00 GMT

Using my curves macro:
---%<---%<---%<---
#version 3.7;

#include "curve.inc"  //https://ingoogni.nl/download/Curve.zip

#global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 emission 0}}

#declare vT = array[2]{0, 1}

#declare vC = array[13]{
   <1.500000, 0.000000, 0>,
   <1.500000, 0.450694, 0>,
   <0.450694, 1.000000, 0>,
   <0.000000, 1.000000, 0>,
   <-0.450694, 1.000000, 0>,
   <-1.500000, 0.450694, 0>,
   <-1.500000, 0.000000, 0>,
   <-1.500000, -0.450694, 0>,
   <-0.450694, -1.000000, 0>,
   <0.000000, -1.000000, 0>,
   <0.450694, -1.000000, 0>,
   <1.500000, -0.450694, 0>,
   <1.500000, 0.000000, 0>
}
#declare Test = CIt(CIlinear(vT), CIbezier3(vC));


//get the points on the curve
#for(T, 0, 1, 0.005)
  sphere{CITget(Test, T), 0.02 pigment{rgb 1}}
#end

//control points
sphere{Test[1][1][0] 0.03 pigment{rgb <1,0,0>}}
#for(i, 1, dimension_size(Test[1][1],1) - 1)
  sphere{Test[1][1][i] 0.03 pigment{rgb <1,0,0>}}
  cylinder{Test[1][1][i-1], Test[1][1][i], 0.01 pigment{rgb <1,0,0>}}
#end

camera {
  perspective angle 45
  location  <0, 0, -6>
  right     x*image_width/image_height
  look_at   <0, 0, 0.0>
}

light_source{<0, 0,-3000> color rgb 1}

---%<---%<---%<---

[Mike Miller] Re: Bezier spline deformation [1128 days 9 hours and 59 minutes ago]

Wed, 15 Mar 2023 04:15:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 14/03/2023 14:01, yesbird wrote:
> > while working on C4D->POV converter, I've discovered a strange form
> > deviation of prism, extruded from bezier spline (see attachment).
>
> And I should say, that for cubic spline I have the same distortion:
> > //----------------------------------------------------------------------------
> camera{ perspective
>  location  <0, 0, 0>
>  angle 53.130102
>
>    matrix
>   <0.999944, -0.000000, -0.010610,
>    0.010182, 0.281279, 0.959572,
>    0.002984, -0.959626, 0.281263,
>    -0.018327, 5.930451, -1.559761>
>
> }
>
> #declare Extrude = prism { linear_sweep cubic_spline 0, 1.000000, 7
>
>    <0.000000, -1.000000>
>    <1.500000, 0.000000>
>    <0.000000, 1.000000>
>    <-1.500000, 0.000000>
>    <0.000000, -1.000000>
>    <1.500000, 0.000000>
>    <0.000000, 1.000000>
>    matrix
>   <1.000000, 0.000000, 0.000000,
>    0.000000, 1.000000, 0.000000,
>    0.000000, 0.000000, 1.000000,
>    0.000000, 0.000000, 0.000000>
>
>    material { mat_default }
> }
>
> object{ Extrude }
> > //----------------------------------------------------------------------------

I'll take a look. Have you tried plotting those same points in another package?
...like AutoCAD or FreeCAD. Did you try adding a tolerance? I doubt it would
matter.
Mike

[yesbird] Re: Studio lighting setup [1129 days 2 hours and 50 minutes ago]

Tue, 14 Mar 2023 11:24:01 GMT

On 14/03/2023 10:04, Thomas de Groot wrote:
> I would expect a bit of shadow /under/ the beetle though...

Yes, this setup needs a lot of tweaking, but I was so glad to obtain
this tool that, posted the first draft immediately. :)
--
YB

[yesbird] Re: Bezier spline deformation [1129 days 2 hours and 53 minutes ago]

Tue, 14 Mar 2023 11:20:10 GMT

On 14/03/2023 14:01, yesbird wrote:
> while working on C4D->POV converter, I've discovered a strange form
> deviation of prism, extruded from bezier spline (see attachment).

And I should say, that for cubic spline I have the same distortion:
> //----------------------------------------------------------------------------
camera{	perspective
	location  <0, 0, 0>
	angle 53.130102

   matrix
  <0.999944, -0.000000, -0.010610,
   0.010182, 0.281279, 0.959572,
   0.002984, -0.959626, 0.281263,
   -0.018327, 5.930451, -1.559761>

}

#declare Extrude = prism { linear_sweep cubic_spline 0, 1.000000, 7

   <0.000000, -1.000000>
   <1.500000, 0.000000>
   <0.000000, 1.000000>
   <-1.500000, 0.000000>
   <0.000000, -1.000000>
   <1.500000, 0.000000>
   <0.000000, 1.000000>
   matrix
  <1.000000, 0.000000, 0.000000,
   0.000000, 1.000000, 0.000000,
   0.000000, 0.000000, 1.000000,
   0.000000, 0.000000, 0.000000>

   material { mat_default }
}

object{ Extrude }
> //----------------------------------------------------------------------------

[yesbird] Bezier spline deformation [1129 days 3 hours and 12 minutes ago]

Tue, 14 Mar 2023 11:01:55 GMT

Hi,

while working on C4D->POV converter, I've discovered a strange form
deviation of prism, extruded from bezier spline (see attachment).

I claim, that exported data is absolutely correct (checked many times),
and no any useful info found here:
https://www.povray.org/documentation/view/3.7.0/62/
https://wiki.povray.org/content/Reference:Prism

I'm not sure about collisions, but only wonder how the same data with
the algorithm can produce different results. It seams to me, that
interpretation is different or maybe some additional scaling is applied
to tangents, for example.

Code is below, any ideas ?

//----------------------------------------------------------------------------
camera{	perspective
	location  <0, 0, 0>
	angle 53.130102

   matrix
  <1.000000, -0.000000, 0.000000,
   0.000000, 0.000000, 1.000000,
   -0.000000, -1.000000, 0.000000,
   0.058724, 5.575552, -0.059483>

}

#declare Extrude = prism { linear_sweep bezier_spline 0, 1.000000, 16

   <1.500000, 0.000000>
   <1.500000, 0.450694>
   <0.450694, 1.000000>
   <0.000000, 1.000000>
   <0.000000, 1.000000>
   <-0.450694, 1.000000>
   <-1.500000, 0.450694>
   <-1.500000, 0.000000>
   <-1.500000, 0.000000>
   <-1.500000, -0.450694>
   <-0.450694, -1.000000>
   <0.000000, -1.000000>
   <0.000000, -1.000000>
   <0.450694, -1.000000>
   <1.500000, -0.450694>
   <1.500000, 0.000000>
   matrix
  <1.000000, 0.000000, 0.000000,
   0.000000, 1.000000, 0.000000,
   0.000000, 0.000000, 1.000000,
   0.000000, 0.000000, 0.000000>

   material { mat_default }
}

object{ Extrude }
//----------------------------------------------------------------------------

[Thomas de Groot] Re: Studio lighting setup [1129 days 7 hours and 9 minutes ago]

Tue, 14 Mar 2023 07:04:48 GMT

Op 13/03/2023 om 18:03 schreef yesbird:
> On 13/03/2023 18:42, yesbird wrote:
>> Many thanks, Thomas, I tried it, and it works fine.
> This is why I was looking for it (attached).
> -- 
> YB
> 

;-)

I would expect a bit of shadow /under/ the beetle though...

-- 
Thomas

[yesbird] Re: Studio lighting setup [1129 days 21 hours and 10 minutes ago]

Mon, 13 Mar 2023 17:04:00 GMT

On 13/03/2023 18:42, yesbird wrote:
> Many thanks, Thomas, I tried it, and it works fine.
This is why I was looking for it (attached).
--
YB

[yesbird] Re: Studio lighting setup [1129 days 22 hours and 31 minutes ago]

Mon, 13 Mar 2023 15:42:36 GMT

On 13/03/2023 17:04, Thomas de Groot wrote:
> Maybe this?
> 
> http://www.ignorancia.org/index.php/technical/tools-objects/studio-lighting-kit/
YES, exactly !
Many thanks, Thomas, I tried it, and it works fine.
--
YB

[Thomas de Groot] Re: Studio lighting setup [1130 days and 9 minutes ago]

Mon, 13 Mar 2023 14:04:16 GMT

Op 13-3-2023 om 14:53 schreef yesbird:
> On 13/03/2023 16:07, ingo wrote:
>> Look for basic portrait photography lighting. It works very well for 
>> single
>> objects.
>> This came up with a quick search,
>>
https://askboxs.com/2014/09/30/what-are-the-5-basic-lighting-setups-used-in-studio-portrait-photography/
> Thanks, but unfortunately this link is not work, and may be I is should
> say, that I mean some ready-to-use examples of POV scenes.
> -- 
> 
Maybe this?

http://www.ignorancia.org/index.php/technical/tools-objects/studio-lighting-kit/

-- 
Thomas

[yesbird] Re: Studio lighting setup [1130 days and 20 minutes ago]

Mon, 13 Mar 2023 13:53:15 GMT

On 13/03/2023 16:07, ingo wrote:
> Look for basic portrait photography lighting. It works very well for single
> objects.
> This came up with a quick search,
>
https://askboxs.com/2014/09/30/what-are-the-5-basic-lighting-setups-used-in-studio-portrait-photography/
Thanks, but unfortunately this link is not work, and may be I is should
say, that I mean some ready-to-use examples of POV scenes.
--
YB

[ingo] Re: Studio lighting setup [1130 days 1 hour and 4 minutes ago]

Mon, 13 Mar 2023 13:10:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> Hi,
> I need your advice in setting up lighting for different scenes, at
> present time mostly for single objects, turned around Y axis (turntable
> animation).

Look for basic portrait photography lighting. It works very well for single
objects.
This came up with a quick search,
https://askboxs.com/2014/09/30/what-are-the-5-basic-lighting-setups-used-in-studio-portrait-photography/

ingo

[yesbird] Studio lighting setup [1130 days 4 hours and 8 minutes ago]

Mon, 13 Mar 2023 10:05:48 GMT

Hi,
I need your advice in setting up lighting for different scenes, at
present time mostly for single objects, turned around Y axis (turntable
animation).

Achieving a good lighting environment is a challenging task, especially
for new users. When I was working with VRay, I found a set of
ready-to-use scenes with lights, light-boxes, umbrellas, etc. for
different cases, such as jewelry, faces, body, glossy objects, etc.
which helps me to start setting up my own.

I read this tips:
http://warp.povusers.org/povtips/
but it's only a basics, I would like to have set of professionally done
examples.

Could you please help me to find them, at least point where to start ?
Thanks in advance,
--
YB

[William F Pokorny] Re: lemon {} revisited [1130 days 10 hours and 38 minutes ago]

Mon, 13 Mar 2023 03:35:40 GMT

On 3/12/23 08:45, Bald Eagle wrote:
> Perhaps an interesting thing to have available in povr would be a "global
> bounding box" for the scene in the render statistics.  It could help clue scene
> authors in to overlooked distance issues and maybe help track down spuriously
> placed objects, as well as resolve other weird issues.

I'm thinking some about this and unsure how to do it in any general way 
that would not often raise false alarms.

> On to the trivial solution.
> Spindle torus, did you say?

I'll write more about accuracy stuff here so folks are not left too 
'depressed' about higher order inbuilt shapes like the lemon. ;-)

Attached is another image with three shapes left to right where the 
orthographic camera is again pulled back about -2000 from the origin 
where the shapes sit. In fact even -2e6 is no problem.

The middle and right shapes are an isosurface, f_torus 'intersect' 
spindle and on the right is the torus 'intersect' spindle. A good 
question is why do these shapes seem to be immune to the camera set back 
(to the long ray length)?

The answer is both shapes have low order container shapes which are in 
fact the first intersection. The isosurface shape uses either a box or a 
sphere(a) which users specify as the container. The torus internally 
creates a bounding sphere which is the first intersection(a).

On the left is again the lemon, but now it works! It does because I did 
this:

union {
     box { -1,1 pigment {rgbt <0,0,0,1>} } // <--- low order bounding(a)
     lemon {
       <0, -Y, 0>, 0, <0, Y, 0>, 0, r
       texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
     //sturm
     }
     translate <-.7,0,-.1>
}

Bill P.

(a) - This kind of outer bounding certainly helps and is often a decent 
work-around, but it is not a general solution. For example, when the 
shapes themselves are large (big interior) - as the ray->surface 
equation and solvers see the shape. Or where the type of csg forces the 
from camera intersections.

The union, clear, first shape bounding can also introduce issues / 
artefacts with other shapes in the scene because that invisible surface 
exists in the scene.

Aside: An attractive argument for representing all shapes with low 
order, mesh approximations is those low order (simpler) ray->surface 
equations tolerate MUCH longer ray to surface distances on cpu float 
hardware.

[William F Pokorny] Re: lemon {} revisited [1130 days 18 hours and 1 minute ago]

Sun, 12 Mar 2023 20:12:24 GMT

On 3/12/23 13:41, Bald Eagle wrote:
> I also have a usage question with regard to orthographic:
> I did not seem to be able to get this particular inclusion of the "angle"
> keyword to work as described, but maybe I didn't try hard enough, or my camera
> {} block was malformed.

My only experience using orthographic & angle was first setting up a 
perspective view of solver test cases - where the camera needs be a 
significant distance away with smaller angles. Then I'd flip perspective 
to orthographic to get the, much harder for ray->surface equations and 
solver, ortho rays as another test case. For me all I did was flip the 
camera types... I've got no experience with more.

Where the documentation says:

"Note: The length of direction is irrelevant unless angle is used." is 
true only in an abstract sense. While not the direction vector length, 
the actual length of the ray in that direction absolutely matters with 
respect to how well many shapes work.

If I take my earlier Camera01z set up and change the location to be:

location <0,0,-2*1e3>

I get the attached image of the same identical scene. The ray length 
went from ~2 to ~2000.

Bill P.

(a) - To some extent it matters to other camera types(b) (or say light 
positions for shooting photons), but in other cases the rays are almost 
all coming in at some angle relative to the scene objects - and this 
alone helps the ray->surface equations set up and the solvers.

(b) - I had too sovler tests for extremely small angle perspective 
cameras 1-2 degrees and these too often turn up equation set up / solver 
issues both because the camera rays are nearing orthogonal, but also due
the length.

[Bald Eagle] Re: lemon {} revisited [1130 days 20 hours and 29 minutes ago]

Sun, 12 Mar 2023 17:45:00 GMT

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

> My (-z / looking toward +z) orthographic camera code is:

I also have a usage question with regard to orthographic:
I did not seem to be able to get this particular inclusion of the "angle"
keyword to work as described, but maybe I didn't try hard enough, or my camera
{} block was malformed.  It would make my life easier instead of having to
switch between 2 different cameras and define (guess at) a Zoom value, like I do
now.


https://wiki.povray.org/content/Reference:Camera#Orthographic_projection


If, in a perspective camera, you replace the perspective keyword by orthographic
and leave all other parameters the same, you will get an orthographic view with
the same image area, i.e. the size of the image is the same. The same can be
achieved by adding the angle keyword to an orthographic camera. A value for the
angle is optional. So this second mode is active if no up and right are within
the camera statement, or when the angle keyword is within the camera statement.

....

Note: The length of direction is irrelevant unless angle is used. The lengths of
up and right define the dimensions of the view. The angle keyword can be used,
as long as less than 180. It will override the length of the right and up
vectors (the aspect ratio between up and right will be kept nevertheless) with a
scope of a perspective camera having the same direction and angle.

[William F Pokorny] Re: lemon {} revisited [1130 days 22 hours and 19 minutes ago]

Sun, 12 Mar 2023 15:54:57 GMT

On 3/12/23 10:30, Bald Eagle wrote:
> It's just the sign.  I was just wondering if the native implementation of the
> torus was "wrong", since I recall the uv-mapping being off compared to most
> other shapes.

You remember correctly. :-)

IIRC think we found the torus 'uv_mapping' reversed (handedness) 
compared to all other uv mapping in POV-Ray. It was for a short time 
corrected, but then restored to what it had been since v3.7 to maintain 
compatibility with old scenes. IIRC povr stuck with the corrected uv 
mapping - but that memory of mine might be wrong...

Aside: It's also true the new 'uv_mapping' added to additional shapes 
for v3.8/v4.0 was turned back off for other general 'uv_mapping' 
concerns. This is one place where our current v3.8 documentation does 
not align with the real state of v3.8 - the last I checked. In pulling 
back the newer 'uv_mapping' I 'think' povr  did too in the moment, 
thinking a fix would soon be adopted - but that never happened and I 
believe povr aligns with v3.8/v4.0.

Bill P.

[William F Pokorny] Re: lemon {} revisited [1130 days 22 hours and 32 minutes ago]

Sun, 12 Mar 2023 15:41:52 GMT

On 3/12/23 08:45, Bald Eagle wrote:
> IIRC, it was the single-image photogrammetry where I had an issue with all my
> stuff disappearing because it hadn't damned on me how LARGE the objects were,
> and therefore how far back they extended (past the camera plane).   So yeah,
> it's WAAAAAY back.   I'll try to keep those under-the-hood issues about the
> solver and the camera distance in mind.

With the orthographic camera, the distance doesn't matter with respect 
to the size of scene things. The size of the orthographic camera plane / 
rectangle does matter - and that the plane be back a small distance from 
all the objects and bounding in the scene.

The location of the camera's ray shooting plane can be very close to 
objects. The orthographic camera rays are more difficult for the 
solvers, as a rule we should position the orthographic cameras close to 
the objects in the scene.

My (-z / looking toward +z) orthographic camera code is:

//---
#declare VarOrthoMult =
5.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
//---

To see a larger part of the x/y plane in the scene, I change that 5.0 
multiplier to something larger.

---

The spindle modes of the regular torus were added to v3.8 and have now 
existed some years (4-5 give or take?), the f_torus modes came with the
addition of functions, the isosurface object and the function vm - which 
I think goes back to v3.5. Those working in v3.7 would have only the 
f_torus spindle options available. The lemon too isn't there in v3.7 
being new in v3.8.

Bill P.

[Bald Eagle] Re: lemon {} revisited [1130 days 23 hours and 39 minutes ago]

Sun, 12 Mar 2023 14:35:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
> nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.

I did the same but needed to remove the fudge factor to transition from the
sphere to the lemon.

My isosurface still need the fudge factor, else I still have the cylinder of
crud.

> and the interior/exterior textures look correct now. A clue to something?

It's just the sign.  I was just wondering if the native implementation of the
torus was "wrong", since I recall the uv-mapping being off compared to most
other shapes.

[Kenneth] Re: lemon {} revisited [1131 days and 44 minutes ago]

Sun, 12 Mar 2023 13:30:00 GMT

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

>
> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface.

The speckling was even worse for me.

By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.
>
> The other issue is that the isosurface seems to have the interior_texture
> on the outside, and the texture on the inside.
>

As an experiment, I negated your spindle function...
      #declare Iso =
      isosurface {
       function {-Spindle (x, y, z)}...

and the interior/exterior textures look correct now. A clue to something?

[Bald Eagle] Re: lemon {} revisited [1131 days 1 hour and 24 minutes ago]

Sun, 12 Mar 2023 12:50:00 GMT

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

Haha!  Your previous post jogged something in my memory that provides a truly
trivial solution.

> Ah, and you are using an orthographic camera.

Yes.  Any time you see me doing graphs and drafting layout lines, there's a 99%
chance it's an orthographic camera.

> This often the worst case
> ray set up for the solvers. Other shapes like the sphere_sweep have
> similar issues with the orthographic camera.

> Right.  I hammer through so many exploratory idea and experiments that my default is
a copy-paste from one of the 20 
last-working-scene tabs that  I have open in the editor.

> Your' also positioning well away it looks too.

IIRC, it was the single-image photogrammetry where I had an issue with all my
stuff disappearing because it hadn't damned on me how LARGE the objects were,
and therefore how far back they extended (past the camera plane).   So yeah,
it's WAAAAAY back.   I'll try to keep those under-the-hood issues about the
solver and the camera distance in mind.

> The ray length matters in that the longer it travels the more the
> accuracy of the ray->surface equation degrades in accuracy. The equation
> has to represent all those useless potential landing steps on the way to
> the shapes surface and this burns up the floating point accuracy.

Perhaps an interesting thing to have available in povr would be a "global
bounding box" for the scene in the render statistics.  It could help clue scene
authors in to overlooked distance issues and maybe help track down spuriously
placed objects, as well as resolve other weird issues.

Still not sure what the crud on my isosurface is that gets removed with the
FudgeFactor.   I'll make a quick switch to the perspective camera and see if it
goes away.

On to the trivial solution.
Spindle torus, did you say?
"The merge and intersection spindle modes have long existed with the f_torus,
but via value arguments."
Well, they've long existed for the regular torus primitive too.
Which I had discovered, and therefore "knew", but forgot.

http://news.povray.org/povray.binaries.misc/message/%3C604613ed%241%40news.povray.org%3E/#%3C604613ed%241%40news.povray
.org%3E

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

and so, adding
torus {R, r intersection texture {pigment {rgb z} finish {specular 0.4}}
translate x*2*r}

gives me just what I was looking for.

"Oh, POV-Ray developers, you understand everything!"  :)

[William F Pokorny] Re: lemon {} revisited [1131 days 8 hours and 56 minutes ago]

Sun, 12 Mar 2023 05:17:55 GMT

On 3/11/23 23:47, William F Pokorny wrote:
> It's not the easiest shape for the solvers.

Ah, and you are using an orthographic camera. This often the worst case 
ray set up for the solvers. Other shapes like the sphere_sweep have 
similar issues with the orthographic camera. Your' also positioning well 
away it looks too.

If I step an ortho camera back just -2 in z and code as the lemon:

#declare r = 1;
#declare R = 0.6;
#declare Y = sqrt ( r*r - R*R );
lemon {
   <0, -Y, 0>, 0, <0, Y, 0>, 0, r
   texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
   sturm
   translate <-.1,0,-.1>
}

I get the attached image.

The ray length matters in that the longer it travels the more the 
accuracy of the ray->surface equation degrades in accuracy. The equation 
has to represent all those useless potential landing steps on the way to 
the shapes surface and this burns up the floating point accuracy.

That bit was my painful discovery discussed in the previously referenced 
github issue. I have a solution for best possible floating point 
hardware accuracy, but the implementation is not trivial...

Bill P.

[William F Pokorny] Re: lemon {} revisited [1131 days 9 hours and 26 minutes ago]

Sun, 12 Mar 2023 04:47:49 GMT

On 3/11/23 16:01, Bald Eagle wrote:
> Anyone have any ideas?

I'm in the middle of another code tangle, but...

After the lemon was added and we started to bang on it, a few numerical 
issues turned up. I think most of this was discussed for a time on the 
developer mailing list. No idea what is fixed. What might github have...
Looks like https://github.com/POV-Ray/povray/pull/358 has a little on 
the lemon if you scroll down through the comments. Well, I suppose not 
would help you near term of that work in any case.

A reminder the f_torus inbuilt function implements a couple of the 
spindle modes though it is not directly documented anywhere that I know 
about. See post to povray.binaries.images

Subject: Some v38 torus vs f_torus() information.
Date: 30 Apr 2020 08:32:29

https://news.povray.org/povray.binaries.images/thread/%3C5eaac55d%241%40news.povray.org%3E/

Message: <5eaac55d$1@news.povray.org>

Running your scene with my current development povr code, and without 
sturm(a), I get the attached a result.

Bill P.

(a) - With sturm on I get a tiny nub on the ends bringing the height to
to about where the left and right shapes are. Without it it 'looks' like
the shape is a little more rounded at the ends than your equivalents. 
Might be there is still some other numerical stuff going on... It's not 
the easiest shape for the solvers.

[yesbird] Re: Least Squares fitting [1131 days 9 hours and 37 minutes ago]

Sun, 12 Mar 2023 04:36:35 GMT

On 11/03/2023 23:44, Bald Eagle wrote:
> "yesbird" <nomail@nomail> wrote:
> I'm not sure how you reach that conclusion, since the function takes all of the
> randomly generated points and calculates the center point and radius of a single
> best-fitting sphere.   It fits a sphere to the data, not the other way around.
Yes, exactly, but I mean something like this:
https://www2.latech.edu/~jkanno/packing.pdf

Please find fixed Matlab function in attachment.
Btw, there is a free version of ML, which supports original syntax:
https://octave.org
--
YB

[Kenneth] Re: Least Squares fitting [1131 days 12 hours and 29 minutes ago]

Sun, 12 Mar 2023 01:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> https://math.stackexchange.com/questions/63238/why-do-we-use-a-least-squares-fit
>

Those stackexchange links are proving to be fascinating and really informative;
thanks! Yes, I see now that 'squaring' has many purposes (and Pythagorean
antecedents) regarding the 'sum of squares' method. Lots to absorb!

[Bald Eagle] Re: Least Squares fitting [1131 days 12 hours and 59 minutes ago]

Sun, 12 Mar 2023 01:15:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> So the (naive) question that I've always pondered is, would CUBING the
> appropriate values-- instead of squaring them-- produce an even tighter fit
> between function and data points? (Assuming that I understand anything at all
> about why even 'squaring' is the accepted method, ha.) Although, I imagine that
> squaring is perhaps 'good enough', and that cubing would be an unnecessary and
> more complex mathematical step.
>
> From reading at least various Wikipedia pages re: the discovery or invention of
> 'sum of squares' etc, it kind of gives me the impression that Gauss et al came
> up with the method in an empirical way(?) rather than from any theoretical
> standpoint. And that it simply proved useful.

https://math.stackexchange.com/questions/63238/why-do-we-use-a-least-squares-fit

[Kenneth] Re: Least Squares fitting [1131 days 13 hours and 29 minutes ago]

Sun, 12 Mar 2023 00:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > That's a really nice result of fitting a set of data points to a function.
>
> It's the reverse.  I'm fitting the function describing a line, circle, and
> sphere to the measured data.  It's "as close to all of the data points as
> it can be _simultaneously_".  And so the overall error is minimized.

Got it. Sorry for my reversed and lazy way of describing things.

> > The general idea of finding the AVERAGE of a set of data points is
> > easy enough to understand...
>
> This is an acceptable method, and of course can be found in early
> treatments of computing the errors in data sets.
>
> > But why is 'squaring' then used? What does that actually
> > accomplish? I have not yet found a simple explanation.
>
> "it makes some of the math simpler" especially when doing multiple dimension
> analyses.
>
> (the variance is equal to the expected value of the square of the distribution
> minus the square of the mean of the distribution)
>

So the (naive) question that I've always pondered is, would CUBING the
appropriate values-- instead of squaring them-- produce an even tighter fit
between function and data points? (Assuming that I understand anything at all
about why even 'squaring' is the accepted method, ha.) Although, I imagine that
squaring is perhaps 'good enough', and that cubing would be an unnecessary and
more complex mathematical step.

From reading at least various Wikipedia pages re: the discovery or invention of
'sum of squares' etc, it kind of gives me the impression that Gauss et al came
up with the method in an empirical way(?) rather than from any theoretical
standpoint. And that it simply proved useful.

[Bald Eagle] Re: Least Squares fitting [1131 days 14 hours and 44 minutes ago]

Sat, 11 Mar 2023 23:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> That's a really nice result of fitting a set of data points to a function.

It's the reverse.  I'm fitting the function describing a line, circle, and
sphere to the measured data.  It's "as close to all of the data points as it can
be _simultaneously_".  And so the overall error is minimized.

> But
> I wish I understood what all of this was about-- starting with the fundamental
> idea of the  'sum of least SQUARES' and why 'squaring' the residual data errors
> is used in these techniques.

I never did much in those areas either.  And to be honest, it's "dangerous" to
be doing serious work with measured values and not understand the basics of the
statistics.  When I worked at American Cyanamid, they had a statistician come in
and give a presentation - in which he showed like 8 sets of data that all had
the same standard deviation, and all looked completely different.

> The general idea of finding the AVERAGE of a set of data points is easy enough
> to understand, as is finding the deviations  or 'offsets' of those points from
> the average.

This is an acceptable method, and of course can be found in early treatments of
computing the errors in data sets.

> But why is 'squaring' then used? What does that actually
> accomplish? I have not yet found a simple explanation.

"it makes some of the math simpler" especially when doing multiple dimension
analyses.

(the variance is equal to the expected value of the square of the distribution
minus the square of the mean of the distribution)

You're also doing a sort of Pythagorean/Euclidean distance calculation, and
that's done with squares rather than absolute values.

"Variances are additive for independent random variables"
"Say I toss a fair coin 900 times. What's the probability that the number of
heads I get is between 440 and 455 inclusive? Just find the expected number of
heads (450 ), and the variance of the number of heads (225=152
), then find the probability with a normal (or Gaussian) distribution with
expectation 450 and standard deviation 15 is between 439.5 and 455.5."

"while the absolute value function (unsquared) is continuous everywhere, its
first derivative is not (at x=0). This makes analytical optimization more
difficult"

https://stats.stackexchange.com/questions/118/why-square-the-difference-instead-of-taking-the-absolute-value-in-standar
d-devia

https://stats.stackexchange.com/questions/46019/why-squared-residuals-instead-of-absolute-residuals-in-ols-estimation

"A lot of reasons."

[Kenneth] Re: Least Squares fitting [1131 days 16 hours and 39 minutes ago]

Sat, 11 Mar 2023 21:35:00 GMT

That's a really nice result of fitting a set of data points to a function.  But
I wish I understood what all of this was about-- starting with the fundamental
idea of the  'sum of least SQUARES' and why 'squaring' the residual data errors
is used in these techniques.  I don't remember ever being introduced to that
concept, in either high-school or college maths classes. (But, I never took a
course in statistics.) The various internet articles on the subject that I have
read over the years are woefully complex and do not explain the *why* of it.

From the Wikipedia article "Partition of sums of squares":
"The distance from any point in a collection of data, to the mean of the data,
is the deviation. ...If all such deviations are squared, then summed, as in
[equation], this gives the "sum of squares" for these data."

The general idea of finding the AVERAGE of a set of data points is easy enough
to understand, as is finding the deviations  or 'offsets' of those points from
the average. But why is 'squaring' then used? What does that actually
accomplish? I have not yet found a simple explanation.

[Bald Eagle] Re: lemon {} revisited [1131 days 16 hours and 54 minutes ago]

Sat, 11 Mar 2023 21:20:00 GMT

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

> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface. (I have
> rendered several successful test lemons in 3.8)
>
> You can just see it in the render.  This makes me sad, as I know Jerome Grimbert
> did a lot of work on this shape.

And wouldn't you know it, subtracting that exact same FudgeFactor from the
radius in the lemon {} makes it show up, but as a sphere, not the shape that I'm
shooting for.

Puzzling.

[Bald Eagle] lemon {} revisited [1131 days 17 hours and 9 minutes ago]

Sat, 11 Mar 2023 21:05:00 GMT

I was interested in using a lemon, or the inner surface of a spindle torus, or
the surface of revolution of a vesica piscis - whichever terminology you prefer
- to compare to a surface.

There is precious little information that I can find describing the lemon, and I
wanted a parameterized object.

The documentation doesn't have a diagram of how the lemon {} available in
version 3.8 is constructed (like it does for the ovus {} ), and the explanation
took me longer than it should have to clearly understand.

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

Presently, I have two problems. And one other issue.

First, when I try to render the lemon {} object with the current parameters, I
only get a very faint speckling rather than a well-formed surface. (I have
rendered several successful test lemons in 3.8)

You can just see it in the render.  This makes me sad, as I know Jerome Grimbert
did a lot of work on this shape.

Second, after I finally worked out how to isolate the inner surface of a
standard torus using an isosurface, I found that I needed to add a Fudgefactor
to the minor radius in order to remove a lot of artefactual noise.  I found the
0.2 magnitude of the FudgeFactor to be disturbingly large.

(Maybe I would have better luck with a polynomial object.)

The other issue is that the isosurface seems to have the interior_texture on the
outside, and the texture on the inside.

Anyone have any ideas?

// -------------------------------------------------------------------------

#version 3.8;
global_settings {assumed_gamma 1}
#declare E = 0.00001;


#declare Zoom = 160;
camera {
 orthographic
 //angle
 location <0, 0,  -image_width*2>
 right x*image_width/Zoom
 up y*image_height/Zoom
 //sky y
 look_at <0, 0, 0>
 rotate y*0
}

light_source {<image_width/2, image_height/2, -image_width*4> rgb 1 shadowless}
sky_sphere {pigment {rgb 1}}


#declare R = 3;
#declare r = 0.25;

#declare Line = 0.01;


#macro LemonLayout (Radius, Distance, Points)
 #local Circle =
 union {
  sphere {0, Line*2}
  torus {Radius, Line rotate x*90}
  pigment {rgb x}
 }
 object {Circle translate  x*Distance}
 object {Circle translate -x*Distance}

 #if (Points)
 union {
  #for (Phi, 0, tau, 0.1)
   #for (Theta, 0, tau, 0.1)
    #local X = Radius * cos (Theta) * sin (Phi) - Distance;
    #if (X >= 0)
     #local Y = Radius * sin (Theta);
     #local Z = X * sin (Phi);
     sphere {<X, Y, Z>, Line*2}
    #end

   #end
  #end
  pigment {rgb z}
 }
 #end

#end


#declare MF = 0.6;
#declare Min_factor= min (MF, 1);
#declare Max_gradient = 250;
#declare P0 = Max_gradient * Min_factor;
#declare P1 = sqrt (Max_gradient/(Max_gradient * Min_factor));
#declare _P2 = 0.7;
#declare P2 = min (_P2, 1);

#declare r = 1;
#declare R = 0.6;

// intersection points of 2 circles
// (x+R)(x+R) + y*y = r*r
// (x-R)(x-R) + y*y = r*r

// x*x + 2*R*x + R*R + y*y = r*r
// x*x - 2*R*x + R*R + y*y = r*r

//       4*R*x = 0
//           x = 0

//  y = sqrt ( r*r - R*R )

#declare Y = sqrt ( r*r - R*R );

#declare FudgeFactor = 0.2;


#declare Torus = function {pow (x*x + y*y + z*z + R*R - r*r, 2) -
4*R*R*(x*x+z*z)}
#declare Spindle = function {select ((r-R)*(r-R) - (x*x+z*z) + FudgeFactor, 0,
pow (x*x + y*y + z*z + R*R - r*r, 2) - 4*R*R*(x*x+z*z))}

#declare Iso =
isosurface {
 function {Spindle (x, y, z)}

 contained_by { box {<-(R-r), -Y, -(R-r)>, <R-r, Y, R-r>} }  // container shape
 accuracy 0.001
 max_gradient 250
 //evaluate P0, P1, P2
 open
 texture {
  pigment {rgb z}
  finish {specular 0.4}
 } // end texture

  interior_texture
  {
  pigment {rgb x+y}
  finish {specular 0.4}
 } // end texture

} // end isosurface



union {
 LemonLayout (1, 0.6, no)
 object {Iso }
 translate -x*r
}

union {
 LemonLayout (1, 0.6, no)
 object {Iso}
 rotate y*90 translate x*r
}


lemon {
 <0, -Y, 0>, 0, <0, Y, 0>, 0, r
 texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
 sturm
}

[Bald Eagle] Re: Least Squares fitting [1131 days 17 hours and 29 minutes ago]

Sat, 11 Mar 2023 20:45:00 GMT

"yesbird" <nomail@nomail> wrote:

> I'am afraid that this paper describes the opposite process: fitting something
> _into_ sphere. I mean counctrusting arbitrary form _from_ spheres of different
> radiuses to achieve best fit (most completed volume). Sorry for
> misunderstanding.

I'm not sure how you reach that conclusion, since the function takes all of the
randomly generated points and calculates the center point and radius of a single
best-fitting sphere.   It fits a sphere to the data, not the other way around.

> Despite that, I forced this Matlab function to work, fixing a few typos.

Excellent.  Maybe Matlab can process mesh vertices / point clouds too?

[yesbird] Re: Least Squares fitting [1131 days 19 hours and 29 minutes ago]

Sat, 11 Mar 2023 18:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> https://arxiv.org/ftp/arxiv/papers/1506/1506.02776.pdf
> ...
> I have no idea where the crazy "sphere parametrization" equations come from, but
> I used _normal_ equations, and fixed a typo in the last line of code (needs
> -'s), and got that to work.

I'am afraid that this paper describes the opposite process: fitting something
_into_ sphere. I mean counctrusting arbitrary form _from_ spheres of different
radiuses to achieve best fit (most completed volume). Sorry for
misunderstanding.

Despite that, I forced this Matlab function to work, fixing a few typos.

In any case this was an interesting investigation, I suppose, we can use this
method in future for something useful.
--
YB

[Bald Eagle] Re: Least Squares fitting [1131 days 21 hours and 44 minutes ago]

Sat, 11 Mar 2023 16:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> yesbird <sya### [at] gmailcom> wrote:
>
> > I can imagine following application: we have volume, constrained by low-
> > poly mesh and want to fill it with spheres with radiuses from Rmin to
> > Rmax, achieving randomized, natural-like form.
>
> Well, that of course suggests that there's an analogous spherical method.  I'll
> have to look and see...

https://arxiv.org/ftp/arxiv/papers/1506/1506.02776.pdf

I have no idea where the crazy "sphere parametrization" equations come from, but
I used _normal_ equations, and fixed a typo in the last line of code (needs
-'s), and got that to work.

Render is the test data in the table of the paper.

[Bald Eagle] Re: Least Squares fitting [1132 days and 54 minutes ago]

Sat, 11 Mar 2023 13:20:00 GMT

It occurred to me that I never described what the render shows.

The yellow circle shows the algebraic result when then data is restricted to a
small arc.   (now WAY off) The red circle is the geometric result which gives a
much more accurate result, but requires an initial "guess" for the center and
radius - which the algebraic method provides.

[Bald Eagle] Re: Least Squares fitting [1132 days 1 hour and 14 minutes ago]

Sat, 11 Mar 2023 13:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:

> I can imagine following application: we have volume, constrained by low-
> poly mesh and want to fill it with spheres with radiuses from Rmin to
> Rmax, achieving randomized, natural-like form.

Well, that of course suggests that there's an analogous spherical method.  I'll
have to look and see...

[yesbird] Re: Least Squares fitting [1132 days 11 hours and 55 minutes ago]

Sat, 11 Mar 2023 02:18:28 GMT

On 11/03/2023 02:35, Bald Eagle wrote:
> Onwards we trudge....
Very interesting investigation !
I can imagine following application: we have volume, constrained by low-
poly mesh and want to fill it with spheres with radiuses from Rmin to
Rmax, achieving randomized, natural-like form. Using this method with
blobs can solve main blob-construction problem - low control and
accuracy.
--
YB

[Bald Eagle] Least Squares fitting [1132 days 14 hours and 34 minutes ago]

Fri, 10 Mar 2023 23:40:00 GMT

So, I've had a few ideas that I've wanted to pursue, and for those, I need a few
tools to perform the tasks more rigorously than "by eye".

I looked at converting some Javascript code, but gave up on that,
https://jsxgraph.uni-bayreuth.de/wiki/index.php/Least-squares_circle_fitting
then found a semi-encouraging post,
https://www.codeproject.com/Questions/228108/Linear-least-squares-circle-fit-in-C-or-Cplusplus
and then found the original paper,
https://ir.canterbury.ac.nz/bitstream/handle/10092/11104/coope_report_no69_1992.pdf?sequence=1
which I thought I could puzzle out - the solution seemed tantalizingly close,
https://towardsdatascience.com/building-linear-regression-least-squares-with-linear-algebra-2adf071dd5dd
https://online.stat.psu.edu/stat462/node/132/
But good ole' Coope just used too many x's and changes of variables, and
sparsely described methods of getting from point A to point B.

Luckily, I found some "good" c++ code, and I was able to successfully convert
the Taubin algebraic solution before I left for work:
https://people.cas.uab.edu/~mosya/cl/CPPcircle.html
and then got back home and worked on the geometric Levenberg-Marquardt fit, only
to find that it's written with a host of ugly "goto" statements.  :O :(

I somehow navigated a path to simulate that in SDL, code the few dependencies,
and fake or ignore the rest.  Got stuck in an endless while loop somewhere when
I started whittling down the circle to an arc of pi*0.6, but fixed that, and...

Seems to be working well enough.   So now I have a regular linear least squares
regression macro, and at least one set of (seemingly) fully functional circle
fitting macros.


Onwards we trudge....

[yesbird] Re: Applying noise to geometry [1142 days 19 hours and 57 minutes ago]

Tue, 28 Feb 2023 18:16:53 GMT

On 27/02/2023 21:32, yesbird wrote:
> Hi,
> while working on Yes-project, I am trying to find the way of making
> the objects less 'geometrical', giving them more natural and 'noisy'
> shapes (like in this attachment, for example). The only way I found in
> manual is to play with normals, but I'd like to have an influence on
> geometry, to apply more relief.

Thanks to all your comments, advice and links, a solution was finally
found. Script is working by making a path of spheres along a spline and
applying relief elements to each sphere. It's left only to make some
randomization and push code to the parameterized macro.

Thanks a lot to everyone !
--
YB

[yesbird] Re: Applying noise to geometry [1142 days 23 hours and 54 minutes ago]

Tue, 28 Feb 2023 14:20:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> See attachment.
Thanks :)

[Thomas de Groot] Re: Applying noise to geometry [1143 days and 59 minutes ago]

Tue, 28 Feb 2023 13:14:53 GMT

Op 28-2-2023 om 07:58 schreef ingo:
> yesbird <sya### [at] gmailcom> wrote:
>> thanks for ideas and examples. Although fist method works fine, second
>> looks more attractive, as, I suppose, will allow 'decorate' imported
>> mesh, which gives me more control on the object's shape.
> 
> I.i.r.c. Poseray https://sites.google.com/site/poseray/ can do mesh displacement
> based on uv vectors and images. Never tried it myself.
> 
> ingo
> 
> 
See attachment.
-- 
Thomas

[yesbird] Re: Applying noise to geometry [1143 days 5 hours and 2 minutes ago]

Tue, 28 Feb 2023 09:11:45 GMT

On 28/02/2023 11:29, ingo wrote:
> A long time ago I wrote an unfinished tool to convert mesh2 to obj files.
> Something like that could be made to write a bunch of pov-ray arrays to a file.
> Then you have full control over the mesh and can transform it by using uv
> information and functions.
> Or, ask FlyerX to add such an option to Poseray, if they are still working on
> it.
Thanks for another idea, but I would like to stay 'inside' POV as long 
as possible, avoiding external tools. Now, after a few experiments, I 
see, that adding some arbitrary 'extensions' to geometry (as in the 
attached image, for ex.) is not too complicated.

Maybe I will try to shift the mesh's vertices according to some noise 
function too.
--
YB

[ingo] Re: Applying noise to geometry [1143 days 5 hours and 44 minutes ago]

Tue, 28 Feb 2023 08:30:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> On 28/02/2023 09:58, ingo wrote:

> Mmm, Poseray ...
> I have one, but it's almost the same as importing mesh from ZBrush.
> Your first advice about using 'meshmaker' seems more attractive to me...

A long time ago I wrote an unfinished tool to convert mesh2 to obj files.
Something like that could be made to write a bunch of pov-ray arrays to a file.
Then you have full control over the mesh and can transform it by using uv
information and functions.
Or, ask FlyerX to add such an option to Poseray, if they are still working on
it.

https://news.povray.org/povray.binaries.utilities/thread/%3CXns94F5A773245Aseed7%40news.povray.org%3E

ingo

[yesbird] Re: Applying noise to geometry [1143 days 6 hours and 27 minutes ago]

Tue, 28 Feb 2023 07:47:04 GMT

On 28/02/2023 09:58, ingo wrote:
> I.i.r.c. Poseray https://sites.google.com/site/poseray/ can do mesh displacement
> based on uv vectors and images. Never tried it myself.
Mmm, Poseray ...
I have one, but it's almost the same as importing mesh from ZBrush.
Your first advice about using 'meshmaker' seems more attractive to me...
--
YB

[ingo] Re: Applying noise to geometry [1143 days 7 hours and 14 minutes ago]

Tue, 28 Feb 2023 07:00:00 GMT

yesbird <sya### [at] gmailcom> wrote:
> thanks for ideas and examples. Although fist method works fine, second
> looks more attractive, as, I suppose, will allow 'decorate' imported
> mesh, which gives me more control on the object's shape.

I.i.r.c. Poseray https://sites.google.com/site/poseray/ can do mesh displacement
based on uv vectors and images. Never tried it myself.

ingo

[yesbird] Re: Dynamic sphere sweep [1143 days 8 hours and 6 minutes ago]

Tue, 28 Feb 2023 06:07:48 GMT

On 28/02/2023 08:57, Cousin Ricky wrote:
> You specify 4 as the number of points, but you are counting by 0.1,
> which gives 40 points.
Oh, really, thanks a lot !

> One of the more annoying features of POV-Ray IMO is having to count the
> points beforehand, but it is what it is.
Indeed, I've already fallen into this pitfall, and now did it again...
--
YB

[Cousin Ricky] Re: Dynamic sphere sweep [1143 days 8 hours and 16 minutes ago]

Tue, 28 Feb 2023 05:57:46 GMT

On 2023-02-28 01:34 (-4), yesbird wrote:
> Hi,
> can't figure out why this construction don't work:
> -------------------------------------------------
> #declare X = 0;
> sphere_sweep {
> Â  linear_spline
> Â  4,
> Â  #while (X < 4)
> Â Â Â  <X,0,0>, 0.1
> Â Â Â  #declare X = X + 0.1;
> Â  #end
> }
> -------------------------------------------------

You specify 4 as the number of points, but you are counting by 0.1,
which gives 40 points.

One of the more annoying features of POV-Ray IMO is having to count the
points beforehand, but it is what it is.