Ray-surface intersections

[JTS]

Hi to all,
I have a quite general question on algorithms for ray-surface
intersections: which one is the best? (here I am joking a little bit).

Let me give a few lines of context. I have played a little bit with
Goptical, trying out light concentration with a compound parabolic
concentrator, and the program misses many of the interceptions. Looking
in the source code, I see that for a generic surface Newton's method of
root finding is implemented (if I understood correctly: I was not able
to follow all of the details of the code).

I would like to experiment a bit with other intersection finding methods
- I have seen browsing the internet (e.g. the documentation for Optica,
the optical design program based on Mathematica and various papers on
ray tracing) and old postings on sci.optics as well that one can first
approximate the surface wih other surfaces with analytic intersections,
then use these as starting points for iterative algorithms.

What are good references for this problem? Books, review papers,
research papers?

Thanks in advance for any hint!

Giovanni

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

[Joseph Gwinn]

Post by JTS
Hi to all,
I have a quite general question on algorithms for ray-surface
intersections: which one is the best? (here I am joking a little bit).

This is like asking which automobile is best. Thi first question is what you
plan to use the automobile for.

Post by JTS
Let me give a few lines of context. I have played a little bit with
Goptical, trying out light concentration with a compound parabolic
concentrator, and the program misses many of the interceptions. Looking
in the source code, I see that for a generic surface Newton's method of
root finding is implemented (if I understood correctly: I was not able
to follow all of the details of the code).
I would like to experiment a bit with other intersection finding methods
- I have seen browsing the internet (e.g. the documentation for Optica,
the optical design program based on Mathematica and various papers on
ray tracing) and old postings on sci.optics as well that one can first
approximate the surface wih other surfaces with analytic intersections,
then use these as starting points for iterative algorithms.
What are good references for this problem? Books, review papers,
research papers?

There are many many good books on the design of optical systems, where the
math is laid out in great detail. Start out with geometric optics, which is
the basis of all such software. Larger and more expensive software will
venture into gaussian optics (for laser beams) and wave optics (holograms,
interference effects, et al).

Check out what textbooks the local universities are using to teach Optics.
But it may be best to take the course. There is a lot to learn.

The vendors of optical design software often have lists of good textbooks and
articles to read.

Optica and LensLab are still available and supported, but as you note these
require Mathematica:

.<http://www.opticasoftware.com/>

Joe Gwinn

[Giovanni]

On 2017-06-03 17:03, Joseph Gwinn wrote:

Hi,
first of all thanks much for answering. Point by point (as I see perhaps
I did not explain well enough what I want)

Post by Joseph Gwinn

Post by JTS
I have a quite general question on algorithms for ray-surface
intersections: which one is the best? (here I am joking a little bit).

This is like asking which automobile is best. Thi first question is what you
plan to use the automobile for.

Right! I did not resist joking on this - the question itself ("which one
is the best") was the joke as it is so general that it cannot be
answered. But maybe it was a joke that I only find funny ;-)

Post by Joseph Gwinn

Post by JTS
What are good references for this problem? Books, review papers,
research papers?

There are many many good books on the design of optical systems, where the
math is laid out in great detail. Start out with geometric optics, which is
the basis of all such software. Larger and more expensive software will
venture into gaussian optics (for laser beams) and wave optics

(holograms,

Post by Joseph Gwinn
interference effects, et al).
Check out what textbooks the local universities are using to teach Optics.
But it may be best to take the course. There is a lot to learn.

I have general knowledge of the subject; it comes from classes I took at
the University, plus some practice with simple cases, these were more
physical optics than geometrical optics but the basics of aberrations
theory where relevant. Now I became interested in this particular
problem - how to best find the ray-surface intersections. As I said in
the first post, I tested Goptical on the case of the compound parabolic
concentrator, and it does not find many intersections; I also own
LensLab (which I find a very nice program by the way) and it has the
same problem with this and other kind of surfaces - I do not own Optica,
and I guess that the more sophisticated routines of Optica should do better.

Writing an algorithm on my own for this - of the kind where one first
approximates a surface, like I said in the original post) would be a
good exercise in C++ (which I am learning) and maybe if it comes out
acceptably good I could even try to insert it into Goptical (this would
require much more understanding of C++ than I have now and quite a bit
of time, but let us not exclude this possibility a priori).

I have made a web search on intersection-finding algorithms and I have
also realized that there is a great deal: the following are among what I
found in the past days

Adamson, A., & Alexa, M. (2003). Approximating and Intersecting Surfaces
from Points. Eurographics Symposium on Geometry Processing. Retrieved
from
https://graphics.stanford.edu/courses/cs468-03-fall/Papers/alexa_surfintersect.pdf

Velho, L., Figueiredo, L. H. de, Gomes, J., De Figueiredo, H., & Gomes,
J. (1997). A Methodology for Piecewise Linear Approximation of Surfaces.
Journal of the Brazilian Computer Society, 3(3).


Now, evaluating references and figuring out what is the current standard
is one of the hard parts of technical work. Also, figuring out which one
is a sensible general algorithm that could solve a good number of
significant cases, even if it is not the state of the art. So that I
could aim at coding that algorithm rather than others which might
perform better but be much more complicated, for example. Sometimes
issues like these are discussed in good books (sometimes in good review
articles as well). So I am asking for some information on this.

[Joseph Gwinn]

Post by Giovanni
Hi,
first of all thanks much for answering. Point by point (as I see perhaps
I did not explain well enough what I want)

[snip]

Post by Giovanni

Post by Joseph Gwinn

Post by JTS
What are good references for this problem? Books, review papers,
research papers?

There are many many good books on the design of optical systems, where the
math is laid out in great detail. Start out with geometric optics, which is
the basis of all such software. Larger and more expensive software will
venture into gaussian optics (for laser beams) and wave optics (holograms,
interference effects, et al).
Check out what textbooks the local universities are using to teach Optics.
But it may be best to take the course. There is a lot to learn.

