Посмотрев на матрицу matrix3d, я могу сказать точно, это не чистая матрица проекции. Предположим это композиционная матрица, в которую уже зашили модельное, видовое и проекционное преобразование.
Первый вопрос: Какая смысловая нагрузка содержалась в модельной, видовой и перспективной матрице?
Второй вопрос: ваши двухмерные координаты x и y. В каком они пространстве? Модельном, мировом или видовом?
Важный момент: после умножения видовых координат [x, y, 0, 1] на матрицу проекции вы получаете однородные координаты. Они для рисования в двухмерном пространства монитора не подходят. Однородные координаты необходимо перевести в декартовы координаты. Для этого вы производите деление на w. Обратите внимание, что ваш результат будет не в пикселях, а в условных единицах. Если x и y в диапазоне [-1 1], то точка попадает пространство монитора. Скажем реальное разрешение области в которую необходимо рисовать 1024х512. После умножения координат на проекционную матрицу и преобразования результата в декартовы координаты вы, например, получаете x = -0.3, y = 1.0. Если точко отсчёта это правый верхний угол (как принято в WinAPI ).
То координаты в пикселях будут: x = ( 1024 / 2 ) + ( -0.3 ) * ( 1024 / 2 ) = 512 — 153.6 = 358.4 или 358 y = ( 512 / 2 ) + ( -1.0 ) * ( 512 / 2 ) = 256 — 256 = 0
Если точка отсчёта это правый нижний угол (как в OpenGL)
То координаты в пикселях будут: x = ( 1024 / 2 ) + ( -0.3 ) * ( 1024 / 2 ) = 512 — 153.6 = 358.4 или 358 y = ( 512 / 2 ) + 1.0 * ( 512 / 2 ) = 256 + 256 = 512
В OpenGL примерно эту же работу выполняет функция glViewPort ( x, y, width, heigth ).
OpenGL в корне отличается от того, во что превратился DirectX. OpenGL — это интерфейс для работы с графикой и всё. DirectX в свою очередь из подобного интерфейса превратился в разросшееся программное обеспечение. Теперь DirectX занимается всем подряд, начиная от растеризации и заканчивая сетью. Несомненно, это может ускорить разработку среднего игрового движка для двух платформ (PC и XBOX). Однако, на мой взляд, DirectX убивает желание разрабатывать что-то своё. Последний гвоздь в гроб DirectX — его не поддерживают мобильные платформы и тот же самый Apple, потому что DirectX стал непомерно большим. Другое дело OpenGL — он полностью описан в спецификации. Реализовывай хоть для микроволновки.
Факт, что больше придётся заниматься программированием, зато у вас больше контроля над происходящим. В DirectX же если хотите больше контроля, то начинаете отказываться от штук, типа ID3DXPMESH. Вспомните хотябы первый Crysis. Чуваки из Crytek просто отказались от всех наворотов DirectX, и практически с нуля написали свой рендерер. А потом, в DirectX появисиль интерфейсы которые были реализованы в Crytek. Не знаю, что будет с 12 версией DirectX, но я крайне скептичен. Время рассудит.
А идея с алгоритмом художника и некой сеткой мне нравится. Никогда не думал о таком решении проблемы z-файтинга. На настоящий момент использую 32 разрядный буфер глубины в своём GBuffer'e. Параметры матрицы проекции n=0.1f, f=5000.0f. Условная единица сцены — 1 реальный метр. Полностью согласен, что от проблемы z-файтинга это не спасёт, однако на карте площадью в 2 квадратных километра (квадрат со стороной 2 км) с любого ракурса z-файтинга выявлено не было.
Компьютерная графика — это наука об артефактах. Скрыть артефакты — великое искусство программиста и дизайнера.
Первый вопрос: Какая смысловая нагрузка содержалась в модельной, видовой и перспективной матрице?
Второй вопрос: ваши двухмерные координаты x и y. В каком они пространстве? Модельном, мировом или видовом?
Важный момент: после умножения видовых координат [x, y, 0, 1] на матрицу проекции вы получаете однородные координаты. Они для рисования в двухмерном пространства монитора не подходят. Однородные координаты необходимо перевести в декартовы координаты. Для этого вы производите деление на w. Обратите внимание, что ваш результат будет не в пикселях, а в условных единицах. Если x и y в диапазоне [-1 1], то точка попадает пространство монитора. Скажем реальное разрешение области в которую необходимо рисовать 1024х512. После умножения координат на проекционную матрицу и преобразования результата в декартовы координаты вы, например, получаете x = -0.3, y = 1.0. Если точко отсчёта это правый верхний угол (как принято в WinAPI ).
То координаты в пикселях будут:
x = ( 1024 / 2 ) + ( -0.3 ) * ( 1024 / 2 ) = 512 — 153.6 = 358.4 или 358
y = ( 512 / 2 ) + ( -1.0 ) * ( 512 / 2 ) = 256 — 256 = 0
Если точка отсчёта это правый нижний угол (как в OpenGL)
То координаты в пикселях будут:
x = ( 1024 / 2 ) + ( -0.3 ) * ( 1024 / 2 ) = 512 — 153.6 = 358.4 или 358
y = ( 512 / 2 ) + 1.0 * ( 512 / 2 ) = 256 + 256 = 512
В OpenGL примерно эту же работу выполняет функция glViewPort ( x, y, width, heigth ).
Факт, что больше придётся заниматься программированием, зато у вас больше контроля над происходящим. В DirectX же если хотите больше контроля, то начинаете отказываться от штук, типа ID3DXPMESH. Вспомните хотябы первый Crysis. Чуваки из Crytek просто отказались от всех наворотов DirectX, и практически с нуля написали свой рендерер. А потом, в DirectX появисиль интерфейсы которые были реализованы в Crytek. Не знаю, что будет с 12 версией DirectX, но я крайне скептичен. Время рассудит.
Компьютерная графика — это наука об артефактах. Скрыть артефакты — великое искусство программиста и дизайнера.