news.povray.org message digest

[jr] Re: U.S. Virgin Islands 4/20 flag [12 hours and 36 minutes ago]

Mon, 20 Apr 2026 21:35:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> Happy 4/20!

it was a rather mixed day, else place ;-).

> The flag is all procedural.  The drug-free edition is at
>  https://en.wikipedia.org/wiki/Flag_of_the_United_States_Virgin_Islands

"three lids a day keeps the doctor away" </grin>.

regards, jr.

[Cousin Ricky] U.S. Virgin Islands 4/20 flag [14 hours and 2 minutes ago]

Mon, 20 Apr 2026 20:08:49 GMT

Happy 4/20!

The flag is all procedural.  The drug-free edition is at
 https://en.wikipedia.org/wiki/Flag_of_the_United_States_Virgin_Islands

[Mr] Re: Would you like a drink? [19 hours and 16 minutes ago]

Mon, 20 Apr 2026 14:55:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> On 11/02/2026 11:04, kurtz le pirate wrote:
> >
> > Hello,
> >
> > One or more suggestions for further improvement ?
> >
> >
>
> A few improvements. I'm working on it little by little.
>
> The surface of the liquid isn't flat anymore, but it doesn't make much
> of a difference. A new texture for the desk.
>
>
>
>
>
>
>
> --
> kurtz le pirate
> compagnie de la banquise

Yes this liquid is much more nuanced and appealing. The scale of the new wood
texture seems too small : it features screws that we would expect to also appear
in a normal bumb, plus not reveal to repeat as much if bigger.

For smoked oak wood, the following page shows low reflectivity but the
interaction with bitmap is hard to assign. Maybe start with a grey material to
get the shininess right...?
https://gustafs.com/knowledge-hub/surfaces/ligt-reflection-values/

[jr] Re: Bullet physics engine test [19 hours and 36 minutes ago]

Mon, 20 Apr 2026 14:35:00 GMT

hi,

"Cossack " <nomail@nomail> wrote:
> just a small demonstration .;]

very nice.  (and yes, (many) questions :-) like Leroy's, was it rendered on the
phone ?)

"Kenneth" <kdw### [at] gmailcom> wrote:
> Very cool!
>
> I have always wanted to play with this 'bullet physics' code in POV-ray, but I
> have no idea how to get it to run in MS Windows, or if it is even available in a
> 'Windows friendly' form. (I am not a C/C++ programmer.)
>
> Has anyone in the POV-ray community ever built a version that will run? I seem
> to vaguely remember *someone* doing that in the past...or maybe it was just for
> Linux/Unix?

I found the attached 2003 code by Alain Ducharme in TdG's (extensive) archives,
a "Povray rigid ball dynamics simulator", not quite "bullet physics" but...  all
in SDL, no other languages needed; I'm sure that there will be other code, 30+
years is a long time.  there is no explicit mention of licensing, but the author
writes "in the meantime, you may wish to collapse the required macros into your
main SimBall .pov files" -- sounds "permissive".  two (quickly rendered :-))
animations AD wrote:
<drive.google.com/file/d/1YASVkhbwLadwsHq3tuSlJZWRklMttItK/view?usp=sharing>
<drive.google.com/file/d/1vjarr_s4miZQqaDZQY6ztNMxMsdVAloH/view?usp=sharing>

regards, jr.

[Kenneth] Re: Bullet physics engine test [21 hours and 41 minutes ago]

Mon, 20 Apr 2026 12:30:00 GMT

Very cool!

I have always wanted to play with this 'bullet physics' code in POV-ray, but I
have no idea how to get it to run in MS Windows, or if it is even available in a
'Windows friendly' form. (I am not a C/C++ programmer.)

Has anyone in the POV-ray community ever built a version that will run? I seem
to vaguely remember *someone* doing that in the past...or maybe it was just for
Linux/Unix?

[Mr] Re: Light bleeding: adding halos to the spikes [23 hours and 16 minutes ago]

Mon, 20 Apr 2026 10:55:00 GMT

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

Did you think about abusing the rainbow primitive for this effect?