I have general knowledge of the subject; it comes from classes I took at
the University, plus some practice with simple cases, these were more
physical optics than geometrical optics but the basics of aberrations
theory where relevant. Now I became interested in this particular
problem - how to best find the ray-surface intersections. As I said in
the first post, I tested Goptical on the case of the compound parabolic
concentrator, and it does not find many intersections; I also own
LensLab (which I find a very nice program by the way) and it has the
same problem with this and other kind of surfaces - I do not own Optica,
and I guess that the more sophisticated routines of Optica should do better.
Writing an algorithm on my own for this - of the kind where one first
approximates a surface, like I said in the original post) would be a
good exercise in C++ (which I am learning) and maybe if it comes out
acceptably good I could even try to insert it into Goptical (this would
require much more understanding of C++ than I have now and quite a bit
of time, but let us not exclude this possibility a priori).

I have considerable undersatnding of Optica’s internals, and this is not
the place to start if you are not already an expert in both optics and
programming in Mathematica.

Use of C++ is a good idea, but resist the temptation to go full
object-oriented. Write the program twice - the first one will be a mess due
to all the mistakes. It’s faster and better to start over than to try
repair.

One designs the raytrace engine first, coevolving with the data structures
that describe the system being analyzed and the rays traversing that system.
This has to be designed for the greatest speed possible. Design from the
start to support non-sequential raytracing, as this is quite difficult to add
after the fact. Well, do this on the second version.

Post by Giovanni
I have made a web search on intersection-finding algorithms and I have
also realized that there is a great deal: the following are among what I
found in the past days
Adamson, A., & Alexa, M. (2003). Approximating and Intersecting Surfaces
from Points. Eurographics Symposium on Geometry Processing. Retrieved
from<https://graphics.stanford.edu/courses/cs468-03-fall/Papers/alexa_surfintersect
.pdf>.

There are lots of ways this is done in optical design software, governed by
tradeoffs between speed and complexity.

Post by Giovanni
Velho, L., Figueiredo, L. H. de, Gomes, J., De Figueiredo, H.,& Gomes,
J. (1997). A Methodology for Piecewise Linear Approximation of Surfaces.
Journal of the Brazilian Computer Society, 3(3).

One chooses the approach for describing surfaces for the correct combination
of accuracy (piecewise linear is not good enough for imaging optics, so
spheres and conics are used) and speed of intersection finding (usually a
two-step process, coarse then fine).

Another good source of ideas is the Computer Graphics rendering engines, such
as POV-Ray (Point Of View), which are used to generate photo-realisitic
“photographs” of things that never were.

.<http://www.povray.org/>

Post by Giovanni
Now, evaluating references and figuring out what is the current standard
is one of the hard parts of technical work. Also, figuring out which one
is a sensible general algorithm that could solve a good number of
significant cases, even if it is not the state of the art. So that I
could aim at coding that algorithm rather than others which might
perform better but be much more complicated, for example. Sometimes
issues like these are discussed in good books (sometimes in good review
articles as well). So I am asking for some information on this.

When I was programming a special-purpose raytracer in Mathematica to explore
a complex system of mirrors and retroreflectors, I used the algorithms from
the first volume of the “Handbook of Optics” from the Optical Society of
America (OSA).

Understand that implementation of optical design software (including ray
tracers) is a career, and one must read many books on optics and also on
numerical methods. But there is no harm in building a simple raytracer for
the experience, as a learning example.

Joe Gwinn

[JTS]

Post by Joseph Gwinn
Use of C++ is a good idea, but resist the temptation to go full
object-oriented. Write the program twice - the first one will be a mess due
to all the mistakes. It’s faster and better to start over than to try
repair.

I am thinking at the moment to write a much simpler program, that deals
with one surface only - with the aim of finding the surface-ray
intersection. I would like as a first target to improve on this

https://www.flickr.com/photos/***@N07/35040566376/in/album-72157682640175740/

(it is the result of Goptical) which - I think - should be doable. The
idea approximate/solve analytically/refine iteratively seems simple and
some parts of it are even easy to program *once that one has found the
correct approximations* (see in fact your comment later on sphere and
conics as best approximations for imaging optics). For the piecewise
linear approximation the first approach that comes to mind is
tessellating the plane perpendicular to the optical axis with triangles
and then using this tessellation as a starting point for the linear
approximation; then taking the closest intersection with any of the
resulting triangles as the starting point for refinement. I do not have
experience with this but intuitively it should work with many different
surfaces.
A refinement of this approach could be to approximate twice, once on one
side of the surface, once on the other side (I took this idea from the
Optica website too). In this way one is able to confine the
intersections and there is a way to make the refinement work (a
bisection will work except in "pathological" cases).
This method for equation solving seems powerful to me and I wonder if it
should be applicable to other cases beyond optics.

The second step could be to find intersections consistently for a large
set of different surfaces; but first step first - second only if it
continues to be fun.

Post by Joseph Gwinn
One designs the raytrace engine first, coevolving with the data structures
that describe the system being analyzed and the rays traversing that system.
This has to be designed for the greatest speed possible. Design from the
start to support non-sequential raytracing, as this is quite difficult to add
after the fact. Well, do this on the second version.

This is a much larger project, and not my plan at the moment.

Post by Joseph Gwinn
One chooses the approach for describing surfaces for the correct combination
of accuracy (piecewise linear is not good enough for imaging optics, so
spheres and conics are used) and speed of intersection finding (usually a
two-step process, coarse then fine).
Another good source of ideas is the Computer Graphics rendering engines, such
as POV-Ray (Point Of View), which are used to generate photo-realisitic
“photographs” of things that never were.
.<http://www.povray.org/>

