povray.general message digest

[Cousin Ricky] Re: Some times I just want to play !? [2 days 11 hours and 50 minutes ago]

Sun, 19 Apr 2026 20:35:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
>
> plane{z,-.5 pigment{granite scale 50}finish{reflection.5 ambient 2}}
> plane{z,.1 pigment{rgbf<.9,.5,.1,.9>}}
> plane{z,1 normal{wood 5}finish{reflection.7}}

Weird that the preview thumbnail is a different color than the full image.  I
suspect it is due to rendering without any assumed_gamma.

[Leroy] Some times I just want to play !? [2 days 13 hours and 40 minutes ago]

Sun, 19 Apr 2026 18:45:00 GMT

Some times I just want to play! I go through my old files looking for something
to play with. I love running old code that took a long time to run on my old
system. Now it's lighten fast! Any way I ran into this file, one of many wrote
for the Shortest Code Contest. And I had to share it.

plane{z,-.5 pigment{granite scale 50}finish{reflection.5 ambient 2}}
plane{z,.1 pigment{rgbf<.9,.5,.1,.9>}}
plane{z,1 normal{wood 5}finish{reflection.7}}


 That's it!
Have Fun!

[Bald Eagle] photorealism ray-tracing huamin wang [6 days 13 hours ago]

Wed, 15 Apr 2026 19:25:00 GMT

Yep.

https://www.slideserve.com/rollin/photorealism-ray-tracing-huamin-wang-whmin-cc-gatech-georgia-tech-nov-11-2008

:D

[Bald Eagle] Re: POV-Ray Origins [6 days 19 hours and 45 minutes ago]

Wed, 15 Apr 2026 12:40:00 GMT

"koppi" <jak### [at] gmailcom> wrote:
> Have been using POV-Ray for the past 30 years.

You're the bullet physics playground guy!

Hello - nice to see you here.  :)

- BE

[koppi] Re: POV-Ray Origins [7 days 10 hours and 35 minutes ago]

Tue, 14 Apr 2026 21:50:00 GMT

Have been using POV-Ray for the past 30 years.

[yesbird] Re: Procedural Methods for Two-Dimensional Textu... [8 days 8 hours and 45 minutes ago]

Mon, 13 Apr 2026 23:40:39 GMT

On 14/04/2026 00:13, yesbird wrote:
> Thanks so much for Marbling - this is very close to what I am looking
> for, also would like to find the methods of generation the following
> structures: https://aleksandrajovanic.com/gm-gen-math/

And found them now:
https://paulbourke.net/fractals/clifford/
https://paulbourke.net/fractals/peterdejong/
-- 
YB

[yesbird] Re: Procedural Methods for Two-Dimensional Textu... [8 days 11 hours and 12 minutes ago]

Mon, 13 Apr 2026 21:13:31 GMT

On 13/04/2026 22:59, Bald Eagle wrote:
> Hmm.
> Not to say any of this is directly applicable, but maybe check out "Mathematical
> marbling"
> 
> https://people.csail.mit.edu/jaffer/Marbling/
> 
> Especially:  https://people.csail.mit.edu/jaffer/Marbling/stroke.pdf
> 
> And skim through Daniel Schiffman's _The Coding Train_ youtube channel.
> He has a lot of interactive, mouse-position events in his code, and other people
> submit derivative works on his website.
> ...

Thanks so much for Marbling - this is very close to what I am looking
for, also would like to find the methods of generation the following
structures: https://aleksandrajovanic.com/gm-gen-math/
-- 
YB

[Bald Eagle] Re: Procedural Methods for Two-Dimensional Textu... [8 days 12 hours and 25 minutes ago]

Mon, 13 Apr 2026 20:00:00 GMT

yesbird wrote:

> In Rebelle API I am limited to vector
> operations of brush movement (press, move, release):
>
https://www.escapemotions.com/products/rebelle/motionio_doc/reference/json_events_reference/

Hmm.
Not to say any of this is directly applicable, but maybe check out "Mathematical
marbling"

https://people.csail.mit.edu/jaffer/Marbling/

Especially:  https://people.csail.mit.edu/jaffer/Marbling/stroke.pdf

And skim through Daniel Schiffman's _The Coding Train_ youtube channel.
He has a lot of interactive, mouse-position events in his code, and other people
submit derivative works on his website.

Maybe you could have a collection of Convolution Kernels that you could drag
across an image with the mouse.
Barrel/pincushion optical effect
Color discretization
etc

- BW

[yesbird] Re: Procedural Methods for Two-Dimensional Textu... [8 days 13 hours and 12 minutes ago]

Mon, 13 Apr 2026 19:13:21 GMT

On 13/04/2026 19:42, Bald Eagle wrote:
> I've come across papers like this before, and have suggested doing similar
> studies and experiments.
> 
> You'll probably enjoy:
> 
>
https://news.povray.org/povray.binaries.images/thread/%3C5435dc14@news.povray.org%3E/
> 
>
https://news.povray.org/povray.binaries.animations/thread/%3C5437a2da%241%40news.povray.org%3E/
> 
> One approach might be to use combinatiorics or L-systems to iteratively
> construct non-trivial patterns from the available keywords in the hierarchy.
> ...

Thanks for these links, Bill, the trick is interesting. I am already
using L-Systems in my extension and guess that cellular automata can
give good results also. In Rebelle API I am limited to vector
operations of brush movement (press, move, release):
https://www.escapemotions.com/products/rebelle/motionio_doc/reference/json_events_reference/

and all raster-based diffusion effects can be applied later.
This is the reason why I am prefer contour-based patterns in my
investigations.
--
YB

[Bald Eagle] Re: Procedural Methods for Two-Dimensional Textu... [8 days 15 hours and 40 minutes ago]

Mon, 13 Apr 2026 16:45:00 GMT

yesbird wrote:

> and while looking for interesting ideas like pattern generation, I found
> this paper (attached), that might be a source for additional POV-Ray
> modules.

I've come across papers like this before, and have suggested doing similar
studies and experiments.

You'll probably enjoy:

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

https://news.povray.org/povray.binaries.animations/thread/%3C5437a2da%241%40news.povray.org%3E/

One approach might be to use combinatiorics or L-systems to iteratively
construct non-trivial patterns from the available keywords in the hierarchy.

Set everything up, run an animation of 1-10k frames, and see what pops out.
Have POV-Ray export the list of settings/features/parameters as a .txt file or
..inc file of the exact texture it produces for that frame.

Then it would be easy to scroll through a list of thumbnail images and pick out
the ones that are interesting enough for further study and improvement.

Time-dependent patterns like reaction-diffusion hold really rich promise, but
would have to be evaluated individually to see at what time-point a "good"
pattern emerges.  It's also quite sensitive to initial values.

An archaeological approach might yield interesting results - have a bot scan for
pigments and textures and render 2D and 3D representations of them.  There's 30
years of stuff out there, especially the IRTC.

- BE

[yesbird] Procedural Methods for Two-Dimensional Texture G... [8 days 17 hours and 39 minutes ago]

Mon, 13 Apr 2026 14:46:27 GMT

Greetings !

I am working now on extension to this digital painting software:
https://www.escapemotions.com/products/rebelle/about

and while looking for interesting ideas like pattern generation, I found
this paper (attached), that might be a source for additional POV-Ray
modules.
--
YB

[kurtz le pirate] Re: Post something [8 days 22 hours and 5 minutes ago]

Mon, 13 Apr 2026 10:20:09 GMT

My Chladni patterns inspired from Ingo

--- sdl ----------------------------------------------------------------
camera {
  orthographic
  location <0,0,-1>
  look_at 0
  right x*image_width/image_height
  }

light_source {
  <0,0,-100>
  color rgb 1
  }

#declare fnChladni = function(x,y,z,_n,_m,_l) {
  cos(_n*pi*x/_l)*cos(_m*pi*y/_l) - cos(_m*pi*x/_l)*cos(_n*pi*y/_l)
  }

#declare n = 7; // number of curves
#declare d = 1/(n+1); // gap
#declare ep = 0.008; // line thickness

#declare Col0 = rgb 0; // first color
#declare Col1 = rgb 1; // second color

#declare CMap = color_map {
  [0 Col0 ]
  #declare i = 1;
  #while ( i < n+1 )
   #declare x0 = i*d-ep;
   #declare x1 = i*d+ep;
   [ x0 Col0 ]
   [ x0 Col1 ]
   [ x1 Col1 ]
   [ x1 Col0 ]
   #declare i = i + 1;
  #end
  [ 1 Col0 ]
  }

// Chladni params
#declare m = 5;
#declare n = 13;
#declare l = 0.6;

plane {
  z, 0
  texture {
   pigment {
    function { fnChladni(x,y,z,n,m,l) }
    color_map { CMap }
    }
   }
  }

--- sdl ----------------------------------------------------------------


-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Post something [9 days 17 hours and 55 minutes ago]

Sun, 12 Apr 2026 14:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm posting this here as a proxy for the author, because I just stumbled across
> it and think it's AWESOME.
>
> I'm archiving it at home once I get network access restored.
>
> https://www.geocities.ws/povstairs/

Good news: this library is also in the Object Collection.  An updated version
will reappear on that server when it is restored.  In the meantime, those having
trouble with the above website can access the files at:

https://github.com/LeForgeron/PovContributions/tree/master/staircase/chrisb%202.0

As for the author, he was the original administrator of the Object Collection,
and he disappeared sometime in late 2009.

[ingo] Re: Post something [11 days and 9 minutes ago]

Sat, 11 Apr 2026 08:16:15 GMT

Some ideas regarding Chladni. Untested code in Nim (sorry) as it has to 
fit into my pattern and audio synthesis stuff, but it should not be to 
complex to convert to POV-Ray (I'm tempted).

for a rectangulare plate:

proc chladniRect*(ampA, ampB, m, n, Lx, Ly: float): Pattern =
   proc fn(x, y, z: float): float =
     ampA * sin(PI * m * x / Lx) * sin(PI * n * y / Ly) +
     ampB * sin(PI * n * x / Lx) * sin(PI * m * y / Ly)
   initPattern(fn)


proc chladniRectFreq*(m, n, Lx, Ly, waveSpeed: float): float =
   (waveSpeed / 2.0) * sqrt((m/Lx)*(m/Lx) + (n/Ly)*(n/Ly))

type
   PlateMaterial* = object
     E:   float    # Young's modulus (Pa) - stiffness
     rho: float    # density (kg/mÂ³)
     nu:  float    # Poisson's ratio - lateral contraction
     h:   float    # thickness (m)

const
   Steel* = PlateMaterial(
     E: 200e9, rho: 7800.0, nu: 0.28, h: 0.001
   )

   Aluminium* = PlateMaterial(
     E: 70e9, rho: 2700.0, nu: 0.33, h: 0.001
   )

   Glass* = PlateMaterial(
     E: 70e9, rho: 2500.0, nu: 0.23, h: 0.001
   )

   Wood* = PlateMaterial(          # spruce, along grain
     E: 12e9, rho: 450.0,  nu: 0.35, h: 0.003
   )

   Brass* = PlateMaterial(
     E: 100e9, rho: 8500.0, nu: 0.35, h: 0.001
   )


proc waveSpeed*(mat: PlateMaterial): float =
   ## Flexural wave speed in thin plate
   let B = mat.E * mat.h * mat.h * mat.h /
           (12.0 * (1.0 - mat.nu * mat.nu))    # bending stiffness
   let rhoH = mat.rho * mat.h                  # mass per unit area
   sqrt(B / rhoH)                              # simplified phase velocity


now the other way around:
f_mn = (c / 2) * sqrt((m/Lx)^2 + (n/Ly)^2)
invert
(2f/c)Â² = (m/Lx)^ + (n/Ly)^

now finde modes at frequency
loop over modes, get chladni and sum
this should then be convered to a spectrogram and create the sound from 
that.

It can be extended to 3d room modes so one can simulate small room 
acoustics (below Schroeder freq) and walk trough a .df3 media room that 
show the soundfield.

ingo

[Ilya Razmanov] Re: SVG Recognized colors [11 days 1 hour and 17 minutes ago]

Sat, 11 Apr 2026 07:07:41 GMT

On 10.04.2026 22:06, Bald Eagle wrote:

> Yes, that's always how the seed gets planted.
> Now it's time to act like a real computer programmer

Fortunately, I'm not a programmer, I'm only trying to make computers do 
what I want.

Unfortunately, sometimes it requires programming.

Well, it seems that currently people start to prefer AI, but I'm an old 
Soviet man, so my first question always is "and who is officially 
responsible for this?" Since AI does not have a butt I can kick, it 
can't be held responsible for anything, therefore I don't trust it.

>> but
>> well, I definitely will turn it into complete madness, making things
>> controlled not by just source colors but coordinates and stuff).
> 
> Code on, brother.
> Make it so!

Well, old people like me may remember Photoshop plugins like Xaos Tools 
or MS Impressionist, which were mapping 2D bitmap "brushstrokes" over 
image, varying brush size and direction to simulate painting. Surely, my 
old idea, resulted in POV-Ray Mosaic, was quite obvious: why don't we 
map 3D objects?

Unfortunately, I was having problems even with first version - how do I 
make all this controllable in some way humans can understand? And, since 
new version is about adding more control, it's giving me more problems 
with my memory, "what is this and why I did this?"

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

[Bald Eagle] Re: SVG Recognized colors [11 days 13 hours and 15 minutes ago]

Fri, 10 Apr 2026 19:10:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

> Hey, all I wanted is making Python translate from "what they wrote at
> W3C" to "what I can directly import in POV-Ray, yet call it official
> colors right from W3C".

Yes, that's always how the seed gets planted.
Now it's time to act like a real computer programmer and implement "scope
creep."
:D

> > Also, I recall seeing some very cool python/povray projects that you might enjoy
> > if you search for them.
>
> Are you trying to say that any python/povray project may be more cool
> than mine?!

Only if such a transparent lie spurs you to ensure that no other python/povray
project COULD be cooler, due to your massive, monomaniacal overkill.

> since POV‑Ray does not seem to support any elegant array unpacking,

Natively it doesn't, but I've done some work on that (somewhere) and I think
Leroy has as well.  Please note what you want, and maybe we've written it or
will get around to doing so "soon".

>but
> well, I definitely will turn it into complete madness, making things
> controlled not by just source colors but coordinates and stuff).

Code on, brother.
Make it so!

-BE

[Ilya Razmanov] Re: SVG Recognized colors [11 days 13 hours and 33 minutes ago]

Fri, 10 Apr 2026 18:52:22 GMT

On 29.03.2026 16:13, Bald Eagle wrote:

> Put all of your colors into an array, and all of the names in another.
> 
> Now I can use a #for loop to cycle through the colors, do something with them,
> and just use the text as a label.

Hey, all I wanted is making Python translate from "what they wrote at 
W3C" to "what I can directly import in POV-Ray, yet call it official 
colors right from W3C".

> Also, I recall seeing some very cool python/povray projects that you might enjoy
> if you search for them.

Are you trying to say that any python/povray project may be more cool 
than mine?! And you are saying so right when I updated my img2mesh, and 
have a very weird plans of upgrading my POVâ€‘Ray Mosaic to version 2 
(yes, unpublished ver. 1.5 includes arrays already. Looks totally ugly, 
since POVâ€‘Ray does not seem to support any elegant array unpacking,
but 
well, I definitely will turn it into complete madness, making things 
controlled not by just source colors but coordinates and stuff).

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

[MichaelJF] Re: Post something [11 days 13 hours and 57 minutes ago]

Fri, 10 Apr 2026 18:27:57 GMT

Am 10.04.26 um 19:06 schrieb kurtz le pirate:
> On 08/04/2026 20:39, MichaelJF wrote:
> 
>>
>> Using Firefox, I get a brief glimpse of a website displaying POV- 
>> Stairs macros, but a few seconds later Iâ€™m redirected to a porn
site. 
>> As far as I know, Geocities has been offline since 2009. Perhaps 
>> someone is trying to lure visitors to their website using old content.
>>
> 
> Neither the website nor Firefox is to blame.
> Your computer is simply infected with malware ;)
> 
> 
> 
> 
Should I switch from Ubuntu to Windows?

[ingo] Re: Post something [11 days 14 hours and 23 minutes ago]

Fri, 10 Apr 2026 18:02:36 GMT

On 2026-04-10 19:36, Bald Eagle wrote:


> Maybe this absolute classic will inspire you to forge ahead:

So far I have used cloth animation, springy mesh, to generate sound. 
Adjust tension stiffness mass and sample vertex positions 44100 times 
per sec. Not stable yet. May be useful for Chladni simulation.

My actual goal with cloth is to sample vertices movement, get 
frequencies of that, sort by frequency, create spectrograms, feed those 
to thousands of oscillators.

But there must be a way to get time = frequency in into or out off 
Chadni and go from there to get harmonics. Not looked onto that.

We'll see what comes of it,

ingo

[Bald Eagle] Re: Post something [11 days 14 hours and 45 minutes ago]

Fri, 10 Apr 2026 17:40:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> Chladni patterns... another area I wanted to explore but never got
> around to. Congrats on this “simple” code, too

Maybe this absolute classic will inspire you to forge ahead:

https://www.youtube.com/watch?v=tFAcYruShow

- BE

[kurtz le pirate] Re: Post something [11 days 15 hours and 9 minutes ago]

Fri, 10 Apr 2026 17:16:28 GMT

On 10/04/2026 17:17, ingo wrote:

> 
> #declare Chladni = function(x,y,z,A,B,C,L,M,N){
>  Â  (A * sin(pi * L * x) * sin(pi * M * y) * sin(pi * N * z) +
>  Â  B * sin(pi * M * x) * sin(pi * N * y) * sin(pi * L * z) +
>  Â  C * sin(pi * N * x) * sin(pi * L * y) * sin(pi * M * z)) / (A+B+C)
> }
> 


Chladni patterns... another area I wanted to explore but never got 
around to. Congrats on this â€œsimpleâ€ code, too


-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Post something [11 days 15 hours and 19 minutes ago]

Fri, 10 Apr 2026 17:06:12 GMT

On 08/04/2026 20:39, MichaelJF wrote:

> 
> Using Firefox, I get a brief glimpse of a website displaying POV-Stairs 
> macros, but a few seconds later Iâ€™m redirected to a porn site. As
far as 
> I know, Geocities has been offline since 2009. Perhaps someone is trying 
> to lure visitors to their website using old content.
> 

Neither the website nor Firefox is to blame.
Your computer is simply infected with malware ;)




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Post something [11 days 15 hours and 45 minutes ago]

Fri, 10 Apr 2026 16:40:00 GMT

Ah, the good ole' Chladni functions  :)

I've played around with these in both 2D and 3D.  I think it takes some time to
evaluate all the possibilities and choose the really good patterns that emerge.

The Chladni patterns remind me of the Zernicke polynomials that I investigated
when exploring lens distortions that cause and relieve astigmatism.

And then there are the spherical harmonics and the atomic oribitals.

Presumably there are a lot more related phenomena that could be pressed into
service for 2D patterns and 3D shapes.

It would be even nicer if there exists a way to interpolate between them.

I have an idea for interpolating between all of the 16 different Boolean
operations via Grey code numbers along the edges connecting the vertices of a
hypercube . . .

.... which may require time expansion, insomnia, and something stronger than
coffee and a gin & tomic.

- BE

[ingo] Re: Post something [11 days 17 hours and 7 minutes ago]

Fri, 10 Apr 2026 15:17:58 GMT

---%<---%<---%<---%<
#version 3.7;
global_settings{assumed_gamma 1}
#default{ finish{ambient 0.1 diffuse 0.9}}
camera {
   orthographic
   location <0,0,1> look_at 0
   right x*image_width/image_height
}

#declare Chladni = function(x,y,z,A,B,C,L,M,N){
   (A * sin(pi * L * x) * sin(pi * M * y) * sin(pi * N * z) +
   B * sin(pi * M * x) * sin(pi * N * y) * sin(pi * L * z) +
   C * sin(pi * N * x) * sin(pi * L * y) * sin(pi * M * z)) / (A+B+C)
}

box {
   <-0.5, -0.5, 0>, <0.5, 0.5, 0>
   texture {
     pigment {
       function{Chladni(x,y,z,3.3,4.0,1.0,2.3,3.8,2.1)}
       color_map {
          [0 rgb 0]
          [0 rgb 1]
          [0.05 rgb 1]
          [0.05 rgb 0]
       }
     }
     translate <0,0,0.8>
     scale 0.15

     finish {
       ambient 1.0
       diffuse 0.0
     }
   }
}
---%<---%<---%<---

[Clarence1898] Re: Post something [13 days 10 hours and 40 minutes ago]

Wed, 8 Apr 2026 21:45:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > >
> > > https://www.geocities.ws/povstairs/
> > >
> >
> > Using Firefox: When I go to that URL, I *briefly* see the intended page, which
> > is then interrupted by another page requiring 'notifications' to be sent to me;
> > otherwise I can't access it. I don't know if that's a Geocities thing, or if the
> > site is being hijacked. In any case, I don't like having to accept notifications
> > just to see a page.
> >
> > I wonder if others see the same thing?
>
> I went too that website in duckduckgo.  Briefly saw the staircase page that was
>

immediately followed by the message: This <webpage> can't be found

When I posted the previous message the line containing the message page name was
deleted.  Sent it from firefox on win 11.

The page was whicoosparabed.com

[Clarence1898] Re: Post something [13 days 10 hours and 55 minutes ago]

Wed, 8 Apr 2026 21:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > https://www.geocities.ws/povstairs/
> >
>
> Using Firefox: When I go to that URL, I *briefly* see the intended page, which
> is then interrupted by another page requiring 'notifications' to be sent to me;
> otherwise I can't access it. I don't know if that's a Geocities thing, or if the
> site is being hijacked. In any case, I don't like having to accept notifications
> just to see a page.
>
> I wonder if others see the same thing?

I went too that website in duckduckgo.  Briefly saw the staircase page that was
immediately followed by    This whicoosparabed.com page can’t be found

[MichaelJF] Re: Post something [13 days 13 hours and 46 minutes ago]

Wed, 8 Apr 2026 18:39:19 GMT

Am 08.04.26 um 19:02 schrieb Alain Martel:
> Le 2026-04-08 Ã  09:46, Kenneth a Ã©critÂ :
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>>
>>> https://www.geocities.ws/povstairs/
>>>
>>
>> Using Firefox: When I go to that URL, I *briefly* see the intended 
>> page, which
>> is then interrupted by another page requiring 'notifications' to be 
>> sent to me;
>> otherwise I can't access it. I don't know if that's a Geocities thing, 
>> or if the
>> site is being hijacked. In any case, I don't like having to accept 
>> notifications
>> just to see a page.
>>
>> I wonder if others see the same thing?
>>
>>
>>
>>
> Also using Firefox and no problem.
> Check your antivirus and other security application. Maybe it's over 
> zealous.

Using Firefox, I get a brief glimpse of a website displaying POV-Stairs 
macros, but a few seconds later Iâ€™m redirected to a porn site. As far
as 
I know, Geocities has been offline since 2009. Perhaps someone is trying 
to lure visitors to their website using old content.

Best regards
Michael

[Alain Martel] Re: Post something [13 days 15 hours and 23 minutes ago]

Wed, 8 Apr 2026 17:02:22 GMT

Le 2026-04-08 Ã  09:46, Kenneth a Ã©critÂ :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>
>> https://www.geocities.ws/povstairs/
>>
> 
> Using Firefox: When I go to that URL, I *briefly* see the intended page, which
> is then interrupted by another page requiring 'notifications' to be sent to me;
> otherwise I can't access it. I don't know if that's a Geocities thing, or if the
> site is being hijacked. In any case, I don't like having to accept notifications
> just to see a page.
> 
> I wonder if others see the same thing?
> 
> 
> 
> 
Also using Firefox and no problem.
Check your antivirus and other security application. Maybe it's over 
zealous.

[Bald Eagle] Re: Post something [13 days 16 hours and 30 minutes ago]

Wed, 8 Apr 2026 15:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> I wonder if others see the same thing?

I (obviously) did not.
Try pasting into archive.org's Wayback Machine and use the archived page.

- BE

[jr] Re: Post something [13 days 18 hours and 10 minutes ago]

Wed, 8 Apr 2026 14:15:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > https://www.geocities.ws/povstairs/
> >
>
> Using Firefox: When I go to that URL, I *briefly* see the intended page, which
> is then interrupted by another page requiring 'notifications' to be sent to me;
> otherwise I can't access it. I don't know if that's a Geocities thing, or if the
> site is being hijacked. In any case, I don't like having to accept notifications
> just to see a page.
>
> I wonder if others see the same thing?

I got asked to do a "McAfee anti-virus scan immediately" </grin>.  agree, looks
"hijacked".


regards, jr.

[Kenneth] Re: Post something [13 days 18 hours and 35 minutes ago]

Wed, 8 Apr 2026 13:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> https://www.geocities.ws/povstairs/
>

Using Firefox: When I go to that URL, I *briefly* see the intended page, which
is then interrupted by another page requiring 'notifications' to be sent to me;
otherwise I can't access it. I don't know if that's a Geocities thing, or if the
site is being hijacked. In any case, I don't like having to accept notifications
just to see a page.

I wonder if others see the same thing?

[Bald Eagle] Re: Post something [13 days 19 hours and 25 minutes ago]

Wed, 8 Apr 2026 13:00:00 GMT

I'm posting this here as a proxy for the author, because I just stumbled across
it and think it's AWESOME.

I'm archiving it at home once I get network access restored.

https://www.geocities.ws/povstairs/

[GioSeregni] Re: about #debug [14 days 19 hours and 35 minutes ago]

Tue, 7 Apr 2026 12:50:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > I'm not sure I understand what you mean (epsilon?)
>
> "Epsilon" is a mathematical concept or symbol used to represent the smallest
> value obtainable without actually being zero.
> In programming, it is just used as some small value to represent the difference
> between 2 values, or just a very small number - such as for use in adding or
> subtracting from surfaces in POV-Ray to avoid coincident surface artefacts.
>
>
> > In any case I eventually have to clean up
> > duplicates and corruptions from my 4 decimal approximation.
>
> I have not done any work with processing large meshes, so I don't know if this
> will be of any help.
>
> Can you use an octree to limit the number of vertices that you have to check
> against any other for duplicates?   The pre-sorting might seem like a large
> up-front cost, however the subsequent checking to see if any other vertices in
> that cube have similar connections might be well worth it.
>
> Surely there has to be some prior art to search.   Graphics Gems, academic
> papers, internet article.   RedBlob games, Stack Exchange, Stack Overflow,
> internet articles, YouTube videos...
>
> It has to be a common problem with so many mesh-based applications.
>
> - BE

Yes, I already use it. Here's a test where my 3x3x3 partitions are highlighted
with colors. But I have to say, it's not very helpful. The partitioning is fast,
but it doesn't improve much over time. Perhaps it's because the faces straddle
adjacent partitions and slow down.
But it's not a huge problem, I've now ported all the features to a 64-bit
auxiliary program, and the difference is astonishing. Now I only have the
interface in 32 bit. Then, when everything is ready, I'll convert that too.

[Bald Eagle] Re: about #debug [14 days 19 hours and 50 minutes ago]

Tue, 7 Apr 2026 12:35:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> I'm not sure I understand what you mean (epsilon?)

"Epsilon" is a mathematical concept or symbol used to represent the smallest
value obtainable without actually being zero.
In programming, it is just used as some small value to represent the difference
between 2 values, or just a very small number - such as for use in adding or
subtracting from surfaces in POV-Ray to avoid coincident surface artefacts.

> In any case I eventually have to clean up
> duplicates and corruptions from my 4 decimal approximation.

I have not done any work with processing large meshes, so I don't know if this
will be of any help.

Can you use an octree to limit the number of vertices that you have to check
against any other for duplicates?   The pre-sorting might seem like a large
up-front cost, however the subsequent checking to see if any other vertices in
that cube have similar connections might be well worth it.

Surely there has to be some prior art to search.   Graphics Gems, academic
papers, internet article.   RedBlob games, Stack Exchange, Stack Overflow,
internet articles, YouTube videos...

It has to be a common problem with so many mesh-based applications.

- BE

[GioSeregni] Re: about #debug [14 days 21 hours and 15 minutes ago]

Tue, 7 Apr 2026 11:10:00 GMT

"ingo" <nomail@nomail> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > sorry ...
> > maybe we meant two different things
> > There could be two problems
>
> in your parser/generator output always force 6 digits after the comma. 6 as an
> example, a fixed number. Even if it becomes 1.000000 (POV-Ray will pad with 0's
> to float64 or what it uses internally?)
>
> if you can't and you have four and six digits mixed, that is what the epsilon is
> for. Set it to 0.0001 for example.
>
>
> ingo

I'm not sure I understand what you mean (epsilon?)
PovRay is not the problem
My parser works using double flot. It is better about rotation and normal
computation.
But al the end I prefer to cut small values. They are sometimes born in the
wrong way due to the characteristic of floats.
Sometimes because the model I'm working on was created with absurd decimal
values, due to the modeling software used by those who created them.
In my final output I cut from the fifth decimal place because it is useless for
both rendering and 3D printing.
Or rather, I round to the nearest fourth decimal place.
In any case I eventually have to clean up
duplicates and corruptions from my 4 decimal approximation.
It is not a good thing to cut while I am building a model with CAD, the results
of rotations especially may not coincide.

[ingo] Re: about #debug [14 days 23 hours and 20 minutes ago]

Tue, 7 Apr 2026 09:05:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> sorry ...
> maybe we meant two different things
> There could be two problems

in your parser/generator output always force 6 digits after the comma. 6 as an
example, a fixed number. Even if it becomes 1.000000 (POV-Ray will pad with 0's
to float64 or what it uses internally?)

if you can't and you have four and six digits mixed, that is what the epsilon is
for. Set it to 0.0001 for example.

ingo

[jr] Re: about #debug [14 days 23 hours and 50 minutes ago]

Tue, 7 Apr 2026 08:35:00 GMT

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> sorry ...
> maybe we meant two different things
> There could be two problems
>
> 1) in a triangle a vertex can become the same as another because
> a value as 100,123407 becames 100,1234 which is already at another vertex
> So the triangle is corrupts
>
> 2) two different triangles, because 100,123407 <> 100,1234 can become the same
> triangle cutting off excess decimals

so what is so "special" about writing only to the 4th decimal digit ?  can you
not simply write the six digits after ?  if nothing else it would much reduce
the likelihood of of two vertices or triangles becoming the same through
truncation.

regards, jr.

[GioSeregni] Re: about #debug [15 days and 50 minutes ago]

Tue, 7 Apr 2026 07:35:00 GMT

sorry ...
maybe we meant two different things
There could be two problems

1) in a triangle a vertex can become the same as another because
a value as 100,123407 becames 100,1234 which is already at another vertex
So the triangle is corrupts

2) two different triangles, because 100,123407 <> 100,1234 can become the same
triangle cutting off excess decimals

but if I always formatted the string output for pov ray,
I think comparing strings using various instrings is the least expensive method,
because it does not have other complex mathematical operations...
in any case I always have a redundant triangle in the mesh.. and I have to
eliminate it..

[ingo] Re: about #debug [15 days 2 hours and 45 minutes ago]

Tue, 7 Apr 2026 05:40:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> > #for tw vac's a & b
> > proc ae(a,b): bool
> > return ae(a.x, b.x) and ae(a.y, b.y) and ae(a.z, b.z)
> >
> >
> > depending on the lang.
> >
> >
> > ingo
>
> does not works
> the triangles can to be
> a.x - a.y - a.z
> VS
> b.y . b.z - b.a
>
> and other cases ....

The second one was just comparing two vertices, for a triangle or quad you need
more vertex comparisons.

The mesh library, does it use half edge mesh? You can then count the occurences
of vertex indices. If it does the indexing proper. Too many is an indiction of
problems. Similar with your conversion to mesh2, if you make sure that for each
index you make sure the point is already in the mesh, so no multiple indices to
the same point, the problem can be signalled in that moment.

ingo

[GioSeregni] Re: about #debug [15 days 13 hours and 30 minutes ago]

Mon, 6 Apr 2026 18:55:00 GMT

"ingo" <nomail@nomail> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > Nothing, I think the most efficient solution is to ignore float comparisons,
> > much less divisions.
>
> something like:
>
> ##for floats:
> ## Almost equal.
> proc ae(a, b): bool
> const Epsilon = 0.000001
> return abs(a - b) <= Epsilon
>
>
> #for tw vac's a & b
> proc ae(a,b): bool
> return ae(a.x, b.x) and ae(a.y, b.y) and ae(a.z, b.z)
>
>
> depending on the lang.
>
>
> ingo

does not works
the triangles can to be
a.x - a.y - a.z
VS
b.y . b.z - b.a

and other cases ....

[ingo] Re: about #debug [15 days 14 hours and 20 minutes ago]

Mon, 6 Apr 2026 18:05:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> Nothing, I think the most efficient solution is to ignore float comparisons,
> much less divisions.

something like:

##for floats:
## Almost equal.
proc ae(a, b): bool
const Epsilon = 0.000001
return abs(a - b) <= Epsilon


#for tw vac's a & b
proc ae(a,b): bool
return ae(a.x, b.x) and ae(a.y, b.y) and ae(a.z, b.z)


depending on the lang.


ingo

[GioSeregni] Re: about #debug [15 days 14 hours and 50 minutes ago]

Mon, 6 Apr 2026 17:35:00 GMT

Nothing, I think the most efficient solution is to ignore float comparisons,
much less divisions.
But create the pov file as a temporary one, and reprocess it by comparing
vertices with string functions. If a triangle has two equal vertices, it should
be removed.

[GioSeregni] Re: about #debug [15 days 15 hours and 55 minutes ago]

Mon, 6 Apr 2026 16:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > ok, thanks to all
> > my trouble was about the format of vertex only on ####.####
>
> Is there a way to filter out those triangles from the start?
> Are they even necessary / visible?
>
> You can probably test just the fractional portion of your double/float by using
> modulo.
>
> #if (mod(Number, 1) < threshold) then ignore triangle #else keep it #end
>
> - BE

Unfortunately, it's more complicated. If the mod exists beyond a certain decimal
point, the parser must first clean up the vertex by the small part of float,
then check if a twin face exists.
I'll have to create a twin face search loop after writing the mesh with
formatting that trims small decimal points... that is, a loop nested within
another loop... a lot of runtime.
povray forgives a duplicate face, but the other formats I use do not (for an STL
this is a serious mistake)

[Bald Eagle] Re: about #debug [15 days 16 hours and 25 minutes ago]

Mon, 6 Apr 2026 16:00:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:
> ok, thanks to all
> my trouble was about the format of vertex only on ####.####

Is there a way to filter out those triangles from the start?
Are they even necessary / visible?

You can probably test just the fractional portion of your double/float by using
modulo.

#if (mod(Number, 1) < threshold) then ignore triangle #else keep it #end

- BE

[GioSeregni] Re: about #debug [15 days 17 hours and 40 minutes ago]

Mon, 6 Apr 2026 14:45:00 GMT

ok, thanks to all
my trouble was about the format of vertex only on ####.#### that can to
degenerate triangle losing last decimals ...
if the #debug cannot try them out, I have to control the triangle again after
the formatting procedure of my parser
no proble... this is my parser working
sketch-up , cad, pov STL ..

[GioSeregni] Re: about #debug [15 days 18 hours and 15 minutes ago]

Mon, 6 Apr 2026 14:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > That's what I already do. I wanted to know if, alternatively (when I go from a
> > double float with area to a single float that becomes arealess), when POV
> > automatically detects and marks them, it can also do this in the file.
> >
> > To avoid reprocessing all the normals in the single float.
>
> It cannot.
> That sort of file processing is left to the user.
>
> At present, we have what we have been given in our little open-source collection
> of modules.
>
> And as clipka was fond of saying: "POV-Ray is a raytracer".  And so there's not
> a lot of "extraneous" capability tied in to the parser.
> And we all know clipka's legendary love for the parser.
>
> So, you either need to write a processor yourself in SDL,
> or as a 3rd-party tool in some other language,
> or write something that can perform that task and be integrated into source.
>
> IIRC, I think MeshLab will detect all the bad triangles, close any holes, and
> save a good file.
>
> - BE

OK, now I'm sure there's no way; studying the #debug function, I couldn't figure
out if it was possible.
I'll implement an additional control filter in my parser, along with the
formatting function I use when generating the pov and inc files.
Note: I normally use MeshLab, but be careful with filters. Sometimes, when
closing holes, and especially in decimation, it introduces intersections that
become tedious to track down. If I use these functions, I then test and ask the
entire shape to normalize again, to verify that no bugs have been generated.
Decimation is really dangerous.

[ingo] Re: about #debug [15 days 18 hours and 25 minutes ago]

Mon, 6 Apr 2026 14:00:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> I've studied the #debug feature a bit, but I don't understand. Is there a way to
> tell PovRay to generate a file with only the incorrect entities, or to rewrite
> my file to clean them up?
> It would save me some often long and tedious work.

The mesh2 files are not accessible as arrays, so you can't loop over the content
and check for vertices being ~equal.

Options:
- manually or using a script turn your mesh-file into a file of arrays. Then you
can loop over them and check

- write a small mesh2 parser in a scripting language. There then loop over the
triangles. I once wrote a mesh2 to obj converter in Python. It may still be
somewhere in the newsgroups. I myself lost it.

- use a mesh cleaner. May have to convert to an other format first, or if you
use an other format before converting to mesh2, use that file format to clean.

- check what PoseRay can do (for you) in this regard. I really don't know, it's
been a long time since i used it.

ingo

[Bald Eagle] Re: about #debug [15 days 19 hours ago]

Mon, 6 Apr 2026 13:25:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> That's what I already do. I wanted to know if, alternatively (when I go from a
> double float with area to a single float that becomes arealess), when POV
> automatically detects and marks them, it can also do this in the file.
>
> To avoid reprocessing all the normals in the single float.

It cannot.
That sort of file processing is left to the user.

At present, we have what we have been given in our little open-source collection
of modules.

And as clipka was fond of saying: "POV-Ray is a raytracer".  And so there's not
a lot of "extraneous" capability tied in to the parser.
And we all know clipka's legendary love for the parser.

So, you either need to write a processor yourself in SDL,
or as a 3rd-party tool in some other language,
or write something that can perform that task and be integrated into source.

IIRC, I think MeshLab will detect all the bad triangles, close any holes, and
save a good file.

- BE

[GioSeregni] Re: about #debug [15 days 19 hours and 5 minutes ago]

Mon, 6 Apr 2026 13:20:00 GMT

Let's see if I can make myself understood with a simple example.
I have a triangle.

<1,1,1><2,1,1><2,1,1.00000009>
this is a valid triangle
ok?

but if I made automatically a pov ray file that uses the format ###.####,
writing the pov file , the triangle becomes with

the vertex 3 becomes = vertex 2
and the triangle is invalid
obviously !!!

If I want to avoid re-checking for every triangle in the formatted file, is it
possible to have POV Ray remove them from my file?
In a new, clean file
or, returning a list of the triangles to delete.

[GioSeregni] Re: about #debug [15 days 19 hours and 15 minutes ago]

Mon, 6 Apr 2026 13:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Gio,
>
> It sounds to me like what you want to do is read in a mesh, and perform a vector
> cross product calculation.
>
> That should identify any degenerate triangles, since the cross product will be
> 0.
>
> Discard those, and write the good triangles to a new file.
>
> - BE
That's what I already do. I wanted to know if, alternatively (when I go from a
double float with area to a single float that becomes arealess), when POV
automatically detects and marks them, it can also do this in the file.

To avoid reprocessing all the normals in the single float.
TX
G.

[Bald Eagle] Re: Post something [15 days 19 hours and 40 minutes ago]

Mon, 6 Apr 2026 12:45:00 GMT

tTh <tth### [at] noneinvalid> wrote:

>     Ok ok. I've been working on this animation for two years,
>     and i now publish this version, just a work in progress,
>     but is a nice land for a lot of enhancements.
>
>     https://tube.interhacker.space/w/rNEQbXXZGZFnoabG7uB6FR

I have only gotten a chance to watch a portion of this, but I like it a LOT.
I can see that you've got a bunch of frame ID's. and have some sort of script or
storyboard in your head that you're piecing together.

I have a lot of things going on at the moment, but am looking forward to getting
the time to watch this in full - probably several times.

Two years is a lot time - I hope you make some more progress and fill in the
gaps!
You can also look into making an .srt file to provide subtitles that explain
what's going on, why, and what's still missing.

- BE

[Bald Eagle] Re: about #debug [15 days 20 hours and 15 minutes ago]

Mon, 6 Apr 2026 12:10:00 GMT

Gio,

It sounds to me like what you want to do is read in a mesh, and perform a vector
cross product calculation.

That should identify any degenerate triangles, since the cross product will be
0.

Discard those, and write the good triangles to a new file.

- BE

[GioSeregni] Re: about #debug [18 days 10 hours and 55 minutes ago]

Fri, 3 Apr 2026 21:30:00 GMT

> (sets of three) vectors, then one could read and process those, and "line
> numbers" and eliminating unwanted triangles would become "doable" (if slow).
> with your current file format, ie fully specified meshes, POV-Ray is the wrong
> tool, imo.
>
>
> regards, jr.

Yes, POV-ray isn't responsible for editing files, but for rendering them.
But I had the idea because it can instantly identify small errors in the shape
that I'd missed when switching from double to single. So I wondered if there was
a way to have it list or correct them without having to go back and re-filter
again.....

Note :In the models I finally store, I generally save the final result in single
float with 4 decimal places.
If they're POV or INC, they're more compact and still satisfactory. If they're
3D for print, even more so, because STL requires single float.
thanks!
BR
G.

[jr] Re: about #debug [18 days 13 hours and 35 minutes ago]

Fri, 3 Apr 2026 18:50:00 GMT

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> > re 'trace', yes, you can use the optional parameter to check the normal's not
> > zero and take whatever "action" is needed.
> sorry I can't explain myself well in English

write (an email) in Italian if you prefer.  (I've Google Translate to hand :-))

> I don't need that POV to "fixes" the errors in the final render, or give me an
> error message step by step over the lines.
> I'd like two alternatives.
> A precise report on "where" the errors are (es. list numbers line).
> Or the elimination of corrupt triangles, physically, by overwriting the file I
> pass it.
> My goal is to generate clean meshes.

the file you pass to POV-Ray already is a mesh I assume; I looked at your
'furgone' and 'bmwvintage' files.  problem 1 -- you pass a mesh to POV-Ray.
meaning, that will simply get parsed and "we" (users) get no information.
problem 2 -- selective overwriting, no can do.  if you could pass CSV files with
(sets of three) vectors, then one could read and process those, and "line
numbers" and eliminating unwanted triangles would become "doable" (if slow).
with your current file format, ie fully specified meshes, POV-Ray is the wrong
tool, imo.

regards, jr.

[MichaelJF] Re: about #debug [18 days 13 hours and 40 minutes ago]

Fri, 3 Apr 2026 18:44:52 GMT

Am 03.04.26 um 20:13 schrieb GioSeregni:
> 
>> re 'trace', yes, you can use the optional parameter to check the normal's not
>> zero and take whatever "action" is needed.
>>
> 
> sorry I can't explain myself well in English
> I don't need that POV to "fixes" the errors in the final render, or give me an
> error message step by step over the lines.
> I'd like two alternatives.
> A precise report on "where" the errors are (es. list numbers line).
> Or the elimination of corrupt triangles, physically, by overwriting the file I
> pass it.
> My goal is to generate clean meshes.
> Thanks!
> G.
> 
> 
I fear there more than one misunderstanding here.

POV cannot debug meshes. The #debug statement displays messages to the 
log only. It can be helpful while debugging a scene but does nothing 
more than displaying text.

To fill holes, eliminate duplicate vertices, adjust wrong normals and do 
other repairs on meshes ypu should consider meshlab. Some of these tasks 
can also be achieved using Blender.

Best regards
Michael

[GioSeregni] Re: about #debug [18 days 14 hours and 10 minutes ago]

Fri, 3 Apr 2026 18:15:00 GMT

> re 'trace', yes, you can use the optional parameter to check the normal's not
> zero and take whatever "action" is needed.
>

sorry I can't explain myself well in English
I don't need that POV to "fixes" the errors in the final render, or give me an
error message step by step over the lines.
I'd like two alternatives.
A precise report on "where" the errors are (es. list numbers line).
Or the elimination of corrupt triangles, physically, by overwriting the file I
pass it.
My goal is to generate clean meshes.
Thanks!
G.

[jr] Re: about #debug [18 days 16 hours and 30 minutes ago]

Fri, 3 Apr 2026 15:55:00 GMT

hi, "GioSeregni" <gms### [at] hotmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> thanks, I don't know if I am right, but I think I understand that with that
> function ['trace'] I can automatically correct rendering errors. Is that right?
> I'd like PovRay to intervene by filtering out nonexistent elements INTO my file,
> thus saving me from having to filter out all the normals or zero-surface
> triangles and recompile its file.

perhaps it is me who misunderstands.  you are talking export POV -> yourFormat ?
 (I had thought the other way round)

re 'trace', yes, you can use the optional parameter to check the normal's not
zero and take whatever "action" is needed.

re duplicate vertices, it might be easier to revise the generating scene such
that duplicates cannot occur rather than trying to "weed them out".

> I can fix them, but it would be faster if when POV found them he cleaned the
> file for me

it would be helpful to see a pared-down scene, perhaps part of the generated
data.

regards, jr.

[GioSeregni] Re: about #debug [18 days 18 hours and 10 minutes ago]

Fri, 3 Apr 2026 14:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > ...
> > In POV-ray, two main errors often occur, which POV-ray reports. Typically:
> > 1) normals at 0,0,0 in smooth triangles. This means the triangles are actually
> > three vertices in a line (and this entity should be removed).
> > 2) nonexistent triangle (again, this means two vertices coincide).
> > I can use other exchange programs to find these elements and correct them. But
> > could I do this with POV-ray?
> > I've studied the #debug feature a bit, but I don't understand. Is there a way to
> > tell PovRay to generate a file with only the incorrect entities, or to rewrite
> > my file to clean them up?
>
> I think the 'trace' function may be useful to you.
> <wiki.povray.org/content/Reference:Vector_Expressions#Functions>
>
>
> regards, jr.
thanks, I don't know if I am right, but I think I understand that with that
function I can automatically correct rendering errors. Is that right?
I'd like PovRay to intervene by filtering out nonexistent elements INTO my file,
thus saving me from having to filter out all the normals or zero-surface
triangles and recompile its file.
These things happen because with double float sometimes very small values
differ from each other and everything is fine, but then, when for
various reasons I happen to work and pass values in single
precision, the problem arises.
I can fix them, but it would be faster if when POV found them he cleaned the
file for me

BR
G.

[jr] Re: about #debug [18 days 20 hours and 20 minutes ago]

Fri, 3 Apr 2026 12:05:00 GMT

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> ...
> In POV-ray, two main errors often occur, which POV-ray reports. Typically:
> 1) normals at 0,0,0 in smooth triangles. This means the triangles are actually
> three vertices in a line (and this entity should be removed).
> 2) nonexistent triangle (again, this means two vertices coincide).
> I can use other exchange programs to find these elements and correct them. But
> could I do this with POV-ray?
> I've studied the #debug feature a bit, but I don't understand. Is there a way to
> tell PovRay to generate a file with only the incorrect entities, or to rewrite
> my file to clean them up?

I think the 'trace' function may be useful to you.
<wiki.povray.org/content/Reference:Vector_Expressions#Functions>


regards, jr.

[GioSeregni] about #debug [18 days 22 hours and 35 minutes ago]

Fri, 3 Apr 2026 09:50:00 GMT

Hi all,
I'd already gone a bit off-topic in another thread and preferred not to go into
further detail because I'm working on my own transformation software and
filtering between various formats, including POV and INC files.
I use models for two purposes: both to build and populate my architectural
previews and the shapes for 3D printing. Online models are almost always huge
and full of bugs; by working across different formats, I clean them up,
streamline them, and enhance them. In short, I make them suitable for both the
total rendering memory and the precision required for 3D printing.
In POV-ray, two main errors often occur, which POV-ray reports. Typically:
1) normals at 0,0,0 in smooth triangles. This means the triangles are actually
three vertices in a line (and this entity should be removed).
2) nonexistent triangle (again, this means two vertices coincide).
I can use other exchange programs to find these elements and correct them. But
could I do this with POV-ray?
I've studied the #debug feature a bit, but I don't understand. Is there a way to
tell PovRay to generate a file with only the incorrect entities, or to rewrite
my file to clean them up?
It would save me some often long and tedious work.
Thanks in advanced!
G.

[Sir] Re: POV-Ray Origins [19 days 6 hours and 25 minutes ago]

Fri, 3 Apr 2026 02:00:00 GMT

I've been using POV-Ray for a few months now, and I have to say it's a
masterpiece of software. And, interestingly enough, my birthday is March 26, so
I'll consider this the best birthday present anyone has ever given me.

Thanks!

[David Buck] Re: POV-Ray Origins [19 days 11 hours and 28 minutes ago]

Thu, 2 Apr 2026 20:57:27 GMT

On 2026-04-02 4:23 a.m., Mr wrote:
> David Buck <dav### [at] simberoncom> wrote:
>> On 2026-03-27 11:51 a.m., Bald Eagle wrote:
>>> Were there things that you've always wanted to implement, but never did?
>>
>> I thought it would be interesting to add octree subdivision to the
>> raytracer.  The main raytrace loop goes:
>>
>>      For each ray
>>         For each object in the scene
>>            If the ray intersects the object
>>               Collect the intersection point
>>         End
>>      End
>>
>>      Find the closest intersection point and calculate the lighting
>>
>> With an octree, you divide the space into large cubes and subdivide
>> those cubes that contain something.  The algorithm, then, becomes
>>
>>      For each ray
>>         Traverse empty cubes until you find a non-empty one
>>            Calculate intersections with the small number of objects in
>> that cube.
>>
>> I always thought that it would dramatically speed up the rendering by
>> eliminating the vast majority of the ray/object intersection calculations.
> 
> Does that mean the BSP and BVH are currently not doing this? that would be a
> major bottleneck! (or did you mean you wish you had implemented it yourself?)
> 
> https://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_8_6
> 
> THANKS for all of this of course ! :-) (we all hope that when you retire you get
> back to more poving!)
> 

I like the elegance of an octree solution.  I can't say whether it's 
better or worse than BSP or BVH.  With octrees, however, the ray can be 
traced using a simple variation of a line drawing algorithm.  It might 
even be possible to do it with integer arithmetic until you hit an 
object.  I simply find it an elegant algorithm and was curious if it 
would speed up POV-Ray.  It has the same problem as BSP's where you need 
to build up the model before you can do the raytracing itself.  I just 
find it interesting.

Post retirement, I think it's unlikely I'll get back into the POV-Ray 
code itself, but I may create software that can create models that 
POV-Ray can render.

David Buck

[Jim Henderson] Re: POV-Ray Origins [19 days 15 hours and 27 minutes ago]

Thu, 2 Apr 2026 16:57:45 GMT

Really cool to see you around again, David - it's always interesting to 
see what folks are doing with the software you originally created.  I 
started playing with POV-Ray in the late 80s/early 90s, and while I spend 
less time playing with it today, it is also fun to see the community that 
has grown out of that software and how it has changed over the years.

Jim

-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

[Mr] Re: POV-Ray Origins [20 days ago]

Thu, 2 Apr 2026 08:25:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> On 2026-03-27 11:51 a.m., Bald Eagle wrote:
> > Were there things that you've always wanted to implement, but never did?
>
> I thought it would be interesting to add octree subdivision to the
> raytracer.  The main raytrace loop goes:
>
>     For each ray
>        For each object in the scene
>           If the ray intersects the object
>              Collect the intersection point
>        End
>     End
>
>     Find the closest intersection point and calculate the lighting
>
> With an octree, you divide the space into large cubes and subdivide
> those cubes that contain something.  The algorithm, then, becomes
>
>     For each ray
>        Traverse empty cubes until you find a non-empty one
>           Calculate intersections with the small number of objects in
> that cube.
>
> I always thought that it would dramatically speed up the rendering by
> eliminating the vast majority of the ray/object intersection calculations.

Does that mean the BSP and BVH are currently not doing this? that would be a
major bottleneck! (or did you mean you wish you had implemented it yourself?)

https://www.povray.org/documentation/3.7.0/r3_2.html#r3_2_8_6

THANKS for all of this of course ! :-) (we all hope that when you retire you get
back to more poving!)

[Mr] Re: Post something [20 days and 20 minutes ago]

Thu, 2 Apr 2026 08:05:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2026-03-20 19:21 (-4), Bald Eagle wrote:
> >
> > Post something.  It doesn't matter what it is.
> > Really.   Just post it.  Here.
>
> Funny you should mention.  I was just at a stopping point with this
> experiment for improving my light bleeding code.

This looks very interesting, the dashed line looks like something that could be
diverted for a lot of Non Photo Real effects ! But that streaked star IS also a
very useful work for photoreal looking effects! keep up!

[Cousin Ricky] Re: There is no yellow in the circle [21 days 17 hours and 45 minutes ago]

Tue, 31 Mar 2026 14:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I really do remember selecting the file to attach the image to the first post.
>
> :(
>
> Trying again.

I was able to reduce the size of the image from 220 KB to 18 KB by using -J +R5.

[jr] Re: POV-Ray Origins [21 days 22 hours and 20 minutes ago]

Tue, 31 Mar 2026 10:05:00 GMT

hi,

> Hi everyone.  David (Kirk) Buck here.  I'm the original author of
> DKBTrace and POV-Ray.

(belated) "hello".


"Bald Eagle" <cre### [at] netscapenet> wrote:
> David Buck <dav### [at] simberoncom> wrote:
> ...
> > I thought it would be interesting to add octree subdivision to the
> > raytracer.
>
> I do believe that we have Binary Space Partitioning (BSP) for most things.
> https://www.povray.org/documentation/3.7.0/r3_2.html
> 3.2.8.6 BSP Bounding
>
> > I always thought that it would dramatically speed up the rendering by
> > eliminating the vast majority of the ray/object intersection calculations.
> ...
> > I would like to see the POV-Ray rendering code extracted as a shared
> > library with an API interface.  That way, I can write other software to
> > do any modeling I want without having to output a scene file and run the
> > renderer separately.  I think that would open the door to a lot of new
> > innovation.
>
> It would, and Chris Cason has discussed going in this direction as well.
> We need developers.
> ...
> > Thanks, those were fun questions.
> > David

I had hoped that (at least) this particular part of the dialogue would continue.


regards, jr.

[Bald Eagle] Re: There is no yellow in the circle [22 days 15 hours and 25 minutes ago]

Mon, 30 Mar 2026 17:00:00 GMT

This appears to be an example of Chromatic assimilation or color assimilation,
perhaps attributable to Akiyoshi Kitaoka

https://www.ritsumei.ac.jp/~akitaoka/index-e.html

How fun do some of THESE look to code up in SDL?  :D

- BE

[laser] Re: Post something [22 days 16 hours and 40 minutes ago]

Mon, 30 Mar 2026 15:45:00 GMT

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

> Tried it on my home machine, and it works.
> So at least I can enjoy all the eye candy and juicy shader code.

That's good.  Unfortunately, I do think the quality of the shaders has gone down
a bit.  Not as many "wow"s.

> On a not-unrelated note: 3Blue1Brown just posted a great video on taking the
> logarithm of an image.  It's probably not at all what you think, and way more
> interesting than the title sounds.
>
> I've also had my eye on reproducing the methods used in the paper the video is
> based on for several months.  That's sure to give be a solid base for moving
> forward on it.  :)

Thanks for the tip.  I'll check it out.  I have watched his videos before... And
even used his manim to create some nice effects in my videos.

[Alain Martel] Re: Post something [22 days 19 hours and 4 minutes ago]

Mon, 30 Mar 2026 13:20:59 GMT

Le 2026-03-30 Ã  08:57, Bald Eagle a Ã©critÂ :
> "laser" <nomail@nomail> wrote:
> 
>> Hmmm.,.  I don't know what would cause that.
> 
> Corporate network security.
> It used to load, and now it doesn't.
> 
> Tried it on my home machine, and it works.
> So at least I can enjoy all the eye candy and juicy shader code.
> 
> 
> 
> On a not-unrelated note: 3Blue1Brown just posted a great video on taking the
> logarithm of an image.  It's probably not at all what you think, and way more
> interesting than the title sounds.
> 
> 
> - BE
> 
> 
> 

Watched that video. Very interesting indeed.

[Bald Eagle] Re: Post something [22 days 19 hours and 25 minutes ago]

Mon, 30 Mar 2026 13:00:00 GMT

"laser" <nomail@nomail> wrote:

> Hmmm.,.  I don't know what would cause that.

Corporate network security.
It used to load, and now it doesn't.

Tried it on my home machine, and it works.
So at least I can enjoy all the eye candy and juicy shader code.



On a not-unrelated note: 3Blue1Brown just posted a great video on taking the
logarithm of an image.  It's probably not at all what you think, and way more
interesting than the title sounds.

I've also had my eye on reproducing the methods used in the paper the video is
based on for several months.  That's sure to give be a solid base for moving
forward on it.  :)

- BE

[Kenneth] Re: There is no yellow in the circle [23 days 13 hours and 25 minutes ago]

Sun, 29 Mar 2026 19:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Imaginary colors:
> there is absolutely no yellow.
>
> Interestingly, the illusion is instantiated by the addition of BLACK.
>

That is uncanny! And it is truly an illusion, not some kind of computer/monitor
technical aberration.

At first, I thought the yellow 'color' might be an odd result of my computer
monitor (and everyone else's!), duo to the lines in the image interacting with
the position or orientation of a monitor's tiny red-green-blue LED's. Or that
your use of a perspective camera might be slightly throwing off the spatial
alignment of lines vs. discs, creating a false color somehow. But nope!

For the attached image, I used only your 'imaginary' disc, and changed your line
spacing to 0.06; then used an orthographic camera a bit closer in.

In the smaller thumbnail preview image that will appear here, the disc will
probably look mostly yellow. But seen at full size (600X600), the 'color'
illusion starts to fade out toward the lower right corner-- i.e., farther from
the blue lines!

Interestingly, changing the blue lines to red or green does not produce such a
false-color illusion-- at least to my eyes. But I wonder if others here see such
a change differently.

[Bald Eagle] Re: There is no yellow in the circle [23 days 16 hours and 5 minutes ago]

Sun, 29 Mar 2026 16:20:00 GMT

I really do remember selecting the file to attach the image to the first post.

:(

Trying again.

[GioSeregni] Re: POV-Ray Origins [23 days 16 hours and 15 minutes ago]

Sun, 29 Mar 2026 16:10:00 GMT

yesbird wrote:
> On 29/03/2026 13:49, GioSeregni wrote:
> > eh eh the output is never a problem
> > but I don't see the input for pov...
> > aand DXF very useful
>
> I have a DXF converter as a separate C program:
> https://github.com/syanenko/dxf2pov
> but found it unuseful in Studio, as it's outdated and rarely used now.
>
> As for POV input, I don't see the use case for it.
> Who wants to write a scene on SDL and then transfer it somewhere (where
> and why ?).
>
> > Instead the calls to the working and writing routines are entrusted to a second
> > executable written in QB64PE, which is great and compiles in C++.
>
> Is this a QBasic and is it still alive ?
> It was the first language I learned, so many years ago ...
>
>
> > It's the only way to publish, today any executable file, if it doesn't have the
> > blackmail price for certification, it gives false positives.
> >
>
> Wish you good luck with publishing, hope it will be demanded.
> --
> YB
I don't need that someone uses it
If anyone finds it useful, fine. Otherwise, it's the same for me.
The DXF format is the most robust for transferring from CAD, which I prefer to
modeling because it's more precise.

[Bald Eagle] There is no yellow in the circle [23 days 18 hours and 10 minutes ago]

Sun, 29 Mar 2026 14:15:00 GMT

(I'm sure many of you have seen this before)

We have rgb, rgbf, rgbt, rgbft,

..... and then we have colors that just aren't there at all.



There is:
a cyan disc
a magenta disc
and a blue vesica piscis
on a plane of blue lines

Imaginary colors:
there is no "dark blue", "green", "red",
and there is absolutely no yellow.

Interestingly, the illusion is instantiated by the addition of BLACK.

Something to think about the next time you ponder why your render "looks weird".

- BE

Try it!

// Color Illusion
// Bill "Bald Eagle" Walker
// 2026-03-29

#version version;
global_settings {assumed_gamma 1.0}
light_source {<10, 20, -50> rgb 1 shadowless}
sky_sphere {pigment {rgb 1}}
camera {
 location <0, 0, -2>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}


#declare ShowIllusion = yes;


#declare BlueLines =
pigment {
 gradient x
 pigment_map {
  [0.0 rgb z]
  [0.5 rgb z]
  [0.5 rgbt 1]
  [1.0 rgbt 1]
 }
}

#declare BlackLines =
pigment {
 gradient x
 pigment_map {
  [0.0 rgb 0]
  [0.5 rgb 0]
  [0.5 rgbt 1]
  [1.0 rgbt 1]
 }
}

#declare LineScale = 0.02;

plane {z, 0 pigment {BlueLines scale LineScale}}

#declare Imaginary =
intersection {
 plane {z, 0 pigment {BlackLines scale LineScale} translate -z*0.001}
 sphere {x*0.25, 0.5 pigment {rgbt 1} rotate z*330 translate z*0.01}
}

#if (ShowIllusion) object {Imaginary} #end

difference {
 disc {x*0.25, -z, 0.5 pigment {rgb y+z} rotate z*90 translate z*0.01}
  sphere {x*0.25, 0.5 pigment {rgbt 1} rotate z*210 translate z*0.01}
}

difference {
 disc {x*0.25, -z, 0.5 pigment {rgb x+z} rotate z*210 translate z*0.01}
  sphere {x*0.25, 0.5 pigment {rgbt 1} rotate z*90 translate z*0.01}
}

intersection {
 disc {x*0.25, -z, 0.5 pigment {rgb z} rotate z*90 translate z*0.01}
  sphere {x*0.25, 0.5 pigment {rgbt 1} rotate z*210 translate z*0.01}
  sphere {x*0.25, 0.5 pigment {rgbt 1} rotate z*90 translate z*0.01}
}

[Francois LE COAT] Re: POV-Ray Origins [23 days 18 hours and 34 minutes ago]

Sun, 29 Mar 2026 13:51:35 GMT

Hi,

David Buck writes:
> DKBTrace was originally developed on an Amiga computer in C.

I'm the author of the Atari 2D Graph Describer and 3D Modeller,
called Eureka 2.12, written in C language. It'll be 40 next year.

Eureka 2.12 is a software package originally developed for Atari ST
till Falcon computers. It is announced as a "2D Graph Describer and 3D
Modeller", meaning it allows users to create and manipulate 2D graphs
and 3D models. The software is notable for 2D curves analysis and 3D
modelling capabilities, enabling users to generate graphs from
mathematical functions (including fractal images like Julia and
Mandelbrot sets) and then map these graphs onto 3D surfaces. Users
can also create 3D animations and transfer images or animations from
other tools like the Persistence Of Vision Raytracer (POV-Ray).

Eureka 2.12 was authored by François Le Coat and is recognized as
a classic Atari application, often used in educational and creative
contexts. The software can be run on modern systems using Atari
Virtual Machine like ARAnyM (Atari Running on Any Machine).

I always was impressed with POV-Ray, Mathematica from their beginning!

Many thanks for your inspiration =)

Best regards,

-- 
François Le Coat
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
<https://eureka.atari.org/>

[Bald Eagle] Re: SVG Recognized colors [23 days 19 hours and 10 minutes ago]

Sun, 29 Mar 2026 13:15:00 GMT

This reminds me of some similar "named color" projects in the past.

Suggestion:

You output your converted colors as identifier declarations:
#declare Aliceblue = srgb <0.941, 0.973, 1.0>;

However, these are less meaningful and useful from the standpoint of SDL, since
you smoosh everything together.  This is the current problem that we have with
the parser, and every badly-written spreadsheet.

Put all of your colors into an array, and all of the names in another.

Now I can use a #for loop to cycle through the colors, do something with them,
and just use the text as a label.

Or you could use a multidimensional array, splitting up the red, green, and blue
components.  Using nested loops, the colors could be rendered in an rgb cube to
show where colors are clustered, and how similar/different they are.
Or an rgb hexagon.
Or a triangular ternary diagram.
Or a sphere, with rgb being mapped to Theta, Phi, Radius.

Perhaps make them all spheres and connect them in a blob {}

More advanced - a macro could be used to loop through all of the color names
until "Aliceblue" was found, and then return the rgb values as the result.
Otherwise "That color name was not found." and perhaps return the default color.

Also, I recall seeing some very cool python/povray projects that you might enjoy
if you search for them.

- BE

[yesbird] Re: POV-Ray Origins [23 days 19 hours and 18 minutes ago]

Sun, 29 Mar 2026 13:07:12 GMT

On 29/03/2026 13:49, GioSeregni wrote:
> eh eh the output is never a problem
> but I don't see the input for pov...
> aand DXF very useful

I have a DXF converter as a separate C program:
https://github.com/syanenko/dxf2pov
but found it unuseful in Studio, as it's outdated and rarely used now.

As for POV input, I don't see the use case for it.
Who wants to write a scene on SDL and then transfer it somewhere (where
and why ?).

> Instead the calls to the working and writing routines are entrusted to a second
> executable written in QB64PE, which is great and compiles in C++.

Is this a QBasic and is it still alive ?
It was the first language I learned, so many years ago ...

> It's the only way to publish, today any executable file, if it doesn't have the
> blackmail price for certification, it gives false positives.
>

Wish you good luck with publishing, hope it will be demanded.
--
YB

[GioSeregni] Re: POV-Ray Origins [23 days 21 hours and 35 minutes ago]

Sun, 29 Mar 2026 10:50:00 GMT

> In converter, mentioned above, I solved this problem with Three.js.
> The following formats are supported now:
> Input: obj, fbx, glb, gltf, stl.
> Output: glb, gltf, pov.
> --
> YB

eh eh the output is never a problem
but I don't see the input for pov...
aand DXF very useful

I'm converting my converter from 32 to 64 bit. I started it many years ago,
using RapidQ (32) , easy to write but now too much slow.

So I looked for other languages, but gave up. Too many inclusions, too many
libraries to load even just to write "hello world."
It's not possible to always check for updates and compatibility, with algorithms
you have no way of controlling or to waste your time searching the bugs..
I finally arrived at a procedure that satisfies me.

For now I have kept the interface and file management written in Rapidq.
Instead the calls to the working and writing routines are entrusted to a second
executable written in QB64PE, which is great and compiles in C++.
Complicated comparison operations that used to take hours, such as those with
normal vectors on huge files, now take minutes.
And the others a few seconds.
I think that in a few months, I haven't written the documentation yet, I will be
able to make the two sources public.
Plus an include "lang".
Only 3 files, which can be compiled simply with the standard RapidQ and QB64PE
compilers, WITHOUT any additional libraries or anything else.

It's the only way to publish, today any executable file, if it doesn't have the
blackmail price for certification, it gives false positives.

BR
G.

[jr] Re: SVG Recognized colors [24 days 12 hours and 30 minutes ago]

Sat, 28 Mar 2026 19:55:00 GMT

hi,


kurtz le pirate <kur### [at] freefr> wrote:
> On 28/03/2026 11:32, jr wrote:
> > really ??  ...
> Shame on me :(

(I started blaming my age :-))


regards, jr.

[kurtz le pirate] Re: SVG Recognized colors [24 days 15 hours and 33 minutes ago]

Sat, 28 Mar 2026 16:52:12 GMT

On 28/03/2026 11:32, jr wrote:

> 
> really ??  why not use the "authoritative" source, '/usr/share/X11/rgb.txt' ?
> and you get well over 500 colour names and variations (594 here).
> 
> 


Shame on me :(

Here, the new one from /usr/share/X11/rgb.txt



-- 
kurtz le pirate
compagnie de la banquise

[Kenneth] Re: Help: The normal map is not working [24 days 15 hours and 40 minutes ago]

Sat, 28 Mar 2026 16:45:00 GMT

I found the cause(s) of that small circle in the bump_map appearance. It is  a
combination of two different things:

1) a gray value *difference* between the left and right edges of the applied
image (see column E). The circle seems to be a natural consequence of this
difference. My guess is that the 'normals' mechanism under-the-hood needs(?) to
use the gray values from BOTH left and right to figure out what the normal
should be at that circle 'point'. Or possibly it's a precision issue.

2) using 'interpolate 2' in the bump_map, which makes the circle even worse. In
this case, the resulting normal  definitely appears to be using the
left-and-right edges of the image for the interpolation.

Column F shows the normals result when the applied image has the SAME gray
values on the left and right-- NO circle is produced, whether or not interpolate
2 is also used. But such an applied image is not a realistic test; it will
usually have natural grayscale differences on the left and right, like LanuHum's
original pattern of a tilted wave.

Column G shows that NO 'circle' is produced when a typical pigment{image_map...}
is applied instead of a  bump_map-- unless 'interpolate 2' is used, which then
'blends' the left and right edge colors of the image_map.

[laser] Re: Post something [24 days 16 hours and 30 minutes ago]

Sat, 28 Mar 2026 15:55:00 GMT

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

>
> Well, I started like everyone else using TRS-80's, and my first home computer
> was a Timex Sinclair 1000.  Then a VIC-20, Then an Atari 800XL.
> I didn't buy myself a "real" computer until after college.
>
> I miss the joystick port.  That was like my own interface to the outside world.
> I suppose I could just use a Raspberry Pi, but being able to have a simple
> makeshift I/O port was really fun.
>

My path was owning a VIC-20 first, then Commodore 64, then Amiga 2000 with XT
Bridgeboard, then a TI-99 4A I bought at a rummage sale for I think around 2
dollars, then various PCs and a Mac or two (Macs either given to me or at
rummage sale for a dollar or five).

My interface port of choice was the VIC-20 User port - parallel port that was
easy to program.

> > > What's up with shadertoy?
> >
> > ... It is very annoying, but the site
> > does work for me once I wait the rather long time (not "it's never going to
> > work" long though) to get to the checkbox,
>
> I only get a black page that says "Bad request"
>
> > If your browser is too old
> I'm using M$ Edge.
>
> - BE

Hmmm.,.  I don't know what would cause that.  Any chance you live in a country
that cloudflare.com wouldn't service (they are the company providing the human
verification test).  I don't know if there is any country that cloudflare
doesn't work in though.  The internet says the typical things: clear browser
cache, clear cookies (maybe too many cookies), check URL for errors, check to
make sure browser extensions aren't screwing it up, try a different browser,
etc.  But you said it happens on multiple browsers so I don't think it would be
any of that.

[yesbird] Re: POV-Ray Origins [24 days 16 hours and 51 minutes ago]

Sat, 28 Mar 2026 15:34:21 GMT

On 28/03/2026 17:41, GioSeregni wrote:
> Thanks, I'll take a look.
> Geometrically, I'm pretty good. The biggest challenge is unraveling PovRay's
> syntax, because it's very rich and doesn't have strict formatting rules. So,
> ...

Yes, I agree, SDL is tricky and sometimes not friendly - this is the
reason why so many people prefer to avoid it.

> the heart of my parser is the construction of its database, in which the various
> 3D formats can enter and exit, rearranging the elements according to the needs
> of each format

In converter, mentioned above, I solved this problem with Three.js.
The following formats are supported now:
Input: obj, fbx, glb, gltf, stl.
Output: glb, gltf, pov.
-- 
YB

[GioSeregni] Re: POV-Ray Origins [24 days 17 hours and 40 minutes ago]

Sat, 28 Mar 2026 14:45:00 GMT

yesbird wrote:
> On 27/03/2026 23:31, GioSeregni wrote:
> > Today, many nany years later, I create 3D models by 3D print, so PovRay, and my
> > editor-converter DXF/Pov-inc/STL is ever on my desk!
> >
>
> Maybe you will find this tool useful also:
> https://povlab.yesbird.online/studio/
> --
> YB

Thanks, I'll take a look.
Geometrically, I'm pretty good. The biggest challenge is unraveling PovRay's
syntax, because it's very rich and doesn't have strict formatting rules. So,
after each object, I have to accumulate the strings until I get parity between
the number of curly brackets... and then delve into the single string I've
constructed...
the heart of my parser is the construction of its database, in which the various
3D formats can enter and exit, rearranging the elements according to the needs
of each format

TYPE INTERNAL_DATA
 numfacets AS LONG ' 4 bytes
 Xmin AS DOUBLE
 Xmax AS DOUBLE
 Ymin AS DOUBLE
 Ymax AS DOUBLE
 Zmin AS DOUBLE
 Zmax AS DOUBLE    'HEADER

' start bloCnt________________________

 x0      As Double
 y0      As Double
 z0      As Double
 x1      As Double
 y1      As Double 'vertex = 72 bytes
 z1      As Double
 x2      As Double
 y2      As Double
 z2      As Double '__________________
 LayerCo As Double    ' 8 bytes
 EntitCo As Double    ' 8 bytes
 Transp  As Double    ' 8 bytes
' end bloCnt  ________________________
'                   repeat bloCnts
 TargetX AS DOUBLE
 TargetY AS DOUBLE
 TargetZ AS DOUBLE
 WPntX   AS DOUBLE 'view = 48 bytes
 WPntY   AS DOUBLE
 WPntZ   AS DOUBLE
 Orto    AS DOUBLE   '8 bytes
'-------------------------------------
END TYPE

[yesbird] Re: POV-Ray Origins [24 days 19 hours and 54 minutes ago]

Sat, 28 Mar 2026 12:30:51 GMT

On 27/03/2026 23:31, GioSeregni wrote:
> Today, many nany years later, I create 3D models by 3D print, so PovRay, and my
> editor-converter DXF/Pov-inc/STL is ever on my desk!
> 

Maybe you will find this tool useful also:
https://povlab.yesbird.online/studio/
-- 
YB

[yesbird] Re: POV-Ray Origins [24 days 20 hours and 1 minute ago]

Sat, 28 Mar 2026 12:24:12 GMT

On 27/03/2026 03:22, David Buck wrote:
> Hi everyone.Â  David (Kirk) Buck here.Â  I'm the original author
of 
> DKBTrace and POV-Ray.
>

Thank you so much for creating such a powerful and flexible tool.
When I was a student, I learned 3D basics with it. It still remains
unbeatable in many aspects, although modern technology goes far beyond.

Please look at the example of combination modern WebGL and high quality
rendering with POV-Ray: https://galleries.yesbird.online/jewelry/

With appreciation,
YB

[jr] Re: SVG Recognized colors [24 days 21 hours and 50 minutes ago]

Sat, 28 Mar 2026 10:35:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> On 25/03/2026 23:02, Cousin Ricky wrote:
> > ...
> > Thanks for this.  I toyed around with this idea a few years ago, but I got the
> > sense that the list of colors varied from distro to distro, so I put it on
> > indefinite hold.  Looking at your source, I wonder if the inconsistencies may
> > have been because I was looking at X11 rather than SVG.
>
> X11 ?
>
>  From <https://en.wikipedia.org/wiki/X11_color_names> ...

really ??  why not use the "authoritative" source, '/usr/share/X11/rgb.txt' ?
and you get well over 500 colour names and variations (594 here).


regards, jr.

[kurtz le pirate] Re: SVG Recognized colors [24 days 22 hours and 27 minutes ago]

Sat, 28 Mar 2026 09:58:31 GMT

On 25/03/2026 23:02, Cousin Ricky wrote:

> ...
> Thanks for this.  I toyed around with this idea a few years ago, but I got the
> sense that the list of colors varied from distro to distro, so I put it on
> indefinite hold.  Looking at your source, I wonder if the inconsistencies may
> have been because I was looking at X11 rather than SVG.
> 

X11 ?

 From <https://en.wikipedia.org/wiki/X11_color_names> and a few formulas 
in Excel :

#declare AliceBlue = color red 0.94 green 0.97 blue 1.00;
#declare AntiqueWhite = color red 0.98 green 0.92 blue 0.84;
#declare Aqua = color red 0.00 green 1.00 blue 1.00;
#declare Aquamarine = color red 0.50 green 1.00 blue 0.83;
#declare Azure = color red 0.94 green 1.00 blue 1.00;
#declare Beige = color red 0.96 green 0.96 blue 0.86;
#declare Bisque = color red 1.00 green 0.89 blue 0.77;
#declare Black = color red 0.00 green 0.00 blue 0.00;
#declare BlanchedAlmond = color red 1.00 green 0.92 blue 0.80;
#declare Blue = color red 0.00 green 0.00 blue 1.00;
#declare BlueViolet = color red 0.54 green 0.17 blue 0.89;
#declare Brown = color red 0.65 green 0.16 blue 0.16;
#declare Burlywood = color red 0.87 green 0.72 blue 0.53;
#declare CadetBlue = color red 0.37 green 0.62 blue 0.63;
#declare Chartreuse = color red 0.50 green 1.00 blue 0.00;
#declare Chocolate = color red 0.82 green 0.41 blue 0.12;
#declare Coral = color red 1.00 green 0.50 blue 0.31;
#declare CornflowerBlue = color red 0.39 green 0.58 blue 0.93;
#declare Cornsilk = color red 1.00 green 0.97 blue 0.86;
#declare Crimson = color red 0.86 green 0.08 blue 0.24;
#declare Cyan = color red 0.00 green 1.00 blue 1.00;
#declare DarkBlue = color red 0.00 green 0.00 blue 0.55;
#declare DarkCyan = color red 0.00 green 0.55 blue 0.55;
#declare DarkGoldenrod = color red 0.72 green 0.53 blue 0.04;
#declare DarkGray = color red 0.66 green 0.66 blue 0.66;
#declare DarkGreen = color red 0.00 green 0.39 blue 0.00;
#declare DarkKhaki = color red 0.74 green 0.72 blue 0.42;
#declare DarkMagenta = color red 0.55 green 0.00 blue 0.55;
#declare DarkOliveGreen = color red 0.33 green 0.42 blue 0.18;
#declare DarkOrange = color red 1.00 green 0.55 blue 0.00;
#declare DarkOrchid = color red 0.60 green 0.20 blue 0.80;
#declare DarkRed = color red 0.55 green 0.00 blue 0.00;
#declare DarkSalmon = color red 0.91 green 0.59 blue 0.48;
#declare DarkSeaGreen = color red 0.56 green 0.74 blue 0.56;
#declare DarkSlateBlue = color red 0.28 green 0.24 blue 0.55;
#declare DarkSlateGray = color red 0.18 green 0.31 blue 0.31;
#declare DarkTurquoise = color red 0.00 green 0.81 blue 0.82;
#declare DarkViolet = color red 0.58 green 0.00 blue 0.83;
#declare DeepPink = color red 1.00 green 0.08 blue 0.58;
#declare DeepSkyBlue = color red 0.00 green 0.75 blue 1.00;
#declare DimGray = color red 0.41 green 0.41 blue 0.41;
#declare DodgerBlue = color red 0.12 green 0.56 blue 1.00;
#declare Firebrick = color red 0.70 green 0.13 blue 0.13;
#declare FloralWhite = color red 1.00 green 0.98 blue 0.94;
#declare ForestGreen = color red 0.13 green 0.55 blue 0.13;
#declare Fuchsia = color red 1.00 green 0.00 blue 1.00;
#declare Gainsboro[a] = color red 0.86 green 0.86 blue 0.86;
#declare GhostWhite = color red 0.97 green 0.97 blue 1.00;
#declare Gold = color red 1.00 green 0.84 blue 0.00;
#declare Goldenrod = color red 0.85 green 0.65 blue 0.13;
#declare Gray = color red 0.75 green 0.75 blue 0.75;
#declare WebGray = color red 0.50 green 0.50 blue 0.50;
#declare Green = color red 0.00 green 1.00 blue 0.00;
#declare WebGreen = color red 0.00 green 0.50 blue 0.00;
#declare GreenYellow = color red 0.68 green 1.00 blue 0.18;
#declare Honeydew = color red 0.94 green 1.00 blue 0.94;
#declare HotPink = color red 1.00 green 0.41 blue 0.71;
#declare IndianRed = color red 0.80 green 0.36 blue 0.36;
#declare Indigo = color red 0.29 green 0.00 blue 0.51;
#declare Ivory = color red 1.00 green 1.00 blue 0.94;
#declare Khaki = color red 0.94 green 0.90 blue 0.55;
#declare Lavender = color red 0.90 green 0.90 blue 0.98;
#declare LavenderBlush = color red 1.00 green 0.94 blue 0.96;
#declare LawnGreen = color red 0.49 green 0.99 blue 0.00;
#declare LemonChiffon = color red 1.00 green 0.98 blue 0.80;
#declare LightBlue = color red 0.68 green 0.85 blue 0.90;
#declare LightCoral = color red 0.94 green 0.50 blue 0.50;
#declare LightCyan = color red 0.88 green 1.00 blue 1.00;
#declare LightGoldenrod = color red 0.98 green 0.98 blue 0.82;
#declare LightGray = color red 0.83 green 0.83 blue 0.83;
#declare LightGreen = color red 0.56 green 0.93 blue 0.56;
#declare LightPink = color red 1.00 green 0.71 blue 0.76;
#declare LightSalmon = color red 1.00 green 0.63 blue 0.48;
#declare LightSeaGreen = color red 0.13 green 0.70 blue 0.67;
#declare LightSkyBlue = color red 0.53 green 0.81 blue 0.98;
#declare LightSlateGray = color red 0.47 green 0.53 blue 0.60;
#declare LightSteelBlue = color red 0.69 green 0.77 blue 0.87;
#declare LightYellow = color red 1.00 green 1.00 blue 0.88;
#declare Lime = color red 0.00 green 1.00 blue 0.00;
#declare LimeGreen = color red 0.20 green 0.80 blue 0.20;
#declare Linen = color red 0.98 green 0.94 blue 0.90;
#declare Magenta = color red 1.00 green 0.00 blue 1.00;
#declare Maroon = color red 0.69 green 0.19 blue 0.38;
#declare WebMaroon = color red 0.50 green 0.00 blue 0.00;
#declare MediumAquamarine = color red 0.40 green 0.80 blue 0.67;
#declare MediumBlue = color red 0.00 green 0.00 blue 0.80;
#declare MediumOrchid = color red 0.73 green 0.33 blue 0.83;
#declare MediumPurple = color red 0.58 green 0.44 blue 0.86;
#declare MediumSeaGreen = color red 0.24 green 0.70 blue 0.44;
#declare MediumSlateBlue = color red 0.48 green 0.41 blue 0.93;
#declare MediumSpringGreen = color red 0.00 green 0.98 blue 0.60;
#declare MediumTurquoise = color red 0.28 green 0.82 blue 0.80;
#declare MediumVioletRed = color red 0.78 green 0.08 blue 0.52;
#declare MidnightBlue = color red 0.10 green 0.10 blue 0.44;
#declare MintCream = color red 0.96 green 1.00 blue 0.98;
#declare MistyRose = color red 1.00 green 0.89 blue 0.88;
#declare Moccasin = color red 1.00 green 0.89 blue 0.71;
#declare NavajoWhite = color red 1.00 green 0.87 blue 0.68;
#declare NavyBlue = color red 0.00 green 0.00 blue 0.50;
#declare OldLace = color red 0.99 green 0.96 blue 0.90;
#declare Olive = color red 0.50 green 0.50 blue 0.00;
#declare OliveDrab = color red 0.42 green 0.56 blue 0.14;
#declare Orange = color red 1.00 green 0.65 blue 0.00;
#declare OrangeRed = color red 1.00 green 0.27 blue 0.00;
#declare Orchid = color red 0.85 green 0.44 blue 0.84;
#declare PaleGoldenrod = color red 0.93 green 0.91 blue 0.67;
#declare PaleGreen = color red 0.60 green 0.98 blue 0.60;
#declare PaleTurquoise = color red 0.69 green 0.93 blue 0.93;
#declare PaleVioletRed = color red 0.86 green 0.44 blue 0.58;
#declare PapayaWhip = color red 1.00 green 0.94 blue 0.84;
#declare PeachPuff = color red 1.00 green 0.85 blue 0.73;
#declare Peru = color red 0.80 green 0.52 blue 0.25;
#declare Pink = color red 1.00 green 0.75 blue 0.80;
#declare Plum = color red 0.87 green 0.63 blue 0.87;
#declare PowderBlue = color red 0.69 green 0.88 blue 0.90;
#declare Purple = color red 0.63 green 0.13 blue 0.94;
#declare WebPurple = color red 0.50 green 0.00 blue 0.50;
#declare RebeccaPurple = color red 0.40 green 0.20 blue 0.60;
#declare Red = color red 1.00 green 0.00 blue 0.00;
#declare RosyBrown = color red 0.74 green 0.56 blue 0.56;
#declare RoyalBlue = color red 0.25 green 0.41 blue 0.88;
#declare Saddlebrown = color red 0.55 green 0.27 blue 0.07;
#declare Salmon = color red 0.98 green 0.50 blue 0.45;
#declare SandyBrown = color red 0.96 green 0.64 blue 0.38;
#declare SeaGreen = color red 0.18 green 0.55 blue 0.34;
#declare Seashell = color red 1.00 green 0.96 blue 0.93;
#declare Sienna = color red 0.63 green 0.32 blue 0.18;
#declare Silver = color red 0.75 green 0.75 blue 0.75;
#declare SkyBlue = color red 0.53 green 0.81 blue 0.92;
#declare SlateBlue = color red 0.42 green 0.35 blue 0.80;
#declare SlateGray = color red 0.44 green 0.50 blue 0.56;
#declare Snow = color red 1.00 green 0.98 blue 0.98;
#declare SpringGreen = color red 0.00 green 1.00 blue 0.50;
#declare SteelBlue = color red 0.27 green 0.51 blue 0.71;
#declare Tan = color red 0.82 green 0.71 blue 0.55;
#declare Teal = color red 0.00 green 0.50 blue 0.50;
#declare Thistle = color red 0.85 green 0.75 blue 0.85;
#declare Tomato = color red 1.00 green 0.39 blue 0.28;
#declare Turquoise = color red 0.25 green 0.88 blue 0.82;
#declare Violet = color red 0.93 green 0.51 blue 0.93;
#declare Wheat = color red 0.96 green 0.87 blue 0.70;
#declare White = color red 1.00 green 1.00 blue 1.00;
#declare WhiteSmoke = color red 0.96 green 0.96 blue 0.96;
#declare Yellow = color red 1.00 green 1.00 blue 0.00;
#declare YellowGreen = color red 0.60 green 0.80 blue 0.20;


ps : spaces in color names have been removed



-- 
kurtz le pirate
compagnie de la banquise

[Ilya Razmanov] Re: SVG Recognized colors [25 days 4 hours and 49 minutes ago]

Sat, 28 Mar 2026 03:36:20 GMT

On 26.03.2026 16:32, jr wrote:

> super.  one small oversight (sorry :-)), all '#debug' statements need an
> explicit '\n' to "show".

LOL, I was so concentrated on adding "\n" to the ends of my strings that 
completely missed adding "\\n" in the middle.

Anyway, here go finally corrected script, so anyone may change things to 
one's own taste.

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

[GioSeregni] Re: POV-Ray Origins [25 days 6 hours and 55 minutes ago]

Sat, 28 Mar 2026 01:30:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> On 2026-03-27 4:31 p.m., GioSeregni wrote:
> >
> > In 1987 I was a young architect 36 years old, so I found DKB very usefull to
> > check and to present my projects.
> > Today, many nany years later, I create 3D models by 3D print, so PovRay, and my
> > editor-converter DXF/Pov-inc/STL is ever on my desk!
> >
>
> That's a use for POV-Ray that I never anticipated.  I have a Bambu A1
> Combo but I haven't tried converting POV-Ray files to STL.
>
> David

About 3D print I limit myself to mesh, triangle, smooth_mesh, and colors.
Camera only for DXF, because it's not supported in STL.

The parser that I use for architecture, however, is enormous. Each object in the
dwg is very schematic, a simple, quick block, but then it calls its twin INCs,
which are very elaborate when I translate for PovRay.
And I also have a system of seasonal indicators, day and night time, lights,
underwater.. etc etc dwg variables or layers
more naturally colors and textures...

[David Buck] Re: POV-Ray Origins [25 days 10 hours and 41 minutes ago]

Fri, 27 Mar 2026 21:43:58 GMT

On 2026-03-27 4:31 p.m., GioSeregni wrote:
> 
> In 1987 I was a young architect 36 years old, so I found DKB very usefull to
> check and to present my projects.
> Today, many nany years later, I create 3D models by 3D print, so PovRay, and my
> editor-converter DXF/Pov-inc/STL is ever on my desk!
> 

That's a use for POV-Ray that I never anticipated.  I have a Bambu A1 
Combo but I haven't tried converting POV-Ray files to STL.

David

[GioSeregni] Re: POV-Ray Origins [25 days 11 hours and 50 minutes ago]

Fri, 27 Mar 2026 20:35:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> On 2026-03-27 8:55 a.m., GioSeregni wrote:
> >
> > I met David Buck on Facebook group, and I'm happy to see him here too.
> > I'm very grateful to him.
> > I've been on POV-ray almost every day since the DKB days.
> > I still have a booklet that was published in Italy around that time,
> > attached to a PC magazine, with the DKB disk.
> >
> > one of the first tests of my DXF to DKB parser
> >
>
>
> What I've always loved about the DKBTrace / POV-Ray community is that
> they took what they had and ran with it to create converters and
> generators that helped reduce the effort required to create models and
> scenes.  There are lots of tools that generate spirals, trees, leaves,
> blades of grass, and tons more.  As I said, I released it to allow
> others to have fun with it as well and I'm delighted to see how that
> turned out.
>
> David

In 1987 I was a young architect 36 years old, so I found DKB very usefull to
check and to present my projects.
Today, many nany years later, I create 3D models by 3D print, so PovRay, and my
editor-converter DXF/Pov-inc/STL is ever on my desk!

[ingo] Re: POV-Ray Origins [25 days 13 hours and 40 minutes ago]

Fri, 27 Mar 2026 18:45:00 GMT

David Buck <dav### [at] simberoncom> wrote:

> Somehow, I've always liked creating scenes by text.  I know graphical
> interfaces make it easy, but I can always be more precise with text.

In a gui the slider goes from [0-1], in POV-Ray we can use light intensity way
beyond or use negative light to calculate something.

I used AutoCAD in it's early days. You type the dimensions, not mouse them.

Playing with code to create (Gordon and Tensor product) surfaces, with a real
time viewer typing numbers for creating the base curves is easier and faster
than click click.

Playing with clay like mesh modeling is very hard without gui.

cheers,

ingo

[MichaelJF] Re: Post something [25 days 13 hours and 41 minutes ago]

Fri, 27 Mar 2026 18:44:38 GMT

Am 26.03.26 um 20:26 schrieb tTh:
> On 3/21/26 00:21, Bald Eagle wrote:
> 
>> Post something.Â  It doesn't matter what it is.
>> Really.Â Â  Just post it.Â  Here.
> 
>  Â Â  Ok ok. I've been working on this animation for two years,
>  Â Â  and i now publish this version, just a work in progress,
>  Â Â  but is a nice land for a lot of enhancements.
> 
>  Â Â  https://tube.interhacker.space/w/rNEQbXXZGZFnoabG7uB6FR
> 
Interesting and technically well-executed, but difficult to interpret 
without an explanation of whatâ€™s happening here. On your website, I 
found some French explanations which I first had to translate using 
DeepL.com, but which do help with understanding. Perhaps you should 
present your ideas a bit more clearly here. As I cannot find the source 
of your inspiration (a sci-fi illustration site from the last century 
featuring futuristic cities and cone-shaped buildings) without further 
clues, and I therefore cannot know how closely your scenario mirrors 
this â€“ possibly dystopian â€“ model, I can only say
that the scenery 
strikes me as conveying a somewhat too gloomy atmosphere. Does the sun 
not shine in this universe?


Translated with DeepL.com (free version)

[Bald Eagle] Re: POV-Ray Origins [25 days 13 hours and 45 minutes ago]

Fri, 27 Mar 2026 18:40:00 GMT

David Buck <dav### [at] simberoncom> wrote:

> I wrote out the general equation of a quadric
> surface that was rotated, scaled and translated.  I calculated the
> intersection of a ray with the generic quadric surface.  I then needed
> partial derivatives to calculate the surface normal at that point.

This sounds . . . familiar.
https://news.povray.org/povray.advanced-users/thread/%3Cweb.635dc3c46f7bb9f1f9dae3025979125%40news.povray.org%3E/

> One thing I really enjoyed was writing the procedural texture code.  I
> took a lot of inspiration from a technical article called "An image
> synthesizer" by Ken Perlin (Computer Graphics 19, 3 1985).  It really
> made the textures look amazing.

I caught the procedural patterns bug a while back.
It's amazing what you can do with a few lines of code.
It's also amazing how a lot of lines of code look like nothing but crap - until
you add that one last line that makes it all come together the way it sould.

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

> CSG made it possible to do modeling
> and procedural textures made them look good.

I started down the CSG path, but really need to learn a lot more about how all
of the nested operations work.  There was a lot more that you can do with the
simplest CSG than I was aware.

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68573b7934ec28cb1f9dae3025979125%40news.povray.org%3
E/

And yes, textures on geometry can make all the difference in the world!
Also lighting.  That can be a whole other quantum leap forward.

> I thought it would be interesting to add octree subdivision to the
> raytracer.

I do believe that we have Binary Space Partitioning (BSP) for most things.
https://www.povray.org/documentation/3.7.0/r3_2.html
3.2.8.6 BSP Bounding

> I always thought that it would dramatically speed up the rendering by
> eliminating the vast majority of the ray/object intersection calculations.

I have experimented with Quadtree, jr wrote a custom Nonatree to do a 3x3
variant of that, and I know some people have done the Octree partitioning.

And you are right - it would dramatically speed up a lot of things - especially
the parametric () object.

> Somehow, I've always liked creating scenes by text.  I know graphical
> interfaces make it easy, but I can always be more precise with text.

Yes.  For diagramming and drawing in 2D, jr will tell you how much I like VISIO.
 You can you use the GUI to drag and drop shapes, and rubber-band them all over
the screen, but you can also select shapes or control points and manually enter
coordinates or dimensions.  It also has "Smart Sheets" which are like embedded
spreadsheets to control what a shape does.  Also, CNC uses G-code, and most
CAD/CAM software of course allows you to snap to grids or dimension lines as
well as manually enter exact dimensions.

https://news.povray.org/moray.win/message/%3Cweb.637f784db7839011f9dae3025979125%40news.povray.org%3E

> I would like to see the POV-Ray rendering code extracted as a shared
> library with an API interface.  That way, I can write other software to
> do any modeling I want without having to output a scene file and run the
> renderer separately.  I think that would open the door to a lot of new
> innovation.

It would, and Chris Cason has discussed going in this direction as well.
We need developers.

> I often run across images and suspect they're done with POV-Ray.
> Sometimes I can prove that I'm right and other times I can just never be
> sure.  I like when the artists explicitly mention the tool they used.

I've helped with some people writing articles or theses, and it was strongly
suggested that they put POV-Ray in the footnotes/bibliography.  When looking for
new ideas, I often do searches for "POV-Ray" in math and science papers to see
who's doing what.  There are also some great people in academia like Paul Bourke
and Oliver Knill who obviously do a lot of amazing stuff with POV-Ray.

> Thanks, those were fun questions.
> David

Thanks for the answers - they were great to read!  :)
POV-Ray makes exploring ideas with visual feedback easy and fun.  All the
different primitives, mathematical surfaces, equations, colors, textures,
optical phenomena - it opens up so many possibilities to explore ideas and see
the implementation of something that might otherwise take fantastic amounts of
time, skill, and money to create in the real world.

- BE

[David Buck] Re: POV-Ray Origins [25 days 14 hours and 55 minutes ago]

Fri, 27 Mar 2026 17:30:19 GMT

On 2026-03-27 11:51 a.m., Bald Eagle wrote:
> David Buck <dav### [at] simberoncom> wrote:
>> Hi everyone.  David (Kirk) Buck here.  I'm the original author of
>> DKBTrace and POV-Ray.
> 
> Hello again, David.
> The above sounds like the introduction to an interview video.  :)
> 
>> I've always been interested in spreading the joy of programming and
>> using computers in a creative way.  DKBTrace was one of many projects
>> I've worked on simply for the joy of coding.
> 
> What did you learn while writing DKBTrace, and what sorts of math or programming
> methods did you realize were truly central to the heart of what made DKBTrace
> work?

When I wrote DKBTrace, I worked out the math myself.  In hindsight, I 
did it the hard way.  I wrote out the general equation of a quadric 
surface that was rotated, scaled and translated.  I calculated the 
intersection of a ray with the generic quadric surface.  I then needed 
partial derivatives to calculate the surface normal at that point.  In 
hindsight, the easier thing to do is to keep the shape normalized at 
<0,0> with a radius of 1 and transform the ray instead of the quadric 
surface.

One thing I really enjoyed was writing the procedural texture code.  I 
took a lot of inspiration from a technical article called "An image 
synthesizer" by Ken Perlin (Computer Graphics 19, 3 1985).  It really 
made the textures look amazing.

> 
> What do you think contributed most to the enduring success of POV-Ray?

I don't think DKBTrace / POV-Ray would have been the success it was 
without Aaron Collins porting it from the Amiga to the PC.  Once he 
contacted me about it, we worked together to make it more portable so it 
ran on Unix, Amiga and PC.  It was the assistance of other developers 
that really made POV-Ray what it is today.

> What are some of the features that were added that you like the most?

Procedural textures and CSG were the two features that made DKBTrace 
interesting.  Before that, I was restricted to basic shapes (i.e., 
spheres) on checkerboard floors.  CSG made it possible to do modeling 
and procedural textures made them look good.

> Were there things that you've always wanted to implement, but never did?

I thought it would be interesting to add octree subdivision to the 
raytracer.  The main raytrace loop goes:

    For each ray
       For each object in the scene
          If the ray intersects the object
             Collect the intersection point
       End
    End

    Find the closest intersection point and calculate the lighting

With an octree, you divide the space into large cubes and subdivide 
those cubes that contain something.  The algorithm, then, becomes

    For each ray
       Traverse empty cubes until you find a non-empty one
          Calculate intersections with the small number of objects in 
that cube.

I always thought that it would dramatically speed up the rendering by 
eliminating the vast majority of the ray/object intersection calculations.

> Do you have friends and colleagues in the programming world that use POV-Ray?

Not really.  Most of my "real" work is business programming.  The people 
I work with may be politely interested in my raytracing work but it 
doesn't "rub off" on them.

I did have an interesting experience when I was teaching a Smalltalk 
course once.

Student:  Is it possible to use Smalltalk for graphics programming?
Me:       It depends on what kind of graphics you want to do.
Student:  I want to do ray tracing.
Me:       Have you tried using available ray tracers?
Student:  Yes, I use POV-Ray
Me:       Oh, I wrote that.
<He looks at me, then at my name on the whiteboard>
Student:  Wait, are you THE David Buck who wrote DKBTrace?
Me:       That's me
Student:  Wow,  what a coincidence
Me:       Not for me

BTW, Smalltalk can do raytracing (I wrote one once), but it can't 
compete in raw speed to a C implementation.  Smalltalk floats (at least 
at the time) were boxed and required allocation and garbage collection, 
so they were slower.

> What do you think are the features or attributes of POV-Ray that make it the
> most useful for certain tasks?

Somehow, I've always liked creating scenes by text.  I know graphical 
interfaces make it easy, but I can always be more precise with text.

> What are some key features that you think POV-Ray would benefit from the most?

I would like to see the POV-Ray rendering code extracted as a shared 
library with an API interface.  That way, I can write other software to 
do any modeling I want without having to output a scene file and run the 
renderer separately.  I think that would open the door to a lot of new 
innovation.

> Do you ever run across images, and instantly recognize that they were rendered
> with POV-Ray?

I often run across images and suspect they're done with POV-Ray. 
Sometimes I can prove that I'm right and other times I can just never be 
sure.  I like when the artists explicitly mention the tool they used.

> 
 > - Bill "Bald Eagle" Walker>

Thanks, those were fun questions.
David

[Bald Eagle] Re: Post something [25 days 15 hours and 10 minutes ago]

Fri, 27 Mar 2026 17:15:00 GMT

"laser" <nomail@nomail> wrote:

> I guess then we're both about the same age - a VIC-20 is how I started,  A tape
> drive came later unfortunately - after a failed attempt to create a tape
> recorder interface that I saw at a science fair.  Maybe the interface worked but
> the VIC-20 didn't like my cassette recorder since I think a tape recorder
> interface I bought didn't work either.

Well, I started like everyone else using TRS-80's, and my first home computer
was a Timex Sinclair 1000.  Then a VIC-20, Then an Atari 800XL.
I didn't buy myself a "real" computer until after college.

I miss the joystick port.  That was like my own interface to the outside world.
I suppose I could just use a Raspberry Pi, but being able to have a simple
makeshift I/O port was really fun.

> > What's up with shadertoy?
>
> ... It is very annoying, but the site
> does work for me once I wait the rather long time (not "it's never going to
> work" long though) to get to the checkbox,

I only get a black page that says "Bad request"

> If your browser is too old
I'm using M$ Edge.

- BE

[Leroy] Re: POV-Ray Origins [25 days 15 hours and 30 minutes ago]

Fri, 27 Mar 2026 16:55:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> Hi everyone.  David (Kirk) Buck here.  I'm the original author of
> DKBTrace and POV-Ray.
>

So your that SOB that start this all:)

> It's now been about 40 years since I wrote DKBTrace.  It seems like
> forever ago, but I can still remember the thrill of generating (very
> slowly) 3D images of scenes I modeled with a text file using software I
> wrote myself.
>

Oh! I remember those days! Late night programing. Waking up early the next day
and going at it again. There is nothing like the feeling of coming with an idea
and exspanding it into working code.

>
> I check this forum periodically, but mostly I just lurk to be honest and
> check out what people are doing.  I was about 24 years old when I first
> wrote DKBTrace. I'll soon be turning 64 years old and I'm aiming at
> retiring soon.
>

Retiring! What's that? All the people I know said they worked harder after that
that, work you said.(retiring) I don't know how many times I've heard "I wish I
could go to work to get some rest!"

> I've always been interested in spreading the joy of programming and
> using computers in a creative way.  DKBTrace was one of many projects
> I've worked on simply for the joy of coding.  Interestingly, when I
> released DKBTrace, I thought I was done with it and was releasing it to
> allow others to have fun as well.  It seems that the fun has been
> continuing for the past 40 years.
>

Well, I have a hell of lot of fun with POV and I only have known it for 30 year
plus years. I enjoyed exploring POV. It has it own view of the world I like
playing in it.

> I'm going to commit to checking this newsgroup more frequently for a
> while and responding to posts.  If you have any questions or comments
> I'll try to respond as quickly as I can.
>
> David Buck

Nice to have you back! Looking forward to your insights.

Have Fun!

[David Buck] Re: POV-Ray Origins [25 days 15 hours and 32 minutes ago]

Fri, 27 Mar 2026 16:52:58 GMT

On 2026-03-27 8:55 a.m., GioSeregni wrote:
> 
> I met David Buck on Facebook group, and I'm happy to see him here too.
> I'm very grateful to him.
> I've been on POV-ray almost every day since the DKB days.
> I still have a booklet that was published in Italy around that time,
> attached to a PC magazine, with the DKB disk.
> 
> one of the first tests of my DXF to DKB parser
> 

What I've always loved about the DKBTrace / POV-Ray community is that 
they took what they had and ran with it to create converters and 
generators that helped reduce the effort required to create models and 
scenes.  There are lots of tools that generate spirals, trees, leaves, 
blades of grass, and tons more.  As I said, I released it to allow 
others to have fun with it as well and I'm delighted to see how that 
turned out.

David

[Bald Eagle] Re: POV-Ray Origins [25 days 16 hours and 30 minutes ago]

Fri, 27 Mar 2026 15:55:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> Hi everyone.  David (Kirk) Buck here.  I'm the original author of
> DKBTrace and POV-Ray.

Hello again, David.
The above sounds like the introduction to an interview video.  :)

> I've always been interested in spreading the joy of programming and
> using computers in a creative way.  DKBTrace was one of many projects
> I've worked on simply for the joy of coding.

What did you learn while writing DKBTrace, and what sorts of math or programming
methods did you realize were truly central to the heart of what made DKBTrace
work?

What do you think contributed most to the enduring success of POV-Ray?
What are some of the features that were added that you like the most?
Were there things that you've always wanted to implement, but never did?
Do you have friends and colleagues in the programming world that use POV-Ray?
What do you think are the features or attributes of POV-Ray that make it the
most useful for certain tasks?
What are some key features that you think POV-Ray would benefit from the most?

Do you ever run across images, and instantly recognize that they were rendered
with POV-Ray?

- Bill "Bald Eagle" Walker

[GioSeregni] Re: POV-Ray Origins [25 days 19 hours and 25 minutes ago]

Fri, 27 Mar 2026 13:00:00 GMT

I met David Buck on Facebook group, and I'm happy to see him here too.
I'm very grateful to him.
I've been on POV-ray almost every day since the DKB days.
I still have a booklet that was published in Italy around that time,
attached to a PC magazine, with the DKB disk.

one of the first tests of my DXF to DKB parser

[David Buck] Re: POV-Ray Origins [25 days 19 hours and 48 minutes ago]

Fri, 27 Mar 2026 12:37:39 GMT

On 2026-03-27 8:24 a.m., ingo wrote:
> David Buck <dav### [at] simberoncom> wrote:
>>
>> How many people even know what Smalltalk is these days?  Not many.
>>
> 
> I remember something with a Dolphin? And was one of the first versions of
> SuperCollider not written in SmallTalk. Their current DSL still resembles it.
> Honestly, I always get lost in it, as in most OOP, it feels so fragmented, or my
> old brain is :)
> 
> ingo
> 

Yes, Dolphin was a version of Smalltalk - actually a pretty nice one. 
It's too bad they couldn't make a commercial success of it.

David

[ingo] Re: POV-Ray Origins [25 days 20 hours ago]

Fri, 27 Mar 2026 12:25:00 GMT

David Buck <dav### [at] simberoncom> wrote:
>
> How many people even know what Smalltalk is these days?  Not many.
>

I remember something with a Dolphin? And was one of the first versions of
SuperCollider not written in SmallTalk. Their current DSL still resembles it.
Honestly, I always get lost in it, as in most OOP, it feels so fragmented, or my
old brain is :)

ingo

[David Buck] Re: POV-Ray Origins [25 days 21 hours and 56 minutes ago]

Fri, 27 Mar 2026 10:29:00 GMT

Thanks.  It was literally my pleasure.

DKBTrace was originally developed on an Amiga computer in C.  I did code 
in some ideas from Smalltalk that I learned a few years earlier (I 
learned Smalltalk in 1984).  By 1996, I was working full-time in 
Smalltalk and have been primarily using Smalltalk for my entire 
programming career.

How many people even know what Smalltalk is these days?  Not many.

David Buck

On 2026-03-27 1:33 a.m., B. Gimeno wrote:
> Hi David,
> A quick note of gratitude: I started with POV-Ray in '96 and still pop into this
> forum occasionally. It means a lot that the original author is still around.
> Thanks for the joy of coding â€” and happy early retirement!
> Cheers,
> 
> B. Gimeno
> 
> 
>

[David Buck] Re: POV-Ray Origins [25 days 22 hours and 3 minutes ago]

Fri, 27 Mar 2026 10:22:16 GMT

Thank you.  I never thought 40 years ago that the little raytracer I 
wrote would grow into the masterpiece that is modern-day POV-Ray.  It's 
been fun watching it grow over the years.

David Buck

On 2026-03-26 11:02 p.m., Ton wrote:
> Hi David,
> 
> the fun has absolutely been continuing for the last 40 years.
> Thank you very much.
> 
> Cheers
> Ton
> 
> 
>

[B Gimeno] Re: POV-Ray Origins [26 days 2 hours and 50 minutes ago]

Fri, 27 Mar 2026 05:35:00 GMT

Hi David,
A quick note of gratitude: I started with POV-Ray in '96 and still pop into this
forum occasionally. It means a lot that the original author is still around.
Thanks for the joy of coding — and happy early retirement!
Cheers,

B. Gimeno

[Ton] Re: POV-Ray Origins [26 days 5 hours and 20 minutes ago]

Fri, 27 Mar 2026 03:05:00 GMT

Hi David,

the fun has absolutely been continuing for the last 40 years.
Thank you very much.

Cheers
Ton

[Cousin Ricky] Re: question about same code(?) and different re... [26 days 7 hours and 34 minutes ago]

Fri, 27 Mar 2026 00:51:00 GMT

On 2026-03-26 10:59 (-4), Bald Eagle wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>> No no! :-)
> 
> I'm sure this is how the War Between The States got started . . .

I'm pretty sure that the war started when some humans insisted that
their greed and sense of racial superiority superseded the freedom and
labor rights of other humans, and a third set of humans disagreed.

>> Or did that piece of info get generated by...uh...A.I.? :-O
> 
> Maybe it was one of those stupid "AI summary" things that they insist on making
> look like an actual search result.
> I mean, with as much of this color-correction crap as we've been through, I
> should have just looked at it and said _That can't be right_, but the coffee
> really just doesn't fully grab hold until maybe 9am or so.

Tell me about it.  I don't know how many weeks or months I was reading
AI summaries of my emails before I discovered that Yahoo was feeding me
AI, and that I had not actually read any of my actual emails during that
time.

NOBODY ASKED FOR THIS!  (Other than over-leveraged venture capitalists,
that is.)

One wake up call was when I checked a flight itinerary, and the "email"
said that I had a layover in St. Thomas.  (I live in St. Thomas.)

[David Buck] POV-Ray Origins [26 days 8 hours and 3 minutes ago]

Fri, 27 Mar 2026 00:22:07 GMT

Hi everyone.  David (Kirk) Buck here.  I'm the original author of 
DKBTrace and POV-Ray.

It's now been about 40 years since I wrote DKBTrace.  It seems like 
forever ago, but I can still remember the thrill of generating (very 
slowly) 3D images of scenes I modeled with a text file using software I 
wrote myself.

I check this forum periodically, but mostly I just lurk to be honest and 
check out what people are doing.  I was about 24 years old when I first 
wrote DKBTrace. I'll soon be turning 64 years old and I'm aiming at 
retiring soon.

I've always been interested in spreading the joy of programming and 
using computers in a creative way.  DKBTrace was one of many projects 
I've worked on simply for the joy of coding.  Interestingly, when I 
released DKBTrace, I thought I was done with it and was releasing it to 
allow others to have fun as well.  It seems that the fun has been 
continuing for the past 40 years.

I'm going to commit to checking this newsgroup more frequently for a 
while and responding to posts.  If you have any questions or comments 
I'll try to respond as quickly as I can.

David Buck

[tTh] Re: Post something [26 days 12 hours and 58 minutes ago]

Thu, 26 Mar 2026 19:26:50 GMT

On 3/21/26 00:21, Bald Eagle wrote:

> Post something.  It doesn't matter what it is.
> Really.   Just post it.  Here.

    Ok ok. I've been working on this animation for two years,
    and i now publish this version, just a work in progress,
    but is a nice land for a lot of enhancements.

    https://tube.interhacker.space/w/rNEQbXXZGZFnoabG7uB6FR

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[Bald Eagle] Re: Help: The normal map is not working [26 days 13 hours and 45 minutes ago]

Thu, 26 Mar 2026 18:40:00 GMT

This also reminded me that hand-rolled a uv_mapping mechanism in SDL.

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5d5757a84c72a7284eec112d0%40news.povray.org%3E/

So you could try that and see what happens.

- BE

[Bald Eagle] Re: Help: The normal map is not working [26 days 14 hours and 15 minutes ago]

Thu, 26 Mar 2026 18:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> You're right, it *is* kind of odd. I took a look at Lanahum's code again, and
> there is nothing there to cause that little circle.

I think I see why - the image_map is getting wrapped around that point as a
pole.
That's why you get that purple/white circle - it's the right edge of your image
map.

> A purple circle shows up on the sphere where the bump_map's 'circle'
> was-- along with a white dot in the center, which is probably a 1-pixel 'repeat'
> from the left side of the image_map(?). So the anomaly does not seem to be
> bump_map specific.
>
> Perhaps it's a result (or a glitch?) of using map_type 0 when applying an
> image_map of any kind to a *sphere*.

Could be.
No way to know without comparing it to spherical map_type.
In the meantime, put a (different) colored stripe along the left side of that
image_map and see if the color of the central dot changes.

If it's a persistent "repeat", then that's a problem.
I should already have a fix for that, if such is the case, but that will require
another dive into the depths of the source code.

y'all know how I love that.

- BE

[Kenneth] Re: Help: The normal map is not working [26 days 15 hours ago]

Thu, 26 Mar 2026 17:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I did comment-out his various matrices to simplify the code, since they were
> having no effect as far as I could tell.

My mistake: His sphere does use a matrix-- but is has no effect on that small
'circle' except to move it (and the pattern itself) around the sphere. I tested
it. (His code had another matrix that I did comment out, which was just a
default one producing no change.)

[Kenneth] Re: Help: The normal map is not working [26 days 15 hours and 15 minutes ago]

Thu, 26 Mar 2026 17:10:00 GMT

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

> >
> > The mis-match seam comes from my attempt to give my own image_map the same
> > 'tilt' of the pattern as Lanahum's...although I didn't get it quite right.
> > Then the pattern repeats on the sphere, causing the visible 'seam'.
>
> Ok, well - it doesn't seem to be there in column B.

Column B is just a copy of Lanahum's initial post, along with my gamma 2.2
'correction' for the bump_map. His own posted pattern is 'tilted' just enough to
show no seam when it repeats.
>
> Just curious if you can use spherical bump-mapping or spherical warp

I never got around to that. "So little time, so much other neat stuff to work
on." ;-)
>
> > That small circle on [the] sphere renders...
>
> That doesn't really make any sense to me.
> I'd experiment with other bump maps - maybe a grid, and see what happens, and
> where on the bump map that artefact appears.
>

You're right, it *is* kind of odd. I took a look at Lanahum's code again, and
there is nothing there to cause that little circle.

Herewith, a grid example. Same Lanahum code, but I substituted an image_map
PIGMENT using the same map_type 0; no bump_map. My grid image_map has a
2-pixel-wide vertical purple stripe on the right edge from top to bottom, as a
tester. A purple circle shows up on the sphere where the bump_map's 'circle'
was-- along with a white dot in the center, which is probably a 1-pixel 'repeat'
from the left side of the image_map(?). So the anomaly does not seem to be
bump_map specific.

Perhaps it's a result (or a glitch?) of using map_type 0 when applying an
image_map of any kind to a *sphere*.

[Bald Eagle] Re: question about same code(?) and different re... [26 days 17 hours and 25 minutes ago]

Thu, 26 Mar 2026 15:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> No no! :-)

I'm sure this is how the War Between The States got started . . .

> Even though GioSeregni solved his own problem, I'm likewise curious as to where
> your search engine pulled up that gamma info about the 'color' keyword. It was
> news to me too. (To satisfy my curiosity, I just tested 'color rgb' vs. rgb-- no
> difference.)
>
> Maybe that was the case in an **old** POV-ray version?
>
> Or did that piece of info get generated by...uh...A.I.? :-O

Man, that was last Friday at 8:15 in the morning.
I likely had 300+ pages of stuff to sort, a truck driver at my window, the phone
ringing, someone behind me talking, the walkie screeching, and I was just trying
to eke out a quick answer before diving into all that.
Maybe it was one of those stupid "AI summary" things that they insist on making
look like an actual search result.
I mean, with as much of this color-correction crap as we've been through, I
should have just looked at it and said _That can't be right_, but the coffee
really just doesn't fully grab hold until maybe 9am or so.

I never use "color", so my snoozing brain must have somehow been bedazzled by
that wild claim.
Caveat Lector.

- BE

[Cousin Ricky] Re: SVG Recognized colors [26 days 17 hours and 35 minutes ago]

Thu, 26 Mar 2026 14:49:57 GMT

On 2026-03-25 18:02 (-4), Cousin Ricky wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> [snip]
>>
>> Resulting .inc file attached in case someone need these named colors.
>>
>> Python file attached as well in case someone wish to change something in
>> output format, like rounding (currently set to 3 decimals) etc.
> 
> I'm pretty sure that, as the W3C has adopted sRGB as its standard, your colors
> should be #declared with `srgb` rather than `rgb`.  Your list is consistent with
> mine, and when I render these colors, it seems clear that they are gamma-2.2 or
> sRGB encoded.  Note that the `srgb` keyword will yield consistent colors
> regardless of your assumed_gamma setting.

Verified: https://www.w3.org/TR/SVG11/types.html#DataTypeColor

You should use the `srgb` keyword, not the `rgb` keyword.

[Kenneth] Re: question about same code(?) and different re... [26 days 17 hours and 55 minutes ago]

Thu, 26 Mar 2026 14:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > Whoa, this is news to me!  Where is this in the documentation?
>
> It didn't seem right - especially due to the vector promotion thing, but I just
> plowed right through that and didn't listen to "the little voice".
>
> What a gaffe.  Someone delete this.  :O
>
> - BE

No no! :-)

Even though GioSeregni solved his own problem, I'm likewise curious as to where
your search engine pulled up that gamma info about the 'color' keyword. It was
news to me too. (To satisfy my curiosity, I just tested 'color rgb' vs. rgb-- no
difference.)

Maybe that was the case in an **old** POV-ray version?

Or did that piece of info get generated by...uh...A.I.? :-O

[Bald Eagle] Re: Help: The normal map is not working [26 days 18 hours and 35 minutes ago]

Thu, 26 Mar 2026 13:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > In some of your renders you get a mis-match / seam in your normal/texture.
> > Also, there is that small half-black/half-white circular "blemish" at the
> > forefront of some of the spheres.
> >
>
> The mis-match seam comes from my attempt to give my own image_map the same
> 'tilt' of the pattern as Lanahum's...although I didn't get it quite right. Then
> the pattern repeats on the sphere, causing the visible 'seam'.

Ok, well - it doesn't seem to be there in column B,
and
looking back at the OP, he's got another weird seam that's perpendicular to that
and seems to line up with where the black/white circle divides.

I would not ignore either of these things, as this is usually where we
discover/learn something important.

Just curious if you can use spherical bump-mapping or spherical warp

> That small circle on my sphere renders is also visible in Lanahum's original
> post, although not as pronounced. I don't quite know what the cause is, as I
> have not really examined his code in detail, and just used it as-is. (Although,
> I did comment-out his various matrices to simplify the code, since they were
> having no effect as far as I could tell.) The circle might be because the
> bump_map's image_map does not exactly fit the sphere(?) or is not exactly
> aligned to it. (We are both using map_type 0 for applying the bump_map, which is
> just planar mapping, not 'spherical')

That doesn't really make any sense to me.
I'd experiment with other bump maps - maybe a grid, and see what happens, and
where on the bump map that artefact appears.

- BE

[jr] Re: SVG Recognized colors [26 days 18 hours and 50 minutes ago]

Thu, 26 Mar 2026 13:35:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 26.03.2026 14:38, jr wrote:
> > well, I don't "speak" Python, so cannot do so either.
> Well, initially my pythonic part consisted of three things:
> ...
> But now I tried to address all the issues mentioned in both replies, so
> my pythonic code like quadrupled in size ;-)
>
> Here go the updated version (and exported .inc example ...

super.  one small oversight (sorry :-)), all '#debug' statements need an
explicit '\n' to "show".


regards, jr.

[Kenneth] Re: Help: The normal map is not working [26 days 18 hours and 55 minutes ago]

Thu, 26 Mar 2026 13:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> In some of your renders you get a mis-match / seam in your normal/texture.
> Also, there is that small half-black/half-white circular "blemish" at the
> forefront of some of the spheres.
>

The mis-match seam comes from my attempt to give my own image_map the same
'tilt' of the pattern as Lanahum's...although I didn't get it quite right. Then
the pattern repeats on the sphere, causing the visible 'seam'.

That small circle on my sphere renders is also visible in Lanahum's original
post, although not as pronounced. I don't quite know what the cause is, as I
have not really examined his code in detail, and just used it as-is. (Although,
I did comment-out his various matrices to simplify the code, since they were
having no effect as far as I could tell.) The circle might be because the
bump_map's image_map does not exactly fit the sphere(?) or is not exactly
aligned to it. (We are both using map_type 0 for applying the bump_map, which is
just planar mapping, not 'spherical')

[Bald Eagle] Re: SVG Recognized colors [26 days 19 hours and 35 minutes ago]

Thu, 26 Mar 2026 12:50:00 GMT

That's the second time TODAY that I've seen the word "idempotent".
Spooky.  But an excellent goal to set for all code.

Also applicable to the keyword project I was discussing, with regard to
self-documenting.

As Richard stated:
"Note that the `srgb` keyword will yield consistent colors
regardless of your assumed_gamma setting."

So, if we are using assumed_gamma 1.0 for all scenes, then why are we even using
rgb?   If everything is implemented from here forward using srgb, then
everything should be good, right?   N^1 = N.

Now, I often have to do experimentation where I modify colors from rgb to rgbf
to rgbt to maybe rgbft, and that gets to be a pain to go back and rewrite all
the keywords and color vectors.

Having worked out a fairly robust system for handling vector arity, I'm
considering just making some kind of all-purpose color macro, that detects the
size of the color vector and emits the appropriate keyword.

- BE

[Ilya Razmanov] Re: SVG Recognized colors [26 days 19 hours and 44 minutes ago]

Thu, 26 Mar 2026 12:40:55 GMT

On 26.03.2026 14:38, jr wrote:

> well, I don't "speak" Python, so cannot do so either.

Well, initially my pythonic part consisted of three things:

1) One "with open..." for file handling.
2) One "for" loop for dictionary iterating.
3) One file .write with f-string, combining dictionary keys and values 
with POV-Ray syntax elements.

All the rest of the file consisted of 147 dictionary entries, whose keys 
and values were directly copied from W3C site.

Main reasons for doing all this with Python were:

1) I'm too lazy to think of search and replace sequence for transforming 
W3C source into POV-Ray, "let the iron mechanism work";
2) Now it's extremely easy to change things en masse by, say, editing 
that single f-string.

But now I tried to address all the issues mentioned in both replies, so 
my pythonic code like quadrupled in size ;-)

Here go the updated version (and exported .inc example for those who 
loathe to touch Python). Note that file name to be inserted here and 
there in all these "include_temp" is defined within program, so it's 
easy to edit it with notepad - all the "doing" code goes after 
dictionary definition, which, considering code and dictionary relative 
sizes, means "at the very end of Python file".

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

[jr] Re: SVG Recognized colors [26 days 20 hours and 45 minutes ago]

Thu, 26 Mar 2026 11:40:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 26.03.2026 11:15, jr wrote:
> >
> > after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
> > should be "idempotent", too.  have attached a copy of a generated
> > 'svg_colors.inc' post-processed (and renamed to fit :-)).
> >
>
> Unfortunately, I understand neither what "idempotent" mean nor what all
> these

idempotent -- in this context, if I were to have a '#include "colours_svg.inc'"
line in every one of my scene and include files, only the first one seen by the
parser gets processed in full, all subsequent ones will not (as the guard
('colours_svg_include_temp') is already defined).
<en.wiktionary.org/wiki/idempotent>

> #ifdef(View_POV_Include_Stack)
> #debug "including colours_svg.inc\n"
> #end

if you'll have a look at the distribution '.inc' files, you will notice those
same lines.  if you declare the 'View_POV_Include_Stack' variable in a scene
_before_ the scene file's "#include" lines, POV-Ray will print the name of each
as it gets parsed.

> are good for ;-). Therefore I'm afraid I can't make my script any
> better, except for changing "rgb" to "srgb" (that's the only part I
> understand).

well, I don't "speak" Python, so cannot do so either.

> Well, on the other hand, there seem to be one more thing I understand:
> many colors in standard "colors.inc" seem to be named just like that
> would be in exported inc, and I'm too lazy to check them all for
> conflicts in case of importing both files. Perharps it would be better
> to change naming convention from color_name.title() (i.e., "blue" to
> "Blue") to, say, color_name.capitalize() (i.e., "blue" to "BLUE")? Or
> may be use prefixes, like "blue" to "svg_blue" or something?

fwiw, personal opinion, the colour names are fine as is.

regards, jr.

[Ilya Razmanov] Re: SVG Recognized colors [26 days 21 hours and 22 minutes ago]

Thu, 26 Mar 2026 11:02:52 GMT

On 26.03.2026 11:15, jr wrote:
> 
> after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
> should be "idempotent", too.  have attached a copy of a generated
> 'svg_colors.inc' post-processed (and renamed to fit :-)).
> 

Unfortunately, I understand neither what "idempotent" mean nor what all 
these

#ifdef(View_POV_Include_Stack)
#debug "including colours_svg.inc\n"
#end

are good for ;-). Therefore I'm afraid I can't make my script any 
better, except for changing "rgb" to "srgb" (that's the only part I 
understand).

Well, on the other hand, there seem to be one more thing I understand: 
many colors in standard "colors.inc" seem to be named just like that 
would be in exported inc, and I'm too lazy to check them all for 
conflicts in case of importing both files. Perharps it would be better 
to change naming convention from color_name.title() (i.e., "blue" to 
"Blue") to, say, color_name.capitalize() (i.e., "blue" to "BLUE")? Or 
may be use prefixes, like "blue" to "svg_blue" or something?

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

[jr] Re: SVG Recognized colors [27 days and 5 minutes ago]

Thu, 26 Mar 2026 08:20:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Ok, since some avians request amphibians to post something, here
> something goes.
> ...
> Anyway, now I do post something, and it's your turn.

after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
should be "idempotent", too.  have attached a copy of a generated
'svg_colors.inc' post-processed (and renamed to fit :-)).

thank you for posting your script.

regards, jr.

[Cousin Ricky] Re: SVG Recognized colors [27 days 10 hours and 20 minutes ago]

Wed, 25 Mar 2026 22:05:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> [snip]
>
> but surely they are referring to SVG named colors!
>
> At this point my patience got exhausted, depleted etc., so I copy/pasted
> text from:
>
> https://www.w3.org/TR/SVG11/types.html#ColorKeywords
>
> with a little search/replace turned into a form of Python dictionary,
> which turned into a file which, being run, exports all these colors in
> the form of POV-Ray .inc file.

Thanks for this.  I toyed around with this idea a few years ago, but I got the
sense that the list of colors varied from distro to distro, so I put it on
indefinite hold.  Looking at your source, I wonder if the inconsistencies may
have been because I was looking at X11 rather than SVG.

> Resulting .inc file attached in case someone need these named colors.
>
> Python file attached as well in case someone wish to change something in
> output format, like rounding (currently set to 3 decimals) etc.

I'm pretty sure that, as the W3C has adopted sRGB as its standard, your colors
should be #declared with `srgb` rather than `rgb`.  Your list is consistent with
mine, and when I render these colors, it seems clear that they are gamma-2.2 or
sRGB encoded.  Note that the `srgb` keyword will yield consistent colors
regardless of your assumed_gamma setting.

[Bald Eagle] Re: Help: The normal map is not working [27 days 13 hours ago]

Wed, 25 Mar 2026 19:25:00 GMT

Nice work producing all those variants.

I'm curious:

In some of your renders you get a mis-match / seam in your normal/texture.
Also, there is that small half-black/half-white circular "blemish" at the
forefront of some of the spheres.

- BE

[Ilya Razmanov] SVG Recognized colors [27 days 15 hours and 52 minutes ago]

Wed, 25 Mar 2026 16:33:39 GMT

Ok, since some avians request amphibians to post something, here
something goes.

For a long time I'm bored by the fact that, when I need some named
colors in 0..1 range (like required by POV-Ray), I find them in 0.255
range at best (at worst they are hexed).

Today I felt like I need having some color gradient to height color my
img2mesh output to make it look like printed map coloring, and the first
thing I found was:

https://www.cartotype.com/developers/documentation/style-sheets/terrain-shading-and-coloring

but surely they are referring to SVG named colors!

At this point my patience got exhausted, depleted etc., so I copy/pasted
text from:

https://www.w3.org/TR/SVG11/types.html#ColorKeywords

with a little search/replace turned into a form of Python dictionary,
which turned into a file which, being run, exports all these colors in
the form of POV-Ray .inc file.

Resulting .inc file attached in case someone need these named colors.

Python file attached as well in case someone wish to change something in
output format, like rounding (currently set to 3 decimals) etc.

Note that Python program writes its output in default working directory,
which normally is the directory the program is placed to.

Note that color names are processed with .title() to make them start
with Cap to avoid conflicts with POV-Ray keywords like "blue"; maybe
someone prefer other naming scheme (like adding "_" or something), feel
free to edit the program.

Anyway, now I do post something, and it's your turn.

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

[laser] Re: Post something [27 days 16 hours and 10 minutes ago]

Wed, 25 Mar 2026 16:15:00 GMT

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

> > I probably have seen the raytracer you mention, but I can't quite remember what
> > it was like right now.
>
>
https://wiki.povray.org/content/Documentation:Tutorial_Section_3.8#SDL_tutorial:_A_raytracer
>

That looks rather interesting - thanks for the link.  I got a kick out of the
"colored mesh" part.

> > I mostly go right to "Image Digest" and don't always
> > read the posts
>
> I'm sure if you've just been skimming, then you must be a very busy guy.

Yeah, my todo list is getting longer.  But there's often too much information to
go through.  I've been using the internet since 1987 (pre-http) so I've seen
both lack of information and too much information.  Too much is better,  This
page is a nice throwback to my USENET days though.

> > If you want to see some of the stuff I've done,
> Thanks - I look forward to reading/watching all that.
> (Loved the Pink Floyd article!)

Glad to hear it.  I always hope Roger Waters would read it and let me know what
he thinks.

> > An x86 assembly raytracer I wrote
>
> Jeez.  I haven't written assembly since I bought a pamphlet that taught me to
> write assembly for my Commodore Vic-20 and save the code on a tape drive.  :O

I guess then we're both about the same age - a VIC-20 is how I started,  A tape
drive came later unfortunately - after a failed attempt to create a tape
recorder interface that I saw at a science fair.  Maybe the interface worked but
the VIC-20 didn't like my cassette recorder since I think a tape recorder
interface I bought didn't work either.

> What's up with shadertoy?  I can't get the site to open on any machine or
> browser that I've tried.  For a long while now.
> It's one of my primary references for helping me get my brain solidly into
> functional-programming mode. :(

A few months or more ago they added the human verification/check because they
were getting hit by too much traffic or something.  They felt it was caused by
AI scrapers,  I don't know if they would have done it if someone on twitter
hadn't recommended adding the human check,  It is very annoying, but the site
does work for me once I wait the rather long time (not "it's never going to
work" long though) to get to the checkbox,  If your browser is too old (I'm not
saying yours is, just pointing out a possible issue), you will get an infinite
loop of trying to verify with no checkbox ever showing up.

> Hopefully you make regular visits - it's always nice to see other people's work
> - for inspiration, learning, and just simple enjoyment.
>
> Nice to finally meet you.
> - BE

Nice to meet/talk to you as well.  Yeah, inspiration and learning are very
important.
- Mark

[Bald Eagle] Re: Post something [27 days 18 hours and 30 minutes ago]

Wed, 25 Mar 2026 13:55:00 GMT

"laser" <nomail@nomail> wrote:

> I'm a programmer.

I am . . . shocked.  ;)

> I probably have seen the raytracer you mention, but I can't quite remember what
> it was like right now.

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.8#SDL_tutorial:_A_raytracer

> I mostly go right to "Image Digest" and don't always
> read the posts

I'm sure if you've just been skimming, then you must be a very busy guy.

> (but I have seen your name often :-) )

Well, yeah.  I've been playing with this for a long time now, and have
progressed from kindergarten level stick figure renders to refactoring and
debugging the source code.

>
> If you want to see some of the stuff I've done,
Thanks - I look forward to reading/watching all that.
(Loved the Pink Floyd article!)

> An x86 assembly raytracer I wrote

Jeez.  I haven't written assembly since I bought a pamphlet that taught me to
write assembly for my Commodore Vic-20 and save the code on a tape drive.  :O

> And a GLSL version can be viewed on my shadertoy
> page: <www.shadertoy.com/user/mrmcsoftware>

What's up with shadertoy?  I can't get the site to open on any machine or
browser that I've tried.  For a long while now.
It's one of my primary references for helping me get my brain solidly into
functional-programming mode. :(

> Sorry about all the self-promoting, but they all are along the same lines we're
> talking about - unorthodox ways of doing raytracing.

Hopefully you make regular visits - it's always nice to see other people's work
- for inspiration, learning, and just simple enjoyment.

Nice to finally meet you.
- BE

[laser] Re: Post something [28 days 9 hours and 50 minutes ago]

Tue, 24 Mar 2026 22:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "laser" <nomail@nomail> wrote:
>
> > I'm modifying a compiler I wrote that was for an assignment in my compilers
> > college course many years ago.  I've expanded the grammar to be a fully usable
> > language rather than a "toy" language.  So, of course, I just had to create a
> > raytracer for it.
>
> Excellent.
> Curious what you do professionally?
>
> Have you seen the raytracer that you can write in SDL?
> I've done about 3 different versions of that so far.
>
> - BE

I'm a programmer.  A compiler is outside of my normal range of coding, though I
have written various configuration (and similar) scripting languages (but that's
interpreted not compiled).

I probably have seen the raytracer you mention, but I can't quite remember what
it was like right now.  I mostly go right to "Image Digest" and don't always
read the posts (but I have seen your name often :-) )

If you want to see some of the stuff I've done, you can see some examples on my
youtube channel (mostly tutorials lately, and my earlier videos contain many
raytracings) (my channel only has 42 videos, so it wouldn't take long to look
through): <www.youtube.com/MrMcSoftware/videos>

An x86 assembly raytracer I wrote (not the one I first posted about) is covered
in my assembly language videos and a little bit in my "My Projects: Pathtracing,
Raytracer (x86 Assembly, Amiga, Linux & Windows), Tesla Coil Use & More" video -
it was based on my assembly raytracer I wrote for a CPU I designed and first
appeared in my video "My Logisim CPU / Computer - Now With Floating Point (FPU)
(Fractals, Raytracer, Etc.)".  And a GLSL version can be viewed on my shadertoy
page: <www.shadertoy.com/user/mrmcsoftware>
Sorry about all the self-promoting, but they all are along the same lines we're
talking about - unorthodox ways of doing raytracing.

[laser] Re: Post something [28 days 16 hours and 20 minutes ago]

Tue, 24 Mar 2026 16:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "laser" <nomail@nomail> wrote:
>
> > I'm modifying a compiler I wrote that was for an assignment in my compilers
> > college course many years ago.  I've expanded the grammar to be a fully usable
> > language rather than a "toy" language.  So, of course, I just had to create a
> > raytracer for it.
>
> Excellent.
> Curious what you do professionally?
>
> Have you seen the raytracer that you can write in SDL?
> I've done about 3 different versions of that so far.
>
> - BE

Thanks.  I'm a programmer, but compiler writing is definitely outside of the
range of my normal coding,  Though configuration script (and similar) writing
(and therefore designing the script language) isn't (but that's interpreted not
compiled).

I probably have seen the raytracer you mention, but I can't quite remember what
it was like right now.  I mostly go right to the "Image Digest" and don't always
read the posts (but I do see your name a lot :-) )

If you're interested in seeing some of my work, etc. you can see examples on my
youtube channel (lot's of tutorials now, and also my earlier videos are
raytracings.  I only have 42 videos so it's not hard to look through the whole
channel):  http://www.youtube.com/MrMcSoftware/videos

An x86 assembly raytracer (different than the one I posted an image of) I coded
is covered in my assembly language videos and a little bit in my "My Projects:
Pathtracing, Raytracer (x86 Assembly, Amiga, Linux & Windows), Tesla Coil Use &
More" video,  This raytracer was based on my assembly raytracer for a CPU I
designed - it first appeared in my "My Logisim CPU / Computer - Now With
Floating Point (FPU) (Fractals, Raytracer, Etc.)" video.  And a GLSL version of
this raytracer is at my shadertoy page:
https://www.shadertoy.com/user/mrmcsoftware (I think that link will provide a
link to it).  Sorry to do so much promoting, but it's all along the same lines
of coding a raytracer in an unorthodox way.

[jr] Re: Animation feature request. [28 days 23 hours and 15 minutes ago]

Tue, 24 Mar 2026 09:10:00 GMT

hi,

"m@b" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > > > another option, ...
>
> Yes - that would work but, as others have sated, the whole thing is getting more
> complicated than it merits.
>
> For now I am happy just to pass the numbers from resolution.ini thus:
>
>     Subset_End_Frame=3755
>     Declare=SEF=3755
>
> Typing the number twice must be quicker than editing a second file each time.

:-)  glad/good you found a way.


regards, jr.

[m@b] Re: Animation feature request. [29 days 6 hours and 35 minutes ago]

Tue, 24 Mar 2026 01:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "m@b" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...
> > > another option, not yet mentioned, is having a (shell) script run from the
> > > 'pre_frame_command' which writes the values to a simple CSV type file that you
> > > can read from within the scene.
> >
> > Hmm, yes, I could shell out to a Python script that parses the resolution.ini
> > file.
>
> too complex, really, for the need.  apologies.  it can (should) all be done "in
> scene", the following quick test works, assuming ten frames and you only want 4
> through 6:
>
> - create a simple "CSV" file with (subset) end and start frame numbers:
>
>   $ echo '6,4' > framenos.csv
>
>
> - my ini file ("mb.ini"):
>
>   initial_frame = 1
>   final_frame = 10
>   cyclic_animation = off
>   subset_start_frame = 4
>   subset_end_frame = 6
>
>   input_file_name = mb.pov
>   output_file_name = mb_
>
>
> - and your scene, ie only the code inside the conditional:
>
>   #version 3.7;
>
>   global_settings {assumed_gamma 1}
>
>   #declare datafn_ = "framenos.csv";
>
>   #fopen tmp_fp_ datafn_ read
>   #read (tmp_fp_,last_,first_)
>   #fclose tmp_fp_
>
>   #if (first_ < last_ & first_ <= frame_number)
>
>     /* scene stuff */
>     box {0,1}
>
>
>     #declare first_ = first_ + 1;  /* 'incr()' ?! ;-) */
>     #fopen tmp_fp_ datafn_ write
>     #write (tmp_fp_,last_,",",first_)
>     #fclose tmp_fp_
>
>   #end
>
>
> hth, let me know if I got "the wrong end of the stick" :-).
>
>
> regards, jr.

Yes - that would work but, as others have sated, the whole thing is getting more
complicated than it merits.

For now I am happy just to pass the numbers from resolution.ini thus:

    Subset_End_Frame=3755
    Declare=SEF=3755

Typing the number twice must be quicker than editing a second file each time.

m@b

[jr] Re: Post something [29 days 11 hours and 55 minutes ago]

Mon, 23 Mar 2026 20:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> a POV-Ray documentation tool I'm playing with.  it requires version 3.7.0.8
> documentation (the HTML files) installed, ...

link to an archive with a copy of my 'povray-3.7.0.8' docs, in case :-)

<drive.google.com/file/d/1ZN8ZHOi5x6GWfSATUtcgrMtsO2ochFRw/view?usp=sharing>


regards, jr.

[Kenneth] Re: Help: The normal map is not working [29 days 13 hours and 55 minutes ago]

Mon, 23 Mar 2026 18:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > I ran your code--using the same 'normal' image that I copied here-- and it
> > seems that a gamma of 1.1 that you used is not a good value for a bump_map.
> > I changed that value to 2.2 (and boosted the bump_size to 10) and it
> > looks much better.
>
>
> If you share your thoughts about how the image gets converted to gamma 2.2 or
> srgb-modified rgb values...

[Sorry for the long delay in responding here; I had to deal with repairs on my
car, one after the other.]

I have been trying to reproduce Lanahum's flat-looking result with my *own*
image(s) for the bump_map, made in POV-ray at typical assumed_gamma 1.0-- and
see 'normals' results  that sometimes do not agree with my previous comments
about the  bump_map's gamma setting requiring a 2.2 value. (I'm running the
tests in v3.7, same as he did.) The surface normals in at least one of my tests
look OK even with the bump_map's gamma at 1.0 (or just leaving out 'gamma'
altogether). That seems strange, based on my earlier remarks. But I finally
'chased the rabbit down its hole' and discovered the reason for the disparity.

Simply put: The final appearance of the 'normal' effect is very sensitive to the
gamma used to encode its image_map (and sensitive to the chosen pattern itself,
apparently.)

NOTE: In the attached image, all of the bump_maps use bump_size 10 for the
normal.

[A] While the default 'gamma' setting in a bump_map does indeed seem to be 1.0,
my new tests indicate that POV-ray automatically compensates for an image having
an intrinsic or 'encoded' gamma of 2.2-- like typical  jpeg's or png's-- and
*without* having to specify a gamma-value change in the bump_map. (I used an
inverted sine_wave pattern for this one; I took the original sine_wave .jpeg
render into my paint.net app and inverted it there.) It's 'normals' look as
expected!

[B] This is just Lanahum's posted pattern again and his original bump_map
result, then with my gamma 2.2 'correction' as before. (To use his pattern, I
simply snipped it out of his .jpeg image post-- using paint.net--and re-saved it
as a .jpeg again.) The final 'normals' result looks like a 'scallop wave'-- but
that's misleading...

[C] To create a pattern that looks like his, I had to use a triangle_wave
pattern instead-- with the image_map **rendered  at assumed_gamma 2.2** in
POV-ray, rather than at my usual 1.0.  It looks nearly identical to Lanahum's
pattern. Using that image in the bump_map-- with a gamma 1.0 setting there--
produces the flat gray-stripes look again, same as Lanahum's.  A setting of 2.2
gives the surface normals some 'depth'...although the result looks like a
'scallop wave' instead of a triangle. That's to be expected: The gamma is
changing the 'slope' of the black-to-white gradations.

[There is another way to produce the same effect, which I didn't post here:
making a triangle-wave image_map *as* a gamma 1.0 image. I made one in POV-ray
using assumed_gamma 1.0 and changing both Display_Gamma and File_Gamma to 1.0,
rather than their usual 2.2 (or 'srgb'). Then it likewise required a gamma 2.2
value in the bump_map. BTW, this image_map had to be in the .png format--
apparently a .jpeg cannot(?) be rendered at gamma 1.]

I think that Lanahum's original image_map was made using one those two schemes--
which is why it required a 2.2 gamma change.

[D] I used POV-ray's triangle_wave pattern again for the image_map, but rendered
at typical assumed_gamma 1.0. With the bump_map's gamma set to 1.0, there
appears to be *some* 'depth' to the normal-- but changing the gamma to 2.2 makes
flat stripes instead(!), which is a mystery. To get any further depth from it
requires a bump_map gamma of between 4 and 5 (4.4??)-- but then it looks like a
'scallop wave' again.

--------------------
[off topic]
Lanahum's code uses a 'brilliance' setting in his finish{...}. That seems to
work (or look) better in v3.7 than in v3.8 beta 1, to my eyes. There must have
been a 'change' of some kind for the current betas.

[Bald Eagle] Re: Post something [29 days 14 hours and 40 minutes ago]

Mon, 23 Mar 2026 17:45:00 GMT

"laser" <nomail@nomail> wrote:

> I'm modifying a compiler I wrote that was for an assignment in my compilers
> college course many years ago.  I've expanded the grammar to be a fully usable
> language rather than a "toy" language.  So, of course, I just had to create a
> raytracer for it.

Excellent.
Curious what you do professionally?

Have you seen the raytracer that you can write in SDL?
I've done about 3 different versions of that so far.

- BE

[laser] Re: Post something [29 days 17 hours and 10 minutes ago]

Mon, 23 Mar 2026 15:15:00 GMT

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

> Post something.  It doesn't matter what it is.
> Really.   Just post it.  Here.
>

I'm modifying a compiler I wrote that was for an assignment in my compilers
college course many years ago.  I've expanded the grammar to be a fully usable
language rather than a "toy" language.  So, of course, I just had to create a
raytracer for it.  Here's the source code written in my language:

{
/* Integer loop + shading vars */
i_x = 0; i_y = 0;
i_shade = 0;
i_check = 0;
i_mod2 = 0;

/* Camera origin */
f_sx = 0.0; f_sy = 0.1; f_sz = 5.5;

/* Light direction (will normalize) */
#f_lx = -2.0; f_ly = 3.0; f_lz = -1.0;
f_lx = -2.0; f_ly = 3.0; f_lz = 2.0;

/* Ray direction */
f_dx = 0.0; f_dy = 0.0; f_dz = 0.0;

/* 2nd Sphere position */
f_sp_x = 1.75; f_sp_y = 0.0; f_sp_z = -2.0;

/* Sphere radiuses */
f_sp1_r = 1.2; f_sp2_r = 0.6;

/* Sphere intersection */
f_b = 0.0; f_c = 0.0; f_disc = 0.0; f_t = 0.0;

/* plane height */
f_ply = -1.6;

/* Normals and points */
f_nx = 0.0; f_ny = 0.0; f_nz = 0.0;
f_px = 0.0; f_py = 0.0; f_pz = 0.0;

/* Helpers */
f_len = 0.0; f_dot = 0.0; f_spec = 0.0; f_tmp = 0.0;
f_fx = 0.0; f_fz = 0.0;

/* Shadow ray vars */
f_sdx = 0.0; f_sdy = 0.0; f_sdz = 0.0;
f_tb = 0.0; f_tc = 0.0; f_tdisc = 0.0; f_tshadow = 0.0;

/* Normalize light direction once */
f_len = sqrt(f_lx*f_lx + f_ly*f_ly + f_lz*f_lz);
f_lx = f_lx / f_len; f_ly = f_ly / f_len; f_lz = f_lz / f_len;

f_aspect = 1.0;

print "P6\n640 480\n255\n";
/* Image loop */
for i_y = -240 to 239 do
 {
 for i_x = -320 to 319 do
  {
  /* Ray direction from camera through pixel */
  f_dx = float(i_x) / 490.0;
  f_dy = -float(i_y) * f_aspect / 490.0;
  f_dz = -1.0;

  /* Normalize ray direction */
  f_len = sqrt(f_dx*f_dx + f_dy*f_dy + f_dz*f_dz);
  f_dx = f_dx / f_len;
  f_dy = f_dy / f_len;
  f_dz = f_dz / f_len;

  /* Sphere intersection: center at (0,0,0), radius 1.2 */
  f_tx = f_sx;
  f_ty = f_sy;
  f_tz = f_sz;
  f_b = 2.0 * (f_dx*f_tx + f_dy*f_ty + f_dz*f_tz);
  f_c = f_tx*f_tx + f_ty*f_ty + f_tz*f_tz - f_sp1_r;

  f_disc = f_b*f_b - 4.0*f_c;

  if f_disc >= 0.0 then
   {
   /* Hit sphere: nearest t */
   f_t = (-f_b - sqrt(f_disc)) / 2.0;
   if f_t <= 0.0 then
    {
    /* Behind camera: treat as no sphere hit, fall through */
    f_disc = -1.0;
    }
   else
    {
    f_obj_red = 0.9;
    f_obj_green = 0.9;
    f_obj_blue = 0.0;
    }
   }

  /* Sphere intersection: center at (f_sp_x,f_sp_y,f_sp_z), radius .6 */
  f_tx2 = f_sx - f_sp_x;
  f_ty2 = f_sy - f_sp_y;
  f_tz2 = f_sz - f_sp_z;
  f_b = 2.0 * (f_dx*f_tx2 + f_dy*f_ty2 + f_dz*f_tz2);
  f_c = f_tx2*f_tx2 + f_ty2*f_ty2 + f_tz2*f_tz2 - f_sp2_r;

  f_disc2 = f_b*f_b - 4.0*f_c;

  if f_disc2 >= 0.0 then
   {
   /* Hit sphere: nearest t */
   f_t2 = (-f_b - sqrt(f_disc2)) / 2.0;
   if f_t2 > 0.0 then
    {
    b_sp1=(f_disc<0.0); #(f_t<0.0); /* boolean */
    b_sp2=(f_t2<f_t); /* boolean */
    if b_sp1+b_sp2 then /* boolean + = or */
     {
     f_obj_red = 0.0;
     f_obj_green = 0.9;
     f_obj_blue = 0.0;
     f_disc = f_disc2;
     f_t = f_t2;
     f_tx = f_tx2;
     f_ty = f_ty2;
     f_tz = f_tz2;
     }
    }
   }

  if f_disc < 0.0 then
   {
   /* No sphere hit: try ground plane y = -1.6 */

   if f_dy == 0.0 then
    {
    /* Ray parallel to plane: background */
    printc 0;
    printc 90;
    printc 130;
    }
   else
    {
    f_t = (f_ply - f_sy) / f_dy;
    if f_t <= 0.0 then
     {
     /* Plane behind camera */
     printc 0;
     printc 90;
     printc 130;
     }
    else
     {
     /* Hit point on plane */
     f_px = f_sx + f_dx*f_t;
     f_py = f_ply;
     f_pz = f_sz + f_dz*f_t;

     /* Checkerboard: floor(px), floor(pz) using int */
     f_fx = float(int(f_px));
     if f_px < 0.0 then f_fx = f_fx - 1.0;

     f_fz = float(int(f_pz));
     if f_pz < 0.0 then f_fz = f_fz - 1.0;

     i_check = (int(f_fx + f_fz)) % 2;
     if (i_check == 0) then { f_red=0.75; f_green=0.0; f_blue=0.0; }
     else { f_red=0.75; f_green=0.75; f_blue=0.75; }

     /* Shadow from sphere onto plane:
     cast ray from plane point toward light,
     check if it hits sphere before light. */

     f_sdx = f_lx;
     f_sdy = f_ly;
     f_sdz = f_lz;

     /* Sphere intersection from plane point:
     ray: P + t*L, sphere at origin, radius 1 */

     f_tb = 2.0 * (f_sdx*f_px + f_sdy*f_py + f_sdz*f_pz);
     f_tc = f_px*f_px + f_py*f_py + f_pz*f_pz - f_sp1_r;
     f_tdisc = f_tb*f_tb - 4.0*f_tc;

     if f_tdisc > 0.0 then
      {
      f_tshadow = (-f_tb - sqrt(f_tdisc)) / 2.0;
      if f_tshadow > 0.0 then
       {
       /* In shadow: darken */
       f_red = f_red * 0.5;
       f_green = f_green * 0.5;
       f_blue = f_blue * 0.5;
       }
      }

     f_tx = f_px - f_sp_x;
     f_ty = f_py - f_sp_y;
     f_tz = f_pz - f_sp_z;

     f_tb = 2.0 * (f_sdx*f_tx + f_sdy*f_ty + f_sdz*f_tz);
     f_tc = f_tx*f_tx + f_ty*f_ty + f_tz*f_tz - f_sp2_r;
     f_tdisc = f_tb*f_tb - 4.0*f_tc;

     if f_tdisc > 0.0 then
      {
      f_tshadow = (-f_tb - sqrt(f_tdisc)) / 2.0;
      if f_tshadow > 0.0 then
       {
       /* In shadow: darken */
       f_red = f_red * 0.5;
       f_green = f_green * 0.5;
       f_blue = f_blue * 0.5;
       }
      }

     i_red=int(f_red * 255.0);
     i_green=int(f_green * 255.0);
     i_blue=int(f_blue * 255.0);

     if i_red < 0 then i_red = 0;
     if i_red > 255 then i_red = 255;
     if i_green < 0 then i_green = 0;
     if i_green > 255 then i_green = 255;
     if i_blue < 0 then i_blue = 0;
     if i_blue > 255 then i_blue = 255;

     printc i_red;
     printc i_green;
     printc i_blue;
     }
    }
   }
  else
   {
   /* Sphere shading */

   /* Hit point */
   f_px = f_tx + f_dx*f_t;
   f_py = f_ty + f_dy*f_t;
   f_pz = f_tz + f_dz*f_t;

   /* Normal at sphere */
   f_nx = f_px;
   f_ny = f_py;
   f_nz = f_pz;

   f_len = sqrt(f_nx*f_nx + f_ny*f_ny + f_nz*f_nz);
   f_nx = f_nx / f_len;
   f_ny = f_ny / f_len;
   f_nz = f_nz / f_len;

   /* Diffuse term */
   f_dot = f_nx*f_lx + f_ny*f_ly + f_nz*f_lz;
   if f_dot < 0.0 then f_dot = 0.0;

   /* Specular: reflection of light around normal, dotted with view dir (-ray)
*/
   f_tmp = 2.0 * f_dot;
   f_fx = f_tmp*f_nx - f_lx;
   f_fz = f_tmp*f_nz - f_lz;
   f_len = f_tmp*f_ny - f_ly;  /* reuse f_len as ry */

   /* view dir is -ray: (-dx, -dy, -dz) */
   f_spec = f_fx*(-f_dx) + f_len*(-f_dy) + f_fz*(-f_dz);
   if f_spec < 0.0 then f_spec = 0.0;
   f_spec = f_spec * f_spec;

   /* Combine diffuse + specular + small ambient */
   f_dot = 0.12 + .6*f_dot + 0.3*f_spec;

   if f_dot < 0.0 then f_dot = 0.0;
   if f_dot > 1.0 then f_dot = 1.0;

   i_red = int(f_obj_red * f_dot * 255.0);
   i_green = int(f_obj_green * f_dot * 255.0);
   i_blue = int(f_obj_blue * f_dot * 255.0);

   if i_red < 0 then i_red = 0;
   if i_red > 255 then i_red = 255;
   if i_green < 0 then i_green = 0;
   if i_green > 255 then i_green = 255;
   if i_blue < 0 then i_blue = 0;
   if i_blue > 255 then i_blue = 255;

   printc i_red;
   printc i_green;
   printc i_blue;
   }
  }
 }
}

There are no specific variable type declarations.  The type is based on the
first letter of the variable (i for integer, f for floating point, s for string,
and b for boolean).
# are line comments and /* */ are comment blocks.  The resulting compiled
x86/x64 program (either Windows or Linux) outputs a PPM (netpbm) image file.
The code is not that great because I haven't fully implemented functions (so no
recursion), and there's no pointers, no structs, and no arrays.  Here's the
resulting image:

[jr] Re: Animation feature request. [29 days 18 hours and 40 minutes ago]

Mon, 23 Mar 2026 13:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > too complex, really, for the need.
>
> Probably, but good learning exercise for more complex scenes.
> We really don't have any demonstrations / tutorials for this.
> Working example code beats everything.

if you, anyone reading, have a tutorial "in them", the wiki would be a good
place for it.  (would be happy to collaborate)

> >   #if (first_ < last_ & first_ <= frame_number)
> won't this always be true?

true, the "bit" after the '&' is .. without use.  (maybe I need to have stronger
coffee in the mornings :-))

> If I understand this correctly, ...

you and me both.. :-)  it'd all be "easier" with the actual scene code, let's
wait for m@b's reply.

regards, jr.

[Bald Eagle] Re: Animation feature request. [29 days 21 hours and 30 minutes ago]

Mon, 23 Mar 2026 10:55:00 GMT

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

> too complex, really, for the need.

Probably, but good learning exercise for more complex scenes.
We really don't have any demonstrations / tutorials for this.
Working example code beats everything.

>   #if (first_ < last_ & first_ <= frame_number)

won't this always be true?

If I understand this correctly, the only data point both necessary and
sufficient is that last frame.  Because once the first sub-frame starts
rendering, you get frame_number, which you can write to file and test the
existence of.

Then you can calculate how many frames altogether and how much left to go

Passing both values in through the ini would be best, but of course it's one
more number to forget to change.

- BE

[jr] Re: Animation feature request. [29 days 21 hours and 40 minutes ago]

Mon, 23 Mar 2026 10:45:00 GMT

hi,

"ingo" <nomail@nomail> wrote:
> > too complex
> yeah ;)

one of my (many) "Achilles heel"s.  </shrug+grin>

> ...
> ingo (or write the complete next frame scene and include it...)

now there's a challenge, "any takers" ?  ;-)

@m@b -- the code is "buggy" I noticed, after posting.. </sigh>  in the 'if' both
comparisons must be '<=', as is the third/last frame will not execute the
"scene" code.  v sorry (it _was_ early :-)).

regards, jr.

[ingo] Re: Animation feature request. [29 days 23 hours and 30 minutes ago]

Mon, 23 Mar 2026 08:55:00 GMT

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

> too complex

yeah ;) Write the data that have to survive between the frames to an array.
Write the array to an include file. Or even just write `#declare This = 3` etc.
instead of an array. Then include it in the next frame.

ingo (or write the complete next frame scene and include it...)

[jr] Re: Animation feature request. [30 days and 55 minutes ago]

Mon, 23 Mar 2026 07:30:00 GMT

"m@b" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > another option, not yet mentioned, is having a (shell) script run from the
> > 'pre_frame_command' which writes the values to a simple CSV type file that you
> > can read from within the scene.
>
> Hmm, yes, I could shell out to a Python script that parses the resolution.ini
> file.

too complex, really, for the need.  apologies.  it can (should) all be done "in
scene", the following quick test works, assuming ten frames and you only want 4
through 6:

- create a simple "CSV" file with (subset) end and start frame numbers:

  $ echo '6,4' > framenos.csv


- my ini file ("mb.ini"):

  initial_frame = 1
  final_frame = 10
  cyclic_animation = off
  subset_start_frame = 4
  subset_end_frame = 6

  input_file_name = mb.pov
  output_file_name = mb_


- and your scene, ie only the code inside the conditional:

  #version 3.7;

  global_settings {assumed_gamma 1}

  #declare datafn_ = "framenos.csv";

  #fopen tmp_fp_ datafn_ read
  #read (tmp_fp_,last_,first_)
  #fclose tmp_fp_

  #if (first_ < last_ & first_ <= frame_number)

    /* scene stuff */
    box {0,1}


    #declare first_ = first_ + 1;  /* 'incr()' ?! ;-) */
    #fopen tmp_fp_ datafn_ write
    #write (tmp_fp_,last_,",",first_)
    #fclose tmp_fp_

  #end


hth, let me know if I got "the wrong end of the stick" :-).


regards, jr.

[m@b] Re: Animation feature request. [30 days 6 hours and 35 minutes ago]

Mon, 23 Mar 2026 01:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "m@b" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > ...
> > > So, in your ini file you do something like Subset_Start_Frame=30
> > > but I'm wondering if you can then do something like
> > > Declare=SSF=Subset_Start_Frame.
> > > If not, you could just set Declare=SSF=30 and then do Subset_Start_Frame=SSF
> > > (if that works)
> >
> > Thanks for the reply, I didn't realise I could pass identifier values from an
> > ini file, that's useful.
> >
> > Unfortunately "The value on the right-hand side must be a constant float value."
> >
> > So this works:
> >
> >    Subset_Start_Frame=394
> >    Declare=SSF=394
> >
> > But these don't:
> >
> >    Subset_Start_Frame=394
> >    Declare=SSF=Subset_Start_Frame
> >
> >    Subset_Start_Frame=394
> >    Declare=SSF=float(Subset_Start_Frame)
> >
> >    Declare=SSF=394
> >    Subset_Start_Frame=SSF
> >
> > Declaring twice is no big hardship as long as I remember!
>
> another option, not yet mentioned, is having a (shell) script run from the
> 'pre_frame_command' which writes the values to a simple CSV type file that you
> can read from within the scene.
>
>
> regards, jr.

Hmm, yes, I could shell out to a Python script that parses the resolution.ini
file.
But how could Python know which section of the resolution file I have selected?

m@

[Josh English] Re: Post something [30 days 8 hours and 56 minutes ago]

Sun, 22 Mar 2026 23:29:06 GMT

On 3/20/2026 4:21 PM, Bald Eagle wrote:
> OK "POV-Ray community,"
> 
> Let's make a concerted effort to get some of those things out of your heads and
> off of your hard drives and onto the forum during the next week.
> 
> Post something.  It doesn't matter what it is.
> Really.   Just post it.  Here.
> 

I've been on-and-off playing with creating cities on the irregular grids 
I was playing with last year.

Buildings align to the "roads" defined by the grid.

[Bald Eagle] Re: Post something [30 days 11 hours and 10 minutes ago]

Sun, 22 Mar 2026 21:15:00 GMT

I have a small library of periodic waveforms.
Note that it's a practical library, sometimes with different ways of
implementing the same general shape.
Some could be trimmed down.
Some could be expanded by adding named parameters that control the shape.
Having differentiable curves would be useful for people who have need for, and
know what they're doing with that sort of thing.

I know that there are a lot of "smoothing functions" out there for use in
animations,

There are some nice polar equations out there.

These should all be standard tools that we can easily implement in scenes.

// Waveform Equations
// Bill "Bald Eagle" Walker 2026/3/22

#version version;
global_settings {assumed_gamma 1.0}


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

light_source {<40, 30, -50> rgb 1 shadowless}

sky_sphere {pigment {rgb 1}}

plane {z, 0.01 pigment {checker rgb 0.9 rgb 0.8}}

#declare Axes =
 union {
  #declare Line = 0.05;
  #declare Base = Line*2;
  #declare Length = 10;
  #declare Ext = 0.25;
  cylinder {<0, 0, 0>, <Length, 0, 0>, Line pigment {rgb x}}
   cone {<Length, 0, 0>, Base, <Length+Ext, 0, 0>, 0 pigment {rgb x} }

  cylinder {<0, 0, 0>, <0, Length, 0>, Line pigment {rgb y}}
   cone {<0, Length, 0>, Base, <0, Length+Ext, 0>, 0 pigment {rgb y}}

  cylinder {<0, 0, 0>, <0, 0, Length>, Line pigment {rgb z}}
   cone {<0, 0, Length>, Base, <0, 0, Length+Ext>, 0 pigment {rgb z}}
 }

//object {Axes}

#declare E = 1e-9;
#declare Inf = 1e10;
#declare Line = 0.08;
#declare Extent = 20;
#declare Step = 0.01;

#declare even = function(N) {select(mod(N, 2), 0, 1, 0)}
#declare odd  = function(N) {select(mod(N, 2), 1, 0, 1)}
#declare sgn  = function(N) {select(N, -1, 0, 1)}
#declare cot = function (N) {1/tan(N)}
#declare sec = function (N) {1/cos(N)}
#declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}

#declare Amplitude = 1;
#declare Period = 1;
#declare a = 1;
#declare b = 1;
#declare c = 0;
#declare f = 1;
#declare m = 1;
#declare l = 1;
#declare p = 1;
#declare T = 0.3; // how long pulse wave stays at 1
// capacitor charge-discharge
//
https://www.syncad.com/waveform_block_equations_for_timing_diagram_editors.htm
#declare pns = 0.2;
#declare pps = pns * 10;
#declare rcns = 0.01;
#declare rcps = 10 * rcns;

#declare Sample = function (N) {mod(N, pps/2)}
#declare Charge = function (N) {select (mod(floor(N/(pps/2)),2), 1, 0, 1)}

#declare Waveforms = array {
 function (N) {abs(-odd(floor(N))+mod(N, 1))},
 function (N) {1-(cos(N*pi)*0.5+0.5)},
 function (N) {sqrt(abs(-odd(floor(N))+mod(N, 1)) )},
 function (N) {pow(abs(-odd(floor(N))+mod(N, 1)), 2)},
 function (N) {select (mod(N, 2)-1, 0, 1)},
 function (N) {mod (N, 1)},
 function (N) {(-3*pow(sin(N*3), 2)*sin(N*6))*0.5},
 function (N) {-pow(sin(N*3), 2)*(a*cos(N*6) + b*sin(N*6))},
 //function (N) {-cos(N*3)*(cos(N*6)+sin(N*6))},
 function (N) {sgn (sin (2*pi*f*N))/2+0.5},
 function (N) {-(2*floor(f*N)-floor(2*f*N))},
 function (N) {pow (-1, floor(2*f*N))/2},
 function (N) {(2/pi) * atan (tan (pi*f*N/2)) + (2/pi) * atan (cot (pi*f*N/2))},
 function (N) {(4/p)*(N-(p/2)*floor(2*N/p+0.5))*pow(-1,floor(2*N/p+0.5))},
 function (N) {2*(N/p-floor(0.5+N/p))},
 function (N) {sgn (cos(2*pi*N/p)-cos(pi*T/p)) * 0.5},
 function (N) {select (Charge(N), 0, a*(1-exp(-Sample(N)/rcps)),
a*exp(-Sample(N)/rcps) )},
 function (N) {(a/pi) * (asin(sin((pi/m)*N+l)) + acos(cos((pi/m)*N+l))) - (a/2)
+ c},
 function (N) {pow(-1, floor(N/2))*sqrt (1-pow((mod(N,2)-1),2))}
};

#declare NF = dimension_size (Waveforms, 1)-1;

#declare Abscissa = x;
#declare Ordinate = y;
// Applicate: The z-coordinate (the last of the three terms by which a point is
referred to,
// in a system of Cartesian coordinates for a three-dimensional space)
#local ZeroVector = <0, 0, 0>;

#for (F, 0, NF)
 #ifdef(Function) #undef Function #end
 #local Function = Waveforms [F];
 //#debug concat ("F = ", str(F, 0, 0), "\n")
 #local Shift_Y = y*F*2;
 cylinder {<0, F*2, 0>, <Extent, F*2, 0> Line*0.75 pigment {checker rgb x rgbf 1
scale 0.25}}
 union {
  #for (i, 0, Extent, Step)
   #local Value = Function (i);
   #local A = Abscissa * i;
   #local O = Ordinate * Value + Shift_Y;
   #local Current = A + O + ZeroVector;
   sphere {Current, Line}
   #if (i > 0)
    cylinder {Last, Current+E Line}
   #end
   #local Last = Current;
  #end
  pigment {rgb 0}
 }
#end

text { ttf "arial.ttf", "Waveform Equations     Bald Eagle 2026/3/22", 0.02, 0.0
pigment {rgb z*0.4} translate y*(F)*2}

[jr] Re: Post something [30 days 14 hours and 40 minutes ago]

Sun, 22 Mar 2026 17:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> OK "POV-Ray community,"
>
> Let's make a concerted effort to get some of those things out of your heads and
> off of your hard drives and onto the forum during the next week.
>
> Post something.  It doesn't matter what it is.
> Really.   Just post it.  Here.

good "initiative", thanks.  so, in the spirit :-), attached a "beta" version of
a POV-Ray documentation tool I'm playing with.  it requires version 3.7.0.8
documentation (the HTML files) installed, and a GNU/Linux "box"; Tcl, SQLite3,
BASH.  while I have a 3.8 version too, the code will need revising first to
allow choice of version (at runtime).

enjoy, jr.

[jr] Re: Animation feature request. [30 days 23 hours and 35 minutes ago]

Sun, 22 Mar 2026 08:50:00 GMT

hi,

"m@b" <nomail@nomail> wrote:
"Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > So, in your ini file you do something like Subset_Start_Frame=30
> > but I'm wondering if you can then do something like
> > Declare=SSF=Subset_Start_Frame.
> > If not, you could just set Declare=SSF=30 and then do Subset_Start_Frame=SSF
> > (if that works)
>
> Thanks for the reply, I didn't realise I could pass identifier values from an
> ini file, that's useful.
>
> Unfortunately "The value on the right-hand side must be a constant float value."
>
> So this works:
>
>    Subset_Start_Frame=394
>    Declare=SSF=394
>
> But these don't:
>
>    Subset_Start_Frame=394
>    Declare=SSF=Subset_Start_Frame
>
>    Subset_Start_Frame=394
>    Declare=SSF=float(Subset_Start_Frame)
>
>    Declare=SSF=394
>    Subset_Start_Frame=SSF
>
> Declaring twice is no big hardship as long as I remember!

another option, not yet mentioned, is having a (shell) script run from the
'pre_frame_command' which writes the values to a simple CSV type file that you
can read from within the scene.


regards, jr.

[m@b] Re: Animation feature request. [31 days and 25 minutes ago]

Sun, 22 Mar 2026 08:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "m@b" <nomail@nomail> wrote:
> > (In response to "Post something", Bald Eagle)
>
> Thanks - that's one facet of this thread - so often we're independently trying
> to work something out by ourselves (which is admirable), but the solution might
> elude us for some time and thwart the completion of a project.
>
> > I wish we had access to Subset_Start_Frame and Subset_End_Frame from within the
> > SDL.
> >
> > We already have access to initial_frame, final_frame, frame_number, etc.
> >
> > I have a inc file that reports (via #debug) animation average frame time,
> > estimated completion time, etc. It doesn't work if I am only rendering a subset
> > of an animation.
>
> Yes, that would be helpful.
> I don't often use animation or ini files (that's more of a jr thing)
> but I'm wondering if you can do something similar to what's done with screen.inc
> where the user defines the camera position and look_at vectors as SDL-visible
> identifiers, and then proceeds to use them from there.
>
> I recall that you can set identifier values from an ini file, so perhaps you can
> pass the information in to the main scene file that way.
>
> 3.2.5.1 Constant
> Declare=IDENTIFIER=FLOAT Declares an identifier with a float value
> You can now declare a constant in an INI file, and that constant will be
> available to the scene. Since INI file statements may also be laced on the
> command-line, you can therefore also declare on the command-line (though there
> is no switch for it).
>
>   Declare=MyValue=24
> This would be the same as a #declare MyValue=24; in a scene file. The value on
> the right-hand side must be a constant float value.
>
> A possible use could be switching off radiosity or photons from command-line:
>
> --in INI-file / on command-line
>
> Declare=RAD=0
>
> --in scenefile
>
> global_settings {
>   #if (RAD)
>     radiosity {
>     ...
>     }
> #end
> }
>
> So, in your ini file you do something like Subset_Start_Frame=30
> but I'm wondering if you can then do something like
> Declare=SSF=Subset_Start_Frame.
> If not, you could just set Declare=SSF=30 and then do Subset_Start_Frame=SSF
> (if that works)
>
>
> - BE

Thanks for the reply, I didn't realise I could pass identifier values from an
ini file, that's useful.

Unfortunately "The value on the right-hand side must be a constant float value."

So this works:

   Subset_Start_Frame=394
   Declare=SSF=394

But these don't:

   Subset_Start_Frame=394
   Declare=SSF=Subset_Start_Frame

   Subset_Start_Frame=394
   Declare=SSF=float(Subset_Start_Frame)

   Declare=SSF=394
   Subset_Start_Frame=SSF

Declaring twice is no big hardship as long as I remember!
Thanks again,
m@

[Bald Eagle] Re: Post something [31 days 14 hours and 20 minutes ago]

Sat, 21 Mar 2026 18:05:00 GMT

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

> A little coding or math trick.

Writing functions for a pigment {function {}} pattern with a scalar-only
function parser / VM can be painful.

For every vector, I need to evaluate 3 separate functions for each component,
and then when I need to daisy-chain functions together, that multiplies at every
step.

So one of the things I have come up with that makes this a little easier is to
extract the component that I need from the vector, and use select () to choose
which equation I need to evaluate based on a nice little operation.

select is a nice little function that gives me a way to use different equations
given the sign of some variable.
The easy way to remember this is to write select (N, -1, 0, 1).
Depending on the sign of N, I get the sign as the result.
You can put whatever you want in place of the sign when actually using this
mnemonic in practice.

To choose what equation you want would require you to remember that the pattern
is x=-1, y=0, and z=+1
But that's one more thing to forget, so we can make use of the dot product to
generate those values for us from the cardinal axis values themselves.

In POV-Ray, during the parse phase,
            ======================
x = <1, 0, 0>
y = <0, 1, 0>
z = <0, 0, 1>

The dot product takes the respective components of each vector, multiplies them
together, and then adds all the quotients to give a scalar value.

V1.x * V2.x +
V1.y * V2.y +
V1.z * V2.z
-------------
= dot product (V1, V2)

With POV-Ray's x, y, and z vectors, we are only ever multiplying anything by 0
or 1.

So what we do is take vector <-1, 0, 1> and calculate the dot product of that
with x, y, or z.

with x, you get 1 * -1, and the rest are zeros. Sum = -1
with Y, you get 1 *  0, and the rest are zeros. Sum =  0
with z, you get 1 *  1, and the rest are zeros. Sum =  1

This makes it easy to write macros that can take a vector argument and return a
function from a macro or the scalar result of a function from select ().

That's handy when you need to write a bunch of functions for x AND y AND z.
Because you can write a macro to assemble the function based upon which vector
you need.

MyMacro (x)

So you can either use an array of x, y, and z, or manually specify in your code
which one you want, and your intent is unambiguous.

This seems trivial.
It also requires a little bit of work up front to create the functionality, but
it makes handling functions along 3 different axes a lot more easily managed,
especially when you have A LOT of them.

In the macro below, I can assemble functions for each axis by using select() to
grab that vector component from an array using dot notation.  This is
interesting because we're operating in the parser, not the function VM, so we
can use both arrays and dot notation to _construct_ a function.

Those values will remain static - which is fine because those are the vector
components of the control points for the Bezier surface, and don't need to
dynamically change during render phase.

#macro MakeVFn_BezierPatch (_Array, _Component)
// Assembles formula for ONE VECTOR COMPONENT of a Bezier patch
//             (need to run THREE TIMES: once each for x, y, and z)
 #local Degree = dimension_size (_Array, 1)-1;
 function (_U, _V) {
 #for (j, 0, Degree)
  #for (i, 0, Degree)
  #local _P =
                select (_Component, _Array [i][j].x, _Array [i][j].y, _Array
[i][j].z);

  Bernstein(Degree, i, _V) * Bernstein(Degree, j, _U) * _P +
  #end
 #end
 0}  // terminates equation for sum of all Bernstein polynomials in the patch
#end

That's a little snippet from a mammoth .pov file, so below is a self-contained
script that you can read and play with.  A different function is graphed along
each axis without having to specify each axis operation by hand.

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


// Scene file for demonstrating the use of the dot product for
// extracting the relevant vector component of a macro argument
// by converting it to an index value for direct use in select ()
// Bill "Bald Eagle" Walker  2026/03/21

// There are other ways to do this, but this highlights one of the
// MANY uses of the vector dot product.

#version version;
global_settings {assumed_gamma 1.0}


camera {
 location  <1/4, 1, -1/2>*15
 right  x*image_width/image_height
 up   y
 look_at  <0, 0, 0>
}

light_source {<40, 30, -50> rgb 1 shadowless}

sky_sphere {pigment {rgb 1}}

plane {y, 0 pigment {checker rgb 0.1 rgb 0.2} scale 2}

#declare E = 0.000001;
#declare Line = 0.05;
#declare Extent = 10;
#declare Step = 0.1;


#declare Vdot = function (Vx, Vy, Vz, Cx, Cy, Cz) {Vx*Cx + Vy*Cy + Vz*Cz}
#macro DotProduct (V1, V2)
 #local V1x = V1.x;
 #local V1y = V1.y;
 #local V1z = V1.z;
 #local V2x = V2.x;
 #local V2y = V2.y;
 #local V2z = V2.z;
 Vdot (V1x, V1y, V1z, V2x, V2y, V2z)
#end
#declare even = function(x) {select(mod(x, 2), 0, 1, 0)}
#declare odd  = function(x) {select(mod(x, 2), 1, 0, 1)}

#declare Cardinal = array {x, y, z}
#declare Selector = <-1, 0, 1>;
#local ZeroVector = <0, 0, 0>;

#declare FunctionX = function (N) {sqrt(N)}
#declare FunctionY = function (N) {abs(-odd(floor(N))+mod(N, 1))}
#declare FunctionZ = function (N) {sin (N)}
#declare V3 = function (N) {mod (N, 3)}

#declare AxisFunction = function (Switch, N) {
 select (
  Switch,
  FunctionX (N),
  FunctionY (N),
  FunctionZ (N)
 )
}

#for (Axis, 0, 2)
 #local Vector = Cardinal [Axis];
 //===============================================
 #local Component = DotProduct (Vector, Selector);
 //===============================================
 #local Abscissa = Vector;
 #local Ordinate = Cardinal [V3(Axis+1)];

 union {
  #for (i, 0, Extent, Step)
   #local Value = AxisFunction (Component, i);
   #local A = Abscissa * i;
   #local O = Ordinate * Value;
   #local Current = A + O + ZeroVector;
   sphere {Current, Line}
   #if (i > 0)
    cylinder {Last, Current+E Line}
   #end
   #local Last = Current;
  #end
  pigment {rgb Vector}
 }
#end

[Bald Eagle] Re: question about same code(?) and different re... [31 days 15 hours and 55 minutes ago]

Sat, 21 Mar 2026 16:30:00 GMT

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

> Whoa, this is news to me!  Where is this in the documentation?

> This has implications for macros that force promotion on its arguments
> or that return vectors to be used as colors.  Sometimes the only way to
> avoid a parse warning or parse error is to use the color keyword.

Yeah, this is what happens when I get too little sleep and try to wrangle things
with a search engine while I'm doing 8 other things at the same time have and no
direct access to povray so I can run test code.

It didn't seem right - especially due to the vector promotion thing, but I just
plowed right through that and didn't listen to "the little voice".

What a gaffe.  Someone delete this.  :O

- BE

[GioSeregni] Re: question about same code(?) and different re... [31 days 16 hours and 30 minutes ago]

Sat, 21 Mar 2026 15:55:00 GMT

Thank to all!
I'm sorry for wasting your time

I accidentally found the source of the problem. It must have happened while
using my compression routine to remove unnecessary white space. I couldn't
replicate the error; when I used it on a very large file, it gave the same
error. Suspended... for now.
Sorry again !

[Cousin Ricky] Re: question about same code(?) and different re... [31 days 16 hours and 46 minutes ago]

Sat, 21 Mar 2026 15:39:03 GMT

On 2026-03-20 08:10 (-4), Bald Eagle wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> 
>> triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
>> pigment{color rgb<255/255,63/255,0/255>}}
>>
>> triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
>> pigment{color rgb<1,63/255,0>}}

I'm confused.  Both colors specifications should be orange, but I see no
orange in the images.  The only difference I see is areas that are black
on the left and white on the right, and that does not look like a gamma
issue.

It would help if we had more context for this code.  When I incorporated
the triangles in a scene, they both were the expected orange.

> This is VERY interesting Gio.
> 
> Apparently the color keyword applies gamma handling,
> but using just rgb is linear color.
> 
> Remove the color keyword and see if the colors are the same.
> 
> I'd also be interested to see what happens if you do your multiplication first.
> #declare Color = <255/255,63/255,0/255>;
> pigment{color rgb Color}}
> 
> I guess "color" triggers legacy gamma correction rules, which exists for
> backwards compatibility.
> 
> - BE
> 
> â€œThe color keyword causes POV‑Ray to treat the given RGB
values as
> gamma‑encoded color values, applying the scene gamma correction rules.
> The plain rgb keyword specifies linear RGB values.â€
> 
> And:
> 
> â€œThe color keyword is deprecated and should be avoided in new
scenes.â€

Whoa, this is news to me!  Where is this in the documentation?

This has implications for macros that force promotion on its arguments
or that return vectors to be used as colors.  Sometimes the only way to
avoid a parse warning or parse error is to use the color keyword.

[Bald Eagle] Re: Post something [31 days 17 hours and 45 minutes ago]

Sat, 21 Mar 2026 14:40:00 GMT

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

> "I tried to get Z to work, but never finished it."

Way back when - when I had lots more time to spend several (mostly)
uninterrupted hours working things out, I coded up an animation of the entire
solar system, which mostly astronomically correct.   Plus the asteroid belt.

Everything started out at clock=0, and all the objects were in syzygy.

For all those other folks playing around with such things like orreries, the
important part is adjusting everything for it's specific Mean Anomaly.

J2000.0 is the standard astronomical epoch—a precise reference time—defined
as
January 1, 2000, at 12:00 Terrestrial Time (TT) or Julian Date 2451545.0

Mean anomaly formulation:
M(t) = M0 + 360 * (t - t0)/P
Where:
- M0 : mean anomaly at J2000
- t : POV-Ray clock (years)
- t0 : epoch (0 = J2000)
- P : orbital period (years)

#declare Epoch_J2000 = 0.0;

#declare Mercury_M0 = 174.79253;
#declare Venus_M0   =  50.37663;
#declare Earth_M0   = 357.51716;
#declare Mars_M0    =  19.39020;
#declare Jupiter_M0 =  19.66796;
#declare Saturn_M0  = 317.02070;
#declare Uranus_M0  = 142.28383;
#declare Neptune_M0 = 260.24710;
#declare Pluto_M0   =  14.53;

Moons don't orbit around the sun, and so they need to be adjusted for their
local barycentric framing.


#declare Luna_M0 = 115.3654;

#declare Io_M0       = 171.0168;
#declare Europa_M0   =  67.9876;
#declare Ganymede_M0 =  44.0648;
#declare Callisto_M0 = 259.7088;

#declare Titan_M0     = 186.5855;
#declare Rhea_M0      = 191.9137;
#declare Iapetus_M0   =  79.6900;
#declare Dione_M0     = 131.5349;
#declare Tethys_M0    = 215.1191;
#declare Enceladus_M0 = 268.0502;

#declare Miranda_M0 = 311.33;
#declare Ariel_M0   =  98.35;
#declare Umbriel_M0 = 355.67;
#declare Titania_M0 =  77.82;
#declare Oberon_M0  = 250.96;

#declare Triton_M0 = 328.92;

[Bald Eagle] Re: Post something [31 days 18 hours and 5 minutes ago]

Sat, 21 Mar 2026 14:20:00 GMT

One of the things that I have sustained an active interest in over the past
several years is the creation of procedural patterns.

Doing this in SDL to create pigment {function {}} patterns can be challenging
due to the scalar-only nature of the function parser / virtual machine.

During experimentation with infinitely tiling a plane or filling space, it
became readily apparent that the stock modulo function - mod (N, M) - did not
remain consistent across the -value|0|+value transition.

So I crafted my own.   And then another.   And then another.
So which one was "right"?  Apparently this is one of those situation-dependent
functions like pow (0, 0).

So I did some investigating and there are a number of different ways to perform
modular arithmetic so that the result has the specific characteristics that you
need in your given situation.  And here's an important note: you may need to use
different behaviours in different parts of your equations.

I discovered that my custom-rolled fmod () function usually worked for what I
needed, but when applied in a blanket manner was inappropriate for certain parts
of my patterns.   So I use fmod () some places, and stock mod () in others.

Here's a small starting library.  I'm sure there are more variations.

// MODULO_LIB.inc
// Behavioral Modulo Library for POV-Ray SDL
// Guarded, scalar-only, function-safe

#ifndef (MODULO_LIB_INC)
#declare MODULO_LIB_INC = yes;

// --- HARD MODULO ---
#declare MOD_HARD_BASIC = function (V, P) { mod(V, P) };

// --- ABSOLUTE MODULO ---
#declare MOD_ABS_BASIC = function (V, P) { mod(abs(V), P) };

// --- PHASE-CORRECTED ABS MODULO ---
#declare MOD_ABS_PHASE = function (V, P)
{ select(V, 1 - mod(abs(V), P), mod(abs(V), P)) };

// --- CENTERED MODULO ---
#declare MOD_CENTER_BASIC = function (V, P)
{ mod(V + P/2, P) - P/2 };

// --- TRIANGLE MODULO ---
#declare MOD_TRI_BASIC = function (V, P)
{ abs(mod(V, 2*P) - P) };

// --- SMOOTH MODULO ---
#declare MOD_SMOOTH_BASIC = function (V, P)
{ P * (0.5 - 0.5*cos(2*pi*V/P)) };

#declare MOD_SMOOTH_SIGNED = function (V, P)
{ V - P * sin(2*pi*V/P)/(2*pi) };

// --- NESTED MODULO ---
#declare MOD_NEST_BASIC = function (V, A, B)
{ mod(mod(V, A), B) };

#declare MOD_NEST_ABS = function (V, A, B)
{ mod(mod(abs(V), A), B) };

#declare MOD_NEST_PHASE = function (V, A, B)
{ select(V, B - mod(mod(abs(V), A), B), mod(mod(abs(V), A), B)) };

// --- LOGIC MODULO ---
#declare MOD_LOGIC_PARITY = function (V, P)
{ mod(floor(abs(V)/P), 2) };

#declare MOD_LOGIC_QUANTIZED = function (V, P, S)
//{ round(mod(V, P)/S)*S };
{ int(mod(V, P)/S)*S };

// --- WINDOWED / CLAMPED ---
#declare MOD_LOGIC_WINDOW = function (V, P)
{ select(V, mod(abs(V), P), 0) };

#declare MOD_LOGIC_CLAMP = function (V, P, C)
{ min(mod(V, P), C) };

// --- METRIC HELPERS ---
#declare MOD_METRIC_RADIAL = function (R, P)
{ mod(R, P) };

#declare MOD_METRIC_ANGLE = function (A, P)
{ mod(A, P) };

#end
// *** end of file ***

[Bald Eagle] Re: Post something [31 days 18 hours and 25 minutes ago]

Sat, 21 Mar 2026 14:00:00 GMT

One of the reasons that I started this thread was to try and spur people into
action, and get people who are scattered over the vast interweb to contribute
here in the official POV-Ray newsgroup.  Not Facebook, Meta, X, Telegram,
Instagram, YouTube, Discord, etc.

I have too many of my own projects to keep up with - I don't have the time and
attention to multiply posting and answer-searching over a dozen other venues.

Also, since I don't have the time to pursue every new thing that I come across
or need to do as part of a 5-step development, I figured I'd start posting bits
and pieces, so that others might be inspired to pick something up, investigate
it further, and maybe carry it across the finish line.

Some things I "complete" just to demonstrate proof-of-concept.
"No, it's not 'impossible'."
Other things I create from spur-of-the moment necessity, and just continue using
as a matter of practicality.
All of those things could surely be "better", more efficient, and more elegant.
They could also be refactored into durable "production code" with future-proof
structuring of the code and data structures, comments, references, and notes on
future, unfinished improvements.

Perhaps if there is interest - the fruits of this thread could be periodically
packaged into a semantic-versioned archive (zip, 7z, tar.gz) that would help
people expand on the official distribution.

- BE

[Bald Eagle] Re: Post something [31 days 18 hours and 45 minutes ago]

Sat, 21 Mar 2026 13:40:00 GMT

"Attractors"

When surfing the Web looking for new and interesting pigment patterns that I
could implement, I came across some very cool looking stuff.

The idea is that a pattern is somehow modulated by its proximity to points or
even lines.  Any attribute can be modified - size, shape, color, position, some
other more complicated thing like a parameter of the underlying pattern, etc.

I've experimented a little with this in the past, but didn't know that it was a
fully-developed "thing".

Here's a sinc function that modulates the size of 3 different object grids.

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

[Bald Eagle] Re: Animation feature request. [31 days 18 hours and 55 minutes ago]

Sat, 21 Mar 2026 13:30:00 GMT

"m@b" <nomail@nomail> wrote:
> (In response to "Post something", Bald Eagle)

Thanks - that's one facet of this thread - so often we're independently trying
to work something out by ourselves (which is admirable), but the solution might
elude us for some time and thwart the completion of a project.

> I wish we had access to Subset_Start_Frame and Subset_End_Frame from within the
> SDL.
>
> We already have access to initial_frame, final_frame, frame_number, etc.
>
> I have a inc file that reports (via #debug) animation average frame time,
> estimated completion time, etc. It doesn't work if I am only rendering a subset
> of an animation.

Yes, that would be helpful.
I don't often use animation or ini files (that's more of a jr thing)
but I'm wondering if you can do something similar to what's done with screen.inc
where the user defines the camera position and look_at vectors as SDL-visible
identifiers, and then proceeds to use them from there.

I recall that you can set identifier values from an ini file, so perhaps you can
pass the information in to the main scene file that way.

3.2.5.1 Constant
Declare=IDENTIFIER=FLOAT Declares an identifier with a float value
You can now declare a constant in an INI file, and that constant will be
available to the scene. Since INI file statements may also be laced on the
command-line, you can therefore also declare on the command-line (though there
is no switch for it).

  Declare=MyValue=24
This would be the same as a #declare MyValue=24; in a scene file. The value on
the right-hand side must be a constant float value.

A possible use could be switching off radiosity or photons from command-line:

--in INI-file / on command-line

Declare=RAD=0

--in scenefile

global_settings {
  #if (RAD)
    radiosity {
    ...
    }
#end
}

So, in your ini file you do something like Subset_Start_Frame=30
but I'm wondering if you can then do something like
Declare=SSF=Subset_Start_Frame.
If not, you could just set Declare=SSF=30 and then do Subset_Start_Frame=SSF
(if that works)

- BE

[Maetes] Re: Animation feature request. [31 days 19 hours and 45 minutes ago]

Sat, 21 Mar 2026 12:40:00 GMT

It won't solve your problem, but I want to advertise my animation script
collection again at this point.

https://www.maetes.com/en/povray-os/ma_screenplay


ma

[Cousin Ricky] Re: Post something [32 days 4 hours and 54 minutes ago]

Sat, 21 Mar 2026 03:31:05 GMT

On 2026-03-20 19:21 (-4), Bald Eagle wrote:
> 
> Post something.  It doesn't matter what it is.
> Really.   Just post it.  Here.

Funny you should mention.  I was just at a stopping point with this
experiment for improving my light bleeding code.

[m@b] Animation feature request. [32 days 4 hours and 55 minutes ago]

Sat, 21 Mar 2026 03:30:00 GMT

I wish we had access to Subset_Start_Frame and Subset_End_Frame from within the
SDL.

We already have access to initial_frame, final_frame, frame_number, etc.

I have a inc file that reports (via #debug) animation average frame time,
estimated completion time, etc. It doesn't work if I am only rendering a subset
of an animation.

(In response to "Post something", Bald Eagle)

m@

[Bald Eagle] Re: Post something [32 days 8 hours and 20 minutes ago]

Sat, 21 Mar 2026 00:05:00 GMT

All-SDL, Fully tileable, Full-color true Voronoi pigment. (grid-based)

[Bald Eagle] Post something [32 days 9 hours ago]

Fri, 20 Mar 2026 23:25:00 GMT

OK "POV-Ray community,"

Let's make a concerted effort to get some of those things out of your heads and
off of your hard drives and onto the forum during the next week.

Post something.  It doesn't matter what it is.
Really.   Just post it.  Here.

A question.
"I saw X and always wondered how they did that."
"I always wanted to do Y, but never knew how."
"I tried to get Z to work, but never finished it."
"How does this work in source code?"
"How do I achieve this effect?"
"I saw this on the forum, and always wondered how they did that."

A simple scene.
A little coding or math trick.
A photo/diagram of something you've always wanted to make in POV-Ray.
And old scene that you've never posted.  "I made this way back in 19XX"

I wish we had XYZ feature.
There's a bug that's always annoyed me.

They can do this with
Blender/Maya/Grasshopper/Shadertoy/Mathematica/MathMod/etc. so why can't we do
that with POV-Ray?

I did a web search for PDQ and I found ABC.   Pretty cool, huh?

If you know some people who are on another website / forum / social media site -
extend the invitation to post . . . something.

Poke your old POV-Ray friends until they post something just to get you to stop
bothering them.  :D

Add new topics to post about.  "You forgot IJK..."

- BE

[jr] Re: question about same code(?) and different re... [32 days 14 hours and 25 minutes ago]

Fri, 20 Mar 2026 18:00:00 GMT

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> mmmm... it seems not working again
> it's possible that in the same vector <nnn,nnn,nnn> the elements cannot to be a
> mix of integer and float (nnn/nnn)

to POV-Ray an "integer" is the same as a float, without decimal point & digits,
"Where POV-Ray needs an integer value it allows you to specify a float value and
it truncates it to an integer".
<wiki.povray.org/content/Reference:Numeric_Expressions>

regards, jr.

[GioSeregni] Re: question about same code(?) and different re... [32 days 14 hours and 45 minutes ago]

Fri, 20 Mar 2026 17:40:00 GMT

mmmm... it seems not working again
it's possible that in the same vector <nnn,nnn,nnn> the elements cannot to be a
mix of integer and float (nnn/nnn)

[GioSeregni] Re: question about same code(?) and different re... [32 days 15 hours and 35 minutes ago]

Fri, 20 Mar 2026 16:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> > pigment{color rgb<255/255,63/255,0/255>}}
> >
> > triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> > pigment{color rgb<1,63/255,0>}}
>
> This is VERY interesting Gio.
>
> Apparently the color keyword applies gamma handling,
> but using just rgb is linear color.
>
> Remove the color keyword and see if the colors are the same.
>
> I'd also be interested to see what happens if you do your multiplication first.
> #declare Color = <255/255,63/255,0/255>;
> pigment{color rgb Color}}
>
> I guess "color" triggers legacy gamma correction rules, which exists for
> backwards compatibility.
>
> - BE
>
>
> gamma‑encoded color values, applying the scene gamma correction rules.
>
>
> And:
>
>
Thanks for the suggestion.
I'm upgrading my POV-STL-CAD translator from 32 to 64 bit, and I realized that
before translating the pov files I need to normalize all the various syntax
expressions I used in my POV and INC files.
If I don't standardize the syntax, compiling the database for exports the
entities will become a very complicated mess.
I'll try what you suggest...

[Bald Eagle] Re: question about same code(?) and different re... [32 days 20 hours and 10 minutes ago]

Fri, 20 Mar 2026 12:15:00 GMT

"GioSeregni" <gms### [at] hotmailcom> wrote:

> triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> pigment{color rgb<255/255,63/255,0/255>}}
>
> triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> pigment{color rgb<1,63/255,0>}}

This is VERY interesting Gio.

Apparently the color keyword applies gamma handling,
but using just rgb is linear color.

Remove the color keyword and see if the colors are the same.

I'd also be interested to see what happens if you do your multiplication first.
#declare Color = <255/255,63/255,0/255>;
pigment{color rgb Color}}

I guess "color" triggers legacy gamma correction rules, which exists for
backwards compatibility.

- BE

“The color keyword causes POV‑Ray to treat the given RGB values as
gamma‑encoded color values, applying the scene gamma correction rules.
The plain rgb keyword specifies linear RGB values.”

And:

“The color keyword is deprecated and should be avoided in new scenes.”

[GioSeregni] question about same code(?) and different render [33 days 4 hours and 50 minutes ago]

Fri, 20 Mar 2026 03:35:00 GMT

I am working at my parser, but I got two different results.

example :

triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
pigment{color rgb<255/255,63/255,0/255>}}

triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
pigment{color rgb<1,63/255,0>}}


but is mathematics an opinion? (ver. 3.7)

many thaks if someone help me to understand!

[Leroy] Re: povray.org and related sites unreachable to ... [35 days 14 hours and 30 minutes ago]

Tue, 17 Mar 2026 17:55:00 GMT

> > Additionally once the issue is resolved, this will serve as an explanation as to
why we were "down" for so long.
> >
> > regards,
> >
> > -- Chris
>
> Thanks! I've posted elsewhere not knowing what the problem was. I still
> don't,(I'm not that bright;) But a lease someone is working on it!

I'm back here 2 days in a row. Somebody did something good!

[LanuHum] Re: Help: The normal map is not working [35 days 16 hours and 5 minutes ago]

Tue, 17 Mar 2026 16:20:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hello! I created a picture with a gradient. I want to use it as a
> > height map for a sphere. However, only gray stripes are visible on the sphere.
> >
>
> The 'flat' look of those gray stripes seems odd to me; there *should* be some
> (fake) 'depth' to them due to your bump_map, based on the normal-pattern image
> that you posted:
>
> normal{ bump_map{"/home/lanuhum/src/Thread_90.jpg"
> gamma 1.1000 map_type 0
> interpolate 2 bump_size 5}
>
> I ran your code--using the same 'normal' image that I copied here-- and it seems
> that a gamma of 1.1 that you used is not a good value for a bump_map. I changed
> that value to 2.2 (and boosted the bump_size to 10) and it looks much better.
>
> If I leave out the gamma keyword altogether, the 'flat' result looks nearly
> identical to your 1.1 value. The POV-ray default is 1.0 (i.e., it treats the
> image as 'linear' data.)
>
> Since we are both using jpeg's for the bump_map, they have a standard 'embedded
> gamma' of around 2.2 (or maybe 'srgb'), which is not linear. So using a value of
> 1.1 (or 1.0) changes that; a somewhat simple explanation is that it reduces the
> contrast of the image-as-bump_map.
>
> From the documentation:
> "While POV-Ray will normally interpret the bump map input file as a container of
> linear data [gamma of 1.0] irregardless of file type, this can be overridden for
> any individual bump map input file by specifying gamma immediately after the
> file name."

My sincere apologies. I missed your message. Thank you so much for your help

[Ilya Razmanov] Re: Help: The normal map is not working [35 days 22 hours and 22 minutes ago]

Tue, 17 Mar 2026 10:02:48 GMT

On 16.03.2026 14:20, Kenneth wrote:
> The 'flat' look of those gray stripes seems odd to me; there *should* be some
> (fake) 'depth' to them due to your bump_map,

Absolutely agree. But I was unable to find the reason why the result do 
not conform with my expectations.

> I changed
> that value to 2.2

Aha! That that seem be that evasive reason!

Thank you, that sort of explains things.

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

[Leroy] Re: povray.org and related sites unreachable to ... [36 days 9 hours and 55 minutes ago]

Mon, 16 Mar 2026 22:30:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The datacenter in which the dedicated server hosting POV-Ray recently changed. As we
have our own class C (/24) subne
t, this (in theory) should not have affected us (outside of a few hours of downtime as
the machine was physically trans
ported) as no IP addresses needed to change: our host only had to alter the
appropriate BGP announcement to indicate th
e new route to/from our network.
>
> However it has since come to our attention that many parts of the internet are
unable to access resources on our serv
er. Sites such as wiki.povray.org and www.irtc.org continue to work as they are cached
by Cloudflare, and Cloudflare ca
n still talk to our server. The problem lies in the fact that whilst we are receiving
the incoming traffic sent our way
, outgoing traffic that needs to pass through Comcast is black-holed only four hops
from our server. This means anyone 
who is behind Comcast addresses are unable to access anything on our server.
>
> We have used our class C network for more than a quarter of a century with no real
issues; this is the first time we'
ve been black-holed by a major transit point in the US and we have no explanation for
it. A request has been lodged wit
h the Comcast NOC to fix this but as of the time of writing it remains in place.
>
> We're posting this message right now primarily to raise awareness amongst those who
are not affected but are in commu
nication with those who are (via means outside this site) to let them know why they
can't connect, since of course affe
cted users aren't able to read this message right now.
>
> Additionally once the issue is resolved, this will serve as an explanation as to why
we were "down" for so long.
>
> regards,
>
> -- Chris

Thanks! I've posted elsewhere not knowing what the problem was. I still
don't,(I'm not that bright;) But a lease someone is working on it!

[Mr] Re: Help: How to create a bolt? [36 days 15 hours and 45 minutes ago]

Mon, 16 Mar 2026 16:40:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > #version 3.8;
> > global_settings {assumed_gamma 1.0 }
> >
> > camera {
> >  location <0, 1, -3>
> >  right x*image_width/image_height
> >  up y
> >  look_at <0, 1, 0>
> > }
> >
> > light_source {<10, 20, -50> rgb 1}
> > sky_sphere {pigment {rgb 1}}
> >
> >
> > #declare TPI = 11; // (Threads per inch / TPI)
> > #declare DM = 0.625/2;
> > #declare Dm = 0.5167/2;
> > #declare Angle = 60;
> >
> > #declare Pitch = 1/TPI;
> > #declare CompAngle = 90-Angle;
> > #declare Asin = atan(radians(CompAngle));
> > #declare dx = DM - Dm;
> > #declare dy = dx * Asin;
> > #declare AL = 2*dy; // total Angled length
> > #declare FL = (Pitch - AL)/2; // Flat length
> >
> > // Profile
> > #declare P = array {
> >       <Dm, 0, 0>,
> >       <DM, dy, 0>,
> >       <DM, dy+FL, 0>,
> >       <Dm, dy+FL+dy, 0>,
> >       <Dm, dy+FL+dy+FL, 0>
> > }
> >
> > #declare OldPoint = array[5][3];
> > #declare NewPoint = array[5][3];
> >
> > #macro MakeBoltProfile (Pitch,Steps, Tex, Copies)
> >       #local Increment = tau/Steps;
> >       #local Unit =
> >       union {
> >       #for (Theta, 0, tau, Increment)
> >
> >             #for (Pt, 0, 4)
> >             #declare NewPoint[Pt][0] = P[Pt].x * cos (Theta);
> >             #declare NewPoint[Pt][1] = P[Pt].y + Pitch * Theta/tau;
> >             #declare NewPoint[Pt][2] = P[Pt].x * sin (Theta);
> >             #end
> >
> >             #if (Theta > 0)
> >             #for (T, 0, 3)
> >                   triangle {<OldPoint[T][0], OldPoint[T][1], OldPoint[T][2]>,
> >                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
> >                         <OldPoint[T+1][0], OldPoint[T+1][1], OldPoint[T+1][2]>
> >                   }
> >                   triangle {<OldPoint[T+1][0], OldPoint[T+1][1],
> > OldPoint[T+1][2]>,
> >                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
> >                         <NewPoint[T+1][0], NewPoint[T+1][1], NewPoint[T+1][2]>
> >                   }
> >             #end
> >           #end
> >
> >             #declare OldPoint = NewPoint;
> >       #end
> >       texture {Tex}
> >       }
> >       #for (C, 1, Copies)
> >             object {Unit translate y*Pitch*C*1}
> >       #end
> > #end
> >
> > #declare MyTex = texture {pigment {rgb 0.9} finish {specular 0.4 reflection
> > 0.01}}
> >
> > MakeBoltProfile (Pitch, 72, MyTex, 25)
>
> Thank you so much. I have no more questions about the topic.

Very glad you're back ! and it looks nice!

[Bald Eagle] Re: Help: The normal map is not working [36 days 19 hours and 15 minutes ago]

Mon, 16 Mar 2026 13:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hello! I created a picture with a gradient. I want to use it as a
> > height map for a sphere. However, only gray stripes are visible on the sphere.

> I ran your code--using the same 'normal' image that I copied here-- and it seems
> that a gamma of 1.1 that you used is not a good value for a bump_map. I changed
> that value to 2.2 (and boosted the bump_size to 10) and it looks much better.

Good work digging a little deeper into this.
I was just checking in during morning coffee, and then heading straight out.

Depending on what the final use case is, he might want consistent/believable
shadows to go along with that deep scalloped surface.
Also, it seems a little silly to evaluate the function to make an image that
then gets used as a bump map - when he can just plug it straight into an
isosurface and get better results without all of the extra workflow and
processing.

However your experiments are not without value.  I think it would be a nice
demonstration scene if you made a grid of spheres each with different gamma
handling and bump sizes - AND had them all cast shadows onto a plane.

If you share your thoughts about how the image gets converted to gamma 2.2 or
srgb-modified rgb values, and I can pipe that into the isosurface equations for
a parallel rendering and comparison.

- BE

[Kenneth] Re: Help: The normal map is not working [36 days 21 hours ago]

Mon, 16 Mar 2026 11:25:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hello! I created a picture with a gradient. I want to use it as a
> height map for a sphere. However, only gray stripes are visible on the sphere.
>

The 'flat' look of those gray stripes seems odd to me; there *should* be some
(fake) 'depth' to them due to your bump_map, based on the normal-pattern image
that you posted:

normal{ bump_map{"/home/lanuhum/src/Thread_90.jpg"
gamma 1.1000 map_type 0
interpolate 2 bump_size 5}

I ran your code--using the same 'normal' image that I copied here-- and it seems
that a gamma of 1.1 that you used is not a good value for a bump_map. I changed
that value to 2.2 (and boosted the bump_size to 10) and it looks much better.

If I leave out the gamma keyword altogether, the 'flat' result looks nearly
identical to your 1.1 value. The POV-ray default is 1.0 (i.e., it treats the
image as 'linear' data.)

Since we are both using jpeg's for the bump_map, they have a standard 'embedded
gamma' of around 2.2 (or maybe 'srgb'), which is not linear. So using a value of
1.1 (or 1.0) changes that; a somewhat simple explanation is that it reduces the
contrast of the image-as-bump_map.

From the documentation:
"While POV-Ray will normally interpret the bump map input file as a container of
linear data [gamma of 1.0] irregardless of file type, this can be overridden for
any individual bump map input file by specifying gamma immediately after the
file name."

[Kenneth] Re: povray.org and related sites unreachable to ... [36 days 22 hours and 55 minutes ago]

Mon, 16 Mar 2026 09:30:00 GMT

Thanks for the info, Chris.

For most of today, I was unable to access either news.povray.org or
www.povray.org (I am in the state of Virginia, U.S), but tried again at 5:15am
and they are working OK now. I have no idea if Comcast is somehow 'intertwined'
with my Verizon internet service here!

(Running the latest Firefox update...or nearly so.)

[Chris Cason] Re: povray.org and related sites unreachable to ... [37 days 6 hours and 44 minutes ago]

Mon, 16 Mar 2026 01:41:36 GMT

On 16/03/2026 00:56, Bald Eagle wrote:
> Is there some sort of BGP / website proxy thing that can serve as a functional
> workaround?

Yes: for the same reason as wiki.povray.org is still accessible. It is cached through
Cloudflare, and the same would work for www. The only reason it's not already in place
long ago is that there is a bug in the interaction between news.povray.org and
www.povray.org when the former sends a user to the latter to log in (e.g. they clicked
on "reply" to a post when not logged in). This is within the PHP code that handles the
website accounts. I did look at it before and thought I had fixed it, but when I
turned Cloudflare on for the site I found the login still broken.

I might have another look at this if we don't get progress in the next 24 hours.

Note that even if I fixed that and CF was turned on for the site, this only affects
web accesses. The NNTP, mail, DNS, ssh and other related servers will remain
inaccessible for those affected by Comcast.

> 2. Does the newsreader still work for everyone?  Thunderbird?

I use Thunderbird. It works, but only because I'm not affected by the routing issue.

> 3. I have noticed that a lot of services are causing problems for people who use
> older browsers.  When I am trying to read email or do other things outside of
> home, the service "flags" my connection as suspicious, since it can't identify
> my browser, or when it does, it associates "older browser" with some sort of
> potential bot attack.

How old is "older"?

-- Chris

[Bald Eagle] Re: povray.org and related sites unreachable to ... [37 days 18 hours and 25 minutes ago]

Sun, 15 Mar 2026 14:00:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> no IP addresses needed to change: our host only had to alter the appropriate BGP
announcement to indicate the new rou
te to/from our network.

No idea how this actually all works.
Is there some sort of BGP / website proxy thing that can serve as a functional
workaround?

> outgoing traffic that needs to pass through Comcast is black-holed only four hops
from our server. This means anyone 
who is behind Comcast addresses are unable to access anything on our server.
>
> We have used our class C network for more than a quarter of a century

1. I can (usually) use the website without issue from my primary desk at work.
However; when I move to the desk on the other side of the office (literally in
the same tiny room, maybe 6 feet away) I get the infinite spinny thing and no
connection.

2. Does the newsreader still work for everyone?  Thunderbird?

3. I have noticed that a lot of services are causing problems for people who use
older browsers.  When I am trying to read email or do other things outside of
home, the service "flags" my connection as suspicious, since it can't identify
my browser, or when it does, it associates "older browser" with some sort of
potential bot attack.

- BE

[Cousin Ricky] Re: povray.org and related sites unreachable to ... [38 days 5 hours and 45 minutes ago]

Sun, 15 Mar 2026 02:40:13 GMT

On 2026-03-14 14:44 (-4), Chris Cason wrote:
> 
> We're posting this message right now primarily to raise awareness
> amongst those who are not affected but are in communication with those
> who are (via means outside this site) to let them know why they can't
> connect, since of course affected users aren't able to read this message
> right now.

I have relayed your message to two POV-Ray-related Facebook groups.

[Ton] Re: povray.org and related sites unreachable to ... [38 days 9 hours and 30 minutes ago]

Sat, 14 Mar 2026 22:55:00 GMT

Wow. Thanks Chris.
One of the problems of modern times, juggling websites.

Cheers
Ton

[Chris Cason] povray.org and related sites unreachable to part... [38 days 13 hours and 39 minutes ago]

Sat, 14 Mar 2026 18:46:32 GMT

The datacenter in which the dedicated server hosting POV-Ray recently changed. As we
have our own class C (/24) subnet, this (in theory) should not have affected us
(outside of a few hours of downtime as the machine was physically transported) as no
IP addresses needed to change: our host only had to alter the appropriate BGP
announcement to indicate the new route to/from our network.

However it has since come to our attention that many parts of the internet are unable
to access resources on our server. Sites such as wiki.povray.org and www.irtc.org
continue to work as they are cached by Cloudflare, and Cloudflare can still talk to
our server. The problem lies in the fact that whilst we are receiving the incoming
traffic sent our way, outgoing traffic that needs to pass through Comcast is
black-holed only four hops from our server. This means anyone who is behind Comcast
addresses are unable to access anything on our server.

We have used our class C network for more than a quarter of a century with no real
issues; this is the first time we've been black-holed by a major transit point in the
US and we have no explanation for it. A request has been lodged with the Comcast NOC
to fix this but as of the time of writing it remains in place.

We're posting this message right now primarily to raise awareness amongst those who
are not affected but are in communication with those who are (via means outside this
site) to let them know why they can't connect, since of course affected users aren't
able to read this message right now.

Additionally once the issue is resolved, this will serve as an explanation as to why
we were "down" for so long.

regards,

-- Chris

[LanuHum] Re: Help: The normal map is not working [38 days 14 hours and 15 minutes ago]

Sat, 14 Mar 2026 18:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hello! I created a picture with a gradient. I want to use it as a height map for
> > a sphere. However, only gray stripes are visible on the sphere.
>
> That's because you're only perturbing the normal vectors on the smooth sphere to
> make the light reflect in different directions than it normally would, and so
> produce the illusion that there is a "texture" on the surface when there isn't.
>
> There are articles on the web and maybe a POV-Ray FAQ that show the shadows cast
> by objects that are really shaped that way vs a smooth object with a normal map.
>
> What you want to do is "surface displacement" where you actually change the
> geometry of the surface of your sphere.
>
> Luckily, myself, WFP, and Maetes have worked on this.
>
> Your best bet is to use whatever function makes your stripes to modulate the
> radius of your sphere so that those points have the actual height dictated by
> the function.
>
>
https://news.povray.org/povray.binaries.images/thread/%3C5f16dc29%40news.povray.org%3E/
>
>
https://news.povray.org/povray.advanced-users/thread/%3Cweb.67b47b18cb1bd5e34d0a98d30225ff5%40news.povray.org%3E/
>
> You can also look at Mike Williams' isosurface tutorial where he has several
> examples of using functions to change the surface of a sphere.
>
> Hope that helps.
>
> - BE

I understand. Thank you.

[Bald Eagle] Re: Help: The normal map is not working [38 days 19 hours and 55 minutes ago]

Sat, 14 Mar 2026 12:30:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hello! I created a picture with a gradient. I want to use it as a height map for
> a sphere. However, only gray stripes are visible on the sphere.

That's because you're only perturbing the normal vectors on the smooth sphere to
make the light reflect in different directions than it normally would, and so
produce the illusion that there is a "texture" on the surface when there isn't.

There are articles on the web and maybe a POV-Ray FAQ that show the shadows cast
by objects that are really shaped that way vs a smooth object with a normal map.

What you want to do is "surface displacement" where you actually change the
geometry of the surface of your sphere.

Luckily, myself, WFP, and Maetes have worked on this.

Your best bet is to use whatever function makes your stripes to modulate the
radius of your sphere so that those points have the actual height dictated by
the function.

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

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

You can also look at Mike Williams' isosurface tutorial where he has several
examples of using functions to change the surface of a sphere.

Hope that helps.

- BE

[LanuHum] Help: The normal map is not working [39 days 3 hours and 20 minutes ago]

Sat, 14 Mar 2026 05:05:00 GMT

Hello! I created a picture with a gradient. I want to use it as a height map for
a sphere. However, only gray stripes are visible on the sphere.

#version 3.7;
#include "shapes.inc"

global_settings {
    assumed_gamma 1.000000
    max_trace_level 3
    charset utf8
}
sky_sphere {
    pigment {rgb<0.051, 0.051, 0.051>}
}

#declare Default_texture = texture{pigment {rgb 0.8}}

#declare Material = texture{
    pigment{color srgbft <0.8000,0.8000,0.8000,0.0000,0.0000>}
    finish{
        diffuse 0.8000
        brilliance 1.8000
          }
}
#declare Material_001 = texture{
    pigment{color srgbft <0.8000,0.8000,0.8000,0.0000,0.0000>}
    normal{ bump_map{"/home/lanuhum/src/Thread_90.jpg" gamma 1.1000 map_type 0
interpolate 2 bump_size 5}
        translate <0.0000,0.0000,0.0000>
        rotate <0.0000,0.0000,0.0000>
        scale <1.0000,1.0000,1.0000>/1
        }
    finish{
        diffuse 0.8000
        brilliance 1.8000
          }
}
#declare data_Sphere_shape_ob = sphere { 0,1
    texture {Material_001}
    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>
}
#include "data_Cube_dec.inc"

object {data_Sphere_shape_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, 0.000000, 0.000000>
}
object {data_Cube_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, 0.000000, 0.000000>
}
light_source {
    <4.08,5.9,-1.01>
    color rgb<1, 1, 1>
    fade_distance 29.9999828339
    fade_power 1
}
camera {
    perspective
    location  <0,0,0>
    look_at  <0,0,-1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-26.440706, 46.691945, -0.000003>
    translate <7.481132, 5.343666, 6.507640>
}

[Leroy] Re: scheduled server down time [41 days 11 hours and 45 minutes ago]

Wed, 11 Mar 2026 20:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "BTW the POV-Ray server is being moved to its new data center tonight (7:30pm
> Eastern time, or about 5hr from now). It will be down at least a few hours. You
> may want to let folks know in the forum ..."
>
>
> regards, jr.

 I couldn't access the forum yesterday and when I got on today none of the new
messages showed. So I posted the Question 'POV server down?'. Of course when I
came back to the forum This message and others appeared.

Having Fun?

[LanuHum] Re: Help: How to create a bolt? [41 days 15 hours ago]

Wed, 11 Mar 2026 17:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> #version 3.8;
> global_settings {assumed_gamma 1.0 }
>
> camera {
>  location <0, 1, -3>
>  right x*image_width/image_height
>  up y
>  look_at <0, 1, 0>
> }
>
> light_source {<10, 20, -50> rgb 1}
> sky_sphere {pigment {rgb 1}}
>
>
> #declare TPI = 11; // (Threads per inch / TPI)
> #declare DM = 0.625/2;
> #declare Dm = 0.5167/2;
> #declare Angle = 60;
>
> #declare Pitch = 1/TPI;
> #declare CompAngle = 90-Angle;
> #declare Asin = atan(radians(CompAngle));
> #declare dx = DM - Dm;
> #declare dy = dx * Asin;
> #declare AL = 2*dy; // total Angled length
> #declare FL = (Pitch - AL)/2; // Flat length
>
> // Profile
> #declare P = array {
>       <Dm, 0, 0>,
>       <DM, dy, 0>,
>       <DM, dy+FL, 0>,
>       <Dm, dy+FL+dy, 0>,
>       <Dm, dy+FL+dy+FL, 0>
> }
>
> #declare OldPoint = array[5][3];
> #declare NewPoint = array[5][3];
>
> #macro MakeBoltProfile (Pitch,Steps, Tex, Copies)
>       #local Increment = tau/Steps;
>       #local Unit =
>       union {
>       #for (Theta, 0, tau, Increment)
>
>             #for (Pt, 0, 4)
>             #declare NewPoint[Pt][0] = P[Pt].x * cos (Theta);
>             #declare NewPoint[Pt][1] = P[Pt].y + Pitch * Theta/tau;
>             #declare NewPoint[Pt][2] = P[Pt].x * sin (Theta);
>             #end
>
>             #if (Theta > 0)
>             #for (T, 0, 3)
>                   triangle {<OldPoint[T][0], OldPoint[T][1], OldPoint[T][2]>,
>                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
>                         <OldPoint[T+1][0], OldPoint[T+1][1], OldPoint[T+1][2]>
>                   }
>                   triangle {<OldPoint[T+1][0], OldPoint[T+1][1],
> OldPoint[T+1][2]>,
>                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
>                         <NewPoint[T+1][0], NewPoint[T+1][1], NewPoint[T+1][2]>
>                   }
>             #end
>           #end
>
>             #declare OldPoint = NewPoint;
>       #end
>       texture {Tex}
>       }
>       #for (C, 1, Copies)
>             object {Unit translate y*Pitch*C*1}
>       #end
> #end
>
> #declare MyTex = texture {pigment {rgb 0.9} finish {specular 0.4 reflection
> 0.01}}
>
> MakeBoltProfile (Pitch, 72, MyTex, 25)

Thank you so much. I have no more questions about the topic.

[Bald Eagle] Re: scheduled server down time [41 days 18 hours and 50 minutes ago]

Wed, 11 Mar 2026 13:35:00 GMT

> "BTW the POV-Ray server is being moved to its new data center tonight (7:30pm
> Eastern time, or about 5hr from now). It will be down at least a few hours. You
> may want to let folks know in the forum ..."

And how did that all go?
Where is this "new data center"?

[Bald Eagle] Re: Help: How to create a bolt? [42 days 10 hours and 55 minutes ago]

Tue, 10 Mar 2026 21:30:00 GMT

#version 3.8;
global_settings {assumed_gamma 1.0 }

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

light_source {<10, 20, -50> rgb 1}
sky_sphere {pigment {rgb 1}}


#declare TPI = 11; // (Threads per inch / TPI)
#declare DM = 0.625/2;
#declare Dm = 0.5167/2;
#declare Angle = 60;

#declare Pitch = 1/TPI;
#declare CompAngle = 90-Angle;
#declare Asin = atan(radians(CompAngle));
#declare dx = DM - Dm;
#declare dy = dx * Asin;
#declare AL = 2*dy; // total Angled length
#declare FL = (Pitch - AL)/2; // Flat length

// Profile
#declare P = array {
      <Dm, 0, 0>,
      <DM, dy, 0>,
      <DM, dy+FL, 0>,
      <Dm, dy+FL+dy, 0>,
      <Dm, dy+FL+dy+FL, 0>
}

#declare OldPoint = array[5][3];
#declare NewPoint = array[5][3];

#macro MakeBoltProfile (Pitch,Steps, Tex, Copies)
      #local Increment = tau/Steps;
      #local Unit =
      union {
      #for (Theta, 0, tau, Increment)

            #for (Pt, 0, 4)
            #declare NewPoint[Pt][0] = P[Pt].x * cos (Theta);
            #declare NewPoint[Pt][1] = P[Pt].y + Pitch * Theta/tau;
            #declare NewPoint[Pt][2] = P[Pt].x * sin (Theta);
            #end

            #if (Theta > 0)
            #for (T, 0, 3)
                  triangle {<OldPoint[T][0], OldPoint[T][1], OldPoint[T][2]>,
                        <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
                        <OldPoint[T+1][0], OldPoint[T+1][1], OldPoint[T+1][2]>
                  }
                  triangle {<OldPoint[T+1][0], OldPoint[T+1][1],
OldPoint[T+1][2]>,
                        <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
                        <NewPoint[T+1][0], NewPoint[T+1][1], NewPoint[T+1][2]>
                  }
            #end
          #end

            #declare OldPoint = NewPoint;
      #end
      texture {Tex}
      }
      #for (C, 1, Copies)
            object {Unit translate y*Pitch*C*1}
      #end
#end

#declare MyTex = texture {pigment {rgb 0.9} finish {specular 0.4 reflection
0.01}}

MakeBoltProfile (Pitch, 72, MyTex, 25)

[LanuHum] Re: Help: How to create a bolt? [42 days 13 hours and 10 minutes ago]

Tue, 10 Mar 2026 19:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I'm trying to understand: you're trying to model this in POV-Ray or Blender?
> - BE

Blender draws its own objects, but when exporting, I can replace the mesh with a
isosurface.

[LanuHum] Re: Help: How to create a bolt? [42 days 13 hours and 20 minutes ago]

Tue, 10 Mar 2026 19:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
>
> > Create that bolt in the blender for the entire scene, select the render Cycles,
> > set the output image size to 38400x21600 and count the seconds until the
> > computer dies.
>
>
> > Thanks. The best option for me is this:
> >
> > isosurface {
>
> So, I'm trying to understand: you're trying to model this in POV-Ray or Blender?
>

>
> - BE

I am a member of the Pov@Ble project. Create a scene in Blender and export it to
a .pov file. Right now I'm trying to create a very heavy scene that the GPU
won't be able to calculate. That's why I'm talking about the size of the output
image of 50-100!!! 4k monitors.

[Bald Eagle] Re: Help: How to create a bolt? [42 days 15 hours and 25 minutes ago]

Tue, 10 Mar 2026 17:00:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:

> Create that bolt in the blender for the entire scene, select the render Cycles,
> set the output image size to 38400x21600 and count the seconds until the
> computer dies.

> Thanks. The best option for me is this:
>
> isosurface {

So, I'm trying to understand: you're trying to model this in POV-Ray or Blender?

A helix is a fairly simple thing to model, and you could make one with the exact
profile that you want by creating a mesh with smooth triangles.

The basic helix is:
X = radius * cos (T);
Y = B * T;
Z = radius * sin (T);

And you just sort of model the profile, spin it a bit, and make quads that you
split into triangles. If you go around once, you can probably just make that one
small mesh and union {} together a string of them.

- BE

[LanuHum] Re: Help: How to create a bolt? [42 days 15 hours and 50 minutes ago]

Tue, 10 Mar 2026 16:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "To create threads in Blender, enable the built-in "Bolt Factory" add-on in Edit
> > Preferences > Add-ons. Once active, press Shift+A, select Mesh, and choose
> Bolt to generate customizable threaded bolts or nuts. Adjust settings like
> Major/Minor Pitch for size and Crest/Root for shape."
>
> - BE

Create that bolt in the blender for the entire scene, select the render Cycles,
set the output image size to 38400x21600 and count the seconds until the
computer dies.

[LanuHum] Re: Help: How to create a bolt? [42 days 16 hours ago]

Tue, 10 Mar 2026 16:25:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> >
> > Thank you. I understand macros very poorly, but I can create a spiral from a
> > sphere_sweep. Then subtract the spiral from the cylinder. But, I want to achieve
> > a realistic profile.
>
> Either of the isosurface solutions Robert Munyer and I posted would satisfy this
> profile.
>
> https://news.povray.org/5eec257c%241%40news.povray.org
> https://news.povray.org/875zph8073.fsf%40munyer.com

Thanks. The best option for me is this:

isosurface { //-------------------------------------------------------------
  function{
     f_helix1(
        x,y,z,
        1,    // number of helixes, (1 = single helix, 2 = double helix etc.)
        44,   // period,      turns on the length of 2*pi
        0.07, // minor radius,
        0.8, // major radius,
        1,    // shape parameter,
        0.3,  // cross section type, (0.0 to 1.0 = square ... rounded to circle
              //                 over 2.0 to 3.0 = rounded to diamond and
concave diamond
        45     // cross section rotation angle
      )
  }
 contained_by {box {<-1,-1,-1>,<1,1,1>}}
 max_gradient 8

 texture{ pigment{ color rgb <1,0.9,0.5>}
          finish {specular 0.1 roughness 0.1 phong 0.2}
        }

} // end of isosurface -------------------------------------------------------

Proper geometry with a radius on the edge and little text.
Mr, this needs to be added to the Pov@ble Blender addon : Menu Add/ Povray
shapes / Add Thread/  )))

[Bald Eagle] Re: Help: How to create a bolt? [42 days 16 hours and 25 minutes ago]

Tue, 10 Mar 2026 16:00:00 GMT

"To create threads in Blender, enable the built-in "Bolt Factory" add-on in Edit
> Preferences > Add-ons. Once active, press Shift+A, select Mesh, and choose
Bolt to generate customizable threaded bolts or nuts. Adjust settings like
Major/Minor Pitch for size and Crest/Root for shape."

- BE

[LanuHum] Re: Help: How to create a bolt? [42 days 16 hours and 35 minutes ago]

Tue, 10 Mar 2026 15:50:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Why do you mention low poly? it's non-mesh... also the heightfield is used only
> for the head, which you don't need.
> But anyway many other answers before I mentioned Jaime's offer other non-mesh
> alternatives so by now, you end up having too many options, so you need more
> time to just pick one of them :-P The scene will be awesome!

My dear friend, I need a version that will be included in our Pov@ble addon. You
have to understand that I'm not going to write a pov file with my hands, but I'm
going to get it from a blender.

[Cousin Ricky] Re: Help: How to create a bolt? [42 days 17 hours and 30 minutes ago]

Tue, 10 Mar 2026 14:55:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
>
> Thank you. I understand macros very poorly, but I can create a spiral from a
> sphere_sweep. Then subtract the spiral from the cylinder. But, I want to achieve
> a realistic profile.

Either of the isosurface solutions Robert Munyer and I posted would satisfy this
profile.

https://news.povray.org/5eec257c%241%40news.povray.org
https://news.povray.org/875zph8073.fsf%40munyer.com

[Mr] Re: Help: How to create a bolt? [42 days 19 hours and 35 minutes ago]

Tue, 10 Mar 2026 12:50:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > "LanuHum" <Lan### [at] yandexru> wrote:
> > > Hi! I am interested in the question: is it possible to create a thread without a
> > > mesh of triangles? We need a smooth surface of the thread in the picture
> > > 38400x21600 (4K * 10)
> >
> > Hi, Also, though it may be less physically accurate with respect to its
> > geometry,
> > this scene on Jaime Vives Piqueres site still works out of the box and features
> > a nice lighting and composition setup:
> > http://ignorancia.org/uploads/zips/boltstill.zip
> > ....If you just drop all of the lightsys macro files within the same folder :
> > http://ignorancia.org/uploads/zips/lightsys4b.zip
>
> Hi! Thanks, I saw a height_field in the file. This is a bad decision for my
> purpose. Scattering media with photons example + drum kit. 2 Up pictures from
> documentation and demo scenes. I want to create a real scene based on two
> examples from the documentation. The camera will be in different locations. In
> some cases, this spiral thread will be perfectly visible.I need clear, smooth
> lines with no signs of a low-poly gamedev.

Why do you mention low poly? it's non-mesh... also the heightfield is used only
for the head, which you don't need.
But anyway many other answers before I mentioned Jaime's offer other non-mesh
alternatives so by now, you end up having too many options, so you need more
time to just pick one of them :-P The scene will be awesome!

[LanuHum] Re: Help: How to create a bolt? [43 days 13 hours and 50 minutes ago]

Mon, 9 Mar 2026 18:35:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hi! I am interested in the question: is it possible to create a thread without a
> > mesh of triangles? We need a smooth surface of the thread in the picture
> > 38400x21600 (4K * 10)
>
> Hi, Also, though it may be less physically accurate with respect to its
> geometry,
> this scene on Jaime Vives Piqueres site still works out of the box and features
> a nice lighting and composition setup:
> http://ignorancia.org/uploads/zips/boltstill.zip
> ....If you just drop all of the lightsys macro files within the same folder :
> http://ignorancia.org/uploads/zips/lightsys4b.zip

Hi! Thanks, I saw a height_field in the file. This is a bad decision for my
purpose. Scattering media with photons example + drum kit. 2 Up pictures from
documentation and demo scenes. I want to create a real scene based on two
examples from the documentation. The camera will be in different locations. In
some cases, this spiral thread will be perfectly visible.I need clear, smooth
lines with no signs of a low-poly gamedev.

[jr] scheduled server down time [43 days 14 hours and 5 minutes ago]

Mon, 9 Mar 2026 18:20:00 GMT

hi,

"BTW the POV-Ray server is being moved to its new data center tonight (7:30pm
Eastern time, or about 5hr from now). It will be down at least a few hours. You
may want to let folks know in the forum ..."


regards, jr.

[LanuHum] Re: Help: How to create a bolt? [43 days 14 hours and 45 minutes ago]

Mon, 9 Mar 2026 17:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > "LanuHum" <Lan### [at] yandexru> wrote:
> > > Hi! I am interested in the question: is it possible to create a thread
> > > without a mesh of triangles?
>
> "Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> > https://news.povray.org/5eec257c%241%40news.povray.org
>
> There is also this thread:
>
http://news.povray.org/povray.general/thread/%3Cweb.64ff068eb373d57cf00fef66b571e5b2%40news.povray.org%3E/
>
> Always do a search for "prior art" when trying to accomplish a task.
> "povray screw threads" or similar.
>
> I'm sure there are several similar projects in the newsgroups - I know that I
> have modeled screw threads and drill bits, and other helical shapes in the past.
>
> - BE

Thanks. I tried to search, but immediately the word spiral thread is associated
with the hyper threads of a computer processor. )))

[Mr] Re: Help: How to create a bolt? [43 days 23 hours and 45 minutes ago]

Mon, 9 Mar 2026 08:40:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hi! I am interested in the question: is it possible to create a thread without a
> mesh of triangles? We need a smooth surface of the thread in the picture
> 38400x21600 (4K * 10)

Hi, Also, though it may be less physically accurate with respect to its
geometry,
this scene on Jaime Vives Piqueres site still works out of the box and features
a nice lighting and composition setup:
http://ignorancia.org/uploads/zips/boltstill.zip
....If you just drop all of the lightsys macro files within the same folder :
http://ignorancia.org/uploads/zips/lightsys4b.zip

[Bald Eagle] Re: Help: How to create a bolt? [44 days 18 hours and 25 minutes ago]

Sun, 8 Mar 2026 14:00:00 GMT

> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hi! I am interested in the question: is it possible to create a thread
> > without a mesh of triangles?

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> https://news.povray.org/5eec257c%241%40news.povray.org

There is also this thread:
http://news.povray.org/povray.general/thread/%3Cweb.64ff068eb373d57cf00fef66b571e5b2%40news.povray.org%3E/

Always do a search for "prior art" when trying to accomplish a task.
"povray screw threads" or similar.

I'm sure there are several similar projects in the newsgroups - I know that I
have modeled screw threads and drill bits, and other helical shapes in the past.

- BE

[LanuHum] Re: Help: How to create a bolt? [45 days 2 hours and 40 minutes ago]

Sun, 8 Mar 2026 05:45:00 GMT

"Jeff Reifel" <jef### [at] gmailcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hi! I am interested in the question: is it possible to create a thread without a
> > mesh of triangles? We need a smooth surface of the thread in the picture
> > 38400x21600 (4K * 10)
>
>
> Here is a simple idea.
> #declare i=0;
> #while(i<18 )
> cone{0,.5,y*-.5,0 translate < .4,-2>  rotate y*360*i translate -y*i*.5
> pigment{blue 1}}
>  cone{0,.5,y*.5,0 translate <.4,-2>  rotate y*360*i translate -y*i*.5
> pigment{red 1}}
> #declare step=.01 ;
> #declare i=i+step;
> #end   translate <0,9,0>}

Thanks, it's a good idea, but for a big picture you need to increase the number
of steps many times. Otherwise, defects are visible :(

[LanuHum] Re: Help: How to create a bolt? [45 days 3 hours and 5 minutes ago]

Sun, 8 Mar 2026 05:20:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> function{
>       f_helix1(
>          x,y,z,
>          1,    // number of helixes, (1 = single helix, 2 = double helix
> etc.)
>          22,   // period,      turns on the length of 2*pi
>          0.07, // minor radius,
>          0.80, // major radius,
>          1,    // shape parameter,
>          0.3,  // cross section type, (0.0 to 1.0 = square ... rounded
> to circle
>                //     over 2.0 to 3.0 = rounded to diamond and concave
> diamond
>          0     // cross section rotation angle
>        )
>    }
>
> The last parameter «cross section rotation angle» is the rotation of the
> shape in degree.
>
> The 9th parameter let you change the shape.

The 9th parameter. I'm distracted.  I turned 90 degrees and saw no change. ))) I
should have been 45!!! Thank you so much!!!

[Jeff Reifel] Re: Help: How to create a bolt? [45 days 8 hours and 15 minutes ago]

Sun, 8 Mar 2026 00:10:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hi! I am interested in the question: is it possible to create a thread without a
> mesh of triangles? We need a smooth surface of the thread in the picture
> 38400x21600 (4K * 10)


Here is a simple idea.
#declare i=0;
#while(i<18 )
cone{0,.5,y*-.5,0 translate < .4,-2>  rotate y*360*i translate -y*i*.5
pigment{blue 1}}
 cone{0,.5,y*.5,0 translate <.4,-2>  rotate y*360*i translate -y*i*.5
pigment{red 1}}
#declare step=.01 ;
#declare i=i+step;
#end   translate <0,9,0>}

[Alain Martel] Re: Help: How to create a bolt? [45 days 8 hours and 54 minutes ago]

Sat, 7 Mar 2026 23:31:29 GMT

Le 2026-03-07 Ã  11:17, jr a Ã©critÂ :
> hi,
> 
> "LanuHum" <Lan### [at] yandexru> wrote:
>> Wow. I found a rectangular thread in the documentation
> 
> nice.  as I said, I've no maths, but if that profile can be rotated by 45
> degrees..
> 
> 
> regards, jr.
> 
function{
      f_helix1(
         x,y,z,
         1,    // number of helixes, (1 = single helix, 2 = double helix 
etc.)
         22,   // period,      turns on the length of 2*pi
         0.07, // minor radius,
         0.80, // major radius,
         1,    // shape parameter,
         0.3,  // cross section type, (0.0 to 1.0 = square ... rounded 
to circle
               //     over 2.0 to 3.0 = rounded to diamond and concave 
diamond
         0     // cross section rotation angle
       )
   }

The last parameter Â«cross section rotation angleÂ» is the
rotation of the 
shape in degree.

The 9th parameter let you change the shape.

[Cousin Ricky] Re: Help: How to create a bolt? [45 days 15 hours and 20 minutes ago]

Sat, 7 Mar 2026 17:05:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hi! I am interested in the question: is it possible to create a thread without a
> mesh of triangles? We need a smooth surface of the thread in the picture
> 38400x21600 (4K * 10)

https://news.povray.org/5eec257c%241%40news.povray.org

[jr] Re: Help: How to create a bolt? [45 days 16 hours and 5 minutes ago]

Sat, 7 Mar 2026 16:20:00 GMT

hi,

"LanuHum" <Lan### [at] yandexru> wrote:
> Wow. I found a rectangular thread in the documentation

nice.  as I said, I've no maths, but if that profile can be rotated by 45
degrees..


regards, jr.

[LanuHum] Re: Help: How to create a bolt? [45 days 16 hours and 15 minutes ago]

Sat, 7 Mar 2026 16:10:00 GMT

Wow. I found a rectangular thread in the documentation
povray-3.8/scenes/templates/Isosurfaces_by_function_inc/6a_Iso_f_helix1.txt

[LanuHum] Re: Help: How to create a bolt? [45 days 16 hours and 40 minutes ago]

Sat, 7 Mar 2026 15:45:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "LanuHum" <Lan### [at] yandexru> wrote:
> > ...
> > > S Benge posted a macro ...
> > Thank you. I understand macros very poorly, but I can create a spiral from a
> > sphere_sweep. Then subtract the spiral from the cylinder.
>
> (I don't even have the maths to do those "from scratch" :-))
>
>
> > But, I want to achieve a realistic profile.
>
> multiple passes with an increasing (sphere) diameter, from the lowest, smallest,
> upwards, is the "crude", naive way I'd try for an approximation.  perhaps the
> spiral itself can be created/shaped with a useful-to-you profile ?
>
>
> regards, jr.

Yes. Thanks. I assumed that maybe there is a function.

object Tread = isosurface {
  function  {bla...bla...bla}}

They told me a long time ago that the mesh is the dark side. But parametric
formulas are good and joyful. However, the developers did not find the formula
for the thread.

[jr] Re: Help: How to create a bolt? [45 days 19 hours and 50 minutes ago]

Sat, 7 Mar 2026 12:35:00 GMT

hi,

"LanuHum" <Lan### [at] yandexru> wrote:
> ...
> > S Benge posted a macro ...
> Thank you. I understand macros very poorly, but I can create a spiral from a
> sphere_sweep. Then subtract the spiral from the cylinder.

(I don't even have the maths to do those "from scratch" :-))

> But, I want to achieve a realistic profile.

multiple passes with an increasing (sphere) diameter, from the lowest, smallest,
upwards, is the "crude", naive way I'd try for an approximation.  perhaps the
spiral itself can be created/shaped with a useful-to-you profile ?

regards, jr.

[LanuHum] Re: Help: How to create a bolt? [45 days 21 hours and 25 minutes ago]

Sat, 7 Mar 2026 11:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Hi! I am interested in the question: is it possible to create a thread without a
> > mesh of triangles? We need a smooth surface of the thread in the picture
> > 38400x21600 (4K * 10)
>
> S Benge posted a macro which "To model a bolt or auger, you could use
> t_coil_solid to cut grooves into a cylinder".  hth.
>
>
<news.povray.org/povray.binaries.images/thread/%3C4c3fee0a%40news.povray.org%3E/?ttop=446838&toff=2350>
>
>
> regards, jr.

Thank you. I understand macros very poorly, but I can create a spiral from a
sphere_sweep. Then subtract the spiral from the cylinder. But, I want to achieve
a realistic profile.

[jr] Re: Help: How to create a bolt? [45 days 23 hours and 15 minutes ago]

Sat, 7 Mar 2026 09:10:00 GMT

hi,

"LanuHum" <Lan### [at] yandexru> wrote:
> Hi! I am interested in the question: is it possible to create a thread without a
> mesh of triangles? We need a smooth surface of the thread in the picture
> 38400x21600 (4K * 10)

S Benge posted a macro which "To model a bolt or auger, you could use
t_coil_solid to cut grooves into a cylinder".  hth.

<news.povray.org/povray.binaries.images/thread/%3C4c3fee0a%40news.povray.org%3E/?ttop=446838&toff=2350>


regards, jr.

[LanuHum] Help: How to create a bolt? [46 days 1 hour and 15 minutes ago]

Sat, 7 Mar 2026 07:10:00 GMT

Hi! I am interested in the question: is it possible to create a thread without a
mesh of triangles? We need a smooth surface of the thread in the picture
38400x21600 (4K * 10)

[Guillermo Espitia] Re: Line numbering [48 days 10 hours and 55 minutes ago]

Wed, 4 Mar 2026 21:30:13 GMT

El 4/03/2026 a las 3:31 p.Â m., Bald Eagle escribiÃ³:
> Guillermo Espitia <gui### [at] gmailcom> wrote:
>> Hello. Is it possible to configure Povray 3.7 so that the line numbering
>> in the editor is not temporary?
> 
> Not that I'm aware of.
> The editor is a Windows thing, not an actual POV-Ray thing, and this has been a
> long standing issue/complaint.
> 
> The best recommendation is use an external editor and command-line interface to
> have POV-Ray render that file once saved.
> 
> - BE
> 
Thanks for the suggestion. Good day.

-- 
Este correo electrÃ³nico ha sido analizado en busca de virus por el software
antivirus de Avast.
www.avast.com

[Bald Eagle] Re: Strange syntax [48 days 11 hours ago]

Wed, 4 Mar 2026 21:25:00 GMT

From:
https://math.hws.edu/eck/cs324/s01/pov-doc/pov171.htm

Operator Promotion
You may use a lone float expression to define a vector whose components are all
the same. POV-Ray knows when it needs a vector of a particular type and will
promote a float into a vector if need be. For example the POV-Ray scale
statement requires a three component vector. If you specify scale 5 then POV-Ray
interprets this as scale <5,5,5> which means you want to scale by 5 in every
direction.

Versions of POV-Ray prior to 3.0 only allowed such use of a float as a vector in
various limited places such as scale and turbulence. However you may now use
this trick anywhere. For example...

 box{0,1}  // Same as box{<0,0,0>,<1,1,1>}

 sphere{0,1} // Same as sphere{<0,0,0>,1}
When promoting a float into a vector of 2, 3, 4 or 5 components, all components
are set to the float value, however when promoting a vector of a lower number of
components into a higher order vector, all remaining components are set to zero.
For example if POV-Ray expects a 4D vector and you specify 9 the result is
<9,9,9,9> but if you specify <7,6> the result is <7,6,0,0>.

[Bald Eagle] Re: Line numbering [48 days 11 hours and 50 minutes ago]

Wed, 4 Mar 2026 20:35:00 GMT

Guillermo Espitia <gui### [at] gmailcom> wrote:
> Hello. Is it possible to configure Povray 3.7 so that the line numbering
> in the editor is not temporary?

Not that I'm aware of.
The editor is a Windows thing, not an actual POV-Ray thing, and this has been a
long standing issue/complaint.

The best recommendation is use an external editor and command-line interface to
have POV-Ray render that file once saved.

- BE

[Guillermo Espitia] Line numbering [48 days 13 hours and 5 minutes ago]

Wed, 4 Mar 2026 19:19:47 GMT

Hello. Is it possible to configure Povray 3.7 so that the line numbering 
in the editor is not temporary?

G

-- 
Este correo electrÃ³nico ha sido analizado en busca de virus por el sof
tware antivirus de Avast.
www.avast.com

[Bald Eagle] Re: Strange syntax [48 days 14 hours and 20 minutes ago]

Wed, 4 Mar 2026 18:05:00 GMT

A few more breadcrumbs from the source code.
- BE

https://github.com/POV-Ray/povray/blob/master/source/parser/parser_expressions.cpp

Starting at Line 1340:

/* Promote_Express promotes Express to the requested number of terms.  If
   *Old_Terms==1, then it sets all terms to Express[0].  Otherwise, it pads
   extra terms with 0.0.

   To maximize the consistency of results, DO NOT promote until it is actually
   required.  This is to ensure, as much as possible, that the same expression
   will produce the same results regardless of the context.
*/

void Parser::Promote_Express(EXPRESS& Express,int *Old_Terms,int New_Terms)
{
    int i;

    if (*Old_Terms >= New_Terms)
        return;

    if (*Old_Terms==1)
    {
        for(i=1;i<New_Terms;i++)
        {
            Express[i]=Express[0];
        }
    }
    else
    {
        for(i=(*Old_Terms);i<New_Terms;i++)
        {
            Express[i]=0.0;
        }
    }

    *Old_Terms=New_Terms;
}

Then, if I'm correctly inferring the meaning at Line 1581:

void Parser::Parse_Rel_Term (EXPRESS& Express,int *Terms)

this must involve the "relational operator" which I'm assuming is whatever is in
between the parentheses of a comparison)

and further down starting at line 1623:

        CASE (EQUALS_TOKEN)
            Parse_Rel_Factor(Local_Express,&Local_Terms);
            Promote_Express(Express,Terms,Local_Terms);

            for(i=0;i<*Terms;i++)
                Express[i] = (DBL)(!FTRUE(Express[i]-Local_Express[i]));
        END_CASE





Further down in the file there is the code with the light source warning
(It's actually a large block of vector code starting at line 2028)

        CASE_VECTOR_UNGET
            if (startedParsing)
            {
                EXIT
            }
            else
            {
                // Note: Setting up for potential warning on single value float
promote to
                // five value color vector. Any single float will be promoted to
the full
                // 'tgtTerms' value. This usually results in filter and transmit
values >0,
                // which caused shadow artifacts back to at least version
v3.6.1.
                if ((CurrentCategorizedTokenId() == FLOAT_TOKEN_CATEGORY) ||
(CurrentTrueTokenId() == FUNCT_ID_TOKEN))
                    sawFloatOrFloatFnct = true;
                else
                    sawFloatOrFloatFnct = false;
                if (expectFT)
                    tgtTerms = 5;
                else
                    tgtTerms = 3;
                Parse_Express(Express,&Terms);
                Promote_Express(Express,&Terms,tgtTerms);
                if (expectFT && (Terms != 5))
                    Error("Color expression expected but float or vector
expression found.");
                else if (!expectFT && ((Terms < 3) || Terms > 5))
                    Error("RGB color expression expected but float or vector
expression found.");
                colour.Set(Express, Terms);
                if (((sawFloatOrFloatFnct) && (Terms==5)) && ((colour.filter()
!= 0) && (colour.transm() != 0)))
                    Warning("Float value promoted to full color vector where
both filter and transmit >0.0.");
                if (!expectFT && ((colour.filter() != 0) || (colour.transm() !=
0)))
                    Warning("Expected pure RGB color expression, unexpected
filter and transmit components will have no effect.");
                startedParsing = true;
            }
        END_CASE

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl... [53 days 11 hours and 30 minutes ago]

Fri, 27 Feb 2026 20:55:00 GMT

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

> Those are shapes

Oh.   :D

Hoping my newest code fixes all of that wrongly oriented stuff.

Thanks for looking again.

- BE

[William F Pokorny] Re: Inexplicably bad lighting in otherwise simpl... [53 days 11 hours and 52 minutes ago]

Fri, 27 Feb 2026 20:33:01 GMT

On 2/27/26 14:12, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Bill W, This morning I got around to running the scene you sent to me -
>> thanks.
> 
> Thanks for taking the time to render and look it over.
> 
> The weird thing about the shadows dead center of the image is that they are a
> dead-flat gray, and _completely blot out the tori_!
> 
> Maybe it's just me, but that seems weird.
> 
> - BE
> 

Those are shapes - see the attached image where I turned the light 
source 'shadowless' and added 'cutaway_textures' to the difference{}. 
Rendered using my v3.8 beta 2 compile.

The only shadow issues I noticed (ignoring the center yellow shape 
issue) was that your posted image had noise in the upper left of the 
overall shape where my local build's render did not.

Bill P.

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl... [53 days 13 hours and 10 minutes ago]

Fri, 27 Feb 2026 19:15:00 GMT

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

> Bill W, This morning I got around to running the scene you sent to me -
> thanks.

Thanks for taking the time to render and look it over.

The weird thing about the shadows dead center of the image is that they are a
dead-flat gray, and _completely blot out the tori_!

Maybe it's just me, but that seems weird.

- BE

[Bald Eagle] Re: Strange syntax [53 days 17 hours and 15 minutes ago]

Fri, 27 Feb 2026 15:10:00 GMT

I wanted to dig in a bit deeper to discover why scalar 1 gets promoted to <1, 0,
0, 0, 0, 0> instead of <1, 1, 1, 1, 1>.

Something clever that I noticed in the response was using vdot (V, V) as a way
to "count" the number of components in the vector (assuming they are all 1).
I will have to play with this idea.
Is there a way to normalize all the components of a vector without knowing how
many components there are?


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

AI response:
Because of how POV‑Ray’s parser “types” expressions and encodes
boolean
results: the equality operator = produces a scalar (0/1). If that scalar is then
required to participate in a 5‑component colour/vector context higher up
the expression tree, the parser embeds the scalar into a 5‑component
register by placing it in the first component only and zeroing the rest—yielding
<1,0,0,0,0> rather than <1,1,1,1,1>. This is distinct from the general “operator
promotion” rule you’re thinking of (float → vector), which does
replicate
a float across all components, but it does not apply to boolean results of
comparisons. [github.com], [math.hws.edu]

What’s going on in detail


Equality is scalar
In POV‑Ray SDL, A = B is a comparison with a scalar truth value (1 for
true, 0 for false). It’s not a vectorized comparison unless you explicitly build
one. Internally the expression evaluator carries results in a small fixed array
(“EXPRESS”) and tracks how many components are “live”. For
comparisons, the live
count is 1. [github.com]


Type/arity is decided by surrounding context
When that scalar result is used where a vector/colour is expected, the parser
promotes it to the needed arity. There are two different promotion paths in the
language implementation:




General operator promotion (float → N‑vector), described in the
reference manual: a lone float can be promoted to a vector of 2/3/4/5 components
by replicating the same value into all components (e.g., 5 → <5,5,5> when
a 3‑vector is needed). This rule applies when a float literal/expression
itself is being used as a vector. [math.hws.edu]


Embedding of boolean/scalar results into multi‑component registers that
occurs inside the expression parser for comparison/logical operations. For
these, the parser stores the truth value in component 0 and clears the
remainder, producing <1,0,0,0,0> if the surrounding context expects a
5‑component value (as happens in colour/5‑term vector contexts).
This is why you observe <1,0,0,0,0> instead of <1,1,1,1,1>. You can see the
relevant behavior in the expression parser implementation (comparison handling
and result packing) in parser_expressions.cpp. [github.com]



Colour (5‑term) contexts are common
Any time an expression is in a colour context (e.g., inside pigment { … } where
colours are 5‑component vectors: rgbft), the arity is 5. The documentation
explains that colour expressions have 5 components—<red, green, blue, filter,
transmit>—and that unspecified filter and transmit default to 0. That’s why
a
non‑colour scalar promoted into a colour context naturally becomes
something shaped like <value, 0, 0, 0, 0> when it comes from a boolean
comparison result. [povray.org], [museum.state.il.us]


Why this differs from “the usual” float→vector promotion
The “replicate to all components” rule is the Operator Promotion rule that
applies when a numeric float is directly promoted to an N‑vector (e.g.,
scale 5 → scale <5,5,5>). That rule does not override how
boolean/comparison results are packaged internally by the parser. So:

1 used as a colour literal where replication is needed: <1,1,1,1,1> (general
promotion). [math.hws.edu]
( <1,1,1> = 1 ) used where a colour is required: comparison yields scalar 1
first → then embedded as <1,0,0,0,0> (boolean embedding). [github.com]


How to get “uniform ones” if that’s what you want
If you need a vector/colour mask of ones after a comparison, build it
explicitly, e.g.:
Plain Textpov isn’t fully supported. Syntax highlighting is based on Plain
Text.#declare V = <1,1,1>;#declare M = (vdot(V, V) = 3 ? <1,1,1,1,1> :
<0,0,0,0,0>); // example of explicit replicationShow more lines
or use arithmetic to replicate the scalar result across components before the
colour context forces 5D:
Chart.js#declare B = (<1,1,1> = 1);     // scalar 0/1#declare M = B *
<1,1,1,1,1>;   // replicate into all 5 lanesShow more lines
(Here the multiplication forces general operator promotion on the float B to a
5‑vector, giving <B,B,B,B,B>.) [math.hws.edu]

If you’d like, I can step into the exact branch of parser_expressions.cpp that
handles = and point to the code paths that set only the first component on
boolean results—just say which POV‑Ray branch/commit you’re building
(3.7,
3.8 alpha, or master). [github.com]


The relevant code in the parser
1) The expression result container and the “truth” macro
POV‑Ray’s expression parser carries intermediate values in a small fixed
array (EXPRESS) plus an integer “arity” (number of live components). It also
defines an epsilon‑based predicate to turn floats into boolean truth
values. You can see both patterns in the current file and its 3.7 predecessor:


// parser_expressions.cpp
#define FTRUE (f) ( (int) (fabs (f)>EPSILON))



This is used throughout the numeric/logic code paths whenever a boolean is
needed. [github.com]
Internally, results are stored as an EXPRESS (a fixed array of DBL) with a
“Terms” count. A number of functions show this pattern; for example, the
float-parameter helper rejects multi‑term results by checking Terms>1:


DBL Parser::Parse_Float_Param ()
{
    DBL Local;
    EXPRESS Express;
    int Terms;
    bool old_allow_id = Allow_Identifier_In_Call;
    Allow_Identifier_In_Call = false;

    Parse_Paren_Begin ();
    Parse_Express (Express,&Terms);
    if (Terms>1)
    {
        Error ("Float expected but vector or color expression found.");
    }
    Local = Express [0];
    Parse_Paren_End ();
    Allow_Identifier_In_Call = old_allow_id;
    return (Local);
}



This shows the (values, arity) representation: Express[0..Terms-1] is the
payload; the scalar case is Terms == 1. [github.com]
You can see the same scheme in the 3.7 code (express.cpp) as well.
[bugs.povray.org]
2) Places that set the arity
Whenever a vector-returning construct is parsed (e.g., a vector function call),
the parser explicitly writes multiple lanes into Express[...] and sets the
arity:


void Parser::Parse_Vector_Function_Call(EXPRESS Express, int *Terms)
{
    // ... call into VM ...
    for (param = 0; param < f->return_size; param++)
        Express[param] = fnVMContext->GetLocal(param);
    *Terms = f->return_size;  // <-- explicit arity for vector returns
}



That “Terms is the number of live components” convention is consistent
across
the expression parser. [bugs.povray.org]
3) Where comparisons land
The actual comparison operators (e.g., =, !=, <, <=, >=, >) are handled in the
numeric/relational part of the expression parser; the code keeps temporary
scalars like greater_val, less_val, equal_val for those results, which are then
written back to the expression register as a single component (arity 1). You can
see these locals declared in the numeric parser routine:


// inside Parser::Parse_Num_Factor(...) in 3.7
DBL greater_val, less_val, equal_val;   // temps for relational/equality tests


Those comparisons convert to 0/1 using epsilon semantics (FTRUE), and then store
the result as a scalar in Express[0] with *Terms = 1. That is the key to the
behavior you’re seeing. [bugs.povray.org]

Why we care: Once a comparison has yielded a scalar Express[0] ∈ {0,1}
with Terms=1, any later need for a vector/colour will trigger a promotion. Which
promotion path it takes determines whether you get <1,0,0,0,0> or <1,1,1,1,1>.


Boolean embedding and promotion—what exactly happens?
POV‑Ray has two distinct (but similarly named) “promotion” behaviors,
and
the end result depends on which one the parser chooses from context:


Float → N‑vector replication (operator promotion rule).
The documentation’s Operator Promotion section says that if POV‑Ray
expects an N‑component vector and you give it a float, it replicates the
float into all components:
9 → <9,9,9,9> (for 4‑vectors), 5 → <5,5,5> (for
3‑vectors), etc. [math.hws.edu]


Lower‑arity vector → higher‑arity vector zero‑fill.
The same section also says that when promoting a vector of lower dimension to a
higher one, the remaining components are set to zero:
<7,6> → <7,6,0,0> if a 4‑vector is required. [math.hws.edu]


The comparison result takes path (2), not (1).
The equality (<1,1,1> = 1) is parsed/evaluated in the numeric/relational
pipeline. The boolean truth value is put into the expression register as a
single‑lane result—conceptually a 1‑component vector, i.e., Terms =
1 and Express[0] = 1.0. When that value is later needed in a 5‑component
colour context (e.g., inside pigment { ... } where colours are rgbft
5‑vectors), POV‑Ray promotes a 1‑component vector to a
5‑component vector, which fills lanes 2..5 with zeros, giving <1,0,0,0,0>.
This matches exactly what you observed. [povray.org], [math.hws.edu]
By contrast, a literal 1 (a float) appearing directly in a colour context
follows path (1): it’s replicated to <1,1,1,1,1> because the parser knows a
5‑vector is expected and it starts from a true float, not from a
“1‑lane vector” that already has an arity. That’s the
“usual” behavior you
had in mind. [povray.org], [math.hws.edu]

Why does a comparison yield a 1‑lane vector instead of a float?
Because of the parser’s internal representation:

All numeric/logic sub‑expressions are computed into the EXPRESS register
(DBL Express[5]) plus an integer Terms.
Pure scalars and booleans both occupy Terms = 1 lane at that point.
But here’s the catch: after certain operations (notably vector/colour handling),
the parser treats a Terms = 1 result as a vector of arity 1 if vector/colour
typing already dominates the surrounding context. From there, the
vector→vector arity promotion (zero‑fill) applies, not the
float→vector replication. [github.com], [bugs.povray.org]

So for (<1,1,1> = 1) you end up with:

Relational evaluation → Express[0] = 1.0, Terms = 1 (boolean true).
[bugs.povray.org]
Used in a colour (5‑vector) position → 1‑lane vector upcast to
5‑lane → <1,0,0,0,0>. [povray.org], [math.hws.edu]


How to get <1,1,1,1,1> from a boolean on purpose
If your intent is a mask of ones across all five colour lanes, force the
float→vector promotion (replication) explicitly by multiplying with a full
vector constant:


#declare B = (<1,1,1> = 1);        // scalar 0/1 in Express[0]
#declare M = B * <1,1,1,1,1>;      // forces float→vector replication
→ <B,B,B,B,B>


This uses general operator promotion (a float on the left in a vector arithmetic
expression) so POV‑Ray replicates B to each lane. [math.hws.edu]
If you’d rather avoid arithmetic, you can also pick the result yourself:

#declare M = select(B, <0,0,0,0,0>, <1,1,1,1,1>);

(That’s often the clearest way to signal intent in SDL.)

[Bald Eagle] Re: Strange syntax [53 days 20 hours and 35 minutes ago]

Fri, 27 Feb 2026 11:50:00 GMT

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

> The 1 should have been promoted to <1, 1, 1, 1, 1>.

Well, this is the danger with code, stems in general, and expectations.

"We would have _expected_ the 1 to be promoted to <1, 1, 1, 0, 0>."
But it did not.

> This would be
> consistent with previous behavior and with other contexts where a scalar
> appears in the same expression as a color or vector.

Right, which is what I was expecting, and what was throwing me off.

> > Totally logical, yet totally unexpected!
>
> Logic can give you wrong answers if a premise (in this case, the
> promotion of the scalar) is wrong.
>
> P.S. Not that it makes a difference here, but colors.inc defines `White`
> as `rgb 1`, which means it does not need promotion.  It already has the
> value <1, 1, 1, 0, 0>.

But it DOES make a difference.
White is _rgb_ 1.  NOT rgbft1.
That only happens on the fly when it needs to be compared to 1, which gets
promoted on the fly to rgbft.

That warning about f&t in the light source being ignored tells you it got
promoted, whereas a "normal" scene with rgb 1 would not issue such a warning.

This will take a lot of looking into to find out WHY it does what it does.
I'm just very thankful that no such thing took place when I was working out the
vector / scalar typing/differentiation!

- BE

[Cousin Ricky] Re: Strange syntax [54 days 7 hours and 23 minutes ago]

Fri, 27 Feb 2026 01:02:10 GMT

On 2026-02-26 09:17 (-4), Bald Eagle wrote:
> 
> So <1, 1, 1> gets promoted to rgbft <1, 1, 1, 0, 0>,
> and 1 gets promoted to <1, 0, 0, 0, 0>
> 
> and then comparing element by element ones gets
> 
> <1, 1, 1, 0, 0>
> <1, 0, 0, 0, 0>
> ---------------
> <1, 0, 0, 1, 1>

Good work!

The 1 should have been promoted to <1, 1, 1, 1, 1>.  This would be
consistent with previous behavior and with other contexts where a scalar
appears in the same expression as a color or vector.

> Totally logical, yet totally unexpected!

Logic can give you wrong answers if a premise (in this case, the
promotion of the scalar) is wrong.

P.S. Not that it makes a difference here, but colors.inc defines `White`
as `rgb 1`, which means it does not need promotion.  It already has the
value <1, 1, 1, 0, 0>.

[kurtz le pirate] Re: Strange syntax [54 days 14 hours and 52 minutes ago]

Thu, 26 Feb 2026 17:33:25 GMT

On 25/02/2026 12:45, Bald Eagle wrote:
> I'm thinking that the red must be coming from something else.
> Post the whole scene, a link, or at least more to work from?

the scene :

#version 3.8;

#include "colors"

global_settings {
   assumed_gamma 1.0
   max_trace_level 5
   }
#default {
   finish {
     ambient 0.00
     emission 0.40
     diffuse 0.60
     }
   }

camera {
   location <40,20,22>
   up y
   right x*image_width/image_height
   look_at <0, a*0.60, 0>
   angle 36
   }

light_source {
   <290, 384, 1350>
   color White=1
   }

plane {
   y,0
   pigment { White }
   }

#declare a = 4;
box {
   <-a, 0, -a>, <+a, 2*a, +a>
   pigment { White }
   }


With the warning :
Parse Warning: Expected pure RGB color expression, unexpected filter and 
transmit components will have no effect.






-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Strange syntax [54 days 19 hours and 5 minutes ago]

Thu, 26 Feb 2026 13:20:00 GMT

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

> The value of `White` never changes.  It is the expression `(White=1)`
> (which is a conditional in this context, not an assignment) that you
> should vstr().

Ah, yes.  Very interesting.

So <1, 1, 1> gets promoted to rgbft <1, 1, 1, 0, 0>,
and 1 gets promoted to <1, 0, 0, 0, 0>

and then comparing element by element ones gets

<1, 1, 1, 0, 0>
<1, 0, 0, 0, 0>
---------------
<1, 0, 0, 1, 1>


Totally logical, yet totally unexpected!

- BE

[William F Pokorny] Re: Inexplicably bad lighting in otherwise simpl... [54 days 20 hours and 24 minutes ago]

Thu, 26 Feb 2026 12:01:07 GMT

On 2/19/26 07:05, Bald Eagle wrote:
> I'm super close, but when I zoomed in to closely inspect how things were
> positioned, I noticed that some objects simply weren't being properly lit.
> Adding emission only partially remedied the situation.
> 
> The objects are all just a simple torus {} with plain rgb pigments.
> But for some reason the yellow torus is the only one really affected.

Bill W, This morning I got around to running the scene you sent to me - 
thanks.

I can reproduce your image with my v3.8 beta 2 - except I don't get some 
noise in the shadows near the top on the left. This difference a 
surprise and I'm unsure what might be the cause. Differences in compiler 
settings? Differences windows to linux? Some difference in ini / command 
lines settings? I don't know. I took a few shots in the dark trying to 
reproduce the shadow noise without success.

When your scene is run with my current development yuqk fork, I again 
get no noise on the top left (matching my v3.8 beta 2 compile), and the 
yellow shape running left to right renders fine - see attached image.

So, some fix(es) in yuqk address whatever issue there is with that 
particular yellow torus{}. I probably won't take the time to run down 
which one(s) - it's time consuming to do.

Bill P.

[Cousin Ricky] Re: Strange syntax [55 days 10 hours and 22 minutes ago]

Wed, 25 Feb 2026 22:03:18 GMT

On 2026-02-25 17:09 (-4), Bald Eagle wrote:
> 
> I vstr()'d the expression White,
> 
> then instantiated the light source (copy/pasted kurtz le pirate's exact code) ,
> 
> then vstr()'d the expression White again.
> 
> Which is now even weirder, because if White got changed to include filter and
> transmit, then why didn't it show up with vstr?  And why did it still have g&b
> values of 1?
> 
> I'll check/post my actual code when I get home - but that won't be for another
> 5h.

The value of `White` never changes.  It is the expression `(White=1)`
(which is a conditional in this context, not an assignment) that you
should vstr().

[Bald Eagle] Re: Strange syntax [55 days 11 hours and 15 minutes ago]

Wed, 25 Feb 2026 21:10:00 GMT

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

> The warning about unexpected filter and transmit components indicates
> that the bug did manifest, but without altering `White`.  Did you create
> an image output?  Did you vstr() the expression `(White=1)`?

As far as I can remember (it was early and I was on my way out the door to
work):

I vstr()'d the expression White,

then instantiated the light source (copy/pasted kurtz le pirate's exact code) ,

then vstr()'d the expression White again.

Which is now even weirder, because if White got changed to include filter and
transmit, then why didn't it show up with vstr?  And why did it still have g&b
values of 1?

I'll check/post my actual code when I get home - but that won't be for another
5h.

- BE

[Cousin Ricky] Re: Strange syntax [55 days 11 hours and 35 minutes ago]

Wed, 25 Feb 2026 20:50:28 GMT

On 2026-02-25 16:11 (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> On 226-02-24 12:36 (-4), kurtz le pirate wrote:
>>>
>>> How this <color White=1> is interpreted and why does it turn red?
>>
>> I just tried it with different versions of POV-Ray.  It is red only with
>> POV-Ray 3.8 and the discontinued POV-Ray 3.7.1.  It is white for all
>> versions 3.5 to 3.7.0.10.
>>
>> This appears to be a bug that was introduced in POV-Ray 3.7.1.
> 
> Nice work, Richard.
> So what are you doing that I didn't?
> Because as you can see above/below, I'm using 3.8

I just opened a bug report on GitHub, issue #486.
https://github.com/POV-Ray/povray/issues/486

> [after light_source]
> White = <1.000, 1.000, 1.000, 0.000, 0.000>
> "C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 13:
> Parse Warning: Expected pure RGB color expression,
> unexpected filter and transmit components will have no effect.

The warning about unexpected filter and transmit components indicates
that the bug did manifest, but without altering `White`.  Did you create
an image output?  Did you vstr() the expression `(White=1)`?

> Are you outputting the color value with vstr(), or performing a render using
> that light source?

Both.  My source code is in the GitHub report.

[Bald Eagle] Re: Strange syntax [55 days 12 hours and 10 minutes ago]

Wed, 25 Feb 2026 20:15:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 226-02-24 12:36 (-4), kurtz le pirate wrote:
> >
> > How this <color White=1> is interpreted and why does it turn red?
>
> I just tried it with different versions of POV-Ray.  It is red only with
> POV-Ray 3.8 and the discontinued POV-Ray 3.7.1.  It is white for all
> versions 3.5 to 3.7.0.10.
>
> This appears to be a bug that was introduced in POV-Ray 3.7.1.

Nice work, Richard.
So what are you doing that I didn't?
Because as you can see above/below, I'm using 3.8

[after light_source]
White = <1.000, 1.000, 1.000, 0.000, 0.000>
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 13:
Parse Warning: Expected pure RGB color expression,
unexpected filter and transmit components will have no effect.

Are you outputting the color value with vstr(), or performing a render using
that light source?

I'm just trying to understand where this all goes off the rails, and where to
look under the hood.

- BE

[Cousin Ricky] Re: Strange syntax [55 days 12 hours and 23 minutes ago]

Wed, 25 Feb 2026 20:01:50 GMT

On 226-02-24 12:36 (-4), kurtz le pirate wrote:
> 
> How this <color White=1> is interpreted and why does it turn red?

I just tried it with different versions of POV-Ray.  It is red only with
POV-Ray 3.8 and the discontinued POV-Ray 3.7.1.  It is white for all
versions 3.5 to 3.7.0.10.

This appears to be a bug that was introduced in POV-Ray 3.7.1.

[Bald Eagle] Re: Strange syntax [55 days 13 hours ago]

Wed, 25 Feb 2026 19:25:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> Just tested, using this : #declare W = (White=1);
> And got this :
>
> W = <1.000, 0.000, 0.000, 1.000, 1.000>
> NOT what I would expect.

Yes indeed, VERY strange.
I was going to do something like that, but I needed to head out.

what if plug (White=1) directly into a debug vstr statement?

- BE

[Alain Martel] Re: Strange syntax [55 days 13 hours and 40 minutes ago]

Wed, 25 Feb 2026 18:45:13 GMT

Le 2026-02-25 Ã  06:45, Bald Eagle a Ã©critÂ :
> [before light_source]
> White = <1.000, 1.000, 1.000, 0.000, 0.000>
> 
> [after light_source]
> White = <1.000, 1.000, 1.000, 0.000, 0.000>
> "C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 13:
> Parse Warning: Expected pure RGB color expression,
> unexpected filter and transmit components will have no effect.
> -
> "C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 16:
> Parse Error: Parse halted by #error directive: No
> objects in scene
> 
> I'm thinking that the red must be coming from something else.
> Post the whole scene, a link, or at least more to work from?
> 
> - BE
> 

Just tested, using this : #declare W = (White=1);
And got this :

W = <1.000, 0.000, 0.000, 1.000, 1.000>
NOT what I would expect.

[Bald Eagle] Re: Strange syntax [55 days 20 hours and 35 minutes ago]

Wed, 25 Feb 2026 11:50:00 GMT

[before light_source]
White = <1.000, 1.000, 1.000, 0.000, 0.000>

[after light_source]
White = <1.000, 1.000, 1.000, 0.000, 0.000>
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 13:
Parse Warning: Expected pure RGB color expression,
unexpected filter and transmit components will have no effect.
-
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\_CodeScratchPad.pov" line 16:
Parse Error: Parse halted by #error directive: No
objects in scene

I'm thinking that the red must be coming from something else.
Post the whole scene, a link, or at least more to work from?

- BE

[kurtz le pirate] Re: Strange syntax [55 days 23 hours and 28 minutes ago]

Wed, 25 Feb 2026 08:56:54 GMT

On 25/02/2026 04:21, Cousin Ricky wrote:
> On 2026-02-24 12:36 (-4), kurtz le pirate wrote:
>>
>> How this <color White=1> is interpreted and why does it turn red?
> 
> Where does the identifier `White` come from?  Like BE, I would like to
> know its value.

White come from "colors.inc"



> My understanding of that syntax is that it compares each component of
> `White` with 1.  But if `White` comes from colors.inc, the
> component-wise comparison would still end up as white.  The only way I
> can see this evaluating as red is if `White.red` is exactly 1, and
> `White.green`, `White.blue`, `White.filter`, and `White.transmit` are
> all something other than 1.
> 

I also thought that "=" was interpreted as a comparison operator.

But since â€œWhiteâ€ is defined by rgb 1, that doesn't
explain anything.







-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Strange syntax [56 days 5 hours and 4 minutes ago]

Wed, 25 Feb 2026 03:21:40 GMT

On 2026-02-24 12:36 (-4), kurtz le pirate wrote:
>
> How this <color White=1> is interpreted and why does it turn red?

Where does the identifier `White` come from?  Like BE, I would like to
know its value.

My understanding of that syntax is that it compares each component of
`White` with 1.  But if `White` comes from colors.inc, the
component-wise comparison would still end up as white.  The only way I
can see this evaluating as red is if `White.red` is exactly 1, and
`White.green`, `White.blue`, `White.filter`, and `White.transmit` are
all something other than 1.

[Bald Eagle] Re: Strange syntax [56 days 15 hours ago]

Tue, 24 Feb 2026 17:25:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
>
> I found this in some very old code (2016) :
>
> light_source {
>    <0, 100, 0>
>    color White=1
>    }

> How this <color White=1> is interpreted and why does it turn red?

Yeah, that's weird.
The parser is a strange and wondrous thing.

Presumably you are including colors.inc.
Can you output the color value of White as a 5D vector to the debug stream
before instantiating the light source, and then show what happens to it after?

- BE

[kurtz le pirate] Strange syntax [56 days 15 hours and 49 minutes ago]

Tue, 24 Feb 2026 16:36:24 GMT

Hello,


I found this in some very old code (2016) :

light_source {
   <0, 100, 0>
   color White=1
   }


and with thise, the light in the scene is red.
of course, back to "normal" color White give white light.



How this <color White=1> is interpreted and why does it turn red?




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Help: Erroneous mathematics information on t... [57 days 18 hours and 20 minutes ago]

Mon, 23 Feb 2026 14:05:00 GMT

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

> So I am a lot less frustrated, and a lot happier now that I'm managed to get
> that all set down into working code.

Well,
I am back to what I was struggling with in my first attempt:
orienting and placing the Villarceau circle equivalents.

To my knowledge, there is no clear documentation about where the centers lie, or
how to calculate the locus of all the centers, or if there is another parameter
like c, which lies along the a semimajor axis, but that lies along the b
semiminor axis.  There is also a movement in y.

My initial attempt involved modeling a torus, inverting it to a cyclide, and
then finding the tangent points of the Villlarceau circles on the torus,
inverting those, and finding the centers.  But orienting them is another step
entirely.

And although I love my circles almost as much as Archimedes, I'm getting a bit
frustrated going around and around this one.

Perhaps someone has a personal insight, a literature reference, an internet
link, or something that an AI actually gets right - to put me on the path to
solving this last critical step.

- BE

[yesbird] Re: Help: Erroneous mathematics information on t... [58 days 20 hours and 54 minutes ago]

Sun, 22 Feb 2026 11:31:24 GMT

On 22/02/2026 12:24, yesbird wrote:
> This forum:
> https://forum.simplify3d.com/viewforum.php?f=8
> also can help a lot.

Espcially following section:
https://www.simplify3d.com/resources/print-quality-troubleshooting/

Here is your case:
https://www.simplify3d.com/resources/print-quality-troubleshooting/not-sticking-to-the-bed/
-- 
YB

[yesbird] Re: Help: Erroneous mathematics information on t... [58 days 23 hours and 1 minute ago]

Sun, 22 Feb 2026 09:24:23 GMT

On 22/02/2026 04:41, Bald Eagle wrote:
> 4: I added a brim after trying to print the whole thing in one go wasn't even
> sticking.

First layer is a common problem, for every type of filament special
temperature and extrusion should be set. Also I am using additional
borosilicate glass on the printer's bad and sometimes even water
with sugar to increase adhesion.

> I am going to look into "z-lift" and "z-hop", as well as try to run some
> calibration tests on the extrusion.

Good idea about tests, but the main source of info is suggestions of
filament manufacturer. This forum:
https://forum.simplify3d.com/viewforum.php?f=8
is also can help a lot.

Maybe bake the filament to make sure it's
> bone-dry.

It depends on filament - some of them are humidity insensitive:
I suggest to avoid ABS and choose PLA, until you need superior strength
of the parts. Find the best filament for your needs, then adjust the
printing process.

> 
> I'm also going to reorient it so that can make 2 "clam-shell" pieces and glue
> them together.  Now that I can calculate the exact radius at each point of the
> cyclide, I'm planning on printing spheres so that I have a Steiner chain.
>

It will be interesting to look at results ...
-- 
YB

[Bald Eagle] Re: Help: Erroneous mathematics information on t... [59 days 6 hours and 40 minutes ago]

Sun, 22 Feb 2026 01:45:00 GMT

yesbird wrote:
> On 21/02/2026 20:34, Bald Eagle wrote:
> > Now I can move on to learning the Bambu P1S and hopefully not have it rip the
> > print off the base after 2h into the print.
> >
>
> There are few tips to avoid this unpleasant event:
>
> 1. Keep printer from drafts - environment temperature should be as
> stable as possible.
> 2. Increase the temperature of the first layer if software allows.
> 3. Increase extrusion of the first layer ...
> 4. Try to use brim.

1-3: interesting
4: I added a brim after trying to print the whole thing in one go wasn't even
sticking.  So I sliced it in half and rotated it so that I was printing a
semicircle.

> If nothing of the above helps read software instruction ).

The issue was that the print head suddenly crashed into the top of the piece and
flung it off the plate.

I am going to look into "z-lift" and "z-hop", as well as try to run some
calibration tests on the extrusion.  Maybe bake the filament to make sure it's
bone-dry.

I'm also going to reorient it so that can make 2 "clam-shell" pieces and glue
them together.  Now that I can calculate the exact radius at each point of the
cyclide, I'm planning on printing spheres so that I have a Steiner chain.

> > And then maybe implement the AMS so that I can do fancy multi-color printing.
>
> It should be interesting ...

Indeed it should!  :)
Thanks for the tips.

- BE

[yesbird] Re: Help: Erroneous mathematics information on t... [59 days 8 hours and 43 minutes ago]

Sat, 21 Feb 2026 23:41:43 GMT

On 21/02/2026 20:34, Bald Eagle wrote:
> Now I can move on to learning the Bambu P1S and hopefully not have it rip the
> print off the base after 2h into the print.
> 

There are few tips to avoid this unpleasant event:

1. Keep printer from drafts - environment temperature should be as
stable as possible.
2. Increase the temperature of the first layer if software allows.
3. Increase extrusion of the first layer ...
4. Try to use brim.

If nothing of the above helps read software instruction ).

> And then maybe implement the AMS so that I can do fancy multi-color printing.

It should be interesting ...
--
YB

[Bald Eagle] Re: Help: Erroneous mathematics information on t... [59 days 14 hours and 50 minutes ago]

Sat, 21 Feb 2026 17:35:00 GMT

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

> The equations in the accompanying text sometimes seem to work, and sometimes
> not.
> So do I question my code, or the equations?

I get sleep and proofread my code another dozen times.
There was a + where there should have been a -.

So I am a lot less frustrated, and a lot happier now that I'm managed to get
that all set down into working code.

Now I can move on to learning the Bambu P1S and hopefully not have it rip the
print off the base after 2h into the print.

And then maybe implement the AMS so that I can do fancy multi-color printing.

Enjoy.  :)

[William F Pokorny] Re: Inexplicably bad lighting in otherwise simpl... [60 days 21 hours and 59 minutes ago]

Fri, 20 Feb 2026 10:25:59 GMT

On 2/19/26 19:18, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> I'll try perspective and maybe sturm when I get back in.
>> The really puzzling thing about it, is that all of the other tori render just
>> fine.
> 
> Changing to perspective helped - but there was still a thin line of cruft around
> the perimeter.
> Sturm didn't do much to remedy that, but shifting the camera up a little bit
> did.
> 
> The shadows still look weird.
> 
On the shadows.

First a disclaimer. In not completely understanding the geometry of your 
scene, seeing what you see as wrong about your shadows is not completely 
clear.

That said, one of the things which can happen is that the shadow test 
rays can resolve to surfaces different than do the camera rays.

For example, sometime last year I posted about the sor example used in 
our documentation being problematic for our solvers - especially those 
in the official POV-Ray releases. There were cases there where shadow 
test rays in some set ups were causing solver problems while those from 
the camera were OK.

I'll also mention the 2.5 issues in the shadow cache mechanism of 
official POV-Ray releases which are fixed in the yuqk fork. Those shadow 
cache issues can cause strange shadow artifacts - depending on 'stuff'.

I'm busy today, but I'll put on my todo list testing with your 
orthographic camera(*) and zoom set up. My generic orthographic camera 
set up is somewhat different.

Aside: An interesting test would be to replace the torus{} shapes with 
isosurface f_torus() shapes. The isosurface mechanism (so long as the 
max gradient is large enough for all ray approaches) is often more 
robust / stable with respect to resolving surfaces from varied ray 
approaches.

Bill P.

[Bald Eagle] Help: Erroneous mathematics information on the web [61 days 7 hours and 40 minutes ago]

Fri, 20 Feb 2026 00:45:00 GMT

Due to my current inability to render a Dupin cyclide (DC) made of its
equivalent Villarceau circles based on my own reasoning, I'm trying to explore
other avenues.

My current state of things experienced frustration due to finding apparently
flawed implementations of computing the center and radius of a circle in 3d
given 3 points.
I currently have a known-good version.

My present experiment is trying to leverage the "easily parameterizable" nature
of DC's and replicate the following diagram:

https://en.wikipedia.org/wiki/Dupin_cyclide#/media/File:Zyklide-maxwell-abcd.svg

The equations in the accompanying text sometimes seem to work, and sometimes
not.
So do I question my code, or the equations?

And for context:
The equations are presumably written by a mathematician who was for many years a
member of Working Group 2 for Geometry & Algebra of the Department of
Mathematics of the TU Darmstadt, and contributed to MANY articles on Wikipedia
from 2013-2022.

There are issues with signs, circles have negative radii, and I'm trying to
document what is correct and what is not --- but it keeps changing depending on
the values I assign to x1, x2, x3, x4.

Perhaps others can try to replicate the diagram and the channel surface (the
envelope of spheres, which I'm representing as circles so i can still see the
rest of the diagram)

https://en.wikipedia.org/wiki/Dupin_cyclide#/media/File:Zyklide-kanalfl-1-2.svg

- BE

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl... [61 days 8 hours and 5 minutes ago]

Fri, 20 Feb 2026 00:20:00 GMT

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

> I'll try perspective and maybe sturm when I get back in.
> The really puzzling thing about it, is that all of the other tori render just
> fine.

Changing to perspective helped - but there was still a thin line of cruft around
the perimeter.
Sturm didn't do much to remedy that, but shifting the camera up a little bit
did.

The shadows still look weird.

- BE

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl... [61 days 11 hours and 40 minutes ago]

Thu, 19 Feb 2026 20:45:01 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/19/26 07:05, Bald Eagle wrote:
> > Any ideas?
>
> Guesses.
>
> Some of what I see in your image can happen when the plane of the camera
> slices into shapes like the torus{}.
>
> That 'emission 1' didn't help much and that you have some apparent
> speckling looks more like solver issues - which could be related to
> geometry of the scene for the image posted and/or the state of the
> 'solver code' itself.

Could be.
The other weird thing is that the yellow torus was not only speckled - but it
was partially transparent as well.
I've seen and mentioned this before in other scenes.

>
> Are you using an orthographic camera?
>
> With the camera set up you have, how are you zooming?

Yes.  Luckily I emailed myself the scene, so I can reference it.

#declare Zoom = 0.4;
camera {
orthographic
location <IR*1.5, 0, -2*IR>
location <IR, 5*M, -2*IR>
//location <IR, 5*M, 0>
right    x*image_width/Zoom
up       y*image_height/Zoom
look_at <IR, 0, 0>
}

>
> Have you tried with both 'sturm' and not? If so, are there differences
> in result?

I didn't yet - but have thought about doing so.

>
> A wilder guess. The ray->surface intersection equations for the torus
> adjust each rays origin prior to creating the equation for the
> solver(s). The origin adjustments are unrolled after roots are found so
> as to get the real intersection positions. It's known that ray origin
> adjustment works less well at larger torus dimensions once the equation
> origin is beyond the first surface.

It's a 150-unit torus.

#declare M = 150;
#declare m = 20;

.....

torus {M, m pigment {rgb 1} translate T_Center}

I'll try perspective and maybe sturm when I get back in.
The really puzzling thing about it, is that all of the other tori render just
fine.

- BE

[William F Pokorny] Re: Inexplicably bad lighting in otherwise simpl... [61 days 12 hours and 13 minutes ago]

Thu, 19 Feb 2026 20:11:50 GMT

On 2/19/26 07:05, Bald Eagle wrote:
> Any ideas?

Guesses.

Some of what I see in your image can happen when the plane of the camera 
slices into shapes like the torus{}.

That 'emission 1' didn't help much and that you have some apparent 
speckling looks more like solver issues - which could be related to 
geometry of the scene for the image posted and/or the state of the 
'solver code' itself.

Are you using an orthographic camera?

With the camera set up you have, how are you zooming?

Have you tried with both 'sturm' and not? If so, are there differences 
in result?

A wilder guess. The ray->surface intersection equations for the torus 
adjust each rays origin prior to creating the equation for the 
solver(s). The origin adjustments are unrolled after roots are found so 
as to get the real intersection positions. It's known that ray origin 
adjustment works less well at larger torus dimensions once the equation 
origin is beyond the first surface.

Bill P.

[Bald Eagle] Inexplicably bad lighting in otherwise simple sc... [61 days 20 hours and 15 minutes ago]

Thu, 19 Feb 2026 12:10:00 GMT

I am working on a scene to establish geometry for conversion to OpenSCAD.

I'm super close, but when I zoomed in to closely inspect how things were
positioned, I noticed that some objects simply weren't being properly lit.
Adding emission only partially remedied the situation.

The objects are all just a simple torus {} with plain rgb pigments.
But for some reason the yellow torus is the only one really affected.
Lights are just point lights.
Lit from the front with no obvious occlusion.
Adding a top light doesn't help.

The shadows are really weird too.

3.8 beta 2

Any ideas?

- BE

[kurtz le pirate] Re: POV-Ray 3.8 and 3.7.0.9 update available [84 days 23 hours and 31 minutes ago]

Tue, 27 Jan 2026 08:54:32 GMT

On 11/01/2026 15:28, yvo (DOT) s (AT) gmx.net wrote:
> Please visit:
> 
> https://povrayunofficial.wordpress.com
> 
> 
> Fixed OpenEXR output, updated Zlib, LibPNG, LibTiff and LibJPEG to the 
> latest versions.
> 
> Fixed some minor bugs in the GUI.
> 
> 
> Both versions are Intel and Apple Silion (universal binaries).
> 
> Runs on BigSur (11) and later, older system versions are no longer 
> supported.
> 
> 
> Best regards,


Good news. Thanks again Yvo.

A little question : You say â€œApple siliconâ€ only,
but what about the M1, 
M2, M3, and M4 in terms of code?

Does XCode automatically optimize and adapt?





-- 
kurtz le pirate
compagnie de la banquise

[David Buck] Re: THERE's A BOOK??! [87 days 5 hours and 55 minutes ago]

Sun, 25 Jan 2026 02:30:15 GMT

On 2026-01-24 9:25 p.m., Josh English wrote:
> On 11/12/2025 7:53 AM, Bald Eagle wrote:
>> I guess this must be David K. Buck's brother?
>>
>> https://devtalk.com/books/the-ray-tracer-challenge
>>
>> Dave wrote the foreword?
>>
>> Did anyone know about this?
>>
>> - BE
>>
> It looks interesting but I don't see any way to actually buy the book.
> 
> Is this a case of DevTalk not understanding capitalism or am I missing a 
> bold "buy now" button?
> 
> Uncle Josh

Check out the book's web page:

http://raytracerchallenge.com/

There's a link at the top for ways to purchase the book.

David Buck

[Josh English] Re: THERE's A BOOK??! [87 days 6 hours ago]

Sun, 25 Jan 2026 02:25:30 GMT

On 11/12/2025 7:53 AM, Bald Eagle wrote:
> I guess this must be David K. Buck's brother?
> 
> https://devtalk.com/books/the-ray-tracer-challenge
> 
> Dave wrote the foreword?
> 
> Did anyone know about this?
> 
> - BE
> 
It looks interesting but I don't see any way to actually buy the book.

Is this a case of DevTalk not understanding capitalism or am I missing a 
bold "buy now" button?

Uncle Josh

[Kenneth] Re: odd behavior of photon reflection/refraction... [88 days 18 hours and 40 minutes ago]

Fri, 23 Jan 2026 13:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But for REFLECTION caustics, no_image works 'as expected'-- the photon light
> *is* blocked.  So currently, no shadow works in a different way for reflected
> vs. refracted caustics.
>

That has a small but confusing typo, sorry:

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no_IMAGE works in a different way for reflected
vs. refracted caustics.

[yesbird] Re: Encyclopedia of Analytical Surfaces [90 days 10 hours and 13 minutes ago]

Wed, 21 Jan 2026 22:12:34 GMT

On 21/01/2026 23:10, Leroy wrote:
> I just had a quick look at that page and it goes over my head. Maybe not over,
> but in it, then rattles around. Did you get the printed copy or just bookmarked
> it?

I have a printed copy and glad that ordered it. It's comprehensive and
well organized - the excellent source of ideas for my math project:
https://mathview.yesbird.online
-- 
YB

[Leroy] Re: Encyclopedia of Analytical Surfaces [90 days 12 hours and 10 minutes ago]

Wed, 21 Jan 2026 20:15:00 GMT

yesbird wrote:
> I have just got a very impressive book "Encyclopedia of Analytical
> Surfaces" - the most complete description with classification of more
> than 500 surfaces:
>
https://books.google.ru/books?id=cXTdBgAAQBAJ&printsec=frontcover#v=onepage&q&f=false
>
> This is the end of my internet quest in searching the sources for my
> surfaces collection. :)
> --
> YB

I just had a quick look at that page and it goes over my head. Maybe not over,
but in it, then rattles around. Did you get the printed copy or just bookmarked
it?
I bookmarked It!

Have Fun!

[Kenneth] Re: odd behavior of photon reflection/refraction... [90 days 13 hours ago]

Wed, 21 Jan 2026 19:25:00 GMT

[Sorry for my silence here, I got side-tracked with just having some fun with
other POV-ray scenes. But I continued testing photon behavior...a tedious
process comparing one feature against another in refraction vs. reflection
set-ups, and in both v3.7 vs 3.8 beta 1...then trying to make sense of it
all...]

>
> [Kenneth wrote]
> Just out of curiosity, I tried adding the typical no_shadow and no_image flags
> to my photon 'target' object, to see what would happen...and either flag
> *eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
> 3.8). That does not *seem* to be an expected result to me...
>
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too [on it own surface].

With further testing, the no_shadow behavior does make sense now, at least
regarding photon 'collectors'. In my original test scene, I neglected to add a
2nd collector behind the 1st one, to see the effect of this flag. Adding it to
the 1st collector makes it 'transparent' to the PHOTON-light effects, so that
they 'pass through' and show up on the 2nd collector surface instead. (And
the docs do say that "no_shadow automatically turns on pass_through"... which I
neglected to read.) The only 'seemingly' weird thing is that this behavior is
unlike *direct* light from the light source, which still shows up on the 1st
collector as expected-- whereas the photon caustics do not. It's as if the
caustics are 'a different and separate kind of light'.

But NO_IMAGE for a 'collector' might not be working as intended: For REFRACTION
caustics, the object does become invisible, but the photon light will pass
through it to a 2nd collector-- identical to no_shadow -- which seems to be
different as to how no_image works in other circumstances: that is, the object
still exists but only its *appearance* is turned off (and *should* block the
photon light). So no_image apparently invokes no_shadow as well.

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no shadow works in a different way for reflected
vs. refracted caustics.

-----
After testing this stuff, I wanted to see how the *actual*
photons{pass_through on/off}  feature worked, as I have never used it before.

The way I understand the v3.8 docs at '3.4.3.4.4 Shooting Photons at an
Object', pass_through ON can be applied to an object that sits *between* a
photon-enabled light_source and a photon 'target'-- so that the 'photon light'
can go through that intervening object as if it was not there, instead of being
blocked by it.

But in v 3.7 and the current 3.8 betas, this does not work for a totally opaque
object; it needs *some* transparency (either f or t) which is not mentioned in
the docs...although, the limited notes there seem to imply a particular photon
*refraction* set-up with a transparent media container and photon-enabled
media(?)....implying transparency for that container object, so that
pass_through will let the photon light bypass the container and interact with
the media itself. But there is no mention of opacity...so I guess we are
supposed to assume that the intervening object needs to have at least some
transparency.

The only way to get photon-enabled light to pass through an opaque object is to
use no_shadow...which automatically turns on pass_through as well.
HOWEVER,  there is a caveat here concerning no_shadow:
an optional pass_through OFF should then work, but does not. According to the
docs for 'pass_through':

"If you use the no_shadow keyword, the object will be tagged as pass_through
automatically. You can then turn off pass_through if necessary by simply using
photons { pass_through off }."

------------
BTW:
I was able to reproduce the unexpected slow-down of photon rendering that I
mentioned earlier...or some variation of it...caused in some way by *multiple*
collector objects in a scene producing photon 'shadows'. Both 3.7 and 3.8 beta
1 show this.

I have included an additional and rather specialized test scene (reflection-only
this time, but refraction shows the same behavior): a light_source, a reflection
'target', and two 'collector' objects. One collector sits above the other, to
produce some photon 'shadowing' on the lower one. The best way to witness the
effect is with Work_Threads=1, to slow down the render.

The render  becomes sluggish in the photon *shadow* area on the lower collector,
whereas the un-shadowed areas render very quickly.  This behavior seems odd to
me, since the shadow has no photon caustics. I do realize that shadow
calculations have to be performed there, but...so slowly?  I don't know what
this implies when a scene has *many* collector objects, each casting its own
shadow onto others.  (Of course, fast multi-threaded machines tend to mask this
effect, but it's still there.)

To see an even worse and 'different'(?) example, use no_shadow for the upper
collector box. In this case, the box itself renders **very** slowly. That's
quite strange.

The only way to prevent these slow-downs is with 'collect off' in either one of
my collector objects.

[yesbird] Encyclopedia of Analytical Surfaces [90 days 18 hours and 23 minutes ago]

Wed, 21 Jan 2026 14:02:33 GMT

I have just got a very impressive book "Encyclopedia of Analytical
Surfaces" - the most complete description with classification of more
than 500 surfaces:
https://books.google.ru/books?id=cXTdBgAAQBAJ&printsec=frontcover#v=onepage&q&f=false

This is the end of my internet quest in searching the sources for my
surfaces collection. :)
--
YB

[David Buck] Re: THERE's A BOOK??! [91 days 5 hours and 13 minutes ago]

Wed, 21 Jan 2026 03:11:59 GMT

On 2025-11-12 12:06 p.m., kurtz le pirate wrote:
> On 12/11/2025 16:53, Bald Eagle wrote:
>> I guess this must be David K. Buck's brother?
>>
>> https://devtalk.com/books/the-ray-tracer-challenge
>>
>> Dave wrote the foreword?
>>
>> Did anyone know about this?
> 
> yes, that's him. we can read it at the end of the foreword :
>  Â  David Buck
>  Â  Author of DKBTrace and Coauthor of POV-Ray
> and that was back in 2019
> 

Yes, I wrote the forward to The Ray Tracer Challenge.  I even followed 
the implementation guided by the book (using Smalltalk) and gave some 
feedback to Jamis about it.

BTW, the last name is a pure coincidence.  As far as I can tell, we're 
not related.

These days, I'm approaching retirement within a few years.  I'm 
releasing a free open-source version of the Smalltalk programming 
language and environment called Beagle Smalltalk.  I do hope to be able 
to do some raytracing in it among other things.  My goal with this is to 
provide an environment where people can easily explore and discover the 
world of software.

I'll also be including sound, music, graphics, games, and lots more.  I 
plan to have fun with software again - hopefully I can get others hooked 
on it as well.

David Buck
Author DKBTrace / POV-Ray

[Mr] Re: New arrival [91 days 16 hours and 40 minutes ago]

Tue, 20 Jan 2026 15:45:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > And that has got me looking into OpenSCAD again.
>
> Because of the resemblance with POV-Ray I looked into it. The resemblance is
> only on the surface. The ned to define all transforms before one can finally add
> the actual object annoyed me, as did the strange immutable vars. But, as I
> understood they started last year with adding a python layer that changes all
> that. There is also a "patched" version of openScad that does that. Have not
> tried it.
>
> I looked into 3D printing and listed what I would do with it. The result, ah,
> that I can make from wood. So, no printer, with the happy side effect of no
> plastics.
>
> The nice thing with woodworking is that I can do my visualisations in POV-Ray
> and fully parametric. I can even print the parts list.
>
> But yes, interaction with openSCAD and FeeCAD are good things to do. I still see
> POV-Ray as two things, SDL and the render engine. I still think a SDL can be
> created that serves multiple back ends, POV-Ray, OpenGL, and all the new fancy
> ray tracers like Embree. But also CAD like applications and proper output to CAM
> equipment.
>
> ingo

Feeling the same, about translating/rotating something before it exists... also
I suspect its material system can't be made to match POV-Ray's

Also even though Python can do even better, POV has the merit to allow not to
call everything as functions as Openscad does, thus reducing the number of
parenthesis or braces to open and close everywhere. Overall, even though I kept
ranting about how more stressfull than Python it could be, looking at Openscad
made me value POV syntax more ! Thanks.

[Bald Eagle] Re: New arrival [91 days 19 hours and 5 minutes ago]

Tue, 20 Jan 2026 13:20:00 GMT

yesbird wrote:

> Why OpenSCAD, but not so popular Blender ?

Familiarity?
Modeling something in OpenSCAD is just like writing a scene in SDL.

Also, it installs in seconds.

I think I tried to install and use Blender once, ages ago.
I can't recall how long the install took, or how much space it took up.
When I opened it, it was like trying to navigate through an alien spacecraft.

Maybe I'll give it another go.

- BE

[yesbird] Re: New arrival [92 days 13 hours and 24 minutes ago]

Mon, 19 Jan 2026 19:01:33 GMT

On 19/01/2026 20:05, Bald Eagle wrote:
> 
> "Almost no layer lines"
> I'm liking it already!   Thanks for the suggestion.

Yes, it's true - I have checked, but maybe you should set some
parameters like layer thickness, extrusion, etc. according to
manufacturer's recommendations.

> 
> Sometime soon I need to figure out printing with support vs bridging
> (my "just print it" experiments have revealed that this bridges pretty well!)
> using multiple filament colors, flipping parts that are oriented badly, scaling,
> and then get down to modeling from scratch in something like OpenSCAD, since
> it's been a good 10 years.
> Also need to learn how to pause print to insert thing like threaded nuts, allen
> wrenches, and other metal items.

I know that feeling - a new device is a new world with huge space to
explore. Wish you a happy journey :).

Why OpenSCAD, but not so popular Blender ?
-- 
YB

[Bald Eagle] Re: New arrival [92 days 15 hours and 15 minutes ago]

Mon, 19 Jan 2026 17:10:00 GMT

yesbird wrote:
> On 19/01/2026 16:46, Bald Eagle wrote:
> > I didn't
> > really know how much actual use it would get.
>
> Just start and you will not stop ...

Well yes.
But it's really supposed to be my son's 3D printer.  ;)

> It's also important to choose a good plastic according to your needs.
> After a long quest, I am ended with this one:
> https://polymaker.com/product/polyterra-pla/

"Almost no layer lines"
I'm liking it already!   Thanks for the suggestion.

Sometime soon I need to figure out printing with support vs bridging
(my "just print it" experiments have revealed that this bridges pretty well!)
using multiple filament colors, flipping parts that are oriented badly, scaling,
and then get down to modeling from scratch in something like OpenSCAD, since
it's been a good 10 years.
Also need to learn how to pause print to insert thing like threaded nuts, allen
wrenches, and other metal items.

> > https://www.thingiverse.com/thing:4229898
> :)))
> I am imaging something like that in real world on the street ...

lol.
I might have to start giving driving directions in <x, y, z> vectors.

- BE

[yesbird] Re: New arrival [92 days 15 hours and 44 minutes ago]

Mon, 19 Jan 2026 16:41:40 GMT

On 19/01/2026 16:46, Bald Eagle wrote:
> I've seen it used on machinist channels like Inheritance Machining,
> and they were having a "sale", so I just ran with that.
> Wasn't prepared to shell out for a high end machine, since I didn't
> really know how much actual use it would get.

Just start and you will not stop ...

> 
> But it did set up fairly fast and produced some decent quality prints using the
> default settings on my wobbly coffee table.

It's also important to choose a good plastic according to your needs.
After a long quest, I am ended with this one:
https://polymaker.com/product/polyterra-pla/

> Then you're missing the point of the opening post.
> ...

Absolutely agree that context is very important and will join this group
with pleasure.

> 
> Yeah - I have been periodically returning to my work on the Dupin Cyclide, and
> so I'll probably try to make a wireframe Dupin Cyclide and maybe one with a
> Steiner Chain of spheres inside.

Good luck with it, looking forward for images. :)

> Also, he're's a direct crossover that is directly related to both 3D printing
> and POV-Ray.  :D
> 
> https://www.thingiverse.com/thing:4229898

:)))
I am imaging something like that in real world on the street ...
-- 
YB

[ingo] Re: New arrival [92 days 16 hours and 50 minutes ago]

Mon, 19 Jan 2026 15:35:00 GMT

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

> And that has got me looking into OpenSCAD again.

Because of the resemblance with POV-Ray I looked into it. The resemblance is
only on the surface. The ned to define all transforms before one can finally add
the actual object annoyed me, as did the strange immutable vars. But, as I
understood they started last year with adding a python layer that changes all
that. There is also a "patched" version of openScad that does that. Have not
tried it.

I looked into 3D printing and listed what I would do with it. The result, ah,
that I can make from wood. So, no printer, with the happy side effect of no
plastics.

The nice thing with woodworking is that I can do my visualisations in POV-Ray
and fully parametric. I can even print the parts list.

But yes, interaction with openSCAD and FeeCAD are good things to do. I still see
POV-Ray as two things, SDL and the render engine. I still think a SDL can be
created that serves multiple back ends, POV-Ray, OpenGL, and all the new fancy
ray tracers like Embree. But also CAD like applications and proper output to CAM
equipment.

ingo


It's only in Dutch, sorry. Cabinet Corpus
---%<---%<---
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}


#macro Korpus(Hoogte, Breedte, Diepte, WandDikte, AchterwandDikte)
  // vaste maten
  #local constGroefAfstand = 15; // afstand groef voor achterwand tot achterkant
  #local constGroefSpeling = 2;  // ruimte die de achterwand in de groef heeft

  // afgeleide maten
  #local BinnenBreedte = Breedte - (2 * WandDikte);
  #local GroefDiepte = WandDikte / 2;
  #local AchterwandBreedte = BinnenBreedte + WandDikte - (2 *
constGroefSpeling);

  #local Zijde = prism{ // extrusie object
    linear_spline
    linear_sweep
    0, Hoogte,
    9,
    <0,0>, <-WandDikte,0>,
    <-WandDikte, Diepte>, <0,Diepte>,
    <0, Diepte - constGroefAfstand>,
    <-GroefDiepte, Diepte - constGroefAfstand>, <-GroefDiepte, Diepte -
constGroefAfstand - AchterwandDikte>,
    <0, Diepte - constGroefAfstand - AchterwandDikte>, <0, 0>
    sturm
    pigment{rgb 1}
  }

  #local LinkerZijde = object{
   Zijde
   translate<-(BinnenBreedte / 2), 0, 0>
  }

  #local RechterZijde = object{
    Zijde
    scale<-1, 1, 1> // negatieve schaal x is spiegel in yz vlak
    translate<(BinnenBreedte/2), 0, 0>
  }

  #local Bodem = box{
    <-BinnenBreedte/2, 0, 0>, <BinnenBreedte/2, WandDikte, Diepte -
constGroefAfstand - AchterwandDikte>
    pigment{rgb 1}
  }

  #local Bovenkant = object{
    Bodem translate<0, Hoogte - WandDikte, 0>
  }

  #local Achterwand = box{
    <-AchterwandBreedte/2, 0, Diepte - constGroefAfstand - AchterwandDikte>,
<AchterwandBreedte/2, Hoogte, Diepte - constGroefAfstand>
    pigment{rgb 1}
  }

  // echo stuklijst na renderen
  #debug concat("Stuklijst Korpus: ", str(Hoogte,0,1), " x ", str(Breedte,0,1),
" x ", str(Diepte,0,1), " mm\n")
  #debug
"----------------------------------------------------------------------------------------\n"
  #debug concat("Zijkant      2x : ", str(Hoogte,0,1), " x ", str(Diepte,0,1), "
x ", str(WandDikte,0,1), "mm\n")
  #debug concat("Bodem/Top    2x : ", str(BinnenBreedte,0,1), " x ", str(Diepte
- (15 + AchterwandDikte),0,1), " x " ,str(WandDikte,0,1), "mm\n")
  #debug concat("Achterwand   1x : ", str(Hoogte,0,1), " x ",
str(AchterwandBreedte,0,1), " x ", str(AchterwandDikte,0,1), "mm\n")

  union{
    object{LinkerZijde}
    object{RechterZijde}
    object{Bodem}
    object{Bovenkant}
    object{Achterwand}
  }
#end


#declare Hoogte = 600;
#declare Breedte = 300;
#declare Diepte = 250;
#declare WandDikte = 19;
#declare AchterwandDikte = 9;

#declare K = Korpus(Hoogte, Breedte, Diepte, WandDikte, AchterwandDikte)
object{
  K
  rotate <0,-30,0>
}

camera{
  angle 60
  location <Breedte , Hoogte / 2, -Hoogte*2>
  look_at <0, Hoogte/2,0>
}

light_source{
  <3000,1000,-1000>
  rgb 1
  shadowless
}
---%<---%<---

[Bald Eagle] Re: New arrival [92 days 18 hours and 35 minutes ago]

Mon, 19 Jan 2026 13:50:00 GMT

yesbird wrote:
Excellent choice, I head that Bambu's printers are stable in work and
produces high-quality models.

I've seen it used on machinist channels like Inheritance Machining,
and they were having a "sale", so I just ran with that.
Wasn't prepared to shell out for a high end machine, since I didn't
really know how much actual use it would get.

But it did set up fairly fast and produced some decent quality prints using the
default settings on my wobbly coffee table.

> Perhaps we should have a 3D printing sub-group....

I like this idea, although it's not POV-related. Looking forward
for shots of your printed models. :)

Then you're missing the point of the opening post.
People who are members of exclusive country clubs aren't there to play golf.
They're there to meet up with other people in the echelon and privately discuss
and arrange things that can't be done in board meetings, in offices on company
time, etc.

The 3D printing group is to attract people from outside the raytracing community
 to the POV-Ray forums, so that they can be exposed to raytracing via a program
that uses a virtually identical language.
They may read other posts, and be able to offer helpful insights, suggestions,
or even code.

People can look through the 3D printing group and see something that they've
wanted to model and ask, "How did you do that?"

When we raytrace, an object in an empty POV-space will look flat, boring, and
substandard.
When we include objects in a scene such as HDR lighting or anything outside the
field of view that the central object can reflect or be influenced by via
radiosity, then there's a richness that can be achieved that is impossible to
get by rendering the central object alone.  That was a lesson I learned trying
to implement iridescence - the bubbles needed something in the scene to
reflect/refract.

We cannot raytrace in a vacuum.
We cannot hyper-focus on "POV-Ray".
I only started making significant advances with what I do when I started
investigating ShaderToy, CAD/Cam, Unity, video games, mathematics, physics, c++,
and other topics in the large penumbra from which everything in POV-Ray
originates.

I am going to print surfaces from this resource:
http://3d-meier.de/tut3/Seite0.html

like here, for example:
https://www.ams.org/journals/notices/201208/rtx120801076p.pdf

Yeah - I have been periodically returning to my work on the Dupin Cyclide, and
so I'll probably try to make a wireframe Dupin Cyclide and maybe one with a
Steiner Chain of spheres inside.

- BE

P.S.
Also, he're's a direct crossover that is directly related to both 3D printing
and POV-Ray.  :D

https://www.thingiverse.com/thing:4229898

[yesbird] Re: New arrival [92 days 20 hours and 34 minutes ago]

Mon, 19 Jan 2026 11:51:07 GMT

On 19/01/2026 05:42, yesbird wrote:
> 
> I like this idea, although it's not POV-related. Looking forward
> for shots of your printed models. :)

I am going to print surfaces from this resource:
http://3d-meier.de/tut3/Seite0.html

using my MathView:
https://mathview.yesbird.online

like here, for example:
https://www.ams.org/journals/notices/201208/rtx120801076p.pdf
--
YB

[yesbird] Re: New arrival [93 days 5 hours and 43 minutes ago]

Mon, 19 Jan 2026 02:42:34 GMT

On 19/01/2026 04:53, Bald Eagle wrote:
> Bambu Labs P1S with the AMS unit.
> Just using the Bambu Studio slicer until I get accustomed to everything.

Excellent choice, I head that Bambu's printers are stable in work and 
produces high-quality models.

> Perhaps we should have a 3D printing sub-group....

I like this idea, although it's not POV-related. Looking forward
for shots of your printed models. :)
-- 
YB

[Bald Eagle] Re: New arrival [93 days 6 hours and 30 minutes ago]

Mon, 19 Jan 2026 01:55:00 GMT

yesbird wrote:

> What printer model do you have and what slicer are you using ?

Bambu Labs P1S with the AMS unit.
Just using the Bambu Studio slicer until I get accustomed to everything.

> I am happy with my CREALITY3D ENDER-3 Pro and Simplify3D for slicing.

Excellent.  It's always really just about what works.

I helped build a 3D printer from scratch, and reverse-engineered some Stratasys
stuff. There's always new materials, new techniques, and new tricks to push the
envelope with regard to what is possible.

Perhaps we should have a 3D printing sub-group....

- BE

[yesbird] Re: New arrival [93 days 8 hours and 21 minutes ago]

Mon, 19 Jan 2026 00:03:51 GMT

On 19/01/2026 01:11, Bald Eagle wrote:
> 
> No, not like that.
> My son was born 15 years ago.  :P
> 
> However, for his 15th birthday I thought maybe he'd enjoy a 3D printer.
> 
> And that has got me looking into OpenSCAD again.
> 

My congratulations to you and him !

Solid modelling always attracted me and I was working with
Autodesk Inventor and SolidWorks, preferring the first as less buggy ).

What printer model do you have and what slicer are you using ?
I am happy with my CREALITY3D ENDER-3 Pro and Simplify3D for slicing.
-- 
YB

[Bald Eagle] "License" [93 days 9 hours and 50 minutes ago]

Sun, 18 Jan 2026 22:35:00 GMT

This was a good, sensible read.

https://github.com/domgetter/NCoC

[Bald Eagle] New arrival [93 days 10 hours and 10 minutes ago]

Sun, 18 Jan 2026 22:15:00 GMT

No, not like that.
My son was born 15 years ago.  :P

However, for his 15th birthday I thought maybe he'd enjoy a 3D printer.

And that has got me looking into OpenSCAD again.

Looking over OpenSCAD, it reminded me that it - shall we say - bears a
*striking* resemblance to POV-Ray.
So much so, that A look at its source might be illuminating.

Now the interesting thing is that OpenSCAD is under active development, is free,
open-source, and has a number of libraries.

They've done Google Summer of Code and all that stuff.

We could likely benefit from a lot of the work that's been done on their
software, and I can see that there could be a lot of cross-over.

So I'm inviting folks to go over, check things out, and maybe borrow a few
models and render them in POV-Ray.  Maybe join the forums and post renders, make
the off-hand comment about how code in OpenSCAD and POV-Ray are (clearly, with
certain differences) nearly identical.  "Hey, this thing this guy rendered would
be pretty neat to 3D print..."  "Hey, that 3D print came out ok, but I'll bet it
would an even more amazing render..."

Talent, expertise, enthusiasm, a vibrant community of coders that are already
familiar with something that's almost exactly like SDL...

I mean, I'm hoping that this doesn't even need selling.

- BE

[Yvo Smellenbergh] POV-Ray 3.8 and 3.7.0.9 update available [100 days 17 hours and 56 minutes ago]

Sun, 11 Jan 2026 14:28:42 GMT

Please visit:
https://povrayunofficial.wordpress.com

Fixed OpenEXR output, updated Zlib, LibPNG, LibTiff and LibJPEG to the 
latest versions.
Fixed some minor bugs in the GUI.

Both versions are Intel and Apple Silion (universal binaries).
Runs on BigSur (11) and later, older system versions are no longer supported.

Best regards,


-- 
Yvo

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


https://povrayunofficial.wordpress.com
E-mail: yvo(DOT)s(AT)gmx.net

[Cousin Ricky] Re: odd behavior of photon reflection/refraction... [106 days 4 hours and 31 minutes ago]

Tue, 6 Jan 2026 03:54:30 GMT

On 2026-01-05 10:46, Kenneth wrote:
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.

The last time I used 'count' was around 20 years ago, back when I was
using a 1996 vintage laptop.  When I bought a new laptop in 2006, I
found new freedom with lots of RAM, and have been using only 'spacing'
for new scenes ever since.

[Alain Martel] Re: odd behavior of photon reflection/refraction... [106 days 16 hours and 42 minutes ago]

Mon, 5 Jan 2026 15:43:31 GMT

Le 2026-01-05 Ã  09:46, Kenneth a Ã©critÂ :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/2/26 20:44, Kenneth wrote:
>>>
>>> However: Given two (or more) 'target' objects in a scene, the photon behavior
>>> for each can be unexpectedly different, depending on whether 'count' vs.
>>> 'spacing' is used:
>>>
>>> A) With 'count':
>>> [snip]
>>>
>>> B) With 'spacing':
>>> [snip]
> 
>>
>> Re: (A) Interesting & news to me. I thought the count applied
>> independently to each target. Thanks for digging into the behavior!
>>
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.
> 
> -------------
> BTW (and a bit off-topic):
> Just out of curiosity, I tried adding the typical no_shadow and no_image flags
> to my photon 'target' object, to see what would happen...and either flag
> *eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
> 3.8). That does not *seem* to be an expected result to me-- based on what those
> flags are usually supposed to do-- but I'm still trying to wrap my brain around
> the logic it. IF those flags are operating correctly in this case, are photons
> 'shadow-based' in some way? That is, should photon caustics be regarded as
> light/SHADOW effects?
> 
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too.  My understanding of
> no_shadow is that it's only supposed to eliminate shadows that are cast *from*
> an object (my collector in this case) onto other objects.
> 
> Whether or not this is the designed/expected behavior of the two flags when
> photons are used, the practical result is that those objects will exhibit
> unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
> default for all objects when a global photons block is present).  And the use of
> no_shadow and no_image for scene 'workarounds' will not work without eliminating
> the caustics as well.
> 
> 
> 
> 
Then, we must remember that shadowless lights never case photons.

 From your test, it seems that disabling shadows also disable photons.

[Kenneth] Re: odd behavior of photon reflection/refraction... [106 days 17 hours and 35 minutes ago]

Mon, 5 Jan 2026 14:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/2/26 20:44, Kenneth wrote:
> >
> > However: Given two (or more) 'target' objects in a scene, the photon behavior
> > for each can be unexpectedly different, depending on whether 'count' vs.
> > 'spacing' is used:
> >
> > A) With 'count':
> > [snip]
> >
> > B) With 'spacing':
> > [snip]

>
> Re: (A) Interesting & news to me. I thought the count applied
> independently to each target. Thanks for digging into the behavior!
>

It was also a new discovery for me...as were Alain's comments when using
*multiple* lights and photon targets. In most of my old photon scenes, I used
'count' out of simplicity-- totally unaware of its various 'if/then/else'
results.

I'm beginning to think that 'count' should be deprecated going forward(!), since
'spacing' easily produces **expected** results, especially with the useful
numerical multiplier for a 'target'.

-------------
BTW (and a bit off-topic):
Just out of curiosity, I tried adding the typical no_shadow and no_image flags
to my photon 'target' object, to see what would happen...and either flag
*eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
3.8). That does not *seem* to be an expected result to me-- based on what those
flags are usually supposed to do-- but I'm still trying to wrap my brain around
the logic it. IF those flags are operating correctly in this case, are photons
'shadow-based' in some way? That is, should photon caustics be regarded as
light/SHADOW effects?

But what definitely seems strange is that adding no_shadow to my *collector*
object eliminated the caustics too.  My understanding of
no_shadow is that it's only supposed to eliminate shadows that are cast *from*
an object (my collector in this case) onto other objects.

Whether or not this is the designed/expected behavior of the two flags when
photons are used, the practical result is that those objects will exhibit
unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
default for all objects when a global photons block is present).  And the use of
no_shadow and no_image for scene 'workarounds' will not work without eliminating
the caustics as well.

[yesbird] Re: Inverse (object) panorama [107 days 19 hours and 14 minutes ago]

Sun, 4 Jan 2026 13:11:37 GMT

On 01/01/2026 13:08, Paul Bourke wrote:
> Physically between 0.5m to 0.8m.
> 
> For this process I render them at 6 million triangles, but that is mostly for
> the rigging and editing processes. Then can be safely reduced to about 1 million
> triangles. Currently a single 64Kx64K texture map.
> 
> Textured
>     https://vimeo.com/1150255426
> And just geometry
>     https://vimeo.com/1150255327
> 

Thanks so much for this info. Now I am trying to optimize 'Metashape'
process, taking into account 6048 x 4032 resolution of my new camera.

I would like to find a balance between model quality and users
devices performance to extend potential community. Few experiments
show that texture size is a serious limit, so I am producing few
model's versions with 4K, 8K, (16k in future).

Now looking for optimal number of triangles ...
-- 
YB

[William F Pokorny] Re: odd behavior of photon reflection/refraction... [108 days 11 hours and 59 minutes ago]

Sat, 3 Jan 2026 20:26:37 GMT

On 1/3/26 13:41, Alain Martel wrote:
> When you use count, the count value is the total number of photons to be 
> shot, distributed between all targets and all lights. The area, or 
> angular size, of the targets also play a role. A big target will tend to 
> get more photons than a small target next to it.
> 
> The photon shooting always try to keep the photon density constant 
> between all targets.
> 
> count 1 000 000
> two lights and two targets of roughly the same size, and each light will 
> shoot about 250 000 photons at each target.
> 
> Have three targets, and you shoot about 166 666 photons per light at 
> each target.

Thank you, Alain. More I didn't know! :-)

Bill P.

[Alain Martel] Re: odd behavior of photon reflection/refraction... [108 days 13 hours and 44 minutes ago]

Sat, 3 Jan 2026 18:41:11 GMT

Le 2026-01-03 Ã  11:15, William F Pokorny a Ã©critÂ :
> On 1/2/26 20:44, Kenneth wrote:
>> My original tests used only one 'target' object, so I tested again 
>> using two,
>> and you're right: A changed multiplier value does work now (for both 
>> targets),
>> even when 'count' is used in the global photons block. This little 
>> 'switch' in
>> behavior is undocumented, as far as I can tell.
>>
>> However: Given two (or more) 'target' objects in a scene, the photon 
>> behavior
>> for each can be unexpectedly different, depending on whether 'count' vs.
>> 'spacing' is used:
>>
>> A) With 'count':
>> Â Â Â Â Â  If two targets both
use a value of 1.0 (or simply 'on'), the 
>> 'count' of
>> Â Â Â Â Â  photons is*split up
evenly* between the two; each target gets 
>> half the
>> Â Â Â Â Â  count. But if one
target uses 1.0 and the other 0.2, the 0.2 
>> target*robs*
>> Â Â Â Â Â  photons from the 1.0
target, with the resulting visual caustic 
>> effect on
>> Â Â Â Â Â  surfaces looking
different from each one. But the total photon
>> Â Â Â Â  'count' remains the same.
>>
>> B) With 'spacing':
>> Â Â Â Â Â  Each target
is*independent*-- they each respond to their individual
>> Â Â Â Â Â  spacing-multiplier
values, no 'robbing' of photons...which means 
>> the total
>> Â Â Â Â Â  NUMBER of photons can
increase, to suit the situation. This would
>> Â Â Â Â Â  produce a more logical
and visually realistic result than 'count'.
> 
> Re: (A) Interesting & news to me. I thought the count applied 
> independently to each target. Thanks for digging into the behavior!
> 
> Bill P.

When you use count, the count value is the total number of photons to be 
shot, distributed between all targets and all lights. The area, or 
angular size, of the targets also play a role. A big target will tend to 
get more photons than a small target next to it.

The photon shooting always try to keep the photon density constant 
between all targets.

count 1 000 000
two lights and two targets of roughly the same size, and each light will 
shoot about 250 000 photons at each target.

Have three targets, and you shoot about 166 666 photons per light at 
each target.

[William F Pokorny] Re: odd behavior of photon reflection/refraction... [108 days 16 hours and 10 minutes ago]

Sat, 3 Jan 2026 16:15:11 GMT

On 1/2/26 20:44, Kenneth wrote:
> My original tests used only one 'target' object, so I tested again using two,
> and you're right: A changed multiplier value does work now (for both targets),
> even when 'count' is used in the global photons block. This little 'switch' in
> behavior is undocumented, as far as I can tell.
> 
> However: Given two (or more) 'target' objects in a scene, the photon behavior
> for each can be unexpectedly different, depending on whether 'count' vs.
> 'spacing' is used:
> 
> A) With 'count':
>       If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
>       photons is*split up evenly* between the two; each target gets half the
>       count. But if one target uses 1.0 and the other 0.2, the 0.2 target*robs*
>       photons from the 1.0 target, with the resulting visual caustic effect on
>       surfaces looking different from each one. But the total photon
>      'count' remains the same.
> 
> B) With 'spacing':
>       Each target is*independent*-- they each respond to their individual
>       spacing-multiplier values, no 'robbing' of photons...which means the total
>       NUMBER of photons can increase, to suit the situation. This would
>       produce a more logical and visually realistic result than 'count'.

Re: (A) Interesting & news to me. I thought the count applied 
independently to each target. Thanks for digging into the behavior!

Bill P.

[Kenneth] Re: odd behavior of photon reflection/refraction... [109 days 6 hours and 40 minutes ago]

Sat, 3 Jan 2026 01:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> >
> > BTW:
> > I think that the docs'  'target' default of 1.0 [the numerical multiplier]
> > also needs a small clarification (...) The 1.0 value also works when
> > 'count' is used [instead of 'spacing'] but incrementally changing the float
> > value has no effect.
> >
>
> The value after target has an effect on the density of the photons for
> the target object.
>
> Even when using count, target 0.5 should cause that object to receive 4
> times as many photons compared to target 1/on/true. When using count,
> this only has an effect when there are at least two target objects.
>

My original tests used only one 'target' object, so I tested again using two,
and you're right: A changed multiplier value does work now (for both targets),
even when 'count' is used in the global photons block. This little 'switch' in
behavior is undocumented, as far as I can tell.

However: Given two (or more) 'target' objects in a scene, the photon behavior
for each can be unexpectedly different, depending on whether 'count' vs.
'spacing' is used:

A) With 'count':
     If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
     photons is *split up evenly* between the two; each target gets half the
     count. But if one target uses 1.0 and the other 0.2, the 0.2 target *robs*
     photons from the 1.0 target, with the resulting visual caustic effect on
     surfaces looking different from each one. But the total photon
    'count' remains the same.

B) With 'spacing':
     Each target is *independent*-- they each respond to their individual
     spacing-multiplier values, no 'robbing' of photons...which means the total
     NUMBER of photons can increase, to suit the situation. This would
     produce a more logical and visually realistic result than 'count'.

Some of these behavioral differences are undocumented as well, or at least not
clearly.

[Paul Bourke] Re: Inverse (object) panorama [110 days 22 hours and 10 minutes ago]

Thu, 1 Jan 2026 10:15:00 GMT

"ingo" <nomail@nomail> wrote:
> "ingo" <nomail@nomail> wrote:
> > In the past I simulated one in POV-Ray by using a 1-3 pixel wide image and
> > animate that around a subject. Then stitch the images together.
>
> found it at
>
https://news.povray.org/povray.binaries.images/thread/%3C389290B0.58D1D188%40email.com%3E/
>
> ingo

That's also how I did it in the past.

[Paul Bourke] Re: Inverse (object) panorama [110 days 22 hours and 15 minutes ago]

Thu, 1 Jan 2026 10:10:00 GMT

yesbird wrote:
> On 27/12/2025 12:04, Paul Bourke wrote:
> > Still in love with the elegance of user_defined cameras. Here's the code for a
> > "inverse panorama", also known as an "object panorama".
> > ...
> It looks interesting and unusual, how large are models of puppets ?

Physical size or data size?

Physically between 0.5m to 0.8m.

For this process I render them at 6 million triangles, but that is mostly for
the rigging and editing processes. Then can be safely reduced to about 1 million
triangles. Currently a single 64Kx64K texture map.

Textured
   https://vimeo.com/1150255426
And just geometry
   https://vimeo.com/1150255327

[ingo] Re: Inverse (object) panorama [115 days and 10 minutes ago]

Sun, 28 Dec 2025 08:15:00 GMT

"ingo" <nomail@nomail> wrote:
> In the past I simulated one in POV-Ray by using a 1-3 pixel wide image and
> animate that around a subject. Then stitch the images together.

found it at
https://news.povray.org/povray.binaries.images/thread/%3C389290B0.58D1D188%40email.com%3E/

ingo

[ingo] Re: Inverse (object) panorama [115 days and 40 minutes ago]

Sun, 28 Dec 2025 07:45:00 GMT

"ingo" <nomail@nomail> wrote:
> In the past I simulated one in POV-Ray by using a 1-3 pixel wide image and
> animate that around a subject. Then stitch the images together.

found it at
https://news.povray.org/povray.binaries.images/thread/%3C389290B0.58D1D188%40email.com%3E/

ingo

[ingo] Re: Inverse (object) panorama [115 days 15 hours and 50 minutes ago]

Sat, 27 Dec 2025 16:35:00 GMT

yesbird wrote:
> On 27/12/2025 12:04, Paul Bourke wrote:
> > Still in love with the elegance of user_defined cameras. Here's the code for a
> > "inverse panorama", also known as an "object panorama".
> > ...
> It looks interesting and unusual, how large are models of puppets ?
> --

Slit camera's are nice, one can do strange things with them. I the past I
simulated one in POV-Ray by using a 1-3 pixel wide image and animate that around
a subject. Then stitch the images together.

for some inspiration:
https://www.flong.com/archive/texts/lists/slit_scan/index.html

Slit camera's are (also) used for photo finishes.

A fist attempt withe the user defined camera:
https://news.povray.org/povray.binaries.images/thread/%3CXnsA9DA8E84160EEseed7@news.povray.org%3E/?ttop=444438&toff=700

ingo

[yesbird] Re: Inverse (object) panorama [115 days 17 hours and 1 minute ago]

Sat, 27 Dec 2025 15:24:21 GMT

On 27/12/2025 12:04, Paul Bourke wrote:
> Still in love with the elegance of user_defined cameras. Here's the code for a
> "inverse panorama", also known as an "object panorama".
> ...
It looks interesting and unusual, how large are models of puppets ?
-- 
YB

[Paul Bourke] Inverse (object) panorama [115 days 23 hours and 20 minutes ago]

Sat, 27 Dec 2025 09:05:00 GMT

Still in love with the elegance of user_defined cameras. Here's the code for a
"inverse panorama", also known as an "object panorama".

// Object panorama camera
// (x,y) range from -0.5 to 0.5 each
#declare ZMIN = -0.45;            // Vertical range of camera
#declare ZMAX = 0.45;             // Determined by actual height range of the
object
#declare RANGE = 10;              // Distance of camera, wide FOV to
orthographic
#declare PANANGLE = radians(90);  // Pan panorama
camera {
   user_defined
   location {
      function { RANGE * cos(x*pi*2 + PANANGLE) }
      function { RANGE * sin(x*pi*2 + PANANGLE) }
      function { ZMIN + (y+0.5) * (ZMAX-ZMIN) }
   }
   direction {
      function { -cos(x*pi*2 + PANANGLE) }
      function { -sin(x*pi*2 + PANANGLE) }
      function { 0 }
   }
}

Instead of a slit camera at a single position rotating about a vertical axis,
one moves a slit camera on a circle around an object where the camera is looking
towards the center of the object. A bit weird, like all multi-point projections.
Some examples attached of some Chinese puppets.

[jr] Re: odd behavior of photon reflection/refraction... [123 days 10 hours and 20 minutes ago]

Fri, 19 Dec 2025 22:05:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > How do you fancy "having a go" at turning the "Perfect Mirror" thread into
> > a "FAQ" item ?  (or a draft for an added "Tip" based on your observations ?)
>
> Sorry for the delay in responding...real-life and holiday chores took over.
> Perhaps a combination of FAQ and B.E.'s all-inclusive test-scene idea would be
> the best approach to a better understanding of the current photons behavior; I
> will try to put together a draft FAQ (or addition to 'photon tips and tricks')
> after the New Year...once I get a clear scenario in my head of how best to
> approach it.

thank you very much.  on "second thought" :-), or perhaps as a wiki "How To"
item ?  (more "elbow room")


> Meanwhile, I continued testing in v3.8 beta 1-- and came across some
> *really* odd behavior of photons interacting with objects (which proved to be
> TEMPORARY, I am happy to say.)
> ...
> Near the end of this testing process, I decided to shut down v3.8 and run the
> scene in v3.7 instead, to compare results: NO odd behavior there, which was a
> good sign. So I brought it back to 3.8... and the problem had suddenly
> DISAPPEARED! I could not even reproduce it by fiddling with photon settings.
> ...
> Or was it just 'gremlins and goblins' playing with me?? I think that's the
> likely answer.  :-o

agree, they (machines) can have "a mind of their own", it seems at times.


regards, jr.

[Kenneth] Re: odd behavior of photon reflection/refraction... [124 days 12 hours and 25 minutes ago]

Thu, 18 Dec 2025 20:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> How do you fancy "having a go" at turning the "Perfect Mirror" thread into
> a "FAQ" item ?  (or a draft for an added "Tip" based on your observations ?)
>

12/18/25

Sorry for the delay in responding...real-life and holiday chores took over.

Perhaps a combination of FAQ and B.E.'s all-inclusive test-scene idea would be
the best approach to a better understanding of the current photons behavior; I
will try to put together a draft FAQ (or addition to 'photon tips and tricks')
after the New Year...once I get a clear scenario in my head of how best to
approach it.

Meanwhile, I continued testing in v3.8 beta 1-- and came across some
*really* odd behavior of photons interacting with objects (which proved to be
TEMPORARY, I am happy to say.)

Essentially, the parse time for my earlier test scene here wildly increased-- by
about 15X-- when I simply added an additional box object to the scene, on the
left side of my  light_source, and with no photons block in that object (thus
as a photon 'collector', the default behavior.) But such a gigantic parse-time
increase  made no sense whatsoever, and  I spent the better part of *three days*
trying to understand why it was occurring and how to eliminate it, running test
after test. (Adding a photon block with 'collect OFF' solved it..but that should
not have made such a big difference.)

Near the end of this testing process, I decided to shut down v3.8 and run the
scene in v3.7 instead, to compare results: NO odd behavior there, which was a
good sign. So I brought it back to 3.8... and the problem had suddenly
DISAPPEARED! I could not even reproduce it by fiddling with photon settings.

(At some point prior to my v3.7 test, I *might* have shut down my computer--
which I do on occasion, when I know I will be away from it for hours..but I
don't remember if or when.)  So did shutting it down 'fix' something in the
Windows registry? And/or did running 3.7 correct some temporary glitch in the
3.8 code? Or did Microsoft sneak-in a 'silent' Windows update while I wasn't
looking, breaking (OR fixing) something?

Or was it just 'gremlins and goblins' playing with me?? I think that's the
likely answer.  :-o

So my new and painfully-learned philosophy concerning the current 3.8 betas (1,
and most likely 2 as well) is this:

When unexpected  and unexplainable scene behavior suddenly occurs that makes no
sense, first RESTART the computer (or just POV-ray?) and test again!

Now that all is well, I continue testing photons...   :-)

[Leroy] Re: What is -1.#IO [124 days 13 hours and 55 minutes ago]

Thu, 18 Dec 2025 18:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Leroy" <whe### [at] gmailcom> wrote:
>
> > > #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
> > >
> > > Caused POV to Crash!
> >
> > That's weird - might be something that the parser doesn't handle well, but
> > crashing isn't acceptable.  Try -Inf
>
> Looks like it's likely a parser / tokenizer issue.
>

That statement never should have been tested. I was just moving to fast to
notice what I was doing. I got into the habit of typing away, hit RUN and fix
the errors that come. But this error caused it to crash!

 I did go back and test '#if(V2.x=V2.x) #debug"hit\n" #end' after I load V2 with
-1.#IO by using vaxis_rotate(<0,0,0>,<0,0,0>,35).

And I got a Hit!

Have Fun!

[Leroy] Re: What is -1.#IO [124 days 14 hours and 20 minutes ago]

Thu, 18 Dec 2025 18:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Following up,
>
> It looks like this is a general "undefined" state for Windows.
> My money is divide by zero error in normalizing the vector to unit length.
>
I agree.


> https://www.mathworks.com/matlabcentral/answers/31571-1-io-error-on-xpc
>
>
https://stackoverflow.com/questions/35997187/what-leads-to-the-floating-point-exception-1-io
>
> https://www.sierrachart.com/SupportBoard.php?ThreadID=14054
>
>
https://unmethours.com/question/24410/-1io-error-value-when-running-battery-storage-in-e/
>
> I'd simply check vlength (Vector) before proceeding, and exit early if a
> zero-length vector is the input.
>
Yea! That's what I did before I posted here. I just never seen -1.#IO before.
And the spline behavior through me. I thought I'd at less get an error saying
don't do that.

> (Using those values in a #if statement should still not crash POV-Ray)
>
Today I tried again to make it crash. And of course it didn't. All I get is :
Parse Error: Expected 'numeric expression', undeclared identifier 'IO' found
instead
Your second link here may have the answer. It said :

"That -1.#IO propogates to all of the other subroutines so eventually I have
thousands of variables with this exception before it blows up"

I did have my first test at the end of the file I was working on.

Have Fun!

[Bald Eagle] Re: What is -1.#IO [125 days 11 hours ago]

Wed, 17 Dec 2025 21:25:00 GMT

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

> > #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
> >
> > Caused POV to Crash!
>
> That's weird - might be something that the parser doesn't handle well, but
> crashing isn't acceptable.  Try -Inf

Looks like it's likely a parser / tokenizer issue.

Also, when comparing vectors, use
VEq(V1, V2). Tests for equal vectors, returns true if all three components of
V1equal the respective components of V2.

(IIRC, that's in math.inc)

-1.#IO is not a legal float literal in POV‑Ray’s SDL. Float literals only
allow digits, an optional decimal point, and optional scientific e/E notation—no
# characters. [wiki.povray.org], [cmp.felk.cvut.cz], [POV-Ray 3....n Page 93.]
In POV‑Ray, # is reserved to start language directives (e.g., #if,
#declare, #include). When the scanner encounters -1.#IO, it reads -1. as a
number but then sees # and tries to parse a directive #IO next—which is invalid
in that position and can confuse the parser. That’s why your line crashes
instead of producing a normal parse error. [povray.org], [POV-Ray: D...n
Language]

There’s also a second issue hidden in your expression:

The condition #if (V2 = <...>) is being treated as a relational equality test
(=) inside the #if (not an assignment). #if conditions must evaluate to a
float/boolean, but both sides here are vectors, which should yield “Float
expected but vector found.” You’re tripping the crash first due to the
illegal #
in the numeric token, but even with valid numbers you would need to compare
vectors via their components or length. [museum.state.il.us], [wiki.povray.org]

[Bald Eagle] Re: What is -1.#IO [125 days 14 hours ago]

Wed, 17 Dec 2025 18:25:00 GMT

Also check out:
https://www.johndcook.com/IEEE_exceptions_in_cpp.html

(I read a lot of John's blog posts - it's very interesting and informative)



Testing for NaNs and infinities
Next suppose you want to test whether a number is an infinity or a NaN. For
example, you may want to write to a log file print a debug message when a
numerical result goes bad, or you may want to execute some sort of alternate
logic in your code. There are simple, portable ways to get summary information
and more complicated, less portable ways to get more information.

First, the simple solution. If you want to test whether a double variable
contains a valid number, you can check whether x == x. This looks like it should
always be true, but it's not! Ordinary numbers always equal themselves, but NaNs
do not. I've used this trick on Windows, Linux, and Mac OSX. If you ever use
this trick, put big bold comments around your code so that some well-meaning
person won't come behind you and delete what he or she things is useless code.
Better yet, put the test in a well-documented function in a library that has
controlled access. The following function will test whether x is a (possibly
infinite) number.


    bool IsNumber(double x)
    {
        // This looks like it should always be true,
        // but it's false if x is a NaN.
        return (x == x);
    }

To test whether a variable contains a finite number, (i.e. not a NaN and not an
infinity) you can use code like the following.


    bool IsFiniteNumber(double x)
    {
        return (x <= DBL_MAX && x >= -DBL_MAX);
    }

Here DBL_MAX is a constant defined in float.h as the largest double that can be
represented. Comparisons with NaNs always fail, even when comparing to
themselves, and so the test above will fail for a NaN. If x is not a NaN but is
infinite, one of the two tests will fail depending on whether it is a positive
infinity or negative infinity.

[Bald Eagle] Re: What is -1.#IO [125 days 14 hours and 5 minutes ago]

Wed, 17 Dec 2025 18:20:00 GMT

1.#IO isn’t a real numeric value. It’s a Windows/MSVCRT formatting artifact
that shows up when you print a special floating‑point value (like infinity
or NaN) with certain precisions; the classic strings 1.#INF (infinity) or 1.#IND
(indeterminate/NaN) get mangled to 1.#IO. In other words, if you see 1.#IO, your
number was almost certainly infinite or not‑a‑number, and the way it
was formatted produced the odd “IO” text. [stackoverflow.com],
[johndcook.com],
[stackoverflow.com], [blog.csdn.net]

What it actually represents
On Windows, the C runtime historically prints special floating‑point
values like this:

1.#INF, -1.#INF — positive/negative infinity. [stackoverflow.com]
1.#IND, -1.#IND — indeterminate (a kind of NaN) produced by undefined operations
such as 0.0/0.0, sqrt(-1), etc. [stackoverflow.com], [johndcook.com]
1.#QNAN / 1.#SNAN — quiet/signaling NaNs (rarer to see directly).
[stackoverflow.com]

When you format those with certain precisions (e.g., printf("%.3f", x) or
fixed/scientific iostream manipulators), the internal #INF / #IND text can be
truncated/rounded into #IO. Demonstrations of %.3f producing -1.#IO and of
iostream precision turning 1.#INF into 1.#IO are documented and reproducible.
[stackoverflow.com], [blog.csdn.net]
So, 1.#IO is “one of those special values printed badly.” Treat it as
infinity
or NaN detected in your computation. [stackoverflow.com], [johndcook.com]

Typical causes (why you got it)
These usually create INF or NaN, which may print as #IO:

Division by zero (1.0/0.0 → +INF, -1.0/0.0 → -INF, 0.0/0.0 →
NaN). [johndcook.com]
Domain errors: sqrt(-1), log(-1), etc. → NaN. [johndcook.com]
Overflow to values too large for float/double → INF. [stackoverflow.com]
Formatting quirks with fixed precision or certain format specifiers (%.3f,
std::fixed << setprecision(3)), which turn #INF/#IND into #IO.
[stackoverflow.com], [blog.csdn.net]


How to detect and handle it correctly
Instead of relying on printed text, test the value:

C/C++ standard checks: std::isnan(x), std::isinf(x), std::fpclassify(x).
[en.cppreference.com]
MSVC‑specific: _isnan(x), _fpclass(x) (legacy). [learn.microsoft.com]

Example (C++):
C++#include <cmath>      // std::isnan, std::isinf, std::fpclassify#include
<iostream>void print_safe(double x) {       if (std::isnan(x))       std::cout
<< "NaN\n";    else if (std::isinf(x))  std::cout << (x > 0 ? "+INF\n" :
"-INF\n");    else                     std::cout << x << "\n";Show more lines
(Functions and behavior documented in the C/C++ libraries.)
[en.cppreference.com]

Practical tips (to avoid seeing 1.#IO)

Fix the math: guard against zero denominators and invalid domains; clamp inputs;
use safer formulations. (These are the root causes of INF/NaN.) [johndcook.com]
Change formatting: use %g or std::defaultfloat so special values print as
inf/nan on newer runtimes, or explicitly test and print “INF/NaN” yourself
as
shown above. [en.cppreference.com]
Diagnose quickly: add checks after any risky operation (division, sqrt/log,
exponentials of large mags). The “INF/NaN contamination” problem is
well‑known—once created, it propagates. [johndcook.com]


If you saw it in POV‑Ray output
POV‑Ray on Windows uses the same CRT for text formatting; if you emit
values (e.g., via #debug or write to a file) with fixed precision, 1.#IO can
appear when your scene math hits INF/NaN. The remedy is the same: guard your
calculations and test for isnan/isinf in any helper code before printing; or
change the format to avoid the mangled representation. (General CRT behavior and
formatting issues apply.) [en.cppreference.com], [stackoverflow.com]

- BE

[Bald Eagle] Re: What is -1.#IO [125 days 14 hours and 15 minutes ago]

Wed, 17 Dec 2025 18:10:00 GMT

Following up,

It looks like this is a general "undefined" state for Windows.
My money is divide by zero error in normalizing the vector to unit length.

https://www.mathworks.com/matlabcentral/answers/31571-1-io-error-on-xpc

https://stackoverflow.com/questions/35997187/what-leads-to-the-floating-point-exception-1-io

https://www.sierrachart.com/SupportBoard.php?ThreadID=14054

https://unmethours.com/question/24410/-1io-error-value-when-running-battery-storage-in-e/

I'd simply check vlength (Vector) before proceeding, and exit early if a
zero-length vector is the input.

(Using those values in a #if statement should still not crash POV-Ray)


- BE

[Bald Eagle] Re: What is -1.#IO [125 days 14 hours and 40 minutes ago]

Wed, 17 Dec 2025 17:45:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> 'vaxis_rotate' returns <-1.#IO,-1.#IO,-1.#IO>
> Or at less this is what POV prints out when checked.

Yeah, that's pretty crazy.
I've never even heard of that notation!

https://stackoverflow.com/questions/18249065/lua-file-output-what-is-1-io

> What was strange is that there never was an error when using the spline, it just
> didn't show any spheres or a few at the ends.

I'm guessing POV-Ray must have some sort of internal error handling for division
by zero / infinite values, and just runs with it.  That's not to say that what
you're doing will render correctly, as I observed with my trig scene.

> #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
>
> Caused POV to Crash!

That's weird - might be something that the parser doesn't handle well, but
crashing isn't acceptable.  Try -Inf

Also submit a bug report.

Does #if(V2.x =-1.#IO) cause a crash?

I'd run some similar experiments with inf, nan, etc. to see what happens

To get your scene to run, I'd test against some "very large value" and
early-exit if your value is greater than that.

- BE

[Leroy] What is -1.#IO [125 days 15 hours and 40 minutes ago]

Wed, 17 Dec 2025 16:45:00 GMT

I was playing with Splines using 'VPerp_To_Vector' & 'vaxis_rotate' to fill
arrays that made a spline. Then using a 'for' loop & the spline to place lots of
spheres.
The trouble started when <0,0,0> was used accidentally as input for the above.
'VPerp_To_Vector' returns <0,0,0>
'vaxis_rotate' returns <-1.#IO,-1.#IO,-1.#IO>
Or at less this is what POV prints out when checked.

What was strange is that there never was an error when using the spline, it just
didn't show any spheres or a few at the ends.

#if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end

Caused POV to Crash!

This was on version 3.7.0.msvc10.win64
And my computer: Window10
Processor Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz   3.30 GHz
Installed RAM 32.0 GB


Have Fun!

[jr] Re: odd behavior of photon reflection/refraction... [130 days and 5 minutes ago]

Sat, 13 Dec 2025 08:20:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> One thing that I did was have it generate ALL the possible permutations of light
> source and object, and I would suggest that part of the distribution be a scene
> that renders all the permutations.  That ought to put an end to any questions
> about how povray actually operates.

yes agree, a simple, "good" .pov/.ini combo which generates a corresponding set
of images would be very useful to have.  (if we had one "in hand", we could
start "badgering" Chris :-))

regards, jr.

[Bald Eagle] Re: odd behavior of photon reflection/refraction... [130 days 18 hours and 40 minutes ago]

Fri, 12 Dec 2025 13:45:00 GMT

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

> keep "us" in the loop please, wrt testing etc.

I have a lot of running around to do, so I'll only be able to sporadically play
with the output.

I'll post a zip of all the files that were generated, and maybe we can all
run/edit/debug the code, etc. and come up with something that makes sense.

One thing that I did was have it generate ALL the possible permutations of light
source and object, and I would suggest that part of the distribution be a scene
that renders all the permutations.  That ought to put an end to any questions
about how povray actually operates.

- BE

[jr] Re: odd behavior of photon reflection/refraction... [130 days 20 hours and 40 minutes ago]

Fri, 12 Dec 2025 11:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I had a window of time today, and set The AI to work on this.
>
> I have diagrams and charts and flowcharts and code.
>
> Still need to go through it all and test it out.
> I can post or forward the zips if you'd like.

keep "us" in the loop please, wrt testing etc.


regards, jr.

[jr] Re: odd behavior of photon reflection/refraction... [130 days 20 hours and 40 minutes ago]

Fri, 12 Dec 2025 11:45:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > I was thinking in terms of 'number' of photons rather
> > than spacing:
> > target 0.5-- the spacing between photons is reduced by half...whereas the number
> > of photons is...either doubled or quadrupled(?)-- like spacing/2
> > (or spacing/4 ?)
>
> "...like spacing/2 or spacing/4" ???
> Please ignore that bad analogy and arithmetic-- a result of 'over-thinking' :-[

no worries (hope that sort of thing doesn't keep you awake at night </grin>).

agree re the 'target', its description, will do that in the coming days.  how do
you fancy "having a go" at turning the "Perfect Mirror" thread in to a "FAQ"
item ?  (or a draft for an added "Tip" based on your observations ?)

regards, jr.

[Kenneth] Re: odd behavior of photon reflection/refraction... [130 days 21 hours and 35 minutes ago]

Fri, 12 Dec 2025 10:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I was thinking in terms of 'number' of photons rather
> than spacing:
>
> target 0.5-- the spacing between photons is reduced by half...whereas the number
> of photons is...either doubled or quadrupled(?)-- like spacing/2
> (or spacing/4 ?)
>

"...like spacing/2 or spacing/4" ???

Please ignore that bad analogy and arithmetic-- a result of 'over-thinking' :-[

[Bald Eagle] Re: odd behavior of photon reflection/refraction... [131 days 8 hours and 50 minutes ago]

Thu, 11 Dec 2025 23:35:00 GMT

I had a window of time today, and set The AI to work on this.

I have diagrams and charts and flowcharts and code.

Still need to go through it all and test it out.
I can post or forward the zips if you'd like.

- BE

[Kenneth] Re: odd behavior of photon reflection/refraction... [131 days 9 hours and 45 minutes ago]

Thu, 11 Dec 2025 22:40:00 GMT

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

>
> "The keyword target makes this object a target."  note, keyword alone.
> <wiki.povray.org/content/Reference:Photons#Photon_Global_Settings>

You're right about that. Although-- at the risk of sounding pedantic-- the
'default' block in the docs does not actually state it in an immediately useful
way. Instead, the only given default for target is 'target 1.0'.  In my ideal
world, I wish it was clearer:

target: OFF when no explicit target keyword is specified
target spacing: 1.0
>
> as I wrote, the syntax diagram says 'target [float]', a value of '1.0' simply
> ensures (I think) that "nothing changes" by default wrt photon spacing.

Yes, that's my understanding as well, and tests confirm it.

>  but, again aiui, 'refraction' and
> 'reflection' do not require the object to be a target.

Actually, an explicit 'target' *is* required (if my tests are any indication.)
In my test code earlier, in the photon blocks, use 'refraction on' in both the
light_source and the translucent box. Then comment-out 'target' in the
translucent box. The result: no refraction effects.
>
> also, fwiw, the documentation calls it a "spacing multiplier", rather than
> "divisor".  luckily, with '1.0', no difference :-).
>

Ah, yes, you're correct. I was thinking in terms of 'number' of photons rather
than spacing:

target 0.5-- the spacing between photons is reduced by half...whereas the number
of photons is...either doubled or quadrupled(?)-- like spacing/2
(or spacing/4 ?)

Sorry for the confusion.

[jr] Re: odd behavior of photon reflection/refraction... [131 days 12 hours and 15 minutes ago]

Thu, 11 Dec 2025 20:10:01 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > > Kenneth wrote:]
> > > > Would these be more appropriate for the docs' default?:
> > > > target 1.0     When 'spacing' is used in the global photons block
> > > > target on     When 'count' is used in the global photons block
> >
> > why 'on' ??
> > (do you actually want to add further "ambiguities" to the parsing ?
>
> Sorry to say that I did not do much testing of 'target' behavior until now-- and
> it is also a bit confusing to me.
>
> Given that the docs say that the default for an object is 'target 1.0'-- which
> should mean ON as I understand it (when *either* 'count' or 'spacing' is used ...

"The keyword target makes this object a target."  note, keyword alone.
<wiki.povray.org/content/Reference:Photons#Photon_Global_Settings>

as I wrote, the syntax diagram says 'target [float]', a value of '1.0' simply
ensures (I think) that "nothing changes" by default wrt photon spacing.

> ...
> So it seems that the target default is OFF for an object-- unless I am
> completely mistaken as the what 'default of target 1.0' means in the docs (other
> than as an explicit 'spacing divisor').

there isn't a photons "default" either w/out corresponding block, iiuc.  unsure
how 'collect' plays with 'target', but, again aiui, 'refraction' and
'reflection' do not require the object to be a target.

also, fwiw, the documentation calls it a "spacing multiplier", rather than
"divisor".  luckily, with '1.0', no difference :-).

regards, jr.

[Kenneth] Re: odd behavior of photon reflection/refraction... [131 days 13 hours and 50 minutes ago]

Thu, 11 Dec 2025 18:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> > > [Kenneth wrote:]
> > > Would these be more appropriate for the docs' default?:
> > > target 1.0     When 'spacing' is used in the global photons block
> > > target on     When 'count' is used in the global photons block
>
> why 'on' ??
> (do you actually want to add further "ambiguities" to the parsing ?)

"jr" <cre### [at] gmailcom> wrote:
>
> > > Kenneth wrote:]
> > > Would these be more appropriate for the docs' default?:
> > > target 1.0     When 'spacing' is used in the global photons block
> > > target on     When 'count' is used in the global photons block
>
> why 'on' ??
> (do you actually want to add further "ambiguities" to the parsing ?

Sorry to say that I did not do much testing of 'target' behavior until now-- and
it is also a bit confusing to me.

Given that the docs say that the default for an object is 'target 1.0'-- which
should mean ON as I understand it (when *either* 'count' or 'spacing' is used in
the global photons block, both of which I tested) -- here are my current
parse/render results in both 3.7 and 3.8 beta 1. I used my test code posted
earlier.

photons{} -- an empty photon block-- the default for 'target' is actually OFF,
not ON.

With NO photons block in an object, the default is likewise OFF, not ON.

photons{target} -- neither 1.0 nor ON explicitly stated-- the object *is* a
photon target, as expected from the explicit use of the keyword

photons{target 1.0} or photons{target on} -- likewise ON as expected.

So it seems that the target default is OFF for an object-- unless I am
completely mistaken as the what 'default of target 1.0' means in the docs (other
than as an explicit 'spacing divisor').

[Bald Eagle] Re: odd behavior of photon reflection/refraction... [131 days 17 hours and 15 minutes ago]

Thu, 11 Dec 2025 15:10:00 GMT

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

> am open to, and interested in, concrete suggestions to improve the photon
> documentation, wrt the "interplay" of features, and all touched on in these two
> threads; posted here or sent (pls use "helpful" subject line ;-)).

The best thing, IMHO, is for someone knowledgeable in the area, or who has the
patience and tenacity to work it out - to write a script / macro  whatever -
that takes the user input and properly outputs what will happen.

An accurate flowchart is a lot better than written documentation that has to be
interpreted.

In this case where there seems to be a lot of if/then/else, then a few lines of
code is worth 10 pages of documentation that the user still has to read,
interpret, comprehend, and then implement in their own code.

Don't document it.  Write the code to DO the thing.  Then anyone can understand
it, or barring that, make practical use of it.

- BE

[jr] Re: odd behavior of photon reflection/refraction... [131 days 17 hours and 30 minutes ago]

Thu, 11 Dec 2025 14:55:00 GMT

hi,

Alain Martel <kua### [at] videotronca> wrote:
> Le 2025-12-09 à 09:42, Kenneth a écrit :
> > Cousin Ricky <ric### [at] yahoocom> wrote:
> >> My results are the same with versions 3.5, 3.6.1, 3.7.0.10, and
> >> 3.8.0-beta.2, all on GNU/Linux.
> >
> > So at this late date, the bigger questions are:
> >
> > 1) What should be done about the documentation concerning the defaults?
> >
> > Given that the behavior is a complicated situation, it seems to me that the most
> > expedient 'fix' would be to issue a warning (of *some* kind)-- in both the docs
> > and during a render.  Something like:
> >
> > "Due to a long-standing quirk in the photons code, be aware that these default
> > values may be overridden and cause unexpected results. Best practice would be to
> > use explicit photon blocks and on/off keywords in your scenes."

so, it all started with radmac's "Perfect Mirror" question.  and looking at the
discussion since, it seems not so much about which feature(s) have which
default(s), but more about the interaction of various features when (not)
explicitly using the keywords and "qualifiers".

the documentation of photons includes both a FAQ and "Tips".  so, eg, the radmac
question (rephrased perhaps) and a precis of the answer/issues, could make a
"fine" entry in the FAQ, and a new Tip could be added wrt explicit use of
keywords (or "why not to rely on defaults" :-)).


> > 2) Should an attempt even be made to correct the underlying code, to bring it
> > into strict compliance with the stated defaults (given that these quirks have
> > been around 'since the beginning of time')? Doing so might alter the outcome of
> > *many* older scenes. However, there are precedents for such a large change: for
> > example, the 'emission' keyword (and its message warning about a too-high
> > ambient value); and radiosity now automatically turning off 'ambient' light.
> > These two changes also required older scenes to be edited.

no :-).  an addendum (addenda, really) to the documentation would be my
preference.


> > BTW:
> > I think that the docs'  'target' default of 1.0 also needs a small
> > clarification, since a numerical value is only meant to apply when 'spacing' is
> > used in the global photos block.  Of course, the 1.0 value  also works when
> > 'count' is used instead-- but as just a Boolean operator in that case(?)-- and
> > incrementally changing the float value has no effect.
> >
> > However, a simple 'on' can also be used, again in either case... but the docs
> > don't mention it.

well, 'target [float]' is documented.  it would be nice if a future parser/SDL
was free from those aspects.


> > Would these be more appropriate for the docs' default?:
> > target 1.0     When 'spacing' is used in the global photons block
> > target on     When 'count' is used in the global photons block

why 'on' ??  (do you actually want to add further "ambiguities" to the parsing ?
:-))


> The value after target have an effect on the density of the photons for
> the target object.
>
> Even when using count, target 0.5 should cause that object to receive 4
> times as many photons compared to target 1/on/true. When using count,
> this only have an effect when there are at least two target objects.
>
> Useful when one object is very simple, like a simple box, and the other
> have a complex geometry, like a faceted gem.

am open to, and interested in, concrete suggestions to improve the photon
documentation, wrt the "interplay" of features, and all touched on in these two
threads; posted here or sent (pls use "helpful" subject line ;-)).


regards, jr.

[Alain Martel] Re: odd behavior of photon reflection/refraction... [133 days 16 hours and 8 minutes ago]

Tue, 9 Dec 2025 16:17:33 GMT

Le 2025-12-09 Ã  09:42, Kenneth a Ã©critÂ :
> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>> My results are the same with versions 3.5, 3.6.1, 3.7.0.10, and
>> 3.8.0-beta.2, all on GNU/Linux.
>>
> 
> So at this late date, the bigger questions are:
> 
> 1) What should be done about the documentation concerning the defaults?
> 
> Given that the behavior is a complicated situation, it seems to me that the most
> expedient 'fix' would be to issue a warning (of *some* kind)-- in both the docs
> and during a render.  Something like:
> 
> "Due to a long-standing quirk in the photons code, be aware that these default
> values may be overridden and cause unexpected results. Best practice would be to
> use explicit photon blocks and on/off keywords in your scenes."
> 
> 2) Should an attempt even be made to correct the underlying code, to bring it
> into strict compliance with the stated defaults (given that these quirks have
> been around 'since the beginning of time')? Doing so might alter the outcome of
> *many* older scenes. However, there are precedents for such a large change: for
> example, the 'emission' keyword (and its message warning about a too-high
> ambient value); and radiosity now automatically turning off 'ambient' light.
> These two changes also required older scenes to be edited.
> 
> -----------
> BTW:
> I think that the docs'  'target' default of 1.0 also needs a small
> clarification, since a numerical value is only meant to apply when 'spacing' is
> used in the global photos block.  Of course, the 1.0 value  also works when
> 'count' is used instead-- but as just a Boolean operator in that case(?)-- and
> incrementally changing the float value has no effect.
> 
> However, a simple 'on' can also be used, again in either case... but the docs
> don't mention it.
> 
> Would these be more appropriate for the docs' default?:
> target 1.0     When 'spacing' is used in the global photons block
> target on     When 'count' is used in the global photons block
> 
> 
> 

The value after target have an effect on the density of the photons for 
the target object.

Even when using count, target 0.5 should cause that object to receive 4 
times as many photons compared to target 1/on/true. When using count, 
this only have an effect when there are at least two target objects.

Useful when one object is very simple, like a simple box, and the other 
have a complex geometry, like a faceted gem.

[Kenneth] Re: odd behavior of photon reflection/refraction... [133 days 17 hours and 40 minutes ago]

Tue, 9 Dec 2025 14:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> My results are the same with versions 3.5, 3.6.1, 3.7.0.10, and
> 3.8.0-beta.2, all on GNU/Linux.
>

So at this late date, the bigger questions are:

1) What should be done about the documentation concerning the defaults?

Given that the behavior is a complicated situation, it seems to me that the most
expedient 'fix' would be to issue a warning (of *some* kind)-- in both the docs
and during a render.  Something like:

"Due to a long-standing quirk in the photons code, be aware that these default
values may be overridden and cause unexpected results. Best practice would be to
use explicit photon blocks and on/off keywords in your scenes."

2) Should an attempt even be made to correct the underlying code, to bring it
into strict compliance with the stated defaults (given that these quirks have
been around 'since the beginning of time')? Doing so might alter the outcome of
*many* older scenes. However, there are precedents for such a large change: for
example, the 'emission' keyword (and its message warning about a too-high
ambient value); and radiosity now automatically turning off 'ambient' light.
These two changes also required older scenes to be edited.

-----------
BTW:
I think that the docs'  'target' default of 1.0 also needs a small
clarification, since a numerical value is only meant to apply when 'spacing' is
used in the global photos block.  Of course, the 1.0 value  also works when
'count' is used instead-- but as just a Boolean operator in that case(?)-- and
incrementally changing the float value has no effect.

However, a simple 'on' can also be used, again in either case... but the docs
don't mention it.

Would these be more appropriate for the docs' default?:
target 1.0     When 'spacing' is used in the global photons block
target on     When 'count' is used in the global photons block

[jr] Re: Perfect mirror [134 days 14 hours and 25 minutes ago]

Mon, 8 Dec 2025 18:00:00 GMT

hi,

just to say.

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

thank you, and Kenneth (and CR just now) for the follow up.

@Kenneth.  got the code, *thank you* for investigating.

will get back to NG in a couple of days or so.


regards, jr.

[Cousin Ricky] Re: odd behavior of photon reflection/refraction... [134 days 15 hours and 1 minute ago]

Mon, 8 Dec 2025 17:24:34 GMT

On 2025-12-08 07:46 (-4), Kenneth wrote:
> 
> 1) With *defaults* for both light_source and object, there are NO refraction
> effects. This agrees with the documentation: one default (or both?) are OFF.
> 
> 2a) With default for the light_source and 'refraction on' for the object, there
> ARE refraction effects. So in this case, the default OFF for the light_source is
> apparently ON instead (or has been overridden.)
> 
> 2b) With 'refraction off' for light_source and 'refraction on' for object, NO
> refraction effects, as expected.
> 
> 3a) With 'refraction off' for light_source and *default* for object, NO
> refraction effects, as expected.
> 
> 3b) With 'refraction on' for light_source and *default* for object, there ARE
> refraction effects. So in this case, the default OFF for the object is
> apparently ON instead (or has been overridden.)
> 
> From these results, it is apparent that the default behaviors are not
> reliable and could cause unexpected rendering effects-- especially when there
> are multiple objects and lights in a scene, each with its own photon block. (The
> workaround would be to explicitly state ON or OFF for the various
> parameters...and not rely on the defaults at all, unfortunately.)

We seem to have 3 categories of scenarios:

1. With no light_source photons block or with an empty light_source
photons block, we get caustics only from explicit refraction on target
objects

2. With light_source { photons { refraction off } }, we get no caustics
from any object.

3. With light_source { photons { refraction on } }, we get caustics from
all target objects by default.

My results are the same with versions 3.5, 3.6.1, 3.7.0.10, and
3.8.0-beta.2, all on GNU/Linux.

My experience has been the same as Alain's.  I only use a light_source
photons block to turn photons off.

Of course, when we add reflection, we get more permutations, but I've
never had occasion to turn one off without the other in a light_source.

none = no photons block
empty = photons { }
target = photons { target }
target, off = photons { target refraction off }
target, on = photons { target refraction on }

[Kenneth] odd behavior of photon reflection/refraction def... [134 days 20 hours and 35 minutes ago]

Mon, 8 Dec 2025 11:50:00 GMT

[Running Windows 10. Tested in both 'official' v3.7.0 and 3.8 beta 1; the
results are the same]

Following up on some preliminary discussions here...
https://news.povray.org/povray.general/thread/%3C69366bae%241%40news.povray.org%3E/

The documentation at "3.4.4.4.3 Photon Global Settings" (for v3.7.0) and
"3.4.3.4.3 Photon Global Settings" (for 3.8) both say this about the default
values for 'reflection' and 'refraction', in objects and light_sources:

Object :
refraction    : off
reflection    : off

Light_source:
refraction    : off
reflection    : off

(As usual, 'default' means commenting-out a keyword, or leaving it out
altogether.)

I've been running a series of photon tests, and it seems that these defaults
actually change (or are overridden) in certain circumstances. Whether or not
this is by design, I don't know; but at the very least, the behavior can cause
unexpected results in a render.

I originally thought that a particular type of light_source was the cause, but
that proved to be false.

I have included a simple test scene below-- using only 'refraction' since it's
quicker to render-- but the same behavior applies to 'reflection'.

Here are some examples of the default 'refraction' behaviors, in the photon
blocks for both the object and the light_source. (This should really be in the
form of a 'truth table' rather than my clumsy descriptions):

1) With *defaults* for both light_source and object, there are NO refraction
effects. This agrees with the documentation: one default (or both?) are OFF.

2a) With default for the light_source and 'refraction on' for the object, there
ARE refraction effects. So in this case, the default OFF for the light_source is
apparently ON instead (or has been overridden.)

2b) With 'refraction off' for light_source and 'refraction on' for object, NO
refraction effects, as expected.

3a) With 'refraction off' for light_source and *default* for object, NO
refraction effects, as expected.

3b) With 'refraction on' for light_source and *default* for object, there ARE
refraction effects. So in this case, the default OFF for the object is
apparently ON instead (or has been overridden.)

From these results, it is apparent that the default behaviors are not
reliable and could cause unexpected rendering effects-- especially when there
are multiple objects and lights in a scene, each with its own photon block. (The
workaround would be to explicitly state ON or OFF for the various
parameters...and not rely on the defaults at all, unfortunately.)

-----------
[test scene]

#version 3.7; // or 3.8
global_settings {
   assumed_gamma 1
   photons {count 100000}
}

camera {
  perspective
  location  <-2, 0, -10>
  look_at   <1.5, 0,  0>
  right     x*image_width/image_height
  angle 55
}

background{rgb .05}

//--------------
light_source {
   <-3,0,0>
   color rgb <0, 1, 0>
   /*
   spotlight
   radius 6
   falloff 8
   tightness 10
   point_at <5,0,0>
   */
   photons {
   refraction on
   reflection off
           }
   looks_like{
    sphere{0,.1
    pigment{rgb 1}
    finish{ambient 1 emission 0 diffuse 0}
          }
             }
}

box { // translucent
   0,1 translate -.5
   scale <.3,6,4>
   pigment { rgbt <1,1,1,.7> }
   normal{bumps scale .3 bump_size 1}

   interior{ior 1.2}

   photons {
      target 1.0
      refraction on
      collect off
           }
}

//---------------
// additional box surface, to show refraction effects
box {
   0,1 translate -.5
   scale <.3,6,4>
   rotate -30*y
   translate 5*x
   pigment { rgb 1 }
   finish{ambient 0 emission 0 diffuse .95}
   photons{collect on} // (ON by default)
   }

[William F Pokorny] Re: Perfect mirror [135 days 2 hours and 15 minutes ago]

Mon, 8 Dec 2025 06:09:50 GMT

On 12/7/25 10:34, Kenneth wrote:
> "jr" <cre### [at] gmailcom> wrote:
>>
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>>
>>> So there is some confusion here. I haven't yet looked at the online wiki
>>> docs to double-check...
>>
>> thank you.  (before changing/updating the docs) can someone looking at the
>> sources confirm the defaults, please ?
>>
> 
> In v3.8 beta 1, I've been running a series of tests (on just the photon
> 'refraction' defaults, not 'reflection' so far), using a modified version of the
> OP's code here-- and there seems to be a mixed-up interaction of on/off/default
> in the photons blocks of the light_source and the refracting object. In other
> words, the *default* behavior changes(!) when other changes are made in one or
> the other of the blocks. Sorry that I cannot be more specific yet, as I am still
> testing and trying to make sense of the results. But as it's off-topic here,
> I'll try to post a follow-up in a new thread.
> 
> I don't yet know if these odd results are specific to the 3.8 betas...and/or to
> the OP's specific cylinder light_source...
> 

I believe for the v3.7 / v3.8 versions, including yuqk, the 
documentation which is 'likely' wrong isn't with the light_source{} 
photon{} block, but the object's photon{} block - where the reflection 
and refraction defaults are 'on'.

---

What Kenneth is seeing is true too - there are some complicated 
dependencies and detail when dealing with photons.

For example, and using the updated scene I posted moving the beam light 
source outside the media box and using the photon mechanism for all 
light intensity calculations, if we set the beam light_source photon 
block's refraction to 'off' we get no photons deposited anywhere. The 
photon tracing stops at the first media box's transparent surface.

The same is true if we set the media box's photon block refraction 'off' 
while the light source's refraction is 'on' - no photons. The object's 
setting overrides the light's in that case.

However, if we turn the light source's photon refraction 'off' and the 
media box's refraction 'on', the light source's setting wins at the 
first media container's surface rather than the object's setting.

OK behavior I think, but not simple.

---

Secondary questions pop into my head: Does having an ior of other than 
one changes the specific behavior above? When we have transparent 
surfaces and ray reflection/fraction ray splitting, do the light's 
photon block's reflection/refraction settings continue to propagate in 
the same ways? What happens when we use, 'magic light transport', pass 
thru objects with light sources?

As Kenneth mentioned, there are too some differences in behavior 
depending upon the light source type. The cylindrical light working (at 
least sometimes) within objects containing media - bending our media 
light sources must be outside media containers rule.

Bill P.

[jr] Re: Perfect mirror [135 days 2 hours and 30 minutes ago]

Mon, 8 Dec 2025 05:55:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ... In other words, the *default* behavior changes(!) when other changes
> are made in one or the other of the blocks. Sorry that I cannot be more
> specific yet, ...

thank you for digging up info / "investigating", appreciated.


regards, jr.

[Alain Martel] Re: Perfect mirror [135 days 16 hours and 10 minutes ago]

Sun, 7 Dec 2025 16:15:39 GMT

Le 2025-12-06 Ã  15:41, Kenneth a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
>>
>>> In your two light sources, I added 'refraction off' to the photon blocks.
>>> Since your mirror is only 'reflecting' light, refraction is not needed. As far
>>> as I can tell, the docs do not mention what the default behavior is--
>>> on or off.
>>
>>
>> Since version 3.6. By default, all light_source, except shadowless
>> lights, have the following photons block :
>> {
>>   reflection on
>>   refraction on
>> }
>>
> 
> In the v3.8 documentation, I did finally find the default behavior at "3.4.3.4.3
> Photon Global Settings"-- but it actually states the opposite(!) :
> 
> All photons default values:
> 
> Light_source:
> area_light    : off
> refraction    : off
> reflection    : off
> 
> So there is some confusion here. I haven't yet looked at the online wiki docs to
> double-check...
> 
> 

And, in my experience, photons work just right WITHOUT any photons block 
in any light_source.

I only add one when I want a light to NOT shoot photons or to activate 
the area_light support.

[Kenneth] Re: Perfect mirror [135 days 16 hours and 50 minutes ago]

Sun, 7 Dec 2025 15:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > So there is some confusion here. I haven't yet looked at the online wiki
> > docs to double-check...
>
> thank you.  (before changing/updating the docs) can someone looking at the
> sources confirm the defaults, please ?
>

In v3.8 beta 1, I've been running a series of tests (on just the photon
'refraction' defaults, not 'reflection' so far), using a modified version of the
OP's code here-- and there seems to be a mixed-up interaction of on/off/default
in the photons blocks of the light_source and the refracting object. In other
words, the *default* behavior changes(!) when other changes are made in one or
the other of the blocks. Sorry that I cannot be more specific yet, as I am still
testing and trying to make sense of the results. But as it's off-topic here,
I'll try to post a follow-up in a new thread.

I don't yet know if these odd results are specific to the 3.8 betas...and/or to
the OP's specific cylinder light_source...

[jr] Re: Perfect mirror [135 days 22 hours and 45 minutes ago]

Sun, 7 Dec 2025 09:40:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> Alain Martel <kua### [at] videotronca> wrote:
> > ...
> > Since version 3.6. By default, all light_source, except shadowless
> > lights, have the following photons block :
> > {
> >  reflection on
> >  refraction on
> > }
> >
> In the v3.8 documentation, I did finally find the default behavior at "3.4.3.4.3
> Photon Global Settings"-- but it actually states the opposite(!) :
>
> All photons default values:
>
> Light_source:
> area_light    : off
> refraction    : off
> reflection    : off
>
> So there is some confusion here. I haven't yet looked at the online wiki docs to
> double-check...

thank you.  (before changing/updating the docs) can someone looking at the
sources confirm the defaults, please ?


regards, jr.

[William F Pokorny] Re: Perfect mirror [136 days 2 hours and 18 minutes ago]

Sun, 7 Dec 2025 06:07:19 GMT

On 12/5/25 09:51, radmac wrote:
> How does one create perfect mirror to reflect beam of light in scattering media?
> In attached scene, the reflected beam is clearly different from the incident
> one.

In your posted scene, mostly, what is causing the difference in 
intensity is that the beam for the light source to the mirror path is 
being calculated by the scattering media mechanism, while the reflected 
beam is being calculated by the photon mechanism.

Attached a modified version of your posted scene and four images (No 
AA). The scene has been updated to calculate both paths light intensity 
with the photon mechanism. For all changes look for '***'.

In the attached image the left column is POV-Ray version 3.8 beta 2; The 
right column is my yuqk fork - which has a fix for the photon banding.

The top row has 'media_interaction on' for the beam light - with the 
photons now used for both paths, the difference in intensity between 
paths due the scattering component is even more apparent. The bottom row 
turns 'media_interaction off' for the beam light - both beam path 
segments are now calculated solely by the photon mechanism.

Bill P.

Aside: The general rule with light sources and media is that the light 
source should be outside any media container by some small value.

[Kenneth] Re: Perfect mirror [136 days 11 hours and 40 minutes ago]

Sat, 6 Dec 2025 20:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
>
> > In your two light sources, I added 'refraction off' to the photon blocks.
> > Since your mirror is only 'reflecting' light, refraction is not needed. As far
> > as I can tell, the docs do not mention what the default behavior is--
> > on or off.
>
>
> Since version 3.6. By default, all light_source, except shadowless
> lights, have the following photons block :
> {
>  reflection on
>  refraction on
> }
>

In the v3.8 documentation, I did finally find the default behavior at "3.4.3.4.3
Photon Global Settings"-- but it actually states the opposite(!) :

All photons default values:

Light_source:
area_light    : off
refraction    : off
reflection    : off

So there is some confusion here. I haven't yet looked at the online wiki docs to
double-check...

[Alain Martel] Re: Perfect mirror [136 days 12 hours and 29 minutes ago]

Sat, 6 Dec 2025 19:56:19 GMT

Le 2025-12-06 Ã  00:57, Kenneth a Ã©critÂ :
> In your global_settings block, try these photon values instead:
> 
> photons {count 200000 media 600, 2}
> 
> That seems to eliminate the 'banding' and fuzziness in the reflected laser
> light.
> 
> Also, just as a safety measure, I added 'collect off' to the photon blocks in
> your media box and the mirror box. According to the docs, it is 'on' by default.
> But those object don't actually need photon effects to show up *on* them-- if I
> correctly understand what 'collect' means. Although, I didn't notice any
> render-time difference by turning it off.
> 
> In your two light sources, I added 'refraction off' to the photon blocks there.
> Since your mirror is only 'reflecting' light, refraction is not needed. As far
> as I can tell, the docs do not mention what the default behavior is-- on or off.


Since version 3.6. By default, all light_source, except shadowless 
lights, have the following photons block :
{
	reflection on
	refraction on
}

Up to version 3.5, the states where the opposite.

[Kenneth] Re: Perfect mirror [137 days 2 hours and 25 minutes ago]

Sat, 6 Dec 2025 06:00:00 GMT

In your global_settings block, try these photon values instead:

photons {count 200000 media 600, 2}

That seems to eliminate the 'banding' and fuzziness in the reflected laser
light.

Also, just as a safety measure, I added 'collect off' to the photon blocks in
your media box and the mirror box. According to the docs, it is 'on' by default.
But those object don't actually need photon effects to show up *on* them-- if I
correctly understand what 'collect' means. Although, I didn't notice any
render-time difference by turning it off.

In your two light sources, I added 'refraction off' to the photon blocks there.
Since your mirror is only 'reflecting' light, refraction is not needed. As far
as I can tell, the docs do not mention what the default behavior is-- on or off.

The most important change I made was in your media box:

media {
    scattering { 1, 1 extinction 0 }
    samples 6 // originally 100
      }

With this lower samples value, I don't see much (if any) difference in the
appearance of the media/light interaction...and the scene renders at least 10X
faster!

> Also, it is possible that the mirror reflect only the light directly from the
> source and not the scattered one (so we do not see the scattered beam on the
> mirror)?

If I understand your question, the only way to get a reflected light beam to
show up in POV-ray is to use photons (as well as media, to interact with the
'photons'.) Or do you mean the reflected appearance of the two light beams *in*
the mirror? That's just typical behavior of the mirror itself.

[jr] Re: Perfect mirror [137 days 16 hours and 45 minutes ago]

Fri, 5 Dec 2025 15:40:00 GMT

hi,

"radmac" <nomail@nomail> wrote:
> How does one create perfect mirror to reflect beam of light in scattering media?

<wiki.povray.org/content/Reference:Finish#Diffuse_Reflection_Items>, see the
section "Specular Reflection" for perfect mirror.


regards, jr.

[radmac] Perfect mirror [137 days 17 hours and 30 minutes ago]

Fri, 5 Dec 2025 14:55:00 GMT

How does one create perfect mirror to reflect beam of light in scattering media?
In attached scene, the reflected beam is clearly different from the incident
one. It is (a) wider, (b) weaker [maybe due to (a)] and (c) contains some
fringes. So if I want reflected beam to look identical to incident one (just
like if the second source is placed at the position of the mirror), what should
I do?

Also, it is possible that the mirror reflect only the light directly from the
source and not the scattered one (so we do not see the scattered beam on the
mirror)?

#declare BOX_X = 10*(4/3);
#declare BOX_Y = 10;
#declare BOX_Z = 0.5;
#declare MIR_S = 1;
#declare MIR_W = 0.2;

global_settings {
   assumed_gamma 1
   photons { count 100000 media 100, 2 }
}

camera {
   location <BOX_X/2, BOX_Y/2, -10>
   look_at  <BOX_X/2, BOX_Y/2, +10>
}

light_source { // ambient light
   <BOX_X/2, BOX_Y/2, BOX_Z/2>
   color rgb 1
   photons { reflection off }
   media_interaction off
}

box { // scattering media
   <0, 0, 0>, <BOX_X, BOX_Y, BOX_Z>
   pigment { rgbt 1 }
   hollow
   interior {
      media {
         scattering { 1, 1 extinction 0 }
         samples 100
      }
   }
   photons { pass_through }
}

light_source { // laser beam
   <0, 0, BOX_Z/2>
   color rgb <0, 1, 0>
   cylinder
   radius 0.01
   falloff 0.2
   point_at <BOX_X, BOX_Y/2, BOX_Z/2>
   photons { reflection on }
}

box { // mirror
   <BOX_X-MIR_W-MIR_S, MIR_S, MIR_S>, <BOX_X-MIR_S, BOX_Y-MIR_S, BOX_Z-MIR_S>
   pigment { rgb 1 }
   finish { reflection 1 }
   photons { target reflection on }
}

[William F Pokorny] Re: Did Friedrich A. Lohmueller pass away? [138 days 17 hours and 30 minutes ago]

Thu, 4 Dec 2025 14:55:05 GMT

On 11/23/25 08:48, jr wrote:
> @WFP
> the summaries now list 221 countries, but Christmas Island has yet to "dial in".

Bummer :-). Thanks for the update & stats!

Bill P.

[jr] Re: Custom output filenames [143 days and 35 minutes ago]

Sun, 30 Nov 2025 07:50:00 GMT

hi,

"stevenvh" <nomail@nomail> wrote:
> ...
> ... Now
>
>     Post_Scene_Command = c:RenumberPOVrayFiles.exe %s
>
> indeed runs my program, but the parameter %s is still not recognized.

check your program ?

fwiw, I'd write a simple shell script, and supply and check the expansion of the
seven substitutions available.

<wiki.povray.org/content/Reference:Shell_Command_Options>

regards, jr.

[stevenvh] Re: Custom output filenames [143 days 14 hours and 55 minutes ago]

Sat, 29 Nov 2025 17:30:00 GMT

"stevenvh" <nomail@nomail> wrote:
> "stevenvh" <nomail@nomail> wrote:
>
> > Current issue:
> > when I add the line
> >
> >     Post_Scene_Command = c:RenumberPOVrayFiles.exe %s
> >
> > nothing happens, my program doesn't run. Is my understanding of
> > "Post_Scene_Command" wrong?
> > Also, the"%s" in the command is just the filename without the path. I need that
> > path in my program (I have a select folder command there), which I hoped to
> > automate.
> >

FYI, I found that execution of external programs is disabled by default. You can
enable it in "Options" -> "Script I/O restrictions" and uncheck "Disable
starting other programs". Now

    Post_Scene_Command = c:RenumberPOVrayFiles.exe %s

indeed runs my program, but the parameter %s is still not recognized.

[Kenneth] Re: user_define camera and undefined location an... [144 days 20 hours and 45 minutes ago]

Fri, 28 Nov 2025 11:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The background *within* your box map does indeed show up as green now-- but does
> PB's question concern the *surrounding* area? That renders as black, regardless
> of the background color.

[running v3.8 beta 1]

I just discovered by chance that adding Output_Alpha=on (or +ua) makes the
surrounding area transparent, rather than black--if that has any practical use.

[Bald Eagle] Re: user_define camera and undefined location an... [146 days 19 hours and 15 minutes ago]

Wed, 26 Nov 2025 13:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> The background *within* your box map does indeed show up as green now-- but does
> PB's question concern the *surrounding* area? That renders as black, regardless
> of the background color.

Go to the camera page on the wiki.

User defined projection
New to version 3.8 a user defined camera capability was added.
Similar to the mesh camera  <---

Mesh:
Keep in mind that a ray that is not associated with a face is not the same thing
as a ray that is but that, when shot, hits nothing.

The latter will return a pixel (even if it is transparent or the background
color),

whereas the former causes the ray to not be shot in the first place; hence, it
is not included in the calculation of the average for the pixel.

So hopefully you can parse that and see why the two are different.

- BW

[Kenneth] Re: user_define camera and undefined location an... [147 days 7 hours ago]

Wed, 26 Nov 2025 01:25:00 GMT

"ingo" <nomail@nomail> wrote:
> "Paul Bourke" <pau### [at] gmailcom> wrote:
> >
> > For example, for a fisheye the points outside the circle are
> > usually deemed to be undefined and shaded as per the background.
> >
> > How does one do this with the user_defined camera? That is, specify that
> > some positions should be assigned the background colour.
>
> I thought it did it automatic?
> [code]
>

I have not yet played with the new user-defined camera, so I ran your code just
to see what it produces. ;-)

I changed your background{rgb 1} to rgb <0,1,0>, to give myself a better
understanding of the rendered result and how it relates to Paul Bourke's
question.

The background *within* your box map does indeed show up as green now-- but does
PB's question concern the *surrounding* area? That renders as black, regardless
of the background color.

[ingo] Re: user_define camera and undefined location an... [147 days 21 hours and 15 minutes ago]

Tue, 25 Nov 2025 11:10:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:
> As some of you may know I'm now a huge fan of the user_defined camera in version
> 3.8.
>
> A question, how does one deal with positions that are undefined for the
> particular camera. For example, for a fisheye the points outside the circle are
> usually deemed to be undefined and shaded as per the background.
>
> How does one do this with the user_defined camera? That is, specify that some
> positions should be assigned the background colour.

I thought it did it automatic?


box map:
---%<------%<------%<---
#include "transforms.inc"

/*== Map input value x in range(y, z) to range(-0.5, 0.5)*/
#declare Map05 = function(x,y,z){((x-y)/(z-y))-0.5};



#macro udcCubeCross(Loc)
  /*==
  Renders cross shaped image for cube map.
  Image aspect ratio 4:3
  //+w800 +h600 +a0.1 +am3

  Look at:
     +Y
  +X,-Z,-Y,+Z
     -Y

  Loc: location of the camera.
  */
  #local CadreX = function(u,v){
    select(//+Y
      (v>1/6 & u>-0.25 & u<0),
      0,
      select(
        (v<1/6 & v>-1/6),
        0,
        select(//-Y
          (v<1/6 & u>-0.25 & u<0),
          0,
          0,
          Map05(u,0,-0.25) //-Y true
        ),
        select(//-X
          (u<-0.25),
          0,
          select(//-Z
            (u>-0.25 & u<0),
            0,
            select(//+X
              (u>0 & u<0.25),
              0,
              select(//+Z
                (u>0.25),
                0,
                0,
                Map05(u,0.25,0.5)//+Z true
              ),
              -0.5//-X true
            ),
            Map05(u,0,-0.25)//-Z true
          ),
          0.5//+X true
        )
      ),
      Map05(u,0,-0.25)//+Ytrue
    )
  };
  #local CadreY = function(u,v){
    select(//+Y
      (v>1/6 & u>-0.25 & u<0),
      0,
      select(
        (v<1/6 & v>-1/6),
        0,
        select(//-Y
          (v<1/6 & u>-0.25 & u<0),
          0,
          0,
          -0.5//-Y true
        ),
        select(//-X
          (u<-0.25),
          0,
          select(//-Z
            (u>-0.25 & u<0),
            0,
            select(//+X
              (u>0 & u<0.25),
              0,
              select(//+Z
                (u>0.25),
                0,
                0,
                Map05(v,-1/6,1/6)//+Z true
              ),
              Map05(v,-1/6,1/6)//+X true
            ),
            Map05(v,-1/6,1/6)//-Z true
          ),
          Map05(v,-1/6,1/6)//-X true
        )
      ),
      0.5//+Ytrue
    )
  };
  #local CadreZ = function(u,v){
    select(//+Y
      (v>1/6 & u>-0.25 & u<0),
      0,
      select(
        (v<1/6 & v>-1/6),
        0,
        select(//-Y
          (v<1/6 & u>-0.25 & u<0),
          0,
          0,
          Map05(v,-1/6,-0.5)//-Y true
        ),
        select(//-X
          (u<-0.25),
          0,
          select(//-Z
            (u>-0.25 & u<0),
            0,
            select(//+X
              (u>0 & u<0.25),
              0,
              select(//+Z
                (u>0.25),
                0,
                0,
                0.5//+Z true
              ),
              Map05(u,0,0.25)//-X true
            ),
            -0.5//-Z true
          ),
          Map05(u,-0.25,-0.5) //+X true
        )
      ),
      Map05(v,1/6,0.5)//+Ytrue
    )
  };
  camera{
    user_defined
    location Loc
    direction {
      function{CadreX(u,v)}
      function{CadreY(u,v)}
      function{CadreZ(u,v)}
    }
  }
#end

udcCubeCross(<0,0,0>)

background{rgb 1}

light_source {<0,0,0> rgb 1}
light_source {<2,0,0> rgb 1}
light_source {<0,2,0> rgb 1}
light_source {<0,0,2> rgb 1}

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

sphere{< 2,0  ,0>,0.5 pigment{rgb x}}  //X:<1,v,u> +X
sphere{< 2,0.5,0>,0.1 pigment{rgb x}}  //          +X
sphere{<-2,0  ,0>,0.5 pigment{rgb x+z}}
sphere{<-2,0.5,0>,0.1 pigment{rgb x+z}}

sphere{< 0, 2,0>,0.5 pigment{rgb y}}   //Y:<u,1,v>
sphere{<.5, 2,0>,0.1 pigment{rgb y}}
sphere{< 0,-2,0>,0.5 pigment{rgb y+z}}
sphere{<.5,-2,0>,0.1 pigment{rgb y+z}}

sphere{<0,0  , 2>,0.5 pigment{rgb z}}   //Z:<u,v,1>  +Z
sphere{<0,0.5, 2>,0.1 pigment{rgb z}}
sphere{<0,0  ,-2>,0.5 pigment{rgb x+y}} //           -Z
sphere{<0,0.5,-2>,0.1 pigment{rgb x+y}}

#declare Radius = 2;
#for(I,1,18,1)
 torus{1,0.04 sturm rotate<90,0,0> rotate<0,I*10,0> pigment{rgb I/36}  }
#end


box{-0.3,0.3 translate < 1,-1, 1> pigment{rgb x}}
box{-0.3,0.3 translate <-1,-1, 1> pigment{rgb y}}
box{-0.3,0.3 translate < 1,-1,-1> pigment{rgb z}}
box{-0.3,0.3 translate <-1,-1,-1> pigment{rgb .5}}

box{-0.3,0.3 translate < 1, 1, 1> pigment{rgb x+y}}
box{-0.3,0.3 translate <-1, 1, 1> pigment{rgb x+z}}
box{-0.3,0.3 translate < 1, 1,-1> pigment{rgb y+z}}
box{-0.3,0.3 translate <-1, 1,-1> pigment{rgb 1}}
---%<------%<------%<---
ingo

[Paul Bourke] user_define camera and undefined location and di... [147 days 22 hours and 40 minutes ago]

Tue, 25 Nov 2025 09:45:00 GMT

As some of you may know I'm now a huge fan of the user_defined camera in version
3.8.

A question, how does one deal with positions that are undefined for the
particular camera. For example, for a fisheye the points outside the circle are
usually deemed to be undefined and shaded as per the background.

How does one do this with the user_defined camera? That is, specify that some
positions should be assigned the background colour.

[yesbird] Re: Did Friedrich A. Lohmueller pass away? [148 days 21 hours and 31 minutes ago]

Mon, 24 Nov 2025 10:54:25 GMT

On 24/11/2025 10:43, jr wrote:
> thanks.  for the 2D charts I'm looking to use Apache 'echarts' again.  any ideas
> re a globe, rather than "Mercator"-style ?

https://globeletjs.org/
Live example: https://globeletjs.org/examples/mountains/index.html
--
YB

[jr] Re: Did Friedrich A. Lohmueller pass away? [148 days 23 hours and 5 minutes ago]

Mon, 24 Nov 2025 09:20:00 GMT

hi,

Thorsten <tho### [at] trfde> wrote:
> On 23.11.2025 14:48, jr wrote:
> > by the end of 2024, approx 651k visitors had made a little over 9.2m requests,
> > 530-odd gigabytes of bandwidth total.
>
> You might want to filter for bots, both legal and illegal (those trying
> to click on advertisements). They create a lot of traffic...

yes, flesh-and-blood visitors are only a part of the "traffic" reported, I sort
of "glossed over" that aspect </shrug+grin>.


regards, jr.

[Thorsten] Re: Did Friedrich A. Lohmueller pass away? [148 days 23 hours and 45 minutes ago]

Mon, 24 Nov 2025 08:40:28 GMT

On 23.11.2025 14:48, jr wrote:
> by the end of 2024, approx 651k visitors had made a little over 9.2m requests,
> 530-odd gigabytes of bandwidth total.

You might want to filter for bots, both legal and illegal (those trying 
to click on advertisements). They create a lot of traffic...

[jr] Re: Did Friedrich A. Lohmueller pass away? [149 days and 40 minutes ago]

Mon, 24 Nov 2025 07:45:00 GMT

hi,

yesbird wrote:
> On 23/11/2025 16:48, jr wrote:
> > I had planned to produce a couple of charts from the summaries, ...
> Everything is much more easy, just let GA work for you: ...

thanks.  for the 2D charts I'm looking to use Apache 'echarts' again.  any ideas
re a globe, rather than "Mercator"-style ?

regards, jr.

[yesbird] Re: Did Friedrich A. Lohmueller pass away? [149 days 8 hours and 37 minutes ago]

Sun, 23 Nov 2025 23:47:56 GMT

On 24/11/2025 02:40, yesbird wrote:
> I have GA entries in all my sites since they exist.

PS: Charts example attached.
--
YB

[yesbird] Re: Did Friedrich A. Lohmueller pass away? [149 days 8 hours and 45 minutes ago]

Sun, 23 Nov 2025 23:40:30 GMT

On 23/11/2025 16:48, jr wrote:
> I had planned to produce a couple of charts from the summaries, and may yet find
> "the excuse" to do, but, for now, here's a percentage view of the use
> ("requests") by continent:
> 

Everything is much more easy, just let GA work for you:
https://analytics.google.com/

I have GA entries in all my sites since they exist.
--
YB

[Bald Eagle] Re: Did Friedrich A. Lohmueller pass away? [149 days 16 hours and 50 minutes ago]

Sun, 23 Nov 2025 15:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
 anyone having suitable (by country) border
> "outlines" to hand ?

https://bvisual.net/2013/08/16/visio-map-of-the-world/

Looks like people use SVG's to create outlines, etc.  There must be some sort of
utility or online converter that would allow extraction of outline information.

Presumably each country in an SVG is stored as a "path", that can be converted
to a polygon or prism.

I used an online converter to go from vsdx to vdx and open it in VISIO 2007.

[jr] Re: Did Friedrich A. Lohmueller pass away? [149 days 18 hours and 30 minutes ago]

Sun, 23 Nov 2025 13:55:00 GMT

hi,

today it is two years exactly since the FL site went back live, even though the
"official" announcement only came in Feb 2024.

Chris (also) provides a log analyser s/ware, and I have daily summaries for the
period.  except.  I fell ill at year's begin and did not notice "missing data"
until too late; from the 1st to 19th of January the scripted process failed
because I had not done "my bit" following the ususal log rotate, and then had a
senior moment when rebuilding a db.  </shrug+sigh>

I had planned to produce a couple of charts from the summaries, and may yet find
"the excuse" to do, but, for now, here's a percentage view of the use
("requests") by continent:

+------------+-------+
| area       | pct % |
+------------+-------+
| Africa     |  0.35 |
| America N  | 38.97 |
| America S  |  0.89 |
| Antarctica |  0.00 | [*]
| Asia       | 36.82 |
| Europe     | 22.75 |
| Oceania    |  0.19 |
| unknown    |  0.02 |
+------------+-------+

[*] a total of six "visitors" (not counting penguins :-)).

@WFP
the summaries now list 221 countries, but Christmas Island has yet to "dial in".
 ;-)

by the end of 2024, approx 651k visitors had made a little over 9.2m requests,
530-odd gigabytes of bandwidth total.

for this year, then, we start Jan 20th, plus, recently (the last couple of
months), the usage figures are distorted because the site has become the target
of some concerted "misuse", some "clever" people requesting the same pages, over
and over, from (literally) hundreds of different IP addresses/hosts.  with that
in mind, we had, as of this morning, around 2.43m visitors, a little over 20m
requests, approx 631 gigabytes bandwidth used.

I also have an idea how "we", for I certainly would need much help, could put
the geolocation data to good use.  a POV-Ray rendered globe, where the
(political) boundaries/borders for each country are 'prism{}' (?) shapes which
can have their heights set according to the frequencies.  animated, using
monthly data.  any interest ?  anyone having suitable (by country) border
"outlines" to hand ?


regards, jr.

[Bald Eagle] Re: 3-D printing via 3D SLICER app-- step by step [150 days 18 hours and 20 minutes ago]

Sat, 22 Nov 2025 14:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> I never really grasped the docs' info about
> max_distance (and making 'slices' of a scene).

Yes, that's the part that really caught my attention - there's no CSG, so I
wonder if there will be a significant speed-up.

Just mesh the screen with quads of triangles, and then rotate the mesh to flip
it up, and then scan down onto your object.  Use the 0.1mm height of your print
for your max depth, and that should do it.

I'm also wondering if this would be a good way to do some of the
object-to-isosurface stuff that's been talked about, and also be used as a sort
of pseudo-trace() to get all the intersections of a ray.

I just saw it when researching other things (as always) and thought you would be
interested.  :)

- BW

[Kenneth] Re: 3-D printing via 3D SLICER app-- step by step [151 days 9 hours and 15 minutes ago]

Fri, 21 Nov 2025 23:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hey Kenneth:
>
> Have you seen this? (mesh projection camera)
> https://wiki.povray.org/content/Reference:Camera
>

I've used the mesh camera in the past-- actually just toyed with it-- but not
since I bought my 3-D printer and began learning about STL...so your reminder is
interesting news! Previously, I never really grasped the docs' info about
max_distance (and making 'slices' of a scene). I do need to go back and
investigate these possibilities...and to re-learn some of what I have probably
forgotten about the mesh camera <*sigh*>

Maybe I simply 're-invented the wheel' with my own object-slicing code
scheme here (?!)

Thanks! :-D

[Bald Eagle] Re: 3-D printing via 3D SLICER app-- step by step [151 days 15 hours and 35 minutes ago]

Fri, 21 Nov 2025 16:50:00 GMT

Hey Kenneth:

Have you seen this? (mesh projection camera)
https://wiki.povray.org/content/Reference:Camera

Max Distance
This is an optional floating-point value which, if greater than EPSILON (a very
small value used internally for comparisons with 0), will be used as the limit
for the length of any rays cast. Objects at a distance greater than this from
the ray origin will not be intersected by the ray.

The primary use for this parameter is to allow a mesh camera to 'probe' a scene
in order to determine whether or not a given location contains a visible object.
Two examples would be a camera that divides the scene into slices for use in 3d
printing or to generate an STL file, and a camera that divides the scene into
cubes to generate voxel information. In both cases, some external means of
processing the generated image into a useful form would be required.

- bw

[Bald Eagle] Re: Custom output filenames [153 days 15 hours and 5 minutes ago]

Wed, 19 Nov 2025 17:20:00 GMT

"stevenvh" <nomail@nomail> wrote:

> But arguments are of little use if
> the program doesn't run in the first place.

Yes, I think jr was trying to reference
https://wiki.povray.org/content/Documentation:Unix_Section_4

With regard to giving povray the necessary permissions for invoking executables.
(Sorry if you've already tried that - it wasn't clear from the thread if you had
or not)

- BW

[jr] Re: Custom output filenames [153 days 15 hours and 5 minutes ago]

Wed, 19 Nov 2025 17:20:00 GMT

hi,

"stevenvh" <nomail@nomail> wrote:
> ...
> ... arguments are of little use if the program doesn't run in the first place.

have you checked your global ("system-wide") 'povray.conf' wrt permissions ?
(your private/user 'povray.conf' too, of course :-))

if your permissions are ok but your program doesn't run, it may be an
environment / $PATH issue; your code may only see a subset of the environment
(variables) POV-Ray sees.

regards, jr.

[stevenvh] Re: Custom output filenames [153 days 15 hours and 20 minutes ago]

Wed, 19 Nov 2025 17:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> given you have a "target" directory, the 'output_file_name' can (should ?) be a
> complete pathname, eg "output_file_name = C:/path/to/selectfolder/myscene". also
> use the 'all_file = on' option and POV-Ray's screen output will be (largely)
> duplicated in a 'alltext.out' "log" file.  and re your Delphi code, what if it
> takes two arguments, that is path and %s separately ?
>
> <wiki.povray.org/content/Reference:File_Output_Options#Output_File_Name>
>

The program can take any number of arguments*, or at least maybe a dozen of
them. (I never could find a limit to them.) But arguments are of little use if
the program doesn't run in the first place.


*) For instance, argument 0 is the program name itself, including its path)

[Alain Martel] Re: [154 days 11 hours and 7 minutes ago]

Tue, 18 Nov 2025 21:18:29 GMT

Le 2025-11-18 Ã  11:37, Lourdes a Ã©critÂ :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> If you search the forums, you will likely find that this is due to trying to
>> model the scene in "realistic units".
>> (Lookup "Ringworld", for instance)
>> Also, this ought to still be in the FAQ.
>>
>> Numbers in a computer can only be so large, and so the numbers themselves "get
>> clipped" and suffer from floating point accuracy issues.
>>
>> Scale everything down so that your number are less than maybe 1E9 or so, and I'm
>> sure that you'll see an improvement.
>>
>> Welcome.
>>
>> - BE
> 
> I tried to scale everything down but it didnt work... clipping still occurs.
> I had everything modelled in km so the distance of the sun reached numbers of
> 1e9 but now that I changed everything to decameters (1decameter=10km) is still
> not working. I tried also megameter (1 megameter=1000km) but still no good
> results.... what else can I try? Or can it be something else what is causing the
> problem?
> 

The problem is the range between the close objects and the far objects.
If you have distances with a ratio of 1e6 to 1, you will have clipping 
issues.

Don't change the scale of the foreground objects. Don't change the 
distance to the foreground objects. Keep the 1 unit = 1Km scale for the 
close objects.

DO make the background objects 1000 to 10000 times closer and smaller.
Use the parallel attribute for your light_source. Here, the scale can 
becomes 1 unit = 1000 Km to 1 unit = 10000Km, possibly even more.

[Bald Eagle] Re: [154 days 14 hours and 35 minutes ago]

Tue, 18 Nov 2025 17:50:00 GMT

To be honest, without seeing the scene code, it's going to be a hard problem to
diagnose.

Suggestions:

1. post a simple scene, perhaps a link to the mesh file.

2. Try a simple placeholder for your mesh like a union of boxes or something,
and see if the problem persists.

3.  Move things around a bit and see what happens.  translate, rotate in all 3
directions by a degree or so.  Make sure nothing's occluding your light onto
your object or getting between camera and object.  Check your finishes - hard
shadows will make everything BLACK and you just won't see that part of your
object.

Try non-zero values in your pigment statements.  (rgb < (val>0), (val>0),
(val>0) >

Add a small amount of diffuse to your finish.

Use radiosity in your scene.

Posting the scene would be best.

- BE

[Lourdes] Re: [154 days 15 hours and 45 minutes ago]

Tue, 18 Nov 2025 16:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> If you search the forums, you will likely find that this is due to trying to
> model the scene in "realistic units".
> (Lookup "Ringworld", for instance)
> Also, this ought to still be in the FAQ.
>
> Numbers in a computer can only be so large, and so the numbers themselves "get
> clipped" and suffer from floating point accuracy issues.
>
> Scale everything down so that your number are less than maybe 1E9 or so, and I'm
> sure that you'll see an improvement.
>
> Welcome.
>
> - BE

I tried to scale everything down but it didnt work... clipping still occurs.
I had everything modelled in km so the distance of the sun reached numbers of
1e9 but now that I changed everything to decameters (1decameter=10km) is still
not working. I tried also megameter (1 megameter=1000km) but still no good
results.... what else can I try? Or can it be something else what is causing the
problem?

[Lourdes] Re: [154 days 16 hours ago]

Tue, 18 Nov 2025 16:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Lourdes" <lou### [at] gmailcom> wrote:
> >
> > I am having clipping image issues with the povray scene I am currently working
> > on and I would sincerely appreciate the help.
> >
>
> From the appearance of your render examples, it looks like you are using an
> orthographic camera(?). Does the clipping of your object still occur if you use
> a typical 'perspective' camera instead?
>
> Which version of POV-ray are you running?

Hello,

I will try with the prespective camera... I tried scaling everything down and it
didnt work....the clipping still occurs. And the version I am running is 3.7.

[jr] Re: Custom output filenames [154 days 22 hours and 20 minutes ago]

Tue, 18 Nov 2025 10:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> > Also, the"%s" in the command is just the filename without the path. I need that
> > path in my program (I have a select folder command there), which I hoped to
> > automate.
>
> I've not tried, but can you not write:  post_frame_command = sh myscript
> path/to/%s

given you have a "target" directory, the 'output_file_name' can (should ?) be a
complete pathname, eg "output_file_name = C:/path/to/selectfolder/myscene". also
use the 'all_file = on' option and POV-Ray's screen output will be (largely)
duplicated in a 'alltext.out' "log" file.  and re your Delphi code, what if it
takes two arguments, that is path and %s separately ?

<wiki.povray.org/content/Reference:File_Output_Options#Output_File_Name>

regards, jr.

[jr] Re: Custom output filenames [155 days and 15 minutes ago]

Tue, 18 Nov 2025 08:10:00 GMT

hi,

"stevenvh" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...
> > > 'Post_Scene_Command' option will help.
> >
> > sorry, 'Post_Frame_Command' is what I meant.
> > ...
> Current issue:
> when I add the line
>
>     Post_Scene_Command = c:RenumberPOVrayFiles.exe %s
>
> nothing happens, my program doesn't run. Is my understanding of
> "Post_Scene_Command" wrong?

by default "we" are not allowed to run shell commands, to avoid a potential
security issue.  in your global 'povray.conf' file, the "[Shellout Security]"
must be enabled / "allowed"; it is a good idea, generally, to tune the global
..conf and .ini files as part of "post installation".


> Also, the"%s" in the command is just the filename without the path. I need that
> path in my program (I have a select folder command there), which I hoped to
> automate.

I've not tried, but can you not write:  post_frame_command = sh myscript
path/to/%s

?

regards, jr.

[Ilya Razmanov] Re: Custom output filenames [155 days 3 hours and 54 minutes ago]

Tue, 18 Nov 2025 04:30:55 GMT

On 17.11.2025 22:05, stevenvh wrote:
> "stevenvh" <nomail@nomail> wrote:
> 
> The "c:RenumberPOVrayFiles.exe" is actually "c:\RenumberPOVrayFiles.exe" with
> the "\" included. The path + program name is correct.
> 

Any chances it may expect "/" rather than "\"? Just a wild guess, in 
theory, in "" everything must work (are "" really a part of command 
line? I mean, are they passed to the system? Any chances you have to 
double them, like '""'?)

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

[Bald Eagle] Re: Custom output filenames [155 days 12 hours and 45 minutes ago]

Mon, 17 Nov 2025 19:40:00 GMT

"stevenvh" <nomail@nomail> wrote:

> Current issue:
> when I add the line
>
>     Post_Scene_Command = c:RenumberPOVrayFiles.exe %s
>
> nothing happens, my program doesn't run. Is my understanding of
> "Post_Scene_Command" wrong?

I don't really use the shell commands, so I have no idea.
Maybe use some program that would be super obvious, and just run a test scene.

> Also, the"%s" in the command is just the filename without the path. I need that
> path in my program (I have a select folder command there), which I hoped to
> automate.

Yeah - I had a question about that too in some other thread that I can't find
(because Google doesn't fully index our site, in spite of Chris Cason's many
attempts to ensure they do)

I'm guessing you're going to have to find some workaround.

I also have no idea if exposing the full filename path to the user has been
implemented in Willaim Pokorny's yuqk fork...

- BE

[stevenvh] Re: Custom output filenames [155 days 13 hours and 15 minutes ago]

Mon, 17 Nov 2025 19:10:00 GMT

"stevenvh" <nomail@nomail> wrote:

> Current issue:
> when I add the line
>
>     Post_Scene_Command = c:RenumberPOVrayFiles.exe %s
>
> nothing happens, my program doesn't run. Is my understanding of
> "Post_Scene_Command" wrong?
> Also, the"%s" in the command is just the filename without the path. I need that
> path in my program (I have a select folder command there), which I hoped to
> automate.
>
> Thanks for the replies.

The "c:RenumberPOVrayFiles.exe" is actually "c:\RenumberPOVrayFiles.exe" with
the "\" included. The path + program name is correct.

[stevenvh] Re: Custom output filenames [155 days 13 hours and 25 minutes ago]

Mon, 17 Nov 2025 19:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > 'Post_Scene_Command' option will help.
>
> sorry, 'Post_Frame_Command' is what I meant.
>
>
> regards, jr.

Ultimately I wrote a quick-and-dirty program in Delphi to do the renumbering. I
run it after the scene (i.e. all frames) are rendered. The program looks for the
line with the definition of "frameList" (var name editable by the user),

    #declare framesList = array[12] {26, 29, 31, 34, 38, 50, 79, 81, 127, 129,
173, 185}

and builds a list of the elements in the array. Then renumbers the output files
as explained in my OP.
So since I run it after the scene your original "Post_Scene_Command" was indeed
what I needed.

Current issue:
when I add the line

    Post_Scene_Command = c:RenumberPOVrayFiles.exe %s

nothing happens, my program doesn't run. Is my understanding of
"Post_Scene_Command" wrong?
Also, the"%s" in the command is just the filename without the path. I need that
path in my program (I have a select folder command there), which I hoped to
automate.

Thanks for the replies.

[Bald Eagle] Re: Journal article request(s) [157 days 18 hours and 5 minutes ago]

Sat, 15 Nov 2025 14:20:00 GMT

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

> Stress Analysis of Heated Complex Shapes
> Richard H. Gallagher
> Joseph Padlog
> P. P. Bijlaard

This references:

Turner, M . J., Clough, R. W. t Martin, H . C , and Topp, L. J.,
"Stiffness and deflection analysis of complex structures," J. Aeronaut. Sci.
23,805-823 (1956).

Which is the earliest paper I can find concerning the transition from the early
Matrix Displacement Method to the fundamentals of modern Finite Element
Analysis.


"Even in the 1950s, the inversion of a matrix of modest size, often took a few
weeks to determine."  :O

- BE

[William F Pokorny] Re: Custom output filenames [158 days 13 hours and 59 minutes ago]

Fri, 14 Nov 2025 18:25:57 GMT

On 11/14/25 11:16, stevenvh wrote:
> Is there a way to have custom numbering for the output files? Like
> 
>    outfile_02
>    outfile_03
>    outfile_05
>    outfile_08
>    outfile_13

Not exactly what you asked for, but you can render single frames with 
the animation frame subset capability via flags or ini options:

subset_start_frame, subset_end_frame, frame_step, +sf, +ef and +stp

   povray myAnimation.pov +sf7, +ef7 +kff10

would render just frame 7 of a 10 frame animation for example - with the 
same frame animation output file name. You'd be running povray multiple 
times change the subset options rather than using an SDL array, but if 
not many high res frames perhaps not a bad approach.

---

Alternately.

Though I'm not a big fan of the capability due possible confusion, It is 
also possible to set the 'frame_number' inside the SDL for your scene.

   #declare frame_number = 2;  // Or make '2' Ary[0] etc.

or set it - and the complete output file name - on the command line with:

   povray myAnimation.pov declare=frame_number=9 +omyAnimation09

Bill P.

[jr] Re: Custom output filenames [158 days 15 hours and 25 minutes ago]

Fri, 14 Nov 2025 17:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> 'Post_Scene_Command' option will help.

sorry, 'Post_Frame_Command' is what I meant.


regards, jr.

[jr] Re: Custom output filenames [158 days 15 hours and 30 minutes ago]

Fri, 14 Nov 2025 16:55:00 GMT

hi,

"stevenvh" <nomail@nomail> wrote:
> I have a scene for which I want a number of different renderings (different
> camera and light locations). I run a .ini file to render the variations, which
> get numbered 0 to 49. In my .pov file I have the following code:
> ...
> The result is a series of output files with filename numbers in sequence
> (defined by the .ini file)
> ...
> Is there a way to have custom numbering for the output files? Like
>   outfile_02
>   outfile_03
>   outfile_05
>   outfile_08
>   outfile_13

> numbers I would get from the array in my .pov file, which would mean that the
> output filename should be defined in the .pov file.

not directly, afaik.  if you could use that "map" of frame->file# from a script,
the 'Post_Scene_Command' option will help.

<wiki.povray.org/content/Reference:Shell_Command_Options>


regards, jr.

[stevenvh] Custom output filenames [158 days 16 hours and 5 minutes ago]

Fri, 14 Nov 2025 16:20:00 GMT

I have a scene for which I want a number of different renderings (different
camera and light locations). I run a .ini file to render the variations, which
get numbered 0 to 49. In my .pov file I have the following code:

  #declare Rnd1 = seed(frame_number); // camera
  #declare Rnd2 = seed(frame_number); // light

From these 50 I select a number to render at high resolution, and I run a
different .ini file for these. In my .pov file I write the following code, which
maps the sequence numbers to my own:

  #declare frames = array[5] {2, 3, 5, 8, 13} // selected for high-res rendering
  #declare frame_nr = frames[frame_number];
  #declare Rnd1 = seed(frame_nr); // camera
  #declare Rnd2 = seed(frame_nr); // light

The result is a series of output files with filename numbers in sequence
(defined by the .ini file)

  outfile_00
  outfile_01
  outfile_02
  outfile_03
  outfile_04

Is there a way to have custom numbering for the output files? Like

  outfile_02
  outfile_03
  outfile_05
  outfile_08
  outfile_13

numbers I would get from the array in my .pov file, which would mean that the
output filename should be defined in the .pov file.

[Bald Eagle] Re: Journal article request(s) [159 days 9 hours and 10 minutes ago]

Thu, 13 Nov 2025 23:15:00 GMT

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

> if it helps, the early sources up to v3.62 are available via FTP:
> <ftp.povray.org/pub/povray/Old-Versions>

It did.
In version 3.1d, 1998, in file NORMAL.C, created 6/3/1998 at 7:05 pm,

static CONST
VECTOR Pyramid_Vect [4]= {{ 0.942809041,-0.333333333, 0.0},
                          {-0.471404521,-0.333333333, 0.816496581},
                          {-0.471404521,-0.333333333,-0.816496581},
                          { 0.0        , 1.0        , 0.0}};

first appears, with no author cited except for "The POV Team".

No citation, no author, no comments, just magic numbers.

It is then implemented in the function

void Perturb_Normal(VECTOR Layer_Normal, TNORMAL *Tnormal, VECTOR  EPoint)

with the following comment:

/* Note, even though DELTA and Pyramid_Vect are constants, we may later
   make DELTA a user-defined parameter.  Good optimising compilers
   should merge the constants anyway. */

I was able to dig back in the literature to an article by Gallagher et al from
1962 concerning Finite Element Analysis (FEM) which is the earliest that I was
able to find documenting this method of calculating a gradient with sample
points arranged in a tetrahedron.

The method used in our source has a vector pointing in the cardinal y-direction,
which could possibly introduce bias that might not be present when using all
off-axis vectors.

- BE

[jr] Re: Journal article request(s) [159 days 10 hours ago]

Thu, 13 Nov 2025 22:25:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Related request:
>
> What is the earliest version of POV-Ray that has ...

if it helps, the early sources up to v3.62 are available via FTP:
<ftp.povray.org/pub/povray/Old-Versions>


regards, jr.

[Bald Eagle] Re: Journal article request(s) [159 days 11 hours and 5 minutes ago]

Thu, 13 Nov 2025 21:20:00 GMT

Related request:

What is the earliest version of POV-Ray that has the "Pyramid Vector",
located (presently) in povray/source/core/material/normal.cpp?


/*****************************************************************************
* Local constants
******************************************************************************/

static const Vector3d Pyramid_Vect [4]= { Vector3d( 0.942809041,-0.333333333,
0.0),
                                          Vector3d(-0.471404521,-0.333333333,
0.816496581),

Vector3d(-0.471404521,-0.333333333,-0.816496581),
                                          Vector3d( 0.0        , 1.0        ,
0.0) };

/*****************************************************************************

Thanks,

- BE

[Bald Eagle] Journal article request(s) [159 days 14 hours and 20 minutes ago]

Thu, 13 Nov 2025 18:05:00 GMT

I'll put this here for now.
Can't use sci-hub from where I'm currently at.

Likely going to want more journal articles in the future, so I'll just start a
thread.

Stress Analysis of Heated Complex Shapes
Richard H. Gallagher
Joseph Padlog
P. P. Bijlaard

30 April 1962
journal article
Published by American Institute of Aeronautics and Astronautics (AIAA) in ARS
Journal
Vol. 32  (5) , 700-707
https://doi.org/10.2514/8.6128

- BE

[Kenneth] Re: [159 days 17 hours and 25 minutes ago]

Thu, 13 Nov 2025 15:00:00 GMT

"Lourdes" <lou### [at] gmailcom> wrote:
>
> I am having clipping image issues with the povray scene I am currently working
> on and I would sincerely appreciate the help.
>

From the appearance of your render examples, it looks like you are using an
orthographic camera(?). Does the clipping of your object still occur if you use
a typical 'perspective' camera instead?

Which version of POV-ray are you running?

[Ilya Razmanov] Re: Negative IOR renders [160 days 3 hours and 2 minutes ago]

Thu, 13 Nov 2025 05:23:34 GMT

On 13.11.2025 1:15, Alain Martel wrote:

> I've tried negative IOR in POV-Ray, and it make the object a perfect 
> mirror. ANY IOR <0 result in reflection.

...that's how you invented fiber optics. Now it's time to invent ATR 
spectroscopy ;-)

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

[Alain Martel] Re: Negative IOR renders [160 days 10 hours and 9 minutes ago]

Wed, 12 Nov 2025 22:15:41 GMT

Le 2025-11-12 Ã  15:21, Bald Eagle a Ã©critÂ :
> 
> Pretty interesting:
> 
> https://opg.optica.org/oe/fulltext.cfm?uri=oe-14-5-1842
> 
> 
> 
I've tried negative IOR in POV-Ray, and it make the object a perfect 
mirror. ANY IOR <0 result in reflection.

[jr] Re: Negative IOR renders [160 days 11 hours and 20 minutes ago]

Wed, 12 Nov 2025 21:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > (first Buck then Hormann, is there a list ?  :-))
>
> Not at present, but there should be.
>
> Maybe Wiki page with sections devoted to POV-Ray "members" who have had things
> published, and then just things like papers or journal covers that used POV-Ray
> to render the graphics.

excellent idea, I agree, a page / section listing papers and articles would be
good, make a "fine resource".  write.


regards, jr.

[Bald Eagle] Re: Negative IOR renders [160 days 11 hours and 30 minutes ago]

Wed, 12 Nov 2025 20:55:00 GMT

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

> (first Buck then Hormann, is there a list ?  :-))

Not at present, but there should be.

Maybe Wiki page with sections devoted to POV-Ray "members" who have had things
published, and then just things like papers or journal covers that used POV-Ray
to render the graphics.

- bw

[jr] Re: Negative IOR renders [160 days 11 hours and 40 minutes ago]

Wed, 12 Nov 2025 20:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Pretty interesting:
>
> https://opg.optica.org/oe/fulltext.cfm?uri=oe-14-5-1842

yes.

(first Buck then Hormann, is there a list ?  :-))


regards, jr.

[Ilya Razmanov] Re: Negative IOR renders [160 days 11 hours and 52 minutes ago]

Wed, 12 Nov 2025 20:33:31 GMT

On 12.11.2025 23:21, Bald Eagle wrote:
> 
> Pretty interesting:
> 
> https://opg.optica.org/oe/fulltext.cfm?uri=oe-14-5-1842
> 

Decades ago, when I was a child, I *invented* a lamp of darkness, that 
is, of negative light. Needless to say, decades later, when I first 
found POV-Ray (3.0 was just released), I used it to visualize my 
invention, and, needless to say, POV-Ray worked perfectly.

Now children invent substances where speed of light is higher than the 
speed of light.

I call it "progress".

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

[Bald Eagle] Negative IOR renders [160 days 12 hours ago]

Wed, 12 Nov 2025 20:25:00 GMT

Pretty interesting:

https://opg.optica.org/oe/fulltext.cfm?uri=oe-14-5-1842

[Bald Eagle] Re: THERE's A BOOK??! [160 days 14 hours and 55 minutes ago]

Wed, 12 Nov 2025 17:30:00 GMT

Writeup:

https://medium.com/@jogrosso/the-ray-tracer-challenge-learning-c-through-computer-graphics-e45a68fb7cd5

[kurtz le pirate] Re: THERE's A BOOK??! [160 days 15 hours and 18 minutes ago]

Wed, 12 Nov 2025 17:06:46 GMT

On 12/11/2025 16:53, Bald Eagle wrote:
> I guess this must be David K. Buck's brother?
> 
> https://devtalk.com/books/the-ray-tracer-challenge
> 
> Dave wrote the foreword?
> 
> Did anyone know about this?

yes, that's him. we can read it at the end of the foreword :
   David Buck
   Author of DKBTrace and Coauthor of POV-Ray
and that was back in 2019

-- 
kurtz le pirate
compagnie de la banquise

[Lourdes] Re: [160 days 15 hours and 45 minutes ago]

Wed, 12 Nov 2025 16:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> https://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_24
>
> https://www.infradead.org/~wmp/proj_rings.html

Thank you very much for your reply!!

[Lourdes] Re: [160 days 15 hours and 45 minutes ago]

Wed, 12 Nov 2025 16:40:00 GMT

"Lourdes" <lou### [at] gmailcom> wrote:
> Hello everyone,
>
> I am having clipping image issues with the povray scene I am currently working
> on and I would sincerely appreciate the help.
>
> The scene I am working on represents a spacecraft in "space", where the earth
> was placed at the center of povrays coordinate system and the sun was at the
> corresponding distance in km defined as a single pointlight.
>
> The spacecraft was first modelled in freecad then imported as independent stl
> parts to blender where textures were assigned and finally using povray add on,
> the pov code defining the different parts as mesh2 was obtained and the
> different objects were merged into a single spacecraft one to be capable of
> moving it around the scene and place it wherever is wished.
>
> The problem is that when I place the spacecraft on a certain lower orbit and at
> a relative distance from the camera of meters, in some cases the object appers
> clipped. Here I provide some images examples showing that.
>
> Is not that we are too close, the FOV is enough, and there is no clipping option
> defined in the camera, in fact this is how the camera is defined:
> camera {
>
>             sky         sky_vector
>
>             right       -(image_width/image_height)*x
>
>             look_at     look
>
>             angle       afov
>
>             location    Cam_pos
>
>
>
> }
>
> Maybe it has to do with the meshes and merge of how the spacecraft os defined,
> but I tried to check this and I didnt find anything... or maybe the problem is
> with the overall scale of the scene??
>
> If anyone has a feeling of what could be happening and knows how to fix it, I
> would really appreciate it.


Just checking if anyone replied...

[Bald Eagle] THERE's A BOOK??! [160 days 16 hours and 30 minutes ago]

Wed, 12 Nov 2025 15:55:00 GMT

I guess this must be David K. Buck's brother?

https://devtalk.com/books/the-ray-tracer-challenge

Dave wrote the foreword?

Did anyone know about this?

- BE

[Bald Eagle] Re: 3-D printing via 3D SLICER app-- step by step [160 days 17 hours and 30 minutes ago]

Wed, 12 Nov 2025 14:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> It will be interesting to follow this work,

Well, the idea was that if you really wanted to, you could contact him directly
and find out all sorts of things.

We can use all the help we can get regarding every aspect of POV-Ray's
development.

- BW

[Kenneth] Re: 3-D printing via 3D SLICER app-- step by step [160 days 17 hours and 35 minutes ago]

Wed, 12 Nov 2025 14:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Possibly of interest to you:
>
> https://www.martinjules.com/projects/single-project?id=5
>

He apparently succeeded in writing his own parser for POV-ray (using Java?) He
mentioned elsewhere that he likes developing real-time rendering techniques;
it's difficult to tell from the video if he implemented that. (BTW, it looks
like he and his school mates(?) are still using v3.6).

It will be interesting to follow this work, to see if they eventually succeed in
coming up with a scheme to *directly* export an STL file (and not just for
mesh/mesh2 triangle-based objects...unless they figure out a way to turn
POV-ray's math-primitive objects and CSG into triangle meshes! *That* would be a
really important development.)

[Bald Eagle] Re: [160 days 19 hours and 5 minutes ago]

Wed, 12 Nov 2025 13:20:00 GMT

https://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_24

https://www.infradead.org/~wmp/proj_rings.html

[Bald Eagle] Re: [160 days 19 hours and 15 minutes ago]

Wed, 12 Nov 2025 13:10:00 GMT

If you search the forums, you will likely find that this is due to trying to
model the scene in "realistic units".
(Lookup "Ringworld", for instance)
Also, this ought to still be in the FAQ.

Numbers in a computer can only be so large, and so the numbers themselves "get
clipped" and suffer from floating point accuracy issues.

Scale everything down so that your number are less than maybe 1E9 or so, and I'm
sure that you'll see an improvement.

Welcome.

- BE

[Lourdes] [160 days 20 hours and 40 minutes ago]

Wed, 12 Nov 2025 11:45:00 GMT

Hello everyone,

I am having clipping image issues with the povray scene I am currently working
on and I would sincerely appreciate the help.

The scene I am working on represents a spacecraft in "space", where the earth
was placed at the center of povrays coordinate system and the sun was at the
corresponding distance in km defined as a single pointlight.

The spacecraft was first modelled in freecad then imported as independent stl
parts to blender where textures were assigned and finally using povray add on,
the pov code defining the different parts as mesh2 was obtained and the
different objects were merged into a single spacecraft one to be capable of
moving it around the scene and place it wherever is wished.

The problem is that when I place the spacecraft on a certain lower orbit and at
a relative distance from the camera of meters, in some cases the object appers
clipped. Here I provide some images examples showing that.

Is not that we are too close, the FOV is enough, and there is no clipping option
defined in the camera, in fact this is how the camera is defined:
camera {

            sky         sky_vector

            right       -(image_width/image_height)*x

            look_at     look

            angle       afov

            location    Cam_pos



}

Maybe it has to do with the meshes and merge of how the spacecraft os defined,
but I tried to check this and I didnt find anything... or maybe the problem is
with the overall scale of the scene??

If anyone has a feeling of what could be happening and knows how to fix it, I
would really appreciate it.

[Bald Eagle] Re: 3-D printing via 3D SLICER app-- step by step [161 days 9 hours and 15 minutes ago]

Tue, 11 Nov 2025 23:10:00 GMT

Possibly of interest to you:

https://www.martinjules.com/projects/single-project?id=5

- BW

[yesbird] Re: Omni Directional Stereoscopic Panoramas [170 days 14 hours and 5 minutes ago]

Sun, 2 Nov 2025 18:20:06 GMT

On 02/11/2025 13:17, Paul Bourke wrote:
> I posted something along these line in the advanced users forum, praising the
> amazing user_defined camera. ...
> 
> I've now implemented the code for both cylindrical and equirectangular, it can
> be found here
>     https://paulbourke.net/stereoscopy/pov_odsp/
> 
> The equirectangular version is more common for head mounted displays. Whereas
> I'm working more with cylindrical displays, hence the cylindrical variant. I
> include support for both commonly encountered zero parallax options, infinity
> for HMDs or at the screen distance for displays.
> 
> One of the important things about this solution is that it is defined in terms
> of real world coordinates. As such the scene should ideally also be defined in
> terms of the same units. This is important for good quality stereographics and
> being able to represent true scale and depth. And critical when it comes to
> compositing with other stereoscopic sources, like 360 stereoscopic cameras.
>

I was also very impressed by this feature, although used
https://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
for such experiments before.

Many thanks for sharing these renderings, I included them in my
gallery, making HMD-ready: https://yesbird.online/gallery/

Menger sponge in space is especially good :).

PS: My old-good-outdated Oculus Go works fine for this stuff and
can be ordered from E-Bay now for less then $100.
--
YB

[Leroy] Re: Omni Directional Stereoscopic Panoramas [170 days 14 hours and 55 minutes ago]

Sun, 2 Nov 2025 17:30:00 GMT

"Paul Bourke" <pau### [at] gmailcom> wrote:
> I posted something along these line in the advanced users forum, praising the
> amazing user_defined camera.
>
> I've now implemented the code for both cylindrical and equirectangular, it can
> be found here
>    https://paulbourke.net/stereoscopy/pov_odsp/
>
> The equirectangular version is more common for head mounted displays. Whereas
> I'm working more with cylindrical displays, hence the cylindrical variant. I
> include support for both commonly encountered zero parallax options, infinity
> for HMDs or at the screen distance for displays.
>
> One of the important things about this solution is that it is defined in terms
> of real world coordinates. As such the scene should ideally also be defined in
> terms of the same units. This is important for good quality stereographics and
> being able to represent true scale and depth. And critical when it comes to
> compositing with other stereoscopic sources, like 360 stereoscopic cameras.

Cool! I've played a little with the 3.8 user_defined camera and the 3.7 mesh
defined camera. Now you gave me something else to play with:)

Have Fun!

[Paul Bourke] Omni Directional Stereoscopic Panoramas [170 days 22 hours and 5 minutes ago]

Sun, 2 Nov 2025 10:20:00 GMT

I posted something along these line in the advanced users forum, praising the
amazing user_defined camera.

I've now implemented the code for both cylindrical and equirectangular, it can
be found here
   https://paulbourke.net/stereoscopy/pov_odsp/

The equirectangular version is more common for head mounted displays. Whereas
I'm working more with cylindrical displays, hence the cylindrical variant. I
include support for both commonly encountered zero parallax options, infinity
for HMDs or at the screen distance for displays.

One of the important things about this solution is that it is defined in terms
of real world coordinates. As such the scene should ideally also be defined in
terms of the same units. This is important for good quality stereographics and
being able to represent true scale and depth. And critical when it comes to
compositing with other stereoscopic sources, like 360 stereoscopic cameras.

[Leroy] Re: General AI code notes [171 days 15 hours and 10 minutes ago]

Sat, 1 Nov 2025 17:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just some clarifications and (hopefully) helpful notes about AI-generated code.
>
> Without direction, AI will just spit out anything it "thinks" works.
>

True! It does spits out a lot of stuff, like vomit. And like vomit there are
things there that could be useful, but You don't want to touch it.


> But we all know that SDL is "special".
>
> At least with GPT-5, I can tell it to remember my coding style, and give it
> certain rules to follow.
>
> If you see code with lowercase identifiers, then it's probably from before I
> puzzled all of that out.
>
> I've tried to have it generate code with capitalized identifiers, and prepending
> all of the ID's with the type:  S_ for scalar, V_ for vector, Arr_ for array,
> etc.
>
> It also sometimes drops * for multiplication and just concatenates two ID's
> together - just insert that * and that line of code should work.
>
> It tries to do c++ style "functions", both by writing multi-line code with
> #declares or #locals, and also by naming the output value and providing that as
> - BE

It did write a function that was really a macro.
LLMs (large language model) don't really understand anything.

Have fun!

[Bald Eagle] General AI code notes [171 days 18 hours and 15 minutes ago]

Sat, 1 Nov 2025 14:10:00 GMT

Just some clarifications and (hopefully) helpful notes about AI-generated code.

Without direction, AI will just spit out anything it "thinks" works.

But we all know that SDL is "special".

At least with GPT-5, I can tell it to remember my coding style, and give it
certain rules to follow.

If you see code with lowercase identifiers, then it's probably from before I
puzzled all of that out.

I've tried to have it generate code with capitalized identifiers, and prepending
all of the ID's with the type:  S_ for scalar, V_ for vector, Arr_ for array,
etc.

It also sometimes drops * for multiplication and just concatenates two ID's
together - just insert that * and that line of code should work.

It tries to do c++ style "functions", both by writing multi-line code with
#declares or #locals, and also by naming the output value and providing that as
part of the input parameters.

Just change
#macro MacroName (ID1, ID2, ID3)

#end

to

#macro MacroName (ID1, ID2)

ID3
#end

and then in the macro call, change:

MacroName (ID1, ID2, ID3)

to

#declare ID3 = MacroName (ID1, ID2);

- BE

[Bald Eagle] Re: Results of the discussion on color changes i... [172 days 16 hours ago]

Fri, 31 Oct 2025 16:25:00 GMT

yesbird wrote:

> Not rendered by POV-Ray, but also impressive :).
> Are you involved in such real mechanic too ?

Not to that extent.
I do a lot of my own automotive work - exhaust, brakes, body work, etc.

I restore vintage hand tools and machinery.  Wooden planes, hand saws, 2-man
crosscut saws for logging, hammers, chisels, Bit braces and augers, draw knives,
Peck, Stow and Wilcox sheet metal rolling mills, wood lathe tools, machinist
tools, axes, knives, blacksmithing tools .....

I've built 2 wooden hand planes, have plans for a frame saw, a shave horse, a
large steady-rest for my lathe, I have a DC motor for my lathe that ought to
allow me to do variable-speed and reverse direction....

I also do some traditional food preparation and preservation - drying, pickling,
canning, salting.

The low-tech / no-tech stuff keeps me sane

As jr says ... "HYPERACTIVE".

-BE

[yesbird] Re: Results of the discussion on color changes i... [172 days 16 hours and 36 minutes ago]

Fri, 31 Oct 2025 15:48:46 GMT

On 27/10/2025 00:55, Bald Eagle wrote:
> As if on cue, one of the best machinery channels on YT just restored a Datsun
> rear differential.

Not rendered by POV-Ray, but also impressive :).
Are you involved in such real mechanic too ?
--
YB

[Bald Eagle] Re: Results of the discussion on color changes i... [177 days 10 hours and 25 minutes ago]

Sun, 26 Oct 2025 22:00:00 GMT

As if on cue, one of the best machinery channels on YT just restored a Datsun
rear differential.

youtube.com/watch?v=PasrD1id2r4

Enjoy.  :)

- BW

[spigor] Re: Results of the discussion on color changes i... [186 days 2 hours and 35 minutes ago]

Sat, 18 Oct 2025 05:50:00 GMT

Bill,
Thank you so much for your deep insights and very interesting links. At first
glance, it looks like there are tons of incredible things there. I will
definitely explore them further when time permits.

I agree with all your points, which doesn't happen very often.

I'm not sure if free hobbing could ever work, but what about using two
sprockets, a chain, and a tensioner?

I'll get in touch about that industrial EM simulation idea, and I'm eager to
see what comes of it.

Ever so,
Igor

[Bald Eagle] Re: Results of the discussion on color changes i... [186 days 16 hours and 15 minutes ago]

Fri, 17 Oct 2025 16:10:00 GMT

Dr. Zarebski,

> My work with POV-Ray has gone smoothly; it seems almost tailor-made for such
> illustrations due to its precise mathematical approach to description,
> calculation, and rendering of cones and cylinders as lathe objects. It is a
> wonderful tool, and I am grateful to all its creators.

Yes, it's pretty difficult to find something that's so suited to such geometric
tasks yet so accessible to anyone, free, and open-source as well.

"rendering of cones and cylinders as lathe objects"
I'm not sure if going that route gains you anything - cones and cylinders are
basic primitive shapes.
https://wiki.povray.org/content/Reference:Cone
But perhaps the shapes you're using don't have simple flat endcaps.

> I viewed the animation of the hypoid
> gear assembly you sent, and it looks very good, so from that perspective, the
> matter is likely settled.

Well that got modeled by
https://www.otvinta.com/download06.html
and I just wanted something that would clearly depict how the gears work, as
supplementary material to your article.

> For flanks such as those in hypoid gears, a
> unique geometry description method is the use of a point cloud with
> corresponding normal vectors. So, it would be necessary to create an object that
> uses such data as input and generates the surface accordingly.

That sounds to me like numerical methods are used to calculate the geometry, and
a mesh of triangles (perhaps the result of FEM) would be the preferred
embodiment of such data.

> Another known method is simulation of machining by calculating successive tool
> positions in relation to the teeth and subtracting solids from each other.
> Surfaces obtained this way tend to be stepped, not perfectly smooth, require
> extensive computation, and very small angular differences at intersections can
> cause unexpected effects.

Yes, I read a lot about that method when modeling very small gears, as it's
quite commonly used to provide an undercut for clearance of the larger gear's
teeth.

I used the same approach to "machine" the toolpath for the flutes of a twist
drill bit, and encountered everything that you mentioned above.

I'm tempted to suggest that a parametric curve ought to be able to describe the
tooth shape - perhaps a Coons patch for the tooth flank.  Presumably the stepped
tool path could be interpolated and thus provide a smoother result.


> Regarding the transition curve at the tooth root, this involves another set of
> phenomena, which have been highlighted, for example, in
>
https://gearsolutions.com/features/transition-curve-much-more-than-a-radius-at-the-root-fillet-of-a-tooth/

Yeah - I have dealt with stress risers and the consequences of inadequate tooth
strength.  I opened up a manual transmission, and a pile of sheared off teeth
just poured out.  (oof.)

> If the modeling goal was solely animation, it would probably suffice to replace
> it simply with a rounding.

Well, yes.  Graphics and engineering are vastly different fields.
I recall reading a quote attributed to Archimedes about art vs math (which I
have since been unable to find again)
It was basically the observation that in art, one can do whatever one wants, but
with math, there are rigorously enforced rules.
(And having known many artists, they are prone to just do whatever and then
rationalize the result after the fact)


> I also want to say that I have found here a group of very interesting people,
> many apparently passionate about gearing. I admire your achievements and believe
> humanity can be proud of you.

Gears are what lie between accomplishing our useful tasks, and Ayn Rand's engine
that drives the world.
And hypoid gears are what drive most heavy vehicles in the rear differential.

Are you familiar with Brandon Sander of Inheritance Machining?
He recently tried to machine some gears, and could probably use some expert
advice from someone of your caliber.
https://www.youtube.com/watch?v=sQ_blQAkC4Y

> I've noticed that collaboration among diverse communities can yield surprising
> and beautiful results. A relative of mine, uncle Zdzisiek, an industrial
> conveyor designer, used to say: "If something can't be done, give it to a
> student. The student doesn't know it can't be done and will just do it."

I agree, and have made the same point.  And I will point out that we both know
the real meaning of "just".  ;)

> For example, I had an industrial project in mind related to electromagnetic wave
> simulation in an industrial setting. If of any interest, anyone wishing to
> contact me directly can find me at the email starting with spigor and ending
> with op.pl.

I can't say that I could help, but I'm interested in hearing about it.  :)

Also, are you familiar with Paul Nylander?
http://www.bugman123.com/Physics/index.html

> I wish you all the best!
> Kind regards,
> Igor

Thank you,
for the kind words, and for sharing the results of your work.

- BW

[yesbird] Re: Results of the discussion on color changes i... [186 days 18 hours and 26 minutes ago]

Fri, 17 Oct 2025 13:59:11 GMT

On 17/10/2025 11:17, spigor wrote:
> About 20 years ago, for the Non-circular gear animation within the Travelling
> Curves project, I used a height field object, but that approach has obvious
> limitations.
>
https://news.povray.org/povray.binaries.animations/thread/%3C68f0002e%241%40news.povray.org%3E/
> https://paulstgeorge.com/travelling-curves/index.html

Can you please share the geometry of gears from 'Travelling curves' ?
They are so unusual and attractive - I would like to make online
real-time animations of them.

> For example, I had an industrial project in mind related to electromagnetic wave
> simulation in an industrial setting. If of any interest, anyone wishing to
> contact me directly can find me at the email starting with spigor and ending
> with op.pl.

Thank you for the invitation, I sent an email today.

With best wishes,
-- 
YB

[spigor] Re: Results of the discussion on color changes i... [187 days and 5 minutes ago]

Fri, 17 Oct 2025 08:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Dr. Zarebski,
>
> I'm happy to see that everything worked out well for you.
>
> Although I have been interested in the geometric, mechanical, and engineering
> aspects of gears for some years, the level that you're operating at is of course
> well beyond anything that I've explored in depth.
>
> From a development standpoint, I'm wondering if you ran into any difficulties or
> limitations with the present POV-Ray release, and if there were any mathematical
> or geometric tools that would have helped you more easily accomplish your task.
>
> And, just out of curiosity, how much more work would be required to fully model
> a set of mating gears complete with teeth?  Because that would make a fantastic
> animation!
>
> I'm also glad to see that in the course of your inquiries and analyses that you
> discovered the previously unknown, or at least unpublished attribute of the
> hypoid gears having a contact stripe rather than simply a tangent line. Surely
> that will be important for analyzing axle and gear stress, strain, and wear.
>
> Wishing you all the best, and thank you for choosing, using, and mentioning
> POV-Ray!
>
> -Bill Walker
>
>
>
> Here are my introductory-level gear projects:
>
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.56eb28497cd2ac6a5e7df57c0%40news.povray.org%3E/
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.593939a97ee89277c437ac910%40news.povray.org%3E/?ttop=4194
32
> &toff=50&mtop=416421
>
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5bde30bdb3e70712765e06870%40news.povray.org%3E/?ttop=446
46
> 1&toff=800

Hello Bill
Thank you for your thoughtful message and for sharing your interesting projects
and insights.

My work with POV-Ray has gone smoothly; it seems almost tailor-made for such
illustrations due to its precise mathematical approach to description,
calculation, and rendering of cones and cylinders as lathe objects. It is a
wonderful tool, and I am grateful to all its creators.

In my opinion, fully modeling gear teeth would first require answering several
questions. If done purely for educational animation purposes, aesthetics matter
most while other factors take a back seat. I viewed the animation of the hypoid
gear assembly you sent, and it looks very good, so from that perspective, the
matter is likely settled.

However, if the modeling were to be used for highly accurate purposes, two areas
should be distinguished the active flank and the transition curve at the tooth
root. For flanks in the simplest involute cases parametric equations exist, but
here we are not talking about those. For flanks such as those in hypoid gears, a
unique geometry description method is the use of a point cloud with
corresponding normal vectors. So, it would be necessary to create an object that
uses such data as input and generates the surface accordingly.

Another known method is simulation of machining by calculating successive tool
positions in relation to the teeth and subtracting solids from each other.
Surfaces obtained this way tend to be stepped, not perfectly smooth, require
extensive computation, and very small angular differences at intersections can
cause unexpected effects.

Regarding the transition curve at the tooth root, this involves another set of
phenomena, which have been highlighted, for example, in
https://gearsolutions.com/features/transition-curve-much-more-than-a-radius-at-the-root-fillet-of-a-tooth/
If the modeling goal was solely animation, it would probably suffice to replace
it simply with a rounding.

There are software packages on the market that realize these tasks in various
ways, so before investing effort in new functionality, one should consider where
we would stand after creating it. A "hypoid gear modeling" query on YouTube
shows some interesting results.

About 20 years ago, for the Non-circular gear animation within the Travelling
Curves project, I used a height field object, but that approach has obvious
limitations.
https://news.povray.org/povray.binaries.animations/thread/%3C68f0002e%241%40news.povray.org%3E/
https://paulstgeorge.com/travelling-curves/index.html

I also want to say that I have found here a group of very interesting people,
many apparently passionate about gearing. I admire your achievements and believe
humanity can be proud of you.

I've noticed that collaboration among diverse communities can yield surprising
and beautiful results. A relative of mine, uncle Zdzisiek, an industrial
conveyor designer, used to say: "If something can't be done, give it to a
student. The student doesn't know it can't be done and will just do it."

For example, I had an industrial project in mind related to electromagnetic wave
simulation in an industrial setting. If of any interest, anyone wishing to
contact me directly can find me at the email starting with spigor and ending
with op.pl.

I wish you all the best!
Kind regards,
Igor

[Paul Bourke] Re: Impossible stl file conversion! [187 days and 55 minutes ago]

Fri, 17 Oct 2025 07:30:00 GMT

> STL may exist in binary form (although I see no good reason for that.

Binary stl files are much smaller in size.
Otherwise as easy to parse as the ascii readable variant.

[Bald Eagle] Re: Fractional axis labeling [188 days 6 hours and 20 minutes ago]

Thu, 16 Oct 2025 02:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> I like this; I might print it out and hang it over my own machines.

Well, what I would do is use the 1/64th scale with the metric equivalents.

And now that I'm telling you to do that, I should look into going in the reverse
direction.

And Metric.

I had a conversation way back with clipka about print resolution data in the
file output.

If we can work out a way to print to scale, then you could also draw tori with
specific diameters, boxes to show the thickness of sheet metal, etc.

And like I did with my (unfinished) slide rule, you could define arrays of
special sizes - number and letter drill bits, and plot those on the scale too.

(I just scored an L. S.  Starrett No. 245 Engineer's Gauge at he flea market)

> An improvement would be to align/stretch each conversion line so that the
> '1.0-unit'-ends on the right will all line up vertically...so that it's clear as
> to where each conversion's values match the others. When I first looked at your
> graph, I assumed that this was already the case.

No, these are just arbitrarily scaled lines that get divided up.
Just take some x-value and set that as the length, and you can calculate
conversion factors for all of the Multipliers in the calls to DrawGraduatedLine
().

> I'm also curious about the divide-by-11 line; the practical use of that one is a
> mystery to me. What's a real-world example?

But you were ok with 18ths and 5ths?

To test if the algorithm works.
What if you wanted to fold a line up into an hendecagon/undecagon?
You'd need to divide it equally into 11 parts.
What if you needed to measure things for The Six-Fingered Man?
Or your amp went up to ELEVEN?

Why tau?  or pi?  or 18?  16?  32?  64?  24?  4?

It needed to be value agnostic.

- The Great Northern Walker

[yesbird] Re: Results of the discussion on color changes i... [188 days 6 hours and 36 minutes ago]

Thu, 16 Oct 2025 01:48:51 GMT

On 16/10/2025 02:40, Bald Eagle wrote:
> And now, through the magic of Sergei's online conversion tool,
> I don't have to do any complex math.
> 
> Enjoy the hypoid gear set - wheel and pinion.

Really nice !
But I'd prefer to see them rusty ).

Gears is my love since a childhood, my grandfather was a chief mechanic
of a heavy machine tool plant - I often saw machinery blueprints at
home and was enchanted by them. Now I have a small CNC (10x13 cm) and
play with it from time to time.

I am completely sure that you know this site:
https://geargenerator.com/
--
YB

[Kenneth] Re: Fractional axis labeling [188 days 7 hours and 35 minutes ago]

Thu, 16 Oct 2025 00:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> It is not extensively tested or optimized in any way.
>
I like this; I might print it out and hang it over my own machines.

An improvement would be to align/stretch each conversion line so that the
'1.0-unit'-ends on the right will all line up vertically...so that it's clear as
to where each conversion's values match the others. When I first looked at your
graph, I assumed that this was already the case.

I'm also curious about the divide-by-11 line; the practical use of that one is a
mystery to me. What's a real-world example?

[Bald Eagle] Re: Results of the discussion on color changes i... [188 days 8 hours and 40 minutes ago]

Wed, 15 Oct 2025 23:45:00 GMT

And now, through the magic of Sergei's online conversion tool,
I don't have to do any complex math.

Enjoy the hypoid gear set - wheel and pinion.

- BW

[spigor] Re: Very thin material - how to avoid color chan... [188 days 16 hours and 50 minutes ago]

Wed, 15 Oct 2025 15:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> I do think, however, that the illustrations you created look "the
> bee's knees", very elegant.

Well, you and everyone behind POV-Ray made this possible! Thank you so much!
Igor

[Bald Eagle] Re: Results of the discussion on color changes i... [188 days 21 hours and 35 minutes ago]

Wed, 15 Oct 2025 10:50:00 GMT

"spigor" <nomail@nomail> wrote:
> Hi
>
> For those interested, here are the results of the discussion in the thread
> https://news.povray.org/web.671f6067fcb28935402042d461a8e06%40news.povray.org
>
> https://archive.geartechnology.com/view/8600970/50/
>
> Thank you once again for your efforts! All the best.

Dr. Zarebski,

I'm happy to see that everything worked out well for you.

Although I have been interested in the geometric, mechanical, and engineering
aspects of gears for some years, the level that you're operating at is of course
well beyond anything that I've explored in depth.

From a development standpoint, I'm wondering if you ran into any difficulties or
limitations with the present POV-Ray release, and if there were any mathematical
or geometric tools that would have helped you more easily accomplish your task.

And, just out of curiosity, how much more work would be required to fully model
a set of mating gears complete with teeth?  Because that would make a fantastic
animation!

I'm also glad to see that in the course of your inquiries and analyses that you
discovered the previously unknown, or at least unpublished attribute of the
hypoid gears having a contact stripe rather than simply a tangent line. Surely
that will be important for analyzing axle and gear stress, strain, and wear.

Wishing you all the best, and thank you for choosing, using, and mentioning
POV-Ray!

-Bill Walker

Here are my introductory-level gear projects:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.56eb28497cd2ac6a5e7df57c0%40news.povray.org%3E/

http://news.povray.org/povray.binaries.images/thread/%3Cweb.593939a97ee89277c437ac910%40news.povray.org%3E/?ttop=419432
&toff=50&mtop=416421

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5bde30bdb3e70712765e06870%40news.povray.org%3E/?ttop=44646
1&toff=800

[jr] Re: Very thin material - how to avoid color chan... [188 days 23 hours and 20 minutes ago]

Wed, 15 Oct 2025 09:05:00 GMT

hi,

"spigor" <nomail@nomail> wrote:
> ...
> Hi
> Here's the result:
>
> [https://archive.geartechnology.com/view/8600970/50/]

the subject matter is "well above my pay grade" :-), and I did not read the
article.  I do think, however, that the illustrations you created look "the
bee's knees", very elegant.

thanks for posting.

regards, jr.

[spigor] Results of the discussion on color changes in ve... [189 days 1 hour ago]

Wed, 15 Oct 2025 07:25:00 GMT

Hi

For those interested, here are the results of the discussion in the thread
https://news.povray.org/web.671f6067fcb28935402042d461a8e06%40news.povray.org

https://archive.geartechnology.com/view/8600970/50/

Thank you once again for your efforts! All the best.

Kind regards,
Igor

[Bald Eagle] Re: Fractional axis labeling [189 days 6 hours and 45 minutes ago]

Wed, 15 Oct 2025 01:40:00 GMT

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

> Finally I have some functional code that will subdivide a line segment,
> calculate the simplified fractional value, use "value symbols" like pi or tau,
> append units, and rotate the axis labels.

[Bald Eagle] Fractional axis labeling [189 days 7 hours and 35 minutes ago]

Wed, 15 Oct 2025 00:50:00 GMT

So, as you all know, I do a lot of graphing, and at one point wanted to have a
nice way to create fractional labels for things like angle values in radians.

I also have a vintage tool addic...  hobby.
And I live in the the US and so use the Imperial system of measurement.

And I wanted to organize all of my drill bits by 64ths of an inch.

And I was bored at work, so I used the gcd function in excel to hammer out the
basics.

Then I ported to povray using the recursive gcd function I wrote.
And then fiddled, DEBUGGED, tweaked, etc.

Finally I have some functional code that will subdivide a line segment,
calculate the simplified fractional value, use "value symbols" like pi or tau,
append units, and rotate the axis labels.

It is not extensively tested or optimized in any way.

Enjoy

[spigor] Re: Very thin material - how to avoid color chan... [189 days 11 hours and 50 minutes ago]

Tue, 14 Oct 2025 20:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "spigor" <nomail@nomail> wrote:
> > Also, I'm sorry for my ignorance on these parameters. I'm an occasional user of
> > this superb software. I did my last project around 2006
> > (https://paulstgeorge.com/travelling-curves/), before that probably in the 90s.
>
> only had time for a very cursory look, alas, but will re-visit.  ('carpet
> castle' appealed :-))
>
> hope you'll find plenty "excuses" to continue using POV-Ray in future projects.
> cheers.
>
>
> regards, jr.

Hi
Here's the result:

[https://archive.geartechnology.com/view/8600970/50/]

Thank you again for your input!
Kind regards,
Igor

[Mr] Re: POV-Ray promotion [197 days 20 hours and 10 minutes ago]

Mon, 6 Oct 2025 12:15:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 1/10/2025 02:04, yesbird wrote:
> > Dear friends-povers !
> >
> > All of us know that our lovely oldest but goldest ray tracer has
> > great potential, but unfortunately not much popular among the modern
> > community for a couple of reasons: complicated SDL, lack of dedicated
> > editor (but Blender can export), not enough information in media, etc.
> >
> > Bill works hard to improve this situation, but the skills and time of
> > one man is not enough for such complicated and time consuming stuff. I
> > would like to assist him all ways I can and have a following proposal.
> >
> > Having conversion service for all popular graphics formats
> > (https://povlab.yesbird.online/all2pov/) now we can try to attract
> > people from most active CG communities, at least:
> > https://www.zbrushcentral.com/
> > https://www.artstation.com/
> > https://blenderartists.org/
> > https://polycount.com/
> >
> > I am already registered in many of them, and can try to make some
> > advertising to to POV-Ray there. The main problem I see here is a
> > lack of modern and convenient communication channel - newsgroups are
> > outdated and people don't want to take a step (or more) back.
> > Realtime chats, fast graphics and video exchange is very important when
> > discussing technical graphics details, so if we need to move forward,
> > appropriate service is a must have.
> >
> > You will laugh, but I guess that Discord channel will be the best
> > solution as it is very popular among CG and gaming society, easy to use
> > and satisfies all our needs. We can use it not instead, but as addition
> > to our present newsgroups publishing best images, technical hints, and
> > answering questions.
> >
> > What do you think about all of the above ?
> > Let's make POV-Ray great again ! (Or, maybe, not ?)
>
> I have a list of things I want to add to POV once we get 3.8 out of the way (I need
someone to do that as I can't, at
 least not right now). Most of the things in my list touch exactly on the topic of
getting more traction. Primarily, th
e way I see we could get most traction is by having not just the full POV-Ray in
releases (i.e. what we have now), but 
also a libPOV - i.e. POV-Ray as a library, without a parser, specifically intended to
be integrated with third-party ap
plications.
>
> This will provide the means for platform-independent raytracing (whether intending
to really raytrace or just to crea
te simple graphics) in applications via a carefully-defined API implemented in a few
officially-supported major languag
es (at least C++, C# / dotnet and Python - the latter is critical). The API would
allow direct creation of objects with
out using SDL, plus permit calling existing functions such as trace etc. It would also
allow for animations to avoid ha
ving to re-parse the entire source when only moving the camera (or a few objects as
long as bounding is re-calculated).

>
> Apart from making it easy to add sophisticated graphic generation to just about
anything, from a simple python script
 up to a huge C++ application (a good example would be rendering circuit boards in PCB
editors).
>
> Additionally it would make it much easier for existing 3D tools to add POV-Ray
support since rather than having to ge
nerate SDL they can call our API directly.
>
> I have a few libraries that I have squirreled away somewhere that would add value,
such as generic object import; I'l
l have to dig them out and list them here.
>
> As for engagement in terms of talking / forums - I have a dislike of walled gardens
like Discord as the knowledge sha
red there is locked away from search and thus does not benefit the general public. I
would consider endorsing one provi
ded we have a path to extract the chats / threads into a form we can have on our
website, thus allowing it to be indexe
d via search engines.
>
> As for our forums themselves - the entire forum system here on news.povray.org needs
replacing with a much more moder
n alternative. I have a (commercial, but affordable) candidate I would like to use,
but the one thing that is bugging m
e is it would require dropping support for NNTP (unless I want to write a plugin for
it, which I don't). If we went thi
s way basically the current forums would be made available on the new site as a
read-only copy of what's here now, sepa
rate from the live forums. There's a bunch of issues with moving to a new forum (like,
do we make the effort to match u
ser accounts with the archived posts) but overall I consider it essential in the long
term.
>
> I'm interested in hearing from existing NNTP users as to whether the move to a
web-based forum will be an impediment 
to you.
>
> Finally: all the above is a bit of a brain-dump that I came up with in the period of
a few minutes; a much more detai
led reply would take me hours as I would need to look at all my notes and saved links
accumulated over the last few yea
rs. Hence some of what I said here may be not quite right, but the overall meaning is,
I hope, understood.
>
> -- Chris

I love these ideas !
About the slowness of Blender's exporter, my bad for it, but some margin does
exist to make it faster, though indeed having a Python module to just import
into the Blender add-on seems grand! and probably way faster, I would assume, if
it has a way to modularly load data, but my own compiled languages skills are
too limited so far if this requires something else than Python to assemble: my
immediate strategy would just be to load blender structures from numpy array
buffers or subsequent alternatives (some alternatives to numpy can already work
on GPU, but these are not yet cross-hardware compatible. Maybe one universal
enough will appear one day or even numpy itself get the feature). Persistent
data and differential file rendering for animated scenes is indeed a key
feature. Meanwhile I'll keep my effort refactoring POV@Ble but I could use some
more expert devs opinions about it. Even when staying within Python only-realm.

[Mr] Re: POV-Ray promotion [197 days 20 hours and 30 minutes ago]

Mon, 6 Oct 2025 11:55:00 GMT

Josh English <Jos### [at] joshuarenglishcom> wrote:
> On 9/30/2025 11:36 AM, tTh wrote:
> > On 9/30/25 18:04, yesbird wrote:
> >
> >> What do you think about all of the above ?
> >
> >     And how many povers are on Mastodon ?
> >
> >     https://mastodon.tetaneutral.net/tags/povray
> >
> I'm there, but I post on Pixelfed. Not many raytraced images, but when I
> feel I should share something it shows up there, too.
>
> Josh

Yes, I'm there too, and to me, this is the direction to investigate, though
Chris Cason would know better of this kind of tool's limitations or issues, I
would definitely vote for a custom tailored mastodon instance, interoperability
is huge, it generates RSS on the fly, and I even wonder if it couldn't actually
interoperate with NNTP? in order to bridge the old database with a new modern
looking interface with a limited and efficient toolset, much more reasonably
manageable than the Discourse powerplant.

[Josh English] Re: POV-Ray promotion [198 days 10 hours and 7 minutes ago]

Sun, 5 Oct 2025 22:18:08 GMT

On 9/30/2025 11:36 AM, tTh wrote:
> On 9/30/25 18:04, yesbird wrote:
> 
>> What do you think about all of the above ?
> 
>  Â Â  And how many povers are on Mastodon ?
> 
>  Â Â  https://mastodon.tetaneutral.net/tags/povray
> 
I'm there, but I post on Pixelfed. Not many raytraced images, but when I 
feel I should share something it shows up there, too.

Josh

[Bald Eagle] Re: Array and vector functions? [199 days 17 hours ago]

Sat, 4 Oct 2025 15:25:00 GMT

I wrote this back in 2022 to play with this sort of thing.

I think that kurtz le pirate also wrote something along these lines once.
http://news.povray.org/povray.general/thread/%3C6580562c%241%40news.povray.org%3E/?ttop=445919&toff=100

Hope these ideas help.

- BW

[Bald Eagle] Re: Array and vector functions? [199 days 17 hours and 25 minutes ago]

Sat, 4 Oct 2025 15:00:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

> (sighing like an angry snake)

I will join you in the chorus.

> Ok, surely I can try transmitting
> arguments in unpacked form like function(array[0], array[1], array[2],
> etc).

You can, and can more easily do so using a loop.
So, write a macro to loop through all of your array indices, and that will work
just fine.
The only thing is, you only get to define that function with it's current array
values ONCE.   Because the function gets defined at parse time and cannot be
changed during render time.

> Once upon a time I even wrote function with 13 named arguments
> (for my Scale3xSFX implementation), but at list I didn't have to unpack
> them every time since they were named already...

Like I said, there are workarounds.
I needed something like this once or twice, and you can do a few interesting
things.
First, you can write a function that allows you to change which parts of the
array that use so that you're not constantly using them all.
Fn=function (N) { select (N, 0, 1, 0) * Array [1] + ....}
So if you write a function where the zeroes land on the array elements that you
want, then those are the only ones multiplied by 1.

You can also write spline functions.

WFP has experiments with using image_maps as a way to sort of store values in an
"array"

- BE

[jr] Re: Array and vector functions? [199 days 20 hours and 25 minutes ago]

Sat, 4 Oct 2025 12:00:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 03.10.2025 22:47, Bald Eagle wrote:
> > You are correct in that they do not exist as inbuilt functions
> (sighing like an angry snake) Ok, surely I can try transmitting
> arguments in unpacked form like function(array[0], array[1], array[2],
> etc). ...

if you're not "averse", you could perhaps use simple list/queue macros; eg
<drive.google.com/file/d/1-lISncj8_qJQsjXR2TclUc67Whv-HmZL/view?usp=sharing>


regards, jr.

[Ilya Razmanov] Re: Array and vector functions? [199 days 22 hours and 12 minutes ago]

Sat, 4 Oct 2025 10:13:14 GMT

On 03.10.2025 22:47, Bald Eagle wrote:
> 
> You are correct in that they do not exist as inbuilt functions
> 

(sighing like an angry snake) Ok, surely I can try transmitting 
arguments in unpacked form like function(array[0], array[1], array[2], 
etc). Once upon a time I even wrote function with 13 named arguments 
(for my Scale3xSFX implementation), but at list I didn't have to unpack 
them every time since they were named already...

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

[Bald Eagle] Re: Array and vector functions? [200 days 12 hours and 35 minutes ago]

Fri, 3 Oct 2025 19:50:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greetings sentients,
>
> do I understand it correctly that POV-Ray does not have array functions
> (meaning I can neither pass an array as argument nor receive it as a
> result), and vector functions are so limited that practically aren't
> worth mentioning?

You are correct in that they do not exist as inbuilt functions

The best we have is

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

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 transforms return a three component vector, while 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.

Depending on what you want to specifically do, there might possibly be a
workaround.

- BE

[Ilya Razmanov] Array and vector functions? [200 days 13 hours ago]

Fri, 3 Oct 2025 19:24:59 GMT

Greetings sentients,

do I understand it correctly that POV-Ray does not have array functions 
(meaning I can neither pass an array as argument nor receive it as a 
result), and vector functions are so limited that practically aren't 
worth mentioning?

I have a weird idea of turning my POV-Ray Mosaic

https://dnyarri.github.io/povzaika.html

into something even more unhuman. Currently primitive attributes are 
controlled by source pixel brightness; I'm thinking of making it 
controlled by arbitrary function of color and coordinates (yes, 
something like "Xaos Tools" "Paint Alchemy" Photoshop plugin, but for 
3D). Not sure it's a good idea but why not to try somedays. For that, I 
need some suitable form of passing arguments/results in a packed form, 
to avoid turning all this into something obscure and cabbalistic.

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

[m@b] Re: Changes to text object? [201 days 6 hours and 21 minutes ago]

Fri, 3 Oct 2025 02:04:23 GMT

On 02/10/2025 15:40, m@b wrote:
> I keep getting this error:
> 

Fixed it now - I got 3.8 beta 2 from github.


Thanks everybody.
m@

[m@b] Re: Changes to text object? [201 days 7 hours and 28 minutes ago]

Fri, 3 Oct 2025 00:57:03 GMT

On 02/10/2025 20:09, Bald Eagle wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
> 
>> #version 3.7;
> 
> But you're using 3.8
> 
> 
> 
Makes no difference,

#version 3.8;

gives the same warning.

[Bald Eagle] Re: Open tab closeout [201 days 14 hours and 10 minutes ago]

Thu, 2 Oct 2025 18:15:00 GMT

Part 2

https://polymake.org/doku.php/start

http://blog.hvidtfeldts.net/index.php/2011/12/distance-estimated-3d-fractals-vii-dual-numbers/

https://antofthy.gitlab.io/graphics/polyhedra/maths.html

quadratics, cubics, quadrics, parametrics, etc
https://people.computing.clemson.edu/~dhouse/courses/405/notes/

https://markjgillespie.com/Research/harnack-tracing/HarnackTracing.pdf

https://www.cs.toronto.edu/~jacobson/images/skinning-cubic-bezier-splines-and-catmull-clark-subdivision-surfaces-siggra
ph-asia-2014-liu-et-al.pdf

- BE

[Bald Eagle] Open tab closeout [201 days 14 hours and 45 minutes ago]

Thu, 2 Oct 2025 17:40:00 GMT

Just posting these links here for general interest and archival purposes.

https://medium.com/@rodrigosetti/the-broccolis-equation-2ed8faaa3f3a

https://robertlovespi.net/tag/rotate/

wrt sphere_sweep
https://tu-dresden.de/ing/informatik/smt/cgv/ressourcen/dateien/publikationen/2020/HermiteSplineTubesVIS2020.pdf?lang=e
n

https://tu-dresden.de/ing/informatik/smt/cgv/ressourcen/dateien/publikationen/2005/streamlines.pdf?lang=en

Matrix math
https://byjus.com/maths/cramers-rule/

http://www.microscopy-uk.org.uk/mag/indexmag.html?http://www.microscopy-uk.org.uk/mag/artjan06/bjmaths.html

- BE

[Bald Eagle] Re: Changes to text object? [201 days 19 hours and 55 minutes ago]

Thu, 2 Oct 2025 12:30:00 GMT

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

> why ??  the example you posted is fine, nothing wrong with the code as written.

Because pre-second-coffee, earlier in the thread, I was curious if:

1. it would work.   Like auto-detect image_map file format
and
2. it would solve the issue because some keyword thing triggered some extra
check that issued the warning.

- BW

[jr] Re: Changes to text object? [201 days 20 hours and 10 minutes ago]

Thu, 2 Oct 2025 12:15:00 GMT

hi,

"m@b" <sai### [at] googlemailcom> wrote:
> ...
> If I take out the ttf I get:
>   "Characters01.inc" line 275: Parse Error: Expected 'ttf or internal',
> string identifier found instead"

why ??  the example you posted is fine, nothing wrong with the code as written.


regards, jr.

[Bald Eagle] Re: Changes to text object? [201 days 20 hours and 15 minutes ago]

Thu, 2 Oct 2025 12:10:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:

> #version 3.7;

But you're using 3.8

[jr] Re: Changes to text object? [201 days 20 hours and 15 minutes ago]

Thu, 2 Oct 2025 12:10:00 GMT

hi,

"m@b" <sai### [at] googlemailcom> wrote:
> ...
> > strange, what version are you using ? ...

thanks for the screenshot.  unsure of exact details but think the whole alpha
line post 9945627 was abandoned / "rolled back" by clipka, causing problems
(then) for 'qtpovray' etc.  I suggest getting a different executable.

> #version 3.7;

out of interest, why not 3.8 ?

regards, jr.

[m@b] Re: Changes to text object? [201 days 20 hours and 18 minutes ago]

Thu, 2 Oct 2025 12:06:52 GMT

On 02/10/2025 18:41, Bald Eagle wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>> I keep getting this error:
>>
>> "Text may not be displayed as expected. Please refer to the user manual
>> regarding changes in POV-Ray v3.8 and later."
>>
>> Here is my sdl line:
>>
>> #declare CapFont = "segoeprb.ttf";
>>
>> text { ttf CapFont, "Read my diary", 0.2, 0.0 pigment{rgb<0,0,1>*1.3}
>> scale 1.5    translate<12.0, 22.25, 012.49>}
>>
>> I am struggling to find the relevant documentation.
>> Any help please.
>>
>> Thanks.
>> m@
> 
> What's your #version directive?
> Something happened with clipka working on some of the code, and this started
> happening, and then it got fixed...   can't find the thread about that.
> 
> Also, is the ttf optional or required?
> 
> - BE
> 

#version 3.7;

If I take out the ttf I get:
  "Characters01.inc" line 275: Parse Error: Expected 'ttf or internal', 
string identifier found instead"

[m@b] Re: Changes to text object? [201 days 20 hours and 34 minutes ago]

Thu, 2 Oct 2025 11:50:48 GMT

On 02/10/2025 17:11, jr wrote:
> hi,
> 
> "m@b" <sai### [at] googlemailcom> wrote:
>> I keep getting this error:
>>
>> "Text may not be displayed as expected. Please refer to the user manual
>> regarding changes in POV-Ray v3.8 and later."
>>
>> Here is my sdl line:
>>
>> #declare CapFont = "segoeprb.ttf";
>>
>> text { ttf CapFont, "Read my diary", 0.2, 0.0 pigment{rgb<0,0,1>*1.3}
>> scale 1.5    translate<12.0, 22.25, 012.49>}
>>
>> I am struggling to find the relevant documentation.
>> Any help please.
> 
> strange, what version are you using ?  the above parses "clean" for me (with
> #version directive and global_settings{} block) using alpha.9945627 and beta.2.
> 
> 
> regards, jr.
> 

#version 3.7;
global_settings{ assumed_gamma 1.5 }

[yesbird] Re: POV-Ray promotion [201 days 21 hours and 16 minutes ago]

Thu, 2 Oct 2025 11:09:01 GMT

On 01/10/2025 01:28, Chris Cason wrote:
> I never said anything about RTR. Specifically, I mentioned 
> "platform-independent raytracing" - this is the entire point, it's 
> independent of GPU or API. Anyone using it does not need to care what 
> the target system is equipped with.

I was confused by mentioned 'animations', now I see that it has no
relation to RTR, sorry.

> I'm not sure of where/when those discussions were, but, given I have 
> worked on this codebase for 30 years, I think I have a pretty good idea 
> of what's possible and how much effort is involved. Basically if I want 
> to do it, I can do it and the effort is not an issue.

Sure, no doubt.

> I have a (commercial, but affordable) candidate I would like to use, but the one
thing that is bugging me is it would require dropping support for NNTP (unless I want
to write a plugin for it, which I don't).

May I ask you about details of your choice ?
I like how Discourse (not mix with Discord :)) works and already tried
it for 14 days: https://www.discourse.org/

I can be indexed and has NNTPplugin:
https://meta.discourse.org/t/sync-discourse-with-nntp/58602

But migration will be painful, agree.
-- 
YB

[Bald Eagle] Re: Changes to text object? [201 days 21 hours and 40 minutes ago]

Thu, 2 Oct 2025 10:45:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> I keep getting this error:
>
> "Text may not be displayed as expected. Please refer to the user manual
> regarding changes in POV-Ray v3.8 and later."
>
> Here is my sdl line:
>
> #declare CapFont = "segoeprb.ttf";
>
> text { ttf CapFont, "Read my diary", 0.2, 0.0 pigment{rgb<0,0,1>*1.3}
> scale 1.5    translate<12.0, 22.25, 012.49>}
>
> I am struggling to find the relevant documentation.
> Any help please.
>
> Thanks.
> m@

What's your #version directive?
Something happened with clipka working on some of the code, and this started
happening, and then it got fixed...   can't find the thread about that.

Also, is the ttf optional or required?

- BE

[jr] Re: Changes to text object? [201 days 23 hours and 10 minutes ago]

Thu, 2 Oct 2025 09:15:00 GMT

hi,

"m@b" <sai### [at] googlemailcom> wrote:
> I keep getting this error:
>
> "Text may not be displayed as expected. Please refer to the user manual
> regarding changes in POV-Ray v3.8 and later."
>
> Here is my sdl line:
>
> #declare CapFont = "segoeprb.ttf";
>
> text { ttf CapFont, "Read my diary", 0.2, 0.0 pigment{rgb<0,0,1>*1.3}
> scale 1.5    translate<12.0, 22.25, 012.49>}
>
> I am struggling to find the relevant documentation.
> Any help please.

strange, what version are you using ?  the above parses "clean" for me (with
#version directive and global_settings{} block) using alpha.9945627 and beta.2.


regards, jr.

[m@b] Changes to text object? [202 days and 44 minutes ago]

Thu, 2 Oct 2025 07:40:46 GMT

I keep getting this error:

"Text may not be displayed as expected. Please refer to the user manual 
regarding changes in POV-Ray v3.8 and later."

Here is my sdl line:

#declare CapFont = "segoeprb.ttf";

text { ttf CapFont, "Read my diary", 0.2, 0.0 pigment{rgb<0,0,1>*1.3} 
scale 1.5    translate<12.0, 22.25, 012.49>}

I am struggling to find the relevant documentation.
Any help please.

Thanks.
m@

[Chris Cason] Re: POV-Ray promotion [203 days 9 hours and 56 minutes ago]

Tue, 30 Sep 2025 22:28:57 GMT

On 1/10/2025 05:25, yesbird wrote:
> libraries generate SDL and it works fine, but not too fast. If someone
> wants real-time graphics generation OpenGL, Vulkan, WebGL, WebGPU will
> be the better choice. Real-time ray tracing on CPU is unlikely possible,

I never said anything about RTR. Specifically, I mentioned "platform-independent
raytracing" - this is the entire point, it's independent of GPU or API. Anyone using
it does not need to care what the target system is equipped with.

> but I remember a few discussions here that came to the conclusion that this is
almost not possible or will take too much effort

I'm not sure of where/when those discussions were, but, given I have worked on this
codebase for 30 years, I think I have a pretty good idea of what's possible and how
much effort is involved. Basically if I want to do it, I can do it and the effort is
not an issue.

-- Chris

[yesbird] Re: POV-Ray promotion [203 days 12 hours and 59 minutes ago]

Tue, 30 Sep 2025 19:25:52 GMT

On 30/09/2025 20:46, Chris Cason wrote:
> I have a list of things I want to add to POV once we get 3.8 out of the 
> way (I need someone to do that as I can't, at least not right now). Most 
> of the things in my list touch exactly on the topic of getting more 
> traction. Primarily, the way I see we could get most traction is by 
> having not just the full POV-Ray in releases (i.e. what we have now), 
> but also a libPOV - i.e. POV-Ray as a library, without a parser, 
> specifically intended to be integrated with third-party applications.

At first look it sounds very promising, but I remember a few discussions
here that came to the conclusion that this is almost not possible or
will take too much effort. At the same time Blender and some Python
libraries generate SDL and it works fine, but not too fast. If someone
wants real-time graphics generation OpenGL, Vulkan, WebGL, WebGPU will
be the better choice. Real-time ray tracing on CPU is unlikely possible,
I guess.

> As for engagement in terms of talking / forums - I have a dislike of 
> walled gardens like Discord as the knowledge shared there is locked away 
> from search and thus does not benefit the general public. I would 
> consider endorsing one provided we have a path to extract the chats / 
> threads into a form we can have on our website, thus allowing it to be 
> indexed via search engines.
> 

Yes, this is a serious disadvantage, no doubt, the standard forum will
work much better for us.

> I'm interested in hearing from existing NNTP users as to whether the 
> move to a web-based forum will be an impediment to you.

As for me, I will leave Thunderbird easily - always dreamed about
something more convenient.

In general, I would like to make a contribution to the POV-Ray project,
but don't want to get back to C++, after more than 30 years working with
it. I am joined the WebGL community now and implementing some external
online tools and services attracts me much more.
-- 
YB

[tTh] Re: POV-Ray promotion [203 days 13 hours and 48 minutes ago]

Tue, 30 Sep 2025 18:36:57 GMT

On 9/30/25 18:04, yesbird wrote:

> What do you think about all of the above ?

    And how many povers are on Mastodon ?

    https://mastodon.tetaneutral.net/tags/povray

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[Chris Cason] Re: POV-Ray promotion [203 days 14 hours and 35 minutes ago]

Tue, 30 Sep 2025 17:49:42 GMT

On 1/10/2025 02:04, yesbird wrote:
> Dear friends-poversÂ !
> 
> All of us know that our lovely oldest but goldest ray tracer has
> greatÂ potential, but unfortunately not much popular among the modern
> community for a couple of reasons: complicated SDL, lack of dedicated
> editor (but Blender can export), not enoughÂ information in media, etc.
> 
> Bill works hard to improve this situation, but the skills and time of
> one man is not enoughÂ for such complicated and time consuming stuff. I
> would like to assist him all ways I can and have a following proposal.
> 
> Having conversionÂ service for all popular graphics formats
> (https://povlab.yesbird.online/all2pov/) now we can try to attract
> people from most active CG communities, at least:
> https://www.zbrushcentral.com/
> https://www.artstation.com/
> https://blenderartists.org/
> https://polycount.com/
> 
> I am alreadyÂ registered in many of them, and can try to make some
> advertising to to POV-Ray there. The main problem I see here is a
> lack of modern and convenient communication channel - newsgroups are
> outdated and people don't want to take a step (or more) back.
> Realtime chats, fast graphics and video exchange is very important when
> discussing technical graphics details, so if we need to move forward,
> appropriate service is a must have.
> 
> You will laugh, but I guess that Discord channel will be the best
> solution as it is very popular among CG and gamingÂ society, easy to use
> and satisfies all our needs. We can use it not instead, but as addition
> to our present newsgroups publishing best images, technicalÂ hints, and
> answering questions.
> 
> What do you think about all of the above ?
> Let's make POV-Ray greatÂ again ! (Or, maybe, not ?)

I have a list of things I want to add to POV once we get 3.8 out of the way (I need
someone to do that as I can't, at least not right now). Most of the things in my list
touch exactly on the topic of getting more traction. Primarily, the way I see we could
get most traction is by having not just the full POV-Ray in releases (i.e. what we
have now), but also a libPOV - i.e. POV-Ray as a library, without a parser,
specifically intended to be integrated with third-party applications.

This will provide the means for platform-independent raytracing (whether intending to
really raytrace or just to create simple graphics) in applications via a
carefully-defined API implemented in a few officially-supported major languages (at
least C++, C# / dotnet and Python - the latter is critical). The API would allow
direct creation of objects without using SDL, plus permit calling existing functions
such as trace etc. It would also allow for animations to avoid having to re-parse the
entire source when only moving the camera (or a few objects as long as bounding is
re-calculated).

Apart from making it easy to add sophisticated graphic generation to just about
anything, from a simple python script up to a huge C++ application (a good example
would be rendering circuit boards in PCB editors).

Additionally it would make it much easier for existing 3D tools to add POV-Ray support
since rather than having to generate SDL they can call our API directly.

I have a few libraries that I have squirreled away somewhere that would add value,
such as generic object import; I'll have to dig them out and list them here.

As for engagement in terms of talking / forums - I have a dislike of walled gardens
like Discord as the knowledge shared there is locked away from search and thus does
not benefit the general public. I would consider endorsing one provided we have a path
to extract the chats / threads into a form we can have on our website, thus allowing
it to be indexed via search engines.

As for our forums themselves - the entire forum system here on news.povray.org needs
replacing with a much more modern alternative. I have a (commercial, but affordable)
candidate I would like to use, but the one thing that is bugging me is it would
require dropping support for NNTP (unless I want to write a plugin for it, which I
don't). If we went this way basically the current forums would be made available on
the new site as a read-only copy of what's here now, separate from the live forums.
There's a bunch of issues with moving to a new forum (like, do we make the effort to
match user accounts with the archived posts) but overall I consider it essential in
the long term.

I'm interested in hearing from existing NNTP users as to whether the move to a
web-based forum will be an impediment to you.

Finally: all the above is a bit of a brain-dump that I came up with in the period of a
few minutes; a much more detailed reply would take me hours as I would need to look at
all my notes and saved links accumulated over the last few years. Hence some of what I
said here may be not quite right, but the overall meaning is, I hope, understood.

-- Chris

[yesbird] Re: POV-Ray promotion [203 days 15 hours and 40 minutes ago]

Tue, 30 Sep 2025 16:45:33 GMT

On 30/09/2025 19:29, Bald Eagle wrote:
> I tried to gain some traction, but I'd say that there needs to be a lot more
> activity in order to "make it happen"
I understand you, exactly.

> 00face has a server running.  See:
>
https://news.povray.org/povray.general/thread/%3Cweb.67b3c5fb138c20b68918f8c4aef99e11%40news.povray.org%3E/
> Please visit, and post your best renders, ideas, projects, tutorials, etc.
> 
Thanks, I was there before - not serious, not popular, nothing to see
there. But I will try to join ...
-- 
YB

[Bald Eagle] Re: POV-Ray promotion [203 days 15 hours and 55 minutes ago]

Tue, 30 Sep 2025 16:30:00 GMT

yesbird wrote:

> You will laugh, but I guess that Discord channel will be the best
> solution as it is very popular among CG and gaming society, easy to use
> and satisfies all our needs. We can use it not instead, but as addition
> to our present newsgroups publishing best images, technical hints, and
> answering questions.

00face has a server running.  See:

https://news.povray.org/povray.general/thread/%3Cweb.67b3c5fb138c20b68918f8c4aef99e11%40news.povray.org%3E/

I tried to gain some traction, but I'd say that there needs to be a lot more
activity in order to "make it happen"

Please visit, and post your best renders, ideas, projects, tutorials, etc.

Dedicated boards/channels/whatever-they're-called for POV-Ray.

- BW

[yesbird] POV-Ray promotion [203 days 16 hours and 21 minutes ago]

Tue, 30 Sep 2025 16:04:06 GMT

Dear friends-poversÂ !

All of us know that our lovely oldest but goldest ray tracer has
greatÂ potential, but unfortunately not much popular among the modern
community for a couple of reasons: complicated SDL, lack of dedicated
editor (but Blender can export), not enoughÂ information in media, etc.

Bill works hard to improve this situation, but the skills and time of
one man is not enoughÂ for such complicated and time consuming stuff. I
would like to assist him all ways I can and have a following proposal.

Having conversionÂ service for all popular graphics formats
(https://povlab.yesbird.online/all2pov/) now we can try to attract
people from most active CG communities, at least:
https://www.zbrushcentral.com/
https://www.artstation.com/
https://blenderartists.org/
https://polycount.com/

I am alreadyÂ registered in many of them, and can try to make some
advertising to to POV-Ray there. The main problem I see here is a
lack of modern and convenient communication channel - newsgroups are
outdated and people don't want to take a step (or more) back.
Realtime chats, fast graphics and video exchange is very important when
discussing technical graphics details, so if we need to move forward,
appropriate service is a must have.

You will laugh, but I guess that Discord channel will be the best
solution as it is very popular among CG and gamingÂ society, easy to use
and satisfies all our needs. We can use it not instead, but as addition
to our present newsgroups publishing best images, technicalÂ hints, and
answering questions.

What do you think about all of the above ?
Let's make POV-Ray greatÂ again ! (Or, maybe, not ?)
-- 
YB

[Ilya Razmanov] Re: img2mesh geometry improved [203 days 17 hours and 23 minutes ago]

Tue, 30 Sep 2025 15:01:44 GMT

On 30.09.2025 13:24, Mr wrote:

> features like that are what give it most purpose !
> I did not think of it that way before but if turned into a python library
> without any other dependencies than those shipped in Blender (getting it more
> easily "substitutable" to tkinter) , this would definitely be a good candidate
> to integrate as an option for low res enhancement within the current POV@Ble
> (blender's POV addon) heightfield primitive!

This would require me learning Blender addons API. Currently my export 
modules for img2mesh are a module already, but they are written to 
receive source image data in the form I like, namely nested list. I find 
this form both logical and suitable (my POV-Ray Mesh includes image 
filtering module, and if you take a look at it, you'll see that this 
image structure allowed me to write simple generalized filter for 
arbitrary number of channels - it simply processes lists/vectors via map 
regardless of their length). So my programs are rather modular, but in 
the way I like. Others may have different ideas.

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

[Mr] Re: img2mesh geometry improved [203 days 22 hours ago]

Tue, 30 Sep 2025 10:25:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,
>
> while fiddling with some old ideas I unintentionally managed to improve
> some aspects of my img2mesh Python image to heightfield 3D mesh converter.
>
> You can view the results at the top of img2mesh page, updates section:
>
> https://dnyarri.github.io/img2mesh.html
>
> and download either Python originals or compiled Win10 exe.
>
> In view of recent discussion "I would like to ask the community: do
> we really need it?"
>
> I mean new version uses geometry switch based on source local contrast,
> corresponding threshold control is added to program GUI but, obviously,
> it doesn't give real-time preview of final rendering. In theory, I may
> add something like ruby mask preview (like one in Photoshop) for local
> contrast to GUI, but, considering my extremely poor programming skills
> and bad memory, it would be quite time consuming. Surely, I was able to
> make a preview for filtering (you may see it at the bottom of my POV‑Ray
> Thread: Linen and Stitch at
>
> https://dnyarri.github.io/povthread.html#averager
>
> so I can do this, but it wasn't easy.
>
> So, the question is: does anybody really need this img2mesh and stuff?
>
> --
> Ilyich the Toad
> https://dnyarri.github.io/

Latest proposition for sharp transtion is very cool and even more "opinionated"
features like that are what give it most purpose !
I did not think of it that way before but if turned into a python library
without any other dependencies than those shipped in Blender (getting it more
easily "substitutable" to tkinter) , this would definitely be a good candidate
to integrate as an option for low res enhancement within the current POV@Ble
(blender's POV addon) heightfield primitive!

[Cousin Ricky] Re: Did you know? [204 days 14 hours and 46 minutes ago]

Mon, 29 Sep 2025 17:39:38 GMT

On 2025-09-27 13:10 (-4), Leroy wrote:
> 
>  And another interesting thing is that it took me so
> long to find it!

I suppose this is a sign that you've been using good programming practices.

[Cousin Ricky] Re: Did you know? [204 days 14 hours and 48 minutes ago]

Mon, 29 Sep 2025 17:37:02 GMT

On 2025-09-25 18:45 (-4), Leroy wrote:
> Variables can act as any type.

There are some exceptions:
 - Macro names cannot be reused as another type without being #undef'd.
 - Function names cannot be reused--even as another function--without
   being #undef'd.
 - Function formal parameters cannot take the name of any existing
   identifier.

Notwithstanding the above, macro formal parameters can always reuse any
name.

Irritatingly, these apply even to local identifiers, meaning that truly
modular programming is impossible in POV-Ray.  If you write a public
include file, you must make sure that your local variables do not
conflict with any macro names that any other POVer might ever use.  If
you write a function that has any formal parameters other than u, v, x,
y, or z, you must choose parameter names that do not conflict with any
identifier of any type that any other POVer might ever use.  And if
you're just creating a scene file, you always run the risk of your
script bombing out because of conflicts with the innards of include
files that, by rights, you shouldn't have to know about.

The fact that macro formal parameters can reuse macro and function names
shows that this scope leakage is not logically inevitable.  It may take
a lot of work on the parser to fix this design flaw, but I think it
should be a priority.

[Leroy] Re: Did you know? [206 days 15 hours and 10 minutes ago]

Sat, 27 Sep 2025 17:15:00 GMT

"Maetes" <nomail@nomail> wrote:
> I Dont understand where is the problem.
>
> I executed the code in the expectation that something great would happen.
>
> disappointed,
> ma

Sorry there is no problem. I thought that the behavior of changing types of a
variable on the fly was interesting. It is strange coming from C or C++ where
types are written in stone. And another interesting thing is that it took me so
long to find it!

Have Fun!

[Maetes] Re: Did you know? [206 days 23 hours and 50 minutes ago]

Sat, 27 Sep 2025 08:35:00 GMT

I Dont understand where is the problem.

I executed the code in the expectation that something great would happen.

disappointed,
ma

[Leroy] Re: Did you know? [207 days 10 hours and 35 minutes ago]

Fri, 26 Sep 2025 21:50:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Variables can act as any type

I guess I didn't learn all the tricks of POV. When I first came to POV it was
from Qbasic and thought that a float is a float is a float, not a string or
anything else. I carried that on for more than 20 years.
 The only reason I found out was because of You Tube with it topics of the worst
and best programing styles. While playing with macros, trying to make my POV
files hard to read or easier to write in win3.7. Macros need to have the
variable define before using it as an input there. So I wrote a macro to declare
a variable and its type with a string. It worked great. I set it up so that you
could declare an unlimited number of variables with a single string(with one
line of code). Cool!
 I had replace #declare with macro Set(A,B) [#local A=B]. While testing things
out I accidently had A & B different types. That was IT.

 If everyone knew this why haven't we have a contest to write code creating the
most complicated scene with the fewest variables used?
I guess it would end a tie with 2 or 3 variables.

Have fun!

[Bald Eagle] Re: Did you know? [207 days 13 hours and 25 minutes ago]

Fri, 26 Sep 2025 19:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> I think that already worked like that with version 3.5...

He knew.
And we all knew he knew.
He just didn't know he knew.
Once that he knows that he knew he knew, he'll see that it's nothing new.

And I knew that's it nothing new too.

- BE

[Alain Martel] Re: Did you know? [207 days 18 hours and 6 minutes ago]

Fri, 26 Sep 2025 14:19:00 GMT

Le 2025-09-25 Ã  18:45, Leroy a Ã©critÂ :
> Variables can act as any type. Like this
> 
> #declare A="35542";
> #declare B="35542";   #debug concat("A,B",A,B"\n")
> #declare A=45;        #debug concat("A =",str(A,0,0),"\n")
> #declare B=-45;       #debug concat("B =",str(B,0,0),"\n")
> #declare A=<4,5,6>;   #debug concat("A= <",vstr(3,A,",",3,3),">\n")
> #declare B=B+<6,5,4>; #debug concat("B= <",vstr(3,B,",",3,3),">\n")
> #declare A=box{-1,1}
> #declare B=pigment{Red}
> object{A pigment{B}}
> 
> This works on 3.7 & 3.8 win versions.
> 
> Have Fun!
> 

I think that already worked like that with version 3.5...

[Leroy] Did you know? [208 days 9 hours and 35 minutes ago]

Thu, 25 Sep 2025 22:50:00 GMT

Variables can act as any type. Like this

#declare A="35542";
#declare B="35542";   #debug concat("A,B",A,B"\n")
#declare A=45;        #debug concat("A =",str(A,0,0),"\n")
#declare B=-45;       #debug concat("B =",str(B,0,0),"\n")
#declare A=<4,5,6>;   #debug concat("A= <",vstr(3,A,",",3,3),">\n")
#declare B=B+<6,5,4>; #debug concat("B= <",vstr(3,B,",",3,3),">\n")
#declare A=box{-1,1}
#declare B=pigment{Red}
object{A pigment{B}}

This works on 3.7 & 3.8 win versions.

Have Fun!

[Kenneth] Re: Impossible stl file conversion! [209 days 17 hours ago]

Wed, 24 Sep 2025 15:25:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 23.09.2025 20:06, Kenneth wrote:
>
> ..or as part of a CSG construction (with the addition of
> > an inside vector to the converted mesh).
>
> STL models, by their nature, must have all sides defined (which makes
> STLs exported by my img2mesh twice as big as POVs, since POVs only have
> a top side). So I guess inside vector may be any.
>
I usually use a single  inside_vector <1,1,1>  in my meshes, so that its vector
direction is not pointed exactly toward any of the x,y,z axes or planes. This
helps prevent subtle CSG errors that have been known to occur at times. <1,1,1>
is my generic 'safety measure'. ;-)

[Bald Eagle] Re: Impossible stl file conversion! [209 days 17 hours and 40 minutes ago]

Wed, 24 Sep 2025 14:45:00 GMT

yesbird wrote:
> On 20/09/2025 16:46, yesbird wrote:
> > Adding export to mesh2 and interface modification is not too
> > complicated, but before starting, I would like to ask the community: do
> > we really need it ?
>
> And so, "silence is golden" :). Now I am completely sure that POV-Ray is
> self-sufficient and doesn't need any external sources of geometry.

Similar to how Le Forgeron states in his sig:
"Just because nobody complains does not mean all parachutes are perfect."

I would follow that up with a similar:
"Just because no one got back to you, doesn't mean no one wants the feature."

There are, as I understand things, many people who download and use POV-Ray
academically and professionally, yet we never see them here on the forums.
People hang out in weird places on the internet, or just have no interest in
participating in the forums.
Over the years, I have tried to scour the internet and post links to instances
where people have, or are currently using POV-Ray - with links to articles,
websites, and sometimes name + academic position.
There is also the phenomenon that this forum will be radio silent for 2 weeks or
more, and then a sudden flurry of activity will occur all at once.

So asking here is not the best way to receive a meaningful answer.

> Thanks for saving my time and effort :).

I was just suggesting it.
I know you have a lot of other activities that take up your time and attention.

- bw

[Bald Eagle] Re: img2mesh geometry improved [210 days 14 hours and 10 minutes ago]

Tue, 23 Sep 2025 18:15:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

> Oh, it's all pretty simple (remember that I started it for my own use,
> and not a science project).

To me, this seems similar to a convolution kernel.
I wonder if you could draw inspiration from that field and achieve some other
effects.  All of your other experiments have yielded really nice results, so I
can only imagine that you would develop some pretty spectacular stuff.

- bw

[Kenneth] Re: Impossible stl file conversion! [210 days 14 hours and 10 minutes ago]

Tue, 23 Sep 2025 18:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > And a favorite technique of my own is to turn an object (even a mesh) into an
> > object pattern, then into a function, and to use that to create an isosurface
> > (although this has some limitations)-- but which can then be altered with
> > interesting distortions like warp{turbulence...}, fnoise_3D, etc.
>
> touch base with Bill Pragnell about how best to use functions to distort your
> meshes directly.

Yes, meshes could be distorted in other ways than by my object-pattern idea; but
I mostly use CSG models with the process. It just happens that meshes work with
it too.

The downside of the process is a lighting problem: The resulting isosurface does
NOT respond to lighting well, and looks very odd-- the surface normals are
*quite* strange, to say the least, probably because the object pattern was never
made to be used this way.  So I texture the final iso using an ambient 1
finish...which sounds very limiting... but I also use Rune's old ILLUSION.INC to
apply the texture (like 'texture baking' in this case), which solves the
lighting problem quite nicely. I've been meaning to post about this scheme for
quite awhile, as the results are rather extraordinary, IMHO. I hope to get
around to it soon...

[Ilya Razmanov] Re: img2mesh geometry improved [210 days 14 hours and 22 minutes ago]

Tue, 23 Sep 2025 18:03:16 GMT

On 23.09.2025 13:46, yesbird wrote:

> I guess this method will be demanded not only by POV-Ray community, may
> be I will manage myself to rewrite it on Javascript to extent Three.js
> library (asking your permission before :)
You are allowed to use it as long as you keep hailing the Toad all the 
time. Oh, and bring me all your money you silly humans.

Seriously, I don't see anything special regarding my algorithm, just 
some common sense, so surely use it at will if you find it useful.

In fact, there is a room for improvements: I use the fact that fold 
geometry is just a particular case of pyramid one, and I use it with 
"sharp" threshold-based "if" condition. Surely I may try some "smooth" 
solution, with folds gradually turning into pyramids, for example, 
linearly based on local contrast. The problem is, all this comes to "I 
like the way it looks" criterion in the end, and I still don't have 
precise mathematical definition for "look", not to mention "like".

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

[Ilya Razmanov] Re: img2mesh geometry improved [210 days 14 hours and 36 minutes ago]

Tue, 23 Sep 2025 17:48:48 GMT

On 23.09.2025 14:53, ingo wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> Greeting,
> 
> Interesting what you do with the sharp transitions.

Oh, it's all pretty simple (remember that I started it for my own use, 
and not a science project).

I was disappointed with the way POV-Ray treats bitmapped heighfield, and 
decided to try some heighfiled to mesh conversion on my own. Initial 
idea was simple: lets assume we have 2x2 pixel area of source image, 
numbering pixels according to Soviet Army "snail" rule:

1 2
4 3

those values (brightness) we name v1 - v4.

Simplest way to make triangles would be two triangles, 1-2-4 and 2-3-4, 
forming a square, folded along 2-4 diagonal. It works, but not too cool, 
so instead of 2 triangle fold I tried 4 triangle pyramid, involving 
interpolated point 0, having v0 = (v1 + v2 + v3 +v4) / 4. So four 
triangles looked like 1-2-0, 2-3-0, 3-4-0 and 4-1-0. This looked 
definitely better than POV-Ray heighfield; I also tried to compare it 
with patches and found to be similar). However I don't like artifacts 
like peaks it produces for cone gradients. But spontaneously I though 
that fold structure above is a case of pyramid structure with v0 = (v2 + 
v4) /2, so combining two geometries is only a matter of setting v0 to 
average of either two or four pixels. So I did this; decision is based 
on simple criterion:

# â†“ Switch between geometry â„–1 and
â„–3.
#   Threshold set ad hoc and is subject to change
if abs(v1 - v3) > threshold or abs(v2 - v4) > threshold:
     # â†“ Geometry â„–1, better sharp diagonals
handling
     if abs(v1 - v3) > abs(v2 - v4):
         v0 = (v2 + v4) / 2  # Fold along 2 - 4 diagonal
     else:
         v0 = (v1 + v3) / 2  # Fold along 1 - 3 diagonal
else:
     # â†“ Geometry â„–3, better for smooth areas
     v0 = (v1 + v2 + v3 + v4) / 4

Note that it includes two folding directions, 2-4 and 1-3, for / and \ 
diagonals.

So, now I have only one problem: choosing threshold. Surely I used 
common sense (I have vast supplies of common sense, "hot' lozhkoy zhuy") 
and added some experiments to it before setting defaults, but it's still 
a matter to discuss.

 > 1. First calculate the face normal

As we are talking of source image areas like 2x2 pixels, I see no sense 
in calculating normal and other wise and complicated stuff. I think I 
can make decisions regarding local source contrast based on simple 
arithmetics like difference and stuff.

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

[Bald Eagle] Re: Impossible stl file conversion! [210 days 14 hours and 50 minutes ago]

Tue, 23 Sep 2025 17:35:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> And a favorite technique of my own is to turn an object (even a mesh) into an
> object pattern, then into a function, and to use that to create an isosurface
> (although this has some limitations)-- but which can then be altered with
> interesting distortions like warp{turbulence...}, fnoise_3D, etc.-- a kind of
> shape-alteration that cannot be done any other way. Some STL models I've seen
> would be great for that.

Perhaps you could also check out

https://www.infradead.org/~wmp/macro_meshrelief.html

or touch base with Bill Pragnell about how best to use functions to distort your
meshes directly.

Once you learn how to remap space, you will have an amazing toybox at your
disposal.

- BW

[Ilya Razmanov] Re: Impossible stl file conversion! [210 days 15 hours and 7 minutes ago]

Tue, 23 Sep 2025 17:17:45 GMT

On 23.09.2025 20:06, Kenneth wrote:

> First and foremost, POV-ray is a great raytracing RENDERER. As B.E. mentioned,
> there are so MANY STL models out there, that could be beautifully rendered by us
> as-is (even if the mesh conversion retained only the un-smoothed
> flat-faceted-triangles); or as part of a CSG construction (with the addition of
> an inside vector to the converted mesh).

STL models, by their nature, must have all sides defined (which makes 
STLs exported by my img2mesh twice as big as POVs, since POVs only have 
a top side). So I guess inside vector may be any.

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

[Kenneth] Re: Impossible stl file conversion! [210 days 15 hours and 15 minutes ago]

Tue, 23 Sep 2025 17:10:00 GMT

yesbird wrote:
> On 09/09/2025 02:32, Bald Eagle wrote:
> > *** TRIGGER WARNING ***
> > ...
> I am following this discussion and asking myself: how many people will
> use this converter(s) and how many conversions will they perform ?
[snip]
>I would like to ask the community: do we really need it ?

I would answer YES, for several reasons:

First and foremost, POV-ray is a great raytracing RENDERER. As B.E. mentioned,
there are so MANY STL models out there, that could be beautifully rendered by us
as-is (even if the mesh conversion retained only the un-smoothed
flat-faceted-triangles); or as part of a CSG construction (with the addition of
an inside vector to the converted mesh).

And a favorite technique of my own is to turn an object (even a mesh) into an
object pattern, then into a function, and to use that to create an isosurface
(although this has some limitations)-- but which can then be altered with
interesting distortions like warp{turbulence...}, fnoise_3D, etc.-- a kind of
shape-alteration that cannot be done any other way. Some STL models I've seen
would be great for that.

It's probably true that the majority of available STL models are in binary form
rather than as ascii files; but Kurtz found an online binary-to-ascii conversion
process, and his mesh 'crate' result is excellent. So that's not a bottleneck.

As to whether or not there are a limited number of us who would benefit from
such a converter, I would argue that there are plenty of *existing* features in
POV-ray that have historically been used by only a few people (including me!)--
but that does not negate their importance or usefulness; they are there IF we
need them. (Personally, I still feel that I have only 'scratched the surface' of
what POV-ray is capable of, with its many features and include files, and even
with its CSG modeling capabilities.)

To be able to use and render STL models would be a great addition to all of the
other features...and might even open up POV-ray to people who might otherwise be
hesitant to learn its SDL.

[Bald Eagle] Re: img2mesh geometry improved [210 days 18 hours and 10 minutes ago]

Tue, 23 Sep 2025 14:15:00 GMT

"ingo" <nomail@nomail> wrote:

> 1. First calculate the face normal, either by cross product of three edges or
> Newell's method
>
> Newell:
>   for i in 0..<vertices.len:
>     let curr = vertices[i]
>     let next = vertices[(i + 1) mod vertices.len]
>     normal.x += (curr.y - next.y) * (curr.z + next.z)
>     normal.y += (curr.z - next.z) * (curr.x + next.x)
>     normal.z += (curr.x - next.x) * (curr.y + next.y)
>   return normalize(normal)
>
> 2. Now calulate the vertex normals, there several weighting types can be used,
> based on properties of the adjacent polygons.
>    Weighted by area, weighted by angle or just average the face normals as they
> are.

You're making me want to revisit one of my other small projects:

https://news.povray.org/web.655dee4084c692a31f9dae3025979125%40news.povray.org

Too much to do, too little time.

- BW

[yesbird] Re: Impossible stl file conversion! [210 days 20 hours and 9 minutes ago]

Tue, 23 Sep 2025 12:15:55 GMT

On 20/09/2025 16:46, yesbird wrote:
> Adding export to mesh2 and interface modification is not too
> complicated, but before starting, I would like to ask the community: do
> we really need it ?

And so, "silence is golden" :). Now I am completely sure that POV-Ray is
self-sufficient and doesn't need any external sources of geometry.

Thanks for saving my time and effort :).
-- 
YB

[ingo] Re: img2mesh geometry improved [210 days 20 hours and 30 minutes ago]

Tue, 23 Sep 2025 11:55:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,

Interesting what you do with the sharp transitions.

Other method that could work in various cases:

1. First calculate the face normal, either by cross product of three edges or
Newell's method

Newell:
  for i in 0..<vertices.len:
    let curr = vertices[i]
    let next = vertices[(i + 1) mod vertices.len]
    normal.x += (curr.y - next.y) * (curr.z + next.z)
    normal.y += (curr.z - next.z) * (curr.x + next.x)
    normal.z += (curr.x - next.x) * (curr.y + next.y)
  return normalize(normal)

2. Now calulate the vertex normals, there several weighting types can be used,
based on properties of the adjacent polygons.
   Weighted by area, weighted by angle or just average the face normals as they
are.


Regarding usefulness, always. Users do crazy things :) It may also be useful if
you provide an export as arrays, so one can (ab)use the data in SDL.

ingo

[yesbird] Re: img2mesh geometry improved [210 days 21 hours and 38 minutes ago]

Tue, 23 Sep 2025 10:46:41 GMT

On 22/09/2025 12:39, Ilya Razmanov wrote:
> 
> So, the question is: does anybody really need this img2mesh and stuff?
> 
Congratulations, this is excellent work !
I guess this method will be demanded not only by POV-Ray community, may
be I will manage myself to rewrite it on Javascript to extent Three.js
library (asking your permission before :)).

-- 
YB

[jr] Re: img2mesh geometry improved [211 days 14 hours and 40 minutes ago]

Mon, 22 Sep 2025 17:45:00 GMT

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,
> ...
> In view of recent discussion "I would like to ask the community: do
> we really need it?"
> ...
> So, the question is: does anybody really need this img2mesh and stuff?

interesting question, though not, perhaps, the correct one </grin>.  will think
about it more but "gut feeling" says yes.  not just because, in a real sense, it
is new/different, but there's also the "aspect" that as creator of XYZ you have
no control, and can have no real idea, what uses others have/will find for XYZ.

regards, jr.

[Ilya Razmanov] img2mesh geometry improved [211 days 22 hours and 45 minutes ago]

Mon, 22 Sep 2025 09:39:42 GMT

Greeting,

while fiddling with some old ideas I unintentionally managed to improve 
some aspects of my img2mesh Python image to heightfield 3D mesh converter.

You can view the results at the top of img2mesh page, updates section:

https://dnyarri.github.io/img2mesh.html

and download either Python originals or compiled Win10 exe.

In view of recent discussion "I would like to ask the community: do
we really need it?"

I mean new version uses geometry switch based on source local contrast, 
corresponding threshold control is added to program GUI but, obviously, 
it doesn't give real-time preview of final rendering. In theory, I may 
add something like ruby mask preview (like one in Photoshop) for local 
contrast to GUI, but, considering my extremely poor programming skills 
and bad memory, it would be quite time consuming. Surely, I was able to 
make a preview for filtering (you may see it at the bottom of my
POVâ€‘Ray 
Thread: Linen and Stitch at

https://dnyarri.github.io/povthread.html#averager

so I can do this, but it wasn't easy.

So, the question is: does anybody really need this img2mesh and stuff?

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

[yesbird] Re: Impossible stl file conversion! [213 days 14 hours and 18 minutes ago]

Sat, 20 Sep 2025 18:07:30 GMT

On 20/09/2025 20:38, kurtz le pirate wrote:
> 
> Just a joke : how many people will use your solution and how many 
> conversions will they generate ?
> 

Exactly, this is the reason for my doubts about writing it.

> 
> Three.js, JavaScript ... yet another new language to learn that isn't 
> designed for creating computer-generated images and which is not that 
> easy to learn.

I guess that JavaScript is one of the easiest languages to learn, at
least much more easy than Perl, for example. Yes, image generation
features are not a part of it, but they are containing in libraries.

At the same time WebGL (and now WebGPU) approach(s) gives a lot of
advantages: easy access to applications with browsers, interactivity,
using the user's GPU for rendering ... This is the reason why I switched
to Three.js from POV-Ray while still loving it.

> 
> ... and, for *me*, javascript is disable in my browser becauseÂ  here is 
> an increasing number of ways for JavaScript to be used maliciously. 
> JavaScript based attacks such as Cross Site Scripting and Click Jacking 
> rely on JavaScript and can cause the security to be compromised. There 
> are an increasing number of security minded people who do not just let 
> JavaScript run on every single page they visit to decrease the chances 
> of these attacks.
> 
> I might be paranoid, but it is only my position.
> 

No, I don't think so, but at modern state of internet huge part of the
sites can't function without JS - can't stop the progress ).

-- 
YB

[kurtz le pirate] Re: Impossible stl file conversion! [213 days 14 hours and 46 minutes ago]

Sat, 20 Sep 2025 17:38:45 GMT

On 20/09/2025 15:46, yesbird wrote:

> I am followingÂ this discussion and asking myself: how many people will
> use this converter(s) and how many conversions will they perform ? I
> have a possible general solutionÂ for conversion frommost popular modern
> formats (obj,fbx,glb,gltf,stl(a)) and can extendÂ this list on
> demand,Â but I'm not sure if it isÂ worth doing.

Just a joke : how many people will use your solution and how many 
conversions will they generate ?

> At present time I am workingÂ with Three.js, making different web
> applications (https://yesbird.online) and one of them is a viewer for
> glaze samples, made for ceramists:
> https://glazeview.yesbird.online/tc.html.

Three.js, JavaScript ... yet another new language to learn that isn't 
designed for creating computer-generated images and which is not that 
easy to learn.

... and, for *me*, javascript is disable in my browser because  here is 
an increasing number of ways for JavaScript to be used maliciously. 
JavaScript based attacks such as Cross Site Scripting and Click Jacking 
rely on JavaScript and can cause the security to be compromised. There 
are an increasing number of security minded people who do not just let 
JavaScript run on every single page they visit to decrease the chances 
of these attacks.

I might be paranoid, but it is only my position.

-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Impossible stl file conversion! [213 days 17 hours and 11 minutes ago]

Sat, 20 Sep 2025 15:13:45 GMT

On 20/09/2025 17:28, Bald Eagle wrote:
> This is probably beautiful.
> I see the pottery and glaze samples, but the rest of it doesn't seem to work
> with Brave browser.   Probably need to update my browser, but I'm using Win7
> anyway...
Try this link to test:
https://webglreport.com
The only Three.js necessary requirement is WebGL support.

> The only speculation that I have to offer is:  If you build it, they will come.
> Grab a bunch of models off of Thingaverse, export them to include files with
> inside_vector already defined, and then see if people play.
> ...
> Look at what Ton is doing.  People might not have the patience for that, but if
> a model of the part they wanted already existed...
> ...
> I can tell you that if we expanded our user base, and offered an inbuilt
> stl-to-mesh conversion, you bet people would use it!  Probably every day.
> I think we might lose a lot of the character of past hand-crafted scenes, but
> you might get people to use POV-Ray to make a scene - any scene at all - if they
> could just #include "MyPart.inc" and raytrace it within minutes.

I am in doubt also, because people already have a free Blender for
modelling which supports rendering with POV-Ray. Why not to use it
instead of leaning complicated and outdated SDL ? SDL is good for math
experiments, for example, but modelling is too painful with it.

> 
> If I learn c++ so I can unravel all of the source code for the solid/surface of
> revolution, and essentially build an SDL modeler for sor {} - will anyone use
> it?   Who uses sor {} anyway?
> 
> I have no idea.   But I'm learning.

Why not to try JS with Three.js instead ? :)
Much more easy, perspective, and highly demanded -
"Close to the Edge" of modern technology :).

> 
> Like I've pointed out in the past.   We need advertising and recruitment.
> And we need development.
> And those two things need to happen simultaneously, so they can build on each
> other.   Chicken & egg.
Ouroboros, maybe :).
> 
> I love what I've seen done with Three.js, and it would be great to get more
> updates on what you've been doing and how  :)
I am planning to concentrate on a parametric surfaces this autumn/winter
season: https://mathview.yesbird.online/
Viewer itself is ready, now it's time to extend surfaces collection.

Wish you good luck with learning and technological discoveries.
--
YB

[Bald Eagle] Re: Impossible stl file conversion! [213 days 17 hours and 55 minutes ago]

Sat, 20 Sep 2025 14:30:00 GMT

yesbird wrote:

> I am following this discussion and asking myself: how many people will
> use this converter(s) and how many conversions will they perform ? I
> have a possible general solution for conversion frommost popular modern
> formats (obj,fbx,glb,gltf,stl(a)) and can extend this list on
> demand, but I'm not sure if it is worth doing.

Well, there's the ever-present risk-vs-benefit gamble.
Just look at the history of VHS vs beta, or any other product.

People ask me all the time:
Is it worth doing ANYTHING with a 30-year old raytracer?

> At present time I am working with Three.js, making different web
> applications (https://yesbird.online) and one of them is a viewer for
> glaze samples, made for ceramists:
> https://glazeview.yesbird.online/tc.html.

This is probably beautiful.
I see the pottery and glaze samples, but the rest of it doesn't seem to work
with Brave browser.   Probably need to update my browser, but I'm using Win7
anyway...

I'll check with my Win 11 <barf> laptop, and at some point, use the linux Mint
side as well.

> Adding export to mesh2 and interface modification is not too
> complicated, but before starting, I would like to ask the community: do
> we really need it ?

The only speculation that I have to offer is:  If you build it, they will come.
Grab a bunch of models off of Thingaverse, export them to include files with
inside_vector already defined, and then see if people play.

Plenty of people in the world (still) ask, "what do I need to learn algebra
for?"

People once asked "Why would anyone use the Fourier transform?"

Look at what Ton is doing.  People might not have the patience for that, but if
a model of the part they wanted already existed...

If I learn c++ so I can unravel all of the source code for the solid/surface of
revolution, and essentially build an SDL modeler for sor {} - will anyone use
it?   Who uses sor {} anyway?

I have no idea.   But I'm learning.

I can tell you that if we expanded our user base, and offered an inbuilt
stl-to-mesh conversion, you bet people would use it!  Probably every day.
I think we might lose a lot of the character of past hand-crafted scenes, but
you might get people to use POV-Ray to make a scene - any scene at all - if they
could just #include "MyPart.inc" and raytrace it within minutes.

Like I've pointed out in the past.   We need advertising and recruitment.
And we need development.
And those two things need to happen simultaneously, so they can build on each
other.   Chicken & egg.

I love what I've seen done with Three.js, and it would be great to get more
updates on what you've been doing and how  :)

- bw

[yesbird] Re: Impossible stl file conversion! [213 days 18 hours and 39 minutes ago]

Sat, 20 Sep 2025 13:46:28 GMT

On 09/09/2025 02:32, Bald Eagle wrote:
> *** TRIGGER WARNING ***
> ...
I am followingÂ this discussion and asking myself: how many people will
use this converter(s) and how many conversions will they perform ? I
have a possible general solutionÂ for conversion frommost popular modern
formats (obj,fbx,glb,gltf,stl(a)) and can extendÂ this list on
demand,Â but I'm not sure if it isÂ worth doing.

At present time I am workingÂ with Three.js, making different web
applications (https://yesbird.online) and one of them is a viewer for
glaze samples, made for ceramists:
https://glazeview.yesbird.online/tc.html.

Adding export to mesh2 and interface modification is not too
complicated, but before starting, I would like to ask the community: do
we really need it ?
--
YB

[kurtz le pirate] Re: Impossible stl file conversion! [214 days 18 hours and 19 minutes ago]

Fri, 19 Sep 2025 14:06:11 GMT

On 18/09/2025 15:09, Kenneth wrote:
> 
> This entire discussion interests me greatly! And it finally shook me out of my
> lazy doldrums. (Real-life took over this summer-- work, plumbing problems, and
> more dental problems.) Anyway...
> 
> Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
> be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
> kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.
> 
> Kurtz's ascii-STL-to-mesh conversion-- vial a Perl script-- is an amazingly
> successful piece of code, and very elegant. The excellent mesh result speaks for
> itself. I don't know Perl, but I am *almost* convinced that a similar piece of
> code could be written directly in POV's SDL, using #read and #write, because the
> syntax used in typical STL files is so simple. The conversion code would
> probably not be as elegant as Kurtz's, but that's a small price to pay.
> 
> Speaking of simplicity, I would argue that converting to a mesh (rather than
> mesh2) would be the way to go-- as in Kurtz's result.  It's much simpler to
> implement, AND much simpler to edit afterwards, should the need arise. The mesh2
> format and syntax is more 'abstract', and the docs' example of how it works (and
> how to write it successfully) is lacking...although the necessary understanding
> can be teased-out (with help from Wikipedia :-) -- at  "triangle mesh", under
> 'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
> create from an STL file,  when using #read/#write.
> 
> Mention was made here of possibly adding 'normals' to the resulting mesh
> conversion-- which I take to mean, converting the triangles to 'smooth
> triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
> than as the original STL flat-triangle 'facets'. But that may not produce the
> intended effect for an *entire* model, as there could be smooth areas as well as
> sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
> model. (The visual smoothing effect would depend on the triangle resolution, of
> course.) The problem is that, in an STL file, there is no way to know which
> triangles should be 'smoothed' and which should not; they are all just flat
> facets.
> 
> An alternate scheme would be to slightly alter the vertex positions of all of
> the flat triangles, to produce a somewhat similar smoothing effect in the POV
> render...although I have no idea as to how that is accomplished, algorithm-wise.
> ------------
> Kurtz's posted file package here has the original STL 'crate' model from
> Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
> when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
> small section of the crate, just to see.) I have noticed this in other
> Thingaverse files as well. Apparently, no check is made of uploaded models
> there, to make sure that the models are 'robust' and completely correct.
> 



Thanks Kenneth.


I completely agree with your message and I would just like to add these 
few points :

* Bad STL source, bad mesh.
* Adding 3D formats directly to POVRay is definitely a good thing, but 
then for STL and not OBJ and not 3DS,...
* I understand, but I may be mistaken, that William F Pokorny is working 
alone to improve and develop version 4 of POV, and that this is already 
an enormous task.
* Adding support for other file formats would require even more work. Of 
course, we could consider creating specific plugins for each format, but 
POV's architecture does not allow for this. This is not a criticism, but 
in 1986 the concept of add-ons did not exist.




Regards,


-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: 3D convex hull ... of sorts [214 days 18 hours and 30 minutes ago]

Fri, 19 Sep 2025 13:55:24 GMT

On 19/09/2025 02:00, Bald Eagle wrote:
> After Kenneth's recent post, I was contemplating the structure of meshes, and
> how to mesh a raw point cloud, and my brain started connecting Voronoi with the
> gift-wrapping algorithm, and somewhere in there I thought it would be
> interesting to simply see the intersection of the prisms generated by projecting
> the points onto the 3 cardinal planes.
> 
> An even, regular distribution of a lot of random points basically gave me a cube
> with uneven edges and corners, so I cut down the number of points, and then
> anisotropically scaled the random coordinates.
> 
> I think that a lot of points randomly generated inside a more complex object
> would yield more interesting results.
> 
> As would intersecting more than 3 prisms.
> 
> But it was just playing with the proof-of-concept of the idea.
> 
> Kind of an axis-aligned bounding prism, if you will.
> 


I'm surprised you brought that up !

I've been studying this same topic since this morning, and I'm currently 
studying Leo McCormack's code on GitHub.
<https://github.com/leomccormack/convhull_3d>


LOL


-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] 3D convex hull ... of sorts [215 days 8 hours and 20 minutes ago]

Fri, 19 Sep 2025 00:05:00 GMT

After Kenneth's recent post, I was contemplating the structure of meshes, and
how to mesh a raw point cloud, and my brain started connecting Voronoi with the
gift-wrapping algorithm, and somewhere in there I thought it would be
interesting to simply see the intersection of the prisms generated by projecting
the points onto the 3 cardinal planes.

An even, regular distribution of a lot of random points basically gave me a cube
with uneven edges and corners, so I cut down the number of points, and then
anisotropically scaled the random coordinates.

I think that a lot of points randomly generated inside a more complex object
would yield more interesting results.

As would intersecting more than 3 prisms.

But it was just playing with the proof-of-concept of the idea.

Kind of an axis-aligned bounding prism, if you will.

Enjoy.

- BE

[Bald Eagle] Re: Impossible stl file conversion! [215 days 18 hours and 35 minutes ago]

Thu, 18 Sep 2025 13:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
> be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
> kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.

That said, if someone could provide a road map for what we need to do to write a
PATCH, then it could simply be added by unzipping a folder of the required
files, and ADDING the feature to the existing 3.7/3.8

>I don't know Perl, but I am *almost* convinced that a similar piece of
> code could be written directly in POV's SDL, using #read and #write, because the
> syntax used in typical STL files is so simple. The conversion code would
> probably not be as elegant as Kurtz's, but that's a small price to pay.

SDL sucks for this kind of thing, mostly because we don't have any way to read a
piece of data from a random file, determine what data type it is, and then run
conditional code.
All strings need to be quoted, we need commas, etc.
So, some sort of pre-processing script would need to be run first.
And if you're going to do that, why do it in SDL at all?  Just do it in the
preprocessing language.

> Speaking of simplicity, I would argue that converting to a mesh (rather than
> mesh2) would be the way to go-- as in Kurtz's result.  It's much simpler to
> implement, AND much simpler to edit afterwards, should the need arise. The mesh2
> format and syntax is more 'abstract', and the docs' example of how it works (and
> how to write it successfully) is lacking...although the necessary understanding
> can be teased-out (with help from Wikipedia :-) -- at  "triangle mesh", under
> 'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
> create from an STL file,  when using #read/#write.

I have written both from scratch, and might have some code to assemble each
primitive from a collection of triangles kicking around somewhere.
It's basically a problem of connectivity.  One can take the raw triangle data
and search for common vertices to see what triangles share edges, and build up
the data structure that way.

I'd favor conversion to a mesh, with the option of taking the resulting mesh and
making a mesh2 as an optional function to invoke separately.

Also no reason we couldn't just distribute such scripts in some sort of utility
directory with the distro.

> Mention was made here of possibly adding 'normals' to the resulting mesh
> conversion-- which I take to mean, converting the triangles to 'smooth
> triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
> than as the original STL flat-triangle 'facets'. But that may not produce the
> intended effect for an *entire* model, as there could be smooth areas as well as
> sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
> model. (The visual smoothing effect would depend on the triangle resolution, of
> course.) The problem is that, in an STL file, there is no way to know which
> triangles should be 'smoothed' and which should not; they are all just flat
> facets.

Very true, thus the continuing need for a modeler.

> An alternate scheme would be to slightly alter the vertex positions of all of
> the flat triangles, to produce a somewhat similar smoothing effect in the POV
> render...although I have no idea as to how that is accomplished, algorithm-wise.

Subdivision.  Plus some interpolation code for the new vertices to follow the
smoothed edge.

> Kurtz's posted file package here has the original STL 'crate' model from
> Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
> when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
> small section of the crate, just to see.) I have noticed this in other
> Thingaverse files as well. Apparently, no check is made of uploaded models
> there, to make sure that the models are 'robust' and completely correct.

Determining the correct normal direction for any given triangle can certainly be
challenging.  It's probably the most difficult part of writing a modeling
software. I'd say you could probably run a check of all the neighboring
triangles and if all of the neighbors are within some given angular range of
each other, but the triangle you're checking is 180-range, then flip it.

Lots of articles and algorithms on the web covering this topic.

- bw

[Kenneth] Re: Impossible stl file conversion! [215 days 19 hours and 15 minutes ago]

Thu, 18 Sep 2025 13:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> another installment in the long-running desire to have native stl support
> for POV-Ray.  There was some insistence that .stl is a binary-only format, or
> that it would be difficult to adapt our mesh {} code to handle stl.
>
> So the point is that if the SDL and stl are virtually identical, then it ought
> to be fairly simple to add the ability _in source_ to #include "MyModel.stl"
>

This entire discussion interests me greatly! And it finally shook me out of my
lazy doldrums. (Real-life took over this summer-- work, plumbing problems, and
more dental problems.) Anyway...

Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.

Kurtz's ascii-STL-to-mesh conversion-- vial a Perl script-- is an amazingly
successful piece of code, and very elegant. The excellent mesh result speaks for
itself. I don't know Perl, but I am *almost* convinced that a similar piece of
code could be written directly in POV's SDL, using #read and #write, because the
syntax used in typical STL files is so simple. The conversion code would
probably not be as elegant as Kurtz's, but that's a small price to pay.

Speaking of simplicity, I would argue that converting to a mesh (rather than
mesh2) would be the way to go-- as in Kurtz's result.  It's much simpler to
implement, AND much simpler to edit afterwards, should the need arise. The mesh2
format and syntax is more 'abstract', and the docs' example of how it works (and
how to write it successfully) is lacking...although the necessary understanding
can be teased-out (with help from Wikipedia :-) -- at  "triangle mesh", under
'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
create from an STL file,  when using #read/#write.

Mention was made here of possibly adding 'normals' to the resulting mesh
conversion-- which I take to mean, converting the triangles to 'smooth
triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
than as the original STL flat-triangle 'facets'. But that may not produce the
intended effect for an *entire* model, as there could be smooth areas as well as
sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
model. (The visual smoothing effect would depend on the triangle resolution, of
course.) The problem is that, in an STL file, there is no way to know which
triangles should be 'smoothed' and which should not; they are all just flat
facets.

An alternate scheme would be to slightly alter the vertex positions of all of
the flat triangles, to produce a somewhat similar smoothing effect in the POV
render...although I have no idea as to how that is accomplished, algorithm-wise.
------------
Kurtz's posted file package here has the original STL 'crate' model from
Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
small section of the crate, just to see.) I have noticed this in other
Thingaverse files as well. Apparently, no check is made of uploaded models
there, to make sure that the models are 'robust' and completely correct.

[jr] Re: Impossible stl file conversion! [216 days 23 hours and 5 minutes ago]

Wed, 17 Sep 2025 09:20:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> ...
> I gather that you speak Perl too ?
> I feel less lonely...

</grin>  sorry to disappoint, but Tcl is my "vice".  but you are certainly not
alone and can take consolation :-) from the fact that a certain s/ware developer
in Australia too favours Perl.  (and cannot understand my .. ignorance :-))

regards, jr.

[kurtz le pirate] Re: Impossible stl file conversion! [217 days 23 hours and 14 minutes ago]

Tue, 16 Sep 2025 09:11:28 GMT

On 15/09/2025 16:32, jr wrote:

>> ...
> 
> thanks, it helped me to find a bug; two, if I count your code </grin>.
> 

Glad to be of help.
I gather that you speak Perl too ?
I feel less lonely...





-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Impossible stl file conversion! [218 days 17 hours and 50 minutes ago]

Mon, 15 Sep 2025 14:35:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> On 10/09/2025 17:11, kurtz le pirate wrote:
> > The wiki page shows that the structure is very simple, and I think Perl*
> > is a very good candidate for this.
>
> Finally, I spent an hour and here is my first result ;)
> ...

thanks, it helped me to find a bug; two, if I count your code </grin>.

according to the Wikipedia page, "An ASCII STL file begins with the line:
solid name
where name is an optional string (though if name is omitted there must still be
a space after solid, for compatibility with some software).

<en.wikipedia.org/wiki/STL_(file_format)>

my code got tripped up by the missing space in the data.

regards, jr.

[kurtz le pirate] Re: Is Trevor G Quayle still around? [218 days 23 hours and 59 minutes ago]

Mon, 15 Sep 2025 08:26:14 GMT

On 15/09/2025 03:55, Cousin Ricky wrote:
> So far as I can determine, he was the one who adapted CGSphere for
> POV-Ray.  I made some modifications to those files that I'd like to
> share, but the files do not have a license attached, and I don't know
> that I have the legal right to share them.

I looked in the CGSphere zip file from 2006. No license file, no 
reference to TGQ. Just a readme file that you must have too.

He has a page on DeviantArt 
(<https://www.deviantart.com/barberofcivil>), but I couldn't find a way 
to contact him directly.

Only send him a note if you have a DeviantArt account...

-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Is Trevor G Quayle still around? [219 days 6 hours and 30 minutes ago]

Mon, 15 Sep 2025 01:55:40 GMT

So far as I can determine, he was the one who adapted CGSphere for
POV-Ray.  I made some modifications to those files that I'd like to
share, but the files do not have a license attached, and I don't know
that I have the legal right to share them.

[ingo] Re: Impossible stl file conversion! [221 days 14 hours and 15 minutes ago]

Fri, 12 Sep 2025 18:10:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
>
>
> I don't know Nim very well, but the code is interesting.
> Even Yoda agrees ;)


Hahaha. Well, for Yoda then, one that reads binary stl, rather untested again,

---%<------%<------%<------%<---
import std/[streams,math, sequtils, strformat]

type
  Vec3 = array[3, float]
  Face = array[3, int]

proc vec3(x,y,z: float): Vec3 = [x,y,z]
proc `+`(a,b: Vec3): Vec3 = [a[0]+b[0], a[1]+b[1], a[2]+b[2]]
proc `/`(a: Vec3, s: float): Vec3 = [a[0]/s, a[1]/s, a[2]/s]
proc dot(a,b: Vec3): float = a[0]*b[0]+a[1]*b[1]+a[2]*b[2]
proc length(v: Vec3): float = sqrt(dot(v,v))
proc normalize(v: Vec3): Vec3 =
  let l = length(v)
  if l > 1e-9: v / l else: vec3(0,1,0)

proc readVec3(s: Stream): Vec3 =
  result[0] = s.readFloat32()
  result[1] = s.readFloat32()
  result[2] = s.readFloat32()

proc loadBinarySTL(path: string): (seq[Vec3], seq[Face], seq[Vec3]) =
  ## Parse binary STL, returning vertices, faces, and per-face normals
  var f = newFileStream(path, fmRead)
  defer: f.close()
  discard f.readStr(80)           # skip header
  let triCount = f.readUint32()

  var verts: seq[Vec3] = @[]
  var faces: seq[Face] = @[]
  var faceNorms: seq[Vec3] = @[]

  for i in 0..<int(triCount):
    let n = readVec3(f)           # face normal
    let v1 = readVec3(f)
    let v2 = readVec3(f)
    let v3 = readVec3(f)
    discard f.readUint16()        # attribute byte count

    let base = verts.len
    verts.add(v1)
    verts.add(v2)
    verts.add(v3)
    faces.add([base, base+1, base+2])
    faceNorms.add(normalize(n))

  return (verts, faces, faceNorms)

# adjecent vertises
proc vertexToFaces(faces: seq[Face], vertexCount: int): seq[seq[int]] =
  result = newSeqWith(vertexCount, newSeq[int]())
  for fi, f in faces:
    for vi in f:
      result[vi].add(fi)

# Vertex normals by averaging face normals
proc computeVertexNormals(vertexCount: int, faceNormals: seq[Vec3], v2f:
seq[seq[int]]): seq[Vec3] =
  result = newSeqWith(vertexCount, vec3(0,0,0))
  for vi in 0..<vertexCount:
    var accum = vec3(0,0,0)
    for fi in v2f[vi]:
      accum = accum + faceNormals[fi]
    result[vi] = normalize(accum)

proc mesh2ToString(verts: seq[Vec3], faces: seq[Face], normals: seq[Vec3]):
string =
  var sb = newStringOfCap(verts.len * 100)
  sb.add("mesh2 {\n")
  sb.add("  vertex_vectors {\n")
  sb.add("    " & $verts.len & ",\n")
  for v in verts: sb.add(&"    <{v[0]}, {v[1]}, {v[2]}>,\n")
  sb.add("  }\n")
  sb.add("  normal_vectors {\n")
  sb.add("    " & $normals.len & ",\n")
  for n in normals: sb.add(&"    <{n[0]}, {n[1]}, {n[2]}>,\n")
  sb.add("  }\n")
  sb.add("  face_indices {\n")
  sb.add("    " & $faces.len & ",\n")
  for f in faces: sb.add(&"    <{f[0]}, {f[1]}, {f[2]}>,\n")
  sb.add("  }\n")
  sb.add("}\n")
  result = sb

proc writeMesh2(path: string, verts: seq[Vec3], faces: seq[Face], normals:
seq[Vec3]) =
  writeFile(path, mesh2ToString(verts, faces, normals))

when isMainModule:
  let (verts, faces, faceNorms) = loadBinarySTL("model.stl")
  let v2f = vertexToFaces(faces, verts.len)
  let vertexNorms = computeVertexNormals(verts.len, faceNorms, v2f)
  writeMesh2("model.inc", verts, faces, vertexNorms)
  echo "Binary STL converted to POV-Ray mesh2."

---%<------%<------%<------%<---

They realy should have/get a decent command line interface...

ingo

[kurtz le pirate] Re: Impossible stl file conversion! [221 days 15 hours and 18 minutes ago]

Fri, 12 Sep 2025 17:07:20 GMT

On 11/09/2025 20:26, ingo wrote:
> A quicky in Nim, not much tested:
> 
> ---%<------%<------%<------%<---
> 
> [snip]
> 
> ---%<------%<------%<------%<---
> 
> ingo


I don't know Nim very well, but the code is interesting.
Even Yoda agrees ;)





-- 
kurtz le pirate
compagnie de la banquise

[ingo] Re: Impossible stl file conversion! [222 days 13 hours and 55 minutes ago]

Thu, 11 Sep 2025 18:30:00 GMT

A quicky in Nim, not much tested:

---%<------%<------%<------%<---

#asciistl2pov.nim

import std/[math, sequtils, strformat, strutils]

type
  Vec3 = array[3, float]
  Face = array[3, int]

proc vec3(x,y,z: float): Vec3 = [x,y,z]

proc `+`(a,b: Vec3): Vec3 = [a[0]+b[0], a[1]+b[1], a[2]+b[2]]

proc `/`(a: Vec3, s: float): Vec3 = [a[0]/s, a[1]/s, a[2]/s]

proc dot(a,b: Vec3): float = a[0]*b[0]+a[1]*b[1]+a[2]*b[2]

proc length(v: Vec3): float = sqrt(dot(v,v))

proc normalize(v: Vec3): Vec3 =
  let l = length(v)
  if l > 1e-9: v / l else: vec3(0,1,0)


# Load STL, ASCII only
proc loadSTL(path: string): (seq[Vec3], seq[Face], seq[Vec3]) =
  var verts: seq[Vec3] = @[]
  var faces: seq[Face] = @[]
  var norms: seq[Vec3] = @[]
  var curVerts: seq[int] = @[]
  var curNormal = vec3(0,0,0)
  for line in lines(path):
    let l = line.strip()
    if l.startsWith("facet normal"):
      let p = l.splitWhitespace()
      curNormal = vec3(p[2].parseFloat, p[3].parseFloat, p[4].parseFloat)
    elif l.startsWith("vertex"):
      let p = l.splitWhitespace()
      let v = vec3(p[1].parseFloat, p[2].parseFloat, p[3].parseFloat)
      verts.add(v)
      curVerts.add(verts.len-1)
    elif l.startsWith("endfacet"):
      if curVerts.len == 3:
        faces.add([curVerts[0], curVerts[1], curVerts[2]])
        norms.add(curNormal)
      curVerts.setLen(0)
  return (verts, faces, norms)


proc vertexToFaces(faces: seq[Face], vertexCount: int): seq[seq[int]] =
  result = newSeqWith(vertexCount, newSeq[int]())
  for fIdx, f in faces:
    for vi in f:
      result[vi].add(fIdx)


proc computeVertexNormals(
  vertexCount: int, faceNormals: seq[Vec3], v2f: seq[seq[int]]
): seq[Vec3] =
  result = newSeqWith(vertexCount, vec3(0,0,0))
  for vIdx in 0..<vertexCount:
    var accum = vec3(0,0,0)
    for fIdx in v2f[vIdx]:
      accum = accum + faceNormals[fIdx]
    result[vIdx] = normalize(accum)


proc mesh2ToString(
  verts: seq[Vec3], faces: seq[Face], normals: seq[Vec3]
): string =
  var sb = newStringOfCap(verts.len * 100) # Preallocate rough size
  sb.add("#declare MSH = mesh2 {\n")

  # Vertex vectors
  sb.add("  vertex_vectors {\n")
  sb.add("    " & $verts.len & ",\n")
  for v in verts:
    sb.add(&"    <{v[0]}, {v[1]}, {v[2]}>,\n")
  sb.add("  }\n")

  # Normal vectors
  sb.add("  normal_vectors {\n")
  sb.add("    " & $normals.len & ",\n")
  for n in normals:
    sb.add(&"    <{n[0]}, {n[1]}, {n[2]}>,\n")
  sb.add("  }\n")

  # Face indices
  sb.add("  face_indices {\n")
  sb.add("    " & $faces.len & ",\n")
  for f in faces:
    sb.add(&"    <{f[0]}, {f[1]}, {f[2]}>,\n")
  sb.add("  }\n")

  sb.add("}\n")
  result = sb


proc writeMesh2(outPath: string, verts: seq[Vec3], faces: seq[Face], normals:
seq[Vec3]) =
  let s = mesh2ToString(verts, faces, normals)
  writeFile(outPath, s)


when isMainModule:
  let (verts, faces, faceNorms) = loadSTL("mesh_output.stl")
  let v2f = vertexToFaces(faces, verts.len)
  let vertexNorms = computeVertexNormals(verts.len, faceNorms, v2f)
  writeMesh2("model.inc", verts, faces, vertexNorms)
  echo "Converted STL to POV-Ray mesh2 with normals."

---%<------%<------%<------%<---

ingo

[kurtz le pirate] Re: Impossible stl file conversion! [222 days 15 hours and 30 minutes ago]

Thu, 11 Sep 2025 16:55:20 GMT

On 11/09/2025 16:51, kurtz le pirate wrote:
> 
> Of course, there are quite a few things to add such as binary format, 
> normals & mesh2{}, colors, etc.
> 

Three more attempts always from Thingiverse.
The lack of normals is clearly visible :(







-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Impossible stl file conversion! [222 days 17 hours and 34 minutes ago]

Thu, 11 Sep 2025 14:51:10 GMT

On 10/09/2025 17:11, kurtz le pirate wrote:
> 
> The wiki page shows that the structure is very simple, and I think Perl* 
> is a very good candidate for this.
> 

Finally, I spent an hour and here is my first result ;)

I found this template on the web : 
<https://www.thingiverse.com/thing:7119375>. The downloaded STL file is 
in binary mode. I converted it to ASCII on this website : 
<https://3dcustomizer.net/tests/stl-bin-to-ascii.html>

Here is the first image to compare with the one on Thingiverse.

I also added an archive that contains :

* Stackable_crate_gridfinity-ascii.stl : the ascii stl file

* stl2pov.pl : the perl script

* Stackable_crate_gridfinity-ascii.inc : the mesh{}Â include file
   generated by the script

* test.pov : demo scene

* test.png : the image

Of course, there are quite a few things to add such as binary format, 
normals & mesh2{}, colors, etc.

-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Impossible stl file conversion! [222 days 22 hours and 5 minutes ago]

Thu, 11 Sep 2025 10:20:18 GMT

On 09/09/2025 02:32, Bald Eagle wrote:
>                   ........... what's that?!!!
> 
> He provides not one but TWO .stl files . . .
> 

Blender can import STL and export POV.
-- 
YB

[ingo] Re: Impossible stl file conversion! [223 days and 20 minutes ago]

Thu, 11 Sep 2025 08:05:00 GMT

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

> #declare MyObject = mesh2 {stl "MyObject.stl" make_arrays ...}

#declare MyStlObject = mesh2{stl "MyObject.stl"}
#declare MyObjObject = mesh2{obj "MyObject.obj"}

that's quite elegant, to extract from a file format, what POV-Ray understands
based on mesh2.

I'd separate extracting array into something like:

mesh2array(mySTLObject, verticesname, normalsname, facesname, uvname,
vertexcoulours etc..)

could result in a bunch of arrays declared with the given names. It should take
mesh & mesh2.

and/or

mesharrays{obj "MyObjObject.obj"} and extract everything the file supports into
arrays, even what's not understood by mesh2, like boning, face normals or non
triangle faces.


ingo

[Bald Eagle] Re: Impossible stl file conversion! [223 days 15 hours and 30 minutes ago]

Wed, 10 Sep 2025 16:55:00 GMT

"ingo" <nomail@nomail> wrote:

> for the current POV-Ray situation, I'm mostly writing my own little tools "that
> do things" and then call POV-Ray on the generated scene. The opposite of POV-Ray
> should be able to do it "all". Although I would like the latter,
>
> ingo

Well, given "the current POV-Ray situation", I'm trying to break out of that,
since "what is tolerated is what will continue".
I suppose I have a Persistence of Vision.  ;)

I'm not exclusionarily averse to things like macros and separate utilities,
however, it would be highly desireable to in some way integrate those things
into the POV-Ray "package".

An official repository on the website, a folder in the official distro, scripts
to run whatever conversion or creation needs to be done, or most preferable -
the inclusion of an additional module in the source.

I'm especially pushing for this stl module, since it appears so straightforward
a task (for a c++ programmer), and the availability of millions of free stl
files available.  We don't have a modeler - but there are models.

And it there are modelers available to make/edit stls.....

- BW

[ingo] Re: Impossible stl file conversion! [223 days 17 hours ago]

Wed, 10 Sep 2025 15:25:00 GMT

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

> I mean, yeah - I just hate all the extra steps, and the generation of a whole
> new file that takes up space next to the original stl.

for the current POV-Ray situation, I'm mostly writing my own little tools "that
do things" and then call POV-Ray on the generated scene. The opposite of POV-Ray
should be able to do it "all". Although I would like the latter,

ingo

[kurtz le pirate] Re: Impossible stl file conversion! [223 days 17 hours and 14 minutes ago]

Wed, 10 Sep 2025 15:11:36 GMT

On 10/09/2025 16:23, ingo wrote:

> 
> A conversion script in a scripting lang is the way out.
> 


I agree with you.


The wiki page shows that the structure is very simple, and I think Perl* 
is a very good candidate for this.




* : (from WIKIPEDIA) Perl was developed by Larry Wall in 1987 and STL 
was invented by the Albert Consulting Group for 3D Systems in 1987 too LOL



-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Impossible stl file conversion! [223 days 17 hours and 25 minutes ago]

Wed, 10 Sep 2025 15:00:00 GMT

"ingo" <nomail@nomail> wrote:

Yeah, sorry, I'm kinda thinking one thing and typing another.
I'm using too many systems at once and hopping between them all in rapid
succession.

> An annoyance of STL is that the number of faces is not given beforehand. Makes
> declaring arrays hard or one has to do a two pass run and count faces.

But we no longer have to declare the size of an array in SDL when constructing
one, unless it's a multidimensional array.

And I'm really talking about somehow doing this in the same way that we use
image_maps.  So we'd be doing this under the hood in c++.

So the thought process is actually more that what we feed the parser through SDL
when we make a mesh {} is nearly identical to the data structure of the ASCII
stl.  And so therefor it ought to be easy to bypass converting to SDL and just
read the triangle vertices in directly from the stl file.

So, I guess it would actually be

#declare MyObject = stl {"MyObject.stl"}

Now, whether or not we create a new keyword, or spruce up the mesh {} keyword to
allow something like  #declare MyObject = mesh {stl "MyObject.stl"} is something
that would be a decision for someone with more development experience than I.

Another idea is to code the conversion script into source - because it would be
nice to convert stl to mesh and save it as a file.  And convert both mesh {} and
stl to mesh2 {}.  And to have an array automatically populated with the triangle
vertices if desired.
(I'd also like to see a similar mechanism to populate an array with rgb data
from an image map and other related finction & pigment data)

So, I can envision both:
#declare MyObject = mesh {stl "MyObject.stl" make_array MyArray}
and
#declare MyObject = mesh2 {stl "MyObject.stl" make_arrays ...}
where there would some mechanism to specify what arrays for vertices, faces, and
normals would exist.

> A conversion script in a scripting lang is the way out.

I mean, yeah - I just hate all the extra steps, and the generation of a whole
new file that takes up space next to the original stl.

#read could probably use some fixing, and we all are intimately familiar with
the long-standing need to have some sort of data-typing mechanism.

- BW

[ingo] Re: Impossible stl file conversion! [223 days 18 hours ago]

Wed, 10 Sep 2025 14:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
>
> .....
>
> Yes, yes.  That's oranges to my apples.
>

Ah, misunderstood. No, the #read directive expects quoted strings, not just text
and thus fails straight away on the stl 'keywords'.

An annoyance of STL is that the number of faces is not given beforehand. Makes
declaring arrays hard or one has to do a two pass run and count faces.

A conversion script in a scripting lang is the way out.

ingo

[Bald Eagle] Re: Impossible stl file conversion! [223 days 19 hours and 20 minutes ago]

Wed, 10 Sep 2025 13:05:00 GMT

"ingo" <nomail@nomail> wrote:

.....

Yes, yes.  That's oranges to my apples.

Download an stl file from thingaverse and show me every step of the workflow to
render that in POV-Ray.

Aint nobody got time for that.


#include "MyObject.stl"
object {MyObject pigment {rgb z}}

Even a newbie can do that and get good results.

- BE

[ingo] Re: Impossible stl file conversion! [223 days 19 hours and 50 minutes ago]

Wed, 10 Sep 2025 12:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> > I'm sorry but I don't get the joke (well, it's only 6:26 here and I'm
> > still waiting for my coffee to extract).
>
> It's now 6:24 here, and I'm in the exact same situation.  :D
>
> > So?
>
> It's another installment in the long-running desire to have native stl support
> for POV-Ray.  There was some insistence that .stl is a binary-only format, or
> that it would be difficult to adapt our mesh {} code to handle stl.
>
> https://news.povray.org/web.65818958d9619d9a1f9dae3025979125%40news.povray.org
>
> So the point is that if the SDL and stl are virtually identical, then it ought
> to be fairly simple to add the ability _in source_ to #include "MyModel.stl"
>
> - BE

#declare VertexVec = array[100] {
    <8,0,0> <9.44122,11.8709,0> <2.70223,19.3541,0>
    <-8.09808,18.1865,0> <-13.0913,7.48319,0> <-9.58918,-5.47232,0>
    <-5.40192,-13.8564,0> <-3.63688,-15.7569,0> <-0.826068,-10.2846,0>
    <4,-3.91887e-15,0> <7.53209,0,1.28558> <8.99892,11.4998,1.58634>
    <2.55384,18.5125,2.34791> <-7.51319,17.1735,3.21394>
<-11.7988,7.01274,3.7792>
    <-8.21366,-5.47232,3.7792> <-4.23215,-13.8564,3.21394>
<-2.7823,-15.7569,2.34791>
    <-0.248686,-10.2846,1.58634> <4.46791,-3.91887e-15,1.28558>
<6.3473,0,1.96962>
    <7.87898,10.5601,2.43042> <2.17809,16.3816,3.59721>
<-6.0322,14.6083,4.92404>
    <-8.52589,5.82151,5.79006> <-4.73074,-5.47232,5.79006>
<-1.27016,-13.8564,4.92404>
    <-0.618457,-15.7569,3.59721> <1.2133,-10.2846,2.43042>
<5.6527,-3.91887e-15,1.96962>
    <5,0,1.73205> <6.60543,9.49143,2.13727> <1.75081,13.9583,3.16333>
    <-4.34808,11.6913,4.33013> <-4.80411,4.46689,5.0917>
<-0.7701,-5.47232,5.0917>
    <2.09808,-13.8564,4.33013> <1.84218,-15.7569,3.16333>
<2.8758,-10.2846,2.13727>
    <7,-3.91887e-15,1.73205> <4.12061,0,0.68404> <5.77417,8.79393,0.844075>
    <1.47192,12.3767,1.2493> <-3.24884,9.78742,1.7101>
<-2.37489,3.58272,2.01087>
    <1.81502,-5.47232,2.01087> <4.29654,-13.8564,1.7101>
<3.44825,-15.7569,1.2493>
    <3.96092,-10.2846,0.844075> <7.87939,-3.91887e-15,0.68404>
<4.12061,0,-0.68404>
    <5.77417,8.79393,-0.844075> <1.47192,12.3767,-1.2493>
<-3.24884,9.78742,-1.7101>
    <-2.37489,3.58272,-2.01087> <1.81502,-5.47232,-2.01087>
<4.29654,-13.8564,-1.7101>
    <3.44825,-15.7569,-1.2493> <3.96092,-10.2846,-0.844075>
<7.87939,-3.91887e-15,-0.68404>
    <5,0,-1.73205> <6.60543,9.49143,-2.13727> <1.75081,13.9583,-3.16333>
    <-4.34808,11.6913,-4.33013> <-4.80411,4.46689,-5.0917>
<-0.7701,-5.47232,-5.0917>
    <2.09808,-13.8564,-4.33013> <1.84218,-15.7569,-3.16333>
<2.8758,-10.2846,-2.13727>
    <7,-3.91887e-15,-1.73205> <6.3473,0,-1.96962> <7.87898,10.5601,-2.43042>
    <2.17809,16.3816,-3.59721> <-6.0322,14.6083,-4.92404>
<-8.52589,5.82151,-5.79006>
    <-4.73074,-5.47232,-5.79006> <-1.27016,-13.8564,-4.92404>
<-0.618457,-15.7569,-3.59721>
    <1.2133,-10.2846,-2.43042> <5.6527,-3.91887e-15,-1.96962>
<7.53209,0,-1.28558>
    <8.99892,11.4998,-1.58634> <2.55384,18.5125,-2.34791>
<-7.51319,17.1735,-3.21394>
    <-11.7988,7.01274,-3.7792> <-8.21366,-5.47232,-3.7792>
<-4.23215,-13.8564,-3.21394>
    <-2.7823,-15.7569,-2.34791> <-0.248686,-10.2846,-1.58634>
<4.46791,-3.91887e-15,-1.28558>
    <8,0,-4.89859e-16> <9.44122,11.8709,-6.04464e-16>
<2.70223,19.3541,-8.94654e-16>
    <-8.09808,18.1865,-1.22465e-15> <-13.0913,7.48319,-1.44003e-15>
<-9.58918,-5.47232,-1.44003e-15>
    <-5.40192,-13.8564,-1.22465e-15> <-3.63688,-15.7569,-8.94654e-16>
<-0.826068,-10.2846,-6.04464e-16>
    <4,-3.91887e-15,-4.89859e-16>
  }

#declare NormalVec = array[100] {
    <0.970398,-0.241511,0> <0.964518,0.264016,0> <0.338788,0.940863,0>
    <-0.600834,0.799374,0> <-0.99802,0.0629003,0> <-0.940787,-0.338999,0>
    <-0.865497,-0.500914,-1.16282e-16> <0.615314,-0.788282,6.5167e-17>
<0.899878,-0.436142,5.59569e-17>
    <0.961129,-0.2761,0> <0.751627,-0.193101,0.63069>
<0.782153,0.176031,0.597703>
    <0.306739,0.711273,0.632456> <-0.439771,0.628692,0.641364>
<-0.779063,0.0397155,0.625686>
    <-0.734709,-0.283085,0.616494> <-0.686809,-0.44291,0.576301>
<0.50335,-0.753823,-0.422361>
    <0.712277,-0.368035,-0.597672> <0.748144,-0.214917,-0.627767>
<0.173444,-0.0485249,0.983648>
    <0.250024,-0.0325129,0.967694> <0.212934,0.135699,0.967597>
<0.00249393,0.200893,0.97961>
    <-0.173347,0.0312182,0.984366> <-0.172656,-0.106756,0.97918>
<-0.167243,-0.269104,0.948479>
    <0.13505,-0.628609,-0.765906> <0.171168,-0.168396,-0.970744>
<0.173433,-0.0498214,-0.983585>
    <-0.494052,0.153785,0.855723> <-0.477882,-0.198973,0.855592>
<0.0681164,-0.513488,0.855389>
    <0.552115,-0.217784,0.804822> <0.557043,0.152347,0.816391>
<0.494296,0.150612,0.856147>
    <0.499687,-0.035358,0.865484> <-0.460527,-0.389434,-0.797657>
<-0.498203,0.0846973,-0.862914>
    <-0.494921,0.142174,-0.857228> <-0.896097,0.301054,0.326153>
<-0.927261,-0.21252,0.308257>
    <-0.0705502,-0.937584,0.340527> <0.888954,-0.364892,0.276793>
<0.911329,0.307808,0.273375>
    <0.885942,0.33336,0.322456> <0.932562,0.122959,0.339425>
<-0.926214,-0.168767,-0.337114>
    <-0.911208,0.244351,-0.331652> <-0.90722,0.260614,-0.330201>
<-0.896097,0.301054,-0.326153>
    <-0.927261,-0.21252,-0.308257> <-0.0705502,-0.937584,-0.340527>
<0.888954,-0.364892,-0.276793>
    <0.911329,0.307808,-0.273375> <0.885942,0.33336,-0.322456>
<0.932562,0.122959,-0.339425>
    <-0.926214,-0.168767,0.337114> <-0.911208,0.244351,0.331652>
<-0.90722,0.260614,0.330201>
    <-0.494052,0.153785,-0.855723> <-0.477882,-0.198973,-0.855592>
<0.0681164,-0.513488,-0.855389>
    <0.552115,-0.217784,-0.804822> <0.557043,0.152347,-0.816391>
<0.494296,0.150612,-0.856147>
    <0.499687,-0.035358,-0.865484> <-0.460527,-0.389434,0.797657>
<-0.498203,0.0846973,0.862914>
    <-0.494921,0.142174,0.857228> <0.173444,-0.0485249,-0.983648>
<0.250024,-0.0325129,-0.967694>
    <0.212934,0.135699,-0.967597> <0.00249393,0.200893,-0.97961>
<-0.173347,0.0312182,-0.984366>
    <-0.172656,-0.106756,-0.97918> <-0.167243,-0.269104,-0.948479>
<0.13505,-0.628609,0.765906>
    <0.171168,-0.168396,0.970744> <0.173433,-0.0498214,0.983585>
<0.751627,-0.193101,-0.63069>
    <0.782153,0.176031,-0.597703> <0.306739,0.711273,-0.632456>
<-0.439771,0.628692,-0.641364>
    <-0.779063,0.0397155,-0.625686> <-0.734709,-0.283085,-0.616494>
<-0.686809,-0.44291,-0.576301>
    <0.50335,-0.753823,0.422361> <0.712277,-0.368035,0.597672>
<0.748144,-0.214917,0.627767>
    <0.970398,-0.241511,0> <0.964518,0.264016,-6.83606e-16>
<0.338788,0.940863,0>
    <-0.600834,0.799374,-9.79107e-17> <-0.99802,0.0629003,-2.37935e-16>
<-0.940787,-0.338999,-4.55888e-16>
    <-0.865497,-0.500914,-2.55819e-16> <0.615314,-0.788282,2.3623e-16>
<0.899878,-0.436142,2.47809e-16>
    <0.961129,-0.2761,3.22825e-16>
  }

#declare FacesIndices = array[162]{
    <0,1,11> <10,0,11> <1,2,12> <11,1,12> <2,3,13> <12,2,13>
    <3,4,14> <13,3,14> <4,5,15> <14,4,15> <5,6,16> <15,5,16>
    <6,7,17> <16,6,17> <7,8,18> <17,7,18> <8,9,19> <18,8,19>
    <10,11,21> <20,10,21> <11,12,22> <21,11,22> <12,13,23> <22,12,23>
    <13,14,24> <23,13,24> <14,15,25> <24,14,25> <15,16,26> <25,15,26>
    <16,17,27> <26,16,27> <17,18,28> <27,17,28> <18,19,29> <28,18,29>
    <20,21,31> <30,20,31> <21,22,32> <31,21,32> <22,23,33> <32,22,33>
    <23,24,34> <33,23,34> <24,25,35> <34,24,35> <25,26,36> <35,25,36>
    <26,27,37> <36,26,37> <27,28,38> <37,27,38> <28,29,39> <38,28,39>
    <30,31,41> <40,30,41> <31,32,42> <41,31,42> <32,33,43> <42,32,43>
    <33,34,44> <43,33,44> <34,35,45> <44,34,45> <35,36,46> <45,35,46>
    <36,37,47> <46,36,47> <37,38,48> <47,37,48> <38,39,49> <48,38,49>
    <40,41,51> <50,40,51> <41,42,52> <51,41,52> <42,43,53> <52,42,53>
    <43,44,54> <53,43,54> <44,45,55> <54,44,55> <45,46,56> <55,45,56>
    <46,47,57> <56,46,57> <47,48,58> <57,47,58> <48,49,59> <58,48,59>
    <50,51,61> <60,50,61> <51,52,62> <61,51,62> <52,53,63> <62,52,63>
    <53,54,64> <63,53,64> <54,55,65> <64,54,65> <55,56,66> <65,55,66>
    <56,57,67> <66,56,67> <57,58,68> <67,57,68> <58,59,69> <68,58,69>
    <60,61,71> <70,60,71> <61,62,72> <71,61,72> <62,63,73> <72,62,73>
    <63,64,74> <73,63,74> <64,65,75> <74,64,75> <65,66,76> <75,65,76>
    <66,67,77> <76,66,77> <67,68,78> <77,67,78> <68,69,79> <78,68,79>
    <70,71,81> <80,70,81> <71,72,82> <81,71,82> <72,73,83> <82,72,83>
    <73,74,84> <83,73,84> <74,75,85> <84,74,85> <75,76,86> <85,75,86>
    <76,77,87> <86,76,87> <77,78,88> <87,77,88> <78,79,89> <88,78,89>
    <80,81,91> <90,80,91> <81,82,92> <91,81,92> <82,83,93> <92,82,93>
    <83,84,94> <93,83,94> <84,85,95> <94,84,95> <85,86,96> <95,85,96>
    <86,87,97> <96,86,97> <87,88,98> <97,87,98> <88,89,99> <98,88,99>
  }

#version 3.7;


// STL export macro
#macro WriteSTL(filename)
  #fopen STLFile filename write

  // Write STL header
  #write(STLFile, "solid POVRayMesh\n")

  // Get the number of faces
  #local NumFaces = dimension_size(FacesIndices, 1);

  // Loop through all faces
  #local i = 0;
  #while (i < NumFaces)
    // Get the three vertex indices for this face
    #local v1_idx = FacesIndices[i].x;
    #local v2_idx = FacesIndices[i].y;
    #local v3_idx = FacesIndices[i].z;

    // Get the vertices
    #local v1 = VertexVec[v1_idx];
    #local v2 = VertexVec[v2_idx];
    #local v3 = VertexVec[v3_idx];

    // Calculate face normal (cross product of two edge vectors)
    #local edge1 = v2 - v1;
    #local edge2 = v3 - v1;
    #local face_normal = vnormalize(vcross(edge1, edge2));

    // Write facet to STL file
    #write(STLFile, "  facet normal ", face_normal.x, " ", face_normal.y, " ",
face_normal.z, "\n")
    #write(STLFile, "    outer loop\n")
    #write(STLFile, "      vertex ", v1.x, " ", v1.y, " ", v1.z, "\n")
    #write(STLFile, "      vertex ", v2.x, " ", v2.y, " ", v2.z, "\n")
    #write(STLFile, "      vertex ", v3.x, " ", v3.y, " ", v3.z, "\n")
    #write(STLFile, "    endloop\n")
    #write(STLFile, "  endfacet\n")

    #local i = i + 1;
  #end

  // Write STL footer
  #write(STLFile, "endsolid POVRayMesh\n")

  #fclose STLFile
#end

// Call the macro to write the STL file
WriteSTL("mesh_output.stl")

// Optional: Display a message
#debug "STL file 'mesh_output.stl' has been created.\n"

// Create a simple scene to render (optional)
camera {
  location <20, 10, -20>
  look_at <0, 0, 0>
}

light_source {
  <30, 30, -30>
  color rgb <1, 1, 1>
}

// Render the mesh for visualization (optional)
mesh2 {
  vertex_vectors {
    dimension_size(VertexVec, 1),
    #local i = 0;
    #while (i < dimension_size(VertexVec, 1))
      VertexVec[i]
      #if (i < dimension_size(VertexVec, 1) - 1) , #end
      #local i = i + 1;
    #end
  }

  normal_vectors {
    dimension_size(NormalVec, 1),
    #local i = 0;
    #while (i < dimension_size(NormalVec, 1))
      NormalVec[i]
      #if (i < dimension_size(NormalVec, 1) - 1) , #end
      #local i = i + 1;
    #end
  }

  face_indices {
    dimension_size(FacesIndices, 1),
    #local i = 0;
    #while (i < dimension_size(FacesIndices, 1))
      FacesIndices[i]
      #if (i < dimension_size(FacesIndices, 1) - 1) , #end
      #local i = i + 1;
    #end
  }

  pigment { color rgb <0.8, 0.6, 0.4> }
  finish { ambient 0.2 diffuse 0.8 }
}

[Ilya Razmanov] Re: Impossible stl file conversion! [223 days 20 hours and 58 minutes ago]

Wed, 10 Sep 2025 11:27:28 GMT

On 10.09.2025 13:27, Bald Eagle wrote:
> 
> It's another installment in the long-running desire to have native stl support
> for POV-Ray.  There was some insistence that .stl is a binary-only format, or
> that it would be difficult to adapt our mesh {} code to handle stl.

STL may exist in binary form (although I see no good reason for that. 
Ok, some people say binary file takes less resources to load but I doubt 
it - I suppose most resources would be taken by interpreted scene 
itself, not the file), but ASCII STLs are fully legal. Like I said, 
beside POV-Ray output, for my img2mesh

https://dnyarri.github.io/img2mesh.html

I wrote ASCII STL, OBJ and DXF exports as well, and, imho, DXF is worst 
of all of them. It seems like developers were simply adding stuff like 
"ok let's plug this in ok so what type the variables are ah hell with 
that". What as to STL, about the only problem seem to be that some 
things declared as necessary are actually redundant and not used by 
various software, and it's hard to predict other software opinion about 
that. Well, with binary STL there would be problem with debugging 
(text-based formats are obviously the best for that), but since data are 
supposed to be the same as for ASCII, and STL allow only quite limited 
subset of what POV-Ray may do, I don't think it's an existential problem.

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

[Bald Eagle] Re: Impossible stl file conversion! [223 days 21 hours and 55 minutes ago]

Wed, 10 Sep 2025 10:30:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:

> I'm sorry but I don't get the joke (well, it's only 6:26 here and I'm
> still waiting for my coffee to extract).

It's now 6:24 here, and I'm in the exact same situation.  :D

> So?

It's another installment in the long-running desire to have native stl support
for POV-Ray.  There was some insistence that .stl is a binary-only format, or
that it would be difficult to adapt our mesh {} code to handle stl.

https://news.povray.org/web.65818958d9619d9a1f9dae3025979125%40news.povray.org

So the point is that if the SDL and stl are virtually identical, then it ought
to be fairly simple to add the ability _in source_ to #include "MyModel.stl"

- BE

[Ilya Razmanov] Re: Impossible stl file conversion! [224 days 4 hours and 50 minutes ago]

Wed, 10 Sep 2025 03:34:44 GMT

On 09.09.2025 2:32, Bald Eagle wrote:

I'm sorry but I don't get the joke (well, it's only 6:26 here and I'm 
still waiting for my coffee to extract). So, text files may be converted 
to text files. We already seen it here with DXF converter by yesbird 
<sya### [at] gmailcom>, and DXFs are definitely more unhuman than STL 
(at least it took me about 5 minutes to read STL specs when I was 
writing STL export for my img2mesh, and DXF specs took whole day just to 
find damn chirality reference). So?

>                                          ... IN ASCII!   :O
> 
> The free, open-source provision of these easily downloadable, viewable,
> interpretable, and 3D-printable files is not only sure to send shockwaves
> throughout the POV-Ray newsgroups, but some joker is actually claiming that such
> files bear more thana passing resemblance to . . . the POV-Ray mesh {} format!
> 
> Incredible!   Preposterous!
> Simultaneously a blasphemous, heretical, and seditious utterance!
> Home-coded find/replace extremism!
> 
> <Monty Python>
> Paradoxically, those that find the _non-binary_ form of this file offensive are
> - - - hateful bigots!
> </Monty Python>
> 
> Ni!
> 
> - BE
> 

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

[Bald Eagle] Impossible stl file conversion! [225 days 8 hours and 50 minutes ago]

Mon, 8 Sep 2025 23:35:00 GMT

*** TRIGGER WARNING ***

Matt Parker (Stand Up Maths) has a new video about a "self-righting"
tetrahedron:

https://www.youtube.com/watch?v=b6S5gHjuN48

But wait ...

                 ........... what's that?!!!

He provides not one but TWO .stl files . . .












                                        ... IN ASCII!   :O

The free, open-source provision of these easily downloadable, viewable,
interpretable, and 3D-printable files is not only sure to send shockwaves
throughout the POV-Ray newsgroups, but some joker is actually claiming that such
files bear more thana passing resemblance to . . . the POV-Ray mesh {} format!

Incredible!   Preposterous!
Simultaneously a blasphemous, heretical, and seditious utterance!
Home-coded find/replace extremism!

<Monty Python>
Paradoxically, those that find the _non-binary_ form of this file offensive are
- - - hateful bigots!
</Monty Python>

Ni!

- BE