povray.general message digest

[19100] Re: So THAT's why all the interest in POV-Ray 2....

Thu, 8 Oct 2026 18:00:00 GMT

Very interesting! Slightly surreal to see that little tutorial I wrote being
adapted into a model benchmark (with some additional fixes too it seems, I
should really write an update).

> - and no, quietly substituting POV-Ray 3.7 does not count.
That could be why illum1.pov was chosen, 3.7 renders it quite differently from
2.2.

[Jim Henderson] Re: So THAT's why all the interest in POV-Ray 2....

Wed, 7 Oct 2026 15:28:56 GMT

That's a great story, Chris - thanks for sharing it!


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

[yesbird] Re: Website pages not functioning.

Wed, 7 Oct 2026 12:12:13 GMT

On 23/09/2026 19:41, Chris Cason wrote:
> Currently my two top choices are Discourse (open-source and not to be 
> confused with Discord, which is a proprietary walled garden that does 
> not share information) and self-hosted XenForo with the Media Gallery 
> and Resource Manager add-ons (commercial but not expensive).
>

+ 1 for Discourse - it's very neat and convenient.
Often visiting this forum and like how it works:
https://discourse.threejs.org/
-- 
YB

[yesbird] Re: So THAT's why all the interest in POV-Ray 2....

Wed, 7 Oct 2026 11:03:41 GMT

On 07/10/2026 12:56, Chris Cason wrote:
> 
> For the last year I have been seeing lots and lots of requests in the
> logs for the version 2.2 sources, many of which were made in locations
> where it had never existed. It thought it curious but in the overall
> scheme of things was not causing problems.
> ...
Thank you, Chris, for sharing this interesting story with us.
It's very unusual use case of POV-Ray code - looking forward
for sequel. :)
--
YB

[ingo] Re: So THAT's why all the interest in POV-Ray 2....

Wed, 7 Oct 2026 11:00:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> [Related note: NNTP users please use nntp.povray.org going forward]
>
> For the last year


and you didn't send the invoice??

ingo

[Chris Cason] So THAT's why all the interest in POV-Ray 2.2 ...

Wed, 7 Oct 2026 10:02:49 GMT

[Related note: NNTP users please use nntp.povray.org going forward]

For the last year I have been seeing lots and lots of requests in the
logs for the version 2.2 sources, many of which were made in locations
where it had never existed. It thought it curious but in the overall
scheme of things was not causing problems.

I have just recently found out the actual cause of this: an AI benchmark
that tasks the agent with finding, downloading and building the version
2.2 POV-Ray source (released 1993)!

The reason I found out: a PR lodged with the authors of the benchmark
noting that their agents had been blocked from downloading since we put
the site behind Cloudflare.

I thought it a bit funny that they didn't just ask us to allow an exception
to the Cloudflare WAF rules, which I would have been happy to do since the
files are all static and put little load on the server. I have in fact now
done this - everything under the /ftp path is now except from most of the
rules (but not from rate limiting, for example) and in addition I have put
in cache overrides for the entire tree, telling Cloudflare to cache *everything*
in there, plus use cache reserve to keep it there. This means we see very
little actual traffic for those files now, since almost all requests are
satisfied by the cache.

After my initial reply to the PR I got curious as to what the actual numbers
were so did some log analysis, and the results were too good not to share :-)

If you are interested you can see my response at
     https://github.com/harbor-framework/terminal-bench-2/issues/76
but I'll also include the meat of it here.

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

A follow-up, now that I finally know why povray.org spent the last year
being asked for a release from 1993. I went through our server logs, and
the numbers turned out to be too good not to share.

First, to be clear: you weren't the cause of our server trouble. From
September 2025 to August 2026, povray.org was being crawled by something
*much* bigger: a not-very-smart scraper working through residential
proxy networks.

- Scale: over 30 million distinct IP addresses hit our web and news
   servers in that time. About 15 million of them sent requests in the
   form a client uses to talk to a proxy, which no ordinary browser sends
   to a web server.

- Rotation: most addresses made only one or two requests, so no
   per-address limit could catch it.

- Manners: it ignored robots.txt and followed every link, including the
   clearly labelled "Post a reply" link on our forums, which only leads
   to a login page. Undeterred, it followed the "if at first you don't
   succeed, just ask again" school of thought: /post/ became the
   most-requested page on the server by a mile, with 30.6 million
   requests for 15.3 million different reply links, four times our home
   page.

- URL handling: it joined URLs so badly that it invented its own. That
   came to 16.5 million distinct URLs out of our links page in four
   weeks, and news thread links glued end to end.

At its worst it took the server down: a kernel panic on 5 August, the
first unplanned reboot in more than 20 years. That is what finally
pushed the sites behind Cloudflare. On 7 August, Cloudflare counted 39
million requests from 18.9 million distinct addresses in a single day;
the busiest hour averaged about 2,500/second, and peaked at an estimated
5,000/second (it appears the authors of the scraper, human or machine,
don't grasp the concept of "moderation").

So your agents just had the bad luck to walk into the bot protection we
put up against all that. For scale, agents seeking the 2.2 source code
came from about 81,000 IP addresses over a whole year -- basically a
rounding error compared to the total of more than 30 million.

POV-Ray 2.2's unexpected second career
--------------------------------------

The three Official-2.2 archives (POVSRC.TAR.Z, POVDOC.TAR.Z,
POVSCN.TAR.Z) used to be fetched a few dozen times a month, mostly by
people feeling nostalgic. Then, on 5 September 2025:

   Distinct addresses since then            at least 81,000
   Served over HTTP (Sep 2025 - Aug 2026)   ~5 million, about 2.4 TB
   Busiest day (7 Jan 2026)                 ~118,000 downloads
   Served over actual FTP                   ~355,000, about 170 GB
   Before September 2025, per month         0-9 by FTP, a few dozen to
                                            a few hundred by HTTP

Almost all of it was curl/8.5.0 and Wget/1.21.4, which is to say Ubuntu
24.04 containers, from just about every major cloud you can name.

Some agents are smarter than others
-----------------------------------

ftp.povray.org does in fact speak FTP, a protocol whose first RFC
predates the C language. Some agents worked that out, and some kept
hammering HTTP. Share of agents (by address) that got the archives over
real FTP:

   Period                   FTP share  What was going on
   -----------------------  ---------  ----------------------------------
   Sep 2025 - mid-May 2026  ~31%       Both doors open (9,078 FTP vs
                                       22,736 HTTP)

   Mid-May - late Aug 2026  ~1%        I'd put ftp. behind Cloudflare,
                                       which doesn't do FTP. My fault

   7 Sep - 4 Oct 2026       73%        HTTPS had a bouncer, so three
                                       quarters went round the back
                                       (14,135 FTP vs 6,525 HTTPS)

   Since 5 Oct (the fix)    ~21%       Front door open; 96% get the
                                       files, nearly all on the first try

Other observations from the logs:

- Thrift: the FTP users averaged about 15 archive downloads per address.
   The HTTP crowd averaged about 58.

- Persistence: 80-85% of the agents that tried FTP got the files in the
   end. One made 4,704 attempts in a single FTP session. (Many of those
   failures are probably at our end: our FTP server rejects data
   connections that come from a different address than the control
   connection, which cloud NAT does a lot. I'll look at it.)

- Imagination: povray-2.2.tar.gz has been requested from at least half a
   dozen directories where it has never existed.

A modest proposal
-----------------

Finding and compiling a 33-year-old C program is one thing. Finding it,
compiling it, and making it render 10x faster, fully autonomously, is
another thing entirely. So here's a cheeky challenge for the next
version of the task:

- the same container (1 CPU, 2 GB);

- a fair scene: illum1.pov at 640x480 with the task's own settings, or
   any 2.2-era benchmark scene you like;

- the output must still pass your SSIM check against the reference
   image;

- no turning features off and no lowering quality;

- and no, quietly substituting POV-Ray 3.7 does not count.

Bonus points if it doesn't download the source 4,704 times first
(looking at you, agent [IP redacted]!)

The files are open and cached now, so please use HTTPS; it's quicker for
everyone. And next time, just ask. We're friendly, and we've been at
this since 1988, when it was called DKB-Trace and passed around on
bulletin boards, 2400 baud was fast, and almost nobody had heard of the
internet. Odds are most of the people building these agents hadn't been
_born_ yet.

And if your agents enjoyed the 1993 source, the current one is here
(stars welcome):

https://github.com/POV-Ray/povray

A few stars might even get my 63-year-old backside off the couch and
into a new release. There are PRs waiting to be merged, and a Claude
instance that's starting to feel neglected.

[GioSeregni] Re: String Functions

Mon, 5 Oct 2026 15:40:00 GMT

I built these, in case anyone finds them useful.


#macro h2d(HexVal)
 (asc(HexVal)>64?asc(HexVal)-55:asc(HexVal)-48)
#end
#macro hex2rgb(hxStr)
 <(16*h2d(substr(hxStr,4,1))+h2d(substr(hxStr,5,1)))/255,(16*h2d(substr(hxStr,6,1))+h2d(substr(hxStr,7,1)))/255,
 (16*h2d(substr(hxStr,8,1))+h2d(substr(hxStr,9,1)))/255>
#end

[Maetes] Re: String Functions

Mon, 5 Oct 2026 12:45:00 GMT

Josh English <Jos### [at] joshuarenglishcom> wrote:
> I'm trying another "push POV-Ray to a new level" and I'm messing around
> with strings.
>
> I'm trying to roll my own and getting a bit frustrated.
>
> Has anyone implemented string functions in the SDL? I'm not finding much
> in regular web searches these days.
>
> Uncle Josh

maybe some of my macros are helpful.

https://www.maetes.com/en/povray-os/ma_helpers

M

[jr] Re: String Functions

Mon, 5 Oct 2026 06:45:00 GMT

hi,

Josh English <Jos### [at] joshuarenglishcom> wrote:
> ...
> Has anyone implemented string functions in the SDL? I'm not finding much
> in regular web searches these days.

I wrote a 'strSplit()' to convert a string to an array of strings:
<wiki.povray.org/content/User:Jr/assorted>


regards, jr.

[Josh English] Re: String Functions

Mon, 5 Oct 2026 00:43:21 GMT

On 10/4/2026 4:55 PM, Bald Eagle wrote:
> Josh English <Jos### [at] joshuarenglishcom> wrote:

> 
>> I'm trying to roll my own and getting a bit frustrated.
> 
> Well, as always, post your goal and the code, and we'll see what we can do.
> 
>> Has anyone implemented string functions in the SDL?
> 
> I'm certain I must have in the past.  Whether I can find it or not...
> 

I was hoping there was a quick "oh yeah and here's the link" to review.

I think I have a working strip(), split(), and join() functions, and I 
think I got there through luck more than actually thinking through the 
problem:

// ---------------------------------------------------------------------
// strip(string)
// Extract the first non-space word of a text, up to the following space
#macro strip(string)
   #local res = "";
   #local I = 1;
   #while(substr(string,I,1) = " ") #local I = I + 1; #end

   #local next_c = 0;
   #while (substr(string,I,1) != " ")
     #local res = concat(res, substr(string, I, 1));
     #local next_c = next_c + 1;
     #local I = I + 1;
     #if(I > strlen(string)) #break #end
   #end

   res

#end

// split(string)
// split a string by spaces
#macro split(string)
   #local len = strlen(string);
   #local I = 1;
   #declare res = array;

   #while(I <= len)
     #local next = strip(substr(string, I, len-I+1));
     //#debug concat("-",next, "-\n")
     #local I = I + strlen(next)+1;
     #declare res[dimension_size(res, 1)] = next;
   #end

   res

#end // macro split

// join(array)
// joins an array of strings into a single text by spaces
#macro join(arr)
   #local res = "";

   #for(I,0,dimension_size(arr,1)-1, 1)
     #local res = concat(res, arr[I], " ");
   #end

   substr(res, 1 strlen(res)-1)

#end
// ---------------------------------------------------------------------

It seems to work for my purposes, which are stupidly complicated, as always.

-- Uncle Josh

[Bald Eagle] Re: String Functions

Mon, 5 Oct 2026 00:00:00 GMT

Josh English <Jos### [at] joshuarenglishcom> wrote:
> I'm trying another "push POV-Ray to a new level" and I'm messing around
> with strings.
>
> Unfortunately the SDL doesn't even have a FIND function or STRIP
> function for strings.

As clipka has mentioned in the past, there's really very little in terms of
string manipulation in povray.

> I'm trying to roll my own and getting a bit frustrated.

Well, as always, post your goal and the code, and we'll see what we can do.

> Has anyone implemented string functions in the SDL?

I'm certain I must have in the past.  Whether I can find it or not...

> I'm not finding much
> in regular web searches these days.

Yep.   Those search engines don't return much of use anymore.

- BE

[Josh English] String Functions

Sun, 4 Oct 2026 23:24:45 GMT

I'm trying another "push POV-Ray to a new level" and I'm messing around 
with strings.

Unfortunately the SDL doesn't even have a FIND function or STRIP 
function for strings.

I'm trying to roll my own and getting a bit frustrated.

Has anyone implemented string functions in the SDL? I'm not finding much 
in regular web searches these days.

Uncle Josh

[Bald Eagle] Re: macros? generators? idk

Sat, 3 Oct 2026 01:20:00 GMT

"Emirhan EkmekÃ§i" <emi### [at] gmailcom> wrote:
> >  As for your question "what if we can make generators only using macros?"
> > I don't understand what your "generators" would generate. Whole pictures? Ideas?
> > objects? Backgrounds? POV can do any of those in a limited way.
>
> Oh i was talking about creating sfuff using macros that can make random stuff
> like pipes randomly generating around like 3D pipes screensaver.
>
> - Emirhan EkmekÃ§i

I could have sworn that someone had one somewhere.
Maybe Nekar Xenos, Tekno Franansia, PM2Ring, or one of the really skilled,
prolific coders.

Absent that, maybe there's a way to make a 3D version of "snake" that doesn't
self-intersect.  Maybe there's something that can be done with the A* algorithm,
or similar.  Perhaps there's some sort of L-system that would work.

Look for prior art.  Look in other languages and coding environments.
Check out Daniel Schiffman and the Coding Train.
Ask around on Stack Exchange, Stack Overflow, and computer graphics forums.

See what you can come up with on your own.
Part of the fun is learning.    And the more you learn, the more you can stretch
out and do.   Which makes it even more fun.

- BE

[Emirhan Ekmekçi] Re: macros? generators? idk

Fri, 2 Oct 2026 20:00:00 GMT

>  As for your question "what if we can make generators only using macros?"
> I don't understand what your "generators" would generate. Whole pictures? Ideas?
> objects? Backgrounds? POV can do any of those in a limited way.

Oh i was talking about creating sfuff using macros that can make random stuff
like pipes randomly generating around like 3D pipes screensaver.

- Emirhan EkmekÃ§i

[jr] Re: macros? generators? idk

Thu, 1 Oct 2026 06:10:00 GMT

hi,

"Emirhan EkmekÃ§i" <emi### [at] gmailcom> wrote:
> hello guys i know i am making random stuff on POV-ray for no reason but i got a
> different idea that says "what if we can make generators only using macros?".
> Now i know you lazy to create a macros that can generate trees, pipes and water
> drops on objects that can work great or others but idk if you guys can do it.
> because im still making random arts while training my skills for like 2.5 weeks
> and im also a teen (male, 13) so idk if it is a great or just a basic idea. idk
> but you can guess it!

"hello" to you too, and I hope you'll enjoy "playing" with POV-Ray for a long
time to come.  regarding "generators" and "pipes" -- there is one guy who has
got "the T-shirt" :-):
<http://www.oyonale.com/modeles.php?lang=en&page=20>


regards, jr.

[ingo] Re: macros? generators? idk

Thu, 1 Oct 2026 06:03:26 GMT

On 2026-09-30 16:19, Emirhan EkmekÃƒÂ§i wrote:
> hello guys 


Emirhan,

You can. Macro's are just text substitution with a bit of special sauce. 
There are many procedural ways of creating shapes, objects or whole 
scenes that can be put inside macro's.

A famous procedural generator is a Lindemayer system, or L-systems. That 
can be used to create plants for example 
https://github.com/t-o-k?tab=repositories search for L-system in this 
page to get an idea.

There is a wealth of macro's that build things "out there".

ingo

[Leroy] Re: macros? generators? idk

Wed, 30 Sep 2026 20:25:00 GMT

"Emirhan Ekmekçi" <emi### [at] gmailcom> wrote:
> hello guys i know i am making random stuff on POV-ray for no reason but i got a
> different idea that says "what if we can make generators only using macros?".
> Now i know you lazy to create a macros that can generate trees, pipes and water
> drops on objects that can work great or others but idk if you guys can do it.
> because im still making random arts while training my skills for like 2.5 weeks
> and im also a teen (male, 13) so idk if it is a great or just a basic idea. idk
> but you can guess it!

 Glad you chose POV! And you came to the right place to talk about it.

 I'm still making "random" art and I've been at it for 30 plus years. Making
stuff is the best way to learn POV. POV is a deep program. That is it has lots
of ideas. from the simple 3d xyz Coordinate System to the complex inter action
between light and textures.
 I always thought that learning POV was like an adventure game. While playing
randomly you find a function that does something interesting and you put it your
toolbox. Then latter while working on a project that something comes up and you
say "I know how to do that!" You've kill it! So the more you play the more tools
you have. And they're your tools! You've earned each and every one.

 As for your question "what if we can make generators only using macros?"
I don't understand what your "generators" would generate. Whole pictures? Ideas?
objects? Backgrounds? POV can do any of those in a limited way.

Have Fun!

[Emirhan Ekmekçi] macros? generators? idk

Wed, 30 Sep 2026 14:25:00 GMT

hello guys i know i am making random stuff on POV-ray for no reason but i got a
different idea that says "what if we can make generators only using macros?".
Now i know you lazy to create a macros that can generate trees, pipes and water
drops on objects that can work great or others but idk if you guys can do it.
because im still making random arts while training my skills for like 2.5 weeks
and im also a teen (male, 13) so idk if it is a great or just a basic idea. idk
but you can guess it!

[Jim Henderson] Re: Website pages not functioning.

Wed, 23 Sep 2026 21:10:48 GMT

On Thu, 24 Sep 2026 02:41:52 +1000, Chris Cason wrote:

> Currently my two top choices are Discourse (open-source and not to be
> confused with Discord, which is a proprietary walled garden that does
> not share information) and self-hosted XenForo with the Media Gallery
> and Resource Manager add-ons (commercial but not expensive).

FWIW, I am an admin in an open source community that uses Discourse.  If 
you want to deploy it yourself, the Docker-based installation is (a) 
officially supported, and (b) super easy to set up and use.

They also have a hosted option, but that may be cost prohibitive for this 
community.

There was an older plugin for integrating with NNTP, but I don't know if 
it has been updated recently or works with the current database schema.  
An experienced coder who understands Ruby (their language of choice) could 
probably update it pretty easily since NNTP hasn't changed in ages.

I also noticed that they recently added fully threaded discussions as an 
option.  I haven't looked at it yet, but probably should (I've got 3 or 4 
different sandbox environments of my own set up).

Jim

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

[Chris Cason] Re: Website pages not functioning.

Wed, 23 Sep 2026 16:45:28 GMT

On 23/09/2026 19:16, Maetes wrote:
> Hey Chris, Is there anything we can help you with?
> 
> I have little experience with forums and don't know how helpful I can be, but
> I'm a Backend PHP programmer.

Thanks for the offer - I do appreciate it. At this point, there is not a lot that can
be done in software. If someone decides to hit the forum with 1,000 requests / second
(for example) there really is no programmatic solution unless they are using a single
IP (what we tend to see these days are residential botnets). Mostly I rely on
Cloudflare now that we are proxied by them.

Generally speaking I try to avoid turning on managed or interactive challenge to stop
them (the latter is quite effective) but am coming to the point where I might have to
add a cron job to auto-activate it (via API call) if the forums get hammered.

I am already planning an exit from the current forum software and have been coding an
"archive" version that is fully static and contains the magic markup that allows
google to index it correctly (we already have valid JSON-LD but google ignores it).
Most likely will go to structured markup. This is also part of work to bring better
search (I'm using Algolia). I'm having good results with the latter but need to work
on the crawler side more.

FWIW the "archive" view will be aggressively cached on Cloudflare. The downside of
this is that no logins work in archive mode (cached version is always the logged-out
view - but there will be a link to the live version), they are single page (this is
also an upside since modern browsers are quite capable of handling even our longest
threads), and no sorting.

The archive view is what will get indexed by search engines and where possible I will
redirect scrapers there (not always possible but we'll see).

> I had also thought about whether I should take a closer look at an open-source
> forum software and try my hand at importing individual forum threads. To maybe
> bring our message board into this millennium, with a few more functions. But
> nothing has come of it so far.

You are looking in the right direction: our forums (as most of the world sees them)
were originally written in an era where the majority of users were connecting via NNTP
and the web view was kind of a fallback. Now most posts and views are from the web.
New forum software is definitely on the tables - potentially with an import from the
existing one, or if not the existing one will serve as a read-only reference
side-by-side with the new one.

We still have some NNTP users (including myself) and I do not want to cut them off.
Nothing out there really caters for threaded views though - yes there are a few
exceptions, but not many. I will do my best to make it happen since I still much
prefer threading for forums (and the entire opposite for emails).

Currently my two top choices are Discourse (open-source and not to be confused with
Discord, which is a proprietary walled garden that does not share information) and
self-hosted XenForo with the Media Gallery and Resource Manager add-ons (commercial
but not expensive).

Also, a footnote regarding import (regardless of what we use): all new forum software
requires login to post, with each article thus attributed to a poster or other
identity on the server. While many posts on this site are able to be connected to a
login, particularly recent ones, this is not the case for all activity (even recent)
and much less so 10-20 years ago. I would not want to treat the two groups
differently, nor would I want to import all posts under a "default" user identity. If
we import at all, at most only very old posts will have a default or missing forum
userid. I will need to engage with currently active NNTP users to get them to create
an account on povray.org (if they don't have one) and find a way of definitively
linking their NNTP posts with the account.

-- Chris

[Maetes] Re: Website pages not functioning.

Wed, 23 Sep 2026 09:20:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 19/09/2026 00:49, Bald Eagle wrote:
> > The full message digest and image digest are not working.
>
> Just the usual abuse. Maybe not as heavy as past weeks.

Hey Chris, Is there anything we can help you with?

I have little experience with forums and don't know how helpful I can be, but
I'm a Backend PHP programmer.

I had also thought about whether I should take a closer look at an open-source
forum software and try my hand at importing individual forum threads. To maybe
bring our message board into this millennium, with a few more functions. But
nothing has come of it so far.

Greetings Ma

[19100] DKBTrace 2.12 (AGPL 3.0+ re-release)

Tue, 22 Sep 2026 20:45:00 GMT

Back in 2024 I emailed David Buck with a few questions about the early days of
DKBTrace/POV-Ray, recently I've had the time to sort out the main thing I wanted
to ask him about. So, with his blessing, I'd like to present a new reissue of
DKBTrace 2.12:
https://archive.org/details/dkb-trace212agpl

What makes this version different from the previous release is that it brings
together originally separate archives into a single package, with all included
files available under licenses that are compatible with upstream POV-Ray. The
main DKBTrace source code (plus a couple of additional utilities written by
David Buck) is now licensed under the GNU Affero General Public License version
3 (or any later version), with the documentation and standard include files
licensed under some older versions of Creative Commons, which is in line with
current POV-Ray. The archive also contains permissively licensed example scenes
and software utilities written by the DKBTrace community back then.

One downside of this new release is that due to incompatible or ambiguous
licensing, a number of scenes and utilities have not been included with this
archive. The good news though is that you can still download the original
release of DKBTrace 2.12, from an archive of the FTP server it was originally
hosted on:
https://archive.org/details/ftp.ccs.carleton.ca

I'd like to thank David for making this release possible and of course for
creating DKBTrace in the first place! I hope people find this archive both
useful and interesting, perhaps something similar will be possible for older
versions of POV-Ray too? ;)

[Chris Cason] Re: Website pages not functioning.

Tue, 22 Sep 2026 16:27:37 GMT

On 19/09/2026 00:49, Bald Eagle wrote:
> The full message digest and image digest are not working.

Just the usual abuse. Maybe not as heavy as past weeks.

[jr] Re: Website pages not functioning.

Tue, 22 Sep 2026 07:25:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ...
> Who runs the forum and is responsible for it?

the infrastructure is owned, and maintained, by Chris (Cason); see eg this
recent post:

<news.povray.org/povray.binaries.images/thread/%3C6aaca6da%241%40news.povray.org%3E/#msg-hdr-448237>


regards, jr.

[Maetes] Re: Website pages not functioning.

Mon, 21 Sep 2026 21:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Looks like everything is working again, both at home and work.
>
> Fingers crossed it stays that way.

Who runs the forum and is responsible for it?

I'm a PHP programmer, maybe I can help.

Ma

[Bald Eagle] Re: Website pages not functioning.

Sat, 19 Sep 2026 15:55:00 GMT

Looks like everything is working again, both at home and work.

Fingers crossed it stays that way.

[Cousin Ricky] Re: Website pages not functioning.

Sat, 19 Sep 2026 04:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> The full message digest and image digest are not working.
>
> This page isn’t working
> news.povray.org is currently unable to handle this request.
> HTTP ERROR 503
>
> - BW

Everything works for me.

[Bald Eagle] Re: Website pages not functioning.

Fri, 18 Sep 2026 18:25:00 GMT

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

> all working here, let's hope it was transient/a "glitch".

Alas, I noticed this yesterday (at home) hoping the same, and it persists here
at work.   So not computer/cache related.

- BW

[jr] Re: Website pages not functioning.

Fri, 18 Sep 2026 15:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> The full message digest and image digest are not working.
>
> This page isnâ€™t working
> news.povray.org is currently unable to handle this request.
> HTTP ERROR 503

all working here, let's hope it was transient/a "glitch".


regards, jr.

[Bald Eagle] Website pages not functioning.

Fri, 18 Sep 2026 14:50:00 GMT

The full message digest and image digest are not working.

This page isnâ€™t working
news.povray.org is currently unable to handle this request.
HTTP ERROR 503

- BW

[Bald Eagle] Re: is this website still alive?

Thu, 17 Sep 2026 13:10:00 GMT

"Demian" <cuc### [at] gmailcom> wrote:
> is this website still alive?

It's as alive as anyone makes it.

If you have scenes that you want to make, effects that you want to create, code
that you want to write and debug, or tasks and even whole projects that you want
to accomplish - then make it happen.

Write, post, ask, encourage, invite others, learn, share, and DO.

we're all here to help - as people before have helped us.

- BE

[S I R ?] Re: is this website still alive?

Tue, 15 Sep 2026 16:05:00 GMT

"Demian" <cuc### [at] gmailcom> wrote:
> hi! I am a beginner in POV-Ray and I have been searching for a group where I can
> talk about it. is this website still alive?

Sure it is ^_~ !

- S I R ?

[Mr] Re: Hello gang - getting back to it.

Tue, 15 Sep 2026 12:05:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> new site:   www.miller-raytracer.com



Yes, all of this site should go to the Hall of Fame!

And great picture*, animated even !

It's almost too dark, at the limit of what's possible without perfectly tuned
gamma :-)

[Cossack ] Re: how do y'all make meshes?

Sun, 13 Sep 2026 20:45:00 GMT

"Demian" <cuc### [at] gmailcom> wrote:
> Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
> you make meshes manually or use some app and then convert them? if an app, then
> what would you recommend?
>
> Thanks :)

â€‹Hi, and welcome to POV-Ray! I know everyone has probably already
covered the
basics, so Iâ€™ll just suggest something that might not have been
mentioned yet:
Art of Illusion. It is a 3D modeling, rendering, and exporting application.
Since itâ€™s written in Java and available in formats like .jar and
.exe, you
can even run it on a phone (which is exactly what I did :)). Additionally, it
can export your models directly into the .pov format!

[S I R ?] Re: pool water

Fri, 11 Sep 2026 01:15:00 GMT

"David Kraics" <bar### [at] aolcom> wrote:
> Hello. I'm doing a render of a building with a roof top pool. I got the shape
> perfect, but I need help with a texture. Light blue with a little transparency.
> Does anyone have any suggestions?

Maybe you could use a polygon to do it:

polygon {

5,
//this part depends of the dimensions of the pool
<-2,-1>,
<-2,1>,
<2,1>,
<2,-1>,
<-2,-1>

texture { pigment { color rgbf  <1,1.5,1,0.6> }
finish { phong 1 ambient .2 diffuse .05 reflection .4 }
normal { ripples 3 scale .5 translate <-10,0,10> } }

//translate to the pool position if needed
//translate <0,0,0>
}

I'm not a experimented POV-Ray user but i hope this helps ya'!

Excuse my english if i had any spelling errors of something :(

- S I R !

[kurtzlepirate] Re: how do y'all make meshes?

Mon, 7 Sep 2026 15:10:26 GMT

On 06/09/2026 16:43, Demian wrote:
> Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
> you make meshes manually or use some app and then convert them? if an app, then
> what would you recommend?
> 
> Thanks :)
> 

hello Demian and welcome to POVRay.

to answer your question, I use:
  * manually for simple meshes.
  * generated by SDL.
  * by converting the files with my own programs or online converters.

-- 
klp
compagnie de la banquise

[Leroy] Re: how do y'all make meshes?

Mon, 7 Sep 2026 01:40:00 GMT

"Demian" <cuc### [at] gmailcom> wrote:
> Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
> you make meshes manually or use some app and then convert them? if an app, then
> what would you recommend?
>
> Thanks :)

Welcome to the wonderful world of POV! It always nice to see new users take up
the tool I love to play with. ingo & yesbird gave you a lot good info. I write
most of the meshes I use by hand. But I really don't use them in complicated
objects. POV has a lot of shapes, primitive & complex that can do some fantastic
stuff! (check them out:)
 When I first started with POV, I went at it like a dungeon & dragons game, that
is I try to do something, learned how POV did it and stuck that little fact into
my weapons bag. Pretty soon the bag was almost full then a new version. That was
awhile back. POV has grown since then. I still once in awhile grab a bow and go
looking for that dragon.

Have Fun!

[yesbird] Re: Hello gang - getting back to it.

Sun, 6 Sep 2026 17:20:12 GMT

On 05/09/2026 19:30, Mike Miller wrote:
> Attached is a current progress rendering of this pumphouse. I hope to be rid of
> this project someday. ha-ha. miller

I like what I see here, but probably there are some other methods
of modelling water besides blobs ?
--
YB

[yesbird] Re: how do y'all make meshes?

Sun, 6 Sep 2026 16:45:46 GMT

On 06/09/2026 17:43, Demian wrote:
> Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
> you make meshes manually or use some app and then convert them? if an app, then
> what would you recommend?
> 
> Thanks :)
> 
Hi, Demian.

I can suggest you the following converter from popular formats
(obj,fbx,glb,gltf,stl):
http://povlab.yesbird.online/studio/

The most powerful (and expensive) mesh editors are C4D and ZBrush,
free alternatives are Blender, SculptGL, Mixos and many others ...
--
YB

[ingo] Re: how do y'all make meshes?

Sun, 6 Sep 2026 15:31:38 GMT

On 2026-09-06 16:43, Demian wrote:
> Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
> you make meshes manually or use some app and then convert them? if an app, then
> what would you recommend?

There's many ways. Modelers, by procedure, stitch manually, convert obj 
models to mesh2.

For procedural there is meshmaker.inc in the distribution and in the 
insert menu/special shapes/meshes by meshmaker.inc you can find examples 
for that.

For conversion (.obj files) there is Poseray. Also useful in combination 
with modelers as many don't support POV-Ray directly.

For modelers, there are a lot of them. Some free, many at relative low 
cost and the high end modellers. Almost all can export to .obj files.

Have fun!

ingo

[Demian] how do y'all make meshes?

Sun, 6 Sep 2026 14:45:00 GMT

Hi! I am a beginner to POV-Ray, and I have a question to experienced users: do
you make meshes manually or use some app and then convert them? if an app, then
what would you recommend?

Thanks :)

[jr] Re: Hello gang - getting back to it.

Sat, 5 Sep 2026 21:30:00 GMT

hi,
"Mike Miller" <mil### [at] gmailcom> wrote:
> ...
> Attached is a current progress rendering of this pumphouse. I hope to be rid of
> this project someday. ha-ha. miller

the "gloom" makes me wish for some "glow" :-)
<en.wikipedia.org/wiki/Cherenkov_radiation>


regards, jr.

[Mike Miller] Re: Hello gang - getting back to it.

