 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
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,
--
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] netscape net> 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
|
|
| |
| |
|
|
|
|
| |
|
|
