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

[vdom]

Думаю, что вам будет интересна статья:
Родионов С.А. Об описании оптических поверхностей в программах расчета оптических систем на ЭВМ. Изв. вузов. Приборостроение. - 1978 - Т.XXI - №5 - С. 105-109. (http://aco.ifmo.ru/rodionov/articles/rsa_1978_01.pdf)
Здесь (http://aco.ifmo.ru/rodionov/rus_articles.html) есть и другие работы этого автора.
Кроме работ Федера, на которые ссылается Родионов, по этому вопросу много писал Гопкинс. В частности H.H.Hopkins Calculation of the aberrations and image assessment for a general optical system. Optica acta, 1981, vol. 28, no. 5, 667-714. В электронном виде не встречал. Придется покопаться в библиотеке.

[Agas]

Кто все? Вы видели в России лицензионные ZEMAX или OSLO?

Я имел в виду солидные, уважающие себя фирмы, например такие как НПЗ или Красногорск, которые, я знаю точно, используют лицензионный софт. Кстати, сам я тоже считаю на лицензионном ZEMAХ-е.  

ОПАЛ появился в начале 70-х (!) и развивался по заказу вояк. Когда они перестали платить (конец 80-х) кончился и ОПАЛ. ОПАЛ был настолько сильно ориентирован на отечественные оптические стандарты (в том числе по обозначениям, системам координат, каталогам стекол, системам допусков и т.д.), что конкуренцию на западном рынке выдержать не мог.

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

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

Ну почему обязательно на Западе, а у нас, что продавать нельзя? Я на примере нашей фирмы могу сказать, что если бы нам пришлось выбирать между ZEMAХом и ОПАЛом, выбор был бы сделан в пользу ОПАЛа, но ведь его же нет! И я уверен, что аналогичный выбор сделали бы не только мы. А так, приходится, матерясь и проклиная этих америкосов юзать Zemaх, поневоле вспоминая старый добрый ОПАЛ, в котором все было так удобно и понятно!

[Ernest]

>Ну почему обязательно на Западе, а у нас, что продавать нельзя? Я на примере нашей фирмы могу сказать, что если бы нам пришлось выбирать между ZEMAХом и ОПАЛом, выбор был бы сделан в пользу ОПАЛа, но ведь его же нет! И я уверен, что аналогичный выбор сделали бы не только мы. А так, приходится, матерясь и проклиная этих америкосов юзать Zemaх, поневоле вспоминая старый добрый ОПАЛ, в котором все было так удобно и понятно!

Велкам!
Вот этот e-mail до сих пор жив opal@aco.ifmo.ru и ОПАЛ-ом в своем отечестве еще торгуют. Хотя, думаю, разработка законсервирована на уровне десятилетней давности.

[Ernest]

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

Показывайте! Порядок задачи не должен меняеться от преобразования координат. То есть если нет общего вида аналитического решения в Гауссе, не должно быть и в сферических координатах - тем более интересно, что у Вас получилось.

[Goodman]

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

Предполагается сделать внешний вид и функциональность программы близкой к внешнему виду и функциональности Borland Delphi.

Есть такая программа Optikwerks http://64.225.36.28/. Интерфейс как раз построен на drag-and-drop. Есть не очень функциональная демка, но достоинства и недостатки такой организации интерфейса оценить можно.

[Alexey_Smirn]

Уважаемый Ernest!

Как я уже писал, из плоского треугольника, образованного вектором на источник света(DistanceVector), вектором, совподающим по направлению с вектором луча света(LightVector) и радиусвектором поверхности(RadiusVector) можно найти такой угол между RadiusVector и LightVector, при котором соблюдается условие пересечения луча, заданного через вектора LightVector и RadiusVector с поверхностью. Назовем угол  между  этими двумя векторами - Gamma. Угол между векторами DistanceVector и LightVector назовем Epsilon

Теперь, найдем длину стороны RadiusVector для величны угла Gamma, при которой происходит пересечение LightVector с поверхностью. Выражение для стороны треугольника получается из формул тригонометрии для плоского треугольника, уготорого известна длина одной стороны (DistamceVector) и два угла при ней - угол Epsilon  и угол Gamma. Формула нужна? Она - тривиальна и взята из учебника. Это - первое выражение.

Теперь, выразим координаты  Alpha и Beta  через углы угол Gamma, углы Alpha(DistanceVector),Beta(DistanceVector), Alpha(LightVector), Beta(LightVector).

Из формул сферической геометрии получим функции для Alpha(Gamma,,,) и Beta(Gamma,,,)

Alpha (Gamma,,,) = F(Gamma, Alpha(DistanceVector),Beta(DistanceVector), Alpha(LightVector), Beta(LightVector))

Beta(Gamma,,,) = F(Gamma, Beta(DistanceVector),  Beta(LightVector))

Конкретные выражения я готов привести в личной переписке.
Как ни странно, получается, что Beta(Gamma,,,) от координат Alpha(LightVector) и Alpha(DistanceVector) не зависит!

Теперь, подставляем наши Alpha(Gamma,,,) и Beta(Gamma,,,) в формулу для поверхности. Это - второе выражение.

Приравниваем друг к другу первое и второе выражение.

Получаем формулу класса

tg(Gamma) = Const(Параметры поверхности) + F(Beta(LightVector),Beta(DistanceVector),Epsilon); 0<Gamma<90 градусов. Решение единственное и полностью определено.

Теперь считаем истинные (Alpha и Beta) координаты точки пересечения.

Вот и все решение.

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

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

[Ernest]

      Может перейдем на e-mail?

      Я не понимаю некоторых ваших вводных. А отсюда и невозможность оценить результат.

(1) Что это за направление на источник света (DistanceVector)? Оптическая ось? Направление из полюса поверхности на точку пересечения луча с предудущей?
      Обычно задачу рассматривают в терминах локальных координат связанных с вершиной поверхности на которую ожидается падение света. Луч описывается направляющими косинусами по отношению к координатам на предыдущей поверхности и координатами пересечения этой пред. поверхности. Затем следует операция преобразования координат (вращение, перенос, вращение) и уже только после этого поиск точки пересечения. Обычно сначала - пересечения с некой промежуточной поверхностью (ее выбор критически влияет на возможную потерю точности). И уже потом с поверхность второго порядка и далее ЧМ по уточнению в случае наличия высших порядков деформации.

(2) Гамма это - просто угол падения? А вот что такое "эпсилон" непонятно, поскольку не ясно с DistanceVector.

(3) Абсолютно не ясна фраза "Теперь, выразим координаты  Alpha и Beta  через углы угол Gamma, углы Alpha(DistanceVector),Beta(DistanceVector), Alpha(LightVector), Beta(LightVector)." И соотв. все последующее.

(4) Не могу понять, как получается "решение единственное и полностью определеное". Ведь даже для тривиальной сферы возможны три случая 0 пересечения, 1 пересечение (касание), 2 пересечения (и тут еще предстоит выбрать, какое из них наше). А для поверхностей высшего порядка пересечений может быть просто много. Да Вы и сами пишете об этом.

(5) Может быть, лучше описать это все формально. Рассмотреть частный случай - пересечение со сферой (или вторым порядком) и сравнить результат хоть со старым добрым Федером? Только провести все преобразования до конца (без отсылок к школьным учебникам ).

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

[Alexey_Smirn]

Уважаемый Ernest!

Мне казалось, что я достаточно внятно описал как начальные условия, так и решение.

Ну да ладно. Еще раз.

Итак. Пусть есть система координат, такая, что ось 0Z направлена вдоль оптической оси, а оси 0X и 0Y определяют плоскость, перпендикулярную оптической оси. Причем ось 0X направлена (в случае плоского рисунка) вертикально вверх, а ось 0Y - на наблюдателя.

Угол Beta определяется от оси 0Z и 0<=Beta<=180 градусов.

Угол Alpha отчитывается в плоскости X0Y от оси 0X и 0<=Alpha<=360 градусов.

В данных ккординатах и задается поверхность и падающий на нее лучь. Поверхность задается в виде:
 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.

Стоит заметить, что ввод такой системы координат позволяет ее рассматривать в качестве "локальной", т.е., каждый раз, при обработке каждой поверхности, совмещать центр системы координат XYZ с центром касательной сферы к обрабатываемой поверхности. Ввиду того, что данная задача будет предусматривать только решения, в которых оптическая ось не предусматривает излома (исключая случаи оптических систем зеркальных телескопов - Ньютона, семейства Кассегрена и т.д.) - не нужно будет задумываться о поворотах векторов. Т.е., брахиты посчитать я на первом этапе не берусь. Хотя, в общем-то - решение может быть распространено и на брахиты.

На вопрос "Что такое DistanceVector?" я ответил?

Угол Gamma - угол между радиус-вектором данной поверхности, направленном к точке падения луча и самим лучом. Угол Gamma будет "просто углом падения" только для сферы. Для других поверхностей он будет отличатся от угла падения, т.к. нормаль к поверхности будет не совпадать с радиус-вектором.

Вообще, рассматривается плоский треугольник, образованный
1)DistanceVector  - вектор, направленный из центра координат в точку, откуда исходят лучи света. Он определяет направление на источник света и расстояние до него.
2)LightVector - вектор, который начинается из точки, откуда исходят лучи света и заканчивается на оптической поверхности.
3)Радиус-вектор оптической поверхности, направленный в точку пересечения с LightVector.

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