Sat, 5 Sep 2026 16:35:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> yesbird wrote:
> > On 28/08/2026 17:54, Mike Miller wrote:
> > > Thanks BE. I'll look into Rune & Koppi's work. I just posted an animation on my
> > > site of my current progress. I'm tweaking the topo and looking at vegetation
> > > ideas along with programming some practical effects (gas and/or venting liquid)
> >
> > Most of all I like twilight atmosphere and lightning - it's very cozy ).
> > Together with large-scale mechanical parts this scene creates very
> > specific impression. Looking forward for next steps.
> >
> > As to effects, may be this volume rendering example can help ?
> > https://paulbourke.net/miscellaneous/povexamples/
> > --
> > YB
>
>
> Thanks, YB. I'll take a look at that. I'm quickly running out of RAM on this
> scene. I had to pull back on some of my vegetation counts once I added a large
> blob practical effect. :) Attached is POV code using randomized spline
> transforms to run animate moving points along. I included some 'crushed' video
> to illustrate. Sorry we can't post anything bigger than 5 mg. I'll post higher
> res on my site. Have a blessed weekend.
> Mike

Attached is a current progress rendering of this pumphouse. I hope to be rid of
this project someday. ha-ha. miller

[Mike Miller] Re: Hello gang - getting back to it.

Sat, 5 Sep 2026 16:15:01 GMT

yesbird wrote:
> On 28/08/2026 17:54, Mike Miller wrote:
> > Thanks BE. I'll look into Rune & Koppi's work. I just posted an animation on my
> > site of my current progress. I'm tweaking the topo and looking at vegetation
> > ideas along with programming some practical effects (gas and/or venting liquid)
>
> Most of all I like twilight atmosphere and lightning - it's very cozy ).
> Together with large-scale mechanical parts this scene creates very
> specific impression. Looking forward for next steps.
>
> As to effects, may be this volume rendering example can help ?
> https://paulbourke.net/miscellaneous/povexamples/
> --
> YB

Thanks, YB. I'll take a look at that. I'm quickly running out of RAM on this
scene. I had to pull back on some of my vegetation counts once I added a large
blob practical effect. :) Attached is POV code using randomized spline
transforms to run animate moving points along. I included some 'crushed' video
to illustrate. Sorry we can't post anything bigger than 5 mg. I'll post higher
res on my site. Have a blessed weekend.
Mike

[Mike Miller] Re: img2mesh update

Thu, 3 Sep 2026 21:50:00 GMT

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greetings,
>
> as some might remember, img2mesh is a pure Python program for converting
> 2D image height fields into 3D triangle mesh, building somewhat
> interesting mesh geometry. Others may take a look at:
>
> https://dnyarri.github.io/img2mesh.html
>
> One of the interesting features of img2mesh is using different types of
> triangle splitting for smooth and sharp source areas, named geometry 3
> and 1, correspondingly. Geometry choice is based on local image contrast
> (currently on max abs difference within neighbour pixels window), more
> specifically, on results of applying user-defined threshold criterion to
> local contrast.
>
> Main reason for current img2mesh update is adding a threshold mask
> display to img2mesh GUI, so now user may easily switch between source
> image preview and mask representation, and edit threshold visually (an
> animated GUI screenshot is attached. Yes, I insist - it's animated, no
> matter what your newsreader says! After all, animated PNG recently
> became accepted as a part of PNG specs). I've spent several days trying
> to make a GUI which I myself wouldn't consider disgusting, so,
> hopefully, other people may find it useful as well.
>
> Simplest way to download img2mesh, as always, is visiting release page:
>
> https://github.com/Dnyarri/img2mesh/releases/latest
>
> --
> Ilyich the Toad
> https://dnyarri.github.io/

NICE! ...thanks for sharing. I'm currently working with a few height field
scenes. Having pre-calculated meshes to morph over time would be very cool to
play with.
Thank you
Miller

[Ilya Razmanov] Re: img2mesh update

Tue, 1 Sep 2026 19:59:04 GMT

On 01.09.2026 19:46, William F Pokorny wrote:
> On 8/31/26 23:20, Ilya Razmanov wrote:
>> different types of triangle splitting for smooth and sharp source areas
> 
> Cool. What method / tool did you use for the encoding?
> 

Some APNG Assembler:

https://apngasm.sourceforge.net/

- it's pretty simple, just drag source PNGs in, set frame delays, and 
export;

plus subsequent compression with Oxipng:

https://github.com/oxipng/oxipng

- oxipng is my tool of choice for PNG compression now; it's way faster 
than ECT, does not destroy 16 bpc images, L/RGB in transparent areas etc 
unless I specifically tell it to do so, and, in general, just does what 
I want, not trying to pretend being smarter than me. I use it even for 
my custom icons - it can't handle ICO files, but I made some small 
pythonic thingy which does nothing but stick PNGs in ICO framework (that 
is, again, does not try to pretend being smarter than me), so I can 
build a set of PNGs, feed them to oxipng, then feed them to my reptile 
creature (not surprisingly, it's called "PNG Sanctifier"), and viola, I 
get exactly what I want.

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

[William F Pokorny] Re: img2mesh update

Tue, 1 Sep 2026 16:46:11 GMT

On 8/31/26 23:20, Ilya Razmanov wrote:
> different types of triangle splitting for smooth and sharp source areas

Cool :-)

 > Animated png

Cool. What method / tool did you use for the encoding?

Bill P.

[ingo] Re: img2mesh update

Tue, 1 Sep 2026 13:19:51 GMT

On 2026-09-01 05:20, Ilya Razmanov wrote:
> as some might remember

I do. I like it.

Cheers,

ingo

[Ilya Razmanov] img2mesh update

Tue, 1 Sep 2026 03:20:51 GMT

Greetings,

as some might remember, img2mesh is a pure Python program for converting 
2D image height fields into 3D triangle mesh, building somewhat 
interesting mesh geometry. Others may take a look at:

https://dnyarri.github.io/img2mesh.html

One of the interesting features of img2mesh is using different types of 
triangle splitting for smooth and sharp source areas, named geometry 3 
and 1, correspondingly. Geometry choice is based on local image contrast 
(currently on max abs difference within neighbour pixels window), more 
specifically, on results of applying user-defined threshold criterion to 
local contrast.

Main reason for current img2mesh update is adding a threshold mask 
display to img2mesh GUI, so now user may easily switch between source 
image preview and mask representation, and edit threshold visually (an 
animated GUI screenshot is attached. Yes, I insist - it's animated, no 
matter what your newsreader says! After all, animated PNG recently 
became accepted as a part of PNG specs). I've spent several days trying 
to make a GUI which I myself wouldn't consider disgusting, so, 
hopefully, other people may find it useful as well.

Simplest way to download img2mesh, as always, is visiting release page:

https://github.com/Dnyarri/img2mesh/releases/latest

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

[yesbird] Re: Hello gang - getting back to it.

Fri, 28 Aug 2026 21:04:11 GMT

On 28/08/2026 17:54, Mike Miller wrote:
> Thanks BE. I'll look into Rune & Koppi's work. I just posted an animation on my
> site of my current progress. I'm tweaking the topo and looking at vegetation
> ideas along with programming some practical effects (gas and/or venting liquid)

Most of all I like twilight atmosphere and lightning - it's very cozy ).
Together with large-scale mechanical parts this scene creates very
specific impression. Looking forward for next steps.

As to effects, may be this volume rendering example can help ?
https://paulbourke.net/miscellaneous/povexamples/
-- 
YB

[Mike Miller] Re: Hello gang - getting back to it.

Fri, 28 Aug 2026 14:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> This is really giving me the "Gates of Durin" / "Mines of Moria" vibe.
>
> I would imagine that Rune wrote some sort of particle physics thing.
> Koppi's particle physics playground.
> I'd also highly suggest "10 minute physics" on YT.
>
> Somehow all of this eye candy is so much better because I know it's being
> rendered with POV-Ray.
>
> - BE

Thanks BE. I'll look into Rune & Koppi's work. I just posted an animation on my
site of my current progress. I'm tweaking the topo and looking at vegetation
ideas along with programming some practical effects (gas and/or venting liquid)
Miller

[Bald Eagle] Re: Hello gang - getting back to it.

Thu, 27 Aug 2026 01:10:00 GMT

This is really giving me the "Gates of Durin" / "Mines of Moria" vibe.

I would imagine that Rune wrote some sort of particle physics thing.
Koppi's particle physics playground.
I'd also highly suggest "10 minute physics" on YT.

Somehow all of this eye candy is so much better because I know it's being
rendered with POV-Ray.

- BE

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 26 Aug 2026 22:05:01 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > yesbird wrote:
> > > On 09/08/2026 15:46, Mike Miller wrote:
> > > > I'm still trying to visualize what is happening on the lower 'entry' level. I
> > > > picture the camera starting at the base of a 'cooling' liquid pool and pipes
> > > > with the camera drifting up the stairs and towards the tunnel entrance.
Attached
> > > > are my current thoughts on the lower level, but I'm still looking at some
> > > > reference, so the design may change. :)
> > >
> > > I like what I see and your images remind me of my childhood when
> > >
> > > I guess finding the optimal camera path can be done easily in
> > > Blender first.
> > > --
> > > YB
> >
> > Yep, I'm definitely using Blender for quick camera angle studies. I jumped into
> > Lumion this morning to start modeling a possible topo terrain and to get a
> > better idea of how much foreground modeling I have. Attached are some quick
> > screen studies from Lumion of what I have so far. I'll be able to export the
> > ..raw height field map to duplicate in POV.
> > Mike.
>
> Attached are some POV progress renderings of my pumphouse project. I'm finishing
> up the topo and have a few more mechanical pipes to model. It's turning into
> more into a fantasy piece than I had original pictured. I'll be adding
> vegetation to the topo and a yet to be designed creature. I'm also thinking
> about adding a 'particle/blob' form venting out one of the pipes. I'm assuming
> someone has written a POV 3D particle generator? some kind of an emitter with an
> object/position array? Not sure I'm ready to tackle the programming or re-invent
> the wheel if there's good working examples. :)
>
> Mike


SORRY... That PDF was no good. Here's a jpeg of what I described above. I see my
hare return formatting is all over the place. :)

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 26 Aug 2026 21:05:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> yesbird wrote:
> > On 09/08/2026 15:46, Mike Miller wrote:
> > > I'm still trying to visualize what is happening on the lower 'entry' level. I
> > > picture the camera starting at the base of a 'cooling' liquid pool and pipes
> > > with the camera drifting up the stairs and towards the tunnel entrance. Attached
> > > are my current thoughts on the lower level, but I'm still looking at some
> > > reference, so the design may change. :)
> >
> > I like what I see and your images remind me of my childhood when
> >
> > I guess finding the optimal camera path can be done easily in
> > Blender first.
> > --
> > YB
>
> Yep, I'm definitely using Blender for quick camera angle studies. I jumped into
> Lumion this morning to start modeling a possible topo terrain and to get a
> better idea of how much foreground modeling I have. Attached are some quick
> screen studies from Lumion of what I have so far. I'll be able to export the
> ..raw height field map to duplicate in POV.
> Mike.

Attached are some POV progress renderings of my pumphouse project. I'm finishing
up the topo and have a few more mechanical pipes to model. It's turning into
more into a fantasy piece than I had original pictured. I'll be adding
vegetation to the topo and a yet to be designed creature. I'm also thinking
about adding a 'particle/blob' form venting out one of the pipes. I'm assuming
someone has written a POV 3D particle generator? some kind of an emitter with an
object/position array? Not sure I'm ready to tackle the programming or re-invent
the wheel if there's good working examples. :)

Mike

[Mike Miller] Re: is this website still alive?

Tue, 25 Aug 2026 15:00:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Demian" <cuc### [at] gmailcom> wrote:
> > hi! I am a beginner in POV-Ray and I have been searching for a group where I can
> > talk about it. is this website still alive?
>
> yes.  and "hello" :-).
>
>
> regards, jr.

Hello. This is a great site, and everyone here are friendly nerds that love 3D,
programming and raytracing. I've been visiting this site forever and there's so
much knowledge here to be gained. Best wishes
Miller

[jr] Re: is this website still alive?

Sun, 23 Aug 2026 13:50:00 GMT

hi,

"Demian" <cuc### [at] gmailcom> wrote:
> hi! I am a beginner in POV-Ray and I have been searching for a group where I can
> talk about it. is this website still alive?

yes.  and "hello" :-).


regards, jr.

[Demian] is this website still alive?

Sun, 23 Aug 2026 12:25:00 GMT

hi! I am a beginner in POV-Ray and I have been searching for a group where I can
talk about it. is this website still alive?

[jr] Re: pls make a app...

Fri, 21 Aug 2026 11:30:00 GMT

hi,

"" wrote:
> > >  it would be helpful if you could post additional information on the bug (?),
> > ...
> i realized that i can use moray to have preview and its great!
>
> - Emirhan

problem solved, good news :-), thanks.


regard, jr.

[] Re: pls make a app...

Thu, 20 Aug 2026 21:05:00 GMT

> >  it would be helpful if you could post additional information on the bug (?),
> yeah... i know... idk if my laptop having a bug or something. i just tried it
> again but when i move object, it doesn't move. idk if i can solve this (im a
> begineer)

i realized that i can use moray to have preview and its great!

- Emirhan

[ingo] Re: Termux !!!

Thu, 20 Aug 2026 16:55:00 GMT

"Cossack " <nomail@nomail> wrote:

> The Holy Trinity in one room !!!!

One of them would be enough ;) I have 3 moto g6 plus' doing nothing. Any way to
do distributed rendering on android 9?

How "fast" is a processor on a phone? I have no clue.

Chipset Qualcomm SDM630 Snapdragon 630 (14 nm)
CPU  Octa-core 2.2 GHz Cortex-A53
GPU  Adreno 508

My only experiment with termux was running my TUI RPN on it. I find these phones
very cumbersome, but for a little render farm, who knows.

ingo

[ingo] Re: looking for a Ron Parker macro or scene

Thu, 20 Aug 2026 11:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > I did a number of v3.7 & v3.8 renders vs yuqk renders
>
> Nice!
>
> This looks like a similar pattern posted by Mike Williams, and also a bit like
> the patterns by Tek that I animated.
>
> I would imagine that there are tons of variations we could do with this, as well
> as perhaps applying "attractors" to vary the pattern.
>
> - BE

I had a somewhat similar idea for patterns. First create a "WorleyForceFiled", a
smooth vector field pointing away from every nearby Worley feature point.

This you can feed into a domain warp that pushes the pattern away a bit, or
pulls it in. Inspired by the black hole warp but without the black holes and
somewhat different.

In my ray-tracer source:

proc worleyWarp*(
    p: PatternSpec,
    amount: float32 = 1.0f,
    radius: float32 = 1.2f,
    seed: int64 = 0,
    searchRadius: int = 1,
): PatternSpec =

  let force = worleyForceField(seed, radius, searchRadius)
  let displaceFn = proc(point: Vec3): Vec3 {.gcsafe.} =
    point + force(point) * amount
  warpedBy(p, displaceFn)

it works, but the ray-tracer as a whole currently not, so no pretty pictures.

ingo

[jr] Re: Refreshing newgroup pages

Wed, 19 Aug 2026 21:20:00 GMT

hi,

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> ... I'm now telling Cloudflare to bypass its own cache, but also telling it to send
an expire time of one minute to t
he browser.

works for me, thx.


regards, jr.

[Chris Cason] Re: Refreshing newgroup pages

Wed, 19 Aug 2026 20:22:16 GMT

On 19/08/2026 23:15, Bald Eagle wrote:
> I noticed yesterday that I missed out on around 2 days of messages because
> reloading the full message page didn't update the posts.
> 
> This morning, I KNEW that there were messages, and that I had posted some as
> well, but had difficulties getting the digest to refresh the posted messages.
> 
> I had to go a roundabout way to get an updated digest page.
> Maybe this has to do with all the cloudflare stuff - I dunno.

I do have a cache bypass rule for the digests configured in cloudflare. However the
specifics of it have changed a bit over the last few days, and it could be your
browser cached a longer expire time. I'm now telling Cloudflare to bypass its own
cache, but also telling it to send an expire time of one minute to the browser.

If you are still getting issues please let me know the exact URL you are having
problems with and also, if you can, give me the full headers of the response. These
can be accessed if you have your browser's developer tools open at the time you load
the page, and go to the network pane.

[jr] Re: Refreshing newgroup pages

Wed, 19 Aug 2026 13:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I noticed yesterday that I missed out on around 2 days of messages because
> reloading the full message page didn't update the posts.
>
> This morning, I KNEW that there were messages, and that I had posted some as
> well, but had difficulties getting the digest to refresh the posted messages.
>
> I had to go a roundabout way to get an updated digest page.
> Maybe this has to do with all the cloudflare stuff - I dunno.

correct, yes, Cloudflare.  Chris posted a few days ago about it being necessary.
 here I have to Shift-Reload, always, or I get a stale, "cached" page (using
Chrome).


regards, jr.

[Bald Eagle] Refreshing newgroup pages

Wed, 19 Aug 2026 13:20:00 GMT

I noticed yesterday that I missed out on around 2 days of messages because
reloading the full message page didn't update the posts.

This morning, I KNEW that there were messages, and that I had posted some as
well, but had difficulties getting the digest to refresh the posted messages.

I had to go a roundabout way to get an updated digest page.
Maybe this has to do with all the cloudflare stuff - I dunno.

Just thought I'd mention it.

- BE

[Maetes] Re: pool water

Wed, 19 Aug 2026 12:15:00 GMT

"David Kraics" <bar### [at] aolcom> wrote:
> Hello. I'm doing a render of a building with a roof top pool. I got the shape
> perfect, but I need help with a texture. Light blue with a little transparency.
> Does anyone have any suggestions?

maybe try out this tutorial.

https://www.f-lohmueller.de/pov_tut/backgrnd/p_wat1.htm

ma

[Bald Eagle] Re: pool water

Wed, 19 Aug 2026 10:40:00 GMT

> Light blue with a little transparency.
> > Does anyone have any suggestions?

Probably gonna need an interior with ior > 1

Try Fountain

https://paulbourke.net/miscellaneous/scc5/final.html

Also look for scenes using caustics, perhaps in the distro.

- BE

[jr] Re: pool water

Wed, 19 Aug 2026 06:30:00 GMT

hi,

"David Kraics" <bar### [at] aolcom> wrote:
> Hello. I'm doing a render of a building with a roof top pool. I got the shape
> perfect, but I need help with a texture. Light blue with a little transparency.
> Does anyone have any suggestions?

perhaps you can (re)use the water from the benchmark scene ?  the F Lohmueller
site too has some good water, in several of his examples.
<www.povray.org/download/benchmark.php>

regards, jr.

[David Kraics] pool water

Wed, 19 Aug 2026 04:40:00 GMT

Hello. I'm doing a render of a building with a roof top pool. I got the shape
perfect, but I need help with a texture. Light blue with a little transparency.
Does anyone have any suggestions?

[Bald Eagle] Re: looking for a Ron Parker macro or scene

Tue, 18 Aug 2026 19:00:00 GMT

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

> I did a number of v3.7 & v3.8 renders vs yuqk renders

Nice!

This looks like a similar pattern posted by Mike Williams, and also a bit like
the patterns by Tek that I animated.

I would imagine that there are tons of variations we could do with this, as well
as perhaps applying "attractors" to vary the pattern.

- BE

[jr] Re: looking for a Ron Parker macro or scene

Tue, 18 Aug 2026 10:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> :-) Hah! I do miss banging on POV-Ray with you guys. Maybe I'll more
> play time this winter.

that would be good.  who knows, maybe the winter will be long enough to see you
getting "bored" and adding an '-into' option ;-).  cheers.

@ingo
.... coffee ...
(sorry.. ;-))

regards, jr.

[kurtzlepirate] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 15:00:35 GMT

On 16/08/2026 15:54, ingo wrote:

> 
> Found it
> ---%<------%<------%<------%<---
> // Arabesque_tile by Ron Parker
 >
> [snip]>

Really very interesting. Thanks for sharing.




-- 
klp
compagnie de la banquise

[William F Pokorny] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 11:01:20 GMT

On 8/17/26 01:31, ingo wrote:
> On 2026-08-16 21:56, William F Pokorny wrote:
>> Results have me wondering how old POV-Ray versions rendered the scene, 
>> but I don't have any old compiles handy and no more time to play...
> 
> I found it in obscure directory with house renovation files dated 2003 
> and 2006. My guess it would have been made with POV-Ray 3.1
> 
> ingo

Thank you (& jr) for the additional information.

I woke up this morning remembering I released R15 of yuqk with the 
crackle cache disabled (a hack). It was done so I would always have 
handy crackle results without bad results due same thread cache 
collisions. Running this version showed no changes in the crackle solid 
color distribution.

I then decided to read my own yuqk release notes... I ran across this 
for R16: "Of note, the dependency the ip_solid option had on the noise 
generators was removed."

(ip_solid being yuqk's new internal pattern keyword for solid)

I've updated the release notes for this change to read:

Of note, the dependency the ip_solid option had on the noise generators 
was removed. This done so the solid values generated are evenly 
distributed between zero and one rather than being a sloppy, 
normalized/Gaussian set of values roughly centered about 0.5.

The color differences are due an intentional change to yuqk that I'd 
forgotten!

Bill P.

[William F Pokorny] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 11:00:02 GMT

On 8/17/26 01:27, jr wrote:
> +1.  seeing the pattern, immediately a question of "cosmic importance"
ðŸ™‚ came
> to mind, attached.

:-) Hah! I do miss banging on POV-Ray with you guys. Maybe I'll more 
play time this winter.

Bill P.

[ingo] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 05:34:44 GMT

On 2026-08-17 07:27, jr wrote:
> 
> +1.  seeing the pattern, immediately a question of "cosmic importance" :-) came
> to mind, attached.
> 
Oh my, coffee on the keyboard :) :)

ingo

[ingo] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 05:31:54 GMT

On 2026-08-16 21:56, William F Pokorny wrote:
> Results have me wondering how old POV-Ray versions rendered the scene, 
> but I don't have any old compiles handy and no more time to play...

I found it in obscure directory with house renovation files dated 2003 
and 2006. My guess it would have been made with POV-Ray 3.1

ingo

[jr] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 05:30:00 GMT

[jr] Re: looking for a Ron Parker macro or scene

Mon, 17 Aug 2026 05:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/16/26 09:54, ingo wrote:
> > Found it
>
> I'm glad you found it, and thanks for posting the code!

+1.  seeing the pattern, immediately a question of "cosmic importance" :-) came
to mind, attached.


> Results have me wondering how old POV-Ray versions rendered the scene,
> but I don't have any old compiles handy and no more time to play...

will post a second reply with a v3.7.0.8 render attached.


regards, jr.

[William F Pokorny] Re: looking for a Ron Parker macro or scene

Sun, 16 Aug 2026 19:56:15 GMT

On 8/16/26 09:54, ingo wrote:
> Found it

I'm glad you found it, and thanks for posting the code!

I did a number of v3.7 & v3.8 renders vs yuqk renders(a) given the code 
is exposed to the, multiple crackle uses within a thread, cache bug in 
the v3.7 and v3.8 code.

V3.8 beta 2 image on top and yuqk image on the bottom.

The color distribution looks better for the 'crackle solid' base pattern 
in yuqk, but I'm unsure why. I doubt it would be cache fix related - but 
maybe? Or, maybe something else with the yuqk re-write of the crackle 
code...

Results have me wondering how old POV-Ray versions rendered the scene, 
but I don't have any old compiles handy and no more time to play...

In any case, cool code!

Bill P.

(a) - I used 'crackle solid scale 0.3' for the base in the images attached.

[ingo] Re: looking for a Ron Parker macro or scene

Sun, 16 Aug 2026 13:54:21 GMT

On 2026-07-19 21:02, ingo wrote:
> I've been trying to dig up an old macro/scene by Ron Parker. It's not on 
> the server anymore, it's not in https://usenetarchives.com/groups.php? 
> c=povray
> 
> It is a macro/scene for creating a arabeske/arabic like tiling 
> pattern.The beauty was that it did work in 3D, not just on a 2D plane. 
> By adding a slight rotation to it the pattern kept changeing, while 
> still being similar.
> 
> Does it ring a bell? Anyone?
> 
> Sadly I lost my complete newsgroup archive.
> 
> Cheers,
> 
> Ingo

Found it
---%<------%<------%<------%<---
// Arabesque_tile by Ron Parker

#macro Arabesque( Param )
   #declare Sd = seed(Param);
   #declare Rv = <rand(Sd),rand(Sd),rand(Sd)>*500;
   #local C=pigment{crackle solid
     color_map{
       [1/12 red 1]
       [1/12 red 1 green 1][3/12 red 1 green 1]
       [3/12 green 1][5/12 green 1]
       [5/12 green 1 blue 1][7/12 green 1 blue 1]
       [7/12 blue 1][9/12 blue 1]
       [9/12 blue 1 red 1][11/12 blue 1 red 1]
       [11/12 red 1]
     }
   }
   #local G=pigment{crackle
     pigment_map{[.05 rgb 0][.05 C]}
     scale .2
     translate Rv
     warp {repeat z flip z}
   }
   #local B=pigment{
     radial
     pigment_map{
       #local i=0;
       /*#while(i<6)
         [i/6 G rotate(30+60*i)*y]
         [(i+1)/6 G rotate(30+60*i)*y]
         #local i=i+1;
       #end*/
       #while(i<12)
         [i/12 G rotate(15+30*i)*y]
         [(i+1)/12 G rotate(15+30*i)*y]
         #local i=i+1;
       #end
     }
   }
   #local T2=sqrt(3)/2;
   radial
   pigment_map{
     [1/3 B translate<.5,0,-T2>]
     [1/3 B translate<-1,0,0>]
     [2/3 B translate<-1,0,0>]
     [2/3 B translate<.5,0,T2>]
   }
   translate x
   warp{repeat 1.5*x flip x}
   warp{repeat .5*sqrt(3)*z flip z}
#end

plane {y 0 pigment {Arabesque(7)rotate <0,0,0.6>} finish {ambient 1} }
camera {location 10*y sky z look_at 0}
---%<------%<------%<------%<---

[Thomas de Groot] Re: nntp connexion hs

Tue, 11 Aug 2026 07:19:22 GMT

Thank you so much, Chris!

-- 
Thomas

[kurtzlepirate] Re: nntp connexion hs

Mon, 10 Aug 2026 07:22:28 GMT

On 09/08/2026 18:38, Chris Cason wrote:

> 
> Any chance that during the reconfiguration you added a username? This 
> isn't necessary for the NNTP server and unless you actually have an 
> account on it (which you don't; the website accounts are for HTTP, not 
> NNTP) then your connection will fail in the way you showed.


Yes, I did add a username.
I understand better now.

Thanks for clarifying that Chris.





-- 
klp
compagnie de la banquise

[William F Pokorny] Re: nntp connexion hs

Mon, 10 Aug 2026 05:30:48 GMT

On 8/8/26 22:21, Chris Cason wrote:
>> I can no longer connect to Thunderbird to read the news.
> 
> Folks,
...

Thank you Chris!

Bill P.

[Mike Miller] Re: Hello gang - getting back to it.

Sun, 9 Aug 2026 21:05:01 GMT

yesbird wrote:
> On 09/08/2026 15:46, Mike Miller wrote:
> > I'm still trying to visualize what is happening on the lower 'entry' level. I
> > picture the camera starting at the base of a 'cooling' liquid pool and pipes
> > with the camera drifting up the stairs and towards the tunnel entrance. Attached
> > are my current thoughts on the lower level, but I'm still looking at some
> > reference, so the design may change. :)
>
> I like what I see and your images remind me of my childhood when
>
> I guess finding the optimal camera path can be done easily in
> Blender first.
> --
> YB

Yep, I'm definitely using Blender for quick camera angle studies. I jumped into
Lumion this morning to start modeling a possible topo terrain and to get a
better idea of how much foreground modeling I have. Attached are some quick
screen studies from Lumion of what I have so far. I'll be able to export the
..raw height field map to duplicate in POV.
Mike.

[Chris Cason] Re: nntp connexion hs

Sun, 9 Aug 2026 16:38:34 GMT

On 10/08/2026 01:31, kurtzlepirate wrote:
> But... my thunderbird didn't handle this transition well, and nothing was working
anymore. I saw some really strange things in the logs (see screenshot).

Any chance that during the reconfiguration you added a username? This isn't necessary
for the NNTP server and unless you actually have an account on it (which you don't;
the website accounts are for HTTP, not NNTP) then your connection will fail in the way
you showed.

While it's working now, I'd still suggest you go to Settings -> Privacy & Security and
click on the "Saved Passwords" button. If in the list you get there is any reference
to news.povray.org then that was the cause.

-- Chris

[kurtzlepirate] Re: nntp connexion hs

Sun, 9 Aug 2026 15:31:50 GMT

On 09/08/2026 04:21, Chris Cason wrote:

> Folks,
> 
> Apologies for the issue, but web scrapers forced my hand by totally 
> bringing the system down attempting to scrape the news.povray.org web 
> interface with several thousand connections per second (!)
> 
> [snip]
> 
> At the moment, provided you can use the new IP address, access to port 
> 119 should work whichever method you employ.
> 

You don't need to apologize. If anything, we're the ones who should 
thank you for the work you do to maintain the POVray server for our 
little community.

Implementing a waf is always complicated. You have to constantly balance 
the service you offer with the security measures you need to put in 
place. In the world of wafs, darkness reigns supremeâ€”or perhaps even 
magic !!!

Setting up this new url just for nntp is a great idea. Simple and effective.

The issue has now been resolved. THANK YOU.

But... my thunderbird didn't handle this transition well, and nothing 
was working anymore. I saw some really strange things in the logs (see 
screenshot).

So I deleted all the POV-Ray configurations (I have other configurations 
for other NTP servers that work fine)

I'm in the process of reconfiguring everything, and my first test in 
p.test went well. Gotchaâ€Š!.

Hoping that Cloudflare doesn't introduce any more jokes.

Regards

[Chris Cason] Re: nntp connexion hs

Sun, 9 Aug 2026 13:59:26 GMT

On 9/08/2026 12:21, Chris Cason wrote:
> This has resulted in news.povray.org getting a new IP address pointing at
cloudflare, and it doesn't relay or proxy NNTP.

Also, for the record, I have now added NNTP SRV records to the DNS for povray.org and
news.povray.org. For the technically inclined, you can use nslookup or dig etc to
query _nntp._tcp.povray.org or _nntp._tcp.news.povray.org. e.g. "nslookup -q=srv
_nntp._tcp.povray.org" or "dig _nntp._tcp.povray.org SRV +short".

There are very few NNTP clients that use SRV but it is a thing (see
https://datatracker.ietf.org/doc/html/rfc2782) and will remain for as long as we can
still run NNTP.

[Chris Cason] Re: nntp connexion hs

Sun, 9 Aug 2026 13:30:43 GMT

To give you an idea of how insane the (presumably AI) scraper was hitting us, here's a
screenshot of the DNS analytics for the period in question (I can't use HTTP analytics
for the "before" period because at the time news.povray.org was not proxied by
Cloudflare and thus they have no data on it; the DNS queries are a substitute).

Keep in mind each DNS query for the IP address of news.povray.org does not equal one
connection, since the scrapers only need to query for the IP address once per client,
and it is then cached. This was demonstrated when I did turn on Cloudflare proxying
but the hammering continued due to the above caching, leading me to need to firewall
it off for a day or two.

We will never know how many individual IP addresses were involved in the attack but I
expect it to be in the millions. This is not unprecedented - we had to deal with a
network of scrapers hitting the f-lohmueller.de site a month or two ago. In that case,
while they were coming in fast, they weren't so fast as to overflow the listen queue
so we were able to log every request (it also helps that the FL site is fully static,
no PHP and no database, which is not the case for the news server). As JR can attest,
for that case alone the logs showed the requests coming from over 800,000 unique IP
addresses. Fortunately we were able to isolate them well enough to firewall those off.

In the DNS analytics screenshot (taken today) you can see that over the prior three
days there were about 29 million queries for the address of news.povray.org, averaging
130 queries/second. But that's over three days - you can see from the spike that
almost all were on Friday (AU time) and peaked at 2.6 million requests/hour (about 720
requests/second) just after 3pm, at which time I started tuning the Cloudflare ruleset
to keep bots out but allow normal visitors (there was a pattern in the HTTP requests).
I was trying to avoid having to use a challenge (the "are you human" dialog that web
visitors get) but in the end I had to turn that on, too, as none of the rules I set up
would bite hard enough. I probably could have done it with a regex, but that's only
available for Enterprise customers*

In the screenshot of the HTTP analytics - which only became relevant once I turned on
the proxy - you can see that in a single four-hour period there were over 17 million
requests, peaking at around 250,000 per minute at 3:15-ish, at which point I started
setting the bot rejection rules. These requests were only from clients that "saw" the
new IP address, as mentioned above there were an unknown (but very large) number of
bots still hitting the direct IP address, which Cloudflare doesn't see.

Overall this careless, stupid and needless deployment of a clearly broken scraper not
only took down the site for a while but also has cost me at least a day of lost
productivity, as well as requiring the DNS change which blocked NNTP access. It is
almost beyond belief that anyone would expect something like this to work. I can only
assume it's a so-called "vibe-coded" program and that the authors simply *did not
care* if it worked or not, they just deployed it anyway.

I have taken the time to document this not only to show our userbase why we had to
make the change, but also to make a public record of what's been going on behind the
scenes due to the race to train LLM's and the cheap availability of immense
residential proxy networks. I will also post this same data to povray.org's front
page.

Our site is not by any means the only one dealing with this sort of nonsense, and I
suspect it's going to get worse before it gets better.

* That said I am grateful to Cloudflare for providing us with a free "Pro" account
under their open-source initiative.

-- Chris

[yesbird] Re: Hello gang - getting back to it.

Sun, 9 Aug 2026 13:19:40 GMT

On 09/08/2026 15:46, Mike Miller wrote:
> I'm still trying to visualize what is happening on the lower 'entry' level. I
> picture the camera starting at the base of a 'cooling' liquid pool and pipes
> with the camera drifting up the stairs and towards the tunnel entrance. Attached
> are my current thoughts on the lower level, but I'm still looking at some
> reference, so the design may change. :)