(I assume you did find this discussion with the same attempt in your search :
https://news.povray.org/povray.general/thread/%3C3BE87585.572DA5DB%40scifi-fantasy.com%3E/?ttop=445854&toff=6650)

[Mr] Re: Light bleeding: adding halos to the spikes [23 hours and 21 minutes ago]

Mon, 20 Apr 2026 10:50:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have been working on my light bleeding code, adding a circular halo to
> the diffraction spikes.  But while the added glow (Spikiness 0.25) looks
> a lot better, it is dreadfully slow, taking 31 minutes for a 512 x 256
> render, versus 1.5 minutes for the spikes alone (Spikiness 1.00).  The
> issue is that halos scale with the square of the radius, while spikes
> scale linearly.
>
> Looks like I'll be investigating Sam's technique to see if I can work
> out a hybrid that won't take forever.  Sam's lb7b allows me to add my
> own diffraction pattern, while my idea has been to bleed only color
> channels in excess of 1.0.
>
> Or, I could attempt to upgrade Nathan Kopp or Chris Colefax to POV-Ray
> 3.7/3.8, but I would rather not have to track light sources--especially
> since this does not account for reflections and highlights.
>
> I'm just noticing another lens flare library on my computer, credited to
> Zeger Knaepen in my notes, though his name is not in the code anywhere.

Yes, great work indeed, the pursue is worth it: looking much more realistic with
halo.

[kurtz le pirate] Re: Light bleeding: adding halos to the spikes [23 hours and 49 minutes ago]

Mon, 20 Apr 2026 10:21:20 GMT

On 19/04/2026 22:09, Cousin Ricky wrote:
> ...
> 
> I'm just noticing another lens flare library on my computer, credited to
> Zeger Knaepen in my notes, though his name is not in the code anywhere.

In fact, there are several examples on Zeger Knaepen's website... but no 
code found. <https://povplace.com/index.php?t=3>

In any case, great work on these halos and spikes.

-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Some times I just want to play !? [1 day 13 hours and 36 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.

[Cousin Ricky] Light bleeding: adding halos to the spikes [1 day 14 hours and 1 minute ago]

Sun, 19 Apr 2026 20:09:52 GMT

I have been working on my light bleeding code, adding a circular halo to
the diffraction spikes.  But while the added glow (Spikiness 0.25) looks
a lot better, it is dreadfully slow, taking 31 minutes for a 512 x 256
render, versus 1.5 minutes for the spikes alone (Spikiness 1.00).  The
issue is that halos scale with the square of the radius, while spikes
scale linearly.

Looks like I'll be investigating Sam's technique to see if I can work
out a hybrid that won't take forever.  Sam's lb7b allows me to add my
own diffraction pattern, while my idea has been to bleed only color
channels in excess of 1.0.

Or, I could attempt to upgrade Nathan Kopp or Chris Colefax to POV-Ray
3.7/3.8, but I would rather not have to track light sources--especially
since this does not account for reflections and highlights.

I'm just noticing another lens flare library on my computer, credited to
Zeger Knaepen in my notes, though his name is not in the code anywhere.

[Kenneth] anaglyph animation of flying car [1 day 14 hours and 6 minutes ago]

Sun, 19 Apr 2026 20:05:01 GMT

For this one, I used my humorous 'bulldog police car' that I made years ago--
which seemed like a good subject for an anaglyph.

WARNING: Be careful that it doesn't put-out your eye! ;-)

[Leroy] Some times I just want to play !? [1 day 15 hours and 26 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!

[Leroy] Re: Bullet physics engine test [1 day 15 hours and 46 minutes ago]

Sun, 19 Apr 2026 18:25:00 GMT

"Cossack " <nomail@nomail> wrote:
> just a small demonstration .;]

Cool! Wondering how long to parse & render it?

Have Fun!

[yesbird] Re: Would you like a drink? [1 day 15 hours and 54 minutes ago]

Sun, 19 Apr 2026 18:16:48 GMT

On 19/04/2026 18:49, kurtz le pirate wrote:
> The surface of the liquid isn't flat anymore, but it doesn't make much 
> of a difference. A new texture for the desk.
>

Much better and natural now, I see the coaster is also improved.
--
YB

[kurtz le pirate] Re: Would you like a drink? [1 day 18 hours and 21 minutes ago]

Sun, 19 Apr 2026 15:50:01 GMT

On 11/02/2026 11:04, kurtz le pirate wrote:
> 
> Hello,
> 
> One or more suggestions for further improvement ?
> 
> 

A few improvements. I'm working on it little by little.

The surface of the liquid isn't flat anymore, but it doesn't make much 
of a difference. A new texture for the desk.

-- 
kurtz le pirate
compagnie de la banquise

[Cossack ] Bullet physics engine test [1 day 19 hours and 36 minutes ago]

Sun, 19 Apr 2026 14:35:01 GMT

just a small demonstration .;]

[Bald Eagle] photorealism ray-tracing huamin wang [5 days 14 hours and 46 minutes 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: Practical Stargate kawoosh effect ideas [5 days 21 hours and 6 minutes ago]

Wed, 15 Apr 2026 13:05:00 GMT

"Nekar Xenos" <nomail@nomail> wrote:
> Today I went down the rabbit hole of Is It Possible To Recreate The Stargate
> Kawoosh theoretically as a practical effect?

I think you need to get in contact with THIS guy . . .

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


- BE

[Bald Eagle] Re: POV-Ray Origins [5 days 21 hours and 31 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 [6 days 12 hours and 21 minutes ago]

Tue, 14 Apr 2026 21:50:00 GMT

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

[Clarence1898] Re: Orrery WIP Part 1 [6 days 21 hours and 1 minute ago]

Tue, 14 Apr 2026 13:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> [I happen to be working on an animation of my own right now.]
>
> Your 'wip 2' (3840x2160 downsized to 640 X 360) looks *much* better than your
> first wip. So the original problem was not due to the MPEG compression your
> used-- I checked both videos' 'bit rates', and wip 2 is even more compressed,
> slightly. But it still looks quite nice.
>
> I made a screenshot from your wip 1 (see attached.) The window and some other
> parts show 'jaggies'-- as if no antialiasing was used at all, which is quite
> strange. I would have assumed that your aa2 method would have completely
> eliminated those.
>
> Do you still have your original 640 X 360 animation renders from wip 1? Maybe
> take a look at some of those, to see if the jaggies are present there.
>
> As B.E. said, a possible problem is that your scene has very sharp narrow lines
> and tiny details, which can sometimes react badly to aa. (You mentioned that you
> turned off your aa jitter. As a suggestion, try using aa method 1 with a setting
> of zero, and turn ON the jitter. Who knows, it might help! I am currently using
> that set-up, and the final MPEG animation result looks fine to me.)

I don't have any of the original renders, I don't keep them around very long.  I
have been experimenting with various anti-alias options yesterday.  The problem
is definitely due to sharp narrow lines and tiny details.  More than any other
animation I have ever done.  I had never needed to use Antialias_Depth before so
I didn't think to use it. When I added Antialias_Depth it has definitely
improved.  I have attached the last test using +am1 +r7.  Because it is shooting
more rays per pixel it does take longer. With a depth of 1 it take 20 minute,
with 7 it goes up to 90 minutes.   A side effect has been a reduction of the
animation size with higher depth.  With a depth of 1 it was 4.6M,  with a depth
of 7 it was 2.0M. So I should be able to render at a higher resolution.  It
seems that rendering at higher depth is kind of equivalent to rendering at
higher resolution then scaling down. Though maybe without as much overhead. In
both you are shooting more rays through each pixel.  I'm going to try using +am2
next to see what that does.

Clarence

[Kenneth] Re: Orrery WIP Part 1 [7 days 2 hours and 1 minute ago]

Tue, 14 Apr 2026 08:10:00 GMT

[I happen to be working on an animation of my own right now.]

Your 'wip 2' (3840x2160 downsized to 640 X 360) looks *much* better than your
first wip. So the original problem was not due to the MPEG compression your
used-- I checked both videos' 'bit rates', and wip 2 is even more compressed,
slightly. But it still looks quite nice.

I made a screenshot from your wip 1 (see attached.) The window and some other
parts show 'jaggies'-- as if no antialiasing was used at all, which is quite
strange. I would have assumed that your aa2 method would have completely
eliminated those.

Do you still have your original 640 X 360 animation renders from wip 1? Maybe
take a look at some of those, to see if the jaggies are present there.

As B.E. said, a possible problem is that your scene has very sharp narrow lines
and tiny details, which can sometimes react badly to aa. (You mentioned that you
turned off your aa jitter. As a suggestion, try using aa method 1 with a setting
of zero, and turn ON the jitter. Who knows, it might help! I am currently using
that set-up, and the final MPEG animation result looks fine to me.)

[yesbird] Re: Procedural Methods for Two-Dimensional Textu... [7 days 10 hours and 30 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... [7 days 12 hours and 57 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... [7 days 14 hours and 11 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... [7 days 14 hours and 57 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... [7 days 17 hours and 26 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... [7 days 19 hours and 24 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

[Bald Eagle] Re: Orrery WIP Part 1 [7 days 19 hours and 31 minutes ago]

Mon, 13 Apr 2026 14:40:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:

> Wow.  Thanks for all the information.  It will take me a while to digest all of
> this.

You and me both.

> It all looks very interesting.

There is just SO much out there to learn.
Just look at all of the fun that we have coloring tiny little squares on a
screen.

> I'll probably start with examining
> anti-aliasing closer.

No worries.
Maybe the flickering on the checkerboard could be eliminated using a smooth-step
kind of transition between squares rather than a discontinuous jump.
Something along the lines of:
https://news.povray.org/web.60888d70cfb077e41f9dae3025979125%40news.povray.org

https://www.youtube.com/watch?v=60VoL-F-jIQ&t=31s

Then maybe you can change your geometry from CSG to a sort of blobbed
isosurface. (like on the doors)
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d4b7ce3a683fa3a4eec112d0%40news.povray.org%3E/
Or maybe just using rounded boxes would help some - I really don't know.
Area light for softer shadows?

I'd do highly stripped-down versions of the animation to investigate what
remediates the problematic parts of the animation so that you can get quick
answers without rendering _everything_.

> Again thank you very much.

Of course - I like to think that if we can assemble a group to offer
constructive criticism and helpful suggestions, that we can ALL benefit and
complete a lot more projects in a timely manner.

- BE

[kurtz le pirate] Re: Arcade Controller Box [7 days 20 hours and 5 minutes ago]

Mon, 13 Apr 2026 14:05:49 GMT

On 08/04/2026 20:51, Dave Blandston wrote:
> Render twice, cut once!

Good potential.


-- 
kurtz le pirate
compagnie de la banquise

[Clarence1898] Re: Orrery WIP Part 1 [7 days 20 hours and 11 minutes ago]

Mon, 13 Apr 2026 14:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > I've made a few minor changes to smooth the camera path.  I'm still unhappy with
> > the flickering.  I've read a few articles, but the only methods that apply to
> > povray was to disable jitter(which is already disabled), increase anti-aliasing,
> > render at larger resolution then downscale, and reduce detail. There are 1501
> > frames in the animation.  At that size the resolution that fits within the 5M
> > post limit is 640x360. Since I distribute the renders across 3 PCs I made sure
> > that all renders are done on the same environment. After a little experimenting
> > with anti-aliasing, the best result was using +a0.0 +am2. I tried 3 resolutions:
> > 640x360, 1920x1080, and 3840x2160, downsizing the latter to 640x360.  The
> > 640x360 version flickering is pretty bad.  the 1920x1080 is better but still not
> > great.  The 3840x2160 is quite a bit better but does not eliminate the flicker.
> > The main problem with rendering at higher resolution and then downscaling is a
> > dramatic increase in render time.  The 640x360 takes under 20 minutes, 1920x1080
> > just under 2 hours, 3840x2160 over 7 hours.  Before reducing detail are there
> > any other suggestions I can try?  I have posted the 640x360 version with this
> > post.  I'll post the downscaled 3840x2160 version in the following post.
>
> Well Boss, I'm not going to say that I understand exactly what the problem is,
> but I will throw a few things out there.
>
> fwidth.  Look it up, play with it.  It's a way to do some amazing things.
> I you find my spiral pattern, it's only 6 lines of code.
> But it doesn't show anything recognizable without that fwidth function.
> And then it's amazing.
>
> Read this article:
> https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8
>
> I'm not saying that it's going to totally fix your problem, but there's a lot
> there for serious POV-Rayers to think about and benefit from.
>
> Perhaps use some different ant-aliasing settings, and search for comments by
> Alain and clipka.  doing a very deep, fine antialiasing might be better and
> faster than doing huge time-consuming renders and then shrinking them down.
> I have opined in the past that we should have some nice antialiasing macros to
> help sort out all of the different modes and options.   Maybe you can look into
> coding a first draft.
>
> ffmpeg has some great settings for chopping down the file size yet keeping the
> video quality the same.
>
> Look into mip-mapping.  Don't know exactly what it is, or how to use it, or if
> we can do that in POV-Ray.
> I do believe that Martijn Steinrucker of Art Of Code youtube channel might cover
> it in his "The Drive Home" series
>
> https://www.youtube.com/watch?v=WrxZ4AZPdOQ
>
> Also:
> https://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf
>
> In summary, I think that there must definitely be a [good] way to get rid of
> your flickering - we just need to find out what it is.
>
> - BE

Wow.  Thanks for all the information.  It will take me a while to digest all of
this.  It all looks very interesting.  I'll probably start with examining
anti-aliasing closer.  Again thank you very much.

Clarence.

[Clarence1898] Re: Orrery WIP Part 1 [7 days 20 hours and 16 minutes ago]

Mon, 13 Apr 2026 13:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > I've made a few minor changes to smooth the camera path.  I'm still unhappy with
> > the flickering. ...
>
> out of interest, the camera path is spline-based ?  (one, or several ?)  do you
> base movement on the clock, or use frame_number ?
>
>
> regards, jr.

The location is based on one spline, the lookat point is base on a second
spline.  Both are based on the clock.  When the camera enters earth orbit it
changes to a spiral path around it.

[kurtz le pirate] Re: Post something [7 days 23 hours and 50 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

[jr] Re: Orrery WIP Part 1 [8 days 5 hours and 41 minutes ago]

Mon, 13 Apr 2026 04:30:00 GMT

hi,

"Clarence1898" <dle### [at] comcastnet> wrote:
> I've made a few minor changes to smooth the camera path.  I'm still unhappy with
> the flickering. ...

out of interest, the camera path is spline-based ?  (one, or several ?)  do you
base movement on the clock, or use frame_number ?

regards, jr.

[Bald Eagle] Re: Orrery WIP Part 1 [8 days 11 hours and 56 minutes ago]

Sun, 12 Apr 2026 22:15:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> I've made a few minor changes to smooth the camera path.  I'm still unhappy with
> the flickering.  I've read a few articles, but the only methods that apply to
> povray was to disable jitter(which is already disabled), increase anti-aliasing,
> render at larger resolution then downscale, and reduce detail. There are 1501
> frames in the animation.  At that size the resolution that fits within the 5M
> post limit is 640x360. Since I distribute the renders across 3 PCs I made sure
> that all renders are done on the same environment. After a little experimenting
> with anti-aliasing, the best result was using +a0.0 +am2. I tried 3 resolutions:
> 640x360, 1920x1080, and 3840x2160, downsizing the latter to 640x360.  The
> 640x360 version flickering is pretty bad.  the 1920x1080 is better but still not
> great.  The 3840x2160 is quite a bit better but does not eliminate the flicker.
> The main problem with rendering at higher resolution and then downscaling is a
> dramatic increase in render time.  The 640x360 takes under 20 minutes, 1920x1080
> just under 2 hours, 3840x2160 over 7 hours.  Before reducing detail are there
> any other suggestions I can try?  I have posted the 640x360 version with this
> post.  I'll post the downscaled 3840x2160 version in the following post.

Well Boss, I'm not going to say that I understand exactly what the problem is,
but I will throw a few things out there.

fwidth.  Look it up, play with it.  It's a way to do some amazing things.
I you find my spiral pattern, it's only 6 lines of code.
But it doesn't show anything recognizable without that fwidth function.
And then it's amazing.

Read this article:
https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8

I'm not saying that it's going to totally fix your problem, but there's a lot
there for serious POV-Rayers to think about and benefit from.

Perhaps use some different ant-aliasing settings, and search for comments by
Alain and clipka.  doing a very deep, fine antialiasing might be better and
faster than doing huge time-consuming renders and then shrinking them down.
I have opined in the past that we should have some nice antialiasing macros to
help sort out all of the different modes and options.   Maybe you can look into
coding a first draft.

ffmpeg has some great settings for chopping down the file size yet keeping the
video quality the same.

Look into mip-mapping.  Don't know exactly what it is, or how to use it, or if
we can do that in POV-Ray.
I do believe that Martijn Steinrucker of Art Of Code youtube channel might cover
it in his "The Drive Home" series

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

Also:
https://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf

In summary, I think that there must definitely be a [good] way to get rid of
your flickering - we just need to find out what it is.

- BE

[Clarence1898] Orrery WIP Part 2 [8 days 14 hours and 21 minutes ago]

Sun, 12 Apr 2026 19:50:02 GMT

Here is the 3840x2160 image scaled to 640x360

[Clarence1898] Orrery WIP Part 1 [8 days 14 hours and 21 minutes ago]

Sun, 12 Apr 2026 19:50:01 GMT

I've made a few minor changes to smooth the camera path.  I'm still unhappy with
the flickering.  I've read a few articles, but the only methods that apply to
povray was to disable jitter(which is already disabled), increase anti-aliasing,
render at larger resolution then downscale, and reduce detail. There are 1501
frames in the animation.  At that size the resolution that fits within the 5M
post limit is 640x360. Since I distribute the renders across 3 PCs I made sure
that all renders are done on the same environment. After a little experimenting
with anti-aliasing, the best result was using +a0.0 +am2. I tried 3 resolutions:
640x360, 1920x1080, and 3840x2160, downsizing the latter to 640x360.  The
640x360 version flickering is pretty bad.  the 1920x1080 is better but still not
great.  The 3840x2160 is quite a bit better but does not eliminate the flicker.
The main problem with rendering at higher resolution and then downscaling is a
dramatic increase in render time.  The 640x360 takes under 20 minutes, 1920x1080
just under 2 hours, 3840x2160 over 7 hours.  Before reducing detail are there
any other suggestions I can try?  I have posted the 640x360 version with this
post.  I'll post the downscaled 3840x2160 version in the following post.

[Cousin Ricky] Re: Post something [8 days 19 hours and 41 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 [10 days 1 hour and 54 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 [10 days 3 hours and 3 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 [10 days 15 hours and 1 minute 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 [10 days 15 hours and 18 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 [10 days 15 hours and 43 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 [10 days 16 hours and 8 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 [10 days 16 hours and 31 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 [10 days 16 hours and 54 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 [10 days 17 hours and 4 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

[kurtz le pirate] Re: Nanotube breaking through the plane [10 days 17 hours and 14 minutes ago]

Fri, 10 Apr 2026 16:56:47 GMT

On 06/04/2026 14:34, Bald Eagle wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> I don't know if that's "chemically" correct.
>> I've always been pretty bad at that stuff.
> 
> This should be chemically correct. *
> 
> * there is a certain strain energy that cannot be exceeded for stable molecules.
> So, as long as your nanotube has a certain minimum radius, then it should be
> fine.   That's not to say that they've actually made/discovered on of that exact
> size, just that there's nothing obviously wrong with the theoretical structure.
> Usually when making things like this, there are the fundamental thermodynamic
> considerations (is it stable?) but there can be overriding kinetic realities
> that control what actually happens. (Structure A is less stable but forms
> faster, so it out-competes structure B and winds up unexpectedly being the major
> reaction product.)
> 
> The only other thing that's "missing" is the filling of the empty valence
> orbitals on those dangling edge carbons.   What is at the edge of a crystal?
> This is where a lot of interesting research goes on in the field of surface
> chemistry.
> You could also likely terminate those sites with methyl groups, alkenes (double
> bonds) or some sort of aldehyde, ketone, or carboxylic acid.
> 
> You can also "dope" nanotubes with small quantities of other elements to replace
> some of the carbons - boron, nitrogen, silicon, ... to imbue them with various
> useful properties.
> 
> - BE
> 
> 


I should have guessed as much when I saw your email. Youâ€™re a true 
chemist for whom certain concepts are obvious but remain a bit abstract 
for othersâ€”at least for me. In any case, your explanations are 
â€œrelativelyâ€ simple and offer some good insigh.


In this image, at least, the nanotube is just a pretext for exploring 
and applying a few mathematical transformations.


-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Post something [10 days 17 hours and 31 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 [10 days 18 hours and 53 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
     }
   }
}
---%<---%<---%<---

[Leroy] Re: anaglyph of cave-- animation [11 days 6 hours and 41 minutes ago]

Fri, 10 Apr 2026 03:30:00 GMT

Why I'm I having trouble attaching stuff? Here's another try..

[Bald Eagle] Re: ISP Failure [11 days 9 hours and 1 minute ago]

Fri, 10 Apr 2026 01:10:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "I am so back."
> >
> > - BE
>
> So what was it a new service or a new provider or both?
>
> Have Fun!

I totally ditched the old provider.
Got new ISP, bought my own gateway, have much faster internet with a stronger
wifi signal for my son, and it's like half the price for 5 years.
Might get a "free" mobile number too.

Caveat Emptor, and all that.  So we'll see, when my first few bills show up.

- BE

Internet installer: "It looks like a machine shop in here."   :D

[Leroy] Re: ISP Failure [11 days 9 hours and 56 minutes ago]

Fri, 10 Apr 2026 00:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "I am so back."
>
> - BE

So what was it a new service or a new provider or both?

Have Fun!

[Leroy] Re: anaglyph of cave-- animation [11 days 10 hours and 1 minute ago]

Fri, 10 Apr 2026 00:10:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> >
> > Beautiful! I sat back from the screen a good distance and I was there:)
> > Didn't notice the ghosting.
> >
>
> Thanks!
>
> Here's an earlier test, while I was working out my scheme. The scene itself
> makes no physical sense, it was just to test some moving objects and camera
> parameters.
>
> I also had to figure out how the scene's 'clock' should work when objects
> actually move. For my initial left/right grayscale animation, the frames
> continually *alternate* between left/right views-- frames 1 and 2 are a stereo
> pair, then frames 3 and 4, etc.-- so the clock needs to 'back up' slightly for
> the even-numbered frames. Otherwise, there would be a slight and incorrect
> positional shift of the objects, between each image in a stereo pair.
>
> This alternating-view scheme is just easier for me to work with, rather than
> running TWO separate animations to get left and right views. And I can more
> easily copy/combine/color each pair later, in a secondary scene set-up.

 It's been awhile since I work on Red green anaglyphs . I used 3 frames one for
the left one for the right then on for the 3d. I don't remember if I used this
for animation, But I do remember creating a 3d jet flight over an island. Can't
find it on this computer it is probably on the XP. I also wrote a win program to
do anaglyphs to make it easier to adjust the left and right placement. It's
still on the XP too. I do have plenty of 3d stills here on this win10. I took a
lot of pictures with my old digital camera(before cell phones). The win program
helped a lot to turn 2 hand take pictures into an anaglyph.
Here's one from the tornado that hit our town.
Have Fun!

[Kenneth] Re: anaglyph of a cave setting [11 days 11 hours and 1 minute ago]

Thu, 9 Apr 2026 23:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I know that you have been playing with this for a while, and have (probably)
> read Paul Bourke's write-ups on this, and are (probably) using a mesh camera.
>
No, this time I didn't use any of POV-ray's included mesh_cam scenes as a
starting point (in the scenes/camera/mesh_camera folder, specifically the
meshcam_persp_demo). Instead, I took an 'old world' approach of simply using two
left/right camera views in a scene.

Back in May of 2023, I did experiment with the mesh camera to try and make
anaglyphs. See my comments and image tests in Josh English's thread, starting
about midway through the various replies...

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

I had to re-read that entire thread, to re-familiarize myself with what I had
done! (Us 'old folks' have a way of forgetting things, ha.) But my final
anaglyph result there also exhibited the '3D distortion' that I mentioned--
which was probably a natural result of the way I used the mesh camera (perhaps
the same way as in my experiments here, when using camera rotation rather than
x-displacement.)  Maybe that distortion could have been eliminated somehow if I
had kept at it, but I could not fully understand the meshcam code or math.

Although, I might revisit that code...

[Bald Eagle] Re: ISP Failure [11 days 14 hours and 56 minutes ago]

Thu, 9 Apr 2026 19:15:00 GMT

"I am so back."

- BE

[Dave Blandston] Re: Arcade Control Box [11 days 15 hours and 21 minutes ago]

Thu, 9 Apr 2026 18:50:00 GMT

Fortunately the prototype won't need the curved front - just flat will do in
order to make sure everything fits OK.

I was excited to see that there's a maker's place in my area but when I looked
at their website it turns out they're just getting started and don't have tools
yet. It would be great if that organization gets going. If I can find a cabinet
guy to build the box though it should only take a couple hours and I can do the
finishing.

Kind regards,
Dave Blandston

[Bald Eagle] Re: Arcade Control Box [11 days 19 hours and 16 minutes ago]

Thu, 9 Apr 2026 14:55:00 GMT

"Dave Blandston" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > (what about foam-core board? With a cardboard shipping tube for the rounded
> > edge.)
>
> Ah-ha, foam-core board will be perfect for a prototype.

Excellent.   I was afraid I was being silly by suggesting it.

> The only thing I'm not
> 100% certain of and won't be until I get the trackball is how tall the sides
> need to be in order to accommodate the trackball housing. I was planning to use
> cardboard but foam-core board will be way easier to work with. The final product
> will be made from 3/4" hardwood so it will be sturdy and heavy.

Foam-core is apparently available in fairly thick forms.
For your bend, you could score at either end of the arc, and peel away the
card-stock, and then "corrugate" or soften the internal foam with heat or a
solvent so that you get a nice, smooth bend without having to fight the
compression on the convex side.
Just make the console overly tall to accommodate the trackball, and then trim it
to height after installation.

You could likely do all of your cutting with a router or even with a Dremel.
Small rotary tool that doesn't require much storage space, and you can do all of
the work outside this Spring. A cheap handsaw could be used for the straight
cuts, but you could even score those with the router bit prior to sawing.

Perhaps there's a maker-space somewhere near you?

- BE

https://corporate.mattel.com/brand-portfolio/power-shop
I rescued and restored an original 1964 model - after it had been submerged in a
flooded basement for ... who knows how many years.  I was absolutely astonished
that it still worked!  And now that I bring it up, I can look into 3D printing
some new parts for it!
:D

[Bald Eagle] Re: anaglyph of a cave setting [11 days 21 hours and 46 minutes ago]

Thu, 9 Apr 2026 12:25:00 GMT

So, I know that you have been playing with this for a while, and have (probably)
read Paul Bourke's write-ups on this, and are (probably) using a mesh camera.

Have you tried not rotating the entire mesh, but rotating the "look-at" vector
of each mesh triangle instead?  Or rotating all of the triangles themselves?
(like a louvre)

- BW

[Kenneth] Re: anaglyph of a cave setting [12 days 4 hours and 26 minutes ago]

Thu, 9 Apr 2026 05:45:00 GMT

"Maetes" <nomail@nomail> wrote:
> Your stereo image should look better, the effect doesn't come into its
> own as it could.
>
> For my 3D shots, I create the left + right shots by ROTATING the camera by 0.5
> to a maximum of 1.5 degrees. It seems to me that you did it differently.
>
I tested a bunch of different camera setups to get my left/right views,
including the rotation scheme you mentioned. If I understand what you use, it's
something like the following(?): (see A in the attached images; assume that the
field of numbers is centered on <0,0,0>)

camera {
  perspective
  location  <0, 0, -25>
  look_at   <0, 0, 0> // ditto
  right     x*image_width/image_height
  angle 67
  rotate 1.0*y // 1.0 for left view, -1.0 for right view
}

That does produce a beautiful 3-D effect, both into and out of the screen plane,
and with no post-processed image-shifting required. But it also creates the
'distortion' I mentioned earlier-- where the red and cyan views of some of the
objects do not line up horizontally. This makes the anaglyph difficult to look
at. In this particular image, the worst offenders are at the top and bottom
corners on both sides; the only truly horizontal color pairs are in a band
across the middle of the image.

To correct for that (see image B), I use a different set-up: no rotation (unless
I want to add it just for effect, and equally to both images), but rather by
shifting the camera's x-location and x-look_at, *equally*:

camera {
  perspective
  location  <-.5, 0, -25> // -/+ .5 for left and right
  look_at   <-.5, 0, 0> // ditto
  right     x*image_width/image_height
  angle 67
  // rotate <0,0,0> // optional; same for each view
}

These x-values are the only things I change-- and this by itself eliminates the
'distortion'; all of the resulting red/cyan pairs are nicely horizontal.
Unfortunately, the resulting 3-D effect-- while correct as to 3-D depth--
appears totally OUT of the screen plane, toward the viewer. In other words, the
'infinite distance' of the scene is *at* the screen plane, instead of appearing
deep into the screen. (To be honest, I am still a bit clueless as to why this
occurs.)

So I correct for that in another step (a special 2nd-scene copying set-up), by
slightly shifting both images in x, in opposite directions, until I get the 3-D
effect I want. See image C.

>
> I'm also interested in the humanoid. I've tried several times on a fully
> controllable person...

My human is a CSG model I made *long* ago (from just basic POV-ray shapes) as a
stand-in for testing various scenes. It's just a rigid shape; I never included
any animation code. Every now and then, I'll go back and tweak various parts. It
has probably gone through a dozen iterations by now! And its code is very messy
:-(

[Dave Blandston] Re: Arcade Control Box [12 days 4 hours and 46 minutes ago]

Thu, 9 Apr 2026 05:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> (what about foam-core board? With a cardboard shipping tube for the rounded
> edge.)

Ah-ha, foam-core board will be perfect for a prototype. The only thing I'm not
100% certain of and won't be until I get the trackball is how tall the sides
need to be in order to accommodate the trackball housing. I was planning to use
cardboard but foam-core board will be way easier to work with. The final product
will be made from 3/4" hardwood so it will be sturdy and heavy.

[Kenneth] Re: anaglyph of cave-- animation [12 days 6 hours and 51 minutes ago]

Thu, 9 Apr 2026 03:20:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
>
> Beautiful! I sat back from the screen a good distance and I was there:)
> Didn't notice the ghosting.
>

Thanks!

Here's an earlier test, while I was working out my scheme. The scene itself
makes no physical sense, it was just to test some moving objects and camera
parameters.

I also had to figure out how the scene's 'clock' should work when objects
actually move. For my initial left/right grayscale animation, the frames
continually *alternate* between left/right views-- frames 1 and 2 are a stereo
pair, then frames 3 and 4, etc.-- so the clock needs to 'back up' slightly for
the even-numbered frames. Otherwise, there would be a slight and incorrect
positional shift of the objects, between each image in a stereo pair.

This alternating-view scheme is just easier for me to work with, rather than
running TWO separate animations to get left and right views. And I can more
easily copy/combine/color each pair later, in a secondary scene set-up.

[Clarence1898] Re: Post something [12 days 12 hours and 26 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 [12 days 12 hours and 41 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

[Leroy] Re: anaglyph of cave-- animation [12 days 13 hours and 56 minutes ago]

Wed, 8 Apr 2026 20:15:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> see my earlier post here...
>
>
https://news.povray.org/povray.binaries.images/message/%3Cweb.69d664d28f6ec17de83955656e066e29%40news.povray.org%3E/#
%3
> Cweb.69d664d28f6ec17de83955656e066e29%40news.povray.org%3E
>
> I had to use higher-than-normal MPEG compression to get the file size to post
> here-- which causes some slight 'ghosting' of the cyan color when viewed.

Beautiful! I sat back from the screen a good distance and I was there:)
Didn't notice the ghosting.

Have Fun!

[Bald Eagle] Re: Nanotube breaking through the plane [12 days 14 hours and 46 minutes ago]

Wed, 8 Apr 2026 19:25:00 GMT

https://www.somewhereville.com/2007/07/20/recent-appearances-hessen-nanotech-and-institute-of-physics/

[Bald Eagle] Re: Arcade Control Box [12 days 15 hours and 1 minute ago]

Wed, 8 Apr 2026 19:10:00 GMT

"Dave Blandston" <nomail@nomail> wrote:

> That's what I would really like to do. But when we moved to our current home I
> sold most of my woodworking tools. At the moment I don't have room for even a
> small workbench.

You should see my 2nd floor apartment.  :D

> The online laser cutter looks awesome
> and I'm glad you pointed it out but their limit for wood thickness disqualifies
> them for this project unfortunately.

Does it though?  Just stack multiple identical sheets.

(what about foam-core board? With a cardboard shipping tube for the rounded
edge.)

 The POV model (without the artwork and
> controls attached) shows all the cuts and holes that are necessary so that may
> help me convince someone to take on the job.

I might know a guy. ;)
We've cut fairly thick pieces of wood, but I'd say best would be 1/4" max.
Also cut plastic, and engrave glass, and granite tile.
Dunno what the shipping from NH would be.

But to go off on a - tangent - you may have noticed some of Mikhail's influence
on some of my modeling projects . . .  maybe 80% ;)

> ... I'm astounded that you were able to
> program a game with an Arduino! That sounds like quite an accomplishment!

Well, I didn't write the whole thing myself, it was part of a kit kinda thing.

 My
> first experience with an Arduino was just a few days ago - I plan to use one to
> control the LEDs on the arcade control box. Very simple, especially compared to
> writing an entire game! How did you manage to display the graphics?

Like I said, it was a toy game, on an, IIRC, 8x8 pixel display.

I've programmed a lot more complicated stuff on Arduinos, and likely have the
"sketches" saved somewhere.  Bluetooth-enabled interface with menu, PID process
control, bunch of other stuff.  Read/write EEPROM, controlling laser displays,
etc.

But there are crazy people in the world:
https://hackaday.com/2022/01/12/arduino-and-an-oled-make-this-space-invaders-cabinet-tiny/

- BW

[Dave Blandston] Arcade Controller Box [12 days 15 hours and 16 minutes ago]

Wed, 8 Apr 2026 18:55:00 GMT

Render twice, cut once!

[Dave Blandston] Re: Arcade Control Box [12 days 15 hours and 26 minutes ago]

Wed, 8 Apr 2026 18:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also, since it's just a cabinet, you would likely be able to save a ton of money
> and just build it yourself.  Paint and a fancy printed vinyl sticker can cover a
> multitude of sins.

That's what I would really like to do. But when we moved to our current home I
sold most of my woodworking tools. At the moment I don't have room for even a
small workbench. I was hoping that the local community college would have a
workshop that I could use if I signed up for a class but it doesn't. Modeling
the box with POV was extremely helpful to determine the measurements though and
it's a really simple woodworking project. The online laser cutter looks awesome
and I'm glad you pointed it out but their limit for wood thickness disqualifies
them for this project unfortunately. The POV model (without the artwork and
controls attached) shows all the cuts and holes that are necessary so that may
help me convince someone to take on the job. I'll post that picture in the
images section too.

The software part of the project is coming along nicely. I'm using QB64PE and
it's fantastic for this sort of thing. I did a false start on this project a few
years ago with C and never finished it so I'm astounded that you were able to
program a game with an Arduino! That sounds like quite an accomplishment! My
first experience with an Arduino was just a few days ago - I plan to use one to
control the LEDs on the arcade control box. Very simple, especially compared to
writing an entire game! How did you manage to display the graphics?

Kind regards,
Dave Blandston

[MichaelJF] Re: Post something [12 days 15 hours and 31 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

[Bald Eagle] Re: anaglyph of a cave setting [12 days 16 hours and 21 minutes ago]

Wed, 8 Apr 2026 17:50:00 GMT

"Maetes" <nomail@nomail> wrote:

> I'm also interested in the humanoid. I've tried several times on a fully
> controllable person, It didn't fail because of the programming, but because of
> the appearance, the things always looked extremely ugly.

PovPerson
BlobMan
IIRC, Rune did a thing with faces that I can't find now
also IIRC, Thomas deGroot worked with someone on an animated scene project with
automated dialog-controlled faces (?)
There may be other inverse kinematics and other skeleton-muscle projects.

They is to exhaustively search for prior art, and look at other sites to see
what they do, and then adapt that to raytracing.

- BE

[Maetes] Re: anaglyph of a cave setting [12 days 16 hours and 36 minutes ago]

Wed, 8 Apr 2026 17:35:00 GMT

Your stereo image should look better, the effect doesn't come into its own as it
could.

For my 3D shots, I create the left + right shots by ROTATING the camera by 0.5
to a maximum of 1.5 degrees. It seems to me that you did it differently.

I don't want to complain, I just want to help.

I'm also interested in the humanoid. I've tried several times on a fully
controllable person, It didn't fail because of the programming, but because of
the appearance, the things always looked extremely ugly.

m

[Alain Martel] Re: Post something [12 days 17 hours and 8 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 [12 days 18 hours and 16 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

[Kenneth] anaglyph of cave-- animation [12 days 19 hours and 1 minute ago]

Wed, 8 Apr 2026 15:10:01 GMT

see my earlier post here...

https://news.povray.org/povray.binaries.images/message/%3Cweb.69d664d28f6ec17de83955656e066e29%40news.povray.org%3E/#%3
Cweb.69d664d28f6ec17de83955656e066e29%40news.povray.org%3E

I had to use higher-than-normal MPEG compression to get the file size to post
here-- which causes some slight 'ghosting' of the cyan color when viewed.

[Kenneth] anaglyph of a cave setting [12 days 19 hours and 31 minutes ago]

Wed, 8 Apr 2026 14:40:00 GMT

[in response to BE's "post something...]

For several weeks, I've been playing around with making anaglyph images, as well
as animations. I was inspired by Maete's recent post about his star-field
animations...

https://news.povray.org/povray.binaries.animations/thread/%3Cweb.697f16a4993dccb938e9762c7597fb06%40news.povray.org%3E/


I had made anaglyphs before from POV-ray scenes in the distant past, but always
used an external image app to color and combine them as the final step. I wanted
to see if I could accomplish the same result completely within POV-ray. (It's a
two step process: running the grayscale left/right views in the 'main' scene,
then using another scene to simply copy them 1:1 while coloring and combining
them-- plus shifting each view horizontally to get the 3-D effect I want, either
into the 'screen plane' or out of it.)

So far, mine are only grayscale versions, not 'full-color' anaglyphs. I first
had to work out the proper camera set-up for getting the left/right views, to
avoid what I call '3D distortion'-- where some of the scene elements in each
view do not line up perfectly horizontally when viewed as red/cyan stereo. (This
causes an uncomfortable viewing experience, where you have to tilt your head to
see the non-aligned parts.)

For the attached image, I used an old scene-- a cave, made using the HF_Cylinder
macro in shapes.inc (along with some functions to give it the craggy 'rock'
look.)

I also made an animation of the scene, that I will post separately.

I'm having WAY too much fun with this!

[jr] Re: Post something [12 days 19 hours and 56 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 [12 days 20 hours and 21 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 [12 days 21 hours and 11 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/

[Jörg "Yadgar" Bleimann] Re: Nanotube breaking through the plane [12 days 21 hours and 14 minutes ago]

Wed, 8 Apr 2026 12:56:54 GMT

Hi(gh)!

Am 04.04.26 um 18:41 schrieb kurtz le pirate:

> I don't know if that's "chemically" correct.
> I've always been pretty bad at that stuff.
> 
> But I think it makes for a nice picture.

Cool! And now make a whole space elevator cable of that stuff!

See you in Khyberspace!

Yadgar

-- 
VBI BENE, IBI BACTRIA!

[Bald Eagle] Re: Arcade Control Box [12 days 21 hours and 16 minutes ago]

Wed, 8 Apr 2026 12:55:00 GMT

"Dave Blandston" <nomail@nomail> wrote:

Hi Dave,

> I'm currently working on programming a remake of the game Centipede

You're programming the whole game yourself?  :O
I remember trying to make my own version of Space Invaders on my Atari 800 XL.
I _may_ have programmed a toy version on an Arduino.

> so if I can
> find a local cabinet shop who's willing to do the woodwork for me I'll make a
> control box to go with it.

Could be pricey.
I'd be sorely tempted to make the prototype myself, since there's usually tweaks
and revisions that ought to be done before a professional charges you for
something you may need to modify anyway.

Also, since it's just a cabinet, you would likely be able to save a ton of money
and just build it yourself.  Paint and a fancy printed vinyl sticker can cover a
multitude of sins.

I don't know what it's like in your area, but people around here throw out
EVERYTHING.  You could probably find a curved-edge table top and a
particle-board table top or kitchen cabinet with that plastic edge spline that
fits in the wood (if you wanted that effect).  Free.
Then if it all works, and the test cabinet is to your satisfaction, you can hand
over the cabinet as a reference model along with your drawings so that they know
_exactly_ what you want.

Brandon Sander of YT channel Inheritence Machining seems to like:
https://sendcutsend.com/services/laser-cutting/

- BW

[Dave Blandston] Arcade Control Box [13 days 9 hours and 21 minutes ago]

Wed, 8 Apr 2026 00:50:00 GMT

It's always fun and helpful to make a POV model before beginning construction...

https://youtu.be/T_OfudwawnU

I'm currently working on programming a remake of the game Centipede so if I can
find a local cabinet shop who's willing to do the woodwork for me I'll make a
control box to go with it.

Have an awesome day everyone!

Kind regards,
Dave Blandston

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [13 days 15 hours and 6 minutes ago]

Tue, 7 Apr 2026 19:05:00 GMT

Also:

The original paper:
https://www.ams.org/notices/200304/fea-escher.pdf

https://www2.oberlin.edu/faculty/kwoods/talks/escher.pdf

http://roy.red/posts/droste/

[GioSeregni] Re: about #debug [13 days 21 hours and 21 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 [13 days 21 hours and 36 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

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [13 days 21 hours and 51 minutes ago]

Tue, 7 Apr 2026 12:20:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Yes, Bill - We've been here for a while now...

Yep - you for far longer than I.  ;)

> And you are right; I've been very busy the last years.
> Not much time to do POV-Ray work =(

That's life.  Work is work, and hobbies are hobbies.
We need clones. :D

> But you, IIRC, have always been - and still are - quite active in here.
> Very good!

Almost every day.  It keeps my mind active, and I just have all of the ideas
that I have to somehow meaningfully get out of my head.  That's why I appreciate
POV-Ray so much - it allows me to simultaneously document and create, and
explore things that a GUI modeler just can't do.

> - I couldn't resist exploring the "Droste Effect" in Escher's
> "Print Gallery" picture with POV-Ray. I've made some progress in
> achieving this in POV-Ray. I'll post some of my results here.

I've been meaning to explore it myself, since it touches on much of what I've
played with in terms of functions in the complex plane, geometric inversion,
procedural patterns, Doyle spirals, etc.

> "M.C. Escher: More Mathematics Than Meets the Eye" - By Sara Robinson
> https://im-possible.info/english/articles/escher_printgallery/index.html
>
> "A logarithmic image transformation" - by Jos Leys
> https://www.josleys.com/article_show.php?id=82
>
> As far as I can see, the page above has much the same contents as
> the document below. But Firefox and Edge do not try to render the
> jsMath formulas within it. The PDF file from the page below has the
> formulas rendered, but it's behind a pay wall.

Yes.  I found Jos' page as well, and the formulas wouldn't render for me either.
 I tried downloading jsMath and unzipping it (holy motherlode of files! :O ) but
I'm assuming I'm missing some key step in getting a browser to locate,
recognize, and use it.

I'd love to have some kind of math formula formatting suite of macros . . . cue
Project Number 4,597.

I have new internet arriving on Thursday, so I can continue with various
projects that are stalled due to connectivity.

Happy Easter - hope to "see" you again sometime soon.

- BE

[GioSeregni] Re: about #debug [13 days 23 hours and 1 minute 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 1 hour and 6 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 1 hour and 36 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 [14 days 2 hours and 36 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 [14 days 4 hours and 31 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

[Tor Olav Kristensen] Re: The macro scope / identifier / semicolon bug [14 days 10 hours and 26 minutes ago]

Mon, 6 Apr 2026 23:45:00 GMT

Yes, Bill - We've been here for a while now...

And you are right; I've been very busy the last years.
Not much time to do POV-Ray work =(
But you, IIRC, have always been - and still are - quite active in here.
Very good!

This Easter I've had some spare time. So, when you, in another post,
mentioned this recent 3Blue1Brown video for us (thank you btw.):

"How (and why) to take a logarithm of an image"
https://www.youtube.com/watch?v=ldxFjLJ3rVY&t=2462s

- I couldn't resist exploring the "Droste Effect" in Escher's
"Print Gallery" picture with POV-Ray. I've made some progress in
achieving this in POV-Ray. I'll post some of my results here.

Here are some other useful texts I've found regarding this topic:

"M.C. Escher: More Mathematics Than Meets the Eye" - By Sara Robinson
https://im-possible.info/english/articles/escher_printgallery/index.html

"A logarithmic image transformation" - by Jos Leys
https://www.josleys.com/article_show.php?id=82

As far as I can see, the page above has much the same contents as
the document below. But Firefox and Edge do not try to render the
jsMath formulas within it. The PDF file from the page below has the
formulas rendered, but it's behind a pay wall.

"The Droste effect image transformation" - by Jos Leys
https://www.sciencedirect.com/science/article/abs/pii/S0097849306002433

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

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi Tor!
>
> I've been bus reviewing all sorts of code, and that of course led me across all
> the different places that we've crossed paths.
> So I was literally just thinking about you for the past few days.
>
> I'm sure you're super busy as always, but hope that you get enough down-time to
> enjoy things.
>
> Thanks for that 26-year-old post. (!)
>
> What other dark secrets lay dormant in the POV-Ray parser, waiting to one day be
> awakened . . . ?
>
> - BE

[GioSeregni] Re: about #debug [14 days 15 hours and 16 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 [14 days 16 hours and 6 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 [14 days 16 hours and 36 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 [14 days 17 hours and 41 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 [14 days 18 hours and 11 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 [14 days 19 hours and 26 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 [14 days 20 hours and 1 minute 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 [14 days 20 hours and 11 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 [14 days 20 hours and 46 minutes 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 [14 days 20 hours and 51 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 [14 days 21 hours and 1 minute 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 [14 days 21 hours and 26 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: Nanotube breaking through the plane [14 days 21 hours and 36 minutes ago]

Mon, 6 Apr 2026 12:35:00 GMT

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

> I don't know if that's "chemically" correct.
> I've always been pretty bad at that stuff.

This should be chemically correct. *

* there is a certain strain energy that cannot be exceeded for stable molecules.
So, as long as your nanotube has a certain minimum radius, then it should be
fine.   That's not to say that they've actually made/discovered on of that exact
size, just that there's nothing obviously wrong with the theoretical structure.
Usually when making things like this, there are the fundamental thermodynamic
considerations (is it stable?) but there can be overriding kinetic realities
that control what actually happens. (Structure A is less stable but forms
faster, so it out-competes structure B and winds up unexpectedly being the major
reaction product.)

The only other thing that's "missing" is the filling of the empty valence
orbitals on those dangling edge carbons.   What is at the edge of a crystal?
This is where a lot of interesting research goes on in the field of surface
chemistry.
You could also likely terminate those sites with methyl groups, alkenes (double
bonds) or some sort of aldehyde, ketone, or carboxylic acid.

You can also "dope" nanotubes with small quantities of other elements to replace
some of the carbons - boron, nitrogen, silicon, ... to imbue them with various
useful properties.

- BE

[Bald Eagle] Re: about #debug [14 days 22 hours and 1 minute 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

[Alain Martel] Re: Nanotube breaking through the plane [15 days 19 hours and 30 minutes ago]

Sun, 5 Apr 2026 14:40:30 GMT

Le 2026-04-04 Ã  12:41, kurtz le pirate a Ã©critÂ :
> 
> Hello,
> 
> 
> My first attempt with nanotubes.
> 
> I don't know if that's "chemically" correct.
> I've always been pretty bad at that stuff.

That's pretty much the actual structure of a real nanotube.

> 
> But I think it makes for a nice picture.
> 

Agree.

> 
> 
> 
> Happy Easter weekend
>

[Ton] Re: Cutty Sark [16 days 9 hours and 6 minutes ago]

Sun, 5 Apr 2026 01:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Ton" <ton### [at] gmailcom> wrote:
> > One shroud done, two to go for the foremast.
> > Tedious work though!
>
> This is coming out great!
> It going to look fantastic once all the masts and sails are up.
>
> Thanks as always for providing regular updates.
>
> I'm curious about what you've learned, what methods/tools you've developed, if
> there's anything that would have made the modeling easier, and how many lines of
> code you have so far.
>
> - BE

Hello BE,
the wife and me were away for a week on Te Waipounamu, the South Island of New
Zealand. Visited Aoraki/Mount Cook National Park. Aoraki is the highest point of
New Zealand, just over 3700 meters.

Learning is hard to quantify. One of the things I would like to do is to have an
..inc file for every object, and then combine them into a higher include. So the
CuttySark.inc file includes Hull.inc, Deck.inc, Bowsprit.inc etc.
Hull.inc includes Keel.inc, Hullside.inc, Bulwark.inc etc.
Keel.inc #declares the keel.
This is to avoid include files with thousands of lines.
CuttySark.pov has all the povray related stuff like lighting, cameras, includes
the standard povray include files, and finally CuttySark.inc.
What I unfortunately still do is putting too much in one file. It is also
sometimes a bit hard to determine what goes where. If there is one small part,
used only in one include file, do you create a separate inc file or not?

My main tool is still good old kpovmodeler. It is not as smooth as Blender, but
it does the trick. I use it only for modeling the parts, so not the whole ship
in one go.

For the Cutty Sark there is plenty of information on the internet. Modelship
forums where people scratch build models of her are interesting to follow.
Drawings can be found, websites from Billing Boats, and Revell for instance,
have nice photos of their models, plus you can download the manuals, which also
give info.

I have about 17000 lines of code right now.
I am not sure about the sails. I think when I have the masts and all the
standing rigging done there will be some goodlooking steam screaming for
attention!

Cheers
Ton.

[tTh] Re: Nanotube breaking through the plane [16 days 13 hours and 20 minutes ago]

Sat, 4 Apr 2026 20:50:27 GMT

On 4/4/26 18:41, kurtz le pirate wrote:
> 
> Hello,
> 
> 
> My first attempt with nanotubes.
> 
> I don't know if that's "chemically" correct.
> I've always been pretty bad at that stuff.

    Is this a pure geometric abstraction or a model
    derived from real datas/formulas ?

> But I think it makes for a nice picture.

    Remember of an old experiment :)
           http://la.buvette.org/POV/FromOBJ/p/

    May be, I can revive this project one day or other ?

> Happy Easter weekend

    Thanks, I've got a nice sun over my home for this w-e.

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

[kurtz le pirate] Nanotube breaking through the plane [16 days 17 hours and 29 minutes ago]

Sat, 4 Apr 2026 16:41:13 GMT

Hello,


My first attempt with nanotubes.

I don't know if that's "chemically" correct.
I've always been pretty bad at that stuff.

But I think it makes for a nice picture.




Happy Easter weekend

-- 
kurtz le pirate
compagnie de la banquise

[Clarence1898] Re: can you help with how to best save the simul... [17 days 8 hours and 6 minutes ago]

Sat, 4 Apr 2026 02:05:00 GMT

"Cossack " <nomail@nomail> wrote:
> I just have a project in python where cubes fall, and I have options: 1. save
> each frame in .txt as a list. 2. (not very good) create a .pov file for each
> frame.
> which one to use?

The process I use to generate animations is similar to option 2.  I create a pov
file for each frame like this: file0000.pov, file0001.pov, file0002.pov etc.
Then I generate a list of commands: povray +Ifile0000.pov +Ofile0000.png <povray
options>; povray +Ifile0001.pov +Ofile0001.png <options>; etc. Then run that
file as a script.  I automatically generate the commands and the script so it
takes minimal effort to do.  The scripts run on either linux or windows wsl.
You could do it on just windows, but the commands will be a little different.
If you have multiple pcs you can distribute the commands across them.

[GioSeregni] Re: about #debug [17 days 12 hours and 41 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 [17 days 15 hours and 21 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 [17 days 15 hours and 26 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 [17 days 15 hours and 56 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 [17 days 18 hours and 16 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 [17 days 19 hours and 56 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 [17 days 22 hours and 6 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 and 21 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 [18 days 8 hours and 11 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 [18 days 13 hours and 13 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 [18 days 17 hours and 13 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 [19 days 1 hour and 46 minutes 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 [19 days 2 hours and 6 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!

[Bald Eagle] ISP Failure [19 days 22 hours and 1 minute ago]

Wed, 1 Apr 2026 12:10:00 GMT

Either my provider has completely dropped the ball,
or my router has finally died.

I may be getting new service or a new provider, but I will have no forum or
email access in the evening until the situation is rectified.

- BE

[Cousin Ricky] Re: There is no yellow in the circle [20 days 19 hours and 31 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 and 6 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 [21 days 17 hours and 11 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 [21 days 18 hours and 26 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 [21 days 20 hours and 50 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 [21 days 21 hours and 11 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 [22 days 15 hours and 11 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 [22 days 17 hours and 51 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 [22 days 18 hours and 1 minute 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 [22 days 19 hours and 56 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 [22 days 20 hours and 19 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 [22 days 20 hours and 56 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 [22 days 21 hours and 3 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 [22 days 23 hours and 21 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.

[ingo] Re: can you help with how to best save the simul... [23 days 1 hour and 26 minutes ago]

Sun, 29 Mar 2026 08:45:00 GMT

"Cossack " <nomail@nomail> wrote:
> I just have a project in python where cubes fall, and I have options: 1. save
> each frame in .txt as a list. 2. (not very good) create a .pov file for each
> frame.
> which one to use?

What I generally (try to) do:

create a base scene plus an .inc file,

have the program create .inc file content with only the variable data, loop
enrolled.

have the program call POV-Ray per frame.

if there is for example collision logic that you use `trace` for, have POV-Ray
write the data your program can uses. In this case that could be a .py with a
list you import in your python program.

ingo

[Cousin Ricky] SVG colors [23 days 9 hours and 23 minutes ago]

Sun, 29 Mar 2026 00:47:36 GMT

Looking at these color assignments, I am still convinced that the nerds
who came up with them were colorblind--or at least had only one X
chromosome.

(The stereotype of men seeing fewer colors than women has a kernel of
truth.  The genes that distinguish between red and green are on the X
chromosome, so if one of those genes goes bad in a chromosomal male,
there is no backup gene.  It's why men are red-green colorblind so much
more often than women.)

[jr] Re: can you help with how to best save the simul... [23 days 14 hours and 16 minutes ago]

Sat, 28 Mar 2026 19:55:00 GMT

hi,

"Cossack " <nomail@nomail> wrote:
> I just have a project in python where cubes fall, and I have options: 1. save
> each frame in .txt as a list. 2. (not very good) create a .pov file for each
> frame.
> which one to use?

for option (1) there'd be "supporting code" in form of my 'Filed()' macro; it
comes with documentation and animation examples.
<wiki.povray.org/content/User:Jr#SDL_code>

regards, jr.

[jr] Re: SVG Recognized colors [23 days 14 hours and 16 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.

[Cossack ] can you help with how to best save the simulatio... [23 days 14 hours and 26 minutes ago]

Sat, 28 Mar 2026 19:45:00 GMT

I just have a project in python where cubes fall, and I have options: 1. save
each frame in .txt as a list. 2. (not very good) create a .pov file for each
frame.
which one to use?

[kurtz le pirate] Re: SVG Recognized colors [23 days 17 hours and 18 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 [23 days 17 hours and 26 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 [23 days 18 hours and 16 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 [23 days 18 hours and 36 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 [23 days 19 hours and 26 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 [23 days 21 hours and 40 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 [23 days 21 hours and 46 minutes 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

[yesbird] Re: Shell from Metashape [23 days 22 hours and 2 minutes ago]

Sat, 28 Mar 2026 12:08:23 GMT

On 27/03/2026 05:46, Dave Blandston wrote:
> What an amazing technology! I especially enjoyed looking at the griffin - next
> best thing to being able to hold it and examine it!
>

Agree with you - this is digital magic, especially with VR headset.
Can't stop playing with it ).
-- 
YB

[jr] Re: SVG Recognized colors [23 days 23 hours and 36 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 and 12 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 [24 days 6 hours and 34 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 [24 days 8 hours and 41 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 [24 days 12 hours and 27 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 [24 days 13 hours and 36 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 [24 days 15 hours and 26 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 [24 days 15 hours and 26 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 [24 days 15 hours and 31 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 [24 days 16 hours and 40 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 [24 days 16 hours and 56 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 [24 days 17 hours and 16 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 [24 days 17 hours and 18 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 [24 days 18 hours and 16 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 [24 days 21 hours and 11 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 [24 days 21 hours and 33 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 [24 days 21 hours and 46 minutes 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 [24 days 23 hours and 42 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 [24 days 23 hours and 48 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 [25 days 4 hours and 36 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 [25 days 7 hours and 6 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

[Dave Blandston] Re: Shell from Metashape [25 days 7 hours and 21 minutes ago]

Fri, 27 Mar 2026 02:50:00 GMT

What an amazing technology! I especially enjoyed looking at the griffin - next
best thing to being able to hold it and examine it!

Kind regards,
Dave Blandston

[Cousin Ricky] Re: question about same code(?) and different re... [25 days 9 hours and 20 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 [25 days 9 hours and 48 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

[Bald Eagle] NAN math [25 days 10 hours and 56 minutes ago]

Thu, 26 Mar 2026 23:15:00 GMT

I've been working on making my vector arity macro robust, and I came across this
surprising fact while stress testing.

NAN is treated differently in the parser than in the function VM.

NAN equals - EVERYTHING in the parser.

NAN equals nothing, not even itself in the function VM.

So my IfNan () macro fails, but my IfNan () function works as expected.

I'll need to dig into this and see where in the source it goes wrong.

I also recall seeing a thread where people were playing with N/0, and I think
the parser biases that - probably because it allows certain code to keep going.

https://news.povray.org/44294a5a%241%40news.povray.org

- BE

[tTh] Re: Post something [25 days 14 hours and 44 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 [25 days 15 hours and 31 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 [25 days 16 hours and 1 minute 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 [25 days 16 hours and 46 minutes 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 [25 days 17 hours and 1 minute 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... [25 days 19 hours and 11 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 [25 days 19 hours and 21 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... [25 days 19 hours and 41 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 [25 days 20 hours and 21 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 [25 days 20 hours and 36 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 [25 days 20 hours and 41 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 [25 days 21 hours and 21 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 [25 days 21 hours and 30 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 [25 days 22 hours and 31 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 [25 days 23 hours and 8 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 [26 days 1 hour and 51 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 [26 days 12 hours and 6 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 [26 days 14 hours and 46 minutes 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

[Bald Eagle] A specific layered texture [26 days 15 hours and 31 minutes ago]

Wed, 25 Mar 2026 18:40:00 GMT

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

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

I'm wondering why.

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

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

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

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

Any examples / ideas?

- BE

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [26 days 15 hours and 41 minutes ago]

Wed, 25 Mar 2026 18:30:00 GMT

https://news.povray.org/6613cd42%241%40news.povray.org

"There are issues in all the recent parser variations with respect to
sometimes necessary, but missing semicolons. The yuqk fork has addressed
a few of them in its version of the parser, but certainly not all.

The worst cause flaky behavior during parsing without any notice
something has gone wrong."

[Ilya Razmanov] SVG Recognized colors [26 days 17 hours and 37 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 [26 days 17 hours and 56 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: v3.8b2. height_field input values at 0.0 not... [26 days 18 hours and 16 minutes ago]

Wed, 25 Mar 2026 15:55:00 GMT

And actually, there seems to be some potentially conflicting information in the
documentation.

https://wiki.povray.org/content/Documentation:Tutorial_Section_2.2
"For every position in POV-space, a pattern returns a float value in the range
from zero to one. Values outside the zero to one range are ignored."

Presumably if a pigment pattern was wrapped in a function, one could then have
access to the actual values emitted, and either graph them or just run tests to
detect the presence of values <0 or >1.

- BE

[Bald Eagle] Re: v3.8b2. height_field input values at 0.0 not... [26 days 18 hours and 26 minutes ago]

Wed, 25 Mar 2026 15:45:00 GMT

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

> Perhaps worth saying a little more than the above. Whether creating a
> height_field or internal image_map from a function in POV-Ray, any
> 'function return' values outside the [0-1] get 'wrapped' to a ramp wave
> as is the default with the majority of inbuilt patterns.
>
> So, function return values of:
> -0.1 --> 0.9
> -0.5 --> 0.5
> -0.9 --> 0.1.
> 1.1 --> 0.1
> 1.5 --> 0.5
> 1.9 --> 0.9

I will just point out that this is not currently documented anywhere.
https://wiki.povray.org/content/Reference:Maps
is blank.

If anyone wanted a quick 10-15 min project, writing a scene with a simple 0 --->
x color map and a loop, function, gradient pigment, or similar and showing that
the color_map value.x is modulo-wrapped would be great.
Numeric output via #debufg or file, or a graph showing Color.x would be nice.

- BE

[Bald Eagle] Re: Post something [26 days 20 hours and 16 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

[Bald Eagle] Re: Cutty Sark [26 days 20 hours and 31 minutes ago]

Wed, 25 Mar 2026 13:40:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> One shroud done, two to go for the foremast.
> Tedious work though!

This is coming out great!
It going to look fantastic once all the masts and sails are up.

Thanks as always for providing regular updates.

I'm curious about what you've learned, what methods/tools you've developed, if
there's anything that would have made the modeling easier, and how many lines of
code you have so far.

- BE

[MichaelJF] Re: My Chessboard [27 days 6 hours and 34 minutes ago]

Wed, 25 Mar 2026 03:36:32 GMT

Am 25.03.26 um 03:57 schrieb BulatMusin:
> "Gaf" <nomail@nomail> wrote:
>>
>>
>>
>> finished image.
>>
>> The original image was made to a speed contest with a 1 week deadline, so I
>>
>> knowledge) to make all the details perfect. On the chessboard you can see a
>>
>>
>> You can find the source code below (with Hungarian comments):
>>
>> www.raytracer.hu/temp/chess.pov
>>
>>
>> it I hope it can be interesting for someone.
>>
>> Warp, congratulations for your chess-image, very nice work.
>>
>> Gaf
> 
> 
> Hi,
> 
> It seems this post is broken, and the link www.raytracer.hu/temp/chess.pov is
> not available!
> 
> But, really, the scene is very interesting!
> 
> Thanks.
> 
> Sincerely,
> Bulat.
> 
> 
The code can still be found on the Internet Archive. However, the 
texture images (table top, background, chessboard) are missing. If you 
replace these, it can be rendered using POV 3.8.

https://web.archive.org/web/20160930144425/www.raytracer.hu/temp/chess.pov

Best regards
Michael

[BulatMusin] Re: My Chessboard [27 days 7 hours and 11 minutes ago]

Wed, 25 Mar 2026 03:00:00 GMT

"Gaf" <nomail@nomail> wrote:
>
>
>
> finished image.
>
> The original image was made to a speed contest with a 1 week deadline, so I
>
> knowledge) to make all the details perfect. On the chessboard you can see a
>
>
> You can find the source code below (with Hungarian comments):
>
> www.raytracer.hu/temp/chess.pov
>
>
> it I hope it can be interesting for someone.
>
> Warp, congratulations for your chess-image, very nice work.
>
> Gaf


Hi,

It seems this post is broken, and the link www.raytracer.hu/temp/chess.pov is
not available!

But, really, the scene is very interesting!

Thanks.

Sincerely,
Bulat.

[BulatMusin] Re: My Chessboard [27 days 7 hours and 21 minutes ago]

Wed, 25 Mar 2026 02:50:00 GMT

"fidos" <fid### [at] wanadoofr> wrote:
> "fidos" <fid### [at] wanadoofr> wrote:
> > Hello,
> >
> > A test with MCPov 0.0.5 of the wonderfull scene of Gaf and with impovements of
> > alphaQuad.
> >
> > Regards,
> > Fidos.
>
> And the source of the scene.


Hi,

Is that code w/o MC for POV-Ray 3.7 available?

Thanks.

Sincerely,
Bulat.

[Ton] Re: Cutty Sark [27 days 9 hours and 46 minutes ago]

Wed, 25 Mar 2026 00:25:00 GMT

One shroud done, two to go for the foremast.
Tedious work though!

Cheers
Ton

[laser] Re: Post something [27 days 11 hours and 36 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 [27 days 18 hours and 6 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.

[Bald Eagle] Re: 3.8 macro parsing errors [27 days 19 hours and 26 minutes ago]

Tue, 24 Mar 2026 14:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Works pretty nice!  :)
>
> Any way to force str to prepend the + sign to +inf?
>
> val ("+inf")  =                 inf
> val ("-inf")  =                -inf
> val ("+nan")  =                 nan
> val ("-nan")  =                -nan
> val (1.0123")  = 1.01229999999999998
> val (1.01 23") = 1.01000000000000001
> val ("inf")   =                 inf
> =============================================
> Val1 = -1.00000000
> Val2 = 1.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = 0.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = -1.00000000
> Val1 = Val2
>
> Val1 = 0.00000000
> Val2 = 0.00000000
> Val1 = Val2
>
> Val1 = 1.00000000
> Val2 = 1.00000000
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2               <--- Oooh, nice.
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = nan
> Val2 = inf               <--- possibly good, possibly bad.
> Val1 = Val2

If anyone's up for writing some SDL, (I'm stuck here for the next 5h)
I need reliable ways to detect +/- inf and +/- nan.
In the #if MyVal = val("inf") sort of way.
^^^
That doesn't need to be the exact implementation, I just need the equivalent
that yields the correct Boolean result.

Square it, multiply it by zero, by -1, test equality to itself, subtract it from
itself, add it to itself, abs(), .... whatever works to
_differentiate inf and nan from the real numbers_.

Thanks!

- BE

[jr] Re: Animation feature request. [28 days 1 hour and 1 minute 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. [28 days 8 hours and 21 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

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [28 days 11 hours and 11 minutes ago]

Mon, 23 Mar 2026 23:00:00 GMT

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

> > I noticed that the parser allowed and didn't complain about:
> > #local in2 = #local Result = {EcResult [2], EcResult [4]};
> > So who know what other wacky constructs it will let slip through.
>
> not that one[*], beta.2 says:
>
> Parse Error: Expected 'RValue to declare', { found instead
>
> same with parentheses (tried supplying a "tuple" instead).
>
> [*] replaced the 'EcResult's with '123.456' and '789.012'.

On 3.7 or 3.8?
Because remember, clipka was playing around with a LOT of parser stuff during
that time, adding and then rolling back. IIRC, that's when I started noticing it
more.

Also, thanks for running the test(s).

- BE

[jr] Re: The macro scope / identifier / semicolon bug [28 days 11 hours and 41 minutes ago]

Mon, 23 Mar 2026 22:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, jr has mentioned various thing about my semicolon usage.
> I noticed upon review that I can successfully assign an array without a
> semicolon, and then it's only the subsequent array that triggers the error when
> it doesn't have a semicolon.

_can_ because the parser is "forgiving", but relying on .. a quirk ?

"Note: There should be a semi-colon after the expression in all float,vector and
color identifier declarations."
<wiki.povray.org/content/Reference:Declare_and_Local_Directives#Declaring_identifiers>


> ...
> I noticed that the parser allowed and didn't complain about:
> #local in2 = #local Result = {EcResult [2], EcResult [4]};
> So who know what other wacky constructs it will let slip through.

not that one[*], beta.2 says:

Parse Error: Expected 'RValue to declare', { found instead

same with parentheses (tried supplying a "tuple" instead).

[*] replaced the 'EcResult's with '123.456' and '789.012'.


regards, jr.

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [28 days 12 hours and 6 minutes ago]

Mon, 23 Mar 2026 22:05:00 GMT

Now, jr has mentioned various thing about my semicolon usage.
I noticed upon review that I can successfully assign an array without a
semicolon, and then it's only the subsequent array that triggers the error when
it doesn't have a semicolon.

So I'm thinking that it might be partially about the semicolon, but also that
the parser allows "tandem assignments" through without raising any kind of
warning or error.

See:

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

I noticed that the parser allowed and didn't complain about:

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

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

- BE

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [28 days 12 hours and 21 minutes ago]

Mon, 23 Mar 2026 21:50:00 GMT

Which is the same macro construct as the following:

// ------------------ Scalar failure ---------------------------
#macro BugScalar(A,B,X)
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
#end

#local S_FAIL = BugScalar(0.1,0.2,T);   // âscalar failure

// ------------------ Vector failure ---------------------------
#macro BugVector(X)
    #if (X < 0.5)
        <1,0,0>
    #else
        <0,1,0>
    #end
#end

#local V_FAIL = BugVector(T);           // âvector failure

However this works:
#macro Test (N)
 0
#end
#local Val = Test (1);

and (provisionally)

#macro Test (N)
    #if (N < 1)
        #local Result = 0;
    #else
        #local Result = 1;
    #end
    Result
#end

#local Val = Test (1);

Also, as Mr. Callwood advised in an older thread,
wrapping the internals of the macro in parentheses allows successful evaluation:

#macro BugScalar(A,B,X)
(
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
)
#end

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [28 days 12 hours and 41 minutes ago]

Mon, 23 Mar 2026 21:30:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Hi Bill
>
> Some posts in this old thread, ... may
> also be relevant:


This one too:

https://news.povray.org/povray.general/thread/%3Cweb.63cc2badcc2a7a8c1742c61c57ffd389%40news.povray.org%3E/?ttop=446984
&toff=200

[jr] Re: Post something [28 days 13 hours and 41 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 [28 days 15 hours and 41 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 [28 days 16 hours and 26 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 [28 days 18 hours and 56 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. [28 days 20 hours and 26 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. [28 days 23 hours and 16 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. [28 days 23 hours and 26 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 1 hour and 16 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. [29 days 2 hours and 41 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. [29 days 8 hours and 21 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 [29 days 10 hours and 41 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 [29 days 12 hours and 56 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}

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [29 days 13 hours and 6 minutes ago]

Sun, 22 Mar 2026 21:05:00 GMT

Hi Tor!

I've been bus reviewing all sorts of code, and that of course led me across all
the different places that we've crossed paths.
So I was literally just thinking about you for the past few days.

I'm sure you're super busy as always, but hope that you get enough down-time to
enjoy things.

Thanks for that 26-year-old post. (!)

What other dark secrets lay dormant in the POV-Ray parser, waiting to one day be
awakened . . . ?

- BE

[Tor Olav Kristensen] Re: The macro scope / identifier / semicolon bug [29 days 15 hours and 31 minutes ago]

Sun, 22 Mar 2026 18:40:00 GMT

Hi Bill

Some posts in this old thread, started March 28th 2000 by Sigmund Kyrre Aas, may
also be relevant:

Newsgroup: povray.advanced-users
Subject: Re: Macros acting strange

https://news.povray.org/povray.advanced-users/thread/%3C38E10B3A.7C6D3308%40stud.ntnu.no%3E/?mtop=61708&moff=4

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

[jr] Re: Post something [29 days 16 hours and 26 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 1 hour and 21 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. [30 days 2 hours and 11 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 [30 days 16 hours and 6 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... [30 days 17 hours and 41 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... [30 days 18 hours and 16 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... [30 days 18 hours and 32 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 [30 days 19 hours and 31 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 [30 days 19 hours and 51 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 [30 days 20 hours and 11 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 [30 days 20 hours and 31 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. [30 days 20 hours and 41 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. [30 days 21 hours and 31 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 [31 days 6 hours and 40 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. [31 days 6 hours and 41 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 [31 days 10 hours and 6 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 [31 days 10 hours and 46 minutes 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... [31 days 16 hours and 11 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... [31 days 16 hours and 31 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... [31 days 17 hours and 21 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...

[jr] Re: Shell from Metashape [31 days 18 hours and 16 minutes ago]

Fri, 20 Mar 2026 15:55:00 GMT

hi,

yesbird wrote:
> This is a scene with shell geometry and set of materials for those who
> want to render it better:
> https://drive.google.com/file/d/1Fh8nRaxaCYb1R-4NdrkrCETzzPKPMvZF/view?usp=sharing

thanks, 81M "data" </grin>.  lovely object.


regards, jr.

[Bald Eagle] Re: question about same code(?) and different re... [31 days 21 hours and 56 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 [32 days 6 hours and 36 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!

[Bald Eagle] Re: The macro scope / identifier / semicolon bug [32 days 14 hours and 21 minutes ago]

Thu, 19 Mar 2026 19:50:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:

> This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
> someone said that the macros are not true C or C++ macros. So I just learn to
> accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
> see no harm.
>
> Have Fun!

Well the issue is that sometimes it shows up and sometimes it doesn't.
And that has caused issues where previously working scenes suddenly didn't work
anymore.
And the intermittent appearance makes debugging a nightmare.

Providing a "minimal scene that reproduces the error" is either impossible, or
the bug doesn't show up when run on someone else's system.

Also, writing:

#macro (Argument)
....
a bunch of povray code
....
#local Result = (my final calculation)

Result

#end

just gives a clean, easily followed logic, since you know that the macro emits
"Result" when exiting.

It used to work just fine, or at least very very often, and then something got
changed and it's a 50/50 shot whether or not the parser wants to let it work or
not - which is not something that I want to be fussing with when trying to write
1000 lines of complicated SDL.

So a solid, reliable fix would be well worth it if the source code edit is
fairly simple.

- BE

[Leroy] Re: The macro scope / identifier / semicolon bug [32 days 14 hours and 41 minutes ago]

Thu, 19 Mar 2026 19:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've run into the issue where assigning the final value(s) of a macro to an
> indentifier such as "Result" and then having the final line of the macro be:
> Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
> error.
> I'm hoping that this might help WFP fix this in the yuqk fork, identify where
> things went off the rails between earlier versions and 3.7/3.8, and propose a
> robust fix for this long-standing and really annoying bug that can nearly drive
> one insane.
>
This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
someone said that the macros are not true C or C++ macros. So I just learn to
accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
see no harm.

Have Fun!

[jr] Re: The macro scope / identifier / semicolon bug [32 days 16 hours and 36 minutes ago]

Thu, 19 Mar 2026 17:35:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've run into the issue where assigning the final value(s) of a macro to an
> indentifier such as "Result" and then having the final line of the macro be:
> Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
> error.
> ...
> The idiom:
>
> ```pov
> #macro Foo()
>     #local Result = 1 + 2;
>     Result
> #end
>
> #local X = Foo();
> ```
>
> After macro expansion, the parser sees:
>
> ```pov
> #local X = 1 + 2
> ```

really ?  would it not "see":
  #local X = 3

anyway, that is as far as I could read the .. generated content.


regards, jr.

[Bald Eagle] The macro scope / identifier / semicolon bug [32 days 18 hours and 1 minute ago]

Thu, 19 Mar 2026 16:10:00 GMT

I've run into the issue where assigning the final value(s) of a macro to an
indentifier such as "Result" and then having the final line of the macro be:
Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
error.
I'm hoping that this might help WFP fix this in the yuqk fork, identify where
things went off the rails between earlier versions and 3.7/3.8, and propose a
robust fix for this long-standing and really annoying bug that can nearly drive
one insane.

"povray has a bug in the way macros work.  A typical way of using a macro is to
use #local to assign a value to an identifier such as "Result", and then have
the identifier be a standalone line at the end of the macro to "export" Result.
 However this often raises an error that Result is undefined.  adding a
semicolon after Result sometimes fixes this behaviour, but then the assignment
using the macro call needs to have its semicolon removed, otherwise the parsers
complains that there is an extra semicolon.  Emitting the raw value from the
macro without assigning it to Result seems to work fine.  Can you look at the
povray code base and see what causes this bug?
https://github.com/POV-Ray/povray"

Short answer: this isn’t a “random macro bug” so much as a **quirk (and
design
limitation) of POV‑Ray’s macro substitution combined with its parser’s
statement/semicolon handling**. When you look at the codebase, the behavior
you’re seeing falls out quite directly from how macro expansion is implemented,
especially in the parser and symbol-table logic.

---

## 1. What macros actually are in POV‑Ray (per the code)

From the documentation and the code, a **POV‑Ray macro is pure textual
substitution at parse time**, not a function with a return value.

When a macro is invoked:

1. A new local symbol table is pushed.
2. The macro body tokens are **spliced verbatim** into the token stream.
3. The parser continues as if the macro body had literally been typed there.
4. At `#end`, all local identifiers are destroyed and parsing resumes.

This behavior is explicitly described in the docs and is reflected in the parser
implementation (`parser.cpp`, `parser_macros`, `SymbolStack`).

---

## 2. Why the “`Result` at the end of a macro” is fragile

The idiom:

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result
#end

#local X = Foo();
```

*looks* reasonable, but here’s what actually happens.

After macro expansion, the parser sees:

```pov
#local X = 1 + 2
```

or sometimes (depending on tokens):

```pov
#local X = Result
```

### Why that breaks

* `Result` is **local to the macro’s symbol table**
* As soon as `#end` is processed, `Result` is destroyed
* The parser may still be in the middle of parsing the surrounding statement
(`#local X = ...`)

So when the parser tries to resolve `Result` **after macro expansion**, the
symbol table no longer contains it → **“identifier undefined”**

---

## 3. Why adding or removing semicolons changes the behavior

This is the part that *feels* like a bug.

### Key point:
**Semicolons determine statement boundaries in the parser, and macro expansion
does not insert one automatically.**

From the POV‑Ray reference:

> All #declare/#local of float, vector, and color require a semicolon in 3.5+; missing
semicolons can cause macros to m
isbehave.

Now consider these two cases.

---

### Case A: No semicolon on the final `Result`

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result
#end

#local X = Foo();
```

After expansion:

```pov
#local X = Result
;
```

The parser:

* Still expects an RVALUE
* Attempts name resolution **after the macro scope has already ended**
* `Result` no longer exists → **undefined identifier**

---

### Case B: Semicolon inside the macro

```pov
#macro Foo()
    #local Result = 1 + 2;
    Result;
#end
```

Now the macro expands to **a complete statement**:

```pov
Result;
```

But when invoked as:

```pov
#local X = Foo();
```

You effectively get:

```pov
#local X = Result;;   // ← double semicolon
```

Hence the “extra semicolon” error.

---

## 4. Why “emitting the raw value” works reliably

This version:

```pov
#macro Foo()
    (1 + 2)
#end
```

works because:

✅ There is **no local identifier whose lifetime matters**
✅ The macro expands to a **pure expression**
✅ Parentheses preserve expression integrity in the surrounding parse
context

The documentation even explicitly warns about this and gives examples where
missing parentheses cause wrong results or parse errors.

---

## 5. What the codebase shows (important)

From the parser design (see `parser.cpp`, `parser_expressions.cpp`, `parser.h`):

* Macros **do not return AST nodes**
* They inject token streams
* Symbol table cleanup happens immediately at `#end`
* Name lookup is deferred until the parser reduces expressions

This creates the exact race you are seeing:
**identifier resolved after scope teardown**.

---

## 6. Is it officially a bug?

Historically: **no**.
Practically: **yes, but entrenched**.

The core team considers this:

* a documented limitation
* consistent with “macro = text substitution”

That’s why:
* docs recommend expression‑only macros
* examples always wrap return values in parentheses
* “return via local variable” is rarely shown in modern docs

---

## 7. Best practices (based on parser reality)

✅ **Correct / robust**
```pov
#macro Foo(A,B)
    ((A + B) / 2)
#end

#local X = Foo(3,5);
```

✅ **Also acceptable**
```pov
#macro Foo(A,B)
    #local R = (A + B) / 2;
    (R)
#end
```

🚫 **Fragile / not recommended**
```pov
#macro Foo()
    #local Result = 42;
    Result
#end
```

---

## 8. Bottom line

What you’re seeing is caused by:

* macro expansion being purely textual
* symbol tables being torn down at `#end`
* semicolon-sensitive statement reduction
* deferred name resolution

It *looks* nondeterministic, but it’s actually a deterministic parse‑order
artifact.

---

Below are the **exact, concrete locations in `parser.cpp` (and closely related
parser code) that together *cause* the macro/`#local Result` behavior you
described**. I’ll give you **line‑precise excerpts**, explain what each
one does, and tie them directly to the failure mode.

---

# 1. Macro invocation creates a **temporary local symbol table**

### File
`source/parser/parser.cpp`

### Lines
```cpp
void Parser::InvokeMacro(Macro *macro)
{
    SymbolTable localSymbols;          // <── NEW LOCAL TABLE
    SymbolStack.Push(&localSymbols);   // <── PUSHED ON ENTRY
```

---

# 2. The macro body is parsed as raw tokens (not an expression)

```cpp
    ParseTokenStream(macro->bodyTokens);
```

---

# 3. The macro scope is destroyed **immediately at `#end`**

```cpp
    SymbolStack.Pop();                 // <── LOCAL SYMBOLS
DESTROYED
}
```

---

# 4. Identifier lookup happens **after** macro expansion

### File
`source/parser/parser_expressions.cpp`

```cpp
for (int i = SymbolStack.GetDepth() - 1; i >= 0; i--)
{
    sym = SymbolStack.GetTable(i)->Lookup(Name);
    if (sym != nullptr)
        return sym;
}
```

---

# 5. Why semicolons change behavior (statement termination)

```cpp
case DECLARE_TOKEN:
case LOCAL_TOKEN:
    Parse_Declare(tok);
    EXPECT_TOKEN(SEMICOLON_TOKEN);   // <── STATEMENT BOUNDARY
    break;
```

---

# 6. Why “emit the raw value” always works

Because this path bypasses **every problematic codepath above**:

* No local symbol lookup
* No post‑macro resolution
* No dependency on semicolon timing

---

# Proposed Fix

## Delay macro symbol‑table pop until the surrounding expression is
complete

### Proposed change

```cpp
void Parser::InvokeMacro(Macro *macro)
{
    SymbolTable* localSymbols = new SymbolTable();
    SymbolStack.Push(localSymbols);

    ParseTokenStream(macro->bodyTokens);

    if (ExpressionNestingDepth == 0)
    {
        SymbolStack.Pop();
        delete localSymbols;
    }
    else
    {
        DeferredMacroScopes.push_back(localSymbols);
    }
}
```

```cpp
void Parser::EndExpression()
{
    ExpressionNestingDepth--;

    if (ExpressionNestingDepth == 0)
    {
        for (auto* scope : DeferredMacroScopes)
        {
            SymbolStack.Pop();
            delete scope;
        }
        DeferredMacroScopes.clear();
    }
}
```

---

# Recommendation

Implement delayed macro‑scope popping tied to expression lifetime.

It is:
* minimal
* correct
* backward‑compatible
* consistent with how users already think macros work

[Mr] Re: my first normal job [32 days 20 hours and 1 minute ago]

Thu, 19 Mar 2026 14:10:00 GMT

"Cossack " <nomail@nomail> wrote:
> "Mister" <m*****r******at_hotmail_dot_fr> wrote:
> > "Kozak" <nomail@nomail> wrote:
> > > "Kozak" <nomail@nomail> wrote:
> > > > here is the result from my phone
> > >
> > > that's better
> >
> > Hello, did you use Termux? or the Linux terminal from Google Pixel
> > Android15+?
>
> I use termux and my device is installed Samsung Android version 14+.
> and thank you for your attention :]

I think it's great to push advertise as much as possible this use of POV. It's
such a unique feature in the 3D world that could bring to it the many new
developers it needs !

Companions to this found so far are Vim for android, as it has great syntax
highlighting, also all the web based guis for POV such as Yes bird's and the web
version of Wings3d and ngplant. All tutorials you can make for this already have
a space in the official POV wiki as they can do great good to this community.

[yesbird] Shell from Metashape [33 days 8 hours and 59 minutes ago]

Thu, 19 Mar 2026 01:11:39 GMT

This is a scene with shell geometry and set of materials for those who
want to render it better:
https://drive.google.com/file/d/1Fh8nRaxaCYb1R-4NdrkrCETzzPKPMvZF/view?usp=sharing 

--
YB

[yesbird] Re: Shell from Metashape [33 days 16 hours and 46 minutes ago]

Wed, 18 Mar 2026 17:24:20 GMT

On 18/03/2026 20:04, yesbird wrote:

Online WebGL model which I am coloring now is here:
https://galleries.yesbird.online/vr/?id=22
-- 
YB

[yesbird] Re: Star catalogue [33 days 16 hours and 54 minutes ago]

Wed, 18 Mar 2026 17:16:19 GMT

On 17/03/2026 21:36, Leroy wrote:
> Second Try! I tried to post these a few days ago and it didn't take!?
> Making spaceships take time, here's one I make a while back base on futurama.
> Because every needs a spaceship!

Nice !
I like it, especially his sinusoidal manner to move, would like to have
the same.
--
YB

[yesbird] Shell from Metashape [33 days 17 hours and 6 minutes ago]

Wed, 18 Mar 2026 17:04:46 GMT

Greetings !

I made this shell model with "Metashape" photogrammetry software
(see screenshot), processed geometry with Z-Brush to emphasize relief
by color and rendered with POV-Ray after POV-Ray studio conversion.

There was no any textures in this process, all color information
stored in 504550 vertices. Material and lighting could be improved,
but geometry looks exactly how I was expected.
-- 
YB

[Clarence1898] Re: Orrery WIP [34 days 12 hours and 51 minutes ago]

Tue, 17 Mar 2026 21:20:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Clarence1898" <dle### [at] comcastnet> wrote:
> > > This is a project I started over 20 years ago by modeling an orrery.
> >
> > And you're still at it!  Good work.
> >
> > It's been a long time since I've seen one of these classic animations.
> >
> > >Then had
> > > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > > looping on in your player.  I would get stuck on it, or real life interrupted,
> > > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > > camera flies through, not enough turbulence.
> >
> > Clouds are notoriously difficult.
> >
> > >There is also some flickering I
> > > haven't been able to get rid of.
> >
> > I didn't really notice anything, so it must be a very small problem.
> >
> > >The camera has a couple of abrupt moves I need
> > > to smooth out.
> >
> > When you're about to make a sharp turn, slow down the camera dramatically.
> > Look into "smoothing functions" to get the sort of thing you want.
> >
> > >I do plan to add more objects to the scene.  Any comments or
> > > suggestions would be welcome.
> >
> > I like the island a LOT.
> > The house, the working lighthouse (make the light MUCH brighter), the ceiling
> > fan, the periodic table, the stencil on the desk....
> >
> > The orrery sun could be a bit brighter/yellower.
> >
> > I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
> > nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
> > graphics models, or someone else's POV-Ray model/effect into a scene.
> >
> > If you hit any more stumbling blocks, don't be afraid to ask for ideas or
> > solutions.  Set your goal on the finish line!
> >
> > - BE
>
> Thank you for the suggestions.  I made a few changes and reposted a new
> animation.  The flickering is much more noticeable at higher resolutions, I
> rendered the animation at 1280x720 then reduced it to 640x360 to get the size
> down for posting.  The planet maps came from a NASA web site, I picked a new sun
> that is brighter and yellower.  It does look better.  The checkered bed was a
> nod to the RSOCP, but the pillow reflects the creme colored walls not the bed
> and it almost looks translucent not reflective.  At the time I created the
> lighthouse I didn't know the color rgb values could be greater than 1.0.  I
> increased the value and it looks much better.  I wrote a program to generate the
> island,  started with a pyramid and recursively divided the faces into smaller
> triangles and translating the vertices a random amount up or down and then
> created a mesh2 object.  I then populated the island with 24000 trees and 32000
> bushes that were created by Arbaro 2.0.  Now I need to work on the camera
> transitions.

In trying to reduce the flicker, I rendered at 3840x2160 then scaled it down to
640x360.  It didn't eliminate all the flickering but did reduce it a lot.  That
cut the size down from 42MB to a more reasonable 3.4MB.  I was also able to
smooth the transition when the camera entered earth orbit.  Still not completely
happy with it, but I think its looking better.

[jr] Re: Star catalogue [34 days 13 hours and 16 minutes ago]

Tue, 17 Mar 2026 20:55:00 GMT

hi,

"Leroy" <whe### [at] gmailcom> wrote:
> "Maetes" <nomail@nomail> wrote:
> > That's the damn reason why I don't have time to build damn spaceships.
> > :)
> > Ma
> Second Try! I tried to post these a few days ago and it didn't take!?
> Making spaceships take time, here's one I make a while back base on futurama.

time well spent, thanks.  Fry used to call ideas "headaches with pictures"..


> Because every needs a spaceship!

yes, see attached ;-)


regards, jr.

[Clarence1898] Re: POV Server go down? [34 days 14 hours and 51 minutes ago]

Tue, 17 Mar 2026 19:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
>
> > From central Indiana and haven't been able to login since Thursday.  I tried
> > Firefox, Google, Edge on my pc and Safari on my phone.  Even a ping would time
> > out.  Didn't have any problem with other sites.
>
> I'm curious:
>
> Have you tried accessing the site using a web proxy service, or a newsreader
> like Thunderbird?
>
> Also, how are you accessing it just now?
>
> - BE

Earlier today I was able to access from my phone, so when I got home I tried
from my pc and was successful.  I have no idea what happened but from Thursday
through Monday it timed out.

[Leroy] Re: Star catalogue [34 days 15 hours and 31 minutes ago]

Tue, 17 Mar 2026 18:40:00 GMT

"Maetes" <nomail@nomail> wrote:
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

Second Try! I tried to post these a few days ago and it didn't take!?
Making spaceships take time, here's one I make a while back base on futurama.
Because every needs a spaceship!

[Leroy] Re: POV Server go down? [34 days 15 hours and 56 minutes ago]

Tue, 17 Mar 2026 18:15:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
>
> From central Indiana and haven't been able to login since Thursday.  I tried
> Firefox, Google, Edge on my pc and Safari on my phone.  Even a ping would time
> out.  Didn't have any problem with other sites.

I'm back(3/17/26) 2 days in a row! :) I think it was relay router(or what ever
the f??? you call it) See Chris Cason's post for more about the matter.

Have Fun!

[Bald Eagle] Re: POV Server go down? [34 days 16 hours and 1 minute ago]

Tue, 17 Mar 2026 18:10:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:

> From central Indiana and haven't been able to login since Thursday.  I tried
> Firefox, Google, Edge on my pc and Safari on my phone.  Even a ping would time
> out.  Didn't have any problem with other sites.

I'm curious:

Have you tried accessing the site using a web proxy service, or a newsreader
like Thunderbird?

Also, how are you accessing it just now?

- BE

[Leroy] Re: povray.org and related sites unreachable to ... [34 days 16 hours and 16 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!

[Clarence1898] Re: POV Server go down? [34 days 17 hours and 36 minutes ago]

Tue, 17 Mar 2026 16:35:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> > Jim Henderson <nos### [at] nospamcom> wrote:
> > > On Wed, 11 Mar 2026 16:24:56 EDT, Leroy wrote:
> > >
> > > > I made a video yesterday and went to post it here and got the warning
> > > > 'Server not found'. I'm in the US (Joplin Missouri for sure) and was
> > > > wandering was the problem POV's server or mine!
> > >
> > > It seems you were able to post this message from the web interface....So
> > > it's unclear where you were trying to post from (I thought I might try to
> > > duplicate the issue myself).
> > >
> > > I see a binary post in povray.binaries.animations dated today, so it seems
> > > to be OK.  But as the news server stores both text and binary files, it
> > > shouldn't have kicked an error when trying to upload if text can be
> > > posted.
> > >
> > >
> > >
> > > --
> > > "I learned long ago, never to wrestle with a pig. You get dirty, and
> > > besides, the pig likes it." - George Bernard Shaw
> >
> > This site wouldn't even load!? Several other sites wouldn't load either. As I
> > don't have any idea who services who, I didn't know if a major server when down
> > or not. It was gone only for a day, But my imagination may have work over time
> > on what could have gone wrong. Maybe AI has decided that half the work doesn't
> > need POV. Maybe the Russians nuked something, or the middle east targeted POV.
> > But I feel much better now!
>
> That was few days ago! I lost POV all day sunday. I keep getting 'Time Out'
> messages. Usually when I load POV it's on the screen before you know it. But
> yesterday it took a few minutes before the error happen. I have Firefox and
> there's a box at the bottom of the screen that show the website address that is
> trying to load. Pov address was there most of the time then something popped up
> like 'trying to load data from It.. .com'. It didn't stay on long enough for me
> to copy it down. So I thinking that the trouble is some where between here and
> there. At least I'm here today:)

From central Indiana and haven't been able to login since Thursday.  I tried
Firefox, Google, Edge on my pc and Safari on my phone.  Even a ping would time
out.  Didn't have any problem with other sites.

[LanuHum] Re: Help: The normal map is not working [34 days 17 hours and 51 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 and 8 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/

[Cossack ] Re: my first normal job [35 days and 31 minutes ago]

Tue, 17 Mar 2026 09:40:00 GMT

"Mister" <m*****r******at_hotmail_dot_fr> wrote:
> "Kozak" <nomail@nomail> wrote:
> > "Kozak" <nomail@nomail> wrote:
> > > here is the result from my phone
> >
> > that's better
>
> Hello, did you use Termux? or the Linux terminal from Google Pixel
> Android15+?

I use termux and my device is installed Samsung Android version 14+.
and thank you for your attention :]

[Dave Blandston] Re: RGB Rainbow Gradient [35 days 4 hours and 41 minutes ago]

Tue, 17 Mar 2026 05:30:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Very nice work!
>   If you want to get around the 3.7 color_map limit. Make an array of colors any
> size you want then cut the array into peaces that are under 3.7 limits. Make
> pigments with color_maps from those peaces with locations that match the
> original location values of a color_map with all the colors in it. Then make a
> pigment of all those pigments. Of course  All the pigment should use the same
> pattern!

Thank you Leroy, that's great advice!

Best regards,
Dave Blandston

[Leroy] Re: RGB Rainbow Gradient [35 days 10 hours and 56 minutes ago]

Mon, 16 Mar 2026 23:15:00 GMT

"Dave Blandston" <nomail@nomail> wrote:
> Greetings Folks,
>
> I'll share this here in case anyone ever finds it useful... The RGB rainbow
> gradient is useless for data visualization but it's still popular for artistic
> purposes. It has some limitations such as excessively bright points at the pure
> yellow, cyan, and purple points, visually unbalanced proportions of the base
> colors, and extreme differences in brightness values over the entire gradient
> with the blue area being most noticeably dim. Here's a version with non-linear
> transitions between the base colors that solves some of the problems. (The blue
> part is still dim compared to the rest of the colors.) It also introduces a new
> problem, which is that more transition points between the base colors are
> required. In my opinion, at least five transition points are necessary to
> achieve acceptable results. The maximum that POV-Ray 3.7 will allow is
> forty-three.
>
> Have an awesome day everyone!
>
> Kind regards,
> Dave Blandston
>
> * * * I hope this "copy-and-pastes" OK!
>
> #local NColorMapEntries = 7;
>
> #local ColorMapEntry = array [NColorMapEntries] {
>    <255, 0,   0  >, //0 Red
>    <255, 255, 0  >, //1 Yellow
>    <0,   255, 0  >, //2 Green
>    <0,   255, 255>, //3 Cyan
>    <0,   0,   255>, //4 Blue
>    <255, 0,   255>, //5 Purple
>    <255, 0,   0  >  //6 Red
> } //array
>
> #local NTransitionPoints = 43;
>
> #local RainbowGradient_NonLinear = texture {
>    pigment {
>       radial
>       color_map {
>          #for (I, 0, NColorMapEntries - 2)
>             #for (J, 0, NTransitionPoints - 2)
>                #local Ratio = J / (NTransitionPoints - 1); //0 .. 1
>                #switch (I)
>                   #case (0) //Red to yellow
>                      #local A = 270 + Ratio * 90; //Fast to slow
>                      #local Ratio = cos (radians (A)); //0 .. 1
>                   #break
>                   #case (1) //Yellow to green
>                      #local A = 180 + Ratio * 90; //Slow to fast
>                      #local Ratio = cos (radians (A)) + 1; //0 .. 1
>                   #break
>                   #case (2) //Green to cyan
>                      #local A = 270 + Ratio * 90; //Fast to slow
>                      #local Ratio = cos (radians (A)); //0 .. 1
>                   #break
>                   #case (3) //Cyan to blue
>                      #local A = 180 + Ratio * 90; //Slow to fast
>                      #local Ratio = cos (radians (A)) + 1; //0 .. 1
>                   #break
>                   #case (4) //Blue to purple
>                      #local A = 270 + Ratio * 90; //Fast to slow
>                      #local Ratio = cos (radians (A)); //0 .. 1
>                   #break
>                   #case (5) //Purple to red
>                      #local A = 180 + Ratio * 90; //Slow to fast
>                      #local Ratio = cos (radians (A)) + 1; //0 .. 1
>                   #break
>                #end //#switch
>                #local CurrentColor = ColorMapEntry [I] * (1 - Ratio) +
> ColorMapEntry [I + 1] * Ratio;
>                #local CurrentPoint = (I * NTransitionPoints + J) /
> ((NColorMapEntries - 1) * NTransitionPoints - 1);
>                [CurrentPoint color CurrentColor / 255]
>             #end //#for
>          #end //#for
>       } //color_map
>    } //pigment
>    rotate -90 * x
>    finish {emission .9}
> } //texture

Very nice work!
  If you want to get around the 3.7 color_map limit. Make an array of colors any
size you want then cut the array into peaces that are under 3.7 limits. Make
pigments with color_maps from those peaces with locations that match the
original location values of a color_map with all the colors in it. Then make a
pigment of all those pigments. Of course  All the pigment should use the same
pattern!
 I made a pigment with a 1000 colors as a test. I never did push the limit of
the number of colors. Now with 3.8 we wont need to :)

Have Fun!

[Leroy] Re: povray.org and related sites unreachable to ... [35 days 11 hours and 41 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!

[Leroy] Re: POV Server go down? [35 days 11 hours and 56 minutes ago]

Mon, 16 Mar 2026 22:15:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
> > On Wed, 11 Mar 2026 16:24:56 EDT, Leroy wrote:
> >
> > > I made a video yesterday and went to post it here and got the warning
> > > 'Server not found'. I'm in the US (Joplin Missouri for sure) and was
> > > wandering was the problem POV's server or mine!
> >
> > It seems you were able to post this message from the web interface....So
> > it's unclear where you were trying to post from (I thought I might try to
> > duplicate the issue myself).
> >
> > I see a binary post in povray.binaries.animations dated today, so it seems
> > to be OK.  But as the news server stores both text and binary files, it
> > shouldn't have kicked an error when trying to upload if text can be
> > posted.
> >
> >
> >
> > --
> > "I learned long ago, never to wrestle with a pig. You get dirty, and
> > besides, the pig likes it." - George Bernard Shaw
>
> This site wouldn't even load!? Several other sites wouldn't load either. As I
> don't have any idea who services who, I didn't know if a major server when down
> or not. It was gone only for a day, But my imagination may have work over time
> on what could have gone wrong. Maybe AI has decided that half the work doesn't
> need POV. Maybe the Russians nuked something, or the middle east targeted POV.
> But I feel much better now!

That was few days ago! I lost POV all day sunday. I keep getting 'Time Out'
messages. Usually when I load POV it's on the screen before you know it. But
yesterday it took a few minutes before the error happen. I have Firefox and
there's a box at the bottom of the screen that show the website address that is
trying to load. Pov address was there most of the time then something popped up
like 'trying to load data from It.. .com'. It didn't stay on long enough for me
to copy it down. So I thinking that the trouble is some where between here and
there. At least I'm here today:)

[Mr] Re: Help: How to create a bolt? [35 days 17 hours and 31 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!

[Mr] Re: my first normal job [35 days 17 hours and 36 minutes ago]

Mon, 16 Mar 2026 16:35:00 GMT

"Cossack " <nomail@nomail> wrote:
> "Cossack " <nomail@nomail> wrote:
> > here is the result from my phone
>
> this is better

Congratulations, Did you use Termux? or the Linux Terminal from Google Pixel's
Android15+ ?

[Bald Eagle] Re: Help: The normal map is not working [35 days 21 hours and 1 minute 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 [35 days 22 hours and 46 minutes 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 and 41 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.)

[Dave Blandston] RGB Rainbow Gradient [36 days 8 hours and 6 minutes ago]

Mon, 16 Mar 2026 02:05:00 GMT

Greetings Folks,

I'll share this here in case anyone ever finds it useful... The RGB rainbow
gradient is useless for data visualization but it's still popular for artistic
purposes. It has some limitations such as excessively bright points at the pure
yellow, cyan, and purple points, visually unbalanced proportions of the base
colors, and extreme differences in brightness values over the entire gradient
with the blue area being most noticeably dim. Here's a version with non-linear
transitions between the base colors that solves some of the problems. (The blue
part is still dim compared to the rest of the colors.) It also introduces a new
problem, which is that more transition points between the base colors are
required. In my opinion, at least five transition points are necessary to
achieve acceptable results. The maximum that POV-Ray 3.7 will allow is
forty-three.

Have an awesome day everyone!

Kind regards,
Dave Blandston

* * * I hope this "copy-and-pastes" OK!

#local NColorMapEntries = 7;

#local ColorMapEntry = array [NColorMapEntries] {
   <255, 0,   0  >, //0 Red
   <255, 255, 0  >, //1 Yellow
   <0,   255, 0  >, //2 Green
   <0,   255, 255>, //3 Cyan
   <0,   0,   255>, //4 Blue
   <255, 0,   255>, //5 Purple
   <255, 0,   0  >  //6 Red
} //array

#local NTransitionPoints = 43;

#local RainbowGradient_NonLinear = texture {
   pigment {
      radial
      color_map {
         #for (I, 0, NColorMapEntries - 2)
            #for (J, 0, NTransitionPoints - 2)
               #local Ratio = J / (NTransitionPoints - 1); //0 .. 1
               #switch (I)
                  #case (0) //Red to yellow
                     #local A = 270 + Ratio * 90; //Fast to slow
                     #local Ratio = cos (radians (A)); //0 .. 1
                  #break
                  #case (1) //Yellow to green
                     #local A = 180 + Ratio * 90; //Slow to fast
                     #local Ratio = cos (radians (A)) + 1; //0 .. 1
                  #break
                  #case (2) //Green to cyan
                     #local A = 270 + Ratio * 90; //Fast to slow
                     #local Ratio = cos (radians (A)); //0 .. 1
                  #break
                  #case (3) //Cyan to blue
                     #local A = 180 + Ratio * 90; //Slow to fast
                     #local Ratio = cos (radians (A)) + 1; //0 .. 1
                  #break
                  #case (4) //Blue to purple
                     #local A = 270 + Ratio * 90; //Fast to slow
                     #local Ratio = cos (radians (A)); //0 .. 1
                  #break
                  #case (5) //Purple to red
                     #local A = 180 + Ratio * 90; //Slow to fast
                     #local Ratio = cos (radians (A)) + 1; //0 .. 1
                  #break
               #end //#switch
               #local CurrentColor = ColorMapEntry [I] * (1 - Ratio) +
ColorMapEntry [I + 1] * Ratio;
               #local CurrentPoint = (I * NTransitionPoints + J) /
((NColorMapEntries - 1) * NTransitionPoints - 1);
               [CurrentPoint color CurrentColor / 255]
            #end //#for
         #end //#for
      } //color_map
   } //pigment
   rotate -90 * x
   finish {emission .9}
} //texture

[Chris Cason] Re: povray.org and related sites unreachable to ... [36 days 8 hours and 29 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 ... [36 days 20 hours and 11 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 ... [37 days 7 hours and 30 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 ... [37 days 11 hours and 16 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... [37 days 15 hours and 24 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 [37 days 16 hours and 1 minute 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 [37 days 21 hours and 41 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

[Cossack ] Re: my first normal job [38 days 1 hour and 1 minute ago]

Sat, 14 Mar 2026 09:10:00 GMT

"Cossack " <nomail@nomail> wrote:
> here is the result from my phone

this is better

[LanuHum] Help: The normal map is not working [38 days 5 hours and 6 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>
}

[Cossack ] my first normal job [38 days 14 hours and 46 minutes ago]

Fri, 13 Mar 2026 19:25:00 GMT

here is the result from my phone

[Jim Henderson] Re: POV Server go down? [39 days 15 hours and 37 minutes ago]

Thu, 12 Mar 2026 18:33:28 GMT

On Wed, 11 Mar 2026 21:16:06 EDT, Leroy wrote:

> This site wouldn't even load!? Several other sites wouldn't load either.
> As I don't have any idea who services who, I didn't know if a major
> server when down or not. It was gone only for a day, But my imagination
> may have work over time on what could have gone wrong. Maybe AI has
> decided that half the work doesn't need POV. Maybe the Russians nuked
> something, or the middle east targeted POV. But I feel much better now!

Could have been a temporary outage, but seems OK now. :)



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

[Bald Eagle] Re: POV Server go down? [39 days 23 hours and 26 minutes ago]

Thu, 12 Mar 2026 10:45:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> ... got the warning
> > > 'Server not found'.

> This site wouldn't even load!?

I got the same thing - it was for maybe 2-3h.
I posted something in the morning, and then went to post something or look
something up, and there was no povray.org

Assuming it was some sort of tech issue that was part of the server move.

- BE

[Leroy] Re: Star catalogue [40 days 8 hours and 41 minutes ago]

Thu, 12 Mar 2026 01:30:00 GMT

"Maetes" <nomail@nomail> wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array.
>
> Documented more thoroughly than I would like, took way too long, as always.
>
> A macro collection that makes use of it is in the works.
>
> See:
> https://www.maetes.com/en/download/hyg-lite-star-catalogue
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

I made a ship a long time ago for a Futurama like game. And the last line of
your post made think...
I'm to lazy to download your stuff and create a sky so I just use the picture
here.
Here it is the ship!

[Leroy] Re: POV Server go down? [40 days 8 hours and 51 minutes ago]

Thu, 12 Mar 2026 01:20:00 GMT

Jim Henderson <nos### [at] nospamcom> wrote:
> On Wed, 11 Mar 2026 16:24:56 EDT, Leroy wrote:
>
> > I made a video yesterday and went to post it here and got the warning
> > 'Server not found'. I'm in the US (Joplin Missouri for sure) and was
> > wandering was the problem POV's server or mine!
>
> It seems you were able to post this message from the web interface....So
> it's unclear where you were trying to post from (I thought I might try to
> duplicate the issue myself).
>
> I see a binary post in povray.binaries.animations dated today, so it seems
> to be OK.  But as the news server stores both text and binary files, it
> shouldn't have kicked an error when trying to upload if text can be
> posted.
>
>
>
> --
> "I learned long ago, never to wrestle with a pig. You get dirty, and
> besides, the pig likes it." - George Bernard Shaw

This site wouldn't even load!? Several other sites wouldn't load either. As I
don't have any idea who services who, I didn't know if a major server when down
or not. It was gone only for a day, But my imagination may have work over time
on what could have gone wrong. Maybe AI has decided that half the work doesn't
need POV. Maybe the Russians nuked something, or the middle east targeted POV.
But I feel much better now!

[Jim Henderson] Re: POV Server go down? [40 days 12 hours and 48 minutes ago]

Wed, 11 Mar 2026 21:22:13 GMT

On Wed, 11 Mar 2026 16:24:56 EDT, Leroy wrote:

> I made a video yesterday and went to post it here and got the warning
> 'Server not found'. I'm in the US (Joplin Missouri for sure) and was
> wandering was the problem POV's server or mine!

It seems you were able to post this message from the web interface....So 
it's unclear where you were trying to post from (I thought I might try to 
duplicate the issue myself).

I see a binary post in povray.binaries.animations dated today, so it seems 
to be OK.  But as the news server stores both text and binary files, it 
shouldn't have kicked an error when trying to upload if text can be 
posted.

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

[Leroy] Re: scheduled server down time [40 days 13 hours and 31 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?

[Leroy] POV Server go down? [40 days 13 hours and 41 minutes ago]

Wed, 11 Mar 2026 20:30:00 GMT

I made a video yesterday and went to post it here and got the warning 'Server
not found'. I'm in the US (Joplin Missouri for sure) and was wandering was the
problem POV's server or mine!

Having Fun?

[LanuHum] Re: Help: How to create a bolt? [40 days 16 hours and 46 minutes 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 [40 days 20 hours and 36 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? [41 days 12 hours and 41 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? [41 days 14 hours and 56 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? [41 days 15 hours and 6 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? [41 days 17 hours and 11 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? [41 days 17 hours and 36 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? [41 days 17 hours and 46 minutes 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? [41 days 18 hours and 11 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? [41 days 18 hours and 21 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: Jaime's bolts, post-processed [41 days 19 hours and 4 minutes ago]

Tue, 10 Mar 2026 15:06:29 GMT

On 2026-03-10 08:16 (-4), Mr wrote:
> 
> Interesting, the exposure looks slightly better despite a little too much
> opacity/uniform visibility of the starry streaks But what gets me curious is
> that the overexposed areas seem to have shifted towards the blue... did you
> initiate this on purpose? or is it something this macro would always do?

The overexposed areas were already bluish in Jaime's original.  The blue
is not evident in a PNG or JPEG render because of the overexposure, but
I post-processed an EXR render, which does record the overexposed color.

[Cousin Ricky] Re: Help: How to create a bolt? [41 days 19 hours and 16 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: Jaime's bolts, post-processed [41 days 21 hours and 21 minutes ago]

Tue, 10 Mar 2026 12:50:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I can't help myself.  I like shiny things.
>
> This is a derivative image; original CC-BY-SA 4.0 Jaime Vives Piqueres.
> The thumbnail is no longer on his page--possibly due to his server
> crash--but you can still find the zip file by searching "boltstill" at
> ignorancia.org.

Interesting, the exposure looks slightly better despite a little too much
opacity/uniform visibility of the starry streaks But what gets me curious is
that the overexposed areas seem to have shifted towards the blue... did you
initiate this on purpose? or is it something this macro would always do?

[Mr] Re: Help: How to create a bolt? [41 days 21 hours and 21 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? [42 days 15 hours and 36 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 [42 days 15 hours and 51 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.

[Cousin Ricky] Jaime's bolts, post-processed [42 days 16 hours and 12 minutes ago]

Mon, 9 Mar 2026 17:58:34 GMT

I can't help myself.  I like shiny things.

This is a derivative image; original CC-BY-SA 4.0 Jaime Vives Piqueres.
The thumbnail is no longer on his page--possibly due to his server
crash--but you can still find the zip file by searching "boltstill" at
ignorancia.org.

[LanuHum] Re: Help: How to create a bolt? [42 days 16 hours and 31 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 1 hour and 31 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

[m@b] Re: Orrery WIP [43 days 7 hours and 21 minutes ago]

Mon, 9 Mar 2026 02:50:00 GMT

> > Very nice. I did an orrery some time ago:
> > <https://www.youtube.com/watch?v=GyqQolOK_qI>
> >
> > I remember one of the first scenes I animated was a lighthouse (using Polyray)
> > way back when :-)
> >
> > m@b
>
> Very nice.  I particularly like the way you morphed the planets into the orrery.
> Impressive.

Thanks :-)

[Bald Eagle] Re: Help: How to create a bolt? [43 days 20 hours and 11 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? [44 days 4 hours and 26 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? [44 days 4 hours and 51 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? [44 days 10 hours and 1 minute 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? [44 days 10 hours and 39 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? [44 days 17 hours and 6 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? [44 days 17 hours and 51 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? [44 days 18 hours and 1 minute 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? [44 days 18 hours and 26 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? [44 days 21 hours and 36 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? [44 days 23 hours and 11 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 1 hour and 1 minute 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? [45 days 3 hours and 1 minute 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)

[Clarence1898] Re: Orrery WIP [46 days 6 hours and 46 minutes ago]

Fri, 6 Mar 2026 03:25:00 GMT

"m@b" <nomail@nomail> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > This is a project I started over 20 years ago by modeling an orrery.  Then had
> > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > looping on in your player.  I would get stuck on it, or real life interrupted,
> > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > camera flies through, not enough turbulence.  There is also some flickering I
> > haven't been able to get rid of.  The camera has a couple of abrupt moves I need
> > to smooth out.  I do plan to add more objects to the scene.  Any comments or
> > suggestions would be welcome.
>
> Very nice. I did an orrery some time ago:
> <https://www.youtube.com/watch?v=GyqQolOK_qI>
>
> I remember one of the first scenes I animated was a lighthouse (using Polyray)
> way back when :-)
>
> m@b

Very nice.  I particularly like the way you morphed the planets into the orrery.
Impressive.

[m@b] Re: Orrery WIP [46 days 7 hours and 56 minutes ago]

Fri, 6 Mar 2026 02:15:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> This is a project I started over 20 years ago by modeling an orrery.  Then had
> to figure out a scene to put it in.  This is what I finally came up with.  Turn
> looping on in your player.  I would get stuck on it, or real life interrupted,
> put aside for a few years then repeat.  I'm not very happy with the clouds the
> camera flies through, not enough turbulence.  There is also some flickering I
> haven't been able to get rid of.  The camera has a couple of abrupt moves I need
> to smooth out.  I do plan to add more objects to the scene.  Any comments or
> suggestions would be welcome.

Very nice. I did an orrery some time ago:
<https://www.youtube.com/watch?v=GyqQolOK_qI>

I remember one of the first scenes I animated was a lighthouse (using Polyray)
way back when :-)

m@b

[Clarence1898] Re: Orrery WIP [46 days 11 hours and 16 minutes ago]

Thu, 5 Mar 2026 22:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Clarence1898" <dle### [at] comcastnet> wrote:
> > This is a project I started over 20 years ago by modeling an orrery.
>
> And you're still at it!  Good work.
>
> It's been a long time since I've seen one of these classic animations.
>
> >Then had
> > to figure out a scene to put it in.  This is what I finally came up with.  Turn
> > looping on in your player.  I would get stuck on it, or real life interrupted,
> > put aside for a few years then repeat.  I'm not very happy with the clouds the
> > camera flies through, not enough turbulence.
>
> Clouds are notoriously difficult.
>
> >There is also some flickering I
> > haven't been able to get rid of.
>
> I didn't really notice anything, so it must be a very small problem.
>
> >The camera has a couple of abrupt moves I need
> > to smooth out.
>
> When you're about to make a sharp turn, slow down the camera dramatically.
> Look into "smoothing functions" to get the sort of thing you want.
>
> >I do plan to add more objects to the scene.  Any comments or
> > suggestions would be welcome.
>
> I like the island a LOT.
> The house, the working lighthouse (make the light MUCH brighter), the ceiling
> fan, the periodic table, the stencil on the desk....
>
> The orrery sun could be a bit brighter/yellower.
>
> I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
> nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
> graphics models, or someone else's POV-Ray model/effect into a scene.
>
> If you hit any more stumbling blocks, don't be afraid to ask for ideas or
> solutions.  Set your goal on the finish line!
>
> - BE

Thank you for the suggestions.  I made a few changes and reposted a new
animation.  The flickering is much more noticeable at higher resolutions, I
rendered the animation at 1280x720 then reduced it to 640x360 to get the size
down for posting.  The planet maps came from a NASA web site, I picked a new sun
that is brighter and yellower.  It does look better.  The checkered bed was a
nod to the RSOCP, but the pillow reflects the creme colored walls not the bed
and it almost looks translucent not reflective.  At the time I created the
lighthouse I didn't know the color rgb values could be greater than 1.0.  I
increased the value and it looks much better.  I wrote a program to generate the
island,  started with a pyramid and recursively divided the faces into smaller
triangles and translating the vertices a random amount up or down and then
created a mesh2 object.  I then populated the island with 24000 trees and 32000
bushes that were created by Arbaro 2.0.  Now I need to work on the camera
transitions.

[Ton] Re: Cutty Sark [46 days 11 hours and 36 minutes ago]

Thu, 5 Mar 2026 22:35:00 GMT

Thanks for the kind words, jr and BE,

Working on the deadeyes right now, and then slowly move up.

Cheers
Ton

[Bald Eagle] Re: Cutty Sark [46 days 19 hours and 56 minutes ago]

Thu, 5 Mar 2026 14:15:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> We're going higher. The foremast is done.
> Next is the standing rigging that keeps this mast up.

Wow - this is going to be another fantastic model!

Thanks for sharing your progress.  It will be amazing to see the finished ship
in the water.

- BE

[Bald Eagle] Re: Orrery WIP [46 days 20 hours and 1 minute ago]

Thu, 5 Mar 2026 14:10:00 GMT

"Clarence1898" <dle### [at] comcastnet> wrote:
> This is a project I started over 20 years ago by modeling an orrery.

And you're still at it!  Good work.

It's been a long time since I've seen one of these classic animations.

>Then had
> to figure out a scene to put it in.  This is what I finally came up with.  Turn
> looping on in your player.  I would get stuck on it, or real life interrupted,
> put aside for a few years then repeat.  I'm not very happy with the clouds the
> camera flies through, not enough turbulence.

Clouds are notoriously difficult.

>There is also some flickering I
> haven't been able to get rid of.

I didn't really notice anything, so it must be a very small problem.

>The camera has a couple of abrupt moves I need
> to smooth out.

When you're about to make a sharp turn, slow down the camera dramatically.
Look into "smoothing functions" to get the sort of thing you want.

>I do plan to add more objects to the scene.  Any comments or
> suggestions would be welcome.

I like the island a LOT.
The house, the working lighthouse (make the light MUCH brighter), the ceiling
fan, the periodic table, the stencil on the desk....

The orrery sun could be a bit brighter/yellower.

I like the checkered bed.  Perhaps a silvery pillow would be a nice "easter egg"
nod to the RSOCP.  It's always fun to sneak some classic POV-Ray / computer
graphics models, or someone else's POV-Ray model/effect into a scene.

If you hit any more stumbling blocks, don't be afraid to ask for ideas or
solutions.  Set your goal on the finish line!

- BE

[jr] Re: Orrery WIP (with mp4) [47 days 1 hour and 51 minutes ago]

Thu, 5 Mar 2026 08:20:00 GMT

hi,

"Clarence1898" <dle### [at] comcastnet> wrote:
> somehow my attachment is missing.  Try it again.

wow, quite the study.. :-)  very nice.


regards, jr.

[Clarence1898] Orrery WIP (with mp4) [47 days 11 hours and 21 minutes ago]

Wed, 4 Mar 2026 22:50:00 GMT

somehow my attachment is missing.  Try it again.

[Clarence1898] Orrery WIP [47 days 12 hours and 26 minutes ago]

Wed, 4 Mar 2026 21:45:00 GMT

This is a project I started over 20 years ago by modeling an orrery.  Then had
to figure out a scene to put it in.  This is what I finally came up with.  Turn
looping on in your player.  I would get stuck on it, or real life interrupted,
put aside for a few years then repeat.  I'm not very happy with the clouds the
camera flies through, not enough turbulence.  There is also some flickering I
haven't been able to get rid of.  The camera has a couple of abrupt moves I need
to smooth out.  I do plan to add more objects to the scene.  Any comments or
suggestions would be welcome.

[Guillermo Espitia] Re: Line numbering [47 days 12 hours and 40 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 [47 days 12 hours and 46 minutes 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 [47 days 13 hours and 36 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

[Bald Eagle] Re: Elliptical torus [47 days 13 hours and 41 minutes ago]

Wed, 4 Mar 2026 20:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ... I'd say that this demonstrates that a solution isn't
> > possible, given the parameters.
> >
>
> > So I think that some of the constraints are mutually exclusive.
>
> However; depending on if the design parameters can be modified and still provide
> an acceptable solution to the intended goal:
>
> Perhaps an elliptical  "torus" that is in reality a Dupin cyclide would be just
> the thing:
> https://en.wikipedia.org/wiki/Dupin_cyclide#Elliptic_cyclides
>
> - BW

So, for whatever reason, my brain revisited this, and I wanted a quick
evaluation of if my intuition about using a cyclide in place of an actual torus
would work.

enjoy.

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

A section of a Dupin cyclide (specifically a ring cyclide) can play the
geometric role of a “torus with circular cross section but elliptical major
radius,” even though a true torus with those properties is impossible.
Below is the detailed geometric reasoning.

Why an elliptically‑centered circular torus is impossible
A standard torus is defined as the surface generated by revolving a circle of
radius rrr around an axis parallel to the circle’s plane, at a distance R>rR >
rR>r. Its defining property is:

The tube centerline is a perfect circle of radius RRR.

If you attempt to replace that circular “major radius path” with an ellipse:

A circle of radius rrr cannot remain perpendicular to an elliptical trajectory
while maintaining constant distance from the ellipse.
As the tube center attempts to follow the ellipse, the required orientation
twists inconsistently.
The surface self‑intersects unless the cross‑section distorts.
A constant‑radius normal field cannot exist along a plane ellipse.

Thus:

A torus with constant circular cross‑section and an elliptical major
radius cannot be embedded in R3\mathbb{R}^3R3 without distortion.

This is a classical result from differential geometry: a tube of constant radius
can only be swept around a curve whose curvature κ(s)\kappa(s)κ(s)
satisfies
r<1max⁡κ(s)r < \frac{1}{\max \kappa(s)}r<maxκ(s)1
and whose normal vector rotates consistently. A planar ellipse does not satisfy
this for a fixed radius circle.

How a Dupin cyclide solves this
A Dupin cyclide—especially a ring cyclide—has the following remarkable
property:

Its cross sections by suitable families of spheres are circles, and the
curvature lines are circles.

That means:

The surface bends around in a general way not limited to being the
parallel‑offset of a single circle.
The curvature lines are Villarceau circles and orthogonal circular families,
giving a structure very similar to a torus but with more flexibility.
Locally, a cyclide can approximate what a “torus with an elliptical major
radius” would look like if such a torus existed.

Why a cyclide can work:
A general ring cyclide is obtained from a torus by inversion in a sphere:
Cyclide=Inversion(Torus)\text{Cyclide} = \text{Inversion} ( \text{Torus}
)Cyclide=Inversion(Torus)
Inversion preserves:

circles → circles,
spheres → spheres,
constant‑curvature structure in a generalized way.

But inversion does not preserve distances, so the resulting surface can bend and
“stretch” in ways that circumvent the rigid constraints that prohibit an
elliptical‑centerline torus.
Thus a Dupin cyclide:

has circular curvature lines (like a torus),
can appear elongated or “elliptical” in global shape,
maintains circular cross‑sections in a transformed sense,
can be fitted to curves (directrices) that are not circles.

Can a section of a cyclide be used as a “pseudo‑torus with elliptical
sweep”?
Yes — this is a common use of cyclides in geometric modeling.
A partial ring cyclide can provide:

an elongated toroidal shape,
smooth curvature without singularities,
circular fiber curves (Villarceau circles),
an approximate “tube” that wraps around an ellipse‑like path.

This is used in:

CAD modeling systems,
sweep surfaces,
transition surfaces (Fillets/Blends),
quadric‑based modeling applications.

Cyclides behave as “generalized tori” exactly in this sense.
Practical interpretation:
If you want:

a circular tube,
bending around an ellipse,
without changing the tube radius,

then a cyclide patch is the mathematically correct surface.
A full cyclide has two circle families suitable for “tube‑like”
structures. A selected region of a cyclide can approximate a torus stretched
around an ellipse, because the inversion mapping allows shapes impossible in
Euclidean rigid sweeps.

Summary

QuestionAnswer“Can a torus with circular tube but elliptical major radius
exist?”No. This is impossible in R3\mathbb{R}^3R3 without distorting the
tube.“Can a Dupin cyclide mimic this?”Yes. A ring cyclide can take on an
elongated shape and maintain circular curvature lines.“Can we use a cyclide
section for a tube following an ellipse?”Yes — this is a textbook
application of
cyclides in geometric modeling.

If you want, I can:

derive the exact cyclide equation needed for a specific ellipse,
construct Villarceau circle fibrations along that cyclide,
generate POV‑Ray macros for a cyclide section that approximates a torus
swept along an ellipse,
create a PDF with diagrams and derivations,
provide a .pov scene with curvature‑coloring and isosurface rendering.

Would you like the full construction?

[Guillermo Espitia] Line numbering [47 days 14 hours and 51 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 [47 days 16 hours and 6 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

[jr] Re: Cutty Sark [48 days 22 hours and 51 minutes ago]

Tue, 3 Mar 2026 11:20:00 GMT

hi,

"Ton" <ton### [at] gmailcom> wrote:
> And another photo...

fabulous, thanks.  this vessel is about to replace Friedrich L's "sternwheeler"
from its top spot :-).


regards, jr.

[Ton] Re: Cutty Sark [49 days 1 hour and 21 minutes ago]

Tue, 3 Mar 2026 08:50:00 GMT

And another photo...

[Ton] Re: Cutty Sark [49 days 1 hour and 21 minutes ago]

Tue, 3 Mar 2026 08:50:00 GMT

We're going higher. The foremast is done.
Next is the standing rigging that keeps this mast up.

Cheers
Ton

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl... [52 days 13 hours and 16 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... [52 days 13 hours and 38 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... [52 days 14 hours and 56 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 [52 days 19 hours and 1 minute 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 [52 days 22 hours and 21 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 [53 days 9 hours and 8 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 [53 days 16 hours and 37 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 [53 days 20 hours and 51 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... [53 days 22 hours and 9 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 [54 days 12 hours and 7 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 [54 days 13 hours and 1 minute 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 [54 days 13 hours and 20 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 [54 days 13 hours and 56 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 [54 days 14 hours and 9 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 [54 days 14 hours and 46 minutes 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 [54 days 15 hours and 25 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 [54 days 22 hours and 21 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 1 hour and 14 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 [55 days 6 hours and 49 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 [55 days 16 hours and 46 minutes 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 [55 days 17 hours and 34 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... [56 days 20 hours and 6 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

[Jörg "Yadgar" Bleimann] Re: Would you like a drink? [57 days 19 hours and 24 minutes ago]

Sun, 22 Feb 2026 14:46:26 GMT

Hi(gh)!

Am 11.02.26 um 12:50 schrieb Bald Eagle:
> kurtz le pirate <kur### [at] freefr> wrote:
>> Hello,
>>
>> One or more suggestions for further improvement ?
> 
> Use the keywords "open" and "hollow" so that I can reach into the screen and
> taste it?

Don't drink and code! Programmers run on caffeine, not alcohol...

See you in Khyberspace!

Yadgar

-- 
VBI BENE, IBI BACTRIA!

[yesbird] Re: Help: Erroneous mathematics information on t... [57 days 22 hours and 39 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 and 46 minutes 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... [58 days 8 hours and 26 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... [58 days 10 hours and 29 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... [58 days 16 hours and 36 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... [59 days 23 hours and 45 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 [60 days 9 hours and 26 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... [60 days 9 hours and 51 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... [60 days 13 hours and 26 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... [60 days 13 hours and 59 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... [60 days 22 hours and 1 minute 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

[yesbird] Re: Git CLI to the rescue! [63 days 15 hours and 29 minutes ago]

Mon, 16 Feb 2026 18:41:58 GMT

On 16/02/2026 19:29, Cousin Ricky wrote:
> Finally some good news on the Git front!  My life is starting to ease up
> a bit.
> 

I am using https://github.com/apps/desktop and happy with it.
There is also a Linux version somewhere ...
-- 
YB

[jr] Re: Git CLI to the rescue! [63 days 16 hours and 51 minutes ago]

Mon, 16 Feb 2026 17:20:00 GMT

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ... Problem is, it piped the output into Less.

you mean 'less', yes ?

  Sorry, but I've been spoiled by GUIs since the late
> 1980s, and find terminal apps such as Less a bit clunky.

wondering which use of "spoiled", ie "(transitive) To ruin the character of, by
overindulgence; to coddle or pamper to excess", or "(transitive) To ruin; to
damage in such a way as to make undesirable or unusable" you had in mind ?
surely not "to become sour"..  </grin>

so, using your usual method, if you want to look at the contents of a zip file
(not extract it), what program do you use ?  or you want to look at a '.tar',
more common on GNU/Linux, perhaps compressed, again, not wanting to extract.
which program ?  if you want to read a compressed text file, say .gz or .xz,
which program do you use ?  or you want to quickly read some part of a PDF,
which program do you open ?  or, say, you are reading through some program
source (in your viewer) and spot a typo, can you edit it ?

'less' lets me do all of the above, including invoking the editor with the
cursor pretty near the "offending" bit (if it was approx centre of 'less' view).
 and all w/out a single rodent click, "hands on keyboard" ;-).

regards, jr.

[Cousin Ricky] Git CLI to the rescue! [63 days 17 hours and 41 minutes ago]

Mon, 16 Feb 2026 16:29:16 GMT

Finally some good news on the Git front!  My life is starting to ease up
a bit.

I found myself confused over what changes I made between a couple of
branches last month, so I tried to use the Diff Branches feature of
Git-Cola.  But I couldn't figure out what Git-Cola was diffing.  Some
blob in the /tmp directory doesn't really tell me what it's looking at.

So I did a git diff from the command line.  Problem is, it piped the
output into Less.  Sorry, but I've been spoiled by GUIs since the late
1980s, and find terminal apps such as Less a bit clunky.

So, after a futile attempt to find clear instructions about Git-Cola
online, I went back to Git-Cola to try to figure things out myself.  But
everything I tried showed a comparison of I-don't-know-what to some
*previous* commit (and I only knew *that* due to a change I did remember
making), which was not what I wanted.

Then Captain Obvious whispered to me: just go back to the CLI and see if
redirecting git diff into a text file would lose the Less pipe!  It
worked.  I can now just peruse the differences with my GUI text editor.

One of the things I appreciate about Git-Cola is how seamlessly it works
with Git.  I can go back and forth between Git-Cola and the CLI at will.

[Mr] Re: Would you like a drink? [63 days 22 hours and 31 minutes ago]

Mon, 16 Feb 2026 11:40:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> On 11/02/2026 11:04, kurtz le pirate wrote:
> >
> > Hello,
> >
> > One or more suggestions for further improvement ?
> >
>
>
>
> Yes, the texture/material of the cardboard is not right.
>
> Numerous attempts have been made, but none have been very satisfactory.
> I am open to suggestions on this matter.
>
>
>
>
> --
> kurtz le pirate
> compagnie de la banquise

Awsome work on the model, composition and texture placement ! It looks
promissing.

You should separate the side and top parts of the glass supporting cardboard,
giving them different textures, just as a real cutout showing the darker
cardboard structure (probably some round form factored crackle (aka circcular
celled voronoi) on the side of the cylinder, but the lighter more grainy (rough
phong with large fade out) currently almost there should be reserved for the top
facing printed paper aspect. it do more justice to it by contrast. (if there was
one in POV (can't remember) you may turn that to Oren Nayar Blinn with max
roughness/sigma everywhere)

About the table, It's diffuse color value is somehow too high :it does not show
the lighting of the room / specular of the table come into play...

Finally some effects :

maybe some photons based caustics could happen if light came proportionally more
from a narrow focused spotlight.

As an ultimate final step, maybe the very minimal atmospheric media in the room
would add to this also as per Blender exporter default settings:
type 1 Isotropic 35 samples with a very dark diffusion color <0.001, 0.001,
0.001> absorption scale 0.00002

[jr] Re: not saving [64 days 1 hour and 21 minutes ago]

Mon, 16 Feb 2026 08:50:00 GMT

hi,

"Franz von Dardel" <dar### [at] orangefr> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Franz von Dardel" <dar### [at] orangefr> wrote:
> > > Using POVRay 3.7.0.x
> > > When I use "not saving" (Image Type Don't Save Image), rendering is OK but
> > > (obviously) the image is not saved.  When I use another Image Type (e.g. PNG) I
> > > get the message "Cannot create render state output file."
> > > Where is the mistake?
> >
> > you wrote about having this problem a while ago, one reply to your original post
> > was by the (Apple stuff) maintainer, did you see/read it ?
> > <https://news.povray.org/69613afe%40news.povray.org>
>
> Yes, I wrote about the problem in January, but at that time I did not realise
> that the option "Don't Save Image" would work, while selecting for instance
> "PNG" would produce the message "Cannot create render state output file.". Why
> is ist so, and what can I do to correct the problem?

I have far too little info, so only can speculate.  (and I do not use an UI
version of POV-Ray).  here, on a GNU/Linux machine, there are two files which
control where POV-Ray can read from and write to, both named 'povray.conf'.  one
is global, the other will be in your user's directory (here '~/.povray/3.7/').
I'd start with checking/customising those.


regards, jr.

[Franz von Dardel] Re: not saving [64 days 18 hours and 1 minute ago]

Sun, 15 Feb 2026 16:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "Franz von Dardel" <dar### [at] orangefr> wrote:
> > Using POVRay 3.7.0.x
> > When I use "not saving" (Image Type Don't Save Image), rendering is OK but
> > (obviously) the image is not saved.  When I use another Image Type (e.g. PNG) I
> > get the message "Cannot create render state output file."
> > Where is the mistake?
>
> you wrote about having this problem a while ago, one reply to your original post
> was by the (Apple stuff) maintainer, did you see/read it ?
> <https://news.povray.org/69613afe%40news.povray.org>
>
>
> regards, jr.

Yes, I wrote about the problem in January, but at that time I did not realise
that the option "Don't Save Image" would work, while selecting for instance
"PNG" would produce the message "Cannot create render state output file.". Why
is ist so, and what can I do to correct the problem?

[William F Pokorny] Re: Suggest v4.0 allow negative phong / spectral... [65 days 13 hours and 12 minutes ago]

Sat, 14 Feb 2026 20:58:42 GMT

On 2/14/26 13:40, Cousin Ricky wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An old (~2021) yuqk change for which I could not find a prior newsgroup
>> post 'description', allows negative phong and spectral values.
>>
>> We have always been able to use the finish{} block phong and specular
>> features together for effects in an additive-color way. The yuqk fork
>> allows negative phong/spectral values too. For example:
>>
>> [snip]
> 
> I'm confused.  By "spectral," do you mean "specular"?
> 
>


I do. Thank you. Every day, I'm a step closer day to talking endlessly 
about turnips... :-(

Bill P.

[Cousin Ricky] Re: Suggest v4.0 allow negative phong / spectral... [65 days 15 hours and 26 minutes ago]

Sat, 14 Feb 2026 18:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> An old (~2021) yuqk change for which I could not find a prior newsgroup
> post 'description', allows negative phong and spectral values.
>
> We have always been able to use the finish{} block phong and specular
> features together for effects in an additive-color way. The yuqk fork
> allows negative phong/spectral values too. For example:
>
> [snip]

I'm confused.  By "spectral," do you mean "specular"?

[William F Pokorny] Suggest v4.0 allow negative phong / spectral val... [65 days 19 hours and 49 minutes ago]

Sat, 14 Feb 2026 14:21:06 GMT

An old (~2021) yuqk change for which I could not find a prior newsgroup 
post 'description', allows negative phong and spectral values.

We have always been able to use the finish{} block phong and specular 
features together for effects in an additive-color way. The yuqk fork 
allows negative phong/spectral values too. For example:

     #declare PirateGold = srgb <0.72941,0.49804,0.01176>;
     #declare Fin01 = finish {
         brilliance 2.2
         diffuse    0.6
         metallic   1.0
         phong     -3.3 phong_size 47    // <---
         specular   3.3 roughness  1/20
         intensity_max 1.0
     }
     #declare Txtr00 = texture {
         pigment { PirateGold }
         normal { granite bump_size 0.5 scale 1/2.5 }
         finish { Fin01 }
     }

This capability, along with the previously discussed, new to yuqk 
feature, intensity_max, allows for highlights which end in white while 
staying within zero to one rgb channel value ranges(*).

---

In the attached image matrix the columns left to right show: phong only, 
spectral only and finally combined phong and spectral use on the right.

The top row shows conventional double use of phong and spectral features 
where, especially together, the output result is clipped to a strong 
yellow (the hue is shifting(**)). If the light source were much 
stronger, that strong yellow would eventually go white in the most 
intense phong/specular regions(**).

The bottom row uses new yuqk finish features as shown in the code above. 
  The differences being the intensity_max option better maintains the 
phong/spectral metallic hue throughout. Coupled with a tighter phong 
highlight and use of a negative phong value, this results in overall 
highlights which gradually move from PirateGold to white within a zero 
to one rgb channel value range (lower right).

Bill P.

(*) - Zero to one rgb channel ranges work better / more cleanly with 
antialiasing (AA) - and many other POV-Ray features.

(**) - Where the output image channel ranges are clipped by the image 
format and/or the display monitor's capabilities.

[Ton] Re: Cutty Sark [66 days 7 hours and 41 minutes ago]

Sat, 14 Feb 2026 02:30:00 GMT

No launch planned yet, but...
the two deckhouses, containing the galley, the carpenter's shop, and bunks for
the seamen, are done.

Cheers
Ton

[Cousin Ricky] Re: Would you like a drink? [67 days 8 hours and 6 minutes ago]

Fri, 13 Feb 2026 02:05:02 GMT

On 2026-02-11 12:18 (-4), kurtz le pirate wrote:
> 
> Yes, the texture/material of the cardboard is not right.
> 
> Numerous attempts have been made, but none have been very satisfactory.
> I am open to suggestions on this matter.

Something I whipped up this evening.

---%<-----%<--[BEGIN CODE]--%<-----%<---
intersection
{ cylinder
  { 0, 0.2 * y, 4.1
    pigment { rgb <1, 0.9, 0.6> }
    normal { bumps 0.1 scale 0.3 }
  }
  cylinder
  { -0.1 * y, 0.3 * y, 4
    pigment { rgb 0.6 }
    normal
    { crackle -0.5
      scale <1, 0.1, 1> * 0.5
    }
  }
}
--->%----->%---[END CODE]--->%----->%---

[Cousin Ricky] Re: How to convert TTF font characters into pris... [67 days 10 hours and 33 minutes ago]

Thu, 12 Feb 2026 23:37:33 GMT

On 2026-02-08 12:16 (-4), JÃ¶rg "Yadgar" Bleimann wrote:
> 
> To generate gold-textured carved inscriptions in marble, I need tapering
> font characters... and (besides turning them into heightfields and
> rotating them afterwards by 180 degrees before subtracting them from the
> marble plate) they only way to achieve this is converting them into
> prism objects and adding the taper_sweep modifier... how could I do this?

I avoid Bevelled_Text() because it's prone to artifacts on the inside
corners of glyphs.  Have you seen my beveled text isosurface tutorial?
If you prefer height fields, I'm sure the technique can be adapted for
those.

  https://github.com/CousinRicky/IsoBevelTut

[Robert McGregor] Re: Would you like a drink? [67 days 16 hours and 46 minutes ago]

Thu, 12 Feb 2026 17:25:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
> One or more suggestions for further improvement ?

This looks really good. I think adding a small rounded bevel to the top of the
liquid will give it a more realistic surface tension effect.

[jr] Re: not saving [67 days 19 hours and 21 minutes ago]

Thu, 12 Feb 2026 14:50:00 GMT

"Franz von Dardel" <dar### [at] orangefr> wrote:
> Using POVRay 3.7.0.x
> When I use "not saving" (Image Type Don't Save Image), rendering is OK but
> (obviously) the image is not saved.  When I use another Image Type (e.g. PNG) I
> get the message "Cannot create render state output file."
> Where is the mistake?

you wrote about having this problem a while ago, one reply to your original post
was by the (Apple stuff) maintainer, did you see/read it ?
<https://news.povray.org/69613afe%40news.povray.org>

regards, jr.

[Franz von Dardel] not saving [67 days 22 hours and 31 minutes ago]

Thu, 12 Feb 2026 11:40:00 GMT

Using POVRay 3.7.0.x
When I use "not saving" (Image Type Don't Save Image), rendering is OK but
(obviously) the image is not saved.  When I use another Image Type (e.g. PNG) I
get the message "Cannot create render state output file."
Where is the mistake?

[MichaelJF] Re: Would you like a drink? [68 days 16 hours and 26 minutes ago]

Wed, 11 Feb 2026 17:44:11 GMT

Am 11.02.26 um 17:18 schrieb kurtz le pirate:
> On 11/02/2026 11:04, kurtz le pirate wrote:
>>
>> Hello,
>>
>> One or more suggestions for further improvement ?
>>
> 
> 
> 
> Yes, the texture/material of the cardboard is not right.
> 
> Numerous attempts have been made, but none have been very satisfactory.
> I am open to suggestions on this matter.
> 
> 
> 
> 
Jaime Vives Piqueres gave some beer coasters in (archived only):

https://web.archive.org/web/20120621193854/http://www.ignorancia.org/uploads/zips/barrabar.zip

Other nice cardboard-objects can be found in:

http://www.povcomp.com/entries/85.php

Best regards
Michael

[jr] Re: Would you like a drink? [68 days 16 hours and 46 minutes ago]

Wed, 11 Feb 2026 17:25:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
> On 11/02/2026 11:04, kurtz le pirate wrote:
> > One or more suggestions for further improvement ?
>
> Yes, the texture/material of the cardboard is not right.

agree with BE, it does look very "inviting" :-).  I think the wood is quite
dark, and a "sun-bleached" version would set off the drink better.

regards, jr.

[Bald Eagle] Re: Would you like a drink? [68 days 16 hours and 51 minutes ago]

Wed, 11 Feb 2026 17:20:00 GMT

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

> Yes, the texture/material of the cardboard is not right.
>
> Numerous attempts have been made, but none have been very satisfactory.
> I am open to suggestions on this matter.

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

-BE

[kurtz le pirate] Re: Would you like a drink? [68 days 17 hours and 52 minutes ago]

Wed, 11 Feb 2026 16:18:45 GMT

On 11/02/2026 11:04, kurtz le pirate wrote:
> 
> Hello,
> 
> One or more suggestions for further improvement ?
> 

Yes, the texture/material of the cardboard is not right.

Numerous attempts have been made, but none have been very satisfactory.
I am open to suggestions on this matter.

-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Would you like a drink? [68 days 19 hours and 1 minute ago]

Wed, 11 Feb 2026 15:09:46 GMT

On 11/02/2026 13:04, kurtz le pirate wrote:
> One or more suggestions for further improvement ?

Great job ...
With pleasure, for your SDL code !

Maybe a few bubbles to bring more life to liquid ?
And usually glass stands are made from cardboard,
here it is more like of plastic.
-- 
YB

[Bald Eagle] Re: Would you like a drink? [68 days 22 hours and 16 minutes ago]

Wed, 11 Feb 2026 11:55:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
> One or more suggestions for further improvement ?

Use the keywords "open" and "hollow" so that I can reach into the screen and
taste it?

Implement rlr - real life raytracing?

:D


Well done!


- BE

[kurtz le pirate] Would you like a drink? [69 days and 6 minutes ago]

Wed, 11 Feb 2026 10:04:29 GMT

Hello,

One or more suggestions for further improvement ?





-- 
kurtz le pirate
compagnie de la banquise

[Nekar Xenos] Re: Practical Stargate kawoosh effect ideas [69 days 5 hours and 11 minutes ago]

Wed, 11 Feb 2026 05:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Nekar Xenos" <nomail@nomail> wrote:
>
> > The reason I posted this in off-topic was a thought experiment on what would be
> > the easiest way to use the above method to make it for a man-cave? Instead of
> > the periscope which is too small, put a 45 degree mirror behind your stargate
> > model and a clear plastic tub of water above it. Then use a compressor to blow
> > air in.
>
> OOOOoooooh.
> Constructing one IRL!
>
> Maybe you could make it small and magnify it, and then just use a pellet gun or
> a paintball marker for your air cannon.
>
> Perhaps even shoot the air through a small hole in a mirror to hide the
> mechanism.
>
> You could even use a webcam or something so that you could composite the
> stargate ring and the kawoosh somehow.
>
> - BE

 Yes, a magnifying mirror might work and maybe even help to bring the image more
foreward. Maybe I should try recreating it in Pov-Ray with photons.

-Nekar Xenos-

[yesbird] Re: Star catalogue [69 days 11 hours and 51 minutes ago]

Tue, 10 Feb 2026 22:19:50 GMT

On 04/02/2026 13:06, Maetes wrote:
> I'm pretty sure you can't wait that long, but I also dealt with constellations,
> lines and borders in December. Corresponding 3 or more database tables as well
> as a Povray macro collection are in the works. However, I need time for the
> completion, I have just started something else. Will probably not be finished
> until March, or even later.
>

You are right about the time - I don't like to waste it, so
working hard on the planetarium, which now is https://viewspace.online/.

One guy on this forum solved all my problems with data sources
in one shot message:
https://www.cloudynights.com/forums/topic/992636-data-sources-for-virtual-planetarium/

Also his site is full of useful code and interesting ideas, so
I am glad that registered there.
--
YB

[Bald Eagle] Re: Practical Stargate kawoosh effect ideas [69 days 22 hours and 6 minutes ago]

Tue, 10 Feb 2026 12:05:00 GMT

"Nekar Xenos" <nomail@nomail> wrote:

> The reason I posted this in off-topic was a thought experiment on what would be
> the easiest way to use the above method to make it for a man-cave? Instead of
> the periscope which is too small, put a 45 degree mirror behind your stargate
> model and a clear plastic tub of water above it. Then use a compressor to blow
> air in.

OOOOoooooh.
Constructing one IRL!

Maybe you could make it small and magnify it, and then just use a pellet gun or
a paintball marker for your air cannon.

Perhaps even shoot the air through a small hole in a mirror to hide the
mechanism.

You could even use a webcam or something so that you could composite the
stargate ring and the kawoosh somehow.

- BE

[Nekar Xenos] Re: Practical Stargate kawoosh effect ideas [70 days 3 hours and 36 minutes ago]

Tue, 10 Feb 2026 06:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
https://www.gateworld.net/news/2020/07/stargate-vfx-supervisor-creating-kawoosh-effect-sg1-early-days/
>
> KAWOOSH!
>
> amazing kawoosh effect on a TV budget and schedule. That iconic shot of the
> Stargate connecting a wormhole to a distant world has to look right.
>
>
> ordered a special [tank] for the show, and it was one meter by one meter by one
>
>
>
>
> tests, then we set the pressure at 50 pounds. So, we roll the camera at 120
> frames per second, the water is as flat as we can make it, you push the button
> and it lets the air go down the tube right into the water. Well, as it turns
> out, [the movie] used about 5 pounds, or 10 pounds. So 50 pounds just emptied
> the tank everywhere!
>

It's nice to see you guys again!

The reason I posted this in off-topic was a thought experiment on what would be
the easiest way to use the above method to make it for a man-cave? Instead of
the periscope which is too small, put a 45 degree mirror behind your stargate
model and a clear plastic tub of water above it. Then use a compressor to blow
air in.

The only issue is that the kawoosh splash won't go out into the room like in the
series, and the ripples will be way behind the stargate. Which is why I started
thinking of parabolic mirrors.

-Nekar Xenos-

[Bald Eagle] Re: Practical Stargate kawoosh effect ideas [70 days 13 hours and 11 minutes ago]

Mon, 9 Feb 2026 21:00:00 GMT

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

> Of course you could do it with spheres and CSG as well.
.....
> I'd say that you'd want that extended "blooping" of a forcibly extruded air
> bubble in water, though.

I'm at work, and my brain is slow ---

this would probably best be done using BLOBS, since that would give you
excellent bounding plus some of that "blooping" effect with spheres that were
semi-detached from the main mass.

Alternatively, you might consider using a cone or capped cylinder isosurface for
the bubbles and perturb the surface with a fractal noise function.

- BE

[Bald Eagle] Re: Practical Stargate kawoosh effect ideas [70 days 16 hours and 41 minutes ago]

Mon, 9 Feb 2026 17:30:00 GMT

https://www.gateworld.net/news/2020/07/stargate-vfx-supervisor-creating-kawoosh-effect-sg1-early-days/

KAWOOSH!
Arguably the biggest task for Gajdecki and his team was to recreate the movie’s
amazing kawoosh effect on a TV budget and schedule. That iconic shot of the
Stargate connecting a wormhole to a distant world has to look right.

For Gajdecki and his team, the answer turned out to be trial and error. “We
ordered a special [tank] for the show, and it was one meter by one meter by one
meter,” he said.

“We set up an air cannon above [but] we didn’t know how much air pressure to
use,” he recalled. “We set the camera up, we set the lights up, we shot some
tests, then we set the pressure at 50 pounds. So, we roll the camera at 120
frames per second, the water is as flat as we can make it, you push the button
and it lets the air go down the tube right into the water. Well, as it turns
out, [the movie] used about 5 pounds, or 10 pounds. So 50 pounds just emptied
the tank everywhere!

“It was spectacularly cool! But OK … fill it back up, everybody dry off, and
we’re going to try it again!”

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

https://www.youtube.com/watch?v=usHi9c3e_rY
"After years of on and off tweaking, I finalized the Kawoosh animation. It's all
done in LightWave 2018 using a complex nodal displacement setup, with some post
processing in After Effects.

It's the very same principle as in the breakdown video ( • Stargate Kawoosh
Animation Test (2014) ) I did years ago. The secret lies in tweaking the
displacement until it looks and animates like a water surface. The rest is
created by reflections of a proper background image, and a luminous surface
behind the event horizon."

Blender tutorial:

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

[Bald Eagle] Re: Practical Stargate kawoosh effect ideas [70 days 16 hours and 51 minutes ago]

Mon, 9 Feb 2026 17:20:00 GMT

"Nekar Xenos" <nomail@nomail> wrote:
> Today I went down the rabbit hole of Is It Possible To Recreate The Stargate
> Kawoosh theoretically as a practical effect? What I thought of first was take a
> periscope, remove the top part with the top mirror/prism and fill it with water.
> The viewer would now see water ripples on a vertical surface. Put a Stargate
> prop around the viewer and you're good to go. But obviously this will be too
> deep in and not be as close to the surface of the Stargate as it should be. Then
> I started thinking about the almost holographic effect of parabolic mirrors
> -that put my brain in an infinite fractal loop :-S
>
> Anyone have any ideas? :)
>
> -Nekar Xenos-

Hi Nekar,
Welcome back to the forums!  :)

like this? :
https://www.youtube.com/watch?v=Mi_xG8XovrE

I'm assuming that it's the big bubble effect of the unstable vortex that you're
trying to do?

Perhaps an isosurface with bubble paths mapped out in randomized sine-wave
spline paths?  That way the bubbles get subtracted from the liquid isosurface,
and whoosh outwards until a max at pi/2 and return to the glyph ring at pi?
Randomizing the path radially would give a fill-in over the whole surface of the
"water".

Of course you could do it with spheres and CSG as well.

We recently partially reworked a bubbles macro, and I did a physically correct
falling raindrop that you could use for bubble shapes as well.

I'd say that you'd want that extended "blooping" of a forcibly extruded air
bubble in water, though.

Maybe model that like the gravitational breakup of a falling stream of water.

- BE

[Nekar Xenos] Practical Stargate kawoosh effect ideas [71 days and 6 minutes ago]

Mon, 9 Feb 2026 10:05:00 GMT

Today I went down the rabbit hole of Is It Possible To Recreate The Stargate
Kawoosh theoretically as a practical effect? What I thought of first was take a
periscope, remove the top part with the top mirror/prism and fill it with water.
The viewer would now see water ripples on a vertical surface. Put a Stargate
prop around the viewer and you're good to go. But obviously this will be too
deep in and not be as close to the surface of the Stargate as it should be. Then
I started thinking about the almost holographic effect of parabolic mirrors
-that put my brain in an infinite fractal loop :-S

Anyone have any ideas? :)

-Nekar Xenos-

[Alain Martel] Re: How to convert TTF font characters into pris... [71 days 16 hours and 8 minutes ago]

Sun, 8 Feb 2026 18:02:18 GMT

Le 2026-02-08 Ã  11:16, JÃ¶rg "Yadgar" Bleimann a
Ã©critÂ :
> Hi(gh)!
> 
> To generate gold-textured carved inscriptions in marble, I need tapering 
> font characters... and (besides turning them into heightfields and 
> rotating them afterwards by 180 degrees before subtracting them from the 
> marble plate) they only way to achieve this is converting them into 
> prism objects and adding the taper_sweep modifier... how could I do this?
> 
> See you in Khyberspace!
> 
> Yadgar
> 
> 

Try the Bevelled_Text macro from shapes.inc.

#macro Bevelled_Text(Font, String, Cuts, BevelAng, BevelDepth, Depth, 
Offset, UseMerge)

BevelAng is in radians.
UseMerge need to be 0.
Cuts determine the smoothness.


Use that macro with scale -1*z to place the bevel on the back of the text.

[Jörg "Yadgar" Bleimann] How to convert TTF font characters into prism ob... [71 days 17 hours and 54 minutes ago]

Sun, 8 Feb 2026 16:16:34 GMT

Hi(gh)!

To generate gold-textured carved inscriptions in marble, I need tapering 
font characters... and (besides turning them into heightfields and 
rotating them afterwards by 180 degrees before subtracting them from the 
marble plate) they only way to achieve this is converting them into 
prism objects and adding the taper_sweep modifier... how could I do this?

See you in Khyberspace!

Yadgar


-- 
VBI BENE, IBI BACTRIA!

[Bald Eagle] Re: Solar System [75 days 18 hours and 11 minutes ago]

Wed, 4 Feb 2026 16:00:00 GMT

"Maetes" <nomail@nomail> wrote:

> Nice animation, but I don't really understand, what is happening in the
> animation. Where ist Earth, where Jupiter, what changes over time?

All of the planets are pictured stationary in their orbits
(I suppose I did that for simplicity at the time)
All of the white objects are the 655,000+ "minor planets" in the asteroid belt
getting animated over the span of 1 year

- BE

[Maetes] Re: Solar System [75 days 23 hours and 56 minutes ago]

Wed, 4 Feb 2026 10:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Further work:
>
> Over the weekend I worked out the REAL way to do orbital inclinations, and
> processed the data for ~655,000 minor plants from:
> http://www.minorplanetcenter.net/iau/MPCORB.html
>
> You can clearly see why it's called the asteroid BELT.  :O

Nice animation, but I don't really understand, what is happening in the
animation. Where ist Earth, where Jupiter, what changes over time?

ma

[Maetes] Re: Star catalogue [76 days and 1 minute ago]

Wed, 4 Feb 2026 10:10:00 GMT

yesbird wrote:
> Thanks for the suggestion, this man provides more details about
> this subject: https://pbarbier.com/constellations/boundaries.html
> Probably I need to dive deeper into astronomy and need a good book for
> beginners. School lessons are not enough and were too many years ago ...

I'm pretty sure you can't wait that long, but I also dealt with constellations,
lines and borders in December. Corresponding 3 or more database tables as well
as a Povray macro collection are in the works. However, I need time for the
completion, I have just started something else. Will probably not be finished
until March, or even later.

ma

[Maetes] Re: Star catalogue [76 days and 6 minutes ago]

Wed, 4 Feb 2026 10:05:00 GMT

yesbird wrote:
> Sorry for the inconvenience, it was my fault - I forgot
> to comment out debug info and all 13979 records of NGC were printed to
> browser's page. Now it works fine - no more crashes, I promise :).

Shame on you. I've absolutely never made such mistakes...


> I have also registered in this serious astronomic community:
> https://www.cloudynights.com/

Interesting site, I didn't know yet, maybe I'll sign up too.


> Here is large-scale prototype for what I am doing:
> http://aladin.cds.unistra.fr/AladinLite/

I also found Aladdin yesterday, but I didn't want to spoil your fun :)


"jr" <cre### [at] gmailcom> wrote:
> in which case, likely, the default setting in the global 'povray.conf' will
> "trip you up".  you have to set "[Shellout Security]" to 'allowed'.

Thanks for that, this little piece of information can potentially save a lot of
searching.

ma

[yesbird] Re: Star catalogue [76 days 6 hours and 12 minutes ago]

Wed, 4 Feb 2026 03:58:40 GMT

On 01/02/2026 12:42, yesbird wrote:
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
> 

Here is large-scale prototype for what I am doing:
http://aladin.cds.unistra.fr/AladinLite/

I am plan to make something similar, but less scientific,
more user friendly, with better GUI, higher quality images
and VR support.
--
YB

[yesbird] Re: Star catalogue [76 days 6 hours and 33 minutes ago]

Wed, 4 Feb 2026 03:37:47 GMT

On 03/02/2026 22:29, Maetes wrote:
> Maybe use bound_20 (top-left in the select-box).
> Thats the epoch, bounds_18 means 1875.
> 
> They are slightly different.
> https://en.wikipedia.org/wiki/Epoch_(astronomy)#Epochs_and_periods_of_validity
> 
Thanks for the suggestion, this man provides more details about
this subject: https://pbarbier.com/constellations/boundaries.html

Probably I need to dive deeper into astronomy and need a good book for
beginners. School lessons are not enough and were too many years ago ...
--
YB

[Leroy] Re: Fan art: Trevor G Quayle's rainbow [76 days 6 hours and 51 minutes ago]

Wed, 4 Feb 2026 03:20:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I created SpectralRender interpretations of Trevor G Quayle's rainbows
> from 2008-2009.  The marble pigment is by Tek.
>
> Original posts:
>  https://news.povray.org/web.492eba0f4cea9e2d81c811d20%40news.povray.org
>  https://news.povray.org/web.49302a15d3e0b85381c811d20%40news.povray.org
>  https://news.povray.org/web.4991cc4af48fbafd81c811d20%40news.povray.org
>  https://news.povray.org/web.4991cc9e3aa58f3d81c811d20%40news.povray.org

Simply Elegant!

[Jim Henderson] Re: Nope, I STILL don't understand git branches [76 days 8 hours and 8 minutes ago]

Wed, 4 Feb 2026 02:02:44 GMT

On Tue,  3 Feb 2026 05:08:03 EST, Mr wrote:

> ....Just make sure you fully grasp the distinction and nature of Commit
> versus push!

100%.  I actually did my little test a few days ago without a remote even 
configured - because you can use git that way. :)

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

[Maetes] Re: Star catalogue [76 days 14 hours and 41 minutes ago]

Tue, 3 Feb 2026 19:30:00 GMT

yesbird wrote:
> And I found it:
>
http://vizier.cds.unistra.fr/viz-bin/VizieR-3?-source=VI/49/bound_18&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-
out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa
>
> --
> YB

Congrats!
Maybe use bound_20 (top-left in the select-box).
Thats the epoch, bounds_18 means 1875.

They are slightly different.
https://en.wikipedia.org/wiki/Epoch_(astronomy)#Epochs_and_periods_of_validity

Ma

[yesbird] Re: Star catalogue [76 days 16 hours and 52 minutes ago]

Tue, 3 Feb 2026 17:18:49 GMT

On 03/02/2026 18:15, yesbird wrote:
> On 03/02/2026 14:52, Maetes wrote:
>>
>> As I said, I haven't looked for it yet, but if I find something, I'll 
>> let you
>> know. I also made a PHP script with which I can create Povray arrays from
>> databases, if helpful. But it takes time, sorry.
>>
> 
> The most desired thing for me now is coordinates of constellation
> bounds, as I would like to store them as vectors to control separately -
> one by one, but not sure if such a thing exists anywhere.

And I found it:
http://vizier.cds.unistra.fr/viz-bin/VizieR-3?-source=VI/49/bound_18&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa

-- 
YB

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [76 days 18 hours and 24 minutes ago]

Tue, 3 Feb 2026 15:46:35 GMT

On 2026-02-03 05:57 (-4), Mr wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> But .gitignore is one aspect of git that has never given me any surprises.
> 
> The way it had for me, if my poor memory is correct, was some kind of wildcard
> that I wasn't aware I had used, and could apply ignore to a whole type of files
> instead of specific ones. But you're probably more cautious than that. :-)

Matter of fact, the wildcard feature has been a great organizational
tool for me.  My typical .gitignore entries include:
  *~
  /*/*
  /test_*

(The /*/* entry works for my Object Collection projects because Object
Collection contributions have no directory structure.)

[yesbird] Re: Star catalogue [76 days 18 hours and 55 minutes ago]

Tue, 3 Feb 2026 15:15:06 GMT

On 03/02/2026 14:52, Maetes wrote:
> 
> As I said, I haven't looked for it yet, but if I find something, I'll let you
> know. I also made a PHP script with which I can create Povray arrays from
> databases, if helpful. But it takes time, sorry.
> 

The most desired thing for me now is coordinates of constellation
bounds, as I would like to store them as vectors to control separately -
one by one, but not sure if such a thing exists anywhere.
-- 
YB

[yesbird] Re: Star catalogue [76 days 19 hours and 34 minutes ago]

Tue, 3 Feb 2026 14:36:55 GMT

On 03/02/2026 15:18, Maetes wrote:
> 
> Now I was curious myself and went on a short search.
> ...

Thanks, very well, I will examine it later, as now I am too busy with
coding. I have also registered in this serious astronomic community:
https://www.cloudynights.com/
and hope for their support.
--
YB

[yesbird] Re: Star catalogue [76 days 19 hours and 44 minutes ago]

Tue, 3 Feb 2026 14:26:21 GMT

On 03/02/2026 12:17, Mr wrote:
> This works insanely great on my phone :-) ! (as usual I had to open it there
> because your site is blocked from my corporate proxy :-/ )
> 

Glad to hear it, as I am now taking care about mobile platform(s) too.
In general, it will support desktops, mobiles and VR headsets.

But nothing to see there yet and it's only a template, which I am
turning into a real application very fast. Hope till Saturday it becomes
much more interesting :).
-- 
YB

[yesbird] Re: Star catalogue [76 days 19 hours and 51 minutes ago]

Tue, 3 Feb 2026 14:19:38 GMT

On 03/02/2026 14:52, Maetes wrote:
> 
> The keyword for coordinates and data is:
> NGC Catalogue.
> https://en.wikipedia.org/wiki/New_General_Catalogue

Thanks a lot, I have already taken and tested it, works fine with
AlaSQL, which I am using as a DB engine.

> 
> Images could be a problem, as I am not aware of any valid source that provides
> such data in a uniform format. Maybe it comes down to the fact that you have to
> search for them manually.
> But I can also be wrong, maybe there is something like that in the meantime. If
> I find something, I'll tell you.

Thanks again, I will start an intensive search after completing
application. Filling DB with the content will be an endless
procedure :).

> Chromium on a Raspberry Pi.
> I clicked somewhere and a Box opened with the text "Object" few million times,
> so my Pi was busy to show all text.
> And in dont want to risk it again, don't like crashes.

Sorry for the inconvenience, it was my fault - I forgot
to comment out debug info and all 13979 records of NGC were printed to
browser's page. Now it works fine - no more crashes, I promise :).
-- 
YB

[jr] Re: Star catalogue [76 days 20 hours and 21 minutes ago]

Tue, 3 Feb 2026 13:50:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...
> > <wiki.povray.org/content/Reference:Shell_Command_Options>
>
> I also have a similar workaround.
> A PHP script that converts an SQL database into an array.
> But it is a detour that is limited in flexibility.

my guess is that you will be able to use that code with (comparatively) little
adaptation.

> Nevertheless the reference to the shell commands is interesting, I didn't know
> them before.

in which case, likely, the default setting in the global 'povray.conf' will
"trip you up".  you have to set "[Shellout Security]" to 'allowed'.

> I'll take a look, maybe I can use my PHP script a little better
> with it.

:-).

regards, jr.

[Maetes] Re: Star catalogue [76 days 21 hours and 6 minutes ago]

Tue, 3 Feb 2026 13:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> one should be able to do this using an ini file, ie have a script executing a
> scene or frame specific query and write the result(s) to a POV-Ray-style CSV
> file, which would be available in the scene/frame for reading.
>
> <wiki.povray.org/content/Reference:Shell_Command_Options>

I also have a similar workaround.
A PHP script that converts an SQL database into an array.
But it is a detour that is limited in flexibility.

Nevertheless the reference to the shell commands is interesting, I didn't know
them before. I'll take a look, maybe I can use my PHP script a little better
with it.

Thanks,
m

[jr] Re: Star catalogue [76 days 21 hours and 36 minutes ago]

Tue, 3 Feb 2026 12:35:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ...
> If Povray could execute SQL queries - even if only simple selects - that would
> be really really nice.

one should be able to do this using an ini file, ie have a script executing a
scene or frame specific query and write the result(s) to a POV-Ray-style CSV
file, which would be available in the scene/frame for reading.

<wiki.povray.org/content/Reference:Shell_Command_Options>

regards, jr.

[Maetes] Re: Star catalogue [76 days 21 hours and 51 minutes ago]

Tue, 3 Feb 2026 12:20:00 GMT

Please ignore the last answer, I thought the forum had deleted the first block.
-----------


Now I was curious myself and went on a short search.

Maybe this is the original one:
https://heasarc.gsfc.nasa.gov/W3Browse/all/ngc2000.html

The data can be found here (ngc2000.dat):
https://cdsarc.cds.unistra.fr/ftp/cats/VII/118/


A newer version maybe is this here, but I havent found a download-file:
http://www.klima-luft.de/steinicke/ngcic/rev2000/Explan.htm

This one could be a competitor of yours:
https://cosmos-book.github.io/catalogue/NGC/index.html


ma

[Maetes] Re: Star catalogue [76 days 22 hours and 11 minutes ago]

Tue, 3 Feb 2026 12:00:00 GMT

yesbird wrote:
> Pictures of good quality with complete objects info, including
> coordinates. This will be a gallery with a pointer to the object's
> location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
> but other sources also can help. This will be a long-term project ...

The keyword for coordinates and data is:
NGC Catalogue.
https://en.wikipedia.org/wiki/New_General_Catalogue

As I said, I haven't looked for it yet, but if I find something, I'll let you
know. I also made a PHP script with which I can create Povray arrays from
databases, if helpful. But it takes time, sorry.

ma

[Maetes] Re: Star catalogue [76 days 22 hours and 11 minutes ago]

Tue, 3 Feb 2026 12:00:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> I think such a thing would be awesome delivered with POV-Ray out of the box!

If Povray could execute SQL queries - even if only simple selects - that would
be really really nice.

It's on my (unpublished) wish list.


Ma

[Maetes] Re: Star catalogue [76 days 22 hours and 16 minutes ago]

Tue, 3 Feb 2026 11:55:00 GMT

yesbird wrote:

> Pictures of good quality with complete objects info, including
> coordinates. This will be a gallery with a pointer to the object's
> location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
> but other sources also can help. This will be a long-term project ...

The keyword for coordinates and data is:
NGC Catalogue.
https://en.wikipedia.org/wiki/New_General_Catalogue

As I said, I haven't looked for it yet, but if I find something, I'll let you
know. I also made a PHP script with which I can create Povray arrays from
databases, if helpful. But it takes time, sorry.

Images could be a problem, as I am not aware of any valid source that provides
such data in a uniform format. Maybe it comes down to the fact that you have to
search for them manually.
But I can also be wrong, maybe there is something like that in the meantime. If
I find something, I'll tell you.

> Possible, as it's in a very early state of development.
> What browser do you have (including a platform) and could you
> please send me console content (F12) ?
> --
> YB

Chromium on a Raspberry Pi.
I clicked somewhere and a Box opened with the text "Object" few million times,
so my Pi was busy to show all text.
And in dont want to risk it again, don't like crashes.

ma

[Mr] Re: Nope, I STILL don't understand git branches [77 days and 1 minute ago]

Tue, 3 Feb 2026 10:10:00 GMT

One other thing I notice when quickly going through this discussion, has been
left out of it, maybe because too "obvious" or people around here generally
better at it than I was (^-^), also you'd have had other issues if that was your
blind spot... but I remember it was one of the slightly confusing cornerstones
for me initially, so I do feel compelled to write about it:

....Just make sure you fully grasp the distinction and nature of Commit versus
push!

[Mr] Re: Nope, I STILL don't understand git branches [77 days and 11 minutes ago]

Tue, 3 Feb 2026 10:00:00 GMT

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

> But .gitignore is one aspect of git that has never given me any surprises.

The way it had for me, if my poor memory is correct, was some kind of wildcard
that I wasn't aware I had used, and could apply ignore to a whole type of files
instead of specific ones. But you're probably more cautious than that. :-)

[Mr] Re: Nope, I STILL don't understand git branches [77 days and 26 minutes ago]

Tue, 3 Feb 2026 09:45:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2026-01-30 22:42 (-4), Bill Pragnell wrote:
> > Jim Henderson <nos### [at] nospamcom> wrote:
> >> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
> >>> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> >>>> But it looks like the file is tracked, so any changes to it made in one
> >>>> branch shouldn't affect other branches,
> >
> > Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> > git-speak) refers to an edit, without any git interaction, which is what I've
> > been assuming. A change to a branch is usually called a 'commit', and that will
> > indeed be unique to the branch.
> >
> >>> I'm sensing disagreement in what "tracked" means.  Jim is using
> >>> "tracked" the way I've understood it, but Bill is describing the
> >>> behavior I'm seeing from git.
> >
> > I think git itself may also be confusing the issue here. 'Tracked' just means
> > the file has been added to the repo. If I add a new file to a project (without
> > git interaction - just make a new file within a repo), it is listed as
> > 'untracked' because it does not yet have an entry in the repo - its entire
> > contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
> > then 'tracked' as part of that branch from that point on. But you could say that
> > even an 'untracked' file is tracked in the sense of git being aware of it,
> > because it appears in the status. Only files/directories in .gitignore are truly
> > untracked because edits to them will be ignored.
> >
> > Uncommitted changes (i.e. edits to a file) will not be affected by switching
> > branches, unless there is a conflict - i.e. if the edits apply to a section of a
> > file that is different in the two branches. In that case, git will not switch
> > branches, but instead tell you to commit or 'stash' your changes before
> > switching (stashing is saving your changes on a temp stack rather than
> > committing them).
> >
> > Sorry if I'm muddying the water here! I remember being quite confused about how
> > git worked when I first started using it.
>
> No, this is very helpful!  Thank you!
>
> (And I just watched a video about how pilots and air traffic controllers
> unknowingly disagreed on definitions of terms, and the result was a
> major crash, all souls lost.)

Yes, that's good clear explanations, the topic itself is complex, and there is a
threshold to it, a kind of "Gestalt" that needs to be reached before one starts
to feel you gain more with all that complexity despite it's learning curve, and
after you reach it, you don't have to become expert/power-user to be okay. you
end up developing a cautious intuition of what features to stay away from vs the
ones to dive into until you do have more time :-D  I still consider myself very
much of a beginner, but still admire and enjoy this tool!

[Mr] Re: Cutty Sark [77 days and 41 minutes ago]

Tue, 3 Feb 2026 09:30:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> And a photo of the complete ship.
>
> Cheers
> Ton

Hi this is taking great shape !

Sorry if I'm mistaken, but except the black ones, all texture appear to me way
too brightly diffuse, did you use assumed gamma 1 with srgb colors all along,
and albedo keyword? overall reflectivity (diffuse+specular/phong) should
generally be below 0.2 for common non reflective materials.

[Mr] Re: Star catalogue [77 days and 51 minutes ago]

Tue, 3 Feb 2026 09:20:00 GMT

"Maetes" <nomail@nomail> wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array.
>
> Documented more thoroughly than I would like, took way too long, as always.
>
> A macro collection that makes use of it is in the works.
>
> See:
> https://www.maetes.com/en/download/hyg-lite-star-catalogue
>
> That's the damn reason why I don't have time to build damn spaceships.
>
> :)
>
> Ma

I think such a thing would be awesome delivered with POV-Ray out of the box!

[Mr] Re: Star catalogue [77 days and 51 minutes ago]

Tue, 3 Feb 2026 09:20:00 GMT

yesbird wrote:
> On 08/12/2025 02:45, Maetes wrote:
> > If anyone wants to try their hand at creating a real starry sky with simulated
> > stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> > into a Povray array. ...
>
> Hi, Maetes.
>
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
>
> I am expected that it should be informative and compact enough,
> also includes deep sky objects like nebulas and galaxies, but
> assume that it will be not for professional use, but mostly addressed
> to schoolchildren and students just for fun.
>
> Could you suggest such a data source ?
> --
> YB

This works insanely great on my phone :-) ! (as usual I had to open it there
because your site is blocked from my corporate proxy :-/ )

[Mr] Re: Fan art: Trevor G Quayle's rainbow [77 days 1 hour and 1 minute ago]

Tue, 3 Feb 2026 09:10:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I created SpectralRender interpretations of Trevor G Quayle's rainbows
> from 2008-2009.  The marble pigment is by Tek.
>
> Original posts:
>  https://news.povray.org/web.492eba0f4cea9e2d81c811d20%40news.povray.org
>  https://news.povray.org/web.49302a15d3e0b85381c811d20%40news.povray.org
>  https://news.povray.org/web.4991cc4af48fbafd81c811d20%40news.povray.org
>  https://news.povray.org/web.4991cc9e3aa58f3d81c811d20%40news.povray.org

You do justice to POV-Ray potential, and only such high quality standard images
should be allowed from now on :-)

The only thing that could, I believe, make it even better would be lowering the
diffuse value of the ground's marble and darkening just as much the foggy
background. Maybe even just inverting the black and white on that Marble !

[kurtz le pirate] Re: Fan art: Trevor G Quayle's rainbow [77 days 3 hours ago]

Tue, 3 Feb 2026 07:10:52 GMT

On 02/02/2026 00:59, Cousin Ricky wrote:
> I created SpectralRender interpretations of Trevor G Quayle's rainbows
> from 2008-2009.  The marble pigment is by Tek.
> 
> Original posts:
>   https://news.povray.org/web.492eba0f4cea9e2d81c811d20%40news.povray.org
>   https://news.povray.org/web.49302a15d3e0b85381c811d20%40news.povray.org
>   https://news.povray.org/web.4991cc4af48fbafd81c811d20%40news.povray.org
>   https://news.povray.org/web.4991cc9e3aa58f3d81c811d20%40news.povray.org


As usual, beautiful lighting.



-- 
kurtz le pirate
compagnie de la banquise

[yesbird] Re: Star catalogue [77 days 5 hours and 11 minutes ago]

Tue, 3 Feb 2026 04:59:52 GMT

On 02/02/2026 20:19, Bald Eagle wrote:
> "Maetes" <nomail@nomail> wrote:
> 
> I did 655,000 minor planets as part of my solar system model:
> 
> https://news.povray.org/web.592d5e424e850994c437ac910%40news.povray.org
>

Thanks, Bill, very interesting source, I've saved it to bookmarks.
Maybe I will use it later, after filling the database with larger
objects :).
--
YB

[yesbird] Re: Star catalogue [77 days 5 hours and 14 minutes ago]

Tue, 3 Feb 2026 04:56:36 GMT

On 02/02/2026 17:14, Maetes wrote:
> Maybe.
> What are you looking for exactly?
> Position-Data?
> Pictures of the objects?

Pictures of good quality with complete objects info, including
coordinates. This will be a gallery with a pointer to the object's
location on the sky sphere. Now I rely mostly on NASA/Hubble materials,
but other sources also can help. This will be a long-term project ...

> Your Planetarium crashed my browser!

Possible, as it's in a very early state of development.
What browser do you have (including a platform) and could you
please send me console content (F12) ?
-- 
YB

[Bald Eagle] Re: Star catalogue [77 days 16 hours and 51 minutes ago]

Mon, 2 Feb 2026 17:20:00 GMT

"Maetes" <nomail@nomail> wrote:

I did 655,000 minor planets as part of my solar system model:

https://news.povray.org/web.592d5e424e850994c437ac910%40news.povray.org

- BE

[Maetes] Re: Star catalogue [77 days 19 hours and 56 minutes ago]

Mon, 2 Feb 2026 14:15:00 GMT

yesbird wrote:
> Thank you for sharing this data. Really, I am looking for good
> data source for my present Virtual planetary project:
> https://yesbird.online/planetarium/
>
> Could you suggest such a data source ?
> --
> YB

Maybe.
What are you looking for exactly?
Position-Data?
Pictures of the objects?

However, I haven't cared about deep sky objects so far, rather stars, exoplanets
and stuff like that. Describe in more detail what you would like to have, then I
can take a look for you during my search for my own data sources. I found so
much crap and didn't find it what I need, I'm slowly developing some practice.

Your Planetarium crashed my browser!

:)

Ma

[Cousin Ricky] Fan art: Trevor G Quayle's rainbow [78 days 10 hours and 11 minutes ago]

Sun, 1 Feb 2026 23:59:54 GMT

I created SpectralRender interpretations of Trevor G Quayle's rainbows
from 2008-2009.  The marble pigment is by Tek.

Original posts:
 https://news.povray.org/web.492eba0f4cea9e2d81c811d20%40news.povray.org
 https://news.povray.org/web.49302a15d3e0b85381c811d20%40news.povray.org
 https://news.povray.org/web.4991cc4af48fbafd81c811d20%40news.povray.org
 https://news.povray.org/web.4991cc9e3aa58f3d81c811d20%40news.povray.org

[Chris] Re: Browser-based POV-Ray Scene Editor (v0.3.8.2... [78 days 10 hours and 56 minutes ago]

Sun, 1 Feb 2026 23:15:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "Chris" <esc### [at] gmailcom> wrote:
> > Here is a refactored version of the monolithic file, organized into labeled
> > sections with comments.
> > The main JS header/module index begins at line ~209 (after the HTML/CSS block)
> > and has the details.
>
> Hi, not sure what to expect nor look at... I tried the biscuit scene and chess2
> which provide very little to no resemblance to what they should look like.
>
> The interface is impressive, wouldn't it be nicer with keyboard arrows moving
> from a selected element to the ones above and below? maybe a tab key to switch
> as well?

Spent the last month working with Claude Co-Work and GPT5.2 refining code for
work and other projects... and think I have more of an idea on this.. but will
revisit it..

Basically - Claude co-work, given the POV documentation and full directory tree
- and ideally- the MORAY source, should have a better chance of generating
something functional. The main issue right now is that there isnt a starting
point for the AI to determine where it is and isnt getting the CSG right... and
I havent had time to train it.

I think the first step is - just getting a reliable representation of CSG that
looks correct.. once that is in place - the rest will build itsself.

- Chris

[yesbird] Re: Star catalogue [79 days and 28 minutes ago]

Sun, 1 Feb 2026 09:42:45 GMT

On 08/12/2025 02:45, Maetes wrote:
> If anyone wants to try their hand at creating a real starry sky with simulated
> stars, I've trimmed the HYG star catalogue (120,000 entries) a bit and turned it
> into a Povray array. ...

Hi, Maetes.

Thank you for sharing this data. Really, I am looking for good
data source for my present Virtual planetary project:
https://yesbird.online/planetarium/

I am expected that it should be informative and compact enough,
also includes deep sky objects like nebulas and galaxies, but
assume that it will be not for professional use, but mostly addressed
to schoolchildren and students just for fun.

Could you suggest such a data source ?
--
YB

[Ton] Re: Starfield-Animations - WIP [79 days 1 hour and 6 minutes ago]

Sun, 1 Feb 2026 09:05:00 GMT

"Maetes" <nomail@nomail> wrote:
> I've finally found some time to work on my old star field animations.
> They are far from what I would like them to be, but at least they are colorful
> now!
>
> 4 Videos, 2  normal and 2 stereo, and some more informations:
> https://www.maetes.com/en/blog/our-stellar-red-neighborhood
>
> One animation shows stars and so-called brown dwarfs within a radius of 20 light
> years (see example image), the second one in 100 light years.
>
> Have a nice day,
> M

Hallo Maetes

an interesting way of star-gazing.

Cheers
Ton

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [79 days 5 hours and 2 minutes ago]

Sun, 1 Feb 2026 05:08:42 GMT

On 2026-01-30 22:42 (-4), Bill Pragnell wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
>>> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>>>> But it looks like the file is tracked, so any changes to it made in one
>>>> branch shouldn't affect other branches,
> 
> Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> git-speak) refers to an edit, without any git interaction, which is what I've
> been assuming. A change to a branch is usually called a 'commit', and that will
> indeed be unique to the branch.
> 
>>> I'm sensing disagreement in what "tracked" means.  Jim is using
>>> "tracked" the way I've understood it, but Bill is describing the
>>> behavior I'm seeing from git.
> 
> I think git itself may also be confusing the issue here. 'Tracked' just means
> the file has been added to the repo. If I add a new file to a project (without
> git interaction - just make a new file within a repo), it is listed as
> 'untracked' because it does not yet have an entry in the repo - its entire
> contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
> then 'tracked' as part of that branch from that point on. But you could say that
> even an 'untracked' file is tracked in the sense of git being aware of it,
> because it appears in the status. Only files/directories in .gitignore are truly
> untracked because edits to them will be ignored.
> 
> Uncommitted changes (i.e. edits to a file) will not be affected by switching
> branches, unless there is a conflict - i.e. if the edits apply to a section of a
> file that is different in the two branches. In that case, git will not switch
> branches, but instead tell you to commit or 'stash' your changes before
> switching (stashing is saving your changes on a temp stack rather than
> committing them).
> 
> Sorry if I'm muddying the water here! I remember being quite confused about how
> git worked when I first started using it.

No, this is very helpful!  Thank you!

(And I just watched a video about how pilots and air traffic controllers
unknowingly disagreed on definitions of terms, and the result was a
major crash, all souls lost.)

[Jim Henderson] Re: Nope, I STILL don't understand git branches [80 days 4 hours and 3 minutes ago]

Sat, 31 Jan 2026 06:07:54 GMT

On 31 Jan 2026 00:55:13 -0500, Jim Henderson wrote:

> On 31 Jan 2026 00:52:22 -0500, Jim Henderson wrote:
> 
>> This is what I'm used to seeing.  But my usage generally had me making
>> changes within a branch, not creating the branch myself, and then the
>> developer who created the branch would merge things back (my main use
>> case for this was years ago creating in-product text strings for
>> documentation purposes - tooltips and the like).
> 
> I think I understand better now - once I committed the changes to
> master, then the branch I created (test1) "reverted" to what was
> originally in the file when I branched it (ie, it was empty).

So it seems to be that once a file is modified and then committed to a 
branch, then changes to it will require a stash or commit before changing 
branches again.

I probably never ran into this since the files I was modifying had already 
been through many iterations by the time I saw them.  But it makes logical 
sense to me that each branch isn't a full copy of everything in the state 
at which it was first added, and that it would be consistent across 
branches until it was changed in one of them.

I'd guess that if a change were committed in 'branch1' and you switched 
back to 'master' where it wasn't committed, and created a new branch 
'branch2', that the behavior would be consistent as well, at least until 
'branch1' was merged back into 'master'.

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

[Jim Henderson] Re: Nope, I STILL don't understand git branches [80 days 4 hours and 15 minutes ago]

Sat, 31 Jan 2026 05:55:13 GMT

On 31 Jan 2026 00:52:22 -0500, Jim Henderson wrote:

> This is what I'm used to seeing.  But my usage generally had me making
> changes within a branch, not creating the branch myself, and then the
> developer who created the branch would merge things back (my main use
> case for this was years ago creating in-product text strings for
> documentation purposes - tooltips and the like).

I think I understand better now - once I committed the changes to master, 
then the branch I created (test1) "reverted" to what was originally in the 
file when I branched it (ie, it was empty).



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

[Jim Henderson] Re: Nope, I STILL don't understand git branches [80 days 4 hours and 18 minutes ago]

Sat, 31 Jan 2026 05:52:22 GMT

On Fri, 30 Jan 2026 21:42:09 EST, Bill Pragnell wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
>> > On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>> >> But it looks like the file is tracked, so any changes to it made in
>> >> one branch shouldn't affect other branches,
> 
> Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
> git-speak) refers to an edit, without any git interaction, which is what
> I've been assuming. A change to a branch is usually called a 'commit',
> and that will indeed be unique to the branch.

No, that's what I'm calling a change - an edit to the file.

>> > I'm sensing disagreement in what "tracked" means.  Jim is using
>> > "tracked" the way I've understood it, but Bill is describing the
>> > behavior I'm seeing from git.
> 
> I think git itself may also be confusing the issue here. 'Tracked' just
> means the file has been added to the repo. If I add a new file to a
> project (without git interaction - just make a new file within a repo),
> it is listed as 'untracked' because it does not yet have an entry in the
> repo - its entire contents are a 'change'. If I 'git add' and then 'git
> commit' that file, it is then 'tracked' as part of that branch from that
> point on. But you could say that even an 'untracked' file is tracked in
> the sense of git being aware of it, because it appears in the status.
> Only files/directories in .gitignore are truly untracked because edits
> to them will be ignored.

Hmmm.  I just created a quick test repo, and it's not working the way I 
remembered it, but it is working the way you're describing and CR is 
saying is happening for his setup, too.

> Uncommitted changes (i.e. edits to a file) will not be affected by
> switching branches, unless there is a conflict - i.e. if the edits apply
> to a section of a file that is different in the two branches. In that
> case, git will not switch branches, but instead tell you to commit or
> 'stash' your changes before switching (stashing is saving your changes
> on a temp stack rather than committing them).

This is what I'm used to seeing.  But my usage generally had me making 
changes within a branch, not creating the branch myself, and then the 
developer who created the branch would merge things back (my main use case 
for this was years ago creating in-product text strings for documentation 
purposes - tooltips and the like).

I've used it a fair bit on my own since then, but generally haven't needed 
to branch since the stuff I'm using it for is all for my own amusement.

> Sorry if I'm muddying the water here! I remember being quite confused
> about how git worked when I first started using it.
> 
> Bill

No worries, you got me to actually try it and see, and it wasn't matching 
my memory.  Show now I need to figure out why my memory is different than 
what I actually saw in my simple test.

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

[Bill Pragnell] Re: Nope, I STILL don't understand git branches [80 days 7 hours and 26 minutes ago]

Sat, 31 Jan 2026 02:45:00 GMT

Jim Henderson <nos### [at] nospamcom> wrote:
> On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:
> > On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> >> But it looks like the file is tracked, so any changes to it made in one
> >> branch shouldn't affect other branches,

Are we confusing our usage of 'change' perhaps? A 'change' to a file (in
git-speak) refers to an edit, without any git interaction, which is what I've
been assuming. A change to a branch is usually called a 'commit', and that will
indeed be unique to the branch.

> > I'm sensing disagreement in what "tracked" means.  Jim is using
> > "tracked" the way I've understood it, but Bill is describing the
> > behavior I'm seeing from git.

I think git itself may also be confusing the issue here. 'Tracked' just means
the file has been added to the repo. If I add a new file to a project (without
git interaction - just make a new file within a repo), it is listed as
'untracked' because it does not yet have an entry in the repo - its entire
contents are a 'change'. If I 'git add' and then 'git commit' that file, it is
then 'tracked' as part of that branch from that point on. But you could say that
even an 'untracked' file is tracked in the sense of git being aware of it,
because it appears in the status. Only files/directories in .gitignore are truly
untracked because edits to them will be ignored.

Uncommitted changes (i.e. edits to a file) will not be affected by switching
branches, unless there is a conflict - i.e. if the edits apply to a section of a
file that is different in the two branches. In that case, git will not switch
branches, but instead tell you to commit or 'stash' your changes before
switching (stashing is saving your changes on a temp stack rather than
committing them).

Sorry if I'm muddying the water here! I remember being quite confused about how
git worked when I first started using it.

Bill

[Maetes] Re: Lunar Crater Catalogue - LCC V1.0 [80 days 18 hours and 41 minutes ago]

Fri, 30 Jan 2026 15:30:00 GMT

Another example-image

[Maetes] Lunar Crater Catalogue - LCC V1.0 [80 days 18 hours and 46 minutes ago]

Fri, 30 Jan 2026 15:25:00 GMT

On my website I have deposited a database with more or less all lunar craters
and other features bigger than 1 kilometer.

It can be downloaded as an SQL import file and in the form of a long Povray
array inside a text file. Both contain almost 9000 entries.

https://www.maetes.com/en/blog/lunar-crater-catalogue-lcc-version-1

Greetings,
M

[Maetes] Re: Cutty Sark [80 days 19 hours and 21 minutes ago]

Fri, 30 Jan 2026 14:50:00 GMT

"Ton" <ton### [at] gmailcom> wrote:
> Fife rails and the bilge-pump are done.
> Two more winches, and it's time for the deck houses.

Great progress, as always.
It's fascinating to see how much work you put into details.

When is the launch planned?

Mar

[Maetes] Starfield-Animations - WIP [80 days 19 hours and 31 minutes ago]

Fri, 30 Jan 2026 14:40:00 GMT

I've finally found some time to work on my old star field animations.
They are far from what I would like them to be, but at least they are colorful
now!

4 Videos, 2  normal and 2 stereo, and some more informations:
https://www.maetes.com/en/blog/our-stellar-red-neighborhood

One animation shows stars and so-called brown dwarfs within a radius of 20 light
years (see example image), the second one in 100 light years.

Have a nice day,
M

[jr] Re: Cutty Sark [82 days 2 hours and 36 minutes ago]

Thu, 29 Jan 2026 07:35:00 GMT

hi,

"Ton" <ton### [at] gmailcom> wrote:
> Fife rails and the bilge-pump are done.
> Two more winches, and it's time for the deck houses.

thanks for posting these updates, I love the "photo".


regards, jr.

[Ton] Re: Cutty Sark [83 days 8 hours and 16 minutes ago]

Wed, 28 Jan 2026 01:55:00 GMT

And a photo of the complete ship.

Cheers
Ton

[Ton] Re: Cutty Sark [83 days 8 hours and 21 minutes ago]

Wed, 28 Jan 2026 01:50:00 GMT

Fife rails and the bilge-pump are done.
Two more winches, and it's time for the deck houses.

Cheers
Ton

[Jim Henderson] Re: Nope, I STILL don't understand git branches [83 days 11 hours and 12 minutes ago]

Tue, 27 Jan 2026 22:58:07 GMT

On Tue, 27 Jan 2026 10:02:14 -0400, Cousin Ricky wrote:

> On 2026-01-26 02:00 (-4), Jim Henderson wrote:
>> On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:
>>>
>>> An untracked file is just a big change after all.
>> 
>> But it looks like the file is tracked, so any changes to it made in one
>> branch shouldn't affect other branches, unless they're either not
>> tracked (which isn't the case) or in .gitignore (which would *probably*
>> require it to have been explicitly added in some way, and I expect CR
>> would know if he'd done that).
> 
> I'm sensing disagreement in what "tracked" means.  Jim is using
> "tracked" the way I've understood it, but Bill is describing the
> behavior I'm seeing from git.
> 
> But .gitignore is one aspect of git that has never given me any
> surprises.

Can you describe the workflow you're using, step by step - commands 
executed, and so on - in order to try to reproduce what you're seeing?


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

[Yvo Smellenbergh] Re: POV-Ray 3.8 and 3.7.0.9 update available [83 days 19 hours and 31 minutes ago]

Tue, 27 Jan 2026 14:39:11 GMT

On 2026-01-27 08:54:32 +0000, kurtz le pirate said:

> 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?c

POV-Ray is a universal binary, so it is not limited to â€œApple
Siliconâ€ 
only, but supports both Intel and Apple Silicon.
There are no specific compiler options used per CPU type (such as 
-mcpu=apple-m1 or -mcpu=apple-m2).
Using such options could cause POV-Ray to no longer work on older Apple 
Silicon chips.
Moreover, any performance gain would be minimal.
-- 
Yvo

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


https://povrayunofficial.wordpress.com
E-mail: yvo(DOT)s(AT)gmx.net

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [83 days 20 hours and 8 minutes ago]

Tue, 27 Jan 2026 14:02:15 GMT

On 2026-01-26 02:00 (-4), Jim Henderson wrote:
> On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:
>>
>> An untracked file is just a big change after all.
> 
> But it looks like the file is tracked, so any changes to it made in one 
> branch shouldn't affect other branches, unless they're either not tracked 
> (which isn't the case) or in .gitignore (which would *probably* require it 
> to have been explicitly added in some way, and I expect CR would know if 
> he'd done that).

I'm sensing disagreement in what "tracked" means.  Jim is using
"tracked" the way I've understood it, but Bill is describing the
behavior I'm seeing from git.

But .gitignore is one aspect of git that has never given me any surprises.

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [83 days 20 hours and 17 minutes ago]

Tue, 27 Jan 2026 13:53:40 GMT

On 2026-01-26 18:44 (-4), Bill Pragnell wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:
>>
>>> The files README.md, gemcuts.pov, and gemcuts_description.txt were
>>> modified while one branch was checked out, and the changes show in the
>>> other branch as well.
>>
>> Hmm.  I guess then we'd need to see what the status looks like from each
>> branch.  What you're seeing isn't consistent with my experience, at least.
> 
> I think that's what I would expect. If the changes don't have conflicts with any
> of the other branches then switching branches makes no difference, the changes
> will be left alone (unless there is a conflict, then git will warn you to commit
> your changes or lose them when switching branch). If you commit the changes to a
> branch, then you'll only see those changes on that branch - and now they won't
> be listed as changes by 'git status' any more.

This is exactly what I've seen since Sunday.

> An untracked file is just a big change after all.

[kurtz le pirate] Re: Tahoe 26.1 [84 days 1 hour and 11 minutes ago]

Tue, 27 Jan 2026 08:59:30 GMT

On 09/01/2026 18:29, yvo (DOT) s (AT) gmx.net wrote:

> Hi,
> 
> 
> Is your issue solved?
> I had exactly the same issue under Tahoe. It was related to the option 
> in the Preferences panel >> Misc tab, â€œRedirect All Output Images
To 
> This Folderâ€. The path to the folder was incorrect.
> The path was wrong; for some reason my output folder was located 
> somewhere else.
> 
> It is also often related to permissions, so in any case check whether 
> the location where the file needs to be written is available and that 
> you have the correct permissions.
> 
> If you are not using the option in the Misc tab, check where the input 
> file is located; the output will then be written to that same location.
> 
> I also see that you are using version 3.8.0-alpha.9606898.unofficial, 
> which comes from the site http://megapov.inetart.net/ 
> povrayunofficial_mac/ <http://megapov.inetart.net/povrayunofficial_mac/ 
>  >. This is a very old version.
> Only use the newer versions that you can find here: https:// 
> povrayunofficial.wordpress.com <https://povrayunofficial.wordpress.com/>



Try creating a "POV" folder in your home directory and not in 
Application folder.

Put program on it and try to render.
Of course, set correct paths in Preferences -> System Include.





-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: POV-Ray 3.8 and 3.7.0.9 update available [84 days 1 hour and 16 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

[Jim Henderson] Re: Nope, I STILL don't understand git branches [84 days 4 hours and 10 minutes ago]

Tue, 27 Jan 2026 06:00:46 GMT

On Mon, 26 Jan 2026 17:44:27 EST, Bill Pragnell wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:
>>
>> > The files README.md, gemcuts.pov, and gemcuts_description.txt were
>> > modified while one branch was checked out, and the changes show in
>> > the other branch as well.
>>
>> Hmm.  I guess then we'd need to see what the status looks like from
>> each branch.  What you're seeing isn't consistent with my experience,
>> at least.
> 
> I think that's what I would expect. If the changes don't have conflicts
> with any of the other branches then switching branches makes no
> difference, the changes will be left alone (unless there is a conflict,
> then git will warn you to commit your changes or lose them when
> switching branch). If you commit the changes to a branch, then you'll
> only see those changes on that branch - and now they won't be listed as
> changes by 'git status' any more.
> 
> An untracked file is just a big change after all.

But it looks like the file is tracked, so any changes to it made in one 
branch shouldn't affect other branches, unless they're either not tracked 
(which isn't the case) or in .gitignore (which would *probably* require it 
to have been explicitly added in some way, and I expect CR would know if 
he'd done that).
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

[Cousin Ricky] SpectralRender dispersion graphs [84 days 11 hours and 12 minutes ago]

Mon, 26 Jan 2026 22:58:10 GMT

Image srdispersion.png gives a visual impression of the non-linearity of
refractive index with respect to wavelength.  The thicker lines
represent 700, 600, 500, and 400 nanometers, left to right.

Corundum (IOR_Ruby), topaz (IOR_Topaz), and quartz (IOR_Amethyst) have a
suspicious regularity to them.  I suspect Ive was working with
incomplete data for these.  Does anyone have better data?

Note that IOR_Sapphire in spectral_minerals.inc has dodgy IORs for 380
and 390 nm.  These wavelengths are nearly invisible to the human eye;
but if they are important to you, then use M_Gem (D_Sapphire, IOR_Ruby,
fade_distance) for sapphire instead of M_Sapphire, as ruby and sapphire
are essentially the same mineral, differing only by their impurities.

Image glass_survey.jpg is a render of the spectra of the glass materials
in SpectralRender.

[Bill Pragnell] Re: Nope, I STILL don't understand git branches [84 days 11 hours and 26 minutes ago]

Mon, 26 Jan 2026 22:45:00 GMT

Jim Henderson <nos### [at] nospamcom> wrote:
> On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:
>
> > The files README.md, gemcuts.pov, and gemcuts_description.txt were
> > modified while one branch was checked out, and the changes show in the
> > other branch as well.
>
> Hmm.  I guess then we'd need to see what the status looks like from each
> branch.  What you're seeing isn't consistent with my experience, at least.

I think that's what I would expect. If the changes don't have conflicts with any
of the other branches then switching branches makes no difference, the changes
will be left alone (unless there is a conflict, then git will warn you to commit
your changes or lose them when switching branch). If you commit the changes to a
branch, then you'll only see those changes on that branch - and now they won't
be listed as changes by 'git status' any more.

An untracked file is just a big change after all.

Bill

[Kenneth] Re: arbitrary camera path in animation [84 days 16 hours and 6 minutes ago]

Mon, 26 Jan 2026 18:05:00 GMT

Anton Sherwood <bro### [at] poboxcom> wrote:
> >
> > Can I define an array of points and have the camera shoot from each of them?
>
> .. oh i think i found it in the docs.

Did you find the Spline_Trans(...) macro, in 'transforms.inc'?

That is what I would use. It takes a spline--made from your designated points--
then the macro is used in a camera, which will follow the spline.

There is a nice animated demonstration scene included with POV-ray, called
'splinefollow.pov', in scenes\animations. Take a look.

[Mr] Re: Nope, I STILL don't understand git branches [85 days 1 hour and 36 minutes ago]

Mon, 26 Jan 2026 08:35:00 GMT

> On 1/24/26 18:25, Bill Pragnell wrote:
>     And have a look at the ".gitignore" file documentation.

Indeed, in that case I would tend to highly suspect the gitignore, which can
feature very wide filters preventing files of some type of some naming patterns
to be normally flagged as untracked... OR you may also have git stash->pop
....ped over several branches. because stash can act as a bucket to port things
from one branch to another.

If you want to have other graphic views of your repos and stash black box, you
can also try :

* Gitlens with VScode/VSCodium or
* Git kraken, which looks awesome but somewhat limits its longterm featureset in
the long run.

-So Git-Cola rules for its cross platform, and free as in freesdom policies...
But mostly, don't forget its "DAG" visualisation for all your branches.

[Anton Sherwood] Re: arbitrary camera path in animation [85 days 5 hours and 52 minutes ago]

Mon, 26 Jan 2026 04:18:47 GMT

>> On 2026-01-25 12:04, Anton Sherwood wrote:
 >>> The mesh for the attached image was generated by a program.  I would
 >>> like to make a simple animation with the camera following the path.
 >>>
 >>> Can I define an array of points and have the camera
 >>> shoot from each of them?

(I don't remember ever using an array before in povray)


On 2026-01-25 13:35, Leroy wrote:
 > It all depends on the program that wrote the mesh and what values
 > you have access to. [...]

Ah, well, I wrote the program, so I have whatever access I want.
(It's a special-purpose program, not a general modeller.)


 > I noticed that the mesh intersects itself a lot and the camera
 > could run into it if care is not taken.

I'll take points in the middle of the 'beams' (which are generated 
first) and double them to get the camera positions.


 > I wrote this up and hit preview and it kicked me out.
 > So I came back and this:

 > Anton Sherwood <bro### [at] poboxcom> wrote:
 >> .. oh i think i found it in the docs.

 > I'm posting this any way!  Sorry, I hate to waste typing!

May it be of use to someone!


-- 
*\\* Anton Sherwood *\\* bendwavy.org

[Leroy] Re: arbitrary camera path in animation [85 days 12 hours and 31 minutes ago]

Sun, 25 Jan 2026 21:40:00 GMT

Anton Sherwood <bro### [at] poboxcom> wrote:
> On 2026-01-25 12:04, Anton Sherwood wrote:
> > The mesh for the attached image was generated by a program.  I would
> > like to make a simple animation with the camera following the path.
> >
> > Can I define an array of points and have the camera shoot from each of them?
>

It all depends on the program that wrote the mesh and what values you have
access to. It also depends on how good you want the simple animation to be.
 If it was wrote with a spline and you have access to it. It wouldn't be much
trouble to make your own spline to move the camera while looking at the old
spline.
 If the mesh was made with a function again if you have access you could make an
array of points that can be use.
 If all you have is the mesh then finding those points you want maybe a little
difficult. But not impossible. It all depends on how the mesh was made. If the
mesh is a POV mesh2 then all the point are in one place and you could go through
them and throw away all but the ones you need. A lot of work but could be done.

I noticed that the mesh intersects itself a lot and the camera could run into it
if care is not taken.

Have Fun!

I wrote this up and hit preview and it kicked me out. So I came back and this:
> .. oh i think i found it in the docs.
I'm posting this any way!  Sorry, I hate to waste typing!

[Anton Sherwood] Re: arbitrary camera path in animation [85 days 13 hours and 39 minutes ago]

Sun, 25 Jan 2026 20:31:44 GMT

On 2026-01-25 12:04, Anton Sherwood wrote:
> The mesh for the attached image was generated by a program.  I would
> like to make a simple animation with the camera following the path.
> 
> Can I define an array of points and have the camera shoot from each of them?

.. oh i think i found it in the docs.

[Anton Sherwood] arbitrary camera path in animation [85 days 14 hours and 6 minutes ago]

Sun, 25 Jan 2026 20:04:20 GMT

The mesh for the attached image was generated by a program.  I would 
like to make a simple animation with the camera following the path.

Can I define an array of points and have the camera shoot from each of them?

-- 
*\\* Anton Sherwood *\\* https://bendwavy.org/

[Jim Henderson] Re: Nope, I STILL don't understand git branches [85 days 17 hours and 24 minutes ago]

Sun, 25 Jan 2026 16:46:51 GMT

On Sat, 24 Jan 2026 23:56:33 -0400, Cousin Ricky wrote:

> The files README.md, gemcuts.pov, and gemcuts_description.txt were
> modified while one branch was checked out, and the changes show in the
> other branch as well.

Hmm.  I guess then we'd need to see what the status looks like from each 
branch.  What you're seeing isn't consistent with my experience, at least.



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

[jr] Re: Nope, I STILL don't understand git branches [85 days 22 hours and 56 minutes ago]

Sun, 25 Jan 2026 11:15:00 GMT

hi,

tTh <tth### [at] noneinvalid> wrote:
> ...
>     And now, I can run the big batch who make my current
>     projet: http://maison.tth.netlib.re/v/hc/full.mp4 :)

v nice, "sweet"..


regards, jr.

[tTh] Re: Nope, I STILL don't understand git branches [86 days 2 hours and 5 minutes ago]

Sun, 25 Jan 2026 08:05:43 GMT

On 1/24/26 18:25, Bill Pragnell wrote:

>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.

    And have a look at the ".gitignore" file documentation.

> Yes, this was my first thought - you need to commit your changes to the current
> branch or nothing gets tracked. Use 'git add <...>' to stage the changes, 'git
> commit' to commit them.

    I use this short-circuit:

$ vim groundbase.inc
     ... do some changes, exit vim
     ... run the tracing, look at the result
     ... if the result look correct, then
$ git commit -m "increase holes diameter" groudbase.inc

    And now, I can run the big batch who make my current
    projet: http://maison.tth.netlib.re/v/hc/full.mp4 :)




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

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [86 days 6 hours and 14 minutes ago]

Sun, 25 Jan 2026 03:56:33 GMT

On 2026-01-24 21:56 (-4), Jim Henderson wrote:
> On Sat, 24 Jan 2026 21:13:05 -0400, Cousin Ricky wrote:
> 
>> On 2026-01-23 10:46 (-4), Jim Henderson wrote:
>>>
>>> I might be mistaken (it's WAY to early in the morning for me to be
>>> thinking about this), but if the file isn't added to the repo and just
>>> lives within the directory, then I don't think any changes get tracked,
>>> and this is the behavior you would probably see.
>>>
>>> Make sure you use `git add <filename>` for anything you want change
>>> tracking enabled.
>>
>> No, the files are definitely part of the repo.
> 
> Do you see them in `git status`?
> 
> If you see something like this:
> 
> $ git status
> On branch electron
> Your branch is up to date with 'origin/electron'.
> 
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 	package-lock.json
> 
> nothing added to commit but untracked files present (use "git add" to 
> track)
> 
> Then the file isn't part of the repo (in this case, package-lock.json 
> isn't part of the repo I was checking). That would be consistent with what 
> you're seeing.

------------------------[BEGIN TERMINAL SESSION]------------------------
$ git checkout restored_oc
M       README.md
M       gemcuts.pov
M       gemcuts_description.txt
Switched to branch 'restored_oc'
$ git status
On branch restored_oc
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
        modified:   gemcuts.pov
        modified:   gemcuts_description.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        gem_ring-CSG.inc

no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout main
M       README.md
M       gemcuts.pov
M       gemcuts_description.txt
Switched to branch 'main'
$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
        modified:   gemcuts.pov
        modified:   gemcuts_description.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        gem_ring-CSG.inc

no changes added to commit (use "git add" and/or "git commit -a")
-------------------------[END TERMINAL SESSION]-------------------------

The files README.md, gemcuts.pov, and gemcuts_description.txt were
modified while one branch was checked out, and the changes show in the
other branch as well.

N.B.  Pay no attention to file gem_ring-CSG.inc; it's untracked on
purpose.  It's just a file that I haven't added to .gitignore, and I'm
still trying to decide what to do with it.

[Cousin Ricky] Re: Still stumped by git branches [86 days 6 hours and 53 minutes ago]

Sun, 25 Jan 2026 03:17:31 GMT

On 2026-01-24 22:00 (-4), Jim Henderson wrote:
> On Sat, 24 Jan 2026 20:55:50 -0400, Cousin Ricky wrote:
> 
>> I think I need to take a class.  Not a video, not a tutorial, but an
>> actual class.
> 
> https://training.linuxfoundation.org/training/git-for-distributed-
> software-development-lfd109x/ might be a good free option to take a look 
> at.  I haven't looked at it, but I know folks at the Linux Foundation who 
> are involved in training, and they generally do a good job.
> 
> I see there's a module on branches as well.

Thanks, I'll look into it.

[David Buck] Re: THERE's A BOOK??! [86 days 7 hours and 40 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??! [86 days 7 hours and 45 minutes 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

[Jim Henderson] Re: Still stumped by git branches [86 days 8 hours and 10 minutes ago]

Sun, 25 Jan 2026 02:00:36 GMT

On Sat, 24 Jan 2026 20:55:50 -0400, Cousin Ricky wrote:

> I think I need to take a class.  Not a video, not a tutorial, but an
> actual class.

https://training.linuxfoundation.org/training/git-for-distributed-
software-development-lfd109x/ might be a good free option to take a look 
at.  I haven't looked at it, but I know folks at the Linux Foundation who 
are involved in training, and they generally do a good job.

I see there's a module on branches as well.

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

[Jim Henderson] Re: Still stumped by git branches [86 days 8 hours and 12 minutes ago]

Sun, 25 Jan 2026 01:58:25 GMT

On Sat, 24 Jan 2026 21:00:03 -0400, Cousin Ricky wrote:

> On 2026-01-23 09:39 (-4), Mr wrote:
>> 
>> Yes, Consider it a scaffolding over which you do not HAVE to walk...
>> but COULD once people responsible for it will lead you by the hand...
>> one floor at a time... meanwhile you are allowed to walk beneath remote
>> admins, and Git does provide you some safer space, no matter how
>> intimidating its shadow is above your head :-P  Here is an example :
>> Instead of branches, you could have just used "stash" for now, which I
>> find simpler because of its being local.
> 
> But I don't understand what stash does.  I don't know what you mean by
> your scaffolding or "walk beneath" analogy.  I DON'T UNDERSTAND ANY OF
> THIS!

'git stash' takes the current set of changes (for tracked files only) and 
stores them separate from the current branch.  It's a way of reverting 
changes without undoing them; you can `pop` the stash to reapply the 
changes.


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

[Jim Henderson] Re: Nope, I STILL don't understand git branches [86 days 8 hours and 14 minutes ago]

Sun, 25 Jan 2026 01:56:23 GMT

On Sat, 24 Jan 2026 21:13:05 -0400, Cousin Ricky wrote:

> On 2026-01-23 10:46 (-4), Jim Henderson wrote:
>> 
>> I might be mistaken (it's WAY to early in the morning for me to be
>> thinking about this), but if the file isn't added to the repo and just
>> lives within the directory, then I don't think any changes get tracked,
>> and this is the behavior you would probably see.
>> 
>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.
> 
> No, the files are definitely part of the repo.

Do you see them in `git status`?

If you see something like this:

$ git status
On branch electron
Your branch is up to date with 'origin/electron'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	package-lock.json

nothing added to commit but untracked files present (use "git add" to 
track)

Then the file isn't part of the repo (in this case, package-lock.json 
isn't part of the repo I was checking). That would be consistent with what 
you're seeing.

Jim

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

[Jim Henderson] Re: Nope, I STILL don't understand git branches [86 days 8 hours and 17 minutes ago]

Sun, 25 Jan 2026 01:53:12 GMT

On Sat, 24 Jan 2026 21:29:18 -0400, Cousin Ricky wrote:

> On 2026-01-24 13:25 (-4), Bill Pragnell wrote:
>> 
>> Yes, this was my first thought - you need to commit your changes to the
>> current branch or nothing gets tracked. Use 'git add <...>' to stage
>> the changes, 'git commit' to commit them.
> 
> Are you saying that changes will show up in *all* branches until they're
> committed to *one* of the branches?

Technically, they don't show up in any branch because the file isn't 
tracked.  If a file isn't tracked, it exists outside git's "system", and 
the file will appear the same in all branches (but it's not in any of 
them.  If you wipe the directory and then do a git pull, the file won't be 
there at all).

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

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [86 days 8 hours and 41 minutes ago]

Sun, 25 Jan 2026 01:29:19 GMT

On 2026-01-24 13:25 (-4), Bill Pragnell wrote:
> 
> Yes, this was my first thought - you need to commit your changes to the current
> branch or nothing gets tracked. Use 'git add <...>' to stage the changes, 'git
> commit' to commit them.

Are you saying that changes will show up in *all* branches until they're
committed to *one* of the branches?

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [86 days 8 hours and 50 minutes ago]

Sun, 25 Jan 2026 01:21:02 GMT

On 2026-01-23 20:15 (-4), Mr wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>>
>> I might be mistaken (it's WAY to early in the morning for me to be
>> thinking about this), but if the file isn't added to the repo and just
>> lives within the directory, then I don't think any changes get tracked,
>> and this is the behavior you would probably see.
>>
>> Make sure you use `git add <filename>` for anything you want change
>> tracking enabled.
> 
> Also I don't know how bad you feel about using GUI, but I love Git-Cola for
> spotting that kind of issue.

Git-Cola has been wonderful, and it works seemlessly with the CLI.  But
the files in question *are* being tracked.

[Cousin Ricky] Re: Nope, I STILL don't understand git branches [86 days 8 hours and 57 minutes ago]

Sun, 25 Jan 2026 01:13:06 GMT

On 2026-01-23 10:46 (-4), Jim Henderson wrote:
> 
> I might be mistaken (it's WAY to early in the morning for me to be 
> thinking about this), but if the file isn't added to the repo and just 
> lives within the directory, then I don't think any changes get tracked, 
> and this is the behavior you would probably see.
> 
> Make sure you use `git add <filename>` for anything you want change 
> tracking enabled.

No, the files are definitely part of the repo.

[Cousin Ricky] Re: Still stumped by git branches [86 days 9 hours and 11 minutes ago]

Sun, 25 Jan 2026 01:00:04 GMT

On 2026-01-23 09:39 (-4), Mr wrote:
> 
> Yes, Consider it a scaffolding over which you do not HAVE to walk... but COULD
> once people responsible for it will lead you by the hand... one floor at a
> time... meanwhile you are allowed to walk beneath remote admins, and Git does
> provide you some safer space, no matter how intimidating its shadow is above
> your head :-P  Here is an example : Instead of branches, you could have just
> used "stash" for now, which I find simpler because of its being local.

But I don't understand what stash does.  I don't know what you mean by
your scaffolding or "walk beneath" analogy.  I DON'T UNDERSTAND ANY OF THIS!

[Cousin Ricky] Re: Still stumped by git branches [86 days 9 hours and 15 minutes ago]

Sun, 25 Jan 2026 00:55:51 GMT

On 2026-01-22 23:23 (-4), Shay wrote:
> 
> Youâ€™re making it hard. Why are you branching at all?
Donâ€™t get caught up in
> trying to do what â€œadvanced usersâ€ do, because
advanced isnâ€™t linear. Learn to
> use the parts *you* need, because you may never use the parts you imagine you
> *might* need, even if you *do* become advanced.

I'm branching because I have future plans and tentative ideas for some
of my projects that I'm not ready to incorporate into the main project.
I also have user manuals and READMEs for my Object Collection
contributions that will need to be updated once the Object Collection is
rebooted.  Up till now, I've been renaming files or keeping them in
separate directories--or, in the case of the user manuals and READMEs,
having to revert the files every time I push an update to GitHub.  This
is rather cumbersome, and git branches seems (to me) to be suitable for
this sort of workflow.

> Branching itself is easy enough. Maybe find a workflow where itâ€™s
required. Fork
> a repo, make a change, then submit a pull request. You donâ€™t even
need to be
> able to code. Submit a request for typos in the README if you like. That is
> straightforward, done the same way by thousands, clearly documented online, and
> a way to use tools for the exact purpose they were designed.

Branching seems super simple on paper, but in practice, it doesn't
behave the way I expect it to.  There is something conceptually
fundamental about git that I do not understand, and I feel that until I
do understand whatever it is that I'm missing, I will continue to be
frustrated with git, no matter how easy or "advanced" the feature.

I think I need to take a class.  Not a video, not a tutorial, but an
actual class.

[Bill Pragnell] Re: Nope, I STILL don't understand git branches [86 days 11 hours and 31 minutes ago]

Sat, 24 Jan 2026 22:40:00 GMT

Jim Henderson <nos### [at] nospamcom> wrote:
> On Sat, 24 Jan 2026 12:25:51 EST, Bill Pragnell wrote:
>
> > Yes, this was my first thought - you need to commit your changes to the
> > current branch or nothing gets tracked. Use 'git add <...>' to stage the
> > changes, 'git commit' to commit them.
>
> IIRC, 'git status' will show if that's the case, as it shows untracked
> files.

Yep, 'git status' with no other args will list staged files, changed tracked
files and untracked files in separate sections.

This scenario sounds like there would just be items in the 'changes' section,
since these are changes to tracked files. A newly added file would appear in
untracked files.

Bill