 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck <dav### [at] simberon com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