I like what I see and your images remind me of my childhood when
grandfather (ChiefÂ mechanic of theÂ heavy machine
toolsÂ plant) was
workingÂ at home with blueprints. At the age of 5 I was completely
enchanted with the powerÂ and the beauty of mechanics.

I guess finding the optimal camera path can be done easily in
Blender first.
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Sun, 9 Aug 2026 12:50:01 GMT

yesbird wrote:
> On 06/08/2026 20:29, Mike Miller wrote:
> > Attached are final plan and elevation renderings from POV of this pump house
> > model. I rendered them at 8K and started drafting a section of the lower level
> > to start the foreground hardscape and topo. I'm working on a pencil drawing of
> > what I imagine as the 'approach' shot and will post.
>
> Excellent combination of pencil and 3D rendering - looks very
> impressive. I am also following updates on your site and
> like new images that appear there, including sketches.
> Some of them remind me of Roger Dean works - wild boar is very good !
> https://www.miller-raytracer.com/s-k-e-t-c-h-e-s
> --
> YB

Thanks YB.
I'm still trying to visualize what is happening on the lower 'entry' level. I
picture the camera starting at the base of a 'cooling' liquid pool and pipes
with the camera drifting up the stairs and towards the tunnel entrance. Attached
are my current thoughts on the lower level, but I'm still looking at some
reference, so the design may change. :)
Mike.

[yesbird] Re: nntp connexion hs

Sun, 9 Aug 2026 10:08:53 GMT

On 09/08/2026 05:21, Chris Cason wrote:
> Apologies for the issue, but web scrapers forced my hand by totally 
> bringing the system down attempting to scrape the news.povray.org web 
> interface with several thousand connections per second (!)

Chris,
thanks so much for this fix and all other things you are doing for our
community. Changing server address to nntp.povray.org in settings works
fine for me.
--
YB

[yesbird] Re: Hello gang - getting back to it.

Sun, 9 Aug 2026 10:03:37 GMT

On 06/08/2026 20:29, Mike Miller wrote:
> Attached are final plan and elevation renderings from POV of this pump house
> model. I rendered them at 8K and started drafting a section of the lower level
> to start the foreground hardscape and topo. I'm working on a pencil drawing of
> what I imagine as the 'approach' shot and will post.

Excellent combination of pencil and 3D rendering - looks very
impressive. I am also following updates on your site and
like new images that appear there, including sketches.
Some of them remind me of Roger Dean works - wild boar is very good !
https://www.miller-raytracer.com/s-k-e-t-c-h-e-s
-- 
YB

[Chris Cason] Re: nntp connexion hs

Sun, 9 Aug 2026 02:49:25 GMT

On 9/08/2026 12:21, Chris Cason wrote:
> by now the scrapers should all have picked up the new IP address, or so I hope.

And this does appear to be the case. So direct connections to the www server should
work again, meaning a hosts entry is probably the best approach for those who can use
it.

-- Chris

[Chris Cason] Re: nntp connexion hs

Sun, 9 Aug 2026 02:21:33 GMT

On 8/08/2026 23:24, kurtz le pirate wrote:
> I can no longer connect to Thunderbird to read the news.

Folks,

Apologies for the issue, but web scrapers forced my hand by totally bringing the
system down attempting to scrape the news.povray.org web interface with several
thousand connections per second (!)

There was no clear pattern of IP addresses or other facets I could use to block them
server-side so I had no option but to turn on cloudflare for the news and www sites.

This has resulted in news.povray.org getting a new IP address pointing at cloudflare,
and it doesn't relay or proxy NNTP.

The workaround for now is to either use a new DNS entry I have created -
nntp.povray.org - which points at the real IP address, or to add a new hosts entry to
your system that equates news.povray.org to the IP address 203.29.75.35. This has the
downside that connections to the web view at news.povray.org will no longer work,
since even after I cloaked news.povray.org with cloudflare, I was still seeing
millions of connections direct to the IP address and had to block ingress on port 80
and 443 to cloudflare IP's only.

After posting this message I will give turning off the IP block a test to see if the
direct connections have gone away - by now the scrapers should all have picked up the
new IP address, or so I hope.

Which method you use depends on your NNTP software. Thunderbird allows you to change
the IP without losing your existing cached NG's, content etc, so changing to
nntp.povray.org in the connection settings should work. Other software may require you
to toss your cached data (my iOS newsreader wanted to do this).

At the moment, provided you can use the new IP address, access to port 119 should work
whichever method you employ.

-- Chris

[Uncle Josh] Re: nntp connexion hs

Sat, 8 Aug 2026 22:30:00 GMT

"kurtz le pirate" <kur### [at] freefr> wrote:
> Hello,
>
> I can no longer connect to Thunderbird to read the news.

I'm glad it's not just me. I was getting very frustrated because Thunderbird
also seemed to disconnect from my Bluehost email and Bluehost is not being
helpful in reconnecting.

Uncle Josh

[yesbird] Re: nntp connexion hs

Sat, 8 Aug 2026 14:10:00 GMT

"kurtz le pirate" <kur### [at] freefr> wrote:
> I can no longer connect to Thunderbird to read the news.

Same here and also thanks to jr for explanation, will communicate by Web now.
--
YB

[kurtz le pirate] nntp connexion hs

Sat, 8 Aug 2026 13:25:00 GMT

Hello,

I can no longer connect to Thunderbird to read the news.

I tried using the web interface, but I was denied access there as well.
My “kurtz the pirate” account seems to have disappeared.

I just created an account that lets me log in via the web interface, but I still
can't log in via nntp.

Still getting the same error in the thunderbird console :

error { target: TCPSocket, isTrusted: true, name: "ConnectionRefusedError",
message: "Network", errorCode: 2152398861, srcElement: TCPSocket, currentTarget:
TCPSocket, eventPhase: 2, bubbles: false, cancelable: false, … }
ConnectionRefusedError Network 2152398861 NntpClient.sys.mjs:254:18
_onError resource:///modules/NntpClient.sys.mjs:254

jr (thanks to him) told me that chris must have, quite rightly, put safeguards
in place with cloudflare

Could using 563 (SSL/TLS) be a solution?


If you have a solution, I'd love to hear it!
Thanks in advance

[Mike Miller] Re: Hello gang - getting back to it.

Thu, 6 Aug 2026 17:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > ...
> > I seem to be dropping sentences when I use line returns in my responses. My
> > previewed messages look OK except for the mis-spells. :) ?
>
> not your fault, the forum s/ware struggles with UTF-8.
>
>
> regards, jr.

Thanks jr. It had me confused. :)

Attached are final plan and elevation renderings from POV of this pump house
model. I rendered them at 8K and started drafting a section of the lower level
to start the foreground hardscape and topo. I'm working on a pencil drawing of
what I imagine as the 'approach' shot and will post.
Miller

[jr] Re: Hello gang - getting back to it.

Thu, 6 Aug 2026 05:35:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> ...
> I seem to be dropping sentences when I use line returns in my responses. My
> previewed messages look OK except for the mis-spells. :) ?

not your fault, the forum s/ware struggles with UTF-8.


regards, jr.

[Mike Miller] Re: Hello gang - getting back to it.

Thu, 6 Aug 2026 03:25:01 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > "Mike Miller" <mil### [at] gmailcom> wrote:
> > > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > > "Mike Miller" <mil### [at] gmailcom> wrote:
> > > >
> > > > > Attached are elevations & plan renderings from POV of my current pump house
> > > > > model.
> > > >
> > > > Damn.
> > > > I'm not an architect or a graphic designer, but have done a fair amount of
> > > > building work, and have needed to measure/estimate the sizes of things, and
have
> > > > designed and drawn plans for buildings, staircases, landscapes, etc.
> > > >
> > > > I love this stuff.
> > > >
> > > > Do you model everything as meshes first?
> > > > Do you ever create anything with scripts/CSG?
> > > >
> > > > What about the textures?
> > > > Are they designed with 3rd party tools?
> > > > UV mapping?
> > > >
> > > > Is anything ever done procedurally?
> > > >
> > > > Why/why not would help a lot of people get good work done more quickly and
then
> > > > step two is making it LOOK better without 100 iterations of tweaking.
> > > >
> > > > - BE
> > >
> > > >> designed and drawn plans for buildings, staircases, landscapes, etc.
> > > Nice, that kind of how I got into architecture. I spent summers in high school
> > > restoring churches and was fascinated when I got to work on old sets of
> > > drawings.
> > >
> > > >> Do you model everything as meshes first?
> > > For the production/client work, yes, but in POV, I try to build scenes without
> > >
> > > do use Blender for some complete forms and for exporting position data for POV
> > > types.
> > >
> > > >> Do you ever create anything with scripts/CSG?
> > > Yes, use macros to create 'types' with 'properties' like: bolts, pipes, window
> > > frames, beams, etc. I also use them in writing & testing materials & for
> > >
> > >
> > > >> What about the textures?> Are they designed with 3rd party tools?
> > > >> UV mapping?
> > > For my POV work, it is a mix. I relied heavily on image mapped textures for my
> > > architectural renderings, but I prefer to make procedural textures for my POV
> > > renderings. Professionally, we use a PBR setup with real-time viewing which
> > > makes the texturing process easier. I still export some diffuse and normal maps
> > > out of Substance.
> > >
> > > Mike
> >
> > SORRY -- I posted something very cryptic this morning.
> >
> > >> designed and drawn plans for buildings, staircases, landscapes, etc.
> >
> > youth-group restoring old churches and was fascinated when I got to work on an
> > old set of drawings. I went from drawing comic books to illustrating building.
> >
> > >> Do you model everything as meshes first?
> > For the production/client work, yes, but in POV, I try to build scenes without
> >
> > do use Blender for some complex forms and for exporting position data for POV
> > types.
> > >> Do you ever create anything with scripts/CSG?
> >
> > Yes, use macros to create 'types with properties' objects: bolts, pipes, window
> > frames, beams, etc. I also use them in my writing & testing materials & for
> >
> > use and can post here. I program parametric Revit families and use a simulate
> > setup in POV (using a 2D profile to create extrudes, sweeps, voids, etc.). I use
> > 'mixed' array to create a 'Sudo' class for storing properties that get passed to
> > a 'construction' macro. It allows for creating many variations from the same
> > template.
> >
> > >> What about the textures?> Are they designed with 3rd party tools?
> > >> UV mapping?
> > For my POV work, it is a mix. I relied heavily on image mapped textures for my
> > architectural renderings, but I prefer to make procedural textures for my POV
> > renderings. Professionally, we use a PBR setup with real-time viewing which
> > makes the texturing process easier. I still export some diffuse and bump-maps
> > out of Substance.
> > Miller
>
> I seem to be dropping sentences when I use line returns in my responses. My
> previewed messages look OK except for the mis-spells. :) ?


Attached are POV renderings of my current model / progress. I still a few more
parts to model and then I'll start working on the foreground hardscape and topo.
Mike.

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 5 Aug 2026 20:30:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > "Mike Miller" <mil### [at] gmailcom> wrote:
> > >
> > > > Attached are elevations & plan renderings from POV of my current pump house
> > > > model.
> > >
> > > Damn.
> > > I'm not an architect or a graphic designer, but have done a fair amount of
> > > building work, and have needed to measure/estimate the sizes of things, and have
> > > designed and drawn plans for buildings, staircases, landscapes, etc.
> > >
> > > I love this stuff.
> > >
> > > Do you model everything as meshes first?
> > > Do you ever create anything with scripts/CSG?
> > >
> > > What about the textures?
> > > Are they designed with 3rd party tools?
> > > UV mapping?
> > >
> > > Is anything ever done procedurally?
> > >
> > > Why/why not would help a lot of people get good work done more quickly and then
> > > step two is making it LOOK better without 100 iterations of tweaking.
> > >
> > > - BE
> >
> > >> designed and drawn plans for buildings, staircases, landscapes, etc.
> > Nice, that kind of how I got into architecture. I spent summers in high school
> > restoring churches and was fascinated when I got to work on old sets of
> > drawings.
> >
> > >> Do you model everything as meshes first?
> > For the production/client work, yes, but in POV, I try to build scenes without
> >
> > do use Blender for some complete forms and for exporting position data for POV
> > types.
> >
> > >> Do you ever create anything with scripts/CSG?
> > Yes, use macros to create 'types' with 'properties' like: bolts, pipes, window
> > frames, beams, etc. I also use them in writing & testing materials & for
> >
> >
> > >> What about the textures?> Are they designed with 3rd party tools?
> > >> UV mapping?
> > For my POV work, it is a mix. I relied heavily on image mapped textures for my
> > architectural renderings, but I prefer to make procedural textures for my POV
> > renderings. Professionally, we use a PBR setup with real-time viewing which
> > makes the texturing process easier. I still export some diffuse and normal maps
> > out of Substance.
> >
> > Mike
>
> SORRY -- I posted something very cryptic this morning.
>
> >> designed and drawn plans for buildings, staircases, landscapes, etc.
>
> youth-group restoring old churches and was fascinated when I got to work on an
> old set of drawings. I went from drawing comic books to illustrating building.
>
> >> Do you model everything as meshes first?
> For the production/client work, yes, but in POV, I try to build scenes without
>
> do use Blender for some complex forms and for exporting position data for POV
> types.
> >> Do you ever create anything with scripts/CSG?
>
> Yes, use macros to create 'types with properties' objects: bolts, pipes, window
> frames, beams, etc. I also use them in my writing & testing materials & for
>
> use and can post here. I program parametric Revit families and use a simulate
> setup in POV (using a 2D profile to create extrudes, sweeps, voids, etc.). I use
> 'mixed' array to create a 'Sudo' class for storing properties that get passed to
> a 'construction' macro. It allows for creating many variations from the same
> template.
>
> >> What about the textures?> Are they designed with 3rd party tools?
> >> UV mapping?
> For my POV work, it is a mix. I relied heavily on image mapped textures for my
> architectural renderings, but I prefer to make procedural textures for my POV
> renderings. Professionally, we use a PBR setup with real-time viewing which
> makes the texturing process easier. I still export some diffuse and bump-maps
> out of Substance.
> Miller

I seem to be dropping sentences when I use line returns in my responses. My
previewed messages look OK except for the mis-spells. :) ?

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 5 Aug 2026 18:45:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Mike Miller" <mil### [at] gmailcom> wrote:
> >
> > > Attached are elevations & plan renderings from POV of my current pump house
> > > model.
> >
> > Damn.
> > I'm not an architect or a graphic designer, but have done a fair amount of
> > building work, and have needed to measure/estimate the sizes of things, and have
> > designed and drawn plans for buildings, staircases, landscapes, etc.
> >
> > I love this stuff.
> >
> > Do you model everything as meshes first?
> > Do you ever create anything with scripts/CSG?
> >
> > What about the textures?
> > Are they designed with 3rd party tools?
> > UV mapping?
> >
> > Is anything ever done procedurally?
> >
> > Why/why not would help a lot of people get good work done more quickly and then
> > step two is making it LOOK better without 100 iterations of tweaking.
> >
> > - BE
>
> >> designed and drawn plans for buildings, staircases, landscapes, etc.
> Nice, that kind of how I got into architecture. I spent summers in high school
> restoring churches and was fascinated when I got to work on old sets of
> drawings.
>
> >> Do you model everything as meshes first?
> For the production/client work, yes, but in POV, I try to build scenes without
>
> do use Blender for some complete forms and for exporting position data for POV
> types.
>
> >> Do you ever create anything with scripts/CSG?
> Yes, use macros to create 'types' with 'properties' like: bolts, pipes, window
> frames, beams, etc. I also use them in writing & testing materials & for
>
>
> >> What about the textures?> Are they designed with 3rd party tools?
> >> UV mapping?
> For my POV work, it is a mix. I relied heavily on image mapped textures for my
> architectural renderings, but I prefer to make procedural textures for my POV
> renderings. Professionally, we use a PBR setup with real-time viewing which
> makes the texturing process easier. I still export some diffuse and normal maps
> out of Substance.
>
> Mike

SORRY -- I posted something very cryptic this morning.

>> designed and drawn plans for buildings, staircases, landscapes, etc.
Nice, that’s kind of how I got into architecture. I spent summers in high school
youth-group restoring old churches and was fascinated when I got to work on an
old set of drawings. I went from drawing comic books to illustrating building.

>> Do you model everything as meshes first?
For the production/client work, yes, but in POV, I try to build scenes without
mesh. It’s rewarding to me when I can a build a complex object in pure CSG.  I
do use Blender for some complex forms and for exporting position data for POV
types.
>> Do you ever create anything with scripts/CSG?

Yes, use macros to create 'types with properties' objects: bolts, pipes, window
frames, beams, etc. I also use them in my writing & testing materials & for
read/write functions between software’s. I have a set of architectural macros I
use and can post here. I program parametric Revit families and use a simulate
setup in POV (using a 2D profile to create extrudes, sweeps, voids, etc.). I use
'mixed' array to create a 'Sudo' class for storing properties that get passed to
a 'construction' macro. It allows for creating many variations from the same
template.

>> What about the textures?> Are they designed with 3rd party tools?
>> UV mapping?
For my POV work, it is a mix. I relied heavily on image mapped textures for my
architectural renderings, but I prefer to make procedural textures for my POV
renderings. Professionally, we use a PBR setup with real-time viewing which
makes the texturing process easier. I still export some diffuse and bump-maps
out of Substance.
Miller

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 5 Aug 2026 12:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > Attached are elevations & plan renderings from POV of my current pump house
> > model.
>
> Damn.
> I'm not an architect or a graphic designer, but have done a fair amount of
> building work, and have needed to measure/estimate the sizes of things, and have
> designed and drawn plans for buildings, staircases, landscapes, etc.
>
> I love this stuff.
>
> Do you model everything as meshes first?
> Do you ever create anything with scripts/CSG?
>
> What about the textures?
> Are they designed with 3rd party tools?
> UV mapping?
>
> Is anything ever done procedurally?
>
> Why/why not would help a lot of people get good work done more quickly and then
> step two is making it LOOK better without 100 iterations of tweaking.
>
> - BE

>> designed and drawn plans for buildings, staircases, landscapes, etc.
Nice, that kind of how I got into architecture. I spent summers in high school
restoring churches and was fascinated when I got to work on old sets of
drawings.

>> Do you model everything as meshes first?
For the production/client work, yes, but in POV, I try to build scenes without
mesh. It’s rewarding for me when I can a build a complex object in pure CSG.  I
do use Blender for some complete forms and for exporting position data for POV
types.

>> Do you ever create anything with scripts/CSG?
Yes, use macros to create 'types' with 'properties' like: bolts, pipes, window
frames, beams, etc. I also use them in writing & testing materials & for
read/write functions between software’s.

>> What about the textures?> Are they designed with 3rd party tools?
>> UV mapping?
For my POV work, it is a mix. I relied heavily on image mapped textures for my
architectural renderings, but I prefer to make procedural textures for my POV
renderings. Professionally, we use a PBR setup with real-time viewing which
makes the texturing process easier. I still export some diffuse and normal maps
out of Substance.

Mike

[Bald Eagle] Re: Hello gang - getting back to it.

Tue, 4 Aug 2026 22:20:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> Attached are elevations & plan renderings from POV of my current pump house
> model.

Damn.
I'm not an architect or a graphic designer, but have done a fair amount of
building work, and have needed to measure/estimate the sizes of things, and have
designed and drawn plans for buildings, staircases, landscapes, etc.

I love this stuff.

Do you model everything as meshes first?
Do you ever create anything with scripts/CSG?

What about the textures?
Are they designed with 3rd party tools?
UV mapping?

Is anything ever done procedurally?

Why/why not would help a lot of people get good work done more quickly and then
step two is making it LOOK better without 100 iterations of tweaking.

- BE

[yesbird] Re: Hello gang - getting back to it.

Tue, 4 Aug 2026 22:09:09 GMT

On 04/08/2026 22:28, Mike Miller wrote:
> Love seeing my fish model - it was fun to model. Your lighting shows it off
> well. I'd love to pass a few files to you if you have a free CPU....and
> absolutely no rush. I'm deep into the deep minutia of my current project.

Hi, Mike.
I will be glad to assist you in your projects by rendering them,
looking forward to sources.
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Tue, 4 Aug 2026 19:30:00 GMT

yesbird wrote:
> On 03/08/2026 23:37, Mike Miller wrote:
> > Yes, that workbench scene does have the object count - almost too many. I would
> > like to animate it someday if I could find a free CPU. :)
> > Mike
>
> Probably I can help you with CPU - I have a hosting with installed
> POVRay 3.8 for long-time experiments, which is not loaded now.
>
> Here is animation of your fish rendered in my small "farm":
> https://www.youtube.com/watch?v=JomLeE21Wic
> --
> YB

Thanks TB.
Love seeing my fish model - it was fun to model. Your lighting shows it off
well. I'd love to pass a few files to you if you have a free CPU....and
absolutely no rush. I'm deep into the deep minutia of my current project.
Mike.

[yesbird] Re: Hello gang - getting back to it.

Tue, 4 Aug 2026 19:09:16 GMT

On 03/08/2026 23:37, Mike Miller wrote:
> Yes, that workbench scene does have the object count - almost too many. I would
> like to animate it someday if I could find a free CPU. :)
> Mike

Probably I can help you with CPU - I have a hosting with installed
POVRay 3.8 for long-time experiments, which is not loaded now.

Here is animation of your fish rendered in my small "farm":
https://www.youtube.com/watch?v=JomLeE21Wic
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Tue, 4 Aug 2026 18:35:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Mike Miller" <mil### [at] gmailcom> wrote:
> >
> > > old site:  www.miller-headspin.com
> > >
> >
> > Hi Mike, went through the images from your old site. There's quite a few I don't
> > remember some of the later ones I do and then the there's "The Fish of '92".
> > Ahhhh
> >
> > If you still can track them, you should date all your images. Not for the gaps
> > in my memory, but just to see the time line.
> >
> > Cheers!
> >
> > ingo
>
> Thanks, ingo.
>
> I agree, I need to get dates and some better descriptions on my site. I lost
> most of my scene files from the early 90's to 2000's. I had posted much of this
> work on my CompuServe account...but I think it's vapor.
> I will be scanning and posting more of my artwork/sketches that I use to model
> POV work.
> Mike.


Attached are elevations & plan renderings from POV of my current pump house
model.
Cheers
Mike

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 3 Aug 2026 20:50:00 GMT

"ingo" <nomail@nomail> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > old site:  www.miller-headspin.com
> >
>
> Hi Mike, went through the images from your old site. There's quite a few I don't
> remember some of the later ones I do and then the there's "The Fish of '92".
> Ahhhh
>
> If you still can track them, you should date all your images. Not for the gaps
> in my memory, but just to see the time line.
>
> Cheers!
>
> ingo

Thanks, ingo.

I agree, I need to get dates and some better descriptions on my site. I lost
most of my scene files from the early 90's to 2000's. I had posted much of this
work on my CompuServe account...but I think it's vapor.
I will be scanning and posting more of my artwork/sketches that I use to model
POV work.
Mike.

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 3 Aug 2026 20:40:00 GMT

"Maetes" <nomail@nomail> wrote:
> Hi Mike, welcome back.
>
> I'm one of the new ones, only active since 2016.
>
> Nice website, crazy good pictures.
>
> I took a look a few days ago, there was a download section, from your workbench.
> Quite a lot of things in it, great that you published it (at least briefly).
>
> It's written for 3.8, but maybe I can still learn a bit for 3.7 (debian
> repository-install).
>
> Greetings from Cologne/Germany.

Hello Germany
Thanks, Maetes.
Yes, that workbench scene does have the object count - almost too many. I would
like to animate it someday if I could find a free CPU. :)
Mike

[ingo] Re: Hello gang - getting back to it.

Mon, 3 Aug 2026 17:45:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> old site:  www.miller-headspin.com
>

Hi Mike, went through the images from your old site. There's quite a few I don't
remember some of the later ones I do and then the there's "The Fish of '92".
Ahhhh

If you still can track them, you should date all your images. Not for the gaps
in my memory, but just to see the time line.

Cheers!

ingo

[Maetes] Re: Popularization of the POV-Ray program on Tik...

Mon, 3 Aug 2026 16:15:00 GMT

If you need free music, try this one.

https://freetouse.com/music

You have to try some tracks to find a good one, but some of them are really
good.
Have used one of them for my spacecraft-movie.
Somewhere you should mention the author and the website (in a description to the
clip), but I think thats no problem.

Ma

[Maetes] Re: Hello gang - getting back to it.

Mon, 3 Aug 2026 16:05:00 GMT

Hi Mike, welcome back.

I'm one of the new ones, only active since 2016.

Nice website, crazy good pictures.

I took a look a few days ago, there was a download section, from your workbench.
Quite a lot of things in it, great that you published it (at least briefly).

It's written for 3.8, but maybe I can still learn a bit for 3.7 (debian
repository-install).

Greetings from Cologne/Germany.

[yesbird] Re: Hello gang - getting back to it.

Sun, 2 Aug 2026 09:47:40 GMT

On 01/08/2026 21:29, Mike Miller wrote:
> Hi guys,
> attached are 2 preliminary renderings of my pumphouse model. I've tweaked the
> design a bit and assigned some 'place-holder' materials before going too far.
> Next will be the upper bridge, stairs & railer, and lamps. ...have a great
> weekend,
> Mike
> 

Looks nice and accurate, materials also "in place",
looking forward to "to be continued" ).
-- 
YB

[Mike Miller] Re: Hello gang - getting back to it.

Sat, 1 Aug 2026 18:30:00 GMT

yesbird wrote:
> On 30/07/2026 01:04, Mike Miller wrote:
> > I attached my current working file. It has the gold metal texture. I'll probably
> > be creating a very 'distressed material' for this model in the end. I'll tackle
> > texturing once I have everything built.
>
> Thanks so much for this 'gold', I will put it into my materials
> collection.
> --
> YB

Hi guys,
attached are 2 preliminary renderings of my pumphouse model. I've tweaked the
design a bit and assigned some 'place-holder' materials before going too far.
Next will be the upper bridge, stairs & railer, and lamps. ...have a great
weekend,
Mike

[yesbird] Re: Hello gang - getting back to it.

Wed, 29 Jul 2026 22:24:00 GMT

On 30/07/2026 01:04, Mike Miller wrote:
> I attached my current working file. It has the gold metal texture. I'll probably
> be creating a very 'distressed material' for this model in the end. I'll tackle
> texturing once I have everything built.

Thanks so much for this 'gold', I will put it into my materials
collection.
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 29 Jul 2026 22:05:01 GMT

yesbird wrote:
> On 29/07/2026 21:34, Mike Miller wrote:
> > Very cool stuff YB. I checked out povlab.yesbird.online stuff. Well done on the
> > materials and viewer. That's all Java? I don't know a thing about WASM... just
> > checked it out.... I'd love to see your progress on that.
> >
>
> Thanks, Mike.
> This is my first attempt to make a POV closer to the modern
> world ). BTW, I've embedded your materials browser here, as I found it
> very useful:
> https://povlab.yesbird.online/?scene=materials/samples_default.pov
>
> WASM compiling can be painful and need a lot of effort to get a stable
> result. This is the reason I postponed it to the autumn, preferring to
> relax in the summer ).
>
> > I'd like to push a few more scenes into animations and dust of some really old
> > work - now that rendering times have really drop compared to 1990's.  :)
>
> Exactly !
>
> >
> > This pump house is going to take me a few weeks to model and another month of
> > landscape work if I had to guess. I'm going to model a lizard as a feature
> > foreground object and use the pump-house structure as a backdrop.
>
> Respect, you have a lot of patience (which I need) to make such a large
> scene. Lizard in industrial environment ? Sounds cool - looking forward
> to see it (sketch at least :)).
>
> >
> > I attached my current POV model / progress of the flywheel and mounts.
> > Most made with lathe or prisms with cubic or linear splines - depending on a
> > bevel or curve look.
>
> I found it very neat, especially "golden wheels" - excellent material,
> which can probably be used in jewelry rendering.
> --
> YB

Thanks. Yes, I need to work out a better sketch.
I attached my current working file. It has the gold metal texture. I'll probably
be creating a very 'distressed material' for this model in the end. I'll tackle
texturing once I have everything built.
Mike.

[yesbird] Re: Hello gang - getting back to it.

Wed, 29 Jul 2026 19:39:07 GMT

On 29/07/2026 21:34, Mike Miller wrote:
> Very cool stuff YB. I checked out povlab.yesbird.online stuff. Well done on the
> materials and viewer. That's all Java? I don't know a thing about WASM... just
> checked it out.... I'd love to see your progress on that.
> 

Thanks, Mike.
This is my first attempt to make a POV closer to the modern
world ). BTW, I've embedded your materials browser here, as I found it
very useful:
https://povlab.yesbird.online/?scene=materials/samples_default.pov

WASM compiling can be painful and need a lot of effort to get a stable
result. This is the reason I postponed it to the autumn, preferring to
relax in the summer ).

> I'd like to push a few more scenes into animations and dust of some really old
> work - now that rendering times have really drop compared to 1990's.  :)

Exactly !

> 
> This pump house is going to take me a few weeks to model and another month of
> landscape work if I had to guess. I'm going to model a lizard as a feature
> foreground object and use the pump-house structure as a backdrop.

Respect, you have a lot of patience (which I need) to make such a large
scene. Lizard in industrial environment ? Sounds cool - looking forward
to see it (sketch at least :)).

> 
> I attached my current POV model / progress of the flywheel and mounts.
> Most made with lathe or prisms with cubic or linear splines - depending on a
> bevel or curve look.

I found it very neat, especially "golden wheels" - excellent material,
which can probably be used in jewelry rendering.
-- 
YB

[Mike Miller] Re: Hello gang - getting back to it.

Wed, 29 Jul 2026 18:35:00 GMT