Thanks for the infos. I will check the manual of POV-Ray and perhaps ask
some questions on the POV-Ray newsgroups once that my ideas are clearer.

Post by Joseph Gwinn

Post by Giovanni
Now, evaluating references and figuring out what is the current standard
is one of the hard parts of technical work. Also, figuring out which one
is a sensible general algorithm that could solve a good number of
significant cases, even if it is not the state of the art. So that I
could aim at coding that algorithm rather than others which might
perform better but be much more complicated, for example. Sometimes
issues like these are discussed in good books (sometimes in good review
articles as well). So I am asking for some information on this.

When I was programming a special-purpose raytracer in Mathematica to explore
a complex system of mirrors and retroreflectors, I used the algorithms from
the first volume of the “Handbook of Optics” from the Optical Society of
America (OSA).

I checked this quickly online and did see formulae for refraction and
ray transfer, but for intersection-finding it refers to additional
literature. Anyway: step by step.

Post by Joseph Gwinn
Understand that implementation of optical design software (including ray
tracers) is a career, and one must read many books on optics and also on
numerical methods. But there is no harm in building a simple raytracer for
the experience, as a learning example.
Joe Gwinn

Right :-)

[Joseph Gwinn]

Post by JTS

Post by Joseph Gwinn
Use of C++ is a good idea, but resist the temptation to go full
object-oriented. Write the program twice - the first one will be a mess due
to all the mistakes. It’s faster and better to start over than to try
repair.

I am thinking at the moment to write a much simpler program, that deals
with one surface only - with the aim of finding the surface-ray
intersection. I would like as a first target to improve on this
740/>
(it is the result of Goptical) which - I think - should be doable. The
idea approximate/solve analytically/refine iteratively seems simple and
some parts of it are even easy to program *once that one has found the
correct approximations* (see in fact your comment later on sphere and
conics as best approximations for imaging optics). For the piecewise
linear approximation the first approach that comes to mind is
tessellating the plane perpendicular to the optical axis with triangles
and then using this tessellation as a starting point for the linear
approximation; then taking the closest intersection with any of the
resulting triangles as the starting point for refinement. I do not have
experience with this but intuitively it should work with many different
surfaces.

The above curve is a parabolic surface, so one can solve directly for the
intersection point, with full precision. No ineration is needed. Likewise
sections of a sphere. Tesselation is not required at all, and is far more
trouble than direct solution.

.<https://math.stackexchange.com/questions/380576/find-the-point-of-
intersection-of-the-line-and-surface>

.<https://en.wikipedia.org/wiki/Intersection_(Euclidean_geometry)>

The main area where one uses tesselation (aside from computer graphics) is
design of light collectors and lighting systems, where one is collecting and
disytibuting light, but are not forming an image, and the tesselation comes
from the mechanical designs system being used to design the fixture.

A common approach is to find the intersection point (if an intersection
exists), then determine of the intersection point is within the physical
component - the ray may have missed the aperture.

Post by JTS
A refinement of this approach could be to approximate twice, once on one
side of the surface, once on the other side (I took this idea from the
Optica website too).

Where?

Post by JTS
In this way one is able to confine the
intersections and there is a way to make the refinement work (a
bisection will work except in "pathological" cases).
This method for equation solving seems powerful to me and I wonder if it
should be applicable to other cases beyond optics.

This is typically done when one is working with an aspherical optical
surface, for which no closed-form formula for the intersection with a line
exists. This came up in the context of nested deeply curved optical elements.
One makes a bounding box consisting of a cylinder and two sperical or conic
end-cap faces, with the aspheric optical surface between the two spheres or
conics (whichever is the tighter fit). This speeds the iteration by starting
very close to the optical surface.

Speaking of Optica (now LensLab), this may be
helpful:<http://www.opticasoftware.com/documentation/LensLab/LensLabWeb/Overvi
ew/overview.html>

Post by JTS
The second step could be to find intersections consistently for a large
set of different surfaces; but first step first - second only if it
continues to be fun.

To cut down on computations, the usual method is to surround each component
with a bounding box or a sphere, and first check which bounding box or sphere
the ray hits, and then solve the more exact equation within the found box or
sphere.

Post by JTS

Post by Joseph Gwinn
One designs the raytrace engine first, coevolving with the data structures
that describe the system being analyzed and the rays traversing that system.
This has to be designed for the greatest speed possible. Design from the
start to support non-sequential raytracing, as this is quite difficult to
add after the fact. Well, do this on the second version.

This is a much larger project, and not my plan at the moment.

Post by Joseph Gwinn
One chooses the approach for describing surfaces for the correct combination
of accuracy (piecewise linear is not good enough for imaging optics, so
spheres and conics are used) and speed of intersection finding (usually a
two-step process, coarse then fine).
Another good source of ideas is the Computer Graphics rendering engines,
such as POV-Ray (Point Of View), which are used to generate photo-realisitic
“photographs” of things that never were.
.<http://www.povray.org/>

Thanks for the infos. I will check the manual of POV-Ray and perhaps ask
some questions on the POV-Ray newsgroups once that my ideas are clearer.
Welcome. But be aware that POV-Ray approaches are not nearly accurate enough for raytracing an optical system that forms images.

Post by Joseph Gwinn

Post by Giovanni
Now, evaluating references and figuring out what is the current standard
is one of the hard parts of technical work. Also, figuring out which one
is a sensible general algorithm that could solve a good number of
significant cases, even if it is not the state of the art. So that I
could aim at coding that algorithm rather than others which might
perform better but be much more complicated, for example. Sometimes
issues like these are discussed in good books (sometimes in good review
articles as well). So I am asking for some information on this.

When I was programming a special-purpose raytracer in Mathematica to explore
a complex system of mirrors and retroreflectors, I used the algorithms from
the first volume of the “Handbook of Optics” from the Optical Society of
America (OSA).

