POV-Ray : Newsgroups : povray.programming : POV-Ray source code development thread Server Time
20 Oct 2025 12:57:50 EDT (-0400)
  POV-Ray source code development thread (Message 1 to 4 of 4)  
From: Bald Eagle
Subject: POV-Ray source code development thread
Date: 6 Oct 2025 12:35:00
Message: <web.68e3ef4131c048888c81785c25979125@news.povray.org>
Having picked my way, line by line, through a few thousand lines of our source
code for various reasons, I thought that it was time to look for a free
debugger.

CLion is free for student and open-source use.

https://www.jetbrains.com/clion/

- BE


Post a reply to this message

From: Bald Eagle
Subject: Re: POV-Ray source code development thread
Date: 16 Oct 2025 12:10:00
Message: <web.68f1183d2ef98f62a433a43625979125@news.povray.org>
Once again, I can't more highly recommend the Graphics Gems series, or how
important and helpful it would be for people interested in helping further
develop POV-Ray to begin implementing some of these algorithms.

Doing so in c++ would allow immediate test implementation, however implementing
them in SDL would allow others to play, learn, and become confident in
implementing algorithms of their own choosing.

http://cas.xav.free.fr/Graphics%20Gems%204%20-%20Paul%20S.%20Heckbert.pdf

I'll likely now be poring over the line/ray-cylinder intersection articles.

(Since it is directly related to sor spline bounding, but also there seems to be
issue with correctly rendering cylinders with an essentially unbounded endpoint)

- BE

(I was also excited to see a full polygonolization algorithm for implicit
surfaces just before the line-cylinder intersection articles!)


Post a reply to this message

From: Bald Eagle
Subject: Re: POV-Ray source code development thread
Date: 17 Oct 2025 14:10:00
Message: <web.68f286262ef98f628f1ef7f525979125@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> I'll likely now be poring over the line/ray-cylinder intersection articles.
>
> (Since it is directly related to sor spline bounding, but also there seems to be
> issue with correctly rendering cylinders with an essentially unbounded endpoint)

Desmos 3d Graph
All vector math, no algebraic solver needed!

https://www.desmos.com/3d/c795aacwsb

(Just click on the orange surface icon on (at present) line 14 to toggle the
cylinder and see the vectors)

"A benefit of this geometric approach to the ray-cylinder intersection is that
it deals directly in object-space coordinates.  This avoids the overhead of
transforming either the rays and/or the bounded cylinder into a canonical form
for testing."

Will work on adding the end cap intersections and surface normals.

Enjoy,

- BE


Post a reply to this message


Attachments:
Download 'screenshot 2025-10-17 140817.png' (64 KB)

Preview of image 'screenshot 2025-10-17 140817.png'
screenshot 2025-10-17 140817.png


 

From: Bald Eagle
Subject: Re: POV-Ray source code development thread
Date: 20 Oct 2025 10:10:00
Message: <web.68f642b22ef98f62c330b87125979125@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> Will work on adding the end cap intersections and surface normals.

Update:

Surface normals got implemented first.
axis-aligned development cylinder worked fine, but when tilted, the normals were
wrong, prompting my vector cross-product question in another thread.

That was the result of using R instead of r, and so once everything gets to the
point of "working", I'll likely do more testing, and then refactor to use more
descriptive identifiers.



1. I found an equation for a general cylinder, however the radius wasn't correct
when I rendered it as an isosurface. (*)
I need to track down the source of that error and document it, because that
would be useful.
As far as I am aware, we only have bounding boxes and spheres for isosurface
shapes.   Odd that we don't have bounding cylinders.
I also verified that we cannot transform that bounding box using something like
the point_at or reorient_trans macros.

2. The vector-based method that I'm using will allow cylinder end caps in any
orientation.  This would likely allow a great saving in computation to make such
shapes, since we wouldn't have to do CSG and add a whole other layer of bounding
and intersection.
A proposed syntax for such a shape might be something like
cylinder {Start, End, Radius, optional StartNormal, optional EndNormal}

That way if no normals are supplied, then it's just the usual right-angle
cylinder.

There may better ways that make implementation easier.

- BE

After I get that all sorted out, then I can hopefully start on properly bounding
the Catmull-Rom spline to fix the blank-out bug.


(*)
searching again for such an equation (surprisingly hard to find) yields:
\((v_{y}(z-z_{0})-v_{z}(y-y_{0}))^{2}+(v_{z}(x-x_{0})-v_{x}(z-z_{0}))^{2}+(v_{x}(y-y_{0})-v_{y}(x-x_{0}))^{2}=(v_{x}^{2
}+v_{y}^{2}+v_{z}^{2})r^{2}\)

Which looks like it may have the corrective factor included as a coefficient of
r^2

also:

https://math.stackexchange.com/questions/1184038/what-is-the-equation-of-a-general-circle-in-3-d-space


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.