On 10/10/25 16:03, William F Pokorny wrote:
> I'm loosely following your sor updates - good work. I'll try and carve 
> out some time to code up your suggested changes in my working yuqk code 
> & do some testing.

OK. Looking specifically at these two suggestions:

1. replace
D = ray.Direction;
with
D = <ray.Direction.x, 0, ray.Direction.z>;

and

2. replace
#if (r0 > Radius2)
with
#if (fabs(r0) > Radius2)

----

1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what 
version of source code are you seeing this?

2) Your fabs() suggestion looks like a win and I plan to adopt it for 
release 20 of yuqk.

---

The benefits of (2) depend on:

a) how much void space there is between that outer cylinder and all the 
inner per segment ones.

b) the alignment of rays with the bounding box used for global bounding. 
I looked too at completely eliminating the initial cylinder bound test 
as we already do cylinder bounding for each segment / interval.

Summarizing the performance changes for a bunch of testing.

------ Worst case bounding box alignment (cyl bound helps most)

56.03 -> 54.79s ---> -2.21% Old to New

55.70 -> 54.79s ---> -1.63% No_InitialCylTest to New

------ Best case bounding box alignment (cyl bound helps least)

43.99 -> 43.89s ---> -0.23%   Old to New

44.47 -> 43.89s ---> -1.30%   No_InitialCylTest to New

------ Turning global bounding completely off in yuqk with '-b'

100.72 -> 98.01s ---> -2.69%  Old to New

  98.44 -> 98.01s ---> -0.44%  No_InitialCylTest to New (*)

(*) Where every ray sees the initial cylinder test (New) vs not, the 
performance is less different due the expensive sqrt() starting to eat 
the better in bounding benefit. The change is still a win because we're 
not running without global bounding except in rare cases.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
> version of source code are you seeing this?

Right because that line is not explicitly there.
D is implicitly defined as the ray direction.

Then in line 256 we do:    len = D.length();

Which is why we need to get rid of the y component for reasons explained.

So really what we need is an extra line that REdefines the _projected_ ray
direction as D = <D.x, 0, D.y> before that length and normalization take place.

- BW

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:


> The benefits of (2) depend on:
>
> a) how much void space there is between that outer cylinder and all the
> inner per segment ones.

Yes, that is a better way to express what is going on.

> b) the alignment of rays with the bounding box used for global bounding.
> I looked too at completely eliminating the initial cylinder bound test
> as we already do cylinder bounding for each segment / interval.

I was having some troubles getting my endcap intersection tests to work
properly.
I think in the pre-work absorbing coffee phaze/haze that I figured out half of
that.

The second half may be directly related and solved by that realization.

So at present, I believe that I have code that reliably tests for intersections
with the infinite cylinder, and once I fix the issue with the end caps, then I
will begin to run some comprehensive tests. (*)

After that, I can either let you look over and test the code on your own, or I
can work on plugging it into the Section 3.9 raytracer as a function call.

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.9#The_idea_and_the_code

- BW

(*)  I have made a list of 16 different types of rays to test, and want to
parameterize them so that I can just auto-calculate rays for any cylinder
parameters I enter.

(1) Ray parallel to cylinder axis, which misses the cylinder
(2) Ray that is skew/perpendicular to cylinder axis which misses the cylinder
(3) Ray parallel to cylinder axis, which intersects the cylinder edge
(4) Ray that is skew/perpendicular and that intersects tangentially
(5) Ray parallel to cylinder axis, which intersects the cylinder inside
(6) Ray that is skew/perpendicular and that intersects inside
Diagonal rays that:
(7) hit the bottom end cap, then the top end cap (non-perpendicularly)
(8) hit the cylinder then the bottom end cap
(9) hit the top end cap then the cylinder
(10) hit the cylinder then the top end cap

(11) Ray that is parallel to bottom end cap and misses
(12) Ray that is parallel to bottom end cap and intersects
(13) Ray that is parallel to top end cap and misses
(14) Ray that is parallel to top end cap and intersects
(15) Ray that clips a bottom corner
(16) Ray that clips a top corner

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I'll look on my other computer at work tomorrow.

No, I do not have that one.
Appreciate you tracking that down for me.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
> > version of source code are you seeing this?
>
> Right because that line is not explicitly there.
> D is implicitly defined as the ray direction.
>
> Then in line 256 we do:    len = D.length();
>
> Which is why we need to get rid of the y component for reasons explained.
>
> So really what we need is an extra line that REdefines the _projected_ ray
> direction as D = <D.x, 0, D.y> before that length and normalization take place.
>
> - BW

https://news.povray.org/web.68e8688f251da1bc1f9dae3025979125%40news.povray.org

"2. The issue (*) above was a result of the ray direction being used as-is.
When I had an angled ray, the length was too large, and overly shortened my
perpendicular vector.
When I only used the ray projection onto the xz plane, all of my perpendicular
vectors were of the proper length."

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Appreciate you tracking that down for me.
>
Sent

ingo

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

@Ingo:  Thank you!