I checked this quickly online and did see formulae for refraction and
ray transfer, but for intersection-finding it refers to additional
literature. Anyway: step by step.

Some references:

“General Ray-Tracing Procedure”, G.H. Spencer and M.V.R.K. Murty, JOSA
v.52, n.6, pages 672-678, June 1962. This one reference appears to be the
basis of many optical design raytrace packages.

ABCD Matrix: In “Optics”, 2nd edition, E. Hecht, Addison-Wesley 1974,
it’s discussed in section 6.2.1
Matrix Methods, pages 216-220. A classic book-length treatment is “Matrix
Methods in Optical
Instrument Design”, Willem Brouwer, Benjamin 1964. Another book, one that
actually uses the term
“ABCD”, is “Introduction to Matrix Methods in Optics”, A.Gerrard and
J.M.Burch, Wiley 1975,
republished by Dover in 1994. “Paraxial Matrix Methods” section 1.17 of
“General Principles of
Geometric Optics” by Douglas S. Goodman, Chapter 1 of the “Handbook of
Optics”, second edition,
Volume I, Optical Society of America, McGraw-Hill 1995.

“Analysis of an algorithm for fast ray tracing using uniform space
subdivision”, John G. Cleary and
Geoff Wyvill, The Visual Computer (1988) 4:65-83, v.4, n.2.

Post by JTS

Post by Joseph Gwinn
Understand that implementation of optical design software (including ray
tracers) is a career, and one must read many books on optics and also on
numerical methods. But there is no harm in building a simple raytracer for
the experience, as a learning example.

Right :-)>

What do you wish to do or learn with your ray tracer?

Goptical is a full-sized optical design tool for imaging systems, or at least
it will someday be.

Joe Gwinn

[JTS]

On 2017-06-04 20:59, Joseph Gwinn wrote:

(with snips here and there)

Thanks much for the list of references, a few of them interest me in
particular, I will get them.

Post by Joseph Gwinn

Post by JTS
I am thinking at the moment to write a much simpler program, that deals
with one surface only - with the aim of finding the surface-ray
intersection. I would like as a first target to improve on this
740/>
(it is the result of Goptical) which - I think - should be doable. The
idea approximate/solve analytically/refine iteratively seems simple and
some parts of it are even easy to program *once that one has found the
correct approximations* (see in fact your comment later on sphere and
conics as best approximations for imaging optics). For the piecewise
linear approximation the first approach that comes to mind is
tessellating the plane perpendicular to the optical axis with triangles
and then using this tessellation as a starting point for the linear
approximation; then taking the closest intersection with any of the
resulting triangles as the starting point for refinement. I do not have
experience with this but intuitively it should work with many different
surfaces.

The above curve is a parabolic surface, so one can solve directly for the
intersection point, with full precision. No ineration is needed. Likewise
sections of a sphere. Tesselation is not required at all, and is far more
trouble than direct solution.

I agree that for a paraboloid you can solve analytically, but there is a
block which I do not know how to circumvent. I have to insert the CPC as
a custom surface, then the program chooses the numerical intersections.
(by the way see the 3d image here:
https://www.flickr.com/photos/***@N07/34969900281)

But let us say that we solve the problem in this particular case
(although the CPC is not a quadric, without looking at the equations I
guess it from the fact that it is called CPC ... half joking here, but
it feels right; I am guessing that parabolae along different meridians
do not belong to the same quadric so that it has to be second order for
meridional rays only); it still remains open for more general surfaces -
and since I want to tace rays for more of these (see answer to your last
question) I need a ray-tracer that finds these intersections.

By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

Post by Joseph Gwinn

Post by JTS
A refinement of this approach could be to approximate twice, once on one
side of the surface, once on the other side (I took this idea from the
Optica website too).

Where?

I have dreamed about it. The reference would have been

http://www.opticasoftware.com/documentation/Rayica/PrinciplesOfRayica/4Customization/#.3.5

starting from the words "The problem is solved when a second, bigger
surface function is supplied to SurfaceApproximation.". I had
misinterpreted it as meaning we were supplying two approximations, one
external and one internal; instead it is only changing approximation. It
looked like a nice approach in my mind.
It seems from

Post by Joseph Gwinn
One makes a bounding box consisting of a cylinder and two sperical or conic
end-cap faces, with the aspheric optical surface between the two spheres or
conics (whichever is the tighter fit).

that in certain cases it makes sense?


Further

Post by Joseph Gwinn
Speaking of Optica (now LensLab), this may be
helpful:<http://www.opticasoftware.com/documentation/LensLab/LensLabWeb/Overvi
ew/overview.html>

Thanks for this. I have read it about one year ago, but I had forgotten
the name of the author :-)
By the way, reading it again I saw that in LensLab too the
approximate/solve analytically/iterate algorithm is applied, and I had
not realized it. In the small simulation of a CPC that I wrote one year
ago using LensLab several intersections are also missed (leading to a
jagged plot for the transmission-angle curve); I checked if the
SurfaceApproximation settings of Optica applied there too, but (as far
as I can remember) they do not. So I had concldued that no approximation
with a piecewise linear function was being made. By the way the missed
intersections appear in LensLab in another example as well, the "Black
hole", if one changes the intersection method using something else
instead of SurfaceRayIntersections->Solve.

These missed intersections are what motivated me to look for another
program (it is not completely out of the question to get Optica too,
given that LensLab is so nice).

Post by Joseph Gwinn
What do you wish to do or learn with your ray tracer?

The basics of nonimaging optics. I went through a couple of the
fundamentals (edge ray principle, flow lines, SMS 2D) and at least I
understood once the mechanisms (for the flow lines I have already
forgotten them!) - which means I am very very far away from
understanding the scope of the methods, that is for example is what kind
of problems does the SMS method solve that the edge-ray can't (talking
much in general).

