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

Post a reply to this message

Hi David,

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

Cheers
Ton

Post a reply to this message

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

Post a reply to this message

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
> 
> 
>

Post a reply to this message

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
> 
> 
>

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

Attachments:
Download 'ac22.gif' (17 KB)

Preview of image 'ac22.gif'

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

Post a reply to this message

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

Post a reply to this message

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!

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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!

Post a reply to this message

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

Post a reply to this message

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...

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

> 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.

Post a reply to this message

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

Post a reply to this message

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/>

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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!)

Post a reply to this message

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

Post a reply to this message

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

Post a reply to this message

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!

Post a reply to this message

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

Post a reply to this message

"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

Post a reply to this message

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.

Post a reply to this message