@all: In addition to:
> (*)  I have made a list of 16 different types of rays to test, and want to
> parameterize them so that I can just auto-calculate rays for any cylinder
> parameters I enter.
>
> (1) Ray parallel to cylinder axis, which misses the cylinder
> (2) Ray that is skew/perpendicular to cylinder axis which misses the cylinder
> (3) Ray parallel to cylinder axis, which intersects the cylinder edge
> (4) Ray that is skew/perpendicular and that intersects tangentially
> (5) Ray parallel to cylinder axis, which intersects the cylinder inside
> (6) Ray that is skew/perpendicular and that intersects inside
> Diagonal rays that:
> (7) hit the bottom end cap, then the top end cap (non-perpendicularly)
> (8) hit the cylinder then the bottom end cap
> (9) hit the top end cap then the cylinder
> (10) hit the cylinder then the top end cap
>
> (11) Ray that is parallel to bottom end cap and misses
> (12) Ray that is parallel to bottom end cap and intersects
> (13) Ray that is parallel to top end cap and misses
> (14) Ray that is parallel to top end cap and intersects
> (15) Ray that clips a bottom corner
> (16) Ray that clips a top corner

I also have to create cases starting on the surface of the cylinder as well as
originating from the interior of the cylinder.

- BE

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> So at present, I believe that I have code that reliably tests for intersections
> with the infinite cylinder, and once I fix the issue with the end caps, then I
> will begin to run some comprehensive tests. (*)

Well, that took way longer than it should have.
It would have probably gone a lot faster if I wasn't stupid and if the paper
explained the code better, or wrote it in a way that showed the pairing of
functions in a use case.

Once I hunted down why everything seemed half-right, upside-down, and
inside-out, I finally got the bounded cylinder to render without any residual
infinite cylinder hits.


> After that, I can either let you look over and test the code on your own, or I
> can work on plugging it into the Section 3.9 raytracer as a function call.

I kinda got a rectangle, which I'm optimistically hoping was my cylinder.
I was still using radius and other data from the sphere sample raytracer, and
when I "fixed" that, I get a black render.

However, now I just have to debug the function call and subsequent calculations,
and I'm hoping to get an actual homemade render soon.

Here's my SDL test scene shooting a bunch of rays from a grid, all having the
same direction vector, and showing missed rays (red), entry hits (green), and
exit hits (blue).

I think it's good enough to begin testing the Catmull-Rom bounding.

- BW

Also, there is a mouse in my kitchen.
Happens every year around this time.   :\

Post a reply to this message

Attachments:
Download 'graphicsgemslinecylinderintersection.png' (218 KB)

Preview of image 'graphicsgemslinecylinderintersection.png'

On 10/23/25 09:51, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>>> 1) I cannot find 'D = ray.Direction;' in my yuqk code? Where and in what
>>> version of source code are you seeing this?
>>
>> Right because that line is not explicitly there.
>> D is implicitly defined as the ray direction.
>>
>> Then in line 256 we do:    len = D.length();
>>
>> Which is why we need to get rid of the y component for reasons explained.
>>
>> So really what we need is an extra line that REdefines the _projected_ ray
>> direction as D = <D.x, 0, D.y> before that length and normalization take place.
>>
>> - BW
> 
> https://news.povray.org/web.68e8688f251da1bc1f9dae3025979125%40news.povray.org
> 
> "2. The issue (*) above was a result of the ray direction being used as-is.
> When I had an angled ray, the length was too large, and overly shortened my
> perpendicular vector.
> When I only used the ray projection onto the xz plane, all of my perpendicular
> vectors were of the proper length."
> 

Thanks Bill.

I think the normalization - including y - is necessary for other reasons 
like the generation of the polynomials, but I also believe I see your 
point about what is needed for the initial bounding cylinder check, 
specifically. I'll try with branch-off code which drops the 'y' 
component for the initial cylinder test only.

Aside: I'd make a moderate bet this tangled with the issues I had in 
some rotation about x tests where parts (partial segments/intervals) of 
the sor would drop out. IIRC, those tests included negative on curve 
(between end control points, points). We'll see.

Bill P.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
once I fix the issue with the end caps, then I
> > will begin to run some comprehensive tests. (*)
>
> Well, that took way longer than it should have.

The issues here were that it was unclear how and when each function should be
called, and in what order.
There were some issues with the signs of normals and dot products.
And then there was the issue with hits on the end cap that should have replaced
the hit on the infinite cylinder.
And clipping of the edge between the cylinder end cap was leaving residual hits.
So there were 4 places that I needed to add code to undef the results of the
infinite cylinder intersection test.

After that, I kinda needed to write a 3rd macro to take everything and assemble
the output of the 2 macros.

A cautionary tale here is that you have the math and geometry, the code that you
write to do it all, and then the code that you write to interpret and visualize
the result.
Don't go chasing bugs in the first two parts, if the problem is in the third
part.

> However, now I just have to debug the function call and subsequent calculations,
> and I'm hoping to get an actual homemade render soon.

That might not get done until the weekend, when I have another 5 straight hours
to scroll back and forth through the code, inventing new expletives until I
finally get something to work.

Stage One is where all of the things in the code get pondered and picked at.
Even if it's the code I wrote myself.

Stage Two is where a "sense" of deeper understanding starts to occur, and one
starts to gain traction, where the parts of the code that really matter start to
be modified and manipulated in a such a way that you can tell that that's where
much of the solution lies.

Stage Three is where you're probably on the edge of giving up, and just make the
decision to spend another 1-2h just trying to push ahead.  Weird things happen.
It seems like code gets edited and restored in an unproductive circle, yet
somehow something happens that nudges it forward.  Then some key debugging
output coupled with new tests and sections of code finally lead you down the
path to success.

Stage Three is where it ALL happens.  DO IT.

- BE

Post a reply to this message