Отбрасывание нелицивых граней с учетом перспективы

Booster

Quake 1 рулит ) У меня исходики где то валяются его, там тоже DirectDraw и С++ )
Кстати насчет перспективы: после перспективных преобразований, для вычисления нормали какие векторы берутся? В аффином я брал первые две стороны и по ним считал, а здесь?

 

Последние две )

 

Я не совсем понимаю как по сторонам искать векторное произведение. Оно вообще-то ищется по трём точкам полика. Ищем нормаль полигона, и в зависимости от её знака определяем обратная это или лицевая сторона. Главное отрисовывать все полики в одном порядке вершин. После перспективного преобразования у нас ещё трёхмерные координаты, так что метод вычисления нормали не меняется.

 

Понятно, у тя сразу все в треугольниках хранится (Или я тя не так понял?). Я немного подругому сделал. Определил обьект многоугольник, который состоит из треугольников в одной плоскости, и для этого обьекта один раз считаю нормаль, которая у всех треугольников входящих в него будет одинакова (афф. пространство). Считаю также как ты сказал - векторным произведением сторон, заданных 3 точками. Может придется отказаться от этого обьекта...

 

Просто в перспективном пространстве нормаль будет меняться даже на плоском полигоне

 

Aloner:

Это как?? Пожалуй, такое мне не осилить без конкретных выражений..

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

 

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

 

Это оч глючная старая версия еще под 16-битный реальный режим.
Управление (Caps Lock Off!): a,s,d,w,q,e - различные повороты предметов внутри локации
r,d,g,h - различные повороты глобальной сцены
i,j,k,l - перемещение источника освещения
m - увеличение мощности источника освещения
Space bar - выход
Глюк на глюке конечно, но работаю, работаю

 

Когда ты проецируешь на картинную плоскость координата z всё ещё есть.
Представь ты проецируешь на картинную плоскость полик у которого точки отличаются только координатой z, значит по идее полигон находится на границе видимости и невидимости, но после проецирования он совсем не на границе. Видимо по-этому и надо делать тест именно после перспективного преобразования, у меня исчезли артефакты когда стал делать именно так.

 

Aloner

Booster

Я немного поотстал от современных методик - игрался с это темой давно в ДОСе на Pascale 6 и Tasme и все вычисления реализовывал сам на основе законов геометрической оптики
Но насколько я понимаю 3d пространство не может быть "перспективным" или нет - перспектива это особенность наблюдения картины "из точки" и потому учесть её можно только в результате проецирования 3d сцены на плоский экран с учётом взаимного расположения сцены, экрана (см ЗЫ) и наблюдателя.
А посему ИМХО сцена с учётом перспективы уже плоская и понятие нормали для её полигонов бессмыслено
Возможно и изобретено некое (неизвестное мне) формальное преобразование "бесперспективной" 3d сцены в "перспективную" 3d сцену, но ИМХО во впервых оно от лукавого и не имеет под собой физического смысла,
а во вторых (и это главное) - знак нормали при таком преобразовании по любому не изменяется - т.е. повёрнутая "спиной к наблюдателю" грань не может вдруг стать повёрнутой лицом и наоборот.
Главное отличие сцен учитывающих и не учитывающих перспективу в том, что при учёте перспективы маленький объект на переднем плане запросто может спрятать под собой большой объект на заднем плане, но это связано уже работой z-буфера и к механизму отбрасывания граней находящихся на оборотной стороне объекта никакого отношения не имеет.

ЗЫ: В OGL взаимное расположение экрана и наблюдателя стандартизировано (т.е. учитывается неявно) и часто вводит новичков в заблуждение что "важно учесть лишь положение камеры относительно сцены, а экран тут вообще не причём"

 

Y_Mur
Да всё правильно, просто тест этот нужно делать с координатами уже переведёнными в экранную плоскость, иначе артефактов не избежать. Ведь тестировать надо именно то, что будет на экране, а не то что где-то в памяти. Да я нигде про это не читал, но на практике имено так, и это вполне логично.
Я имел ввиду что после перевода координат в экранные, z координата ещё есть, и этим можно воспользоваться для теста.

А вот и нет вполне может, почему уже писал выше.

 

Booster

Если ты про это:

то ты не прав - речь у тебя здесь как раз о взаимном перекрывании полигонов (не важно принадлежат эти полигоны одному объекту или разным), а отбрасывание нелицевых граней с отрицательной нормалью это совсем другая песня - и нелицевая грань от учёта перспективы лицевой совершенно точно не станет - другое дело что спятанная под другим полигоном грань может стать видимой \ не видимой но при этом и прячущийся и перекрывающий полигон будут иметь положительную нормаль

 

Извини что сам себя цитирую, но это для понимания сути проблемы:

 

Y_Mur
Почему не станет, ведь луч от точки наблюдения до объекта при перспективной проекции не перпендикулярен экранной плоскости и не учитывать это ну совсем не верно.
Может в терминах лицевых и обратных плоскостей как ты пишешь так и есть, но тогда непонятно зачем он применятся для отсечения невидимых поликов в выпуклых объектах, ведь тогда он имеет сильную погрешность. Что-то я не помню таких погрешностей ни в DirectX ни в OpenGL.

Логично, если они видимы. Но штука в том, что нам ненужно отображать невидимые полигоны.

 

Короче, есть метод с расчетом отбрасывания после перспективнычх преобразований и просчета нормали каждый паз при рендэре нового кадра. (Работает 100%)
Я же прошу подсказать метод альтернативный этому: посчитать нормаль один раз, потом ее при рендэре нового кадра поворачивать и определять отбрасывать или нет.

 

Aloner
То есть когда ты заранее считаешь нормаль, трансформируешь вместе с объектом, переводишь в перспективу, то проверка не фурычит?

 

Да разобрался действительно псевдопроекция (зелёная) по методу Boosterа может сменить знак нормали и стать лицевой из оборотной.

 

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

 

Booster

Именно так и есть - если формально применить перспективное преобразование не к площадке а к уже посчитанному вектору, то вместо правильно чёрного вектора получим неправильный синий, который знак не меняет.
Aloner

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

 

Наверно нужно прибавить к одной из координат полика, координату нормали. Затем перевести полученную координату в перспективу, и вычесть из нёё координату точки полика, тоже переведённой в перспективу. Вроде так или как-то похоже.