Пересечение луча, падающего на оптическую поверхность с поверхностью.

[Alexey_Smirn]

Господа!

Пишу программу трассировки лучей через оптическую поверхность.

У  меня к Вам просьба на миллион долларов! Шутка. Но, тем не менее, мой  светлый разум без помощи Вашего светлого разума данную задачу решить не может.

Итак, формулировка:

Есть система координат 0X, 0Y, 0Z.

В этой системе координа задаются вектора с параметрами (Alpha, Beta, Ro), где Ro - длина вектора, угол Alpha отсчитавается в плоскости X0Y, от оси 0X в сторону оси 0Y, 0=<Alpha<=2*Pi. Угол Beta отсчитывается от оси 0Z, 0-<Beta<=2*Pi.

В системе координат (Alpha, Beta, Ro) задана поверхность. которая являет из себя тело вращения вокруг оси 0Z, образованное коническим сечением (круг, эллипс, парабола, гипербола).
Данная поверхность задается в виде:

                              Ro(Alpha,Beta) :=FOpticalSurfaceParameter/(1.0 + Sqrt(FOpticalSurfaceEccentricity)*Cos(dBeta)):

                          где FOpticalSurfaceParameter  :=Abs(FOpticalSurfaceCurveRadius) * (1.0 + Sqrt(FOpticalSurfaceEccentricity));
                              FOpticalSurfaceCurveRadius - радиус касательной окружности к данному коническому сечению
                                  FOpticalSurfaceEccentricity - квадрат эксцентриситета данного конического сечения.
                       Центр конического сечения совпадает с точкой 0 системы координат (Alpha, Beta, Ro) и, соответственно, (X,Y,Z)

Имеется источник света, определяемый друмя векторами:
1)DistanceVector(Alpha,Beta,Ro) - вектор, направленный из точки 0 в точку, откуда исходит излучение. Он определяет направление на источник излучения и расстояние до него.
2)LightVector(Alpha,Beta,Ro) - вектор единичной длины, который определяет истинное направление лучей света, которые исходят из точки, определенной вектором DistanceVector.

Нужно определить радиус вектор точки указанной выше поверхности, с которой произойдет пересечение продолжения вектора LightVector, т.е., точку (Alpha, Beta, Ro) поверхности, на которую попадет световой луч, описанный векторами DistanceVector и  LightVector.

Я долго думал, и вот что придумал.
1)Радиус-Вектор точки пересечения поверхности и светового луча, вектора  DistanceVector и  LightVector находятся в одной плоскости, т.е. нормализованное (с длиной, равной 1) векторное произведение указанного радиусвектора и вектора DistanceVector должно быть равно векторному произведению (опять же, нормализованному) векторов DistanceVector и  LightVector.
2)Все эти три вектора образуют плоский треугольник, углы между ними получаются из скалярного произведения указанных выше векторов.
3)Ну и последнее условие. Длина искомого радиусвектора при найденном значении Alpha и Beta должна соответствовать длине, вычисленной из формулы, которой данная поверхность описывается. Длину этого радисвектора можно получить из плоского треугольника, образованного этим вектором и векторами DistanceVector и  LightVector.

Вот такие мысли. Но дальше формализация не пошла.

Я был бы очень благодарен за помошь в решении этой задачи.

С уважением, Алексей.

[Алексей Юдин]

"Не отвлекайтесь на ерунду, Ватсон, ###### ! "
Есть куча библиотек численных методов - возьми и юзай.
GSL, NAG и т. д. (смотря чё пишешь).

[Alexey_Smirn]

Ребята!

 Спасибо за ответы.А теперь - по существу.

То, что есть численное, приближенное решение - я и так знаю. Уже придумал. Но, это долго и некузяво, как-то.

Про то, что есть библиотеки - говорить не стоит. Во-первых, я этот впрос исследовал, а во-вторых, пишу я программу универсальную, которую можно будет откомпилить и в Виндах, и в Полуоси и в Линуксе. Библиотеки мне в этом случае не помогут.

С уважением, Алексей.

