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

Проблема с усечением Frustum области другим Frustumом (8 стр)

Страницы: 13 4 5 6 7 8
#105
22:15, 18 мая 2021

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


#106
22:20, 18 мая 2021

Видимо возникнет алгоритмическая сложность определения пересечения объектов с фигурой. Хотя фигуры простые. Если фигуры останутся выпуклыми многогранниками, то совсем легко. Просто проверить каждую плоскость, не отсекла ли она объект.

#107
(Правка: 1:03) 0:53, 19 мая 2021

m210
Портал с боков ограничивают 2 вертикальные плоскости, проходящие через 2 вертикальные линии
Тут просто выбрать самую правую из левых и самую левую из правых
Сверху и снизу - сложнее, 2  линии, за счет поворота горизонтальной линии вокруг вертикальной оси получаются наклонные плоскости. Каждое пересечение порталов добавляет линии в многоугольник.
А если взять портал с запасом, по нижнему краю проекции на экран нижней горизонтальной линии -
тогда пересечение считать просто

У тебя реально такие огромные уровни, что нужны оптимизации?
Что если вывести целиком? Затык в филрейт или переключениях текстур?

> Еще я пробовал Occlusion Query, так это вообще дико медленная хреновина
Просто ты его неправильно используешь
Coherent Hierarchical Culling - Hardware Occlusion Queries Made Useful
Конечно, запоздание 1 кадр, пока видеокарта не отрендерит - не узнает результат
> и я полагаю с проживанием половины памяти видюхи
На что бы она тратилась? Просто считает сколько пикселей отрендил с момента последнего вызова

#108
(Правка: 14:06) 13:58, 20 мая 2021

Aslan
> Портал с боков ограничивают 2 вертикальные плоскости, проходящие через 2
> вертикальные линии
> Тут просто выбрать самую правую из левых и самую левую из правых

Ну так я так и делаю, в начале темы даже код приводил.
Aslan
> Что если вывести целиком?
Если выводить целиком, ты будешь видеть то, что видеть ни в коем случае не должен (это тоже объяснял в самом начале темы), у движка есть Room over Room, в одном и том же пространстве может находится несколько секторов.

Вот довольно старое видео, где я включаю-отключаю отрисовку всей карты целиком
https://www.youtube.com/watch?v=6IxvAa5iaRw


Оптимизацию провожу с целью добиться бОльшей производительности, ежели в старом Polymost 2003 года...если выводить всю карту целиком, тогда, например, Raspberry Pi вылетит с ошибкой из-за нехватки памяти, а если что-то и выведет, то с 1fps, а не 40-60fps (то, что сейчас имею я)
И получается, можно конечно плюнут на все, на оптимизацию и делать как это принято в современном мире - "и так сойдет", когда 3 полигона дико тормозят на core i7 и жрут 16гб оперативки, но я так не хочу :)
И если делать "и так сойдет", тогда какой в этом смысл, если старый Polymost будет в 10 раз быстрее. Пока что мне удается держать скорость и она местами быстрее, чем в Полимосте со значительными приимуществами, и даже есть пару идей, как можно ускорить алгоритм раза в полтора а может и в 2...но пока забил на этом, и так работает более-менее хорошо.


Aslan
> Просто ты его неправильно используешь
> На что бы она тратилась?

Возможно, но:
1. На каждый полигон нужно регистрировать свой query-буфер, чтобы потом получить из него данные - отрисовался полигон или нет. С этим вроде вопросов нет.

Далее, в движке (на неосовременном) поддерживается 16384 стены и 2048 секторов (т.е. 4096 потолков и полов)...значит нужно зарегистрировать 20000 буферов, отрисовать всю карту целиком, потом пробегаться по всем этим буферам, чтобы определить что отрисовалось, а что нет.

Далее после отрисовки ждем от 1 до 10мс, пока видюха передаст данные в CPU....вот поэтому я и назвал этот метод дико тормозным, потоки не синхронизированны, данные можно получить сразу или с диким запаздыванием, а можно и вообще не получить.

Ну и хрен с ним с запаздыванием, нужно иметь в памяти видюхи 20000 буферов и столько же в оперативке для передачи данных из видюхи.

Или я что-то не знаю?
Готов попробовать и видюшный метод отрисовки, может он и действительно будет работать быстрее 5мс за кадр, но других методов я не знаю.

#109
14:08, 20 мая 2021

betauser
Я такое не осилю :)

#110
20:23, 7 июня 2021

Если интересно, со сканером видимых секторов я закончил (на время, оно не идеально и может работать явно быстрее, но решил пока забить)

https://www.youtube.com/watch?v=-ASEp8brqG4

Сегодня увидел новую проблему :)

#111
10:27, 8 июня 2021

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

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