Post by Joseph Gwinn
Goptical is a full-sized optical design tool for imaging systems, or at least
it will someday be.

As far as I can see right now
1) it is sufficient - from one side - for at least simple nonimaging
optics too, as it does nonsequential raytracing; which means in the
simple cases I am looking at, multiple bounces off the same element are
allowed. In the case of a sequential raytrace, we would make one bounce
(or a fixed number of bounces, if we list the same element several
times) and stop.
"Multiple bounces allowed" is how I understood "nonsequential
raytracing" applies to the CPC case:please correct me if I am wrong here

2) the intersections can be improved. In the spirit of free software, we
would not need to wait for the original author to do that himself; but I
have a rather long way to go before I can attempt it myself.

[JTS]

Post by JTS
By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

I got a hint for what is wrong between Goptical and the CPC, and
following the program execution I know now what is happening: at the
start value the CPC sagitta function evaluates to NaN (it has to happen
because of the way the CPC profile is defined). So I extended the
sagitta definition outside the aperture of the CPC by reflection (so to
have a smooth derivative at the aperture radius) and the program is
behaving much better:

https://www.flickr.com/photos/***@N07/34304612313

There are still a few rays for which the intersections are not found, I
need to figure out whether I made a mistake somewhere with my extended
function definition or it is the Newton method which is - in this case
really - not working for this surface.

[Mike S]

Post by JTS

Post by JTS
By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

I got a hint for what is wrong between Goptical and the CPC, and
following the program execution I know now what is happening: at the
start value the CPC sagitta function evaluates to NaN (it has to happen
because of the way the CPC profile is defined). So I extended the
sagitta definition outside the aperture of the CPC by reflection (so to
have a smooth derivative at the aperture radius) and the program is
There are still a few rays for which the intersections are not found, I
need to figure out whether I made a mistake somewhere with my extended
function definition or it is the Newton method which is - in this case
really - not working for this surface.

Interesting. Any chance you could post both functions here, if that's
not difficult, or asking for proprietary code?

[JTS]

Post by Mike S
Interesting. Any chance you could post both functions here, if that's
not difficult, or asking for proprietary code?

I started out from the equation of the CPC sagitta given in implicit
form by Welford and Winston, High Collection Nonimaging Optics (in the
edition I have, 1989, it is equation 4.6).

(r*cos(θ_max)+z*sin(θ_max))^2+2*a*r*(1+sin(θ_max))^2-a^2*(1+sin(θ_max))*(3+sin(θ_max))-2*a*z*cos(θ_max)*(2+sin(θ_max))
= 0

I solved for z as a function of r using Maxima, the relevant solution is

z=-(-2*a*cos(θ_max)+(r-a)*cos(θ_max)*sin(θ_max)+
sqrt((a^2-2*a*r)*sin(θ_max)^4+(4*a^2-4*a*r)*sin(θ_max)^3+(3*a^2-2*a*r+(a^2-2*a*r)*cos(θ_max)^2)*sin(θ_max)^2+(4*a^2-4*a*r)*cos(θ_max)^2*sin(θ_max)+4*a^2*cos(θ_max)^2))/(sin(θ_max)^2

I tried to simplify it using Maxima's facsum command, but I did not
achieve anything simpler (I do not have almost any experience with
algebra manipulations using Maxima)

then I set θ_max=%pi/16,a=50

With these parameters the aperture radius of the CPC is a little more
than 240.

The CPC looks like this:

https://www.flickr.com/photos/***@N07/34280163004

in order to get the extension, I set a new function, let us call it
z_extended(r), in the following way:

z_extended(r) = 2*z(240)-z(2*240 - r)

(mirroring with respect to the point 240, z(240)

the extended CPC looks like this

https://www.flickr.com/photos/***@N07/34991668131

but the aperture radius, set in Goptical at r = 240, limits it to only
the part which is the CPC. The sagitta looks like this:

https://www.flickr.com/photos/***@N07/35102724796

If interesting, I can post somewhere the Maxima notebook where I made
the calculations.

[Mike S]

Post by JTS

Post by Mike S
Interesting. Any chance you could post both functions here, if that's
not difficult, or asking for proprietary code?

I started out from the equation of the CPC sagitta given in implicit
form by Welford and Winston, High Collection Nonimaging Optics (in the
edition I have, 1989, it is equation 4.6).
(r*cos(θ_max)+z*sin(θ_max))^2+2*a*r*(1+sin(θ_max))^2-a^2*(1+sin(θ_max))*(3+sin(θ_max))-2*a*z*cos(θ_max)*(2+sin(θ_max))
= 0
I solved for z as a function of r using Maxima, the relevant solution is
z=-(-2*a*cos(θ_max)+(r-a)*cos(θ_max)*sin(θ_max)+
sqrt((a^2-2*a*r)*sin(θ_max)^4+(4*a^2-4*a*r)*sin(θ_max)^3+(3*a^2-2*a*r+(a^2-2*a*r)*cos(θ_max)^2)*sin(θ_max)^2+(4*a^2-4*a*r)*cos(θ_max)^2*sin(θ_max)+4*a^2*cos(θ_max)^2))/(sin(θ_max)^2
I tried to simplify it using Maxima's facsum command, but I did not
achieve anything simpler (I do not have almost any experience with
algebra manipulations using Maxima)
then I set θ_max=%pi/16,a=50
With these parameters the aperture radius of the CPC is a little more
than 240.
in order to get the extension, I set a new function, let us call it
z_extended(r) = 2*z(240)-z(2*240 - r)
(mirroring with respect to the point 240, z(240)
the extended CPC looks like this
but the aperture radius, set in Goptical at r = 240, limits it to only
If interesting, I can post somewhere the Maxima notebook where I made
the calculations.

Very nice work!

[JTS]

Post by Mike S

Post by JTS
but the aperture radius, set in Goptical at r = 240, limits it to only
If interesting, I can post somewhere the Maxima notebook where I made
the calculations.

Very nice work!

thanks. Since the ray-tracing with this
is still this

https://www.flickr.com/photos/***@N07/34304612313

I want to do some more work to figure out why some intersections are
still not found. I need a bit of time to do that, but I hope to be able
to post here what I am able to find out.


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

[JTS]

Post by JTS
in order to get the extension, I set a new function, let us call it
z_extended(r) = 2*z(240)-z(2*240 - r)
(mirroring with respect to the point 240, z(240)
the extended CPC looks like this

By the way: I realized that this definition incurs in a problem (at
least in Goptical), illustrated in

https://www.flickr.com/photos/***@N07/3522010623

and

https://www.flickr.com/photos/***@N07/34962796960


Steep rays seem to be reflected from empty space.

The reason is (I think, I did not verify it in detail) that the extended
sagitta, as defined, bends back for r larger than a certain value
(https://www.flickr.com/photos/***@N07/34962796960). The lagorithm
must be intersecting to the backbent part of the surface. It is possible
to change the definition to avoid the backbending (for example, periodic
with a shift, I am not going to enter into details); but - to me this
playing with the definition of the sagitta does not look like a very
useful technique in general, it should solve this problem for this
program only.

[JTS]

The correct link is

https://www.flickr.com/photos/***@N07/35220106231

[Joseph Gwinn]

Post by JTS

Post by JTS
in order to get the extension, I set a new function, let us call it
z_extended(r) = 2*z(240)-z(2*240 - r)
(mirroring with respect to the point 240, z(240)
the extended CPC looks like this

By the way: I realized that this definition incurs in a problem (at
least in Goptical), illustrated in
and

Actually<https://www.flickr.com/photos/***@N07/35220106231>.
.
One problem with the drawings is that one cannot tell the direction of
propagation by looking.
.

Post by JTS
Steep rays seem to be reflected from empty space.
The reason is (I think, I did not verify it in detail) that the extended
sagitta, as defined, bends back for r larger than a certain value
must be intersecting to the backbent part of the surface. It is possible
to change the definition to avoid the backbending (for example, periodic
with a shift, I am not going to enter into details); but - to me this
playing with the definition of the sagitta does not look like a very
useful technique in general, it should solve this problem for this
program only.

.
Yes. I see two problems.

First, there is no raycatcher to stop the ray from hitting the a surface
outside of its defined area or volume. Many surface equations are valid only
over a restricted region, and can be wildly wrong outside that region.

Also useful is a bounding box around the entire optical system being
analyzed, to intercept rays leaving the system.

Second, even if the equation is valid, the mathematical definition may extend
far beyond the actual aperture of the optical element.

Although I cannot tell from the two pictures, another common problem is when
the ray goes backward, because the found intersection is behind the origin of
the immediately previous intersection point, this being the origin point of
the ray segment one is trying to propagate.

It can be an amazing amount of coding effort to cover all the chinks in the
armor, to keep the rays from taking a wrong turn somewhere. When doing full
raytracing with a few hunderd rays, even very small chinks will soon be
found. One common cause is using bounding boxes for round components - here,
one does coarse-fine, where the box is coarse, and the actual aperture
(usually a circle) is the fine.
.

Joe Gwinn

[Joseph Gwinn]

Post by JTS
(with snips here and there)
Thanks much for the list of references, a few of them interest me in
particular, I will get them.

Post by Joseph Gwinn

Post by JTS
I am thinking at the moment to write a much simpler program, that deals
with one surface only - with the aim of finding the surface-ray
intersection. I would like as a first target to improve on this
0175740/>
(it is the result of Goptical) which - I think - should be doable. The
idea approximate/solve analytically/refine iteratively seems simple and
some parts of it are even easy to program *once that one has found the
correct approximations* (see in fact your comment later on sphere and
conics as best approximations for imaging optics). For the piecewise
linear approximation the first approach that comes to mind is
tessellating the plane perpendicular to the optical axis with triangles
and then using this tessellation as a starting point for the linear
approximation; then taking the closest intersection with any of the
resulting triangles as the starting point for refinement. I do not have
experience with this but intuitively it should work with many different
surfaces.

The above curve is a parabolic surface, so one can solve directly for the
intersection point, with full precision. No ineration is needed. Likewise
sections of a sphere. Tesselation is not required at all, and is far more
trouble than direct solution.

I agree that for a paraboloid you can solve analytically, but there is a
block which I do not know how to circumvent. I have to insert the CPC as
a custom surface, then the program chooses the numerical intersections.
But let us say that we solve the problem in this particular case
(although the CPC is not a quadric, without looking at the equations I
guess it from the fact that it is called CPC ... half joking here, but
it feels right; I am guessing that parabolae along different meridians
do not belong to the same quadric so that it has to be second order for
meridional rays only); it still remains open for more general surfaces -
and since I want to trace rays for more of these (see answer to your last
question) I need a ray-tracer that finds these intersections.

.
Well, I have not dug into the Goptical source code at all, but I think it
does real 3D vectors and 2D surfaces in 3D space. If so, there is no reason
to worry about meridians et all - it handles skew rays just the same.

Post by JTS
By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

.
The iterations are basically done by Newton’s method, so this ought to
work.

Post by JTS

Post by Joseph Gwinn

Post by JTS
A refinement of this approach could be to approximate twice, once on one
side of the surface, once on the other side (I took this idea from the
Optica website too).

Where?

I have dreamed about it. The reference would have been
<http://www.opticasoftware.com/documentation/Rayica/PrinciplesOfRayica/4Customi
zation/#.3.5>
starting from the words "The problem is solved when a second, bigger
surface function is supplied to SurfaceApproximation.". I had
misinterpreted it as meaning we were supplying two approximations, one
external and one internal; instead it is only changing approximation. It
looked like a nice approach in my mind.
It seems from

Post by Joseph Gwinn
One makes a bounding box consisting of a cylinder and two sperical or conic
end-cap faces, with the aspheric optical surface between the two spheres or
conics (whichever is the tighter fit).

that in certain cases it makes sense?

.
The discussion in section 3.5 arose from a discussion I had with Don Barnhart
back in the days of Optica, before it became the present LensLab. This is
easily ten years ago. (There was a predecessor LensLab, if memory serves.)

The issue was how to handle the elements of compound lenses like say a
telephoto lens with 20 elements, some very deeply curved and nested one
within another. A bounding box with planar end caps did not isolate the
elements well enough - a given bounding box could contain two or even three
lens separate elements.

Also, there was the issue of how to initialize the iterative search of
intersection - a plane didn’t work all that well for a steeply curved lens,
and we were worrying about aspheric lenses as well. So, there are two main
cases. Steeply curved, and nearly spherical surfaces. One example is a
schmidt corrector plate for a telescope. Or a maksukov telescope.

In all cases, if the initial approximation was a sphere or conic for which a
closed-form solution existed, the iteration could start very close to the
true intersection, and this would be both faster and -more importantly- far
more likely to converge successfully.

Post by JTS
Further

Post by Joseph Gwinn
Speaking of Optica (now LensLab), this may be
helpful:<http://www.opticasoftware.com/documentation/LensLab/LensLabWeb/Over
view/overview.html>

Thanks for this. I have read it about one year ago, but I had forgotten
the name of the author :-)
By the way, reading it again I saw that in LensLab too the
approximate/solve analytically/iterate algorithm is applied, and I had
not realized it. In the small simulation of a CPC that I wrote one year
ago using LensLab several intersections are also missed (leading to a
jagged plot for the transmission-angle curve); I checked if the
SurfaceApproximation settings of Optica applied there too, but (as far
as I can remember) they do not. So I had concluded that no approximation
with a piecewise linear function was being made. By the way the missed
intersections appear in LensLab in another example as well, the "Black
hole", if one changes the intersection method using something else
instead of SurfaceRayIntersections->Solve.

.
I’m not clear as to what was happening, but LensLab does generate piecewise
linear rays or ray trees. The path is linear in a given piece of dielectric
material (like glass), and bends abruptly at the surfaces between kinds of
media (kinds of glass, or at metal surfaces).

Post by JTS
These missed intersections are what motivated me to look for another
program (it is not completely out of the question to get Optica too,
given that LensLab is so nice).

.
All optical design systems do this. You need to debug the problem in LensLab
or Optica. Using a different bit of optical design software will not help.
Although you may have different problems, you will not have fewer problems.

Post by JTS

Post by Joseph Gwinn
What do you wish to do or learn with your ray tracer?

The basics of nonimaging optics. I went through a couple of the
fundamentals (edge ray principle, flow lines, SMS 2D) and at least I
understood once the mechanisms (for the flow lines I have already
forgotten them!) - which means I am very very far away from
understanding the scope of the methods, that is for example is what kind
of problems does the SMS method solve that the edge-ray can't (talking
much in general).

.
Ahh. This explains the acceptance of tesselated surfaces. However, tesselated
surfaces are slow to solve, so it’s usually more efficient if you can
describe most surfaceswith simple equations.

Post by JTS

Post by Joseph Gwinn
Goptical is a full-sized optical design tool for imaging systems, or at
least it will someday be.

1) it is sufficient - from one side - for at least simple nonimaging
optics too, as it does nonsequential raytracing; which means in the
simple cases I am looking at, multiple bounces off the same element are
allowed. In the case of a sequential raytrace, we would make one bounce
(or a fixed number of bounces, if we list the same element several
times) and stop.
"Multiple bounces allowed" is how I understood "nonsequential
raytracing" applies to the CPC case:please correct me if I am wrong here.

.
Depends on how Goptical defines things. To be pedantic, sequential raytracing
allows any number of bounces, but they must be specified in advance, and one
can enter the same surface multiple times. But they probably mean non
sequential raytracing, where one always specifies the maximum allowed number
of bends in the ray (one bend to a traversed surface), to prevent infinite
loops. In practice, the ray weakes a bit on each bend, and eventually becomes
too weak to matter - this is also used to prune rays. Another way to prune is
to note that the ray has altogether departed the system under analysis.

Post by JTS
2) the intersections can be improved. In the spirit of free software, we
would not need to wait for the original author to do that himself; but I
have a rather long way to go before I can attempt it myself.

Well, yes, but there is no harm in trying - there is nothing to lose. Just
set up an isolated testbed, and start to play with the critical part of the
intersection code, and see what happens. It will fail many times, especially
at first, but will do no damage. So just try again, and learn at every step,
untill it all becomes clear.

Joe Gwinn

[JTS]

Am 07.06.2017 um 05:36 schrieb Joseph Gwinn:

(snipping a bit)

Post by Joseph Gwinn

Post by JTS
But let us say that we solve the problem in this particular case
(although the CPC is not a quadric, without looking at the equations I
guess it from the fact that it is called CPC ... half joking here, but
it feels right; I am guessing that parabolae along different meridians
do not belong to the same quadric so that it has to be second order for
meridional rays only); it still remains open for more general surfaces -
and since I want to trace rays for more of these (see answer to your last
question) I need a ray-tracer that finds these intersections.

.
Well, I have not dug into the Goptical source code at all, but I think it
does real 3D vectors and 2D surfaces in 3D space. If so, there is no reason
to worry about meridians et all - it handles skew rays just the same.

Here I still insist that there is a difference.
1) the CPC is a quadric along the meridians
1a) if we were tracing only meridian rays, we could find the
intersections analytically
2) the CPC is not a quadric in 3-dimensional space (I guess it is a quartic)
2a) we need an iterative algorithm to find the intersections (unless we
are going to use the solutions for a 4th degree equation - I am not
going to do that)

Post by Joseph Gwinn

Post by JTS
By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

.
The iterations are basically done by Newton’s method, so this ought to
work.

So far it has not worked
(https://www.flickr.com/photos/***@N07/34304612313). It can be
because I made a mistake somewhere (possible) or because the starting
point for the rays where the algorithm fails is not a good one
(possible) or because the algorithm is not so suited for this kind of
surface (I am not inclined towards this at the moment, it looks too
smooth and nice: and some failing intersections are in points of the
surface where the slope looks reasonable; but it is alo possible).

On the rest (the LensLab/Optica solution for the CPC) I need to do some
work before I'll be able to discuss further (which would be interesting
at least for myself!).

For this on the opposite

Post by Joseph Gwinn

Post by JTS
2) the intersections can be improved. In the spirit of free software, we
would not need to wait for the original author to do that himself; but I
have a rather long way to go before I can attempt it myself.

Well, yes, but there is no harm in trying - there is nothing to lose. Just
set up an isolated testbed, and start to play with the critical part of the
intersection code, and see what happens. It will fail many times, especially
at first, but will do no damage. So just try again, and learn at every step,
untill it all becomes clear.

This is good advice and thanks for it. My habit (very vaguely speaking)
is to try and udnerstand things a bit in general and then try an apply
the understanding to a particular case. But I could follow for once the
road that you suggest. If I will reach an acceptable understanding of if
and how the intersection-finding algorithm can be improved, I will try
to implement that in Goptical.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

[Joseph Gwinn]

Post by JTS
(snipping a bit)

Post by Joseph Gwinn

Post by JTS
But let us say that we solve the problem in this particular case
(although the CPC is not a quadric, without looking at the equations I
guess it from the fact that it is called CPC ... half joking here, but
it feels right; I am guessing that parabolae along different meridians
do not belong to the same quadric so that it has to be second order for
meridional rays only); it still remains open for more general surfaces -
and since I want to trace rays for more of these (see answer to your last
question) I need a ray-tracer that finds these intersections.

.
Well, I have not dug into the Goptical source code at all, but I think it
does real 3D vectors and 2D surfaces in 3D space. If so, there is no reason
to worry about meridians et all - it handles skew rays just the same.

Here I still insist that there is a difference.
1) the CPC is a quadric along the meridians
1a) if we were tracing only meridian rays, we could find the
intersections analytically
2) the CPC is not a quadric in 3-dimensional space (I guess it is a quartic)
2a) we need an iterative algorithm to find the intersections (unless we
are going to use the solutions for a 4th degree equation - I am not
going to do that)

Well, we’d have to decode the code, but if one is doing the full 3D
raytracing approach, there is no distinction between tangental, sagittal, or
skew rays. These distinctions arose when computation was difficult and slow,
so people took any simplification they could. Tangental and sagittal are
special cases of skew rays No longer necessary.

Post by JTS

Post by Joseph Gwinn

Post by JTS
By the way I have written up this afternoon the Newton method for
ray-curve intersection (one dimensional and without any refinement) in
Matlab and I hope to get an insight soon of where is that the ray
tracing of the CPC fails (above linked image).

.
The iterations are basically done by Newton’s method, so this ought to
work.

So far it has not worked
because I made a mistake somewhere (possible) or because the starting
point for the rays where the algorithm fails is not a good one
(possible) or because the algorithm is not so suited for this kind of
surface (I am not inclined towards this at the moment, it looks too
smooth and nice: and some failing intersections are in points of the
surface where the slope looks reasonable; but it is alo possible).

It will be a mistake somewhere. Bad starting point is a common design mistake
as well. Easy to do.

I’d set things up so you can slow the ray trace down such that you can see
each internal step, one tiny step at a time, when clicking a button.

Post by JTS
On the rest (the LensLab/Optica solution for the CPC) I need to do some
work before I'll be able to discuss further (which would be interesting
at least for myself!).
For this on the opposite

Post by Joseph Gwinn

Post by JTS
2) the intersections can be improved. In the spirit of free software, we
would not need to wait for the original author to do that himself; but I
have a rather long way to go before I can attempt it myself.

Well, yes, but there is no harm in trying - there is nothing to lose. Just
set up an isolated testbed, and start to play with the critical part of the
intersection code, and see what happens. It will fail many times, especially
at first, but will do no damage. So just try again, and learn at every step,
untill it all becomes clear.

This is good advice and thanks for it. My habit (very vaguely speaking)
is to try and udnerstand things a bit in general and then try an apply
the understanding to a particular case. But I could follow for once the
road that you suggest. If I will reach an acceptable understanding of if
and how the intersection-finding algorithm can be improved, I will try
to implement that in Goptical.

I find it best to do both at the same time - each becomes sterile very soon,
but when doing both approaches in alternation, each refreshes the other.

Joe Gwinn

[JTS]

Post by Joseph Gwinn

Post by JTS
So far it has not worked
because I made a mistake somewhere (possible) or because the starting
point for the rays where the algorithm fails is not a good one
(possible) or because the algorithm is not so suited for this kind of
surface (I am not inclined towards this at the moment, it looks too
smooth and nice: and some failing intersections are in points of the
surface where the slope looks reasonable; but it is alo possible).

It will be a mistake somewhere. Bad starting point is a common design mistake
as well. Easy to do.
I’d set things up so you can slow the ray trace down such that you can see
each internal step, one tiny step at a time, when clicking a button.

Working on it. Hopefully I can figure it out! If the solution is at
least vaguely interesting I will post it here. Thanks for the rest.

For the part of the discussion on the tangential/sagittal rays on the
CPC it is possible that we got lost in the exchange. But it is not a
crucial point.