yesbird wrote:
> On 28/07/2026 00:52, Mike Miller wrote:
> > thanks, YB.
> > How have you been? What fun ideas have you been working on? Sorry, I need to
> > read through the threads.  ...any ways, cheers.
> >
>
> Hi, Mike.
> There are a lot of things I would like to do, and some of them
> POV-related. I moved to browser-based Javascript graphics (Three.js) and
> building the bridge between this technology and POV-Ray, first attempt
> is here: https://povlab.yesbird.online/
>
> Next project is based on POV-ray studio (online converter from popular
> formats to mesh2 https://povlab.yesbird.online/studio/) is a jewelry
> renderer (early beta now):
> https://jray.yesbird.online/
>
> All POV rendering is done on the server now, but I am thinking about
> pushing it into the browser with WASM. This is a serious challenge, so I
> need a time to prepare carefully to start, maybe in September ...
>
> BTW, here is my portfolio:
> https://yesbird.online/
>
> Hope your work on Pump House will be smooth and fast.
> What other plans do you have ?
> --
> YB

Very cool stuff YB. I checked out povlab.yesbird.online stuff. Well done on the
materials and viewer. That's all Java? I don't know a thing about WASM... just
checked it out.... I'd love to see your progress on that.

I'd like to push a few more scenes into animations and dust of some really old
work - now that rendering times have really drop compared to 1990's.  :)

This pump house is going to take me a few weeks to model and another month of
landscape work if I had to guess. I'm going to model a lizard as a feature
foreground object and use the pump-house structure as a backdrop.

I attached my current POV model / progress of the flywheel and mounts.
Most made with lathe or prisms with cubic or linear splines - depending on a
bevel or curve look.

Mike

[yesbird] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 22:28:02 GMT

On 28/07/2026 00:52, Mike Miller wrote:
> thanks, YB.
> How have you been? What fun ideas have you been working on? Sorry, I need to
> read through the threads.  ...any ways, cheers.
> 

Hi, Mike.
There are a lot of things I would like to do, and some of them
POV-related. I moved to browser-based Javascript graphics (Three.js) and
building the bridge between this technology and POV-Ray, first attempt
is here: https://povlab.yesbird.online/

Next project is based on POV-ray studio (online converter from popular
formats to mesh2 https://povlab.yesbird.online/studio/) is a jewelry
renderer (early beta now):
https://jray.yesbird.online/

All POV rendering is done on the server now, but I am thinking about
pushing it into the browser with WASM. This is a serious challenge, so I
need a time to prepare carefully to start, maybe in September ...

BTW, here is my portfolio:
https://yesbird.online/

Hope your work on Pump House will be smooth and fast.
What other plans do you have ?
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 21:55:00 GMT

yesbird wrote:
> On 27/07/2026 15:28, Mike Miller wrote:
> > As I work through the POV scene building, I'll keep posting screen grabs on my
> > web page. I'm currently exporting point position 'profiles' from Blender for POV
> > lathes.
>
> Looking forward to see them, good luck !
> --
> YB

thanks, YB.
How have you been? What fun ideas have you been working on? Sorry, I need to
read through the threads.  ...any ways, cheers.

[Cossack ] Re: Termux !!!

Mon, 27 Jul 2026 13:40:00 GMT

"Cossack " <nomail@nomail> wrote:
> ~/POV_Projects_SD/balcony $ uberpov -version
> uberpov: cannot open the system configuration file
> /usr/local/etc/uberpov/1.37/uberpov.conf: No such file or directory
> UberPOV 1.37.1.0
>
> This is an unofficial version compiled by:
>  Termux User
> Neither the POV-Ray Team(tm) nor the UberPOV maintainers are responsible for
> supporting this version.
>
> Copyright 1991-2015 Persistence of Vision Raytracer Pty. Ltd.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Built-in features:
>   I/O restrictions:          enabled
>   X Window display:          disabled
>   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
>   Unsupported image formats: openexr
>
> Compilation settings:
>   Build architecture:  armv8l-unknown-linux-androideabi
>   Built/Optimized for: armv8l-unknown-linux-androideabi
>   Compiler vendor:     gnu
>   Compiler version:    clang++ 21.1.8
>   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -O3 -ffast-math
> -std=c++17
> ~/POV_Projects_SD/balcony $ povray -version
> POV-Ray 3.8.0-beta.2.unofficial
>
> This is an unofficial version compiled by:
>  Termux
>  The POV-Ray Team is not responsible for supporting this version.
>
> Copyright 1991-2021 Persistence of Vision Raytracer Pty. Ltd.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Built-in features:
>   I/O restrictions:          enabled
>   X Window display:          disabled
>   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
>   Unsupported image formats: -
>
> Compilation settings:
>   Build architecture:  x86_64-pc-linux-gnu
>   Built/Optimized for: arm-unknown-linux-androideabi
>   Compiler vendor:     clang
>   Compiler version:    arm-linux-androideabi-clang++ 21.0.0
>   Compiler flags:      -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mthumb
> -fstack-protector-strong -Oz -std=c++14 -pthread
> ~/POV_Projects_SD/balcony $ uberpov -version
> uberpov: cannot open the system configuration file
> /usr/local/etc/uberpov/1.37/uberpov.conf: No such file or directory
> ....
> ~/POV_Projects_SD/balcony $
>
> The Holy Trinity in one room !!!!

Oops, forgot this one — NOW the trinity is complete >:]] !!!!!"
POV_Projects_SD/balcony $ megapov -version
megapov: cannot open the system configuration file
/usr/local/etc/megapov/1.2.1/povray.conf: No such file or directory
megapov: cannot open the user configuration file
/data/data/com.termux/files/home/.megapov/1.2.1/povray.conf: No such file or
directory
megapov: I/O restrictions are disabled.
Persistence of Vision(tm) Ray Tracer Version MegaPOV 1.2.1/ based on Pov-RAY
 3.6.1 (clang++ @ armv8l-unknown-linux-gnu)
This is an unofficial version compiled by:
 Termux User
 The POV-Ray Team(tm) is not responsible for supporting this version.
POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins
Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2004 Persistence of Vision Raytracer Pty. Ltd.

Primary POV-Ray 3.5/3.6 Developers: (Alphabetically)
  Chris Cason         Thorsten Froehlich  Nathan Kopp         Ron Parker

Contributing Authors: (Alphabetically)
  Steve Anger         Eric Barish         Dieter Bayer        Steve A. Bennett
  David K. Buck       Nicolas Calimet     Aaron A. Collins    Chris Dailey
  Steve Demlow        Andreas Dilger      Alexander Enzmann   Dan Farmer
  Mark Gordon         Christoph Hormann   Mike Hough          Chris Huff
  Kari Kivisalo       Lutz Kretzschmar    Jochen Lippert      Pascal Massimino
  Jim McElhiney       Douglas Muir        Juha Nieminen       Bill Pulver
  Eduard Schwan       Wlodzimierz Skiba   Robert Skinner      Yvo Smellenbergh
  Zsolt Szalavari     Scott Taylor        Massimo Valentini   Timothy Wegner
  Drew Wells          Chris Young

MegaPOV Contributing Authors: (Alphabetically)
  Christophe Bouffartigue  Thorsten Froehlich       Christoph Hormann
  Chris Huff               Jurjen                   Kari Kivisalo
  Nathan Kopp              Vahur Krouverk           William Pokorny
  Micha Riser              Wlodzimierz Skiba        Rene Smellenbergh
  Yvo Smellenbergh         Massimo Valentini        Thomas Willhalm

Other contributors are listed in the documentation.

Support libraries used by POV-Ray:
  ZLib 1.3.2, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
  LibPNG 1.6.58, Copyright 1998-2002 Glenn Randers-Pehrson
  LibJPEG 8, Copyright 1998 Thomas G. Lane
  LibTIFF 4.7.2, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Redirecting Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
  Warning Stream to console.......On
Parsing Options
  Input file: OBJECT.POV (compatible to version 3.61)
  Remove bounds........On
  Split unions.........Off
  Library paths:
    /data/data/com.termux/files/home/povray-3.6.1/include
Output Options
  Image resolution 100 by 100 (rows 1 to 100, columns 1 to 100).
  Output file: /storage/0000-0000/POV_Projects/balcony/OBJECT.png, 24 bpp PNG
  Graphic display......Off
  Mosaic preview.......Off
  CPU usage histogram..Off
  Continued trace......Off
Tracing Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 25
  Light Buffer.........On
  Vista Buffer.........On   Draw Vista Buffer....Off
  Antialiasing.........Off
  Clock value:    0.000  (Animation off)

  0:00:00 Parsing
Possible Scene File Parser Initialization Error: Could not find file
 'OBJECT.POV'
Scene File Parser Initialization Error: Cannot open input file.
Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  0 seconds (0 seconds)
  Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
  Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
  Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Render Time:   0 hours  0 minutes  0 seconds (0 seconds)
  Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Total Time:    0 hours  0 minutes  0 seconds (0 seconds)
~/POV_Projects_SD/balcony $

[Cossack ] Termux !!!

Mon, 27 Jul 2026 12:40:00 GMT

~/POV_Projects_SD/balcony $ uberpov -version
uberpov: cannot open the system configuration file
/usr/local/etc/uberpov/1.37/uberpov.conf: No such file or directory
UberPOV 1.37.1.0

This is an unofficial version compiled by:
 Termux User
Neither the POV-Ray Team(tm) nor the UberPOV maintainers are responsible for
supporting this version.

Copyright 1991-2015 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          disabled
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
  Unsupported image formats: openexr

Compilation settings:
  Build architecture:  armv8l-unknown-linux-androideabi
  Built/Optimized for: armv8l-unknown-linux-androideabi
  Compiler vendor:     gnu
  Compiler version:    clang++ 21.1.8
  Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -O3 -ffast-math
-std=c++17
~/POV_Projects_SD/balcony $ povray -version
POV-Ray 3.8.0-beta.2.unofficial

This is an unofficial version compiled by:
 Termux
 The POV-Ray Team is not responsible for supporting this version.

Copyright 1991-2021 Persistence of Vision Raytracer Pty. Ltd.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          disabled
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
  Unsupported image formats: -

Compilation settings:
  Build architecture:  x86_64-pc-linux-gnu
  Built/Optimized for: arm-unknown-linux-androideabi
  Compiler vendor:     clang
  Compiler version:    arm-linux-androideabi-clang++ 21.0.0
  Compiler flags:      -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mthumb
-fstack-protector-strong -Oz -std=c++14 -pthread
~/POV_Projects_SD/balcony $ uberpov -version
uberpov: cannot open the system configuration file
/usr/local/etc/uberpov/1.37/uberpov.conf: No such file or directory
....
~/POV_Projects_SD/balcony $

The Holy Trinity in one room !!!!

[yesbird] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 12:36:08 GMT

On 27/07/2026 15:28, Mike Miller wrote:
> As I work through the POV scene building, I'll keep posting screen grabs on my
> web page. I'm currently exporting point position 'profiles' from Blender for POV
> lathes.

Looking forward to see them, good luck !
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 12:30:00 GMT

yesbird wrote:
> On 27/07/2026 14:14, Mike Miller wrote:
> > It is. If you can get the model to behave and render correctly out of these Bim
> > products. Coincidental faces or shading problem showed their ugly head in
> > animation.
> > oopps...
> > I thought I attached this.
>
>  From PDF I see that the scene is large, maybe it makes sense to get
> something less for the start ?
>
> To prepare scene for online and  test how it will work this editor can
> help a lot: https://threejs.org/editor/
> --
> YB

Thanks. That Petmin project was from 2000-2001. I heard they filed for
bankruptcy. I wonder if GPD got paid. I did. :) ...perks of not being the owner.
haha

As I work through the POV scene building, I'll keep posting screen grabs on my
web page. I'm currently exporting point position 'profiles' from Blender for POV
lathes.
Mike

[yesbird] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 11:33:13 GMT

On 27/07/2026 14:14, Mike Miller wrote:
> It is. If you can get the model to behave and render correctly out of these Bim
> products. Coincidental faces or shading problem showed their ugly head in
> animation.
> oopps...
> I thought I attached this.

 From PDF I see that the scene is large, maybe it makes sense to get
something less for the start ?

To prepare scene for online and  test how it will work this editor can
help a lot: https://threejs.org/editor/
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 11:15:00 GMT

yesbird wrote:
> On 27/07/2026 04:35, Mike Miller wrote:
> > Thanks, YB. Yeah, I've work on many projects that included modeling major
> > piping, pumps, and conduit. I like the look of the technical complexity, even
> > though I have little idea how it works. :) Attached is a project that I worked
> > on for months for Pitman Pigiron. I need to find my interior renderings of the
> > facility. Thes model is more complex than the exterior. Built in Naviworks
> > before importing to Revit & Max for site work. Day & night animations in Lumion
> > Mike
>
> I see you have a rich background and a large archive of interesting
> geometry. What about publishing them online in 3D with my following
> tools:
>
> https://povlab.yesbird.online/studio/
> https://galleries.yesbird.online/vr/
>
> Guess it will be interesting to walk through pumps and pipes in VR ).
> --
> YB

It is. If you can get the model to behave and render correctly out of these Bim
products. Coincidental faces or shading problem showed their ugly head in
animation.
oopps...
I thought I attached this.

[yesbird] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 10:47:54 GMT

On 27/07/2026 04:35, Mike Miller wrote:
> Thanks, YB. Yeah, I've work on many projects that included modeling major
> piping, pumps, and conduit. I like the look of the technical complexity, even
> though I have little idea how it works. :) Attached is a project that I worked
> on for months for Pitman Pigiron. I need to find my interior renderings of the
> facility. Thes model is more complex than the exterior. Built in Naviworks
> before importing to Revit & Max for site work. Day & night animations in Lumion
> Mike

I see you have a rich background and a large archive of interesting
geometry. What about publishing them online in 3D with my following
tools:

https://povlab.yesbird.online/studio/
https://galleries.yesbird.online/vr/

Guess it will be interesting to walk through pumps and pipes in VR ).
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Mon, 27 Jul 2026 01:40:00 GMT

yesbird wrote:
> On 26/07/2026 18:57, Mike Miller wrote:
> >
> > I've added some progress images to my Pump House page and a bullet list of
> > processes. I was able to get a temp license for Revit and extracted the CAD and
> > 3D models I wanted before starting the POV model. I'll start on the main
> > flywheel and mounts first and post progress as I go.
> > miller
>
> Hi, Mike!
> Glad to see (read) you here again after a long break. Your new site
> looks neat and elegant. Pump House is also exiting (I like industrial
> environment), especially rendered with Lumion which make it even more
> impressive.
>
> Looking forward for POV version - good luck with this work !
> --
> YB

Thanks, YB. Yeah, I've work on many projects that included modeling major
piping, pumps, and conduit. I like the look of the technical complexity, even
though I have little idea how it works. :) Attached is a project that I worked
on for months for Pitman Pigiron. I need to find my interior renderings of the
facility. Thes model is more complex than the exterior. Built in Naviworks
before importing to Revit & Max for site work. Day & night animations in Lumion
Mike

[yesbird] Re: Hello gang - getting back to it.

Sun, 26 Jul 2026 19:25:25 GMT

On 26/07/2026 18:57, Mike Miller wrote:
> 
> I've added some progress images to my Pump House page and a bullet list of
> processes. I was able to get a temp license for Revit and extracted the CAD and
> 3D models I wanted before starting the POV model. I'll start on the main
> flywheel and mounts first and post progress as I go.
> miller

Hi, Mike!
Glad to see (read) you here again after a long break. Your new site
looks neat and elegant. Pump House is also exiting (I like industrial
environment), especially rendered with Lumion which make it even more
impressive.

Looking forward for POV version - good luck with this work !
--
YB

[Mike Miller] Re: Hello gang - getting back to it.

Sun, 26 Jul 2026 16:00:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Mike Miller" <mil### [at] gmailcom> wrote:
> >
> > > Thanks BE.
> > Thank _you_, Mike.
> > It's been great see all of the sketches, development, WIPs, and renders.
> >
> > > I'll set up a page on my website for this current project 'pump house' and post
> > > here with any news or updates. I found my original concept sketches and the
> > > Collada/Lumion files. I'll take some screen grabs of this model and post along
> > > with my sketches and images I gathered for reference & inspiration. I always
> > > pull images and sketch* what I can before I get too far into modeling. I built
> > > the first model in Revit and exported it to Unity and Lumion for animations and
> > > visuals.
> >
> > Yes.  I think that "storyboarding" or flowcharting how you go from initial idea
> > to final render would do much to dispel the "magic" of how such final renders
> > come into being.
> >
> > You don't just open up a text editor and start typing out SDL.
> > (Well, _I_ do a lot of times . . .)
> > Showing all of the sketches and modelers and conversion utilities, and 3rd party
> > software that gets used in preparation for a final POV-Ray render, and then
> > maybe even post-render processing would be a master class in what you do so
> > well.
> >
> > > .... I'm also thinking
> > > about camera path animations and how to break a scene down into manageable
> > > parts.
> >
> > Yeah - that's always another layer of challenges which have their own solutions.
> >
> > - BE
>
> Thanks, BE
> I just posted some concept sketches for this POV piece along with images of my
> past models to my web. I'll do have a 'plan of attack' to make this happen in
> POV and will put a bullet-list together.
> miller

I've added some progress images to my Pump House page and a bullet list of
processes. I was able to get a temp license for Revit and extracted the CAD and
3D models I wanted before starting the POV model. I'll start on the main
flywheel and mounts first and post progress as I go.
miller

[jr] Re: Returning to POV-Ray

Sat, 25 Jul 2026 15:15:00 GMT

hi,

"Macca" <almac45@gmail,com> wrote:
> ...
> Hi JC. I'm going back to around 2012.
> But someone else has replied telling me where is it.
> I had been looking for it in the menu.

great, and thanks.


@KlP cheers.


regards, jr.

[Mike Miller] Re: Hello gang - getting back to it.

Fri, 24 Jul 2026 23:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > Thanks BE.
> Thank _you_, Mike.
> It's been great see all of the sketches, development, WIPs, and renders.
>
> > I'll set up a page on my website for this current project 'pump house' and post
> > here with any news or updates. I found my original concept sketches and the
> > Collada/Lumion files. I'll take some screen grabs of this model and post along
> > with my sketches and images I gathered for reference & inspiration. I always
> > pull images and sketch* what I can before I get too far into modeling. I built
> > the first model in Revit and exported it to Unity and Lumion for animations and
> > visuals.
>
> Yes.  I think that "storyboarding" or flowcharting how you go from initial idea
> to final render would do much to dispel the "magic" of how such final renders
> come into being.
>
> You don't just open up a text editor and start typing out SDL.
> (Well, _I_ do a lot of times . . .)
> Showing all of the sketches and modelers and conversion utilities, and 3rd party
> software that gets used in preparation for a final POV-Ray render, and then
> maybe even post-render processing would be a master class in what you do so
> well.
>
> > .... I'm also thinking
> > about camera path animations and how to break a scene down into manageable
> > parts.
>
> Yeah - that's always another layer of challenges which have their own solutions.
>
> - BE

Thanks, BE
I just posted some concept sketches for this POV piece along with images of my
past models to my web. I'll do have a 'plan of attack' to make this happen in
POV and will put a bullet-list together.
miller

[Macca] Re: Returning to POV-Ray

Fri, 24 Jul 2026 21:30:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> On 24/07/2026 16:19, jr wrote:
> > hi,
> >
> > "Macca" <almac45@gmail,com> wrote:
> >> Hello all, I am returning to Pov-Ray after finding a lot of my old Pov-ray files
> >> on a CD.
> >
> > :-)
> >
> >
> >> I've downloaded the newest one to try on my Windows 10 PC.
> >> I have been looking through the web site and a lot of things have changed.
> >> I notice in the "Hall of Fame", all the videos from the monthly competition are
> >> no longer there. I enjoyed watching them and was looking for to seeing them.
> >> Are they still around somewhere?
> >
> > I cannot remember there being links to videos on the hof (but I am a relative
> > "newbie" :-)), from when (approx) is your memory ?
> >
> >
> > regards, jr.
> >
>
>
> Maybe Macca is referring to the IRTC with "Sill image" and "Animation" ?
> The archive is here : <https://www.irtc.org/>
>
>
>
>
> --
> kurtz le pirate
> compagnie de la banquise


Thank you Kurtz le pirate.

I had been searching using the menu options and could not find it.
Thanks for the link.

Cheers, Macca

[Macca] Re: Returning to POV-Ray

Fri, 24 Jul 2026 21:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Macca" <almac45@gmail,com> wrote:
> > Hello all, I am returning to Pov-Ray after finding a lot of my old Pov-ray files
> > on a CD.
>
> :-)
>
>
> > I've downloaded the newest one to try on my Windows 10 PC.
> > I have been looking through the web site and a lot of things have changed.
> > I notice in the "Hall of Fame", all the videos from the monthly competition are
> > no longer there. I enjoyed watching them and was looking for to seeing them.
> > Are they still around somewhere?
>
> I cannot remember there being links to videos on the hof (but I am a relative
> "newbie" :-)), from when (approx) is your memory ?
>
>
> regards, jr.

Hi JC. I'm going back to around 2012.
But someone else has replied telling me where is it.
I had been looking for it in the menu.

Cheers Macca

[Bald Eagle] Re: Hello gang - getting back to it.

Fri, 24 Jul 2026 17:45:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> Thanks BE.
Thank _you_, Mike.
It's been great see all of the sketches, development, WIPs, and renders.

> I'll set up a page on my website for this current project 'pump house' and post
> here with any news or updates. I found my original concept sketches and the
> Collada/Lumion files. I'll take some screen grabs of this model and post along
> with my sketches and images I gathered for reference & inspiration. I always
> pull images and sketch* what I can before I get too far into modeling. I built
> the first model in Revit and exported it to Unity and Lumion for animations and
> visuals.

Yes.  I think that "storyboarding" or flowcharting how you go from initial idea
to final render would do much to dispel the "magic" of how such final renders
come into being.

You don't just open up a text editor and start typing out SDL.
(Well, _I_ do a lot of times . . .)
Showing all of the sketches and modelers and conversion utilities, and 3rd party
software that gets used in preparation for a final POV-Ray render, and then
maybe even post-render processing would be a master class in what you do so
well.

> .... I'm also thinking
> about camera path animations and how to break a scene down into manageable
> parts.

Yeah - that's always another layer of challenges which have their own solutions.

- BE

[kurtz le pirate] Re: Returning to POV-Ray

Fri, 24 Jul 2026 15:38:17 GMT

On 24/07/2026 16:19, jr wrote:
> hi,
> 
> "Macca" <almac45@gmail,com> wrote:
>> Hello all, I am returning to Pov-Ray after finding a lot of my old Pov-ray files
>> on a CD.
> 
> :-)
> 
> 
>> I've downloaded the newest one to try on my Windows 10 PC.
>> I have been looking through the web site and a lot of things have changed.
>> I notice in the "Hall of Fame", all the videos from the monthly competition are
>> no longer there. I enjoyed watching them and was looking for to seeing them.
>> Are they still around somewhere?
> 
> I cannot remember there being links to videos on the hof (but I am a relative
> "newbie" :-)), from when (approx) is your memory ?
> 
> 
> regards, jr.
> 


Maybe Macca is referring to the IRTC with "Sill image" and "Animation" ?
The archive is here : <https://www.irtc.org/>




-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: Returning to POV-Ray

Fri, 24 Jul 2026 14:20:00 GMT

hi,

"Macca" <almac45@gmail,com> wrote:
> Hello all, I am returning to Pov-Ray after finding a lot of my old Pov-ray files
> on a CD.

:-)


> I've downloaded the newest one to try on my Windows 10 PC.
> I have been looking through the web site and a lot of things have changed.
> I notice in the "Hall of Fame", all the videos from the monthly competition are
> no longer there. I enjoyed watching them and was looking for to seeing them.
> Are they still around somewhere?

I cannot remember there being links to videos on the hof (but I am a relative
"newbie" :-)), from when (approx) is your memory ?


regards, jr.

[jr] Re: Hello gang - getting back to it.

Fri, 24 Jul 2026 14:15:00 GMT

hi,

"Mike Miller" <mil### [at] gmailcom> wrote:
> It's been a while ... I hope all is well with everyone.
>
> I took a break from most of my computer/graphic work to 'work the farm', fish
> and relax. Recently thought, I've have had the itch to get back into some POV
> rendering. I just started animating my old 'Nest' scene, which has recently
> become more of a 'test' scene for writing some visualizing tools.
>
> I'm currently working on a few ideas to help speed my POV scene building and
> have started a new web site to post and archive my current work and code. I'm
> working in a 'project tree' directory structure that allows me to jump around to
> various render-able asset libraries (materials, images, color_maps, objects,
> etc.).
> There are also a few utilities I've coded to help the process that I've also
> posted.
>
> new site:   www.miller-raytracer.com

nice site, although my "old eyes" struggled with the contrast, in places.
thanks.


regards, jr.

[jr] Re: pls make a app...

Fri, 24 Jul 2026 14:10:00 GMT

hi,

"" wrote:
> yeah... i know... idk if my laptop having a bug or something. i just tried it
> again but when i move object, it doesn't move. idk if i can solve this (im a
> begineer)

the screenshot showed nothing "going wrong", only warnings.  as mentioned
before, a cut-down version of your scene, or a different, simple scene
illustrating the problem, is needed.

regards, jr.

[Mike Miller] Re: Hello gang - getting back to it.

Fri, 24 Jul 2026 13:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > BE, did you mean post stuff in this .general thread, or somewhere else?
>
> You could do it here, where I think having your skill, creativity, experience,
> and expertise archived would be a fantastic resource for people who really want
> to learn how to achieve more professional looking results in their renders.
>
> Or you could maintain a sort of blog on your site.
>
> Or cross-post everything so that it's in both places.   Because - digital things
> disappear sometimes.
>
> - BE

Thanks BE.
I'll set up a page on my website for this current project 'pump house' and post
here with any news or updates. I found my original concept sketches and the
Collada/Lumion files. I'll take some screen grabs of this model and post along
with my sketches and images I gathered for reference & inspiration. I always
pull images and sketch* what I can before I get too far into modeling. I built
the first model in Revit and exported it to Unity and Lumion for animations and
visuals.

* I usually have a 'final' image or 2 in mind that I'll rough out in pencil, but
my drawing skills are diminishing with age - so more like doodles. :) Now that I
have a few CPU's that can render frames at a decent rate, I'm also thinking
about camera path animations and how to break a scene down into manageable
parts.

Mike

[Macca] Returning to POV-Ray

Fri, 24 Jul 2026 05:50:00 GMT

Hello all, I am returning to Pov-Ray after finding a lot of my old Pov-ray files
on a CD.
I've downloaded the newest one to try on my Windows 10 PC.
I have been looking through the web site and a lot of things have changed.
I notice in the "Hall of Fame", all the videos from the monthly competition are
no longer there. I enjoyed watching them and was looking for to seeing them.
Are they still around somewhere?

[Bald Eagle] Re: Hello gang - getting back to it.

Fri, 24 Jul 2026 02:25:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> BE, did you mean post stuff in this .general thread, or somewhere else?

You could do it here, where I think having your skill, creativity, experience,
and expertise archived would be a fantastic resource for people who really want
to learn how to achieve more professional looking results in their renders.

Or you could maintain a sort of blog on your site.

Or cross-post everything so that it's in both places.   Because - digital things
disappear sometimes.

- BE

[Mike Miller] Re: POV-Ray Origins

Thu, 23 Jul 2026 14:35:00 GMT

David Buck <dav### [at] simberoncom> wrote:
> 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

Thank you, David, for DKBTrace, POV and your support that follows. It sure
changed my 3D career path in the early 90's. It allowed me to produce art in a
new and fantastic way. I used POV early on to produce renders for Columbus
architects, which eventually lead to becoming a design architect and using 3D
extensively for presenting concepts to my clients. POV remains dear to my heart.

Congrats on turning 64 and retirement! I'll be turning 68 myself - time does
fly. I'm just get back to some new POV work and will try to post more often.
God Bless,
Mike.

[Mike Miller] Re: Hello gang - getting back to it.

Thu, 23 Jul 2026 13:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Mike Miller" <mil### [at] gmailcom> wrote:
>
> > I'm currently working on a few ideas to help speed my POV scene building and
> > have started a new web site to post and archive my current work and code. I'm
> > working in a 'project tree' directory structure that allows me to jump around to
> > various render-able asset libraries (materials, images, color_maps, objects,
> > etc.).
> > There are also a few utilities I've coded to help the process that I've also
> > posted.
>
> Hi Mike, and welcome back!
>
> I like the new site, and the visuals are stunning as usual.  :)
>
> I'm sure that you have a vast amount of knowledge about what makes things "look
> good" - from the fundamental geometric aspects of structure and "smoothness", to
> scene composition, lighting, and of course textures, normals, and finishes.
>
> It would be really nice, and educational, if you could just post things here and
> there about what was going through your head at the outset, and the key things
> that you ensured were present to get the desired effects in the render.
>
> "I _could_ have done it this way, but that would take too long, so I ...."
> "I wanted to make this look [wet][powdery][translucent][hard & shiny][soft &
> leathery] ... and so a texture like that requires at the minimum ...."
> "The tentacle needs to look smooth and flowing, without any kinks, so I used a
> [type] spline ..."
> "Since I'm doing this in POV-Ray, I needed to take the structure of the SDL and
> parsing into account.  [This] needed to be parameterized. [That] needed to
> precede [xyz]. And [Sumthin' else] needed to be stored in a [data structure] to
> really make it efficiently useable."
>
> I think that new users would be fascinated and learn a lot, and even long-time
> experienced users who don't have any graphic arts background would find such
> explanations a goldmine of information and inspiration.
>
> Just something to think about - it doesn't need to be formal.  Every little
> tidbit, trick, rule, strategy, and optimization really helps.
>
> Thanks for all that you have done and continue to do!
> I like the new website, and the images are fantastic as always.
> I'm sure the animations are going to be mesmerizing (and creepy ;) ).
>
> - BE

Thanks BE.
I'll be happy to post my 'thought process' as I work though some new renderings.
I finally put 'pencils down' on my 'Nest project'. I have sketches of this from
30 years ago. haha. I'm rendering a 2000 frame drift animation through the
scene...which is taking some time @8 min per fame.

I've just started a new POV scene based on an old 'world' I designed in
Unity and exported for final renderings in Lumion 9. A software I own but is
'almost' impossible to export data out of. The renderings and animations focused
on an old flywheel driven 'pump-house' buried in ruin and over-grown vegetation.
I'll post some sketches of my idea along with some preliminary rendering I did
years ago. My goal on this will be to rebuild the Lumion scene in POV
without using smooth triangles - I miss CSG modeling and like a good challenge.
I do have my original CAD drawings that I'll use as underlays for building the
architectural structures.

BE, did you mean post stuff in this .general thread, or somewhere else?
Thanks!

miller

[Bald Eagle] Re: Hello gang - getting back to it.

Thu, 23 Jul 2026 10:45:00 GMT

"Mike Miller" <mil### [at] gmailcom> wrote:

> I'm currently working on a few ideas to help speed my POV scene building and
> have started a new web site to post and archive my current work and code. I'm
> working in a 'project tree' directory structure that allows me to jump around to
> various render-able asset libraries (materials, images, color_maps, objects,
> etc.).
> There are also a few utilities I've coded to help the process that I've also
> posted.

Hi Mike, and welcome back!

I like the new site, and the visuals are stunning as usual.  :)

I'm sure that you have a vast amount of knowledge about what makes things "look
good" - from the fundamental geometric aspects of structure and "smoothness", to
scene composition, lighting, and of course textures, normals, and finishes.

It would be really nice, and educational, if you could just post things here and
there about what was going through your head at the outset, and the key things
that you ensured were present to get the desired effects in the render.

"I _could_ have done it this way, but that would take too long, so I ...."
"I wanted to make this look [wet][powdery][translucent][hard & shiny][soft &
leathery] ... and so a texture like that requires at the minimum ...."
"The tentacle needs to look smooth and flowing, without any kinks, so I used a
[type] spline ..."
"Since I'm doing this in POV-Ray, I needed to take the structure of the SDL and
parsing into account.  [This] needed to be parameterized. [That] needed to
precede [xyz]. And [Sumthin' else] needed to be stored in a [data structure] to
really make it efficiently useable."

I think that new users would be fascinated and learn a lot, and even long-time
experienced users who don't have any graphic arts background would find such
explanations a goldmine of information and inspiration.

Just something to think about - it doesn't need to be formal.  Every little
tidbit, trick, rule, strategy, and optimization really helps.

Thanks for all that you have done and continue to do!
I like the new website, and the images are fantastic as always.
I'm sure the animations are going to be mesmerizing (and creepy ;) ).

- BE

[Bald Eagle] Re: pls make a app...

Thu, 23 Jul 2026 10:10:00 GMT

wrote:
> > - "crashes" should, of course, not happen.  you can use, for instance, the
> > 'all_file' option[*] to "record" POV-Ray's text output, including error message.
> >  it would be helpful if you could post additional information on the bug (?),
> yeah... i know... idk if my laptop having a bug or something. i just tried it
> again but when i move object, it doesn't move. idk if i can solve this (im a
> begineer)

#version needs to come first before anything else. (except comments)
It's also useful to define your scene gamma.

#version 3.8;
global_settings {assumed_gamma 1.0}

But in the absence of any code, that's all I got.

- BE

[] Re: pls make a app...

Thu, 23 Jul 2026 06:05:00 GMT

> - "crashes" should, of course, not happen.  you can use, for instance, the
> 'all_file' option[*] to "record" POV-Ray's text output, including error message.
>  it would be helpful if you could post additional information on the bug (?),
yeah... i know... idk if my laptop having a bug or something. i just tried it
again but when i move object, it doesn't move. idk if i can solve this (im a
begineer)

[Mike Miller] Re: Popularization of the POV-Ray program on Tik...

