- GLoom
- Постоялец
m210
В том же Urho3D occlusion culling считается на основе того что попало в конус камеры и помечено как occluder. Можно делать динамические окклюдеры и проезщающая фура может вполне закрывать кусок сцены. В итоге BSP из оригинального уровня у меня никак вообще не использовался.
Cheb
> Если видеокарта расчитана рисовать дохреналион треугольников в кадре, а у тебя
> проседает на смешном количестве (а ретро-карты - реально смешное количество) -
> значит ты что-то делаешь не так.
В этой карте 639306 вершин, значит 213102 треугольников, не уж то мало? :)
Quake3 бегает нормально, потому что там немного другой подход - там рисование не по полигонам а по текстурам, типа на карте например 10 текстур, берется 1я текстура и рисуются все меши с этой текстурой за один drawcall, и так 10 раз. Мне такой подход не годится, иначе бы давно сделал бы также
Майнкрафт рисуется достаточно быстро, потому что там всего одна текстура - один атлас, а меш объединяется в один drawcall на чанк и опять таки полное 3D.
У меня, где одна комната может находится внутри другой комнаты и при этом не должна быть видна, если не виден портал, который в нее ведет - все эти методы не годятся
GLoom
> Можно делать динамические окклюдеры
До этого я тоже почти дошел, но пока не знаю как построить near плоскость такого оклюдера, иначе будет отсекаться то, что находится перед столбом например
Вот пример, почему мне не подходят методы из 3D движков и объединение мешей в один большой.
Но мне осталось немного, чтобы добить алгоритм определения видимости до конца))
Как вариант: если портал попадает во фруструм, строим новый фруструм по вершинам портала.
т.е. не режем портал, а по числу его граней строим новые плоскости нового фруструма.
Ну будет возможно не очень оптимально... что-то лишнее отрисуется, да и то не всегда...
>Вот пример, почему мне не подходят методы из 3D движков
Я тоже когда-то был, такой, "Уря, можно сделать сектор внутри сектора! Крута!" - вот только это нелегальная операция и даже в оригинальном Дюке нихрена не работало, всё время глюки лезли, пули бились об воздух и просверкивали спрайты из того второго сектора.
См. http://chebmaster.com/downloads/mod_dn.exe - моя упоротая карта начала 2000х с порталом между параллельными мирами.
P.S. Навскидку: забить на Z и строить видимость строго обходом секторов портальным методом, на посекторной основе. Потом всё условно видимое упаковывать в списки, отсортитрованные по текстурам и сдавать видеокарте. Но сначала сдать ей неотекстуренный меш для раннего Z отсечения.
Хранить списки с предыдущего кадра и повторно использовать, если не изменились.
m210
В современных движках это можно делать включением/выключением частей уровня при переходе через триггер или телепортацией игрока в визуально идентичное место.
Или ты именно хочешь рендерить какие то старые уровни из build двика?
GLoom
> Или ты именно хочешь рендерить какие то старые уровни из build двика?
Ну он же порт пишет. Конечно хочет, хех.
https://m210.duke4.net/
entryway
А, ок. Беда тогда, надо урезать порталы в плоскости экрана.
> значит 213102 треугольников,
Да, для Raspberry Pi 2 это напряжно, еле потянет на 60 фпс.
..для Raspberry Pi 2.
..и офисных гробиков середины нулевых.
Короче, озвученная проблема выглядит для меня, как преждевременная оптимизация. *Сначала* укротить огл и добиться производительности на современной видеокарте, используя примитивные методы отсечения (на по-секторной основе). А уже после этого начинать оптимизацию отсечения видимости для слабых машин с учётом Z. Если понадобится.
P.S. Более лучший для тебя вариант: определить взаимопроникающие секторы, вырезать их нахрен из группы соединённых секторов в две отдельные группы и присоединить искусственно добавленными порталами.
После этого, используя постулат, что взаимопроникающие секторы *не могут* быть видимы одновременно, спокойно заниматься рендером, аттача тот, который в текущий момент виден.
Cheb
Надеюсь до этого не дойдет, тем более уже проверено лично, что левая и правая плоскость фрустума автоматически отсекает пересекающиеся сектора, но если не учитывать Z, как раз получаю глюки в дюке (и все прекрасно работает на алгоритме с построением aabb, там Z учитывается и глюков меньше, чем в оригинальном рендере) Попробую в общем строить фрустум по aabb, посмотрим что получится.
Придумал еще один подход, пробую его реализовать:
Беру стену-портал, строю 4 вершины.
Далее проверяю эти вершины на видимость через текущий портал.
Если плоскости портала режут 1 вершину - игнорирую это и плоскость фрустума портала будет строиться без клипирования...если срезает 2 вершины, то вместо постройки плокости нового фрустума беру секущую плоскость текущего портала (в этом сейчас основная загвоздка)
https://youtu.be/9Ih0dGDPBkE
Вот как это сейчас работает - т.е условно правильно, верхняя и нижняя плоскости строятся часто неправильно, но они строятся так, что просто захватывают больше чем должны, а значит это уже и не такая большая проблема.
Но опытов я проводил мало и проблема скорее всего большая))
Надо теперь написать код расширения портала, а то сектора-квадратики видятся дырами
Но в целом видно то, чего я добиваюсь
Всем привет! В общем плюнул пока-что на построение точных фрустумов и реализовал идею, предложенную 0xc0de, собственно спасибо ему за наводку!
Получается конечно то, от чего я хотел уйти, но в итоге вернулся к AABB, с чего и начинал (только раньше я проецировал все стены и проверял пересечение AABB каждой стены, а сейчас от AABB строю фрустум и пересечение проверял только с порталами)
Ну и как ожидалось, получилось, медленнее раза в 2 на участках с большим количеством порталов и немного быстрее, где больше обычных стен. Но зато появилась возможность проверки вообще любой точки без необходимости проецирования ее на экран, благодаря чему я сделал проверку видимости пола, потолка сектора, спрайтов и частей стен над/под порталами.
Вот картинка во время реализации:
Типа зеленый квадрат AABB от портала (5 стен, которые легко объединить в один квадрат) и справа построенный фрустум через такой AABB.
В таком ракурсе AABB получается почти ничего лишнего не захватывает, а вот если развернуть камеру так, чтобы эти стены напоминали вытянутый параллелограмм, тогда AABB получается на пол экрана, что приводит к определению лишних видимых стен - в этом можно убедиться по видео-ролику ниже на карте Египта из Duke World Tour, там из-за низкой точности этих фрустумов рисуется половина карты.
Ну и вот само видео с тем, что получается:
https://youtu.be/_aHjd7cH12w
Кстати, чтобы из AABB построить фрустум, я делаю обратное проецирование координат в мировые...отсюда и скорость работы в 2 раза меньше, ведь по-сути выполнить проецирование уже нужно дважды на каждый портал. Если есть способы, как построить фрустум без умножения на обратную матрицу, дайте знать :)
m210
> Пишу новый рендер для Build Engine, результаты такие
Ого, как!
Но там, насколько я понимаю, порталы - плоские сектора, а не фрустумы
Вычислять пересечение секторов же просто
Есть идея алгоритма растеризации 2.5D с невыпуклыми секторами, но не дошли руки реализовать
Тема в архиве.
