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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
#45
14:55, 15 мая 2004

tav
Я делал BSP-компилятор, полностью и до конца, причём с оптимизацией (это долго). Однако он работает на файлах моего формата, перегоняемых из ASE-формата моим перегонщиком, который я сейчас переделываю. Плюс у меня всё на Си и комментарии очень смешные. Времени на переделку всей этой байды пока нет, но выслать на мыло всё это могу.


#46
15:45, 15 мая 2004

Zloy
А у тебя портализация + построение PVS есть?

#47
12:23, 16 мая 2004

Zloy
>Я делал BSP-компилятор, полностью и до конца, причём с оптимизацией...
Ну и как. Вообще не глючит, что-ли? На очень больших сценах, например. Если глюки, были, то можешь поделиться как с ними справиться? И было ли "откусывание" части сцены (очень-очень сложного её объема -- тот глюк, который я не устранил).

#48
13:23, 16 мая 2004

Кстати, в статье про solid BSP написано. А для чего оно нужно вобще? Для коллизий? И где, тогда, про это можно прочитать? А то че-то столкновения классическим BSP расчитывать у меня не получилось.

#49
22:25, 16 мая 2004

tav
Именно solid-BSP и есть сила. Для колизий, тестов на попадение в сектор.

#50
1:37, 17 мая 2004

Zemedelec
Честно говоря так из статьи до конца и не понял зачем это "solid" надо. Почему скажем обычное деревце не подходит? Вполне можно обойтись NULL-терминатором для того пространства, где нет геометрии, а не тянуть за уши какой-то solid-узел c флагом isSolid...Можешь объяснить вкратце суть?

#51
12:32, 17 мая 2004

Джо
Тъ думаю не понял.
Solid - ето когда ВСЕ полигонъ участвуют в дереве, а non-solid - совсем необязательно все, т.е. когда скажем они образуют convex множество, можно остановится разбивать.
Таким образом solid дерево своими узлами и листьями задает 'контур' всей поверхности уровня, а non-solid - нет.

#52
16:06, 17 мая 2004

Zemedelec
Извини, портализации пока нет. Да и дерево строится node-based. Правда, ввиду особенностей алгоритма перестроить его под листья несложно. К сожалению, пока мне всем этим заниматься некогда.
tav
Глюки были, конечно. Но только их частота зависит не от количества полигонов, а от их "плотности". Да, бывало, откусывало части полигонов. Лучший метод борьбы с этим - отслеживание попадания точек прямо на секущую плоскость и увеличение EPSILON (см. статью). Только не увеличивай EPSILON слишком, 0.001 - 0.0001 достаточно.

#53
0:29, 18 мая 2004

Джо
>Zemedelec
>Честно говоря так из статьи до конца и не понял зачем это "solid" надо. Почему
>скажем обычное деревце не подходит? Вполне можно обойтись NULL-терминатором для
>того пространства, где нет геометрии, а не тянуть за уши какой-то solid-узел c
>флагом isSolid...Можешь объяснить вкратце суть?

Блин ну написал же уже один раз что это моя промашка :)
Повторим еще раз - без экстра узла вполне можно обойтись. Избыточность.

Что до разницы,
solid вариант отличается еще и в процедуре генерации.

wat
Серег, сделай пожалуйста сноску на основе одного из комментариев к статье, когда я писал об этом.

#54
0:31, 18 мая 2004

hardcoder
>jm
>>> ...некоторые источники в Интернет анализировавшие код украденной альфа
>>>версии Дум 3 предполагают...
>
>Речь идет о исполняемом коде или исходниках?

конечно о реверсированном коде :)
исходники могли утечь только в апреле с подачи CyberDemon'а ;)

#55
0:36, 18 мая 2004

FLashM
>Одного не понимаю:
>Для Leaf BSP и просто BSP Z-Buffer для прорисовки уровня не нужен, но как тогда

для leaf bsp zbuffer нужен.

>прорисовывать персонажей?

да как угодно :) возьми банальный алгоритм художника ;) Только придется подумать как связать его с BSP ;)

а вообще, если тебя потянуло в сторону седой старины и софтверного рендеринга поищи pdf
Rambling in realtime / Michael Abrash /
Хотя там на сколько я помню все решили именно наличием программного z-buffer'а

#56
2:55, 18 мая 2004

jm
Я тебя тоже поздравляю с очередной грамотной статьей :)
Чую, скоро можно будет издавать и твою книгу. Заранее встаю первым в очередь за автографом ;)

#57
13:07, 18 мая 2004

jm
Не без z-buffer-а не обойтись никак, если только 'голое' BSP не рисовать.

#58
15:13, 18 мая 2004

Zemedelec
>jm
>Не без z-buffer-а не обойтись никак, если только 'голое' BSP не рисовать.

О голом в статье и шла речь. А так бесспорно. Раньше еще можно было порассуждать или хотя бы попытаться, а сейчас однозначно z-buffer...

#59
15:42, 18 мая 2004

Кстати, насчет того, что ф-ии Split_Polygon в И-нете я не нашел, это я ошибся. Еще как нашел. Очень давно правда, даже на винт статейку сохранил (сайт 3D Universe). Но со временем забыл про нее. А там, кстати есть одна интересная особенность. И дело не в том, что полигоны там не из индексов, а из самих вершин, а том что В ПОЛИГОНЕ ХРАНИТСЯ ИНФО О ЕГО НОРМАЛИ. Вообще-то, я еще не глядя на тот код, просто прочитав статью, сделал BSP-компилятор, были глюки, которые я хотел устранить именно таким способом (хранением нормали каждого полигона). Я сам так решил сделать, а то, что в статье этот метод используется, только сейчас заметил. Короче, тестировал, я сейчас, раз 50 в уме алгоритм деления полигонов свой "продвинутый", ошибок не нашел, вроде дублирование вершин не происходит, лишние не создаются, а глючит на некоторых сценах кошмарно (глюк оказался тот же, хоть я думал, что я его устранил). Вобщем, плюнул я на все, и решил сделать как давно хотел -- расчитывать нормали полигонов еще до создания BSP, а дублирование вершин в полигонах фиг с ним. Тогда это дублирование не может повлиять на уравнение очередной делящей плоскости (ну и что, что если нулевые отрезки). Всех глюков как не бывало.

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

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