Wed, 22 Jul 2026 23:55:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "Cossack " <nomail@nomail> wrote:
> > The idea is simple: create content like memes, tutorials, videos, etc. Here's an
> > example:
>
> The first problem is adapting it to tiktok format: audio track needs to be
>
> EITHER:
> paired your renders with trending synthwave, chillwave, or retro-electronic
> music to match the aesthetic.
>
> OR:
> original to avoid being censored. So what should a POV soundtrack be like? I
> think sound samples from an on-topic talking podcast or tutorial, one that the
> author would allow us to use could make a good backdrop... (e.g. SMCA: Stephen
> Mc Avoy, with your awesome scottish accent, would you allow such derivative use
> of your works?)
>
> Then there is the content:
>
> *WIP Videos: Users love seeing how things are made. So a time-lapse of a POV-Ray
> scene compiling, or a "code vs. render" split screen, may perform very well.
>
> *Satisfying Loops: POV-Ray is great for creating perfect, mathematically precise
>
> watch.
>
> * generally, using the below tags could federate and ease the virality:
>
> #POVRay
> #RetroCGI
> #3DRender
> #OldSchoolCGI
> #FractalArt
> #GenerativeArt
>
> * Join Broader Communities: Post your work in the
> #3DArtists
> #DigitalArt
>
> * Is there any challenge worth contributing to? These might be a fit:
>
> #RetroCGIChallenge
> #LowPolyArt
> #FractalFriday
>
> * When using Nostalgia & "Retro-Future" Aesthetic:
> #Y2K
> #AnalogHorror"
> #RetroCGI

"POV-Ray is great for creating perfect, mathematically precise"
Yes... you had me at Nostalgia :)
At times ....at least for me, POV is the only thing in this world that makes
sense.

[Mike Miller] Hello gang - getting back to it.

Wed, 22 Jul 2026 21:45:00 GMT

It's been a while ... I hope all is well with everyone.

I took a break from most of my computer/graphic work to 'work the farm', fish
and relax. Recently thought, I've have had the itch to get back into some POV
rendering. I just started animating my old 'Nest' scene, which has recently
become more of a 'test' scene for writing some visualizing tools.

I'm currently working on a few ideas to help speed my POV scene building and
have started a new web site to post and archive my current work and code. I'm
working in a 'project tree' directory structure that allows me to jump around to
various render-able asset libraries (materials, images, color_maps, objects,
etc.).
There are also a few utilities I've coded to help the process that I've also
posted.

new site:   www.miller-raytracer.com
new email   mil### [at] gmailcom

I have an old site, that I don't update, that has some very early sketches and
POV stuff.
old site:  www.miller-headspin.com

I'm hoping to be check in more often. God bless
Mike Miller

[Bald Eagle] Re: Antikythera mechanism

Mon, 20 Jul 2026 11:35:00 GMT

yesbird wrote:
> Greetings !
> Interesting device for modelling, don't you think so ?

I absolutely think so.  :)

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

I have watched all of the documentaries, and every ClickSpring video.

The pin-and-slot assembly is certainly one of the most interesting and
challenging features.

- BW

[yesbird] Antikythera mechanism

Mon, 20 Jul 2026 06:25:23 GMT

Greetings !
Interesting device for modelling, don't you think so ?

https://www.euronews.com/culture/2026/07/20/antikythera-mechanism-greek-computer-that-predicted-eclipses-2000-years-ago
-- 
YB

[ingo] looking for a Ron Parker macro or scene

Sun, 19 Jul 2026 19:02:49 GMT

I've been trying to dig up an old macro/scene by Ron Parker. It's not on 
the server anymore, it's not in 
https://usenetarchives.com/groups.php?c=povray

It is a macro/scene for creating a arabeske/arabic like tiling 
pattern.The beauty was that it did work in 3D, not just on a 2D plane. 
By adding a slight rotation to it the pattern kept changeing, while 
still being similar.

Does it ring a bell? Anyone?

Sadly I lost my complete newsgroup archive.

Cheers,

Ingo

[kurtz le pirate] Re: Damn, I can't add an object!

Sat, 18 Jul 2026 09:34:58 GMT

On 18/07/2026 08:45, Cossack wrote:
> I compiled a project on termux x11 but it won't add the object >:[ .
> Anyone know how to fix this?

I'm no expert, but this makes me think there might be one or more 
missing libraries such as SDL, X11-Dev ?


-- 
kurtz le pirate
compagnie de la banquise

[Cossack ] Damn, I can't add an object!

Sat, 18 Jul 2026 06:50:00 GMT

I compiled a project on termux x11 but it won't add the object >:[ .
Anyone know how to fix this?

[ingo] Re: Include path

Wed, 15 Jul 2026 10:56:11 GMT

On 2026-07-14 13:37, Maetes wrote:
> Is there a way 
povosc needs waveheader
test is a subdir of current dir

#include "povosc.inc"
#include "test/waveheader.inc"

this works

#include "povosc.inc"
#include "./test/waveheader.inc"

this also

POV-Ray 3.8 on Win11

ingo

[Bald Eagle] Re: Include path

Wed, 15 Jul 2026 10:35:00 GMT

You can get the file name of the current scene file, but I don't think the whole
path.

[Maetes] Re: Include path

Wed, 15 Jul 2026 10:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> how about, for every scene file, you add a corresponding .ini file ?  there, not
> only can you provide explicit paths (via 'library_path'), but also "fix" other
> stuff you'd usually provide on the command-line, like antialias etc.  "added
> bonus" is being able to simply write:
>   $ povray myscene.ini
> and done ;-).

Is that easier than defining a path?
I don't think so.
It would just shift the problem to an (additional) ini file.

Alain Martel <kua### [at] videotronca> wrote:
> When POV-Ray looks for include files, it start in the same folder as the
> current scene file, then, it search in the include folder.
> When searching for an include from inside another include file, it
> search in the folder where the first include is located.

The last sentence is my problem. What I would need would be something like a
Povray variable that says where the currently included script is. Then I could
use it to load more scripts of this "sub-include".

But maybe I'm not describing my problem well enough.
I'll do it with manual path information first, maybe then I'll get a hint on how
to do it more elegantly.

Thank you for the tips.

ma

[Alain Martel] Re: Include path

Tue, 14 Jul 2026 20:56:07 GMT

Le 2026-07-14 Ã  07:37, Maetes a Ã©critÂ :
> Is there a way to find out in an included script where it is relative to the
> executed script?
> 
> Problem: I include a script that needs to include more scripts, textures in
> separate files, or images. Unfortunately, it is the case that the path of the
> executed script applies in the included script.
> 
> #include "textures.inc"
> 
> therefore does not lead to success there.
> 
> At the moment I do this by setting a path before the first include.
> 
> #declare Coupe_Path = ".. /base/cars/coupe/";
> 
> I then use this path with Concat, and thus include further scripts and images.
> 
> Is there a better method?
> 
> I think there is the possibility to give general include_path, but I don't want
> to use it. That would be too many and the folder structure changes often.
> 
> Ma
> 
> 
> 

When POV-Ray looks for include files, it start in the same folder as the 
current scene file, then, it search in the include folder.
When searching for an include from inside another include file, it 
search in the folder where the first include is located.

So, create a folder for your scene.
Place any custom include in that same folder.
Avoid placing your custom includes in the includes folder.
Benefits : Your project is easier to manage. If you want to publish your 
scene, you can simply zip the whole folder and get all of the required 
files.

[jr] Re: Include path

Tue, 14 Jul 2026 17:50:00 GMT

hi,

"Maetes" <nomail@nomail> wrote:
> ingo <ing### [at] nomailcom> wrote:
> > dir/myIncludeChaos holds the actual files. dir/myWorkingStructure is
> > what you see. In your editor you go to /house and open the link
> > include1.ini. Your editor actually opens the include1.pov from the chaos
> > directory.
> That's too complicated for me.
>
> I also want to publish the scripts. Then everyone who wants to use them would
> have to deal with sym-links.

how about, for every scene file, you add a corresponding .ini file ?  there, not
only can you provide explicit paths (via 'library_path'), but also "fix" other
stuff you'd usually provide on the command-line, like antialias etc.  "added
bonus" is being able to simply write:
  $ povray myscene.ini
and done ;-).

regards, jr.

[Maetes] Re: Include path

Tue, 14 Jul 2026 13:50:00 GMT

ingo <ing### [at] nomailcom> wrote:
> dir/myIncludeChaos holds the actual files. dir/myWorkingStructure is
> what you see. In your editor you go to /house and open the link
> include1.ini. Your editor actually opens the include1.pov from the chaos
> directory.
>

That's too complicated for me.

I also want to publish the scripts. Then everyone who wants to use them would
have to deal with sym-links.

Your solution may be elegant, but I don't like it.
It would be easier to set a path, I think.

m

[ingo] Re: Include path

Tue, 14 Jul 2026 13:27:41 GMT

On 2026-07-14 14:16, Maetes wrote:

Lets try and visualize:

dir/myIncludeChaos
   object1.pov
   object2.pov
   object3.pov
   include1.inc
   include2.inc


dir/myWorkingStructure
   subdir/car
     link to object1.pov
     link to include2.ini

   subdir/house
     link to include1.ini

     subsubdir/furniture
       link to object2.pov
       link to object2.pov
       link to include2.ini

dir/myIncludeChaos holds the actual files. dir/myWorkingStructure is 
what you see. In your editor you go to /house and open the link 
include1.ini. Your editor actually opens the include1.pov from the chaos 
directory.


https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/


ingo

> Unless I didn't understand your explanation correctly, my English is not the
> best (I use translation tool)
> 
> m
> 
>

[Maetes] Re: Include path

Tue, 14 Jul 2026 12:20:00 GMT

"ingo" <nomail@nomail> wrote:

> For working with the files, a single directory that holds them all and a
> directory structure with soft/sim links from where you edit the files.
>
> When including in POV-Ray you point to the single dir that holds them all. And
> answering your other question, include one top_level file that includes the
> rest. That then works as there is only one directory with the actual files.
>
> Would that work for you?


I don't think so.

I tinker with small worlds with countless objects. All of which are under
construction, so most of them are housed in their own folders.

If I put them all together in one folder, it becomes a huge chaos.

Unless I didn't understand your explanation correctly, my English is not the
best (I use translation tool)

m

[ingo] Re: Include path

Tue, 14 Jul 2026 12:10:00 GMT

"Maetes" <nomail@nomail> wrote:
>
> Is there a better method?
>
> I think there is the possibility to give general include_path, but I don't want
> to use it. That would be too many and the folder structure changes often.
>

For working with the files, a single directory that holds them all and a
directory structure with soft/sim links from where you edit the files.

When including in POV-Ray you point to the single dir that holds them all. And
answering your other question, include one top_level file that includes the
rest. That then works as there is only one directory with the actual files.

Would that work for you?

ingo

[Maetes] Re: auto-include?

Tue, 14 Jul 2026 12:10:00 GMT

Thanks for the hints, jr, didn't know this options.

but thats to complicated.
The more includes, the more complicated.

ma

[jr] Re: auto-include?

Tue, 14 Jul 2026 12:00:00 GMT

hi,

addressing both posts.

"Maetes" <nomail@nomail> wrote:

> Is there a way to find out in an included script where it is relative to the
> executed script?
> ...
> At the moment I do this by setting a path before the first include.
> #declare Coupe_Path = ".. /base/cars/coupe/";
> I then use this path with Concat, and thus include further scripts and images.
> Is there a better method?

not really I think, but you could (perhaps) supply one or more paths via a CLI
declare, ie:
  $ povray ... declare=library_path=/some/path/

you'll need to "fuss" with quoting the construct for most shells, easier to use
an ini file, imo.

> Imagine I had a model that is split into several files for a better overview.
> ...
> If there should be an auto-include, the car_base.inc would have to be given a
> path where it can find the rest of the files - relative to the script executed.

there sort-of is, see 'include_header',
<https://wiki.povray.org/content/Reference:Scene_Parsing_Options#Include_File_Name>.

regards, jr.

[Maetes] auto-include?

Tue, 14 Jul 2026 11:45:00 GMT

Imagine I had a model that is split into several files for a better overview.

car_base.inc
car_textures.inc
car_tyres.inc
.....

Would you include them all individually in your executing script?
Or would you expect all includes to be done automatically in e.g. car_base.inc?

I have quite a few models here that I would like to publish, but I'm not sure
about the handling.

If there should be an auto-include, the car_base.inc would have to be given a
path where it can find the rest of the files - relative to the script executed.

ma

[Maetes] Include path

Tue, 14 Jul 2026 11:40:00 GMT

Is there a way to find out in an included script where it is relative to the
executed script?

Problem: I include a script that needs to include more scripts, textures in
separate files, or images. Unfortunately, it is the case that the path of the
executed script applies in the included script.

#include "textures.inc"

therefore does not lead to success there.

At the moment I do this by setting a path before the first include.

#declare Coupe_Path = ".. /base/cars/coupe/";

I then use this path with Concat, and thus include further scripts and images.

Is there a better method?

I think there is the possibility to give general include_path, but I don't want
to use it. That would be too many and the folder structure changes often.

Ma

[Cossack ] Re: pls make a app...

Tue, 14 Jul 2026 05:25:00 GMT

wrote:
> hello POV-ray users... im trying to make the best POV-ray scene ever but it
> looks like trash... soo... can somebody pls make a app for pc (windows) that
> show how to make povray scene much better? and also can somebody create an
> software that works like blender (a 3D software that can create scenes with
> preview and no coding) that shows the preview every 100 milisecond on 320x240
> but they after render the scene (not the full scene) pls?

So there are various POVRay modelers and POSRay that could help with this, and
Blender also supports POV Ray, so probably all the issues are resolved?

[Bald Eagle] Re: pls make a app...

Tue, 14 Jul 2026 00:30:00 GMT

Dude.  Just answer the guy's question.























;)  :P

[jr] Re: pls make a app...

Mon, 13 Jul 2026 14:25:00 GMT

hi,

"" wrote:
> > perhaps the real time render option ('+rtr') will help ?
> well i tried but sometimes it just crashes my app

</sigh>..  try (please) to put yourself in my / the reader's "shoes".  you wrote
you have a scene you'd like to improve, and that (on a Windows box, I assume ?)
the RTR "sometimes" crashes the app.  you will have to admit that "vague" is an
understatement ;-).

if you want to go without "handle", no problem, but zero information ?!

if you are interested in working on your scene to make it better I suggest:

- give us a (cut-down) version of the scene code and a sentence or two
explaining what you're aiming for, and what problem(s) you see.

- "crashes" should, of course, not happen.  you can use, for instance, the
'all_file' option[*] to "record" POV-Ray's text output, including error message.
 it would be helpful if you could post additional information on the bug (?),
tia.

[*]
<wiki.povray.org/content/Reference:Text_Output_Options#Directing_Text_Streams_to_Files>

regards, jr.

[] Re: pls make a app...

Mon, 13 Jul 2026 10:40:00 GMT

> perhaps the real time render option ('+rtr') will help ?
>
>
> regards, jr.

well i tried but sometimes it just crashes my app

[Alain Martel] Re: pls make a app...

Sat, 11 Jul 2026 14:55:20 GMT

Le 2026-07-10 Ã  16:01,  a Ã©critÂ :
> hello POV-ray users... im trying to make the best POV-ray scene ever but it
> looks like trash... soo... can somebody pls make a app for pc (windows) that
> show how to make povray scene much better? and also can somebody create an
> software that works like blender (a 3D software that can create scenes with
> preview and no coding) that shows the preview every 100 milisecond on 320x240
> but they after render the scene (not the full scene) pls?
> 
> 

A good lighting is essential. Place your main lights in realistic 
places. Use some fill lights. Low intensity lights with the shadowless 
attribute.
Use area_light instead of regular lights. Use the adaptive sampling. 
Start with adaptive 0. This start using the corner of the area_light and 
subdivide it as needed. ONLY use adaptive 1 or adaptive 2 if there are 
artifacts.
A light using
area_light 2*x 2*z 65 65 adaptive 0
renders faster than one using
area_light 2*x 2*z 4 4 jitter

Next, texture and finish. If you have reflective surfaces, most of the 
time, you want fresnel reflection, unless the surface is a metal. Don't 
forget to give an IOR to the object. Usual IOR range is about 1.3 to 2.1.
Metallic textures should have an ambient value of zero.

[Bald Eagle] Re: pls make a app...

Sat, 11 Jul 2026 11:00:00 GMT

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

> > im trying to make the best POV-ray scene ever but it
> > looks like trash... soo... can somebody pls make a app for pc (windows) that
> > show how to make povray scene much better?
>
> if you post the scene, or a cut-down version of it, and tell how you rendered
> it, that is, which options etc, I'm sure people will try to help.

The biggest things that are going to affect what your scene looks like are
textures, and lighting.  You can have amazing geometry, but without those, the
whole scene will look flat, fake, and "like trash".

Consider how your scene is "composed" in terms of how photographers
painstakingly set up a scene.
Apply textures with normals and finishes.  You'd be surprised just how far that
will go.
Use good lighting.  Warp wrote an article about 3-point lighting, highlights and
shadows will do much to create a much richer sense of depth, complexity, "3D"
and realism.  And using high quality radiosity will also do amzing things that
just can't be accomplished by simply tweaking all of the above.
And then you have HDR light probes.  That will bath your scene with complex
light that simply cannot be matched in any other way. Especially if you have
some reflection in your finishes.
You truly have to see it to believe it.

As for speed, POV-Ray is slow.   It's a raytracer and uses a lot of
physical-based rendering techniques.  It's not a raster graphics package, and
doesn't use a GPU.
One must be thoughtful, and hand-craft the scene like the old masters.   You get
out what you put in.

Like jr said, post some code and a render, and we can spot areas that can
benefit from specific improvements, and help optimize things that would
otherwise unnecessarily slow down the render.

- BE

[jr] Re: pls make a app...

Sat, 11 Jul 2026 07:45:00 GMT

hi.

"" wrote:
> hello POV-ray users... im trying to make the best POV-ray scene ever but it
> looks like trash... soo... can somebody pls make a app for pc (windows) that
> show how to make povray scene much better?

if you post the scene, or a cut-down version of it, and tell how you rendered
it, that is, which options etc, I'm sure people will try to help.  (if there are
multiple files post a Zip archive)

> and also can somebody create an
> software that works like blender (a 3D software that can create scenes with
> preview and no coding) that shows the preview every 100 milisecond on 320x240
> but they after render the scene (not the full scene) pls?

perhaps the real time render option ('+rtr') will help ?

regards, jr.

[] pls make a app...

Fri, 10 Jul 2026 20:05:00 GMT

hello POV-ray users... im trying to make the best POV-ray scene ever but it
looks like trash... soo... can somebody pls make a app for pc (windows) that
show how to make povray scene much better? and also can somebody create an
software that works like blender (a 3D software that can create scenes with
preview and no coding) that shows the preview every 100 milisecond on 320x240
but they after render the scene (not the full scene) pls?

[yesbird] Re: How about a Gaussian Splat primitive in Povr...

Sat, 27 Jun 2026 13:09:54 GMT

On 27/06/2026 15:57, yesbird wrote:> Thanks so much for pointing to this 
technology, not seen itÂ before.

Was very impressed by this site:
https://superspl.at/
-- 
YB

[yesbird] Re: How about a Gaussian Splat primitive in Povr...

Sat, 27 Jun 2026 12:57:58 GMT

On 26/06/2026 08:05, Paul Bourke wrote:
> Subject says it all.
> 

Thanks so much for pointing to this technology, not seen itÂ before.

If I understand well, oneÂ ofÂ advantages is rendering performance
for
real-time applications.Not sure if POV-Ray implementation will give
better qualityÂ to sacrificeÂ thisÂ feature.
--
YB

[jr] Re: Distributed POV-Ray Rendering and Some SDL E...

Sat, 27 Jun 2026 06:35:00 GMT

hi,

"boltcapt" <bol### [at] aolcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "boltcapt" <bol### [at] aolcom> wrote:
> > ...
> > > with five new function types: userfun(), uservectfun(), usercolorfun(),
> > > useruv(), and userfracfun(), returning scalar, vector, color, UV, and 4D values
> > > respectively.
> > > For example:
> > > uservectfun("curl_field", x, y, z)
> > > where curl_field is a function exported by a dynamically loaded plugin.
> >
> > The other stuff sounds great, but plugins sound fantastic!
> >
> > I am VERY eager to hear more.
> >
> > Also, you seem to have a highly desirable skill set.
> > I have done an extensive amount of work tracking down some issues with source
> > code, but now find myself with limited time to get that implemented in a patch.
> >
> >
https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68bdae61251da1bc1f9dae3025979125%40news.povray.o
rg
> %3
> > E/
> >
> > Do you think that you could possibly help me get that work pushed across the
> > finish line so that all the time and effort was not wasted?
> >
> > - BE
>
> Happy to provide you with a good sample of a plugin package. It's long, but I
> can email it.

could you also be interested in putting together a wiki page[*] to document your
work ?  tia.

[*] MediaWiki, would be happy to assist with markup etc if you provide
"content".


regards, jr.

[boltcapt] Re: Distributed POV-Ray Rendering and Some SDL E...

Sat, 27 Jun 2026 03:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "boltcapt" <bol### [at] aolcom> wrote:
>
> > I also added a feature that I personally felt was missing from POV-Ray: the
> > ability to call precompiled native functions directly from the Scene Description
> > Language. To support this, I developed a plugin system and extended the parser
> > with five new function types: userfun(), uservectfun(), usercolorfun(),
> > useruv(), and userfracfun(), returning scalar, vector, color, UV, and 4D values
> > respectively.
> > For example:
> > uservectfun("curl_field", x, y, z)
> > where curl_field is a function exported by a dynamically loaded plugin.
>
> The other stuff sounds great, but plugins sound fantastic!
>
> I am VERY eager to hear more.
>
> Also, you seem to have a highly desirable skill set.
> I have done an extensive amount of work tracking down some issues with source
> code, but now find myself with limited time to get that implemented in a patch.
>
>
https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68bdae61251da1bc1f9dae3025979125%40news.povray.org
%3
> E/
>
> Do you think that you could possibly help me get that work pushed across the
> finish line so that all the time and effort was not wasted?
>
> - BE

Happy to provide you with a good sample of a plugin package. It's long, but I
can email it.

[ingo] Re: How about a Gaussian Splat primitive in Povr...

Fri, 26 Jun 2026 17:54:27 GMT

On 2026-06-26 07:05, Paul Bourke wrote:
> Subject says it all.
> 

Yes please ;)

I've seen some very good results but have no clue whatsoever how it works.

ingo

[Paul Bourke] How about a Gaussian Splat primitive in Povray?

Fri, 26 Jun 2026 05:10:00 GMT

Subject says it all.

[Bald Eagle] Re: Distributed POV-Ray Rendering and Some SDL E...

Thu, 25 Jun 2026 22:45:00 GMT

"boltcapt" <bol### [at] aolcom> wrote:

> I also added a feature that I personally felt was missing from POV-Ray: the
> ability to call precompiled native functions directly from the Scene Description
> Language. To support this, I developed a plugin system and extended the parser
> with five new function types: userfun(), uservectfun(), usercolorfun(),
> useruv(), and userfracfun(), returning scalar, vector, color, UV, and 4D values
> respectively.
> For example:
> uservectfun("curl_field", x, y, z)
> where curl_field is a function exported by a dynamically loaded plugin.

The other stuff sounds great, but plugins sound fantastic!

I am VERY eager to hear more.

Also, you seem to have a highly desirable skill set.
I have done an extensive amount of work tracking down some issues with source
code, but now find myself with limited time to get that implemented in a patch.

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.68bdae61251da1bc1f9dae3025979125%40news.povray.org%3
E/

Do you think that you could possibly help me get that work pushed across the
finish line so that all the time and effort was not wasted?

- BE

[Bald Eagle] Re: Distributed POV-Ray Rendering and Some SDL E...

Thu, 25 Jun 2026 22:45:00 GMT

That question has been answered as recently as this thread:

https://news.povray.org/povray.off-topic/message/%3Cweb.6a23f45069259b1fd1d09a9825979125%40news.povray.org%3E/#%3Cweb.6
a23f45069259b1fd1d09a9825979125%40news.povray.org%3E

Just don't use any UTF-8 characters and all should be fine.

- BE

[boltcapt] Re: Distributed POV-Ray Rendering and Some SDL E...

Thu, 25 Jun 2026 21:25:00 GMT

"boltcapt" <bol### [at] aolcom> wrote:

the blank 9th line should read:

performance is even more interesting: total speedups range from 17x to 63x,

I have no idea why it was deleted

> I have been a POV-Ray fan for a long time. I know there have been several
> approaches to distributed rendering over the years, but after retiring I was
> looking for a project and decided to create my own distributed client-server
> rendering system, using POV-Ray 3.7.0.10 as the base.
>
> So far the results have been encouraging. With 8 clients, measured speedup for
> still-image rendering ranges from 88.4% to 98.2% scaling efficiency, depending
> on image size and complexity (larger, more complex images scale best). Animation
>
> depending on scene characteristics. These gains come not only from distributing
> work across clients, but also from parser and caching optimizations that
> eliminate a significant amount of repeated work.
>
> Here is a summary of the project.
>
> For hardware, I wanted to see what could be accomplished with a cluster of
> Raspberry Pi 5 Compute Modules. To that end I built two self-contained four-node
> Pi clusters. I'm happy to share hardware details if anyone is interested, but
> the hardware is not really the focus of this post.
>
> The more interesting work was creating the client-server software environment.
> Starting with POV-Ray 3.7.0.10, I modified the renderer to operate as a
> non-terminating client and optimized it for distributed operation. The server
> assigns work and collects results. Work distribution itself is straightforward:
> still images are divided into row ranges, while animations are distributed one
> frame per client.
>
> The key client-side modifications are aimed at avoiding unnecessary repeated
> work. Each client maintains a single persistent POV-Ray session across multiple
> tasks and renders. Parsed scene information is cached so that repeated renders
> of the same scene do not require reparsing. In addition, I modified the parser
> to support a static keyword, allowing large clock-independent structures to be
> cached and reused between animation frames. Similar concepts have been explored
> before, but the persistent-session architecture makes this particularly
> effective.
>
> I also added a feature that I personally felt was missing from POV-Ray: the
> ability to call precompiled native functions directly from the Scene Description
> Language. To support this, I developed a plugin system and extended the parser
> with five new function types: userfun(), uservectfun(), usercolorfun(),
> useruv(), and userfracfun(), returning scalar, vector, color, UV, and 4D values
> respectively.
> For example:
> uservectfun("curl_field", x, y, z)
> where curl_field is a function exported by a dynamically loaded plugin.
>
> The server side includes a number of supporting capabilities, including
> heartbeat monitoring, failed-task reassignment, thermal management, archive
> reuse, and delta synchronization of include files.
>
> I'd be interested in hearing whether others have experimented with similar
> persistent-session approaches, parser extensions, or SDL plugin mechanisms.

[boltcapt] Distributed POV-Ray Rendering and Some SDL Enhan...

Thu, 25 Jun 2026 21:00:00 GMT

I have been a POV-Ray fan for a long time. I know there have been several
approaches to distributed rendering over the years, but after retiring I was
looking for a project and decided to create my own distributed client-server
rendering system, using POV-Ray 3.7.0.10 as the base.

So far the results have been encouraging. With 8 clients, measured speedup for
still-image rendering ranges from 88.4% to 98.2% scaling efficiency, depending
on image size and complexity (larger, more complex images scale best). Animation
performance is even more interesting: total speedups range from 17× to 63×,
depending on scene characteristics. These gains come not only from distributing
work across clients, but also from parser and caching optimizations that
eliminate a significant amount of repeated work.

Here is a summary of the project.

For hardware, I wanted to see what could be accomplished with a cluster of
Raspberry Pi 5 Compute Modules. To that end I built two self-contained four-node
Pi clusters. I'm happy to share hardware details if anyone is interested, but
the hardware is not really the focus of this post.

The more interesting work was creating the client-server software environment.
Starting with POV-Ray 3.7.0.10, I modified the renderer to operate as a
non-terminating client and optimized it for distributed operation. The server
assigns work and collects results. Work distribution itself is straightforward:
still images are divided into row ranges, while animations are distributed one
frame per client.

The key client-side modifications are aimed at avoiding unnecessary repeated
work. Each client maintains a single persistent POV-Ray session across multiple
tasks and renders. Parsed scene information is cached so that repeated renders
of the same scene do not require reparsing. In addition, I modified the parser
to support a static keyword, allowing large clock-independent structures to be
cached and reused between animation frames. Similar concepts have been explored
before, but the persistent-session architecture makes this particularly
effective.

I also added a feature that I personally felt was missing from POV-Ray: the
ability to call precompiled native functions directly from the Scene Description
Language. To support this, I developed a plugin system and extended the parser
with five new function types: userfun(), uservectfun(), usercolorfun(),
useruv(), and userfracfun(), returning scalar, vector, color, UV, and 4D values
respectively.
For example:
uservectfun("curl_field", x, y, z)
where curl_field is a function exported by a dynamically loaded plugin.

The server side includes a number of supporting capabilities, including
heartbeat monitoring, failed-task reassignment, thermal management, archive
reuse, and delta synchronization of include files.

I'd be interested in hearing whether others have experimented with similar
persistent-session approaches, parser extensions, or SDL plugin mechanisms.

[Peter Markley] Re: Popularization of the POV-Ray program on Tik...

Sat, 6 Jun 2026 16:10:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> * generally, using the below tags could federate and ease the virality:
>
> #POVRay
> #RetroCGI
> #3DRender
> #OldSchoolCGI
> #FractalArt
> #GenerativeArt
>
> * Join Broader Communities: Post your work in the
> #3DArtists
> #DigitalArt
>
> * Is there any challenge worth contributing to? These might be a fit:
>
> #RetroCGIChallenge
> #LowPolyArt
> #FractalFriday
>
> * When using Nostalgia & "Retro-Future" Aesthetic:
> #Y2K
> #AnalogHorror"
> #RetroCGI

I happened to notice this artist on Instagram using POV-Ray with the hashtag
'#vaporwaveart': https://www.instagram.com/rgbsphere

Here's some more info I found on the term "vaporwave":
https://cari.institute/aesthetics/vaporwave

--
https://petermarkley.com

[Mr] Re: Popularization of the POV-Ray program on Tik...

Thu, 28 May 2026 12:10:00 GMT

"Cossack " <nomail@nomail> wrote:
> The idea is simple: create content like memes, tutorials, videos, etc. Here's an
> example:

The first problem is adapting it to tiktok format: audio track needs to be

EITHER:
paired your renders with trending synthwave, chillwave, or retro-electronic
music to match the aesthetic.

OR:
original to avoid being censored. So what should a POV soundtrack be like? I
think sound samples from an on-topic talking podcast or tutorial, one that the
author would allow us to use could make a good backdrop... (e.g. SMCA: Stephen
Mc Avoy, with your awesome scottish accent, would you allow such derivative use
of your works?)

Then there is the content:

*WIP Videos: Users love seeing how things are made. So a time-lapse of a POV-Ray
scene compiling, or a "code vs. render" split screen, may perform very well.

*Satisfying Loops: POV-Ray is great for creating perfect, mathematically precise
loops (Möbius strips, fractals, morphing shapes) which are highly addictive to
watch.

* generally, using the below tags could federate and ease the virality:

#POVRay
#RetroCGI
#3DRender
#OldSchoolCGI
#FractalArt
#GenerativeArt

* Join Broader Communities: Post your work in the
#3DArtists
#DigitalArt

* Is there any challenge worth contributing to? These might be a fit:

#RetroCGIChallenge
#LowPolyArt
#FractalFriday

* When using Nostalgia & "Retro-Future" Aesthetic:
#Y2K
#AnalogHorror"
#RetroCGI

[Cossack ] Popularization of the POV-Ray program on TikTok

Wed, 27 May 2026 12:00:00 GMT

The idea is simple: create content like memes, tutorials, videos, etc. Here's an
example:

[jr] Re: v3.8 documentation preview (5 May version)

Tue, 26 May 2026 11:15:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > just to add, "we" would also like to know about other problems regarding the
> > documentation, for instance, are there any omissions[*] you may be aware of ?
>
> I'm sure I've commented on a few things over the past few years.

:-)

> ...
> Dunno if this has been fixed:
> https://news.povray.org/616c99b9%40news.povray.org

WFP's suggested wording was added (by JH) on the same day as his post.

> ...
> That's all for now

the "documented domain(s)" stuff has been noted.  thanks, very much.


regards, jr.

[Bald Eagle] Re: v3.8 documentation preview (5 May version)

Mon, 25 May 2026 22:35:00 GMT

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

> just to add, "we" would also like to know about other problems regarding the
> documentation, for instance, are there any omissions[*] you may be aware of ?

I'm sure I've commented on a few things over the past few years.

That can be tough to find, but I'll see what I can come up with off the top of
my head.

Functions like acos have a certain valid domain, and it would be very nice if
the input domain of the function was specifically listed for all such functions.

https://news.povray.org/povray.pov4.discussion.general/thread/%3Cweb.67ba4f111d1d35891f9dae3025979125%40news.povray.org
%3E/

Dunno if this has been fixed:

https://news.povray.org/616c99b9%40news.povray.org

https://news.povray.org/povray.advanced-users/message/%3C5e933f68%241%40news.povray.org%3E/#%3C5e933f68%241%40news.povr
ay.org%3E