Фразу "Теперь, выразим координаты  Alpha и Beta  через углы угол Gamma, углы Alpha(DistanceVector),Beta(DistanceVector), Alpha(LightVector), Beta(LightVector)" можно рассматривать как предложение переситать координаты всех лучей для нового положения оси 0Z, совпадающего с вектором DistanceVector. Так понятнее?

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

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

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

[Pavel_Boboshkin]

To Alexey_Smirn:
Честно скажу, я не приложил достаточно усилий, чтобы разобраться в Ваших выводах, кроме того, я мыслю (на эту тему) в декартовых координатах. Но истина, кажется, не должна зависеть от системы координат. Я сейчас попытаюсь доказать "на пальцах", что в ваших рассуждения закралась ошибка. Рассмотрим упрощенный вариант плоской задачи (в меридианальной плоскости), пусть поверхность задана в виде полинома четвертого (шестого, восьмого, ...) порядка. Луч - естественно прямая. Получилось:
A1*y^2+a2*y^4+...=b1*y+b2
А это - уравнение четвертого (шестого, восьмого, ...) порядка в чистом виде, и решений у него ровно черыре (шесть, восемь...), только некоторые из них могут быть комплексными или совпадать. Исключение - когда луч паралелен оптической оси (только одно решение), но думаю этот случай мало интересен.

