- nes
- Постоялец
rock88
Где-то тут на форуме писали что все матричные операции лучше делать на CPU, а в шейдер передавать результирующую матрицу.
leonardo98
> матрица ортогональная должна быть, углы плитки при повороте надо самому
> посчитать для имитации пространственных искажений
Ну давай, приведи пример, я посмотрю, как у тебя это получится :)
Я бы делал так, поскольку для такой площадки нужно полное 3Д (без обид).
Для того, чтобы площадка "привязывалась к экрану в нужных местах", надо попросту, зная пропорции нашей площадки, подобрать угол ее наклона на экране и по ним вычислить матрицу проекции. (Да - тут надо предзадать zNear/zFar самому, и остается два варианта - либо программно вычислять наклон проекции - либо (что проще), на основании угла наклона площадки подобрать FOV).
Далее работаем с этой матрицей проекции.
Если на плитках стоят спрайты - для них экранные координаты мы можем узнать, зная матрицу проекции и положение плитки. Зная ту же самую матрицу проекции - можно вычислить расстояния до экрана и таким образом масштабировать 2Д спрайты на плитках.
Поворот в данном случае будет МАКСИМАЛЬНО есс-но выглядет на ЛЮБОМ разрешении экрана и путем ничтожных усилий.
А все эти 2Д искажения, чтобы "подогнать под 3Д эффект" - геморрой, в конечном итоге все равно приводящий к изложенному выше решению. Хотя да, никто не мешает потратить на эксперименты недельку-другую, чтобы в этом убедиться ЛИЧНО.
Можно сделать умножение на перспективную матрицу на CPU (для каждой плитки — свою) и батчить полученные 4-вектора.
Ввиду того, что эта перспективная матрица достаточно ограничена, умножение на нее будет дешевле умножения на произвольную 4-матрицу.
CasDev
> Ну давай, приведи пример, я посмотрю, как у тебя это получится :)
10баксов - и скину код через 30 минут
leonardo98
Для имитации поворота надо еще учитывать еще и текстуру плитки.
Гуд, если она однородная. А завтра Заказчик захочет резную "под дерево" - будем пилить вместо углов сетки всю сетку целиком под каждый пиксель в зависимости от разрешения экрана? Крутое решение, я не против.
CasDev
> А завтра Заказчик захочет резную "под дерево" - будем пилить вместо углов сетки
> всю сетку целиком под каждый пиксель в зависимости от разрешения экрана?
не вижу никакой проблемы нарисовать что угодно, формула получения перспективы screen = [world.x / (world.z + a) * b, world.y / (world.z + a) * b] - немного утрировано, конечно, но это обычная матрица трансформации записанная в виде формулы, посчитать по ней можно хоть полигон, хоть сетку на 1000 треугольников на современных компьютерах в тысячные доли секунды, кода там - 10 строк, но, конечно, лучше пудрить мозги заказчику о невероятной сложности задачи)))
leonardo98
Фишка не в получении координат узлов текстуры перспективы - фишка в ИСКАЖЕНИИ текстуры при растеризации.
Возьми квадрат с диагоналями в виде текстуры.
Далее - устанавливаем орто, делаем спрайт в виде трапеции (насколько я понял - твой метод) - растеризуем.
То же самое - но квадратный спрайт, с разными Z по в узлах - растеризуется норм.
CasDev
> фишка в ИСКАЖЕНИИ текстуры при растеризации.
искажения будут, действительно, и примерно в 1% случаев их можно увидеть - если сильно присмотреться
Я предлагаю размещать плитку не на ровной плоскости а на сфере, так, чтобы она "лицом" была повёрнута на камеру. Искажение получается из-за того, что под разными углами смотришь на все плитки.
rock88
Andy51 и leonardo98 рабочие варианты предложили.
1) Можно самому производить перспективные преобразования: перенос в центр, деление (x,y) на дистанцию до вершины, перенос в нужное место. Но если не позаботиться о zw-координатах, тогда возникнет проблема некорректной интерполяции атрибутов вершин (в вашем случае это будут как минимум текстурные координаты).
2) Можно сделать через матрицы и так будет правильнее. Пусть плитки покрывают квадрат с размером стороны 2 и центром в (0,0). Тогда после поворота (R) и перспективного проецирования (P) можно координаты (v) домножить на матрицу масштабирования (S) и переноса (T) в нужную часть экрана. Итого получается T * S * P * R * v. T, S, P у вас константы - можно объединить в одну, посчитав 1 раз. Причём можно в рантайме генерировать исходник для вершинного шейдера "запекая" в него эти 10 константных матриц. 10 матриц поворота R можно прокинуть в шейдер как юниформ-массив, а к вершинам в виде атрибутов добавить индекс нужного элемента массива - тогда можно всё отрисовать за 1 вызов glDrawElements/Arrays
Спасибо, ребят! На выходных буду пробовать с этим что-то сделать =)
Тема в архиве.