That's all for now

- BE

[jr] Re: v3.8 documentation preview (5 May version)

Mon, 25 May 2026 15:15:00 GMT

hi,

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Folks,
>
> While the final content of the v3.8 documentation is certain to change (at a minimum
I want to update the Windows sec
tion, plus replace all images with larger ones), we thought it prudent to spin up a
docset to test the generation proce
ss since it has not been run since the server crash a while back.
>
> As some of you may know, the documentation on the Wiki is considered the master, and
thus we have some PHP code which
 pulls the content directly from the Wiki database, modifies it according to our needs
(e.g. converting wiki markup to 
HTML, pulling the images out of the wiki file storage), and then outputs the filesets
I will refer to below.
>
> In addition a special version of the windows docs are generated (separate from the
tarfile) from which the HtmlHelp C
HM file is generated.
>
> Due to changes in our OS install post-crash (particularly the PHP version), the PHP
scripts had to be updated to work
 with the current setup.
>
> I'd like to make a shout-out to forum regular jr who took on the task of getting
this all going and making the filese
ts I'm about to reference.
>
> Because we have had immense trouble with AI bots scraping the site (they almost all
ignore any robots.txt directives*
) and also because we do not want these pre-release docs indexed by any search engine,
I will not put the full path to 
the docs here; I am sure you can work it out :)
>
> They are on the povray site, in temp/05May2026Docs. There you will find three
tarballs (Mac, Windows and Unix) plus a
 Windows HtmlHelp file (.chm). There is also an online viewable version of the unix
docs (identical to what's in the ta
rball, I just extracted it as-is).
>
> I ask that you please do NOT share the full link anywhere public, and in particular
not in any site on the web that c
ould be indexed by search engines.


just to add, "we" would also like to know about other problems regarding the
documentation, for instance, are there any omissions[*] you may be aware of ?

[*] eg
<wiki.povray.org/content/Documentation:Tutorial_Section_1#Changes_and_New_Features_Summary>

if no one reports, finds cause to :-), we will then "move on" from middle of
June, or so.


regards, jr.

[Bald Eagle] Re: v3.8 documentation preview (5 May version)

Fri, 15 May 2026 15:50:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:

> I'd like to make a shout-out to forum regular jr who took on the task of getting
this all going and making the filese
ts I'm about to reference.

Slightly disappointed that the shout-out to jr was not in ALL CAPS.  :D

Excellent to hear that things are getting spruced up a bit.

There are thousands of ridiculously large data centers that are being built, and
people are even losing their homes and farms to "eminent domain", water prices
and electricity prices are going up, and computer memory is commanding
top-dollar.

Data centers so large that economists have determined that the scale is far
beyond what any reasonable investor would build and expect to pay off with the
profit from expected consumer usage.

Something wicked this way comes.

If only Google would index our site as thoroughly as AI scrapes it . . .  :|

Keep up the good work.

- BE

[ingo] Re: v3.8 documentation preview (5 May version)

Fri, 15 May 2026 14:08:54 GMT

On 2026-05-15 09:08, Chris Cason wrote:
> Regarding the AI scrapers ...

First at thank you to all working on POV-Ray!

Second, Chris, maybe put the AI part on the front page news. Many sites 
have been hit by this.

ingo

[yesbird] Re: v3.8 documentation preview (5 May version)

Fri, 15 May 2026 11:47:35 GMT

On 15/05/2026 07:07, Chris Cason wrote:
> Folks,
> 
> While the final content of the v3.8 documentation is certain to change 
> (at a minimum I want to update the Windows section, plus replace all 
> images with larger ones), we thought it prudent to spin up a docset to 
> test the generation process since it has not been run since the server 
> crash a while back.
> ...

Many thanks, Chris, for your hard work !

Unix online documentation is very useful and the Windows version
looks fine, even with the present size of images.
--
YB

[Chris Cason] Re: v3.8 documentation preview (5 May version)

Fri, 15 May 2026 07:09:06 GMT

Regarding the AI scrapers ...

Just in the last week we've been hit badly by them - its been going on for longer, but
it really ramped up in the past 7 days - one of which was stuck stupidly scraping
every possible permutation of the wiki, particularly the special pages, which require
much more DB time than ordinary pages. jr alerted me to the fact the system load was
sitting at 4 (normally it idles at around 0.3) and when I investigated I found the
wiki being absolutely hammered. I did a "tail -f" on the logfile and it was scrolling
too fast to easily read. The bot in question is IMO badly written as it's not as if
MediaWiki structure is uncommon (looking at you, meta ... 1.5m requests to the wiki
alone, consuming 76 GB of HTML).

Not to be outdone, I also found the old bugs.povray.org site being hammered, again by
a bot scraping every possible permutation of the content (sorting, filtering, etc ...
looking at you, apple).

Between just those two instances, just in the last week, they managed to generate more
than 30gb of log files alone. The total bandwidth consumed is not known as I did not
have cloudflare enabled for the bugs site (it is now), but I did for the wiki and,
well, I'll let the screenshots do the talking.

I have turned on cloudflare's AI bot defense which has quieted things quite a bit (see
the final image, aftermath.png - it was taken the day after I turned the bot
protection on). However I cannot yet enable cloudflare on the main website (I have to
fix a bug in the login process that only occurs when it's turned on) so it's still
vulnerable (as is the news server).

Look, see and understand why I don't want them darn AI bots finding something else to
chew on ...

[Chris Cason] v3.8 documentation preview (5 May version)

Fri, 15 May 2026 04:09:51 GMT

Folks,

While the final content of the v3.8 documentation is certain to change (at a minimum I
want to update the Windows section, plus replace all images with larger ones), we
thought it prudent to spin up a docset to test the generation process since it has not
been run since the server crash a while back.

As some of you may know, the documentation on the Wiki is considered the master, and
thus we have some PHP code which pulls the content directly from the Wiki database,
modifies it according to our needs (e.g. converting wiki markup to HTML, pulling the
images out of the wiki file storage), and then outputs the filesets I will refer to
below.

In addition a special version of the windows docs are generated (separate from the
tarfile) from which the HtmlHelp CHM file is generated.

Due to changes in our OS install post-crash (particularly the PHP version), the PHP
scripts had to be updated to work with the current setup.

I'd like to make a shout-out to forum regular jr who took on the task of getting this
all going and making the filesets I'm about to reference.

Because we have had immense trouble with AI bots scraping the site (they almost all
ignore any robots.txt directives*) and also because we do not want these pre-release
docs indexed by any search engine, I will not put the full path to the docs here; I am
sure you can work it out :)

They are on the povray site, in temp/05May2026Docs. There you will find three tarballs
(Mac, Windows and Unix) plus a Windows HtmlHelp file (.chm). There is also an online
viewable version of the unix docs (identical to what's in the tarball, I just
extracted it as-is).

I ask that you please do NOT share the full link anywhere public, and in particular
not in any site on the web that could be indexed by search engines.

* see my followup post as to just how bad it was

-- Chris

[ingo] Re: a little ray tracer

Wed, 6 May 2026 12:55:02 GMT

On 2026-05-06 14:07, Bald Eagle wrote:
> So much so, that governments here even steal our wages to manufacture and
> install metal signs that read "DEAD END". ;)

Is the situation that dire out there at the moment? :(

I used to do product development in the past. Keeping an "engineers 
diary" was extremely valuable.

ingo

[Bald Eagle] Re: a little ray tracer

Wed, 6 May 2026 12:10:00 GMT

ingo <ing### [at] nomailcom> wrote:
> Might be an awful
> lot of work to find yet another dead end street, but we can hope that
> there is a good pub at the end of it then.

Having worked on many projects at many different levels, it is just as important
to know and document what DID NOT work.  (And what was learned along the way)

So much so, that governments here even steal our wages to manufacture and
install metal signs that read "DEAD END". ;)

- BW

[ingo] Re: a little ray tracer

Wed, 6 May 2026 09:05:57 GMT

On 2026-05-05 23:18, jr wrote:
> "nagging feeling"

Hah, I have a 2000 lines "design" document, there's quite a few lines in 
it that evoke that feeling, so it's in constant flux. Might be an awful 
lot of work to find yet another dead end street, but we can hope that 
there is a good pub at the end of it then.

ingo

[ingo] Re: a little ray tracer

Wed, 6 May 2026 08:59:40 GMT

On 2026-05-06 02:45, Mr wrote:
> I suddenly feel like I was off topic as, [...]

No problem.

> [...] what would the syntax invoking them look like?
> 

Currently it's not all very well organized. For example in scene.nim 
there are mixed reposibilities. The whole intersection / traversal logic 
there should go to the raytracer file. Also the loop in main should go 
there.

The ppm generation is only "instant gratification" the database will be 
the result and it will contain HDR data. An image could be extracted 
with something that does:

proc exportPPM*(db: DbConn, frame: int, filename: string) =
   let rows = db.allRows(sql"""
     SELECT pixel_x, pixel_y,
            tonemap_reinhard(sum(rgb_r)) AS r,
            tonemap_reinhard(sum(rgb_g)) AS g,
            tonemap_reinhard(sum(rgb_b)) AS b
     FROM (
       SELECT pixel_x, pixel_y,
              spectral_to_rgb(contribution, wavelength) AS (r,g,b)
       FROM final_pixel_values
       WHERE frame = ?
     ) GROUP BY pixel_x, pixel_y
   """, frame)

   writePPM(filename, rows, width, height)

this is currently the whole scene description:

----
var sc = initScene()

# Materials
let matFloor = sc.addMaterial(Material(colour: vec3(0.8f, 0.8f, 0.8f)))
let matSphere = sc.addMaterial(Material(colour: vec3(0.8f, 0.2f, 0.2f)))
let matBox = sc.addMaterial(Material(colour: vec3(0.2f, 0.6f, 0.2f)))

# Shapes
discard sc.addShape(plane(vec3(0f, 1f, 0f), -1f, matFloor))
discard sc.addShape(sphere(vec3(0f, 0f, -3f), 1f, matSphere))
discard sc.addShape(box(vec3(-2f, -1f, -4f), vec3(-0.5f, 0.5f, -2f), 
matBox))

initPerspectiveCamera(
   relays = relays,
   pos = vec3(0f, 1f, 2f),
   lookAt = vec3(0f, 0f, -3f),
   up = vec3(0f, 1f, 0f),
   fovDeg = 60f,
   width = Width,
   height = Height
)

initRaytracerRenderer(relays, sc)

addPointLight(relays, vec3(5f, 8f, 2f),  vec3(1f, 1f, 1f),       100f)
addPointLight(relays, vec3(-3f, 4f, 0f), vec3(0.4f, 0.6f, 1f),    40f)

initColourMaterial(relays, sc)
initBlueBackground(relays)

----

I do not like that!

initScene() annoyed me. But then, one can put multiple scene in one file 
and render them in orther. Scene2 can the re-use, abuse, data from 
scene1. (Contrived crazy example, Scene One can be an animation of a 
ball bouncing against a wall many times, denting it a bit and leaving 
some colour. Train a little neural net with it. Scene Two uses the net 
for texture and displacement mapping generation.)

Currently an order in the scene is required. Not nice, maybe things can 
be ordered after a "parsing" step.

Initializing the relays can be "hidden", be done lazy. When adding a 
light source check whether a render relay is initialized if not do it.

Also shapes and materials do not look nice, I just chose the easy way to 
get the whole ting going. And, certainly there is a lot I've not thought 
about yet.

ingo

[Mr] Re: a little ray tracer

Wed, 6 May 2026 00:50:00 GMT

I suddenly feel like I was off topic as, seeing no attachment and reading too
fast missed the line with repo link so I did not realize there was something to
try out already sorry! but is it actually POV-Ray

or else, might the discussion have been posted into a more explicit category
such as pov4.discussion.general?

The concept of nim sounds good to me, but seeing your repo reads more obscure to
me than some pov code... Sorry to be thick at this late hour, so is it elements
of a new renderer itself? if so, what would the syntax invoking them look like?

[jr] Re: a little ray tracer

Tue, 5 May 2026 21:20:00 GMT

hi,

ingo <ing### [at] nomailcom> wrote:
> On 2026-05-04 21:09, jr wrote:
>  > what happened to "variety is the spice of life" ?! ...
> but but, but the raytracer's job is to populate the database. The trace
> data is the render. Everything else is SQL. Image is a query, depthmap
> is a query, normalmap is a query ...
> -- depth map as a query, not a render pass
> SELECT
>    pixel_x,
>    pixel_y,
>    MIN(t) AS depth  -- closest hit along each ray
> FROM bounces
> WHERE frame = 42
> GROUP BY pixel_x, pixel_y

you sure know how "to take the wind out of my sails" </grin>.  that really is an
interesting perspective.  heavy..

> to take it to the extreme, ...

I don't have the required background(s) but am still left with a "nagging
feeling".  a fully spec'd "application binary interface", as you've alluded to
with the dynamic-link libraries, ought to be enough.  (unless I misunderstood ?)

regards, jr.

[ingo] Re: a little ray tracer

Tue, 5 May 2026 14:47:31 GMT

On 2026-05-05 15:02, Bald Eagle wrote:
> Perhaps you could take a bit of time to explain how the parser gets handled.

When using Nim, as I do there are two and two halve options.

- Just use Nim as I have done now (could be cleaner), no need to write a 
parser as we use Nim's parser & compiler.

- A halve option adds a Domain Specific Language on top. That is created 
using Nim's macro system (AST rewriting at compile time). It is still 
pure Nim and the DSL could be done for scene description while using 
usual Nim code for the rest functions etc. Look at it as a syntax sugar 
layer:

scene:
   camera perspective:
     pos    = vec3(0, 1, 2)
     lookAt = vec3(0, 0, -3)
     fov    = 60

   sphere:
     center   = vec3(0, 0, -3)
     radius   = 1.0
     material = red

   pointLight:
     pos       = vec3(5, 8, 2)
     intensity = 100

Squiggels can probably be added to make it look more POV-Ray.

- A halve option would be to use Nim's scripting language. That would 
require no compilation but it does not (yet?) fully / seamlessly 
integrate with the compiled version. But it still looks and feels the 
same as Nim

- An option would be to write a full scene parser. I have not arrived at 
that stage, but feel it as "limiting".

Nim3 is in the making, a part of it is a Lisp like language that could 
bridge a parser and the Nim compiler. If I understand it all correctly.

https://github.com/nim-lang/nifspec/blob/master/README.md
https://github.com/nim-lang/nifspec/blob/master/doc/nif-spec.md

A front end parses and converts "POV-Ray SDL" and outputs:
(.nif27)
(.lang "raytracer")
(stmts
   (camera@2,1 (vec3 0.0 1.0 2.0) (vec3 0.0 0.0 -3.0) 60.0)
   (sphere@3,1 (vec3 0.0 0.0 -3.0) 1.0 (material :red.0.materials))
)
Nim parses it, compiles and renders.

But, what becomes clear in the discussion so far, we are trying to solve 
different problems.

ingo

[Bald Eagle] Re: a little ray tracer

Tue, 5 May 2026 13:05:00 GMT

ingo <ing### [at] nomailcom> wrote:
> .... Everything else is SQL. Image is a query, depthmap
> is a query, normalmap is a query ...

Perhaps you could take a bit of time to explain how the parser gets handled.

clipka's major concern was fixing/refactoring the parser.
I know that we have a special, hand-written parser that's not like most
languages.

If I understand all of it correctly, we have

A raw tokenizer
A tokenizer
A scanner
A parser
and then handling of objects, symbol tables, functions, textures, etc.

I don't really understand all the grammar, lexemes, syntax vs semantics, symbol
tables, etc. that go into building a language, and I think it would help if we
dedicated a few threads to discussing these aspects of the source, so that we
can better understand what we HAVE, and plan out a path to where we want/need to
be.

Writing out some code that just goes through the motions but doesn't implement
anything would give people an idea about the roadmap that constitutes how the
raytracer works overall, and I think a high-level pseudocode version would be a
great way to help organize all of the various parts.

We have redundant code, things that are intertwined in the parser that ought not
be there, and various algorithms that get applied to different shapes as part of
the bounding (bsp, cylinder bounding, AABB, sphere bounding).

If we rearranged the code at a high level, and made extensive comments about WHY
the parts of the code ought be in the places we're putting them, then that would
be a big step forward in filling in the place-holder stuff with actual code.

We already have the code base, so we can just copy-paste a lot of what already
exists, and then it would be a matter of making all of the various parts work
together.  We can make it modular, add much-needed comments and references,
standardize some of the math and constants used (epsilons), etc.

This would also be a good class on writing patches and compiling source code, so
that more people can understand how to make POV-Ray vX.Y.Z

- BW

[ingo] Re: a little ray tracer

Tue, 5 May 2026 12:20:26 GMT

On 2026-05-04 21:09, jr wrote:

 > what happened to "variety is the spice of life" ?!  different 
languages (both
 > computer and human) all have their strengths and weaknesses, and I 
see nothing
 > "wrong" with "multi-language" projects.
 >

but but, but the raytracer's job is to populate the database. The trace 
data is the render. Everything else is SQL. Image is a query, depthmap 
is a query, normalmap is a query ...

-- depth map as a query, not a render pass
SELECT
   pixel_x,
   pixel_y,
   MIN(t) AS depth  -- closest hit along each ray
FROM bounces
WHERE frame = 42
GROUP BY pixel_x, pixel_y

to take it to the extreme, the render relay should probably be the only 
thing that actually traces rays. Everything else â€” depth, normals, 
object IDs, albedo â€” is a material relay or a post-process query.

ingo

[jr] Re: a little ray tracer

Mon, 4 May 2026 19:10:00 GMT

hi,

ingo <ing### [at] nomailcom> wrote:
> Why is POV-Ray (development) in decline? Lack of developers? Realy?

I like Mr's take (for which thanks) -- "...train is steadily moving forwards..."


> Look at the wealth of include files.
> What if we can compile an include file, use it as a dll? What if after
> some time it gets integrated in the core?
> ...
> A glimpse of the goal:
>
> Scene SDL
> │
> ├--> Raytracer backend       (analytical intersection, BVH/R-tree) ←
> reference
> |--> Path tracer backend     (physically based)
> |--> OpenGL / Vulkan backend (realtime preview, all geometry meshed)
> |--> STL / mesh backend      (3D printing, watertight meshes)
> |--> Audio backend           (acoustic simulation)

ideally, yes.  however

> ... English bridges the gap between my Dutch and your French. What
> if there is no gap at all, in coding language? Front end, back end
> middle ware all in the same language. Coders and users speak the same
> language, they all "code". That removes "friction". That can enhance the
> product.

what happened to "variety is the spice of life" ?!  different languages (both
computer and human) all have their strengths and weaknesses, and I see nothing
"wrong" with "multi-language" projects.



@Bald Eagle.
> ...the sor {} object...

yes, "unfinished business", write.


regards, jr.

[ingo] Re: a little ray tracer

Mon, 4 May 2026 17:36:13 GMT

On 2026-05-04 15:04, Bald Eagle wrote:
> So I'll say it again:   1 fully working code example for every keyword.

One of the reasons I wrote the stuff in the portfolio when I worked on 
the documentation. Currently only for patterns, textures, shapes and 
objects but it can be extended to all kinds of keywords.  All kind 
radiosity setting in a Cornell box...

ingo

[Bald Eagle] Re: a little ray tracer

Mon, 4 May 2026 13:05:00 GMT

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

jr and I have had extensive discussions and brainstorming / planning sessions
where we have striven to address how we should go about
fixing/rewriting/developing POV-Ray and how to best manage an open-source
project.

I like to use the analogy of actually building something.
It may start with an idea, then a sketch, then an analysis of the details:
requirements, parameters, goals, features, allowing modification/extension, etc.
Detailed drawings, Geometric Dimensioning and Tolerancing, and perspective
drawings to get a preview of what it will look like when finished.

As folks have seen, I have tried to make lists of "things" in POV-Ray that I'd
like to implemented, improved, or fixed.

I've also made some doodles in SDL to sketch out what I'd like to see formally
implemented in source code.

With things like sor {}, I've gone through the source and done the research and
detective work necessary to understand what the goals, are, how they are
currently implemented, and meticulously checked all of the steps that make it
work, and compared that to expected or desired outputs.

Then I offered suggested source code edits, and critiqued the current state of
not only the sor {} object, but the related lathe, the spline code, the root
solver(s), and the bounding.

> There is a, almost natural, discrepancy between developers and users of
> a program. They have different interests, goals. Nothing wrong with
> that.

Yes, but there does need to be communication and meaningful feedback for
anything productive and substantive to happen.

Developers create the things that the users implement.
Users dream up applications of what the developers create.

There's a behind-the-scenes anecdote regarding the film's set design. When
reviewing script scenes depicting Hell, Director Adrian Lyne asked writer Bruce
Joel Rubin, "How many carpenters do I need to build the abyss?"
That really struck home to the writer the immense practical construction
required for the film’s surreal visuals - which are easy to convey in a book,
but might take a herculean effort to create on a set.

"Easier said than done."

Also consider the "bullet time" scene from The Matrix.  I think it took a year
and a half and a huge pile of equipment and money just to implement an effect
for only a few seconds of a scene in an otherwise long film.

> Coders and users speak the same
> language, they all "code". That removes "friction". That can enhance the
> product.

> I'm in no way suggesting that in such a case users can suddenly be core
> POV-Ray developers. Knowing the moves of chess pieces don't make me a
> chess player.

Yes, this is why I have strongly suggested that users pick a feature and try to
implement it in SDL. (or any other language)
It serves to increase understanding of what actually goes into making a shape,
or solving some equation, and properly visualizing it on the screen.

It also helps (self)document things, incidentally discover limitations, bugs,
and other unknowns, and usually the user winds up providing the results of their
research and discoveries in the forum.

That helps everyone in the long run.

Documentation is a giant pain in the ass.
However, formal documentation need not be a stumbling block for releasing a new
version.
No one needs a 4-paragraph explanation about how to use a volume control.  Be it
a rocker-style button with +/- marking, a knob to rotate that has a wedge shaped
glyph, or a slider that has a bar-graph indicator.
Even if the label is somewhat cryptic and mysterious, you just move the control
and observe the change.  Understanding is almost instantaneous.

If we have working code that a user can implement in seconds, then they can just
fiddle with the controls to intuitively understand what might takes pages of
written documentation to convey.  Not to mention all of the renders and diagrams
that might be necessary to supplement the text.

So I'll say it again:   1 fully working code example for every keyword.

Once the code gets written, it's a lot easier to understand what may need to be
written about it, and the written part can always lag behind the development
(presuming that comments are provided in the cde, as they should be).

- BE

[ingo] Re: a little ray tracer

Mon, 4 May 2026 09:21:09 GMT

On 2026-05-04 10:04, Mr wrote:
> 
> Initiatives, brainstorming are always good ! And POV development is indeed not
> at all in decline but I wouldn't look at macros to advocate that (because core
> developers know best the real gap between lowest levels and the SDL, I would
> rather look at master codebase pull requests:[...]
 >

There is a, almost natural, discrepancy between developers and users of 
a program. They have different interests, goals. Nothing wrong with 
that. They speak different languages (in life and in code (in POV-Ray's 
case)). English bridges the gap between my Dutch and your French. What 
if there is no gap at all, in coding language? Front end, back end 
middle ware all in the same language. Coders and users speak the same 
language, they all "code". That removes "friction". That can enhance the 
product.

I'm in no way suggesting that in such a case users can suddenly be core 
POV-Ray developers. Knowing the moves of chess pieces don't make me a 
chess player.

Decline; It always saddens me when I mention POV-Ray within a relevant 
context that the response is, "yeah, I used that 20 years ago, is it 
still around?".

Anyway, thoughts like this made my give it a try and see wether it would 
work. As said, it is the first working version. In theory the concept is 
very extensible up to the question: is POV-Ray the plug-in to the 
modeller or is the modeller a plug-in for POV-Ray. Don't want to quote 
Goehte here, yes, boundaries should be set, but first have to be 
explored. So far, it's just a little fun project.

ingo

[Mr] Re: a little ray tracer

Mon, 4 May 2026 08:05:00 GMT

ingo <ing### [at] nomailcom> wrote:
> Why is POV-Ray (development) in decline? Lack of developers? Realy? Look
> at the wealth of include files.
>
> What if we can compile an include file, use it as a dll? What if after
> some time it gets integrated in the core?
>
> simple scene
>    -> include file      (sphere.nim imported, used directly)
>      -> plugin          (sphere.nim compiled as shared lib, loaded at
> runtime)
>        -> core feature  (merged into core)
>
> Then the author of the Nim programming languge published:
> https://nim-lang.org/araq/relays.html
> It clicked.
>
> That woud make it possible to write torus.nim as an "extension". Add
> `import torus` in a nim scene file. The parser would detect it, but does
> not know it. Looks for the file in the right place, compiles it to a dll
> and uses it
>
> `torus.nim` would contain just the torus intersection algorithm, a
> constructor and a few tidbits. In the future it will contain a proc that
> will result in a mesh of a torus and a pies of code that extends a scene
> parser with `torus`
>
> so, shapes are relays. Lights are relays, cameras and materials are.
>
> I've been discussing ratracing for quite some time with Claude, this
> brought it all together.
>
> A glimpse of the goal:
>
> Scene SDL
> │
> ├--> Raytracer backend       (analytical intersection, BVH/R-tree) ←
> reference
> |--> Path tracer backend     (physically based)
> |--> OpenGL / Vulkan backend (realtime preview, all geometry meshed)
> |--> STL / mesh backend      (3D printing, watertight meshes)
> |--> Audio backend           (acoustic simulation)
>
> Back-ends are also relays. When back-end is switched to vulcan all
> shapes will be meshified.
>
> So far very little is implemented. The little ray tracer does not
> support plug ins yet and it just has one fixed back-end. Shapes etc are
> relays.
>
> The first code I got running with the help of Claude:
> https://gist.github.com/ingoogni/c4ca054e37a79706ff9c05c75b435467
>
> You'll find SQlite references in the code. Not implemented yet, but the
> goal is to store a lot of data during tracing in a database. These data
> can be used for example for post processing the image(s). Re-colour a
> light source?
>
> ingo

Initiatives, brainstorming are always good ! And POV development is indeed not
at all in decline but I wouldn't look at macros to advocate that (because core
developers know best the real gap between lowest levels and the SDL, I would
rather look at master codebase pull requests:
And indeed flags are turning green there: Much awaited steps are being worked on
such as incrementing Visual studio version, adding more modern scalable
processors with future-proof architectures (AVX512) without throwing away
ubiquity (3.8 bsd port is available, as is a Termux package).
Even when considering only the couple of pull requests that are being closely
reviewed by the Chris Cason, main developer, and followed through by their
openers to conform to his suggested technical tweaks or legal conformity
demands. Slow train is steadily moving forwards, with a solid strategy!

POV versions have always been slow to happen, sometimes allowing branches to
appear as they did in the MegaPOV era. But since the git-hub era started, The
improvements of these branches could almost directly benefit the plain master
version of POV after thorough testing and pruning: a lot of the Uberpov features
got merged, and a lot of the POVR/YUQK fixes also did.
The currently underestimated number one bottleneck :
More time and focus should be given to documentation. because what prevented
latest 3.8 version to go out exactly as it used to, with binary installers etc.
is docs (not only draft bits and pieces, but finalizing them and all of it):
After the departure of the person who had for decades single-handedly maintained
POV documentation. And only someone who has been there long enough to be highly
trusted by the core team and the community could fill in to not lower the
currently triple A quality, with native language (US vs UK, good expressive
style...) and lots of free time to proofread, convert it to other formats, etc.

[ingo] a little ray tracer

Mon, 4 May 2026 06:51:06 GMT

Why is POV-Ray (development) in decline? Lack of developers? Realy? Look 
at the wealth of include files.

What if we can compile an include file, use it as a dll? What if after 
some time it gets integrated in the core?

simple scene
   -> include file      (sphere.nim imported, used directly)
     -> plugin          (sphere.nim compiled as shared lib, loaded at 
runtime)
       -> core feature  (merged into core)

Then the author of the Nim programming languge published: 
https://nim-lang.org/araq/relays.html
It clicked.

That woud make it possible to write torus.nim as an "extension". Add 
`import torus` in a nim scene file. The parser would detect it, but does 
not know it. Looks for the file in the right place, compiles it to a dll 
and uses it

`torus.nim` would contain just the torus intersection algorithm, a 
constructor and a few tidbits. In the future it will contain a proc that 
will result in a mesh of a torus and a pies of code that extends a scene 
parser with `torus`

so, shapes are relays. Lights are relays, cameras and materials are.

I've been discussing ratracing for quite some time with Claude, this 
brought it all together.

A glimpse of the goal:

Scene SDL
â”‚
â”œ--> Raytracer backend       (analytical intersection, BVH/R-tree)
â† 
reference
|--> Path tracer backend     (physically based)
|--> OpenGL / Vulkan backend (realtime preview, all geometry meshed)
|--> STL / mesh backend      (3D printing, watertight meshes)
|--> Audio backend           (acoustic simulation)

Back-ends are also relays. When back-end is switched to vulcan all 
shapes will be meshified.

So far very little is implemented. The little ray tracer does not 
support plug ins yet and it just has one fixed back-end. Shapes etc are 
relays.

The first code I got running with the help of Claude:
https://gist.github.com/ingoogni/c4ca054e37a79706ff9c05c75b435467

You'll find SQlite references in the code. Not implemented yet, but the 
goal is to store a lot of data during tracing in a database. These data 
can be used for example for post processing the image(s). Re-colour a 
light source?

ingo

[Kenneth] Re: Some times I just want to play !?

Wed, 22 Apr 2026 12:50:00 GMT

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
>
> Weird that the preview thumbnail is a different color than the full image.  I
> suspect it is due to rendering without any assumed_gamma.

I see the same thing.
I think it has to do with how the thumbnail preview here treats a .png image's
encoded gamma... if it is somehow not encoded correctly. I agree with your
suspicion. I noticed this a long time ago, when I was using an *old* version of
Photoshop that encoded png's with the wrong gamma. When I uploaded them to the
newsgroups, the previews looked...wrong. Somehow, the full-size image corrects
for this (when viewed in Firefox's web browser here), or just ignores the png's
gamma altogether and substitutes the correct value.

As a 'safety measure', I try to upload only jpeg's here, which never seem to
show this odd problem. I am probably being overly-cautious now with current
standardized software, but I learned the hard way not to trust png's for
posting. :-/

[Cousin Ricky] Re: Some times I just want to play !?

Sun, 19 Apr 2026 20:35:00 GMT

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

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

[Leroy] Some times I just want to play !?

Sun, 19 Apr 2026 18:45:00 GMT

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

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


 That's it!
Have Fun!

[Bald Eagle] photorealism ray-tracing huamin wang

Wed, 15 Apr 2026 19:25:00 GMT

Yep.

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

:D

[Bald Eagle] Re: POV-Ray Origins

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

Tue, 14 Apr 2026 21:50:00 GMT

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

[yesbird] Re: Procedural Methods for Two-Dimensional Textu...

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...

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...

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...

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...

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...

Mon, 13 Apr 2026 14:46:27 GMT

Greetings !

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

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

[kurtz le pirate] Re: Post something

Mon, 13 Apr 2026 10:20:09 GMT

My Chladni patterns inspired from Ingo

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

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

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

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

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

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

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

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

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


-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Post something

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

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

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

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

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

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

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

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

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

Fri, 10 Apr 2026 17:06:12 GMT

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

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

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




-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Post something

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

Fri, 10 Apr 2026 15:17:58 GMT

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

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

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

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

[Clarence1898] Re: Post something

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

Wed, 8 Apr 2026 21:30:00 GMT

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

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

[MichaelJF] Re: Post something

Wed, 8 Apr 2026 18:39:19 GMT

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

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

Best regards
Michael

[Alain Martel] Re: Post something

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

Wed, 8 Apr 2026 15:55:00 GMT

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

> I wonder if others see the same thing?

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

- BE

[jr] Re: Post something

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

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

Wed, 8 Apr 2026 13:00:00 GMT

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

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

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

[GioSeregni] Re: about #debug

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

Tue, 7 Apr 2026 12:35:00 GMT

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

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

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

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

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

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

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

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

- BE

[GioSeregni] Re: about #debug

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

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

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

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

Tue, 7 Apr 2026 05:40:00 GMT

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

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

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

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

ingo

[GioSeregni] Re: about #debug

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

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

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

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

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

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

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

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

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

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

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

Mon, 6 Apr 2026 12:45:00 GMT

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

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

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

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

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

- BE

[Bald Eagle] Re: about #debug

Mon, 6 Apr 2026 12:10:00 GMT

Gio,

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

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

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

- BE

[GioSeregni] Re: about #debug

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

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

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

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

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

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

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

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

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

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

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

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

Thu, 2 Apr 2026 08:05:00 GMT

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

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

[Cousin Ricky] Re: There is no yellow in the circle

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

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

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

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

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

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

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

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

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

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

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

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

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

Sun, 29 Mar 2026 10:50:00 GMT

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

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

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

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

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

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

BR
G.

[jr] Re: SVG Recognized colors

Sat, 28 Mar 2026 19:55:00 GMT

hi,


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

(I started blaming my age :-))


