Геометрия (задачки)

[Igors]

Из того что Вы рассказали я понял что матрица GL_MODELVIEW никакого отношения к масштабу и пикселям не имеет.

Имеет.
...
Я может быть ошибаюсь, но к пикселям имеет отношение почти всё, ...

Разумеется любые изменения GL_MODELVIEW повлияют на результат. Но различные вызовы glOrtho никак не изменяют эту матрицу. Поэтому практичнее для операций pan/zoom вообще ее не трогать а просто управлять пр-ком подаваемым в glOrtho

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

- для простоты принимается bounding box [-0.5..0.5], по-взрослому он должен вычисляться на основании модели и иметь любые размеры/центр

- выбор вертекса предполагает единичные матрицы OpenGL иначе не будет работать корректно. Ну и вообще перебор всех - не подход.

- возможно более правильно (или технично) использовать gluProject/gluunProject вместо самопальных переводов

Ну в конце-концов это просто пример 

[__Heaven__]

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

Вот ещё момент вчера решил. Как будем таскать объект по экрану с помощью ПКМ?

При отпускании мыши она должна указывать на ту же точку геометрии, что и при нажатии. Я это уже решил, но интересно мнение форумчан
P.S.: в своем проекте я выполняю pan за счет трансляции в начале рисования, то есть с помощью ModelView. И это удобно

[Igors]

Как будем таскать объект по экрану с помощью ПКМ?

Такая аббревиатура мне неизвестна Зависит от смысла "таскания". Если имеется ввиду реальное перемещение объекта - то однозначно GL_PROJECTION. Если же меняется view (pan, т.е. скролл окна) то так же как в примере выше.

[__Heaven__]

ПКМ - правая кнопка мыши.

Да, забыл упомянуть, я задачки решаю на ортопроекции.

Тут еще пришло в голову:

destVertex = project * someMatrixOperations * ModelView * sourceVertex.

someMatrixOperations - некие операции трансляции, поворота и масштаба, представлены в виде перемножения различных матриц и очень редко изменяются пользоватлем, или даже вообще не изменяются, например это перенос центра исходной геометрии в центр "экрана", поворот на 100500 градусов вокруг осей и масштабирование в 2 раза, то есть так сказать положение, от которого начинаем плясать. Также нам известно, что projection тоже редко меняется, а ModelView перестраивается на каждом кадре.

Так вот, чтобы сэкономить на операциях предлагаю такой вариант решения задачи:
В матрицу project запишем результат project * someMatrixOperations. Таким образом эта матрица будет хранить не только правила проецирования геометрии, но также и её преднастройку. А матрицу ModelView мы можем вертеть как хочешь.

[Igors]

предлагаю такой вариант решения задачи:

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

Предлагаю сделать отдельную тему, напр "Создаем OpenGL Viewer с нуля" - и там уже развернуться по полной, со всеми подробностями.

[__Heaven__]

ок, ещё раз 

Задача - отрисовать геометрию на экране с учётом всех преобразований.
Для этого требуется к каждой вершине sourceVertex применить ряд операций, то есть projection и modelview, как мы привыкли.
Но вот мы знаем, что каждый раз выводя геометрию на экран нам необходимо предварительно сделать ряд однообразных превращений modelview. Пускай это будет перемещение в центр области построения геометрический центр (центр масс) детали (она у нас одна). На протяжении работы с деталью геометрический центр остаётся неизменным. То есть у нас получается, что мы каждый раз при прорисовке детали делаем одну и ту же операцию.

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

Если имеется ввиду реальное перемещение объекта - то однозначно GL_PROJECTION. Если же меняется view (pan, т.е. скролл окна) то так же как в примере выше.

Не важно, каким образом происходит перемещение (но необходим оптимальный). Важно, чтобы на экране пользователя объект был перемещён из точки А в точку Б.
То есть интересно как мы пиксели будем переводить в координаты и производить само перетаскивание каким либо из методов.

[Igors]

Но вот мы знаем, что каждый раз выводя геометрию на экран нам необходимо предварительно сделать ряд однообразных превращений modelview. Пускай это будет перемещение в центр области построения геометрический центр (центр масс) детали (она у нас одна). На протяжении работы с деталью геометрический центр остаётся неизменным. То есть у нас получается, что мы каждый раз при прорисовке детали делаем одну и ту же операцию.

В изометрии есть обязательная операция Fit (вписать) которая гарантирует что все объекты будут полностью видимы. Ее тоже лучше делать не трогая никакие матрицы как в примере выше (см resizeGL). Конечно можно все сделать в одной (любой) матрице, но потом с ней будет неудобно работать. Стандартные роли:

