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