regards, jr.

[kurtz le pirate] Re: SVG Recognized colors

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

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

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

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

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

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

Sat, 28 Mar 2026 12:24:12 GMT

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

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

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

With appreciation,
YB

[jr] Re: SVG Recognized colors

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fri, 27 Mar 2026 03:05:00 GMT

Hi David,

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

Cheers
Ton

[Cousin Ricky] Re: question about same code(?) and different re...

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

Fri, 27 Mar 2026 00:22:07 GMT

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

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

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

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

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

David Buck

[tTh] Re: Post something

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

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

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

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

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...

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

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...

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

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

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

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

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

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

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

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

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

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

Wed, 25 Mar 2026 19:25:00 GMT

Nice work producing all those variants.

I'm curious:

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

- BE

[Ilya Razmanov] SVG Recognized colors

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

Wed, 25 Mar 2026 16:15:00 GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

[Bald Eagle] Re: Post something

Wed, 25 Mar 2026 13:55:00 GMT

"laser" <nomail@nomail> wrote:

> I'm a programmer.

I am . . . shocked.  ;)

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

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

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

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

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

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

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

> An x86 assembly raytracer I wrote

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

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

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

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

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

Nice to finally meet you.
- BE

[laser] Re: Post something

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

Tue, 24 Mar 2026 16:05:00 GMT

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

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

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

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

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

[jr] Re: Animation feature request.

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.

Tue, 24 Mar 2026 01:50:00 GMT

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

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

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

    Subset_End_Frame=3755
    Declare=SEF=3755

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

m@b

[jr] Re: Post something

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

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

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

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.

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.

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.

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.

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.

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.

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

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

Sun, 22 Mar 2026 21:15:00 GMT

I have a small library of periodic waveforms.
Note that it's a practical library, sometimes with different ways of
implementing the same general shape.
Some could be trimmed down.
Some could be expanded by adding named parameters that control the shape.
Having differentiable curves would be useful for people who have need for, and
know what they're doing with that sort of thing.

I know that there are a lot of "smoothing functions" out there for use in
animations,

There are some nice polar equations out there.

These should all be standard tools that we can easily implement in scenes.

// Waveform Equations
// Bill "Bald Eagle" Walker 2026/3/22

#version version;
global_settings {assumed_gamma 1.0}


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

light_source {<40, 30, -50> rgb 1 shadowless}

sky_sphere {pigment {rgb 1}}

plane {z, 0.01 pigment {checker rgb 0.9 rgb 0.8}}

#declare Axes =
 union {
  #declare Line = 0.05;
  #declare Base = Line*2;
  #declare Length = 10;
  #declare Ext = 0.25;
  cylinder {<0, 0, 0>, <Length, 0, 0>, Line pigment {rgb x}}
   cone {<Length, 0, 0>, Base, <Length+Ext, 0, 0>, 0 pigment {rgb x} }

  cylinder {<0, 0, 0>, <0, Length, 0>, Line pigment {rgb y}}
   cone {<0, Length, 0>, Base, <0, Length+Ext, 0>, 0 pigment {rgb y}}

  cylinder {<0, 0, 0>, <0, 0, Length>, Line pigment {rgb z}}
   cone {<0, 0, Length>, Base, <0, 0, Length+Ext>, 0 pigment {rgb z}}
 }

//object {Axes}

#declare E = 1e-9;
#declare Inf = 1e10;
#declare Line = 0.08;
#declare Extent = 20;
#declare Step = 0.01;

#declare even = function(N) {select(mod(N, 2), 0, 1, 0)}
#declare odd  = function(N) {select(mod(N, 2), 1, 0, 1)}
#declare sgn  = function(N) {select(N, -1, 0, 1)}
#declare cot = function (N) {1/tan(N)}
#declare sec = function (N) {1/cos(N)}
#declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}

#declare Amplitude = 1;
#declare Period = 1;
#declare a = 1;
#declare b = 1;
#declare c = 0;
#declare f = 1;
#declare m = 1;
#declare l = 1;
#declare p = 1;
#declare T = 0.3; // how long pulse wave stays at 1
// capacitor charge-discharge
//
https://www.syncad.com/waveform_block_equations_for_timing_diagram_editors.htm
#declare pns = 0.2;
#declare pps = pns * 10;
#declare rcns = 0.01;
#declare rcps = 10 * rcns;

#declare Sample = function (N) {mod(N, pps/2)}
#declare Charge = function (N) {select (mod(floor(N/(pps/2)),2), 1, 0, 1)}

#declare Waveforms = array {
 function (N) {abs(-odd(floor(N))+mod(N, 1))},
 function (N) {1-(cos(N*pi)*0.5+0.5)},
 function (N) {sqrt(abs(-odd(floor(N))+mod(N, 1)) )},
 function (N) {pow(abs(-odd(floor(N))+mod(N, 1)), 2)},
 function (N) {select (mod(N, 2)-1, 0, 1)},
 function (N) {mod (N, 1)},
 function (N) {(-3*pow(sin(N*3), 2)*sin(N*6))*0.5},
 function (N) {-pow(sin(N*3), 2)*(a*cos(N*6) + b*sin(N*6))},
 //function (N) {-cos(N*3)*(cos(N*6)+sin(N*6))},
 function (N) {sgn (sin (2*pi*f*N))/2+0.5},
 function (N) {-(2*floor(f*N)-floor(2*f*N))},
 function (N) {pow (-1, floor(2*f*N))/2},
 function (N) {(2/pi) * atan (tan (pi*f*N/2)) + (2/pi) * atan (cot (pi*f*N/2))},
 function (N) {(4/p)*(N-(p/2)*floor(2*N/p+0.5))*pow(-1,floor(2*N/p+0.5))},
 function (N) {2*(N/p-floor(0.5+N/p))},
 function (N) {sgn (cos(2*pi*N/p)-cos(pi*T/p)) * 0.5},
 function (N) {select (Charge(N), 0, a*(1-exp(-Sample(N)/rcps)),
a*exp(-Sample(N)/rcps) )},
 function (N) {(a/pi) * (asin(sin((pi/m)*N+l)) + acos(cos((pi/m)*N+l))) - (a/2)
+ c},
 function (N) {pow(-1, floor(N/2))*sqrt (1-pow((mod(N,2)-1),2))}
};

#declare NF = dimension_size (Waveforms, 1)-1;

#declare Abscissa = x;
#declare Ordinate = y;
// Applicate: The z-coordinate (the last of the three terms by which a point is
referred to,
// in a system of Cartesian coordinates for a three-dimensional space)
#local ZeroVector = <0, 0, 0>;

#for (F, 0, NF)
 #ifdef(Function) #undef Function #end
 #local Function = Waveforms [F];
 //#debug concat ("F = ", str(F, 0, 0), "\n")
 #local Shift_Y = y*F*2;
 cylinder {<0, F*2, 0>, <Extent, F*2, 0> Line*0.75 pigment {checker rgb x rgbf 1
scale 0.25}}
 union {
  #for (i, 0, Extent, Step)
   #local Value = Function (i);
   #local A = Abscissa * i;
   #local O = Ordinate * Value + Shift_Y;
   #local Current = A + O + ZeroVector;
   sphere {Current, Line}
   #if (i > 0)
    cylinder {Last, Current+E Line}
   #end
   #local Last = Current;
  #end
  pigment {rgb 0}
 }
#end

text { ttf "arial.ttf", "Waveform Equations     Bald Eagle 2026/3/22", 0.02, 0.0
pigment {rgb z*0.4} translate y*(F)*2}

[jr] Re: Post something

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.

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.

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

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...

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...

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...

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

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

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

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

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.

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.

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

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.

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

Sat, 21 Mar 2026 00:05:00 GMT

All-SDL, Fully tileable, Full-color true Voronoi pigment. (grid-based)

[Bald Eagle] Post something

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...

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...

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...

Fri, 20 Mar 2026 16:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
>
> > triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> > pigment{color rgb<255/255,63/255,0/255>}}
> >
> > triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
> > pigment{color rgb<1,63/255,0>}}
>
> This is VERY interesting Gio.
>
> Apparently the color keyword applies gamma handling,
> but using just rgb is linear color.
>
> Remove the color keyword and see if the colors are the same.
>
> I'd also be interested to see what happens if you do your multiplication first.
> #declare Color = <255/255,63/255,0/255>;
> pigment{color rgb Color}}
>
> I guess "color" triggers legacy gamma correction rules, which exists for
> backwards compatibility.
>
> - BE
>
>
> gamma‑encoded color values, applying the scene gamma correction rules.
>
>
> And:
>
>
Thanks for the suggestion.
I'm upgrading my POV-STL-CAD translator from 32 to 64 bit, and I realized that
before translating the pov files I need to normalize all the various syntax
expressions I used in my POV and INC files.
If I don't standardize the syntax, compiling the database for exports the
entities will become a very complicated mess.
I'll try what you suggest...

[Bald Eagle] Re: question about same code(?) and different re...

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

Fri, 20 Mar 2026 03:35:00 GMT

I am working at my parser, but I got two different results.

example :

triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
pigment{color rgb<255/255,63/255,0/255>}}

triangle{<3.2475,.9143,6.0001><3.4358,.9376,5.9847><3.2475,.9376,6.0047>
pigment{color rgb<1,63/255,0>}}


but is mathematics an opinion? (ver. 3.7)

many thaks if someone help me to understand!

[Leroy] Re: povray.org and related sites unreachable to ...

Tue, 17 Mar 2026 17:55:00 GMT

> > Additionally once the issue is resolved, this will serve as an explanation as to
why we were "down" for so long.
> >
> > regards,
> >
> > -- Chris
>
> Thanks! I've posted elsewhere not knowing what the problem was. I still
> don't,(I'm not that bright;) But a lease someone is working on it!

I'm back here 2 days in a row. Somebody did something good!

[LanuHum] Re: Help: The normal map is not working

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

Tue, 17 Mar 2026 10:02:48 GMT

On 16.03.2026 14:20, Kenneth wrote:
> The 'flat' look of those gray stripes seems odd to me; there *should* be some
> (fake) 'depth' to them due to your bump_map,

Absolutely agree. But I was unable to find the reason why the result do 
not conform with my expectations.

> I changed
> that value to 2.2

Aha! That that seem be that evasive reason!

Thank you, that sort of explains things.

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

[Leroy] Re: povray.org and related sites unreachable to ...

Mon, 16 Mar 2026 22:30:00 GMT

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The datacenter in which the dedicated server hosting POV-Ray recently changed. As we
have our own class C (/24) subne
t, this (in theory) should not have affected us (outside of a few hours of downtime as
the machine was physically trans
ported) as no IP addresses needed to change: our host only had to alter the
appropriate BGP announcement to indicate th
e new route to/from our network.
>
> However it has since come to our attention that many parts of the internet are
unable to access resources on our serv
er. Sites such as wiki.povray.org and www.irtc.org continue to work as they are cached
by Cloudflare, and Cloudflare ca
n still talk to our server. The problem lies in the fact that whilst we are receiving
the incoming traffic sent our way
, outgoing traffic that needs to pass through Comcast is black-holed only four hops
from our server. This means anyone 
who is behind Comcast addresses are unable to access anything on our server.
>
> We have used our class C network for more than a quarter of a century with no real
issues; this is the first time we'
ve been black-holed by a major transit point in the US and we have no explanation for
it. A request has been lodged wit
h the Comcast NOC to fix this but as of the time of writing it remains in place.
>
> We're posting this message right now primarily to raise awareness amongst those who
are not affected but are in commu
nication with those who are (via means outside this site) to let them know why they
can't connect, since of course affe
cted users aren't able to read this message right now.
>
> Additionally once the issue is resolved, this will serve as an explanation as to why
we were "down" for so long.
>
> regards,
>
> -- Chris

Thanks! I've posted elsewhere not knowing what the problem was. I still
don't,(I'm not that bright;) But a lease someone is working on it!

[Mr] Re: Help: How to create a bolt?

Mon, 16 Mar 2026 16:40:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > #version 3.8;
> > global_settings {assumed_gamma 1.0 }
> >
> > camera {
> >  location <0, 1, -3>
> >  right x*image_width/image_height
> >  up y
> >  look_at <0, 1, 0>
> > }
> >
> > light_source {<10, 20, -50> rgb 1}
> > sky_sphere {pigment {rgb 1}}
> >
> >
> > #declare TPI = 11; // (Threads per inch / TPI)
> > #declare DM = 0.625/2;
> > #declare Dm = 0.5167/2;
> > #declare Angle = 60;
> >
> > #declare Pitch = 1/TPI;
> > #declare CompAngle = 90-Angle;
> > #declare Asin = atan(radians(CompAngle));
> > #declare dx = DM - Dm;
> > #declare dy = dx * Asin;
> > #declare AL = 2*dy; // total Angled length
> > #declare FL = (Pitch - AL)/2; // Flat length
> >
> > // Profile
> > #declare P = array {
> >       <Dm, 0, 0>,
> >       <DM, dy, 0>,
> >       <DM, dy+FL, 0>,
> >       <Dm, dy+FL+dy, 0>,
> >       <Dm, dy+FL+dy+FL, 0>
> > }
> >
> > #declare OldPoint = array[5][3];
> > #declare NewPoint = array[5][3];
> >
> > #macro MakeBoltProfile (Pitch,Steps, Tex, Copies)
> >       #local Increment = tau/Steps;
> >       #local Unit =
> >       union {
> >       #for (Theta, 0, tau, Increment)
> >
> >             #for (Pt, 0, 4)
> >             #declare NewPoint[Pt][0] = P[Pt].x * cos (Theta);
> >             #declare NewPoint[Pt][1] = P[Pt].y + Pitch * Theta/tau;
> >             #declare NewPoint[Pt][2] = P[Pt].x * sin (Theta);
> >             #end
> >
> >             #if (Theta > 0)
> >             #for (T, 0, 3)
> >                   triangle {<OldPoint[T][0], OldPoint[T][1], OldPoint[T][2]>,
> >                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
> >                         <OldPoint[T+1][0], OldPoint[T+1][1], OldPoint[T+1][2]>
> >                   }
> >                   triangle {<OldPoint[T+1][0], OldPoint[T+1][1],
> > OldPoint[T+1][2]>,
> >                         <NewPoint[T][0], NewPoint[T][1], NewPoint[T][2]>,
> >                         <NewPoint[T+1][0], NewPoint[T+1][1], NewPoint[T+1][2]>
> >                   }
> >             #end
> >           #end
> >
> >             #declare OldPoint = NewPoint;
> >       #end
> >       texture {Tex}
> >       }
> >       #for (C, 1, Copies)
> >             object {Unit translate y*Pitch*C*1}
> >       #end
> > #end
> >
> > #declare MyTex = texture {pigment {rgb 0.9} finish {specular 0.4 reflection
> > 0.01}}
> >
> > MakeBoltProfile (Pitch, 72, MyTex, 25)
>
> Thank you so much. I have no more questions about the topic.

Very glad you're back ! and it looks nice!

[Bald Eagle] Re: Help: The normal map is not working

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

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 ...

Mon, 16 Mar 2026 09:30:00 GMT

Thanks for the info, Chris.

For most of today, I was unable to access either news.povray.org or
www.povray.org (I am in the state of Virginia, U.S), but tried again at 5:15am
and they are working OK now. I have no idea if Comcast is somehow 'intertwined'
with my Verizon internet service here!

(Running the latest Firefox update...or nearly so.)

[Chris Cason] Re: povray.org and related sites unreachable to ...

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 ...

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 ...

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 ...

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...

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

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

Sat, 14 Mar 2026 12:30:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hello! I created a picture with a gradient. I want to use it as a height map for
> a sphere. However, only gray stripes are visible on the sphere.

That's because you're only perturbing the normal vectors on the smooth sphere to
make the light reflect in different directions than it normally would, and so
produce the illusion that there is a "texture" on the surface when there isn't.

There are articles on the web and maybe a POV-Ray FAQ that show the shadows cast
by objects that are really shaped that way vs a smooth object with a normal map.

What you want to do is "surface displacement" where you actually change the
geometry of the surface of your sphere.

Luckily, myself, WFP, and Maetes have worked on this.

Your best bet is to use whatever function makes your stripes to modulate the
radius of your sphere so that those points have the actual height dictated by
the function.

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

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

You can also look at Mike Williams' isosurface tutorial where he has several
examples of using functions to change the surface of a sphere.

Hope that helps.

- BE

[LanuHum] Help: The normal map is not working

Sat, 14 Mar 2026 05:05:00 GMT

Hello! I created a picture with a gradient. I want to use it as a height map for
a sphere. However, only gray stripes are visible on the sphere.

#version 3.7;
#include "shapes.inc"

global_settings {
    assumed_gamma 1.000000
    max_trace_level 3
    charset utf8
}
sky_sphere {
    pigment {rgb<0.051, 0.051, 0.051>}
}

#declare Default_texture = texture{pigment {rgb 0.8}}

#declare Material = texture{
    pigment{color srgbft <0.8000,0.8000,0.8000,0.0000,0.0000>}
    finish{
        diffuse 0.8000
        brilliance 1.8000
          }
}
#declare Material_001 = texture{
    pigment{color srgbft <0.8000,0.8000,0.8000,0.0000,0.0000>}
    normal{ bump_map{"/home/lanuhum/src/Thread_90.jpg" gamma 1.1000 map_type 0
interpolate 2 bump_size 5}
        translate <0.0000,0.0000,0.0000>
        rotate <0.0000,0.0000,0.0000>
        scale <1.0000,1.0000,1.0000>/1
        }
    finish{
        diffuse 0.8000
        brilliance 1.8000
          }
}
#declare data_Sphere_shape_ob = sphere { 0,1
    texture {Material_001}
    matrix <1.000000, 0.000000, 0.000000,  0.000000, 1.000000, 0.000000,
0.000000, 0.000000, 1.000000,  0.000000, 0.000000, 0.000000>
}
#include "data_Cube_dec.inc"

object {data_Sphere_shape_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, 0.000000, 0.000000>
}
object {data_Cube_ob
    matrix <1.000000, 0.000000, 0.000000,  0.000000, -0.000000, -1.000000,
0.000000, 1.000000, -0.000000,  0.000000, 0.000000, 0.000000>
}
light_source {
    <4.08,5.9,-1.01>
    color rgb<1, 1, 1>
    fade_distance 29.9999828339
    fade_power 1
}
camera {
    perspective
    location  <0,0,0>
    look_at  <0,0,-1>
    right <-1.7777777777777777, 0, 0>
    up <0, 1, 0>
    angle  49.134343
    rotate  <-26.440706, 46.691945, -0.000003>
    translate <7.481132, 5.343666, 6.507640>
}

[Leroy] Re: scheduled server down time

Wed, 11 Mar 2026 20:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "BTW the POV-Ray server is being moved to its new data center tonight (7:30pm
> Eastern time, or about 5hr from now). It will be down at least a few hours. You
> may want to let folks know in the forum ..."
>
>
> regards, jr.

 I couldn't access the forum yesterday and when I got on today none of the new
messages showed. So I posted the Question 'POV server down?'. Of course when I
came back to the forum This message and others appeared.

Having Fun?

[LanuHum] Re: Help: How to create a bolt?

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

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?

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?

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?

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?

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?

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?

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?

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?

Tue, 10 Mar 2026 15:50:00 GMT

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Why do you mention low poly? it's non-mesh... also the heightfield is used only
> for the head, which you don't need.
> But anyway many other answers before I mentioned Jaime's offer other non-mesh
> alternatives so by now, you end up having too many options, so you need more
> time to just pick one of them :-P The scene will be awesome!

My dear friend, I need a version that will be included in our Pov@ble addon. You
have to understand that I'm not going to write a pov file with my hands, but I'm
going to get it from a blender.

[Cousin Ricky] Re: Help: How to create a bolt?

Tue, 10 Mar 2026 14:55:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
>
> Thank you. I understand macros very poorly, but I can create a spiral from a
> sphere_sweep. Then subtract the spiral from the cylinder. But, I want to achieve
> a realistic profile.

Either of the isosurface solutions Robert Munyer and I posted would satisfy this
profile.

https://news.povray.org/5eec257c%241%40news.povray.org
https://news.povray.org/875zph8073.fsf%40munyer.com

[Mr] Re: Help: How to create a bolt?

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?

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

Mon, 9 Mar 2026 18:20:00 GMT

hi,

"BTW the POV-Ray server is being moved to its new data center tonight (7:30pm
Eastern time, or about 5hr from now). It will be down at least a few hours. You
may want to let folks know in the forum ..."


regards, jr.

[LanuHum] Re: Help: How to create a bolt?

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?

Mon, 9 Mar 2026 08:40:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Hi! I am interested in the question: is it possible to create a thread without a
> mesh of triangles? We need a smooth surface of the thread in the picture
> 38400x21600 (4K * 10)

Hi, Also, though it may be less physically accurate with respect to its
geometry,
this scene on Jaime Vives Piqueres site still works out of the box and features
a nice lighting and composition setup:
http://ignorancia.org/uploads/zips/boltstill.zip
....If you just drop all of the lightsys macro files within the same folder :
http://ignorancia.org/uploads/zips/lightsys4b.zip

[Bald Eagle] Re: Help: How to create a bolt?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

Sat, 7 Mar 2026 07:10:00 GMT

Hi! I am interested in the question: is it possible to create a thread without a
mesh of triangles? We need a smooth surface of the thread in the picture
38400x21600 (4K * 10)

[Guillermo Espitia] Re: Line numbering

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

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

Wed, 4 Mar 2026 20:35:00 GMT

Guillermo Espitia <gui### [at] gmailcom> wrote:
> Hello. Is it possible to configure Povray 3.7 so that the line numbering
> in the editor is not temporary?

Not that I'm aware of.
The editor is a Windows thing, not an actual POV-Ray thing, and this has been a
long standing issue/complaint.

The best recommendation is use an external editor and command-line interface to
have POV-Ray render that file once saved.

- BE

[Guillermo Espitia] Line numbering

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

Wed, 4 Mar 2026 18:05:00 GMT

A few more breadcrumbs from the source code.
- BE

https://github.com/POV-Ray/povray/blob/master/source/parser/parser_expressions.cpp

Starting at Line 1340:

/* Promote_Express promotes Express to the requested number of terms.  If
   *Old_Terms==1, then it sets all terms to Express[0].  Otherwise, it pads
   extra terms with 0.0.

   To maximize the consistency of results, DO NOT promote until it is actually
   required.  This is to ensure, as much as possible, that the same expression
   will produce the same results regardless of the context.
*/

void Parser::Promote_Express(EXPRESS& Express,int *Old_Terms,int New_Terms)
{
    int i;

    if (*Old_Terms >= New_Terms)
        return;

    if (*Old_Terms==1)
    {
        for(i=1;i<New_Terms;i++)
        {
            Express[i]=Express[0];
        }
    }
    else
    {
        for(i=(*Old_Terms);i<New_Terms;i++)
        {
            Express[i]=0.0;
        }
    }

    *Old_Terms=New_Terms;
}

Then, if I'm correctly inferring the meaning at Line 1581:

void Parser::Parse_Rel_Term (EXPRESS& Express,int *Terms)

this must involve the "relational operator" which I'm assuming is whatever is in
between the parentheses of a comparison)

and further down starting at line 1623:

        CASE (EQUALS_TOKEN)
            Parse_Rel_Factor(Local_Express,&Local_Terms);
            Promote_Express(Express,Terms,Local_Terms);

            for(i=0;i<*Terms;i++)
                Express[i] = (DBL)(!FTRUE(Express[i]-Local_Express[i]));
        END_CASE





Further down in the file there is the code with the light source warning
(It's actually a large block of vector code starting at line 2028)

        CASE_VECTOR_UNGET
            if (startedParsing)
            {
                EXIT
            }
            else
            {
                // Note: Setting up for potential warning on single value float
promote to
                // five value color vector. Any single float will be promoted to
the full
                // 'tgtTerms' value. This usually results in filter and transmit
values >0,
                // which caused shadow artifacts back to at least version
v3.6.1.
                if ((CurrentCategorizedTokenId() == FLOAT_TOKEN_CATEGORY) ||
(CurrentTrueTokenId() == FUNCT_ID_TOKEN))
                    sawFloatOrFloatFnct = true;
                else
                    sawFloatOrFloatFnct = false;
                if (expectFT)
                    tgtTerms = 5;
                else
                    tgtTerms = 3;
                Parse_Express(Express,&Terms);
                Promote_Express(Express,&Terms,tgtTerms);
                if (expectFT && (Terms != 5))
                    Error("Color expression expected but float or vector
expression found.");
                else if (!expectFT && ((Terms < 3) || Terms > 5))
                    Error("RGB color expression expected but float or vector
expression found.");
                colour.Set(Express, Terms);
                if (((sawFloatOrFloatFnct) && (Terms==5)) && ((colour.filter()
!= 0) && (colour.transm() != 0)))
                    Warning("Float value promoted to full color vector where
both filter and transmit >0.0.");
                if (!expectFT && ((colour.filter() != 0) || (colour.transm() !=
0)))
                    Warning("Expected pure RGB color expression, unexpected
filter and transmit components will have no effect.");
                startedParsing = true;
            }
        END_CASE

[Bald Eagle] Re: Inexplicably bad lighting in otherwise simpl...

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...

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...

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

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

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

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

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

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...

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

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

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

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

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

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

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

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

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

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

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

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

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...

Mon, 23 Feb 2026 14:05:00 GMT

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

> So I am a lot less frustrated, and a lot happier now that I'm managed to get
> that all set down into working code.

Well,
I am back to what I was struggling with in my first attempt:
orienting and placing the Villarceau circle equivalents.

To my knowledge, there is no clear documentation about where the centers lie, or
how to calculate the locus of all the centers, or if there is another parameter
like c, which lies along the a semimajor axis, but that lies along the b
semiminor axis.  There is also a movement in y.

My initial attempt involved modeling a torus, inverting it to a cyclide, and
then finding the tangent points of the Villlarceau circles on the torus,
inverting those, and finding the centers.  But orienting them is another step
entirely.

And although I love my circles almost as much as Archimedes, I'm getting a bit
frustrated going around and around this one.

Perhaps someone has a personal insight, a literature reference, an internet
link, or something that an AI actually gets right - to put me on the path to
solving this last critical step.

- BE

[yesbird] Re: Help: Erroneous mathematics information on t...

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...

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...

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...

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...

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...

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

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...

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...

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...

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...

Thu, 19 Feb 2026 12:10:00 GMT

I am working on a scene to establish geometry for conversion to OpenSCAD.

I'm super close, but when I zoomed in to closely inspect how things were
positioned, I noticed that some objects simply weren't being properly lit.
Adding emission only partially remedied the situation.

The objects are all just a simple torus {} with plain rgb pigments.
But for some reason the yellow torus is the only one really affected.
Lights are just point lights.
Lit from the front with no obvious occlusion.
Adding a top light doesn't help.

The shadows are really weird too.

3.8 beta 2

Any ideas?

- BE

[kurtz le pirate] Re: POV-Ray 3.8 and 3.7.0.9 update available

Tue, 27 Jan 2026 08:54:32 GMT

On 11/01/2026 15:28, yvo (DOT) s (AT) gmx.net wrote:
> Please visit:
> 
> https://povrayunofficial.wordpress.com
> 
> 
> Fixed OpenEXR output, updated Zlib, LibPNG, LibTiff and LibJPEG to the 
> latest versions.
> 
> Fixed some minor bugs in the GUI.
> 
> 
> Both versions are Intel and Apple Silion (universal binaries).
> 
> Runs on BigSur (11) and later, older system versions are no longer 
> supported.
> 
> 
> Best regards,


Good news. Thanks again Yvo.

A little question : You say â€œApple siliconâ€ only,
but what about the M1, 
M2, M3, and M4 in terms of code?

Does XCode automatically optimize and adapt?





-- 
kurtz le pirate
compagnie de la banquise

[David Buck] Re: THERE's A BOOK??!

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??!

Sun, 25 Jan 2026 02:25:30 GMT

On 11/12/2025 7:53 AM, Bald Eagle wrote:
> I guess this must be David K. Buck's brother?
> 
> https://devtalk.com/books/the-ray-tracer-challenge
> 
> Dave wrote the foreword?
> 
> Did anyone know about this?
> 
> - BE
> 
It looks interesting but I don't see any way to actually buy the book.

Is this a case of DevTalk not understanding capitalism or am I missing a 
bold "buy now" button?

Uncle Josh

[Kenneth] Re: odd behavior of photon reflection/refraction...

Fri, 23 Jan 2026 13:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But for REFLECTION caustics, no_image works 'as expected'-- the photon light
> *is* blocked.  So currently, no shadow works in a different way for reflected
> vs. refracted caustics.
>

That has a small but confusing typo, sorry:

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no_IMAGE works in a different way for reflected
vs. refracted caustics.

[yesbird] Re: Encyclopedia of Analytical Surfaces

Wed, 21 Jan 2026 22:12:34 GMT

On 21/01/2026 23:10, Leroy wrote:
> I just had a quick look at that page and it goes over my head. Maybe not over,
> but in it, then rattles around. Did you get the printed copy or just bookmarked
> it?

I have a printed copy and glad that ordered it. It's comprehensive and
well organized - the excellent source of ideas for my math project:
https://mathview.yesbird.online
-- 
YB

[Leroy] Re: Encyclopedia of Analytical Surfaces

Wed, 21 Jan 2026 20:15:00 GMT

yesbird wrote:
> I have just got a very impressive book "Encyclopedia of Analytical
> Surfaces" - the most complete description with classification of more
> than 500 surfaces:
>
https://books.google.ru/books?id=cXTdBgAAQBAJ&printsec=frontcover#v=onepage&q&f=false
>
> This is the end of my internet quest in searching the sources for my
> surfaces collection. :)
> --
> YB

I just had a quick look at that page and it goes over my head. Maybe not over,
but in it, then rattles around. Did you get the printed copy or just bookmarked
it?
I bookmarked It!

Have Fun!

[Kenneth] Re: odd behavior of photon reflection/refraction...

Wed, 21 Jan 2026 19:25:00 GMT

[Sorry for my silence here, I got side-tracked with just having some fun with
other POV-ray scenes. But I continued testing photon behavior...a tedious
process comparing one feature against another in refraction vs. reflection
set-ups, and in both v3.7 vs 3.8 beta 1...then trying to make sense of it
all...]

>
> [Kenneth wrote]
> Just out of curiosity, I tried adding the typical no_shadow and no_image flags
> to my photon 'target' object, to see what would happen...and either flag
> *eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
> 3.8). That does not *seem* to be an expected result to me...
>
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too [on it own surface].

With further testing, the no_shadow behavior does make sense now, at least
regarding photon 'collectors'. In my original test scene, I neglected to add a
2nd collector behind the 1st one, to see the effect of this flag. Adding it to
the 1st collector makes it 'transparent' to the PHOTON-light effects, so that
they 'pass through' and show up on the 2nd collector surface instead. (And
the docs do say that "no_shadow automatically turns on pass_through"... which I
neglected to read.) The only 'seemingly' weird thing is that this behavior is
unlike *direct* light from the light source, which still shows up on the 1st
collector as expected-- whereas the photon caustics do not. It's as if the
caustics are 'a different and separate kind of light'.

But NO_IMAGE for a 'collector' might not be working as intended: For REFRACTION
caustics, the object does become invisible, but the photon light will pass
through it to a 2nd collector-- identical to no_shadow -- which seems to be
different as to how no_image works in other circumstances: that is, the object
still exists but only its *appearance* is turned off (and *should* block the
photon light). So no_image apparently invokes no_shadow as well.

But for REFLECTION caustics, no_image works 'as expected'-- the photon light
*is* blocked.  So currently, no shadow works in a different way for reflected
vs. refracted caustics.

-----
After testing this stuff, I wanted to see how the *actual*
photons{pass_through on/off}  feature worked, as I have never used it before.

The way I understand the v3.8 docs at '3.4.3.4.4 Shooting Photons at an
Object', pass_through ON can be applied to an object that sits *between* a
photon-enabled light_source and a photon 'target'-- so that the 'photon light'
can go through that intervening object as if it was not there, instead of being
blocked by it.

But in v 3.7 and the current 3.8 betas, this does not work for a totally opaque
object; it needs *some* transparency (either f or t) which is not mentioned in
the docs...although, the limited notes there seem to imply a particular photon
*refraction* set-up with a transparent media container and photon-enabled
media(?)....implying transparency for that container object, so that
pass_through will let the photon light bypass the container and interact with
the media itself. But there is no mention of opacity...so I guess we are
supposed to assume that the intervening object needs to have at least some
transparency.

The only way to get photon-enabled light to pass through an opaque object is to
use no_shadow...which automatically turns on pass_through as well.
HOWEVER,  there is a caveat here concerning no_shadow:
an optional pass_through OFF should then work, but does not. According to the
docs for 'pass_through':

"If you use the no_shadow keyword, the object will be tagged as pass_through
automatically. You can then turn off pass_through if necessary by simply using
photons { pass_through off }."

------------
BTW:
I was able to reproduce the unexpected slow-down of photon rendering that I
mentioned earlier...or some variation of it...caused in some way by *multiple*
collector objects in a scene producing photon 'shadows'. Both 3.7 and 3.8 beta
1 show this.

I have included an additional and rather specialized test scene (reflection-only
this time, but refraction shows the same behavior): a light_source, a reflection
'target', and two 'collector' objects. One collector sits above the other, to
produce some photon 'shadowing' on the lower one. The best way to witness the
effect is with Work_Threads=1, to slow down the render.

The render  becomes sluggish in the photon *shadow* area on the lower collector,
whereas the un-shadowed areas render very quickly.  This behavior seems odd to
me, since the shadow has no photon caustics. I do realize that shadow
calculations have to be performed there, but...so slowly?  I don't know what
this implies when a scene has *many* collector objects, each casting its own
shadow onto others.  (Of course, fast multi-threaded machines tend to mask this
effect, but it's still there.)

To see an even worse and 'different'(?) example, use no_shadow for the upper
collector box. In this case, the box itself renders **very** slowly. That's
quite strange.

The only way to prevent these slow-downs is with 'collect off' in either one of
my collector objects.

[yesbird] Encyclopedia of Analytical Surfaces

Wed, 21 Jan 2026 14:02:33 GMT

I have just got a very impressive book "Encyclopedia of Analytical
Surfaces" - the most complete description with classification of more
than 500 surfaces:
https://books.google.ru/books?id=cXTdBgAAQBAJ&printsec=frontcover#v=onepage&q&f=false

This is the end of my internet quest in searching the sources for my
surfaces collection. :)
--
YB

[David Buck] Re: THERE's A BOOK??!

Wed, 21 Jan 2026 03:11:59 GMT

On 2025-11-12 12:06 p.m., kurtz le pirate wrote:
> On 12/11/2025 16:53, Bald Eagle wrote:
>> I guess this must be David K. Buck's brother?
>>
>> https://devtalk.com/books/the-ray-tracer-challenge
>>
>> Dave wrote the foreword?
>>
>> Did anyone know about this?
> 
> yes, that's him. we can read it at the end of the foreword :
>  Â  David Buck
>  Â  Author of DKBTrace and Coauthor of POV-Ray
> and that was back in 2019
> 

Yes, I wrote the forward to The Ray Tracer Challenge.  I even followed 
the implementation guided by the book (using Smalltalk) and gave some 
feedback to Jamis about it.

BTW, the last name is a pure coincidence.  As far as I can tell, we're 
not related.

These days, I'm approaching retirement within a few years.  I'm 
releasing a free open-source version of the Smalltalk programming 
language and environment called Beagle Smalltalk.  I do hope to be able 
to do some raytracing in it among other things.  My goal with this is to 
provide an environment where people can easily explore and discover the 
world of software.

I'll also be including sound, music, graphics, games, and lots more.  I 
plan to have fun with software again - hopefully I can get others hooked 
on it as well.

David Buck
Author DKBTrace / POV-Ray

[Mr] Re: New arrival

Tue, 20 Jan 2026 15:45:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > And that has got me looking into OpenSCAD again.
>
> Because of the resemblance with POV-Ray I looked into it. The resemblance is
> only on the surface. The ned to define all transforms before one can finally add
> the actual object annoyed me, as did the strange immutable vars. But, as I
> understood they started last year with adding a python layer that changes all
> that. There is also a "patched" version of openScad that does that. Have not
> tried it.
>
> I looked into 3D printing and listed what I would do with it. The result, ah,
> that I can make from wood. So, no printer, with the happy side effect of no
> plastics.
>
> The nice thing with woodworking is that I can do my visualisations in POV-Ray
> and fully parametric. I can even print the parts list.
>
> But yes, interaction with openSCAD and FeeCAD are good things to do. I still see
> POV-Ray as two things, SDL and the render engine. I still think a SDL can be
> created that serves multiple back ends, POV-Ray, OpenGL, and all the new fancy
> ray tracers like Embree. But also CAD like applications and proper output to CAM
> equipment.
>
> ingo

Feeling the same, about translating/rotating something before it exists... also
I suspect its material system can't be made to match POV-Ray's

Also even though Python can do even better, POV has the merit to allow not to
call everything as functions as Openscad does, thus reducing the number of
parenthesis or braces to open and close everywhere. Overall, even though I kept
ranting about how more stressfull than Python it could be, looking at Openscad
made me value POV syntax more ! Thanks.

[Bald Eagle] Re: New arrival

Tue, 20 Jan 2026 13:20:00 GMT

yesbird wrote:

> Why OpenSCAD, but not so popular Blender ?

Familiarity?
Modeling something in OpenSCAD is just like writing a scene in SDL.

Also, it installs in seconds.

I think I tried to install and use Blender once, ages ago.
I can't recall how long the install took, or how much space it took up.
When I opened it, it was like trying to navigate through an alien spacecraft.

Maybe I'll give it another go.

- BE

[yesbird] Re: New arrival

Mon, 19 Jan 2026 19:01:33 GMT

On 19/01/2026 20:05, Bald Eagle wrote:
> 
> "Almost no layer lines"
> I'm liking it already!   Thanks for the suggestion.

Yes, it's true - I have checked, but maybe you should set some
parameters like layer thickness, extrusion, etc. according to
manufacturer's recommendations.

> 
> Sometime soon I need to figure out printing with support vs bridging
> (my "just print it" experiments have revealed that this bridges pretty well!)
> using multiple filament colors, flipping parts that are oriented badly, scaling,
> and then get down to modeling from scratch in something like OpenSCAD, since
> it's been a good 10 years.
> Also need to learn how to pause print to insert thing like threaded nuts, allen
> wrenches, and other metal items.

I know that feeling - a new device is a new world with huge space to
explore. Wish you a happy journey :).

Why OpenSCAD, but not so popular Blender ?
-- 
YB

[Bald Eagle] Re: New arrival

Mon, 19 Jan 2026 17:10:00 GMT

yesbird wrote:
> On 19/01/2026 16:46, Bald Eagle wrote:
> > I didn't
> > really know how much actual use it would get.
>
> Just start and you will not stop ...

Well yes.
But it's really supposed to be my son's 3D printer.  ;)

> It's also important to choose a good plastic according to your needs.
> After a long quest, I am ended with this one:
> https://polymaker.com/product/polyterra-pla/

"Almost no layer lines"
I'm liking it already!   Thanks for the suggestion.

Sometime soon I need to figure out printing with support vs bridging
(my "just print it" experiments have revealed that this bridges pretty well!)
using multiple filament colors, flipping parts that are oriented badly, scaling,
and then get down to modeling from scratch in something like OpenSCAD, since
it's been a good 10 years.
Also need to learn how to pause print to insert thing like threaded nuts, allen
wrenches, and other metal items.

> > https://www.thingiverse.com/thing:4229898
> :)))
> I am imaging something like that in real world on the street ...

