POV-Ray : Newsgroups : povray.documentation.inbuilt : SOR documentation Server Time
23 Oct 2025 16:46:31 EDT (-0400)
  SOR documentation (Message 52 to 61 of 62)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 1 Messages >>>
From: Bald Eagle
Subject: Re: SOR documentation
Date: 12 Oct 2025 07:55:00
Message: <web.68eb96e1251da1bc1f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> 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.

Thank you, Sir.
I'm hoping that at least a little bit of improvement will come of all of this.

Interested in your thoughts about the possibility of breaking the sor {} up into
individual spline segments for rendering to optimize the cylindrical bounding.

- BW


Post a reply to this message

From: Bald Eagle
Subject: Re: SOR documentation
Date: 21 Oct 2025 14:05:00
Message: <web.68f7cafa251da1bc438b893125979125@news.povray.org>
2025 paper, if someone can access the full article.

https://www.researchgate.net/publication/3904359_Ray_tracing_surfaces_of_revolution_An_old_problem_with_a_new_perspecti
ve

Ray tracing surfaces of revolution: An old problem with a new perspective
February 2001Proceedings of Computer Graphics International Conference, CGI

Abstract
We present a new subdivision scheme that is shown to improve the performance of
ray tracing surfaces of revolution over Kajiya's (1983) classical work. This is
based on a monotonic interval partitioning of a generatrix of a surface of
revolution. The algorithm has a search complexity upper bound of O(log(m n)) for
m monotonic intervals and n subdivisions for each interval and runs up to three
times faster on large scenes. This method also suggests a novel hybrid bounding
volume scheme that reduces this number of intersection tests between a ray and
the actual object surface


Post a reply to this message

From: ingo
Subject: Re: SOR documentation
Date: 22 Oct 2025 03:55:00
Message: <web.68f88da3251da1bc17bac71e8ffb8ce3@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> 2025 paper, if someone can access the full article.
>
>
https://www.researchgate.net/publication/3904359_Ray_tracing_surfaces_of_revolution_An_old_problem_with_a_new_perspec
ti
> ve

looks interesting. do you need it or do you already have it? I can mail it.

ingo


Post a reply to this message

From: Bald Eagle
Subject: Re: SOR documentation
Date: 22 Oct 2025 20:15:00
Message: <web.68f97329251da1bc1f9dae3025979125@news.povray.org>
"ingo" <nomail@nomail> wrote:

> looks interesting. do you need it or do you already have it? I can mail it.
>
> ingo

Thanks Ingo.
Let me check and see if I was able to get that one.

I'll look on my other computer at work tomorrow.
I was in the midst of a flurry of activity and can't recall if I managed to get
that one.

The original sor {} paper(s) for our source code would be very nice to have.  ;)

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: SOR documentation
Date: 23 Oct 2025 03:34:30
Message: <68f9da86$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: SOR documentation
Date: 23 Oct 2025 06:35:00
Message: <web.68fa03ae251da1bc1f9dae3025979125@news.povray.org>
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

From: Bald Eagle
Subject: Re: SOR documentation
Date: 23 Oct 2025 09:40:00
Message: <web.68fa2fde251da1bc76d02faa25979125@news.povray.org>
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

From: Bald Eagle
Subject: Re: SOR documentation
Date: 23 Oct 2025 09:50:00
Message: <web.68fa318e251da1bc76d02faa25979125@news.povray.org>
"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

From: Bald Eagle
Subject: Re: SOR documentation
Date: 23 Oct 2025 09:55:00
Message: <web.68fa32f4251da1bc76d02faa25979125@news.povray.org>
"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

From: ingo
Subject: Re: SOR documentation
Date: 23 Oct 2025 10:25:00
Message: <web.68fa3a66251da1bc17bac71e8ffb8ce3@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> Appreciate you tracking that down for me.
>
Sent

ingo


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 1 Messages >>>

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