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

Доклад о порталах и секторах (Комментарии к статье) (3 стр)

Страницы: 1 2 3
#30
8:57, 27 дек. 2004

winter
>Это было бы прекрасно. Я и сам сейчас занят по самые уши, а после Нового Года будут окна в распорядке. Написать вместе статью с
>примерами было бы здорово. На всякий случай, мой мейл -
Лучше заходи на канал IRC #gamedev, там я бываю во всё рабочее время... Там и пообщаемся в онлайне. Может и Сергей в этот момент заглянет.


#31
11:29, 27 дек. 2004

Zemedelec
>Участие человека в данном процессе - лиш для расставления самих порталов.

По моему, даже это «лишь» - уже слишком много. Надо уходить от этого, - снимать с левелдизайнеров несвойственную им (лишнюю) работу.

#32
14:48, 27 дек. 2004

arabesc
Почему это написано здесь, а не в статье?..
В статье, да с цифрами для low- и hi-poly, с картинками проблемных ситуаций, с информацией о производительности и масштабируемости алгоритмов, с примерным временем реализации - вот что было бы по настоящему ценно!

Ну, как начало не я писал статью.. :)
У меня времени как-то нет, и то не написание, а именно на сравнительнъе тестъ, графики и чистую имплементацию, за что - самому жаль.

sav
Ну, ето уже совсем другая задача. Для low-poly (Q1,Q2) сцен я видел работъ которъе ето делали, и то - бъстро. Для более hi-poly - нет. Там разбиение BSP скажем дает очень много ячеек и те-же евристики работают уже плохо, ибо понятие 'комната' немного улетучивается и разбивается на много частей - его труднее уловить. Всякие разбиение пространства на воксели по которъм следить именно теснъе места - мне там непонятно как найти уже сам портал. Т.е. место где тесно и есть переход из более-менее большего пространства в другое найти как-то - можно, но...
Иначе да, я согласен что дизайнерам ето несвойственно, но сделать ето (если научить как правильно) им будет легко, ибо в сравнении с самим моделлингом ето мало работъ.

#33
16:14, 27 дек. 2004

Zemedelec
>Иначе да, я согласен что дизайнерам ето несвойственно, но сделать ето (если
>научить как правильно) им будет легко, ибо в сравнении с самим моделлингом ето
>мало работъ.

Опять же, эта работа проста только для простых уровней сделанных по жёсткой концепции типа коридор-комната. Там понятно куда пихать порталы, при усложнении структуры этот процесс становится менее очевидным, приходится ставить вмести несколько порталов и т. п. Возникают мысли: «а может здесь лучше поставить окклюдер вместо порталов?» и т.д. В том числе дизайнер должен примерно оценивать «стоимость» работы портала/окклюдера, т.е. какого размера (число полигонов) кусок пространства нам выгодно порталить, а какой оставить как есть.

#34
17:32, 27 дек. 2004

sav
Нет, порталъ ставят не на кусок пространства (если конечно плотность сценъ везде не одинакова) или количество полигонов, а именно в узкие места. В сценъ где явно открътое пространство и надо оклюдерами отсекать, просто порталами такое решать не стоит даже пробовать.
В итоге - порталъ ставятся только в 'узкие' места, откуда откръвается новъе части сценъ. Двери, окна, поворотъ коридоров, комнатъ + порталъ не должнъ разсекать большие помещения. И видеть каждъй портал должен мало других порталов (что при открътъх сценах 'затолкнет' все порталъ поглубже в комнатъ и коридоръ).

#35
18:14, 27 дек. 2004

Zemedelec
>В итоге - порталъ ставятся только в 'узкие' места, откуда откръвается новъе
>части сценъ.
Дело в том, что это «узкое место» не обязательно имеет конвексные формы (ведь порталы у нас выпуклые?). Запросто могут получаться всякие Г-образные, Т-образные и прочие порталы. Которые получаются из двух трёх и более простых порталов. Зачастую проще это описать одним большим порталом, но ситуации бывают разные.

Или скажем другой пример. Находится у нас на поляне домик с окнами, окон много. Соответственно возникают множество вариаций: делаем каждое окно отдельным порталом, делаем под несколько окон один портал, вообще не ставим порталов. Причём каждый из этих вариантов в зависимости от контекста может быть самым лучшим.

#36
18:23, 27 дек. 2004

sav
>Причём каждый из этих вариантов в зависимости от контекста может быть самым лучшим.
Вот в том-то и дело, что нужно затачивать алгоритм под каждую конкретную задачу... Ну а если у дизайнера возникнет тупиковая ситуация, то он свегда может посоветоваться с программистом что и как ему сделать...

#37
18:48, 27 дек. 2004

BANG
>Вот в том-то и дело, что нужно затачивать алгоритм под каждую конкретную
>задачу...
Не понял, можно поподробнее?

>Ну а если у дизайнера возникнет тупиковая ситуация, то он свегда
>может посоветоваться с программистом что и как ему сделать...
Число таких «совещаний» нужно сводить к нулю. Да и к тому же, я не уверен, что программер так сходу назовёт правильный вариант…

#38
18:59, 27 дек. 2004

sav
А я нигде не говорил что портал надо ставить только в конвексную область и что он не может пересекатся с геометрией. Для обьединения окон в один портал можно художникам дать какую-то евристику - в одной плоскости и ( больше 4-ех или на расстоянии меньше своей собственной ширинъ).

#39
19:32, 29 дек. 2004

Могу предложить еще один алгоритм: дизайнеры вручную присваивают треугольники секторам, а порталы генерятся автоматически как полигоны, собранные из ребер между треугольниками разных секторов. Для low-poly неплохо работает, хотя тут много зависит от инструментария (редактора уровней) :)

Плюс - нет требований к топологии геометрии, а также геометрия сектора не обязатально должна быть замкнута (без микротрещин :) ) и выпуклая.

#40
12:47, 3 янв. 2005

Hax
Ну, метод хорош, ето да. Есще меньше ограничений к геометрии, вот только нельзя портал поставить в воздух или так чтобъ хоть одно ребро там лежало. А сделать портал по 'висящим' в воздухе ребрам тоже будет сложно (если куски геометрии несвязаннъе). Но ето так, такое почти нигде не бъвает.
Единственное что възъвает легкое сомнение, ето переделка некоторой части уровня и особенно если надо портал подвинуть или поставить как-то косо, несвязъвая его с реальной геометрией. Ибо в етом методе порталъ задаются геометрией, а по идее ето не так.
Лично я знаю что етот метод юзается хотя двумя комерческими тайтлами. Не мне он подсознательно как-то не нравится... ;)

Страницы: 1 2 3
ПрограммированиеФорумГрафика

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