GL_PROJECTION - отражает реальные движения объекта
GL_MODELVIEW - поворот камеры
glOrtho - отвечает за pan/zoom

Все удобно, зачем искать приключений?

(она у нас одна).

Заявления типа "у меня одна (и только одна) модель!", "у меня нет (и не будет) источников света!" показывают, мягко говоря, "недостаток опыта" и капитально отбивают охоту Вам отвечать.

И еще: пожалуйста создайте новую тему, там продолжим. А этот топик я создавал для др целей и больше отвечать Вам здесь НЕ буду. Спасибо за понимание. 

[Igors]

#8) Солнечный свет - он параллельный или как? Параллельны ли "солнечные лучи"?. Чему (какой модели) соответствует солнечный свет в CG? (CG = computer graphics). А в (долбаном) OpenGL? Насколько бесспорно это соответствие?

Данные: радиус Солнца 695,800 km, радиус Земли ~6,400 km, расстояние ~150e+6 km

[__Heaven__]

Солнечный свет - он параллельный или как? Параллельны ли "солнечные лучи"?.

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

Чему (какой модели) соответствует солнечный свет в CG? (CG = computer graphics). А в (долбаном) OpenGL?

Про CG = computer graphics не слышал. Слышал про C for Graphics. Он стал прародителем GLSL (что является частью OpenGL).
Если вы имели в виду этот Cg, то я находил несколько моделей на GLSL в книжке Алексея Борескова "Разработка и отладка шейдеров".
Не скажу, что там модели именно для 100% имитации солнца, но что-то на них сделать можно. Советую посмотреть откомпилированные примеры. По моему, там были и примеры на Cg.
В OpenGL 1.x можно попробовать написать некую приблуду, которая позволит оперативно расставлять источники света и регулировать их показатели отражаемости, диффузии и окружающей освещенности. Ну и чтобы она свойства освещаемого материала могла крутить оперативно. Далее тупой подбор.

Насколько бесспорно это соответствие?

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

[Igors]

Если вы имели в виду этот Cg,

Не имел, это 2 разные аббревиатуры

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

Хмм.. ну вот я дернул фотку наугад (аттач), вроде очень даже значительно

[m_ax]

Хмм.. ну вот я дернул фотку наугад (аттач), вроде очень даже значительно

У меня тож задачка:
Если вечером, прогуливаясь, сильно прищурившись посмотреть на свет от дальних фонарей, то свет от них мы будем видеть в виде вертикальных светлых полос.. Почему так?)     

[__Heaven__]

Ну, я не особо наблюдательный и в реальной жизни таких рассветов не видал.
Предположим, что есть материальная точка в виде солнца. Расстояние до земли составляет 149.6E9 метров. Предположим, что протяжённость горы, изображенной на фото 200км. Значит от середины горы (за которой и располагается материальная точка) до края горы будет 100Е3 метров.
Подсчитаем угол между лучом по середине и крайним лучом.
alpha = atan(100E3 / 149.6E9) = 3.829931785633275e-005 градуса
На фото мы видим явно завышенный угол. Значит:
1) фотография - фэйк
2) за горой стоит здоровенный отражательный прибор
3) я в чём-то ошибаюсь

[__Heaven__]

У меня тож задачка:
Если вечером, прогуливаясь, сильно прищурившись посмотреть на свет от дальних фонарей, то свет от них мы будем видеть в виде вертикальных светлых полос.. Почему так?)     

Свет огибает ресницы

[m_ax]

У меня тож задачка:
Если вечером, прогуливаясь, сильно прищурившись посмотреть на свет от дальних фонарей, то свет от них мы будем видеть в виде вертикальных светлых полос.. Почему так?)     

Свет огибает ресницы

Нет) Для чистоты эксперимента можно выщипать ресницы) Эффект только усилиться)

[__Heaven__]

У меня тож задачка:
Если вечером, прогуливаясь, сильно прищурившись посмотреть на свет от дальних фонарей, то свет от них мы будем видеть в виде вертикальных светлых полос.. Почему так?)     

Свет огибает ресницы

Нет) Для чистоты эксперимента можно выщипать ресницы) Эффект только усилиться)

Боюсь спросить, откуда вы знаете
Но если начать наклонять голову от плеча к плечу, то полосы начнут поворачиваться вместе с головой. То есть вертикальность относительно земли пропадёт.