Войти
ПрограммированиеФорумОбщее

Введение в BSP деревья или BSP для самых «маленьких». Часть первая, теоретическая. (Комментарии к статье) (6 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#75
10:26, 21 мая 2004

jm
Кроме того, мне вот кажется что leaf+pvs для открытых пространств как раз быстрее будет...
Может быть, может быть. Но тогда PVS сжимать с помощью ZLE не выгодно будет (нулей уж больно мало -- все видно вокруг -- одни единицы) :-).
А если серьезно, то черт знает как туда вобще порталы притулить -- ведь вроде их смысл в том, чтобы отображать только те полигоны, которые попадают в видимые порталы. И уж на открытой местности порталы помочь не смогут (например, гора какая-нибудь закрывает высокополигональный объект -- попробуй определи, что его не видно).
Да и как, например DeltaForc'ы сделаны -- т.е. как делается смесь открытых пространств и помещений.


#76
11:26, 21 мая 2004

в открытых пространствах вместо порталов нужно использоваль окклудеры, т. е. для уровня нужно делать специальную упрощённую копию, которая поможет двиглу определять видимость объектов. PVS для широких долин и всё такое прочее - это смерть.

#77
11:31, 24 мая 2004

tav
Ладно, спорить-то! Я же сказал, что мы говорим о разных вещах. Бред, не бред. Ты даже не попытался вникнуть мою реализацию bsp (не-классического) а уже бросаешься громкими словами.

#78
15:42, 24 мая 2004

Zlobnyi Serg
Я просто предложил возможно более эффективный способ трассировки луча.
>Ты даже не попытался вникнуть мою реализацию bsp (не-классического)
А че тут вникать. Я же пример определения пересечения луча с BBOX'ом написал, чего ж еще?

#79
9:30, 1 июня 2004

--------------------------------------------------------------------------------------------------------------------------------------------------------------
Как уже, надеюсь, понял читатель после прочтения этой статьи, не следует использовать BSP алгоритмы для открытых пространств или в проектах, требующих тотального разрушения окружающего мира. Это не даст положительных результатов из-за специфики самого алгоритма
--------------------------------------------------------------------------------------------------------------------------------------------------------------

так какой же алгоритм надо применять в проектах, требующих тотального разрушения окружающего мира?

#80
10:47, 1 июня 2004

Подскажите, пожалуйста, где можно почитать про минимизацию кол-ва полигонов в BSP-дереве (балансировка дерева не требуется)?
Насколько эфективен предложенный в статье способ сортировки по весу?

#81
10:47, 1 июня 2004

_ps_
В таких проектах надо сперва подумать - 'а за что мъ беремся...?'.

#82
16:26, 1 июня 2004

capgreen
Насчёт минимизации количества полигонов в BSP-дереве - ты вряд ли найдёшь обсуждение этого вопроса без балансировки, они всегда идут вместе. А если не нужно учитывать, сбалансировано дерево или нет, просто не учитывай этот фактор при подсчете весов (w1 просто отбрось).

А что касается эффективности способа, предложенного в статье - я бы к правой части формулы подсчёта весов добавил ещё соотношение получаемых частей рассекаемого объема со своим коэффициентом. Ну а онплэйновские полигоны я бы вообще не учитывал так - так как их можно записать и в список front и в список back, то это наша дополнительная фора при балансировании.

#83
11:17, 2 июня 2004

Zloy
про w1 понятно (вобщем и раньше было понятно ;-) )
про "части рассекакемого объёма" - не понятно, какой объём имеется ввиду? на входе есть просто набор полигонов, я даже готов гарантировать их выпуклость ;-)

Вообще изначально есть таблица описывающее взаимное расположении полигонов: A[i,j] может иметь три значения Positive (полигон j лежит в положительном полупространтсве полигона i), Negative (в отрицательном) и Intersected (j пересекает полоскость полигона i).
Хочется использовать эту таблицу для максимального уменьшения кол-ва разрезаний исходных полигонов, при построении BSP дерева.

PS. есть хорошее русское слово "компланарный" вместо "онплэйновский" $-)

#84
16:34, 2 июня 2004

capgreen
Про объём - у нас есть bbox сцены, есть конкретный набор полигонов при выборе очередной секущей плоскости - и для каждого поддерева существует свой объём, отхватываемый от bbox'а сцены секущими плоскостями высшего уровня - для хорошего CD полезно учитывать примерное равенство частей, на которые будет разбит этот "отхваченный" объём очередным сплиттером. Вот о чём я.
К слову о таблице - я вообще делаю гораздо более дико: храню для каждого конкретного полигона массив данных о его пересечении плоскостями полигонов сцены. Причём значений всё-таки 4 - ещё добавляется Complanar (извиняюсь за "онплэйновский"), надо же два бита использовать по-полной.

#85
11:08, 7 июня 2004

Обнаружил интересную статейку в журнале "Discrete & Computational Geometry" за 1990 год.
"Efficient Binary Space Partitions for Hidden-Suface Removal and Solid Modeling" Michael S. Paterson and F. Frances Yao.

#86
10:38, 28 июня 2004

НаконецТа... Ёще б 2ой части... :)

#87
23:15, 22 ноя. 2004

А когда будет вторая часть? Если не скоро, то скажите как сохранить в файл карту уровня лабиринта?

Прошло более 2 лет
#88
11:26, 23 ноя. 2006

Я так понимаю, вторая часть статьи с "созданием простейших программ рендеринга игровых уровней  для таких игр как Quake, Quake2 и Quake3" так и не была написана, а где можно найти исходники подобных рендеров?

#89
14:47, 23 ноя. 2006

katabolh
ftp.idsoftware.com

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.