lol.
I might have to start giving driving directions in <x, y, z> vectors.

- BE

[yesbird] Re: New arrival

Mon, 19 Jan 2026 16:41:40 GMT

On 19/01/2026 16:46, Bald Eagle wrote:
> I've seen it used on machinist channels like Inheritance Machining,
> and they were having a "sale", so I just ran with that.
> Wasn't prepared to shell out for a high end machine, since I didn't
> really know how much actual use it would get.

Just start and you will not stop ...

> 
> But it did set up fairly fast and produced some decent quality prints using the
> default settings on my wobbly coffee table.

It's also important to choose a good plastic according to your needs.
After a long quest, I am ended with this one:
https://polymaker.com/product/polyterra-pla/

> Then you're missing the point of the opening post.
> ...

Absolutely agree that context is very important and will join this group
with pleasure.

> 
> Yeah - I have been periodically returning to my work on the Dupin Cyclide, and
> so I'll probably try to make a wireframe Dupin Cyclide and maybe one with a
> Steiner Chain of spheres inside.

Good luck with it, looking forward for images. :)

> Also, he're's a direct crossover that is directly related to both 3D printing
> and POV-Ray.  :D
> 
> https://www.thingiverse.com/thing:4229898

:)))
I am imaging something like that in real world on the street ...
-- 
YB

[ingo] Re: New arrival

Mon, 19 Jan 2026 15:35:00 GMT

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

> And that has got me looking into OpenSCAD again.

Because of the resemblance with POV-Ray I looked into it. The resemblance is
only on the surface. The ned to define all transforms before one can finally add
the actual object annoyed me, as did the strange immutable vars. But, as I
understood they started last year with adding a python layer that changes all
that. There is also a "patched" version of openScad that does that. Have not
tried it.

I looked into 3D printing and listed what I would do with it. The result, ah,
that I can make from wood. So, no printer, with the happy side effect of no
plastics.

The nice thing with woodworking is that I can do my visualisations in POV-Ray
and fully parametric. I can even print the parts list.

But yes, interaction with openSCAD and FeeCAD are good things to do. I still see
POV-Ray as two things, SDL and the render engine. I still think a SDL can be
created that serves multiple back ends, POV-Ray, OpenGL, and all the new fancy
ray tracers like Embree. But also CAD like applications and proper output to CAM
equipment.

ingo


It's only in Dutch, sorry. Cabinet Corpus
---%<---%<---
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish{ ambient 0.1 diffuse 0.9 }}


#macro Korpus(Hoogte, Breedte, Diepte, WandDikte, AchterwandDikte)
  // vaste maten
  #local constGroefAfstand = 15; // afstand groef voor achterwand tot achterkant
  #local constGroefSpeling = 2;  // ruimte die de achterwand in de groef heeft

  // afgeleide maten
  #local BinnenBreedte = Breedte - (2 * WandDikte);
  #local GroefDiepte = WandDikte / 2;
  #local AchterwandBreedte = BinnenBreedte + WandDikte - (2 *
constGroefSpeling);

  #local Zijde = prism{ // extrusie object
    linear_spline
    linear_sweep
    0, Hoogte,
    9,
    <0,0>, <-WandDikte,0>,
    <-WandDikte, Diepte>, <0,Diepte>,
    <0, Diepte - constGroefAfstand>,
    <-GroefDiepte, Diepte - constGroefAfstand>, <-GroefDiepte, Diepte -
constGroefAfstand - AchterwandDikte>,
    <0, Diepte - constGroefAfstand - AchterwandDikte>, <0, 0>
    sturm
    pigment{rgb 1}
  }

  #local LinkerZijde = object{
   Zijde
   translate<-(BinnenBreedte / 2), 0, 0>
  }

  #local RechterZijde = object{
    Zijde
    scale<-1, 1, 1> // negatieve schaal x is spiegel in yz vlak
    translate<(BinnenBreedte/2), 0, 0>
  }

  #local Bodem = box{
    <-BinnenBreedte/2, 0, 0>, <BinnenBreedte/2, WandDikte, Diepte -
constGroefAfstand - AchterwandDikte>
    pigment{rgb 1}
  }

  #local Bovenkant = object{
    Bodem translate<0, Hoogte - WandDikte, 0>
  }

  #local Achterwand = box{
    <-AchterwandBreedte/2, 0, Diepte - constGroefAfstand - AchterwandDikte>,
<AchterwandBreedte/2, Hoogte, Diepte - constGroefAfstand>
    pigment{rgb 1}
  }

  // echo stuklijst na renderen
  #debug concat("Stuklijst Korpus: ", str(Hoogte,0,1), " x ", str(Breedte,0,1),
" x ", str(Diepte,0,1), " mm\n")
  #debug
"----------------------------------------------------------------------------------------\n"
  #debug concat("Zijkant      2x : ", str(Hoogte,0,1), " x ", str(Diepte,0,1), "
x ", str(WandDikte,0,1), "mm\n")
  #debug concat("Bodem/Top    2x : ", str(BinnenBreedte,0,1), " x ", str(Diepte
- (15 + AchterwandDikte),0,1), " x " ,str(WandDikte,0,1), "mm\n")
  #debug concat("Achterwand   1x : ", str(Hoogte,0,1), " x ",
str(AchterwandBreedte,0,1), " x ", str(AchterwandDikte,0,1), "mm\n")

  union{
    object{LinkerZijde}
    object{RechterZijde}
    object{Bodem}
    object{Bovenkant}
    object{Achterwand}
  }
#end


#declare Hoogte = 600;
#declare Breedte = 300;
#declare Diepte = 250;
#declare WandDikte = 19;
#declare AchterwandDikte = 9;

#declare K = Korpus(Hoogte, Breedte, Diepte, WandDikte, AchterwandDikte)
object{
  K
  rotate <0,-30,0>
}

camera{
  angle 60
  location <Breedte , Hoogte / 2, -Hoogte*2>
  look_at <0, Hoogte/2,0>
}

light_source{
  <3000,1000,-1000>
  rgb 1
  shadowless
}
---%<---%<---

[Bald Eagle] Re: New arrival

Mon, 19 Jan 2026 13:50:00 GMT

yesbird wrote:
Excellent choice, I head that Bambu's printers are stable in work and
produces high-quality models.

I've seen it used on machinist channels like Inheritance Machining,
and they were having a "sale", so I just ran with that.
Wasn't prepared to shell out for a high end machine, since I didn't
really know how much actual use it would get.

But it did set up fairly fast and produced some decent quality prints using the
default settings on my wobbly coffee table.

> Perhaps we should have a 3D printing sub-group....

I like this idea, although it's not POV-related. Looking forward
for shots of your printed models. :)

Then you're missing the point of the opening post.
People who are members of exclusive country clubs aren't there to play golf.
They're there to meet up with other people in the echelon and privately discuss
and arrange things that can't be done in board meetings, in offices on company
time, etc.

The 3D printing group is to attract people from outside the raytracing community
 to the POV-Ray forums, so that they can be exposed to raytracing via a program
that uses a virtually identical language.
They may read other posts, and be able to offer helpful insights, suggestions,
or even code.

People can look through the 3D printing group and see something that they've
wanted to model and ask, "How did you do that?"

When we raytrace, an object in an empty POV-space will look flat, boring, and
substandard.
When we include objects in a scene such as HDR lighting or anything outside the
field of view that the central object can reflect or be influenced by via
radiosity, then there's a richness that can be achieved that is impossible to
get by rendering the central object alone.  That was a lesson I learned trying
to implement iridescence - the bubbles needed something in the scene to
reflect/refract.

We cannot raytrace in a vacuum.
We cannot hyper-focus on "POV-Ray".
I only started making significant advances with what I do when I started
investigating ShaderToy, CAD/Cam, Unity, video games, mathematics, physics, c++,
and other topics in the large penumbra from which everything in POV-Ray
originates.

I am going to print surfaces from this resource:
http://3d-meier.de/tut3/Seite0.html

like here, for example:
https://www.ams.org/journals/notices/201208/rtx120801076p.pdf

Yeah - I have been periodically returning to my work on the Dupin Cyclide, and
so I'll probably try to make a wireframe Dupin Cyclide and maybe one with a
Steiner Chain of spheres inside.

- BE

P.S.
Also, he're's a direct crossover that is directly related to both 3D printing
and POV-Ray.  :D

https://www.thingiverse.com/thing:4229898

[yesbird] Re: New arrival

Mon, 19 Jan 2026 11:51:07 GMT

On 19/01/2026 05:42, yesbird wrote:
> 
> I like this idea, although it's not POV-related. Looking forward
> for shots of your printed models. :)

I am going to print surfaces from this resource:
http://3d-meier.de/tut3/Seite0.html

using my MathView:
https://mathview.yesbird.online

like here, for example:
https://www.ams.org/journals/notices/201208/rtx120801076p.pdf
--
YB

[yesbird] Re: New arrival

Mon, 19 Jan 2026 02:42:34 GMT

On 19/01/2026 04:53, Bald Eagle wrote:
> Bambu Labs P1S with the AMS unit.
> Just using the Bambu Studio slicer until I get accustomed to everything.

Excellent choice, I head that Bambu's printers are stable in work and 
produces high-quality models.

> Perhaps we should have a 3D printing sub-group....

I like this idea, although it's not POV-related. Looking forward
for shots of your printed models. :)
-- 
YB

[Bald Eagle] Re: New arrival

Mon, 19 Jan 2026 01:55:00 GMT

yesbird wrote:

> What printer model do you have and what slicer are you using ?

Bambu Labs P1S with the AMS unit.
Just using the Bambu Studio slicer until I get accustomed to everything.

> I am happy with my CREALITY3D ENDER-3 Pro and Simplify3D for slicing.

Excellent.  It's always really just about what works.

I helped build a 3D printer from scratch, and reverse-engineered some Stratasys
stuff. There's always new materials, new techniques, and new tricks to push the
envelope with regard to what is possible.

Perhaps we should have a 3D printing sub-group....

- BE

[yesbird] Re: New arrival

Mon, 19 Jan 2026 00:03:51 GMT

On 19/01/2026 01:11, Bald Eagle wrote:
> 
> No, not like that.
> My son was born 15 years ago.  :P
> 
> However, for his 15th birthday I thought maybe he'd enjoy a 3D printer.
> 
> And that has got me looking into OpenSCAD again.
> 

My congratulations to you and him !

Solid modelling always attracted me and I was working with
Autodesk Inventor and SolidWorks, preferring the first as less buggy ).

What printer model do you have and what slicer are you using ?
I am happy with my CREALITY3D ENDER-3 Pro and Simplify3D for slicing.
-- 
YB

[Bald Eagle] "License"

Sun, 18 Jan 2026 22:35:00 GMT

This was a good, sensible read.

https://github.com/domgetter/NCoC

[Bald Eagle] New arrival

Sun, 18 Jan 2026 22:15:00 GMT

No, not like that.
My son was born 15 years ago.  :P

However, for his 15th birthday I thought maybe he'd enjoy a 3D printer.

And that has got me looking into OpenSCAD again.

Looking over OpenSCAD, it reminded me that it - shall we say - bears a
*striking* resemblance to POV-Ray.
So much so, that A look at its source might be illuminating.

Now the interesting thing is that OpenSCAD is under active development, is free,
open-source, and has a number of libraries.

They've done Google Summer of Code and all that stuff.

We could likely benefit from a lot of the work that's been done on their
software, and I can see that there could be a lot of cross-over.

So I'm inviting folks to go over, check things out, and maybe borrow a few
models and render them in POV-Ray.  Maybe join the forums and post renders, make
the off-hand comment about how code in OpenSCAD and POV-Ray are (clearly, with
certain differences) nearly identical.  "Hey, this thing this guy rendered would
be pretty neat to 3D print..."  "Hey, that 3D print came out ok, but I'll bet it
would an even more amazing render..."

Talent, expertise, enthusiasm, a vibrant community of coders that are already
familiar with something that's almost exactly like SDL...

I mean, I'm hoping that this doesn't even need selling.

- BE

[Yvo Smellenbergh] POV-Ray 3.8 and 3.7.0.9 update available

Sun, 11 Jan 2026 14:28:42 GMT

Please visit:
https://povrayunofficial.wordpress.com

Fixed OpenEXR output, updated Zlib, LibPNG, LibTiff and LibJPEG to the 
latest versions.
Fixed some minor bugs in the GUI.

Both versions are Intel and Apple Silion (universal binaries).
Runs on BigSur (11) and later, older system versions are no longer supported.

Best regards,


-- 
Yvo

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


https://povrayunofficial.wordpress.com
E-mail: yvo(DOT)s(AT)gmx.net

[Cousin Ricky] Re: odd behavior of photon reflection/refraction...

Tue, 6 Jan 2026 03:54:30 GMT

On 2026-01-05 10:46, Kenneth wrote:
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.

The last time I used 'count' was around 20 years ago, back when I was
using a 1996 vintage laptop.  When I bought a new laptop in 2006, I
found new freedom with lots of RAM, and have been using only 'spacing'
for new scenes ever since.

[Alain Martel] Re: odd behavior of photon reflection/refraction...

Mon, 5 Jan 2026 15:43:31 GMT

Le 2026-01-05 Ã  09:46, Kenneth a Ã©critÂ :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/2/26 20:44, Kenneth wrote:
>>>
>>> However: Given two (or more) 'target' objects in a scene, the photon behavior
>>> for each can be unexpectedly different, depending on whether 'count' vs.
>>> 'spacing' is used:
>>>
>>> A) With 'count':
>>> [snip]
>>>
>>> B) With 'spacing':
>>> [snip]
> 
>>
>> Re: (A) Interesting & news to me. I thought the count applied
>> independently to each target. Thanks for digging into the behavior!
>>
> 
> It was also a new discovery for me...as were Alain's comments when using
> *multiple* lights and photon targets. In most of my old photon scenes, I used
> 'count' out of simplicity-- totally unaware of its various 'if/then/else'
> results.
> 
> I'm beginning to think that 'count' should be deprecated going forward(!), since
> 'spacing' easily produces **expected** results, especially with the useful
> numerical multiplier for a 'target'.
> 
> -------------
> BTW (and a bit off-topic):
> Just out of curiosity, I tried adding the typical no_shadow and no_image flags
> to my photon 'target' object, to see what would happen...and either flag
> *eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
> 3.8). That does not *seem* to be an expected result to me-- based on what those
> flags are usually supposed to do-- but I'm still trying to wrap my brain around
> the logic it. IF those flags are operating correctly in this case, are photons
> 'shadow-based' in some way? That is, should photon caustics be regarded as
> light/SHADOW effects?
> 
> But what definitely seems strange is that adding no_shadow to my *collector*
> object eliminated the caustics too.  My understanding of
> no_shadow is that it's only supposed to eliminate shadows that are cast *from*
> an object (my collector in this case) onto other objects.
> 
> Whether or not this is the designed/expected behavior of the two flags when
> photons are used, the practical result is that those objects will exhibit
> unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
> default for all objects when a global photons block is present).  And the use of
> no_shadow and no_image for scene 'workarounds' will not work without eliminating
> the caustics as well.
> 
> 
> 
> 
Then, we must remember that shadowless lights never case photons.

 From your test, it seems that disabling shadows also disable photons.

[Kenneth] Re: odd behavior of photon reflection/refraction...

Mon, 5 Jan 2026 14:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/2/26 20:44, Kenneth wrote:
> >
> > However: Given two (or more) 'target' objects in a scene, the photon behavior
> > for each can be unexpectedly different, depending on whether 'count' vs.
> > 'spacing' is used:
> >
> > A) With 'count':
> > [snip]
> >
> > B) With 'spacing':
> > [snip]

>
> Re: (A) Interesting & news to me. I thought the count applied
> independently to each target. Thanks for digging into the behavior!
>

It was also a new discovery for me...as were Alain's comments when using
*multiple* lights and photon targets. In most of my old photon scenes, I used
'count' out of simplicity-- totally unaware of its various 'if/then/else'
results.

I'm beginning to think that 'count' should be deprecated going forward(!), since
'spacing' easily produces **expected** results, especially with the useful
numerical multiplier for a 'target'.

-------------
BTW (and a bit off-topic):
Just out of curiosity, I tried adding the typical no_shadow and no_image flags
to my photon 'target' object, to see what would happen...and either flag
*eliminated* the caustics on my 'collector' object's surface (in both v3.7 and
3.8). That does not *seem* to be an expected result to me-- based on what those
flags are usually supposed to do-- but I'm still trying to wrap my brain around
the logic it. IF those flags are operating correctly in this case, are photons
'shadow-based' in some way? That is, should photon caustics be regarded as
light/SHADOW effects?

But what definitely seems strange is that adding no_shadow to my *collector*
object eliminated the caustics too.  My understanding of
no_shadow is that it's only supposed to eliminate shadows that are cast *from*
an object (my collector in this case) onto other objects.

Whether or not this is the designed/expected behavior of the two flags when
photons are used, the practical result is that those objects will exhibit
unexpected absence-of-photon effects in a scene (given that 'collect ON' is the
default for all objects when a global photons block is present).  And the use of
no_shadow and no_image for scene 'workarounds' will not work without eliminating
the caustics as well.

[yesbird] Re: Inverse (object) panorama

Sun, 4 Jan 2026 13:11:37 GMT

On 01/01/2026 13:08, Paul Bourke wrote:
> Physically between 0.5m to 0.8m.
> 
> For this process I render them at 6 million triangles, but that is mostly for
> the rigging and editing processes. Then can be safely reduced to about 1 million
> triangles. Currently a single 64Kx64K texture map.
> 
> Textured
>     https://vimeo.com/1150255426
> And just geometry
>     https://vimeo.com/1150255327
> 

Thanks so much for this info. Now I am trying to optimize 'Metashape'
process, taking into account 6048 x 4032 resolution of my new camera.

I would like to find a balance between model quality and users
devices performance to extend potential community. Few experiments
show that texture size is a serious limit, so I am producing few
model's versions with 4K, 8K, (16k in future).

Now looking for optimal number of triangles ...
-- 
YB

[William F Pokorny] Re: odd behavior of photon reflection/refraction...

Sat, 3 Jan 2026 20:26:37 GMT

On 1/3/26 13:41, Alain Martel wrote:
> When you use count, the count value is the total number of photons to be 
> shot, distributed between all targets and all lights. The area, or 
> angular size, of the targets also play a role. A big target will tend to 
> get more photons than a small target next to it.
> 
> The photon shooting always try to keep the photon density constant 
> between all targets.
> 
> count 1 000 000
> two lights and two targets of roughly the same size, and each light will 
> shoot about 250 000 photons at each target.
> 
> Have three targets, and you shoot about 166 666 photons per light at 
> each target.

Thank you, Alain. More I didn't know! :-)

Bill P.

[Alain Martel] Re: odd behavior of photon reflection/refraction...

Sat, 3 Jan 2026 18:41:11 GMT

Le 2026-01-03 Ã  11:15, William F Pokorny a Ã©critÂ :
> On 1/2/26 20:44, Kenneth wrote:
>> My original tests used only one 'target' object, so I tested again 
>> using two,
>> and you're right: A changed multiplier value does work now (for both 
>> targets),
>> even when 'count' is used in the global photons block. This little 
>> 'switch' in
>> behavior is undocumented, as far as I can tell.
>>
>> However: Given two (or more) 'target' objects in a scene, the photon 
>> behavior
>> for each can be unexpectedly different, depending on whether 'count' vs.
>> 'spacing' is used:
>>
>> A) With 'count':
>> Â Â Â Â Â  If two targets both
use a value of 1.0 (or simply 'on'), the 
>> 'count' of
>> Â Â Â Â Â  photons is*split up
evenly* between the two; each target gets 
>> half the
>> Â Â Â Â Â  count. But if one
target uses 1.0 and the other 0.2, the 0.2 
>> target*robs*
>> Â Â Â Â Â  photons from the 1.0
target, with the resulting visual caustic 
>> effect on
>> Â Â Â Â Â  surfaces looking
different from each one. But the total photon
>> Â Â Â Â  'count' remains the same.
>>
>> B) With 'spacing':
>> Â Â Â Â Â  Each target
is*independent*-- they each respond to their individual
>> Â Â Â Â Â  spacing-multiplier
values, no 'robbing' of photons...which means 
>> the total
>> Â Â Â Â Â  NUMBER of photons can
increase, to suit the situation. This would
>> Â Â Â Â Â  produce a more logical
and visually realistic result than 'count'.
> 
> Re: (A) Interesting & news to me. I thought the count applied 
> independently to each target. Thanks for digging into the behavior!
> 
> Bill P.

When you use count, the count value is the total number of photons to be 
shot, distributed between all targets and all lights. The area, or 
angular size, of the targets also play a role. A big target will tend to 
get more photons than a small target next to it.

The photon shooting always try to keep the photon density constant 
between all targets.

count 1 000 000
two lights and two targets of roughly the same size, and each light will 
shoot about 250 000 photons at each target.

Have three targets, and you shoot about 166 666 photons per light at 
each target.

[William F Pokorny] Re: odd behavior of photon reflection/refraction...

Sat, 3 Jan 2026 16:15:11 GMT

On 1/2/26 20:44, Kenneth wrote:
> My original tests used only one 'target' object, so I tested again using two,
> and you're right: A changed multiplier value does work now (for both targets),
> even when 'count' is used in the global photons block. This little 'switch' in
> behavior is undocumented, as far as I can tell.
> 
> However: Given two (or more) 'target' objects in a scene, the photon behavior
> for each can be unexpectedly different, depending on whether 'count' vs.
> 'spacing' is used:
> 
> A) With 'count':
>       If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
>       photons is*split up evenly* between the two; each target gets half the
>       count. But if one target uses 1.0 and the other 0.2, the 0.2 target*robs*
>       photons from the 1.0 target, with the resulting visual caustic effect on
>       surfaces looking different from each one. But the total photon
>      'count' remains the same.
> 
> B) With 'spacing':
>       Each target is*independent*-- they each respond to their individual
>       spacing-multiplier values, no 'robbing' of photons...which means the total
>       NUMBER of photons can increase, to suit the situation. This would
>       produce a more logical and visually realistic result than 'count'.

Re: (A) Interesting & news to me. I thought the count applied 
independently to each target. Thanks for digging into the behavior!

Bill P.

[Kenneth] Re: odd behavior of photon reflection/refraction...

Sat, 3 Jan 2026 01:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> >
> > BTW:
> > I think that the docs'  'target' default of 1.0 [the numerical multiplier]
> > also needs a small clarification (...) The 1.0 value also works when
> > 'count' is used [instead of 'spacing'] but incrementally changing the float
> > value has no effect.
> >
>
> The value after target has an effect on the density of the photons for
> the target object.
>
> Even when using count, target 0.5 should cause that object to receive 4
> times as many photons compared to target 1/on/true. When using count,
> this only has an effect when there are at least two target objects.
>

My original tests used only one 'target' object, so I tested again using two,
and you're right: A changed multiplier value does work now (for both targets),
even when 'count' is used in the global photons block. This little 'switch' in
behavior is undocumented, as far as I can tell.

However: Given two (or more) 'target' objects in a scene, the photon behavior
for each can be unexpectedly different, depending on whether 'count' vs.
'spacing' is used:

A) With 'count':
     If two targets both use a value of 1.0 (or simply 'on'), the 'count' of
     photons is *split up evenly* between the two; each target gets half the
     count. But if one target uses 1.0 and the other 0.2, the 0.2 target *robs*
     photons from the 1.0 target, with the resulting visual caustic effect on
     surfaces looking different from each one. But the total photon
    'count' remains the same.

B) With 'spacing':
     Each target is *independent*-- they each respond to their individual
     spacing-multiplier values, no 'robbing' of photons...which means the total
     NUMBER of photons can increase, to suit the situation. This would
     produce a more logical and visually realistic result than 'count'.

Some of these behavioral differences are undocumented as well, or at least not
clearly.

[Paul Bourke] Re: Inverse (object) panorama

Thu, 1 Jan 2026 10:15:00 GMT

"ingo" <nomail@nomail> wrote:
> "ingo" <nomail@nomail> wrote:
> > In the past I simulated one in POV-Ray by using a 1-3 pixel wide image and
> > animate that around a subject. Then stitch the images together.
>
> found it at
>
https://news.povray.org/povray.binaries.images/thread/%3C389290B0.58D1D188%40email.com%3E/
>
> ingo

That's also how I did it in the past.

[Paul Bourke] Re: Inverse (object) panorama

Thu, 1 Jan 2026 10:10:00 GMT

yesbird wrote:
> On 27/12/2025 12:04, Paul Bourke wrote:
> > Still in love with the elegance of user_defined cameras. Here's the code for a
> > "inverse panorama", also known as an "object panorama".
> > ...
> It looks interesting and unusual, how large are models of puppets ?

Physical size or data size?

Physically between 0.5m to 0.8m.

For this process I render them at 6 million triangles, but that is mostly for
the rigging and editing processes. Then can be safely reduced to about 1 million
triangles. Currently a single 64Kx64K texture map.

Textured
   https://vimeo.com/1150255426
And just geometry
   https://vimeo.com/1150255327

[ingo] Re: Inverse (object) panorama

Sun, 28 Dec 2025 08:15:00 GMT

"ingo" <nomail@nomail> wrote:
> In the past I simulated one in POV-Ray by using a 1-3 pixel wide image and
> animate that around a subject. Then stitch the images together.

found it at
https://news.povray.org/povray.binaries.images/thread/%3C389290B0.58D1D188%40email.com%3E/

ingo