 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> 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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I probably spent about 5h last night working out various parts of the diagram.
There was still a bug lurking in my code, and tracked that down to a stray
identifier assignment.
After I fixed that, everything started working exactly as expected.
1. errors that are close to right, and that don't show up using standard
orientations are deceptive. Move everything around.
2.This also highlights the dangers of global identifiers.
Or even identifiers that persist throughout the scope of your whole macro.
I got all my ray points and intersections properly plotted, and then worked out
how to calculate distances along the cylinder axis instead of the ray. Then
this morning I worked out most of the circles I wanted to draw, and I've almost
got the last 2 essential points figured out.
Then I just need to orient all my labels to face the camera and parameterize the
point and line thicknesses.
> 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.
I found another equation that was essentially the same, and a few others that
were total crap and slowed the rendering down to a standstill.
Got the good one working, and then...
Sometimes it would work, sometimes it wouldn't.
Radius 1 worked, not so much for 3 and 0.5
***Normalize the axis vector, Bill.*** Yes - now it all works.
Still need to just add in the translation so that it works for any orientation
and any position.
> As far as I am aware, we only have bounding boxes and spheres for isosurface
> shapes. Odd that we don't have bounding cylinders.
Once I get this working nicely, I hope that we can get it applied to
isosurfaces. Because rendering an oblique cylinder as an isosurface using an
axis-aligned bounding box leaves a LOT of empty space to test.
Using an oblique bounding cylinder with a small buffer would be spectacularly
efficient.
Note: If one is rendering a complex isosurface with regions of empty space,
then it would probably be more efficient to define a number of unioned bounding
boxes of the same isosurface that only contain the shape and not the empty
space. Just like the sor{} is a number of segments that are for all practical
purposes unioned{} under the hood.
> I also verified that we cannot transform that bounding box using something like
> the point_at or reorient_trans macros.
I believe that if we are able to add this functionality, it might speed up a lot
of renders.
> 2. The vector-based method that I'm using will allow cylinder end caps in any
> orientation.
I'll try to quickly code this up as a supplement to the right-angle-only
version. May or may not do extensive testing, as I want to get moving along
this increasingly long daisy-chained to-do list.
Also would likely need to implement an insidedness test, which ought to be easy
to test with a ton of gridded and random points.
One thing I think I may do is implement this as a function call from the SDL
raytracing in the documentation to see if I can instantiate a bunch of cylinders
in various orientations and just render them all from within POV-Ray. :D
> 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.
I'm hoping that that will be a reasonably quick thing to do, since it's just
converting the spline to Bezier form, and pairing up a calculated radius with
the bounding polygon of each spline segment.
One thing I'm very curious about is whether or not we even need to DO bounding
tests for the sor. If the vector method makes root-solving superfluous, then
I'll bet I can just work my way from base to top and do end-cap testing along
the entire sor {} to find intersections. I'll think that out once I have the
basic implementation done.
I'm hoping to make some diagrams with macros to sequentially explain a lot of
the cross product and dot product calculations to show what they do and the
meaning of each part of the whole expression.
Then I think that rewriting the whole thing with better identifiers would be
essential, and then optimizing by working out each expression and canceling out
any repetitive factors. Maybe expand out all of the vectors, cross and dot
products and then cancel out all of the vector duplicate vector components.
Might be a job for Mathematica to make simplifying all of that faster and less
error-prone.
That might be it for now.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