[Alexey_Smirn]

уважаемый Pavel_Boboshkin!

Постарайтесь, все же, разобраться в предложенном решении. Решение и вправду весьма элегантное. И мало того, еще и работающее.

Могу сказать, что такое решение и сама любовь к сферическим координатам проистекла у меня еще с 1989 года, когда я начал делать модель астероида для эмуляции его кривой блеска и построения изображения оного в процессе вращения.

Астероид задавался в указанных выше сферических координатах как трехосный эллипсоид или как ряд по сферическим функциям. Астероид имел ориентацию оси вращения в пространстве, задавался так же вектор на наблюдателя и вектор на источник света.

Согласитесь, достаточно близкая задача! Ну так вот. Все это работало и работает. И даже на 386DX40 с сопроцессором моя ДОСовская программа давала картинку вращающегося астероида с вполне правдоподобными тенями с частотой 3-5 кадров в секуду. И никакого OpenGL или DirectX - все вручную.

По сравнению с декартовыми координатами расчет в сферических координатах позволял сэкономить СОТНИ процентов процессорного времени. Поверьте, я проверял.

Указанную программку могу выслать Вам по почте. Для ее запуска нужно будет препринять кое-какие меры - написана она на Борлад Паскале и на процессорах класса Целерон 333 и выше при старте у нее случается ошибка "деление на 0".

На счет 4, 8. и т.д. корней. Если мы рассматриваем луч света, как некий материальный объект - скажем, как струю воды, то тогда решение получиться одно.
В самом деле, если сразу отбросить варинты, когда
1)луч света параллелен оптической оси
2)луч света заведомо не попадает на поверность, ограниченную данными геометрическими размерами,

