Войти
ПрограммированиеФорумГрафика

Кто силен в математике - помогите с матрицами! (9 стр)

Страницы: 14 5 6 7 8 9
#120
16:08, 10 мар. 2019

san
> Вообще-то фрустум это перевернутая пирамида, стоящая на вьюпорте, т.е вьюпорт это ее основание.
Нет. Я тоже неверно написал, это не куб, а прямоугольный параллелепипед. А пирамидой его делаешь ты, умножая в вертексном шейдере вертексы на матрицу, содержащую перспективные искажения.

FordPerfect
> чтобы реализовать scissor достаточно
А цикл именно такой, как ты написал? Мне кажется, он ближе к такому:

for(int y=y0;y<y1;++y)
{
  int xx1=lerp(x0,x1,(y-y0)/(y1-y0));
  int xx2=lerp(x0,x2,(y-y0)/(y1-y0));
  for(int x=xx1;x<xx2;++x)
    process_pixel(x,y);
}
И никаких проверок выхода за границу внутри цикла, ведь frustum culling, это не просто оптимизация, он гарантирует, что все пиксели попадут во вьюпорт, проверять не нужно.

#121
19:16, 10 мар. 2019

san
> Я показал тебе фрустим отсечения, который получается ПОСЛЕ того, как матрица
> повернута должным образом.
Это только одна плоскость отсечения. И вычисления ее не проще не сложнее оно такие же как и везде.

#122
22:16, 10 мар. 2019

Mikle
> А цикл именно такой, как ты написал? Мне кажется, он ближе к такому:
Твой цикл - это scanline rasterizer. У меня - halfspace. В железе - практически всегда halfspace.
Вот чуть более полноценный пример цикла (в софтрендере):
https://gamedev.ru/projects/forum/?id=215799&page=55&m=4345819#m823

> И никаких проверок выхода за границу внутри цикла
Они менее дорогие, чем кажется. И установка границ в каждой сканлинии - небесплатна.

> ведь frustum culling, это не просто оптимизация, он гарантирует, что все пиксели попадут во вьюпорт
На практике - не особо. Потому что:
1. Точность плавающей точки.
2. Guard-band clipping (мы хотим (для производительности), чтобы координаты треугольника могли выходить за viewport, т. к. при этом мы можем в куче случаев заменить дорогой 3D clipping дешёвым 2D).
https://docs.microsoft.com/en-us/windows-hardware/drivers/display… band-clipping
https://developer.download.nvidia.com/assets/gamedev/docs/Guard_B… _Clipping.pdf
https://fgiesen.wordpress.com/2011/07/05/a-trip-through-the-graph… -2011-part-5/

#123
9:18, 11 мар. 2019

FordPerfect
> На практике - не особо. Потому что:
> 1. Точность плавающей точки.
Так ведь frustum culling проходит на уже приведённых вертексах, плоскости отсечения строго перпендикулярны осям координат, когда frustum прямоугольный, а его размеры целочисленны и равны размеру бэкбуфера в пикселях. Чтобы float в точности не совпал с int, последний должен превысить 16 000 000, неслабый экранчик :)

#124
9:47, 11 мар. 2019

Mikle
> Так ведь frustum culling проходит на уже приведённых вертексах, плоскости отсечения строго перпендикулярны осям координат, когда frustum прямоугольный, а его размеры целочисленны и равны размеру бэкбуфера в пикселях.
Эээ... нет? Совсем нет, ведь вроде же.

Точнее, frustum culling - это, строго говоря, софтовый алгоритм, который программист пишет сам. Как хочет, так и пишет. Может в целочисленных координатах.

Тот "frustum culling", который в железе - clipping ( https://www.khronos.org/opengl/wiki/Vertex_Post-Processing#Clipping ), он в clip-space, вполне себе в плавучих координатах. И новые вершины, которые он потенциально создаёт - тоже в плавучих координатах.

#125
11:02, 11 мар. 2019

FordPerfect
> frustum culling - это, строго говоря, софтовый алгоритм, который программист пишет сам.
Значит опять путаница в терминах, я про Clipping объёмом viewing volume, к которому приводится frustum после вертексного шейдера.

> он в clip-space, вполне себе в плавучих координатах. И новые вершины, которые он потенциально создаёт - тоже в плавучих координатах.
Я писал о том, что координаты ЧИСЛЕННО равны целым величинам, а не являются int, но тут я был неправ, написано, что они приводятся к +-w, меня сбило то, что в FFP в приведённом формате координаты задаются в пикселях. В Direct3D при использовании шейдеров, если убрать вертексный шейдер (оставить только "mov oPos, v0"), получается +-1. То есть даже численно это float, но сути дела не меняет, при разумных размерах бэкбуфера 2/Width или 2/Height вполне точны, при умножении на Width или Height погрешность не достигнет полпикселя.

#126
23:24, 17 мар. 2019

Mikle
> А фрустум (выше я неправильно написал "вьюпорт") - это изначально куб

фрустум куб ? :D это в каких координатах ?

+ Показать

https://gamedev.ru/code/articles/FrustumCulling

#127
23:30, 17 мар. 2019

> это в каких координатах ?
В однородных координатах в clip-space видимый объём выглядит так:

-w <= x <= +w
-w <= y <= +w
-w <= z <= +w

#128
(Правка: 2:19) 2:17, 18 мар. 2019

FordPerfect
> В однородных координатах в clip-space видимый объём выглядит так
Думаю при таких условиях это как раз не совсем куб будет описывать. Тут придется/требуется все на W поделить тогда будет куб. Все таки W не константа для отдельного clip-space. В любом случае куб и пирамида будут понятия взаимозависимыми.

#129
5:43, 18 мар. 2019

foxes
Я имел в виду 4D куб, а не 3D. Понятно, что однородные координаты - это не совсем нормальное 4D, а класс эквивалентности.

Страницы: 14 5 6 7 8 9
ПрограммированиеФорумГрафика