А я не могу представить себе, например, ранофовский бункер модельной геометрией. Они что там все, куски стен делают моделями?
По-моему на современных компах такая оптимизация, как на движке Анриал 3 всё ещё не так хороша как сорсовский вис. Хотя не знаю... просто на сорсе там одновременно рендерится больше, но при этом переходы между листьями реже, меньше запросов на догрузку новых полигонов. А там где баундинг бокс одной модели скрывается, как только перестаёт быть видимым за другой моделью... там процесс оптимизации больше процессор загружает (или что там он загружает) чем прорисовка моделей целиком... когда в экране постоянно идёт отслеживание и просчёт видимости каждого объекта... Да ну нах, листья рулят)))
Их много получается - если на карте несколько тысяч объектов + 20-30 обьектов содержащих окклудеры (которые к тому же дублируют друг-друга во многих случаях) - там из этих копеек может накапать рубль. Но процы становятся мощнее, алгоритмы - умнее и а динамический окклюжен прост и удобен для конечного "пользователя" - маппера. Из вышедших за последние годы движков я ни в одном аналога VVIS уже не видел.
>Их много получается - если на карте несколько тысяч объектов
Ну проверка видимости в любом случае занимает на порядки меньше времени чем отрисовка модели. Трансформировать 8 вершин (или побольше если по сферам или каким-то более сложным коробам=), немного короче) и растеризовать с проверкой по збуферу - это в любом случае _vs_ трансформировать хотя б 500-1000 вершин + растеризация, тяжеленные пиксельные шейдеры в среднем 300-500 треугольников, это по минимуму, в самом пессимистичном случае. Это ж аццкий труд. Другое дело отношение видимых/невидимых объектов, оно то как раз таки важно. В сложных сценах куча перекрытий.
>Но процы становятся мощнее
А VVIS разве не деревья строит навроде octree?
Я мож отстал, кажись BBox везде есть?)
Ну проверка видимости в любом случае занимает на порядки меньше времени чем отрисовка модели.
Да, только проверку видимости модели (в отличие от отрисовки геометрии) осуществляет наш медленный CPU общего назначения, загруженный еще кучей задач.
Цитата:
А VVIS разве не деревья строит навроде octree?
VVIS всегда BSP-деревья строил (и всегда - делал это минутами и часами в оффлайн режиме компиляции карты), а в игре source по видимому просто получает данные для текущего листа - какие листья из него видно по оффлайн-рассчетам VVIS-а - и рендерит только их содержимое. И так для каждого листа, в котором может оказаться игрок (что и делает рассчеты VVISа безумно долгими при увеличении числа листьев выше нескольких тысяч). Реалтаймовое отсечение по BBох'ам в сорсе тоже есть, но только для моделей (с помощью окклудеров-брашей, расставленных в нужныхм местах) - на ворлд браши оно не распостраняется.
И куча других иконок, указывающих на то, что Source2 будет иметь all-in-one игровой редактор.
4. Скорее всего вальв откажется от vgui и будет использовать исключительно qt для интерфейса как редактора так и самого движка.
5. Известно, что Dear Esther тоже связан с Source2 (возможно использует его или его редактор)
Уже хочется искать в этом бессмысленную шараду от валв и начинать её решать. Хотя да, я бы посмотрел, что бы они сделали. Если они действительно это сделают. Вдруг это будет был бы сорс с полной поддержкой дх11
Оригинальное сообщение от Research И с этой стороны они начинают троллить! Официально говорят что нет смысла в Source 2, а сами намеренно пилят намеки. Valve-style.
Они давненько это говорили. А смысл очень есть, особенно учитывая их наполеоновские планы с консолями.
??
Мне что, присоединиться к толпе недовольных, которые орут что консоли тормозят игровую индустрию? Если следующий движок от валв не будет поддерживать дх11, то