То останется ровно один вариант - первый контакт луча с поверностью. После первого контакта контактировать уже нечему - все отразилось или преломилось. А первый контакт луча с поверностью соответствует НАИМЕНЬШЕЙ длине вектора LightVector.

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

С уважением, Алексей
P.S. Сейчас я в отпуске, к Интернету имею доступ от случая к случаю. Когда выйду из отпуска - смогу описать решение более подробно, с рисунками. И может быть, к этому моменту созреет что-нибудь, что можно будет уже потрогать руками. Работы ведуться. Уже очень скоро буду выходить на написание интерфейсной части.

[Ernest]

Ага вроде начинает проясняться - Вы центр локальных координат совместили с центром кривизны (для сферы). Ну тогда вынос тела может состоятся еще до подробного анализа и преобразования асферик.

Такого сорта метод (не важно в каких координатах) работает более-менее, только при значительных кривизнах поверхностей (радиусы кривизны должны быть сравнимы с величинами промежутков). Как только вы выходите на "покатые" поверхности (радиус кривизны больше хода луча между поверхностями на порядок и более) метод катастрофически теряет точность. То есть для неоптического рэйтресинга это маловажно (освещенности сцены, отражения в кривом стекле и т.п. задачи), а в оптике существенны волновые аберрации (0.0001 мм и менее), которые набегают на нескольких десятках поверхностей с ходом луча, скажем, 5000-10000 мм, то есть относительная суммарная погрешность расчета должна быть порядка 1.0E-8..1.0E-9 (на самом деле даже жеще). На каждой поверхности еще меньше 1.0E-9..1.0E-10. Похоже Ваш метод будет давать катастрофическое накопление ошибок на поверностях близких к плоским, включая планоиды (типа пластинок Шмидта).

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

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

[Alexey_Smirn]

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

В первую очередь - извинения.

Действительно, результат для угла Gamma к виду Tg(Gamma) = Const. свести не удалось.

Итак, имеет место следующая формула.
A*Sin(Gamma) + B*Cos(Gamma) = C

Данная формула сводиться к квадратному уравнению вида
Y^2 *(B^2 + A^2)  -  2*C*B*Y + C^2 - A^2 =0,
где Y := Cos(Gamma);

