jm
Кроме того, мне вот кажется что leaf+pvs для открытых пространств как раз быстрее будет...
Может быть, может быть. Но тогда PVS сжимать с помощью ZLE не выгодно будет (нулей уж больно мало -- все видно вокруг -- одни единицы) :-).
А если серьезно, то черт знает как туда вобще порталы притулить -- ведь вроде их смысл в том, чтобы отображать только те полигоны, которые попадают в видимые порталы. И уж на открытой местности порталы помочь не смогут (например, гора какая-нибудь закрывает высокополигональный объект -- попробуй определи, что его не видно).
Да и как, например DeltaForc'ы сделаны -- т.е. как делается смесь открытых пространств и помещений.
в открытых пространствах вместо порталов нужно использоваль окклудеры, т. е. для уровня нужно делать специальную упрощённую копию, которая поможет двиглу определять видимость объектов. PVS для широких долин и всё такое прочее - это смерть.
tav
Ладно, спорить-то! Я же сказал, что мы говорим о разных вещах. Бред, не бред. Ты даже не попытался вникнуть мою реализацию bsp (не-классического) а уже бросаешься громкими словами.
Zlobnyi Serg
Я просто предложил возможно более эффективный способ трассировки луча.
>Ты даже не попытался вникнуть мою реализацию bsp (не-классического)
А че тут вникать. Я же пример определения пересечения луча с BBOX'ом написал, чего ж еще?
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Как уже, надеюсь, понял читатель после прочтения этой статьи, не следует использовать BSP алгоритмы для открытых пространств или в проектах, требующих тотального разрушения окружающего мира. Это не даст положительных результатов из-за специфики самого алгоритма
--------------------------------------------------------------------------------------------------------------------------------------------------------------
так какой же алгоритм надо применять в проектах, требующих тотального разрушения окружающего мира?
Подскажите, пожалуйста, где можно почитать про минимизацию кол-ва полигонов в BSP-дереве (балансировка дерева не требуется)?
Насколько эфективен предложенный в статье способ сортировки по весу?
_ps_
В таких проектах надо сперва подумать - 'а за что мъ беремся...?'.
capgreen
Насчёт минимизации количества полигонов в BSP-дереве - ты вряд ли найдёшь обсуждение этого вопроса без балансировки, они всегда идут вместе. А если не нужно учитывать, сбалансировано дерево или нет, просто не учитывай этот фактор при подсчете весов (w1 просто отбрось).
А что касается эффективности способа, предложенного в статье - я бы к правой части формулы подсчёта весов добавил ещё соотношение получаемых частей рассекаемого объема со своим коэффициентом. Ну а онплэйновские полигоны я бы вообще не учитывал так - так как их можно записать и в список front и в список back, то это наша дополнительная фора при балансировании.
Zloy
про w1 понятно (вобщем и раньше было понятно ;-) )
про "части рассекакемого объёма" - не понятно, какой объём имеется ввиду? на входе есть просто набор полигонов, я даже готов гарантировать их выпуклость ;-)
Вообще изначально есть таблица описывающее взаимное расположении полигонов: A[i,j] может иметь три значения Positive (полигон j лежит в положительном полупространтсве полигона i), Negative (в отрицательном) и Intersected (j пересекает полоскость полигона i).
Хочется использовать эту таблицу для максимального уменьшения кол-ва разрезаний исходных полигонов, при построении BSP дерева.
PS. есть хорошее русское слово "компланарный" вместо "онплэйновский" $-)
capgreen
Про объём - у нас есть bbox сцены, есть конкретный набор полигонов при выборе очередной секущей плоскости - и для каждого поддерева существует свой объём, отхватываемый от bbox'а сцены секущими плоскостями высшего уровня - для хорошего CD полезно учитывать примерное равенство частей, на которые будет разбит этот "отхваченный" объём очередным сплиттером. Вот о чём я.
К слову о таблице - я вообще делаю гораздо более дико: храню для каждого конкретного полигона массив данных о его пересечении плоскостями полигонов сцены. Причём значений всё-таки 4 - ещё добавляется Complanar (извиняюсь за "онплэйновский"), надо же два бита использовать по-полной.
Обнаружил интересную статейку в журнале "Discrete & Computational Geometry" за 1990 год.
"Efficient Binary Space Partitions for Hidden-Suface Removal and Solid Modeling" Michael S. Paterson and F. Frances Yao.
НаконецТа... Ёще б 2ой части... :)
А когда будет вторая часть? Если не скоро, то скажите как сохранить в файл карту уровня лабиринта?
Я так понимаю, вторая часть статьи с "созданием простейших программ рендеринга игровых уровней для таких игр как Quake, Quake2 и Quake3" так и не была написана, а где можно найти исходники подобных рендеров?
katabolh
ftp.idsoftware.com
Тема в архиве.