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

Post a reply to this message

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.

Post a reply to this message

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

Post a reply to this message

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

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

Post a reply to this message

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

Post a reply to this message

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.

Post a reply to this message