При Beta(DistanceVector)<>0 коэфициенты A, B и C имеют следующее выражение:

 A := D * Sqrt(FOpticalSurfaceExcentrisity)*(Cos(Beta(LightVector) + Cos(Epsilon)*Cos(Beta(DistamceVector)) - FOpticalSurfaceParameter*Cos(Epsilon);

B := Sin(Epsilon) *(D *Sqrt(FOpticalSurfaceExcentrisity) *Cos(Beta(DistamceVector)) - FOpticalSurfaceParameter);

C := - D*Sin(Epsilon);

где D - длина вектора DistanceVector, FOpticalSurfaceExcentrisity - квадрат эксцентриситета оптической поверхности.

Теперь, ув. Ernest, не могли бы Вы проверить приведенные мною формулы?

И объясните мне, пожалуйста, на каком этапе, конкретно, накапливается указанная Вами ошибка? Из анализа решения и приведенных формул я этого не понимаю.

Проблема в низкой точности вычислений Синуса и Косинуса? Я все привык выражать в виде Extended - 80 битовом представлении числа с плавающей точкой которое дает 19 значащих цифр. Такой точности хватит?

С уважением, Алексей.
P.S. Для получения аналитического решения для асферик высшего порядка необходимо иметь представление данных поверхностей в используемой мною системе координат. У меня его нет. Кто-нибудь поможет найти данные по этому вопросу? Т.е., нужны ссылки на материалы, в которых есть формулы по заданию асферик более высокого, чем конические сечения, порядка в СФЕРИЧЕСКИХ КООРДИНАТАХ.

Собственно, практически все приведнные формулы - в том числе и приведенные в следующем моем посте ("В догонку") для таких поверхностей не именяться.

Изменятся только формулы, описывающие коэфициенты A, B и С. Или, возможно, выражение A*Sin(Gamma) + B*Cos(Gamma) = C приобретет более сложный вид.
 Но сам способ решения изменений не претерпит.

[Alexey_Smirn]

В догонку.

Формулы для пересчета угла Gamma в углы Alpha и Beta.

Cos(Beta(Gamma)) := Cos(Gamma)*Cos(Beta(DistanceVector))+Sin(Gamma)*(Cos(Beta(LightVector))+Cos(Epsilon)*Cos(Beta(VDistanceVector)))/Sin(Epsilon);

Cos(|Alpha(Gamma) - Alpha(DistanceVector)|) := (Cos(Gamma) - Cos(Beta(Gamma)*Cos(Beta(DistanceVector)))/(Sin(Beta(Gamma)*Sin(Beta(DistanceVector)));

Непределенности при Beta(DistanceVector) = 0, Beta(Gamma)=0 и Epsilon=0 обходятся легко.

В частности, при Beta(DistanceVector) = 0
Beta(Gamma):=Gamma;
Alpha(Gamma):=0;

при Beta(Gamma)=0 Alpha(Gamma):=0;

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

[Serge Chuprakov]

Приветствую всех!
Уважаемые, если вам нужна программа для дела (что-то надо расчитать), то чем вас не устраивает дема ZEMAX, лежащая а моей страничке

http://ursa.irk.ru/chupr/index.htm

Дема прекрасно работает, редактор стекол работает (обратите внимание!), оптимизация работает. Да, наворотов вроде непоследовательной трассировки лучей нет, двулучепреломления нет, оптимизации глобальным перебором тоже нет, но скажите - оно нужно??? Зато имеется полный набор всех типов поверхностей, которые могут только присниться.
Формат ZMX прост как ..., при этом прекрасно описан в прилагающемся руководстве. В конце концов можно состряпать несложный интерфейсик (это кому сложно разобраться в формате ZMX - уверяю вас, это гораздо проще, чем написать такой интерфейсик).


Serge Chuprakov

[Alexey_Smirn]

Уважаемый All!

Вы просили меня предоставить формулы для анализа. Я предоставил. Что, уже не надо? Или никому не интересно?

А для Вас, уважаемый Serge Chuprakov, повторю еще раз. Мне не нравитсья интерфейс Zemax. Не могу я разобраться в нем. И он кажется мне очень неудобным. И еще - я хочу написать что-то свое. Вполне разумный подход, как Вы полагаете?

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

[Serge Chuprakov]

А для Вас, уважаемый Serge Chuprakov, повторю еще раз. Мне не нравитсья интерфейс Zemax. Не могу я разобраться в нем. И он кажется мне очень неудобным. И еще - я хочу написать что-то свое. Вполне разумный подход, как Вы полагаете?

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

Приветствую, Алексей!
Я как раз и говорил, что можно написать свой интерфейсик, который бы только генерировал ZMX файлы.

А что, если переписать движок POV-Ray для оптических расчетов? Последняя версия POV-Ray имеет возможность расчета каустик (изображения источников света), учитывать показатели преломления материалов, задавать индикатриссы рассеяния на поверхностях и много чего другого. Получилась бы замечательная гибкая и очень мощная система кроме всего прочего для непоследовательной трассировки и учета рассеяного света (!!!) - очень удобная и практичная. Уж поверьте, у вас бы ее с руками оторвали - и я был бы первый!
Исходники POV-Ray имеются, авторы никого не ограничивают в творчестве (даже приветствуют).

Надо только повыкидывать из POV-Ray всякие процедурные текстуры и увеличить точность расчета точек пересечения и нормалей (только постоянные поменять - все остальное уже реализовано и отлично работает)...

Сергей

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

Весь интерфейс Земакса, точнее большинство работы с ним состоит из 3-х хоткеев (Ctrl-G, Ctrl-W,Ctrl-F), спридшита, кнопки F6 и полутора менюх - Analysis и немного Tools. Плюс рекомендуется проглядеть пункт Conventions&Definitions в мануале. Для нетерпеливых - там же туториал. И всё!!! После этого Земакс превращается в приятную и интересную игрушку, вытесняющую с компа все остальные  .
А драгэндропные ГУИ ведут к боли в запястье - потом тяжело стекло тереть будет.  
 

[Alexey_Smirn]

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

Огромное спасибо за содержательные, а, главное, очень соответсвующие теме и тем вопросам, которые я задал, ответы, советы и пожелания!

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

Надеюсь, что именно благодаря Вам Российским программистам удасться поддерживать высокий профессиональный уровень в области программных разработок САПР для проектирования оптических систем.

С уважением,

Искренне Ваш, Алексей.

[Serge Chuprakov]

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

Огромное спасибо за содержательные, а, главное, очень соответсвующие теме и тем вопросам, которые я задал, ответы, советы и пожелания!

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

Надеюсь, что именно благодаря Вам Российским программистам удасться поддерживать высокий профессиональный уровень в области программных разработок САПР для проектирования оптических систем.

С уважением,

Искренне Ваш, Алексей.

Алексей, ваша ирония не совсем уместна.
Вот вы спрашивали, не кажется ли мне ваш подход разумным. Так вот - не кажется... Конечно, написать свое всегда полезнее - для того кто пишет. Но если вы хотите сделать нечто полезное для других на высокоп профессиональном уровне, то разумнее вначале спросить как можно больше людей, уже имеющих опыт работы с подобными системами. Проанализировать их пожелания и предложения. И вот что они вам скажут:

1. очень редко оперируют таким понятием как "оптический компонент" - времена голландских мальчиков, случайным образом составляющих линзы прошли почти 170 лет назад (с появлением теории аберраций)... Не могу себе представить зачем мне перемещать целую линзу мышкой какое в этом "удобство" А вот например сразу видеть уравнения для коэффициентов аберраций через основные параметры тонких компонентов - очень бы хотелось...

2. а как быть с децентрированными поверхностями? Я говорю не о разработчиках децентрированных систем (хотя таких тоже немало), а хотя бы о тех, кто хочет проверить систему на чувствительность к разъюстировке.

3. Непоследовательная трассировка - учет бликов и рассеянного света (особенно бликов). пакетов, способных делать такие вещи очнь немного и они малодоступны. Но, представьте себе всем очень и очень нужны!

4. И конечно оптимизация! Черт с ним с методом наименьших квадратов и методом Ньютона - они просты и их реализация в разных пакетах почти не отличаются. А вот что касается методов "глобального" поиска, то существует много литературы на эту тему - всякие "генетические алгоритмы" и множество других - хотелось бы видеть все это в современном оптическом пакете.

5. Моделирование ошибок поверхностей - всегда хочется узнать, что будет, если на какой-то поверхности недоубран например "завал". надоело задавать поверхность с "завалом" общим уравнением - хотелось бы именно "наложить" "завал" на идеальную поверхность!

6. ... и т. д.

Вот какие вопросы и пожелания возникают "на вскидку" например у меня... Достаточно содержательно?

Сергей Чупраков

[Alexey_Smirn]

Уважаемый Serge Chuprakov!

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

А какая была реакция?
 - Использовать ZeMax...
- Использовать стандартные алгоритмы...
- Использовать готовые библиотеки...

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

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

А пока - сухой остаток ОТВЕТОВ на мои вопросы очень прост -
"НЕ СТОИТ ПРОГРАММИРОВАТЬ НИЧЕГО НОВОГО, НОВОГО СЛОВА ВЫ, АЛЕКСЕЙ, НЕ СКАЖЕТЕ, ТАК ЧТО - ИЗУЧАЙТЕ ЛУЧШЕ ZEMAX!"

Поверьте, Serge Chuprakov, у меня есть опыт разработки и внедрения коммерческих и shareware продуктов! Я на них деньги зарабатываю, понимаете? Плюс, по роду своей основной деятельности, отслеживаю процесс внедрения и произвожу выбор и тестирование, даю рецензии на применимось продуктов крупнейших софтварных фирм. Это и SUN, и Novell, и IBM/LOTUS и даже не поверите, Microsoft!   И я прекрасно знаю специфику как компьютерных систем масштаба предприятия, так и SOHO.

Вот такие вот первоапрельские мысли!

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