[Pavel_Boboshkin]

Я тоже пишу подобную программу. Занимался этим еще с 1986 года (с перерывами). Только я использую не полярные а декартовы координаты. В начале использовал свои формулы, затем мне посоветовали книгу Михельсона "Оптические телескопы и методы их расчета". Там есть глава, посвященная как раз расчету хода луча через оптическую поверхность. Искать надо формулы Федера. Они позволяют аналитически (напрямую, а не путем последовательных приближений) найти точку пересечения луча с повержностью (сферой или коникоидом) , а для остальных асферик - итерационно. Кстати, разница в быстродействии аналитического и итерационного методов почти незаметна.
Вообще, по моему для решения задачи нахождения пересечения прямой и коникоида достаточно и школьных знаний (плюс надо знать вид уравнения конического сечения - аналитическая геометрия, 1-й курс) . Задача сводится к решению квадратного уравнения, но требует большой внимательности. Надо учитывать знаки радиусов и величины e^2-1. У меня , помню, часто вылазил не тот корень кв. уравнения или вообще получался дискриминант <0.

[Алексей Юдин]

А как глубокоуважаемый сэр собирается решать уравнения >4 степени аналитически    Они этого не любят   .  Вообще-то уже из соображений простоты и однородности следует юзать только ЧМы. Пара лишних итераций на пересечение - разумная цена.
Насчёт либ - так именно из соображений мультиплатформенности их и надо юзать. GSL, например.
Вопросы оптимизации и анализа - вот ключевая задача.
Это и отличает многокилобаксовый рейтрейсер от недельной развлекаловки. А изобретать велосипед не надо. Если вы  сами реализуете все нужные ЧМы, то это всё будет в течение долгого времени весьма глючно и тормозно, это отдельный большой проект. Возьмите вылизанную библиотеку и не мучайтесь.

[Ernest]

Все это очень разумно - библиотеки для того и пишут, чтобы их использовать.

Но вот в реальной практике, оптические пакеты довольно быстро обрастают indoor-писанными численными методами, поскольку всегда оказывается, что универсальные численные методы весьма тяжеловесны, имеют неудобный интерфейс, работают слишком медленно и требуют много дополнительной памяти.

Метод Ньютона для нахождения пересечения с поверхностью высшего порядка - не бог весть что, можно и самому быстренько наваять. Куда более сложные ЧМ (оптимизации, к примеру) приходится писать самому. Другое дело матричные преобразования - в большинстве своем библиотечные функции могут быть использованы как есть.

[Alexey_Smirn]

Ну, хорошо!

 А как я под Полуосью буду эти библиотеки использовать? Ведь не выйдет... А это - практически оновная моя рабочая система.

Про метод Ньютона. Ув. Эрнест, огромное спасибо, - но можно по подробнее? Сыылку в Интренете или наименование книги - попробую поискать.

С уважением, Алексей.

[Ed_Trygubov]

"Сыылку в Интренете или наименование книги - попробую поискать."



Зачем мучать "загривок"...
Всё уже давно придумано.
Рекомендую классный учебник:
С.А. Родионов "Автоматизация проектирования оптических систем",  Машиностроение, где-то 1986 год.
В ней описание ОС и все численные методы включая оптимизацию - как на ладони.

Желаю успеха.

[Agas]

Совершенно верно: Родионов С.А. Автоматизация проектирования оптических систем. Л.: Машиностроение, 1982. 270 с.
И более фундаментальный труд:  Слюсарев Г.Г.  Методы расчета оптических систем. Л.: Машиностроение, 1969. 672 с.
Там есть и метод Ньютона, и его модификации и многое другое…

Это все конечно интересно, но из своего опыта написания оптических программ могу сказать что все эти ЧМ и вообще мат.анализ занимают относительно небольшой объем работы над программой. А большую часть занимает разработка и отладка сервиса (если конечно программа не предназначена только для собственного использования). Вот уж совершенно рутинная, тупая работа, но без нее нормальную программу, с которой реально можно было бы работать, к сожалению не создашь.  

[Alexey_Smirn]

Ребята!

За литературу - спасибо!  Буду теперь ее выискивать.

А вот про интерфейс - не извольте беспокоиться! Как энджин напишу - выложу бету куда-нибудь, вместе и обсудим.

У меня есть определенный опыт в общении с эндюзером. Есть и мысли по поводу интерфейса.

За написание программы я решил взяться, посмотрев на существующие. Ну не устраивает меня такой интерфейс, как в Земаксе и в  ОСЛО!!! Мне он неудобен. Я хочу Даг-енд-дроп, мышкой больше, чем коммандной строкой.

Предполагается сделать внешний вид и функциональность программы близкой к внешнему виду и функциональности Borland Delphi. Т.е., будет линейка заранее заготовленных оптических компонентов (мениски, двояковыпуклые или двояковогнутые линзы, плосковыпуклыеи плосковогнутые линзы, различные зеркала и т.д.) которые можновыбрать и положить в проект. Дальше уже параметры самого оптического компонета можно менять (или мышкой или путем заполнения соотв. формы).

Кроме линейки "простых" оптических элементов будут и сложные - линза Манжена, двух и трехлинзовые системы, "перископы" и "монокли" и т.д.

С уважением, Алексей.

[Дмитрий Маколкин]

Ребята!
...
Предполагается сделать внешний вид и функциональность программы близкой к внешнему виду и функциональности Borland Delphi. Т.е., будет линейка заранее заготовленных оптических компонентов (мениски, двояковыпуклые или двояковогнутые линзы, плосковыпуклыеи плосковогнутые линзы, различные зеркала и т.д.) которые можновыбрать и положить в проект. Дальше уже параметры самого оптического компонета можно менять (или мышкой или путем заполнения соотв. формы).

Кроме линейки "простых" оптических элементов будут и сложные - линза Манжена, двух и трехлинзовые системы, "перископы" и "монокли" и т.д.

С уважением, Алексей.

Т.е., если я правильно понял, описание оптической системы будет не через последовательное прохождение светом через набор оптических поверхностей, а с помощью описания объектов? А как тогда будут передаваться склейки? В обычных программах склееный дублет описывается тремя поверхностями и двумя промежутками, а тут как?

[Ernest]

>Рекомендую классный учебник: С.А. Родионов "Автоматизация проектирования оптических систем"

Книга для пишущих самопальные оптические САПРы самая подходящая, хотя и немного устарела. Мы ее называли "Зеленой Библией". Я даже успел иллюстрации к ней порисовать . А вот автор недавно умер - мир его праху. Но, сказать по чести, ее содержание настолько же отличается от алгоритмического содержания приличной программы для расчета оптики, как букварь от "Войны и Мира" это при том, что она наиболее полная и лучшая по качеству изложенных идей в отечественной литературе.

>Это все конечно интересно, но из своего опыта написания оптических программ могу сказать что все эти ЧМ и вообще мат.анализ занимают относительно небольшой объем работы над программой.

Мой опыт свидетельствует об обратном. В ОПАЛ-е объем математической части всегда превосходил GUI (при том что этот пакет успешно работал на десятке разных платформ). Не говоря уже об разнице в качестве и стоимости затраченного времени на разработку графической и оптической частей. Обычно графикой заведовали не способные на другое студенты в свободное от учебы время. В то время как оптическую часть (включая специализированные ЧМ) писали научные сотрудники в течение многих лет.

Хотя все зависит от того, что вкладывать в понятие "оптические алгоритмы" и как решать юзеровский интерфейс. Если вся оптика - это тупой ray tracing, а начинать проектирование апликации с рисование такой благостной картинки:

> Предполагается сделать внешний вид и функциональность программы близкой к внешнему виду и функциональности Borland Delphi. Т.е., будет линейка заранее заготовленных оптических компонентов (мениски, двояковыпуклые или двояковогнутые линзы, плосковыпуклыеи плосковогнутые линзы, различные зеркала и т.д.) которые можновыбрать и положить в проект. Дальше уже параметры самого оптического компонета можно менять (или мышкой или путем заполнения соотв. формы).

то, пожалуй, действительно 90% сил будет потрачено на программирование эвентов и борьбу с графическим контекстом.

Но кто может знать заранее, может что путное и выйдет.

[Agas]

Мой опыт свидетельствует об обратном. В ОПАЛ-е объем математической части всегда превосходил GUI (при том что этот пакет успешно работал на десятке разных платформ). Не говоря уже об разнице в качестве и стоимости затраченного времени на разработку графической и оптической частей. Обычно графикой заведовали не способные на другое студенты в свободное от учебы время...

Может в том числе и поэтому, теперь все считают на ZEMAX и OSLO?  
 А  OPAL, где он, опал?  

[Ed_Trygubov]

"А  OPAL, где он, опал? "

Я как-то слышал, что те кто написал отечественный "ОптКом" в 1989-1990 году(уникальную для того времени вещицу, честно говоря Земакс в то врямя просто отдыхал...) уехали в Штаты и подняли Земакс до его настоящего уровня.
Может кто знает подробности?

С ув. Эд

[Alexey_Smirn]

Уважаемый Дмитрий Маколкин!

Оптические элементы описываются как соскупности оптических поверхностей, рассояния между ними и типа преломляющего материала.

Написаны следующий классы:
1)Оптический материал (имеет уравнение, описывающие лучепреломление, как одну из функций - 'Герцбергера(Herzberger)','Зелмейера(Sellmeier)','Конради(Conrady)','Шотта (Schott)','Резника', )
2)Оптическая поверхность - имеет радиус кривизны, квадрат эксцентриситета, диаметр и тип поверхности - отражающая или преломляющая.
3)Оптический элемент (имеет 2 отпические поверхности, ссылку на левый и на правый отпический элемент, ссылку на класс оптического материала, толщину, расстояние от центра оптического элемента до некоторой фиксированной точки, которая является точкой пересечения фокальной плоскости и оптической оси системы) Фокальная плоскость задается предварительно, рассматривается для случая прохождения через систему линз лучей от бесконечно удаленного предмета. Фактически, фокальная плоскость в данном смысле задается в терминах "рабочий отрезок", т.е., фиксируется минимальное расстояние от последнего оптического элемента до фокальной плоскости.
4)Оптическая система - как совокупности оптических элементов.

В данной схеме ход лучей будет определяться трассировкой лучей через оптическую систему в целом. Отдельные, заранее заготовленные оптические элементы нужны для таких невежд, как я - чтобы быстрее начать работу.

В таком контексте склейка описывается как два(или более) отпических элемента, у которых в структуре заполненны поля взаимных ссылок (левое или правое, или оба).

С уважением, Алексей.

[Дмитрий Маколкин]

...
Написаны следующий классы:
...
С уважением, Алексей.

С большим интересом буду следить за развитием программы, обязательно сообщите о первой бета-версии...
Записываюсь в бета-тестеры прямо сейчас!

[Alexey_Smirn]

Уважаемый Господа!

Я пидумал аналитическое решение той самой задачи, которую я ставил перед Вами.

Итак.

Рассмотрим плоский треугольник, образованный
1)Радиус-вектором DistanceVector (который определяет направление на источник света и расстояние до него)
2)Радиус-вектором LightVector (который определяет направление самого луча света)
3)Радиус-вектором , который указывает на точку пересечения продолжения луча света, определяемого векторами DistanceVector и LightVector с поверхностью. Назовем его CollisionVector.

Поверхность, как мы помним, - коническое сечение, заданное в сферических координатах в конечном счете через касательную окружность и квадрат эксцентриситета.

Итак, в данном треугольнике нас, в конечном счете интересует угол между CollisionVector и LightVector. Т.е., мы должны найти такую величину данного угла, чтобы продолжение луча света, определяемого векторами DistanceVector и LightVector пересекалось с поверхностью. Назовем его CollisionAngle.

Этот угол легко пересчитывается в совокупность углов Alpha и Beta исходной системы координат по формулам сферической тригонометрии. Вывод приводить не буду - он элементарен.

Наш CollisionVector на самом деле состоит из друх векторов - собственно радиусвектора поверхности при данной величине (Alpha, Beta), как функии от CollisionAngle и некой добавки(DeltaVector). При углах, меньших, чем искомый - величина этой добавки будет отлична от нуля.

Итак, всего-то.

Выражаем эту добавку аналитически:

DeltaVector(CollisionAngel):= DistanceVector + LightVector(CollisionAngle) -  RadiusVector(CollisionAngle).

где LightVector(CollisionAngle) - сторона плоского треугольника, образованная на векторе LightVector. Длина этой стороны зависит от угла CollisionAngle и высчитывается из простейших тригонометрических формул из длины стороны, образованной на векторе DistanceVector.

RadiusVector(CollisionAngle) - радиус-вектор поверхности, заданной в координатах (Alpha, Beta), который в свою очередь, высчитываютя как указанно выше из формул сферичмской тригонометрии и зависят от угла CollisionAngle. Правильнее было бы написать RadiusVector(Alpha(CollisionAngle), Beta(CollisionAngle)) - но в данной ситуации это ненаглядно.

Нам необходимо найти минимум функции. описывающей DeltaVector(CollisionAngel). Этот минимум - один. В нем в нуль обращается как сама функция, так и ее первая производная. Следите  за моей мыслью?  

Дифференцируем функцию DeltaVector(CollisionAngel) по CollisionAngle и ищем единственный корень.

Покритикуйте такое решение!

С уважением, Алексей.
P.S. Сколько не смотрел, не смог увидеть уравнений со степенью большей двойки.

[Ernest]

Может в том числе и поэтому, теперь все считают на ZEMAX и OSLO?  
 А  OPAL, где он, опал?

Кто все? Вы видели в России лицензионные ZEMAX или OSLO? Так что на нашем рынке и эти фирмы долго-бы не продержались. ОПАЛ появился в начале 70-х (!) и развивался по заказу вояк. Когда они перестали платить (конец 80-х) кончился и ОПАЛ. ОПАЛ был настолько сильно ориентирован на отечественные оптические стандарты (в том числе по обозначениям, системам координат, каталогам стекол, системам допусков и т.д.), что конкуренцию на западном рынке выдержать не мог. Да никто серьезно его и не продвигал (дитя оказалось в какой то момент без родителей).

Что касается интерфейса, то в конце 80-х я имел удовольствие участвовать в конференции по оптическим CAD/CAM и были там ребята из Kidger optics, Oslo, Zemax со своими продуктами. На тот момент они переживали кризис жанра - переходили с Unix-а на ПК. Графика была в самом зачаточном состоянии, интерфейс командной строки и цифровые листинги на 5-6 экранов. В то время как у ОПАЛа была полностью графическая оболочка.

Не в графике дело... Может Вы знаете какой-нибудь отечественный программный наукоемкий продукт, который котируется на Западе и у нас?

[Ernest]

Поверхность, как мы помним, - коническое сечение, заданное в сферических координатах в конечном счете через касательную окружность и квадрат эксцентриситета.

Пересечение произвольного луча и поверхности вращения второго порядка - действительно находится аналитически - см. литературу.

Только, вроде, выше шла речь о поверхности вращения высшего порядка. Там без ЧМ не обойтись.

[Alexey_Smirn]

Уважаемый Ernest!

Я нашел аналитическое решение задачи, которую сам и поставил. В данном случае, рассматривается поверхность, заданная в сферических координатах, в конечном случае через радиус кривизны и квадрат эксцентриситета.

При данно задании поверхности она зависит только от координаты Beta, т.к. является поверхностью вращения.

Однако, предложенное решение, которое я таки довел до логического конца (полный вывод я могу представить сюда) может быть распространено и на любые другие поверхности. которые имеют однозначно определенный способ задания в сферических координатах. В том числе, и на поверхности высших порядков.

С уважением, Алексей.