- betauser
- Постоялец
betauser
а про свой формат можно поподробнее? бсп-древо или порталы?
betauser
судя по цене некоммерческой (демки\учебной) лицензии - о стоимости полноценной [а возможно она еще будет привязана и количеству проектов...рабочих мест...блаблабла...и роялти не исключаются возможно] можно уже догадаться =). а функциональность будет где-то в районе как у платной "демки" Unigine - то есть можно побаловаться со скриптами [возможно их политика уже изменилась, не знаю, уже неинтересно] или побогаче ? =)...
для кого делаете-то? для русских одиночек\мелких конторок, которым непосилен в принципе Unreal Warfare\Gamebryo\Source или для компаний (которые ранее перечисленные движкив состоянии спокойно купить).
уж лучше (в который раз) обратиться НЕ к отечественным разработчикам, ибо от них одни разочарования\обломы (за масюсенькими исключениями, которые пока что еще есть - но это из области обычного софта).
P.S. в общем безрадостно как-то. не обижайся и не сочти за флуд.
и еще важный вопрос - что там с мультиплеером.
хотя бы по обычной локалке?
g-cont
Формат карты, грубо - это список сущностей расставленных на карте.
На основе сущностей построен менеджер сцены.
Сейчас реализована портальная система. Можно смешивать indoor и outdoor пространства (ставя т.н. outdoor порталы).
Также можно расставлять окклюдеры (которые перекрывают порталы).
Полностью динамическая система. не нужно предрасчетов как в bps.
+ вся статика режет на тайлы (octree)
для определения видимости мы бегаем по octree и порталам.
включите в игре FrustumTest режим (в Menu->Debug->Frustum Test).
так будет нагляднее.
froqus
SDK - это не побаловаться со скриптами.
Это полноценный API для разработчика.
Вся демка которую вы видели (все тематические комнаты) сделаны на основе NeoAxis API.
Т.е. если эти демки на ваш взгляд - так.. баловство, то да. вы правы. :)
g-cont
Поддержки сети пока нет.
Она будет несколько позже.
Без сети такой движок не может стоить 7000 долларов.
А когда вы введете сетевой код наружу всплывет масса мелких пакостей, вплоть до тех, которые пойдут вразрез с архитектурой движка. Например очень интересно посмотреть как будет работать ODE в условиях сетевых лагов.
betauser
Можно про outdoor-порталы ссылочку?
>Полностью динамическая система. не нужно предрасчетов как в bps.
"Динамическая система" это комбинация octree + еще что-то? Или это BVH?
>+ вся статика режет на тайлы (octree)
В случае, когда примитив пересекает границы узла, режете его на части или используете mailboxing? Интересно что-то :)
и еще вопрос. Если карты у нас не компилируются, то как свет считать? или там реалтайм попикселка?
онож тормозит на слабых машинах, а коммерческий движок должен иметь вполне определенную минимальную конфу и чем она слабее, тем лучше для движка.
chiaroscuro
outdoor-порталами я называю порталы, которые соединяют одну зону и outdoor пространство.
indoor-порталы (или просто порталы) соединяют две indoor зоны.
не знаю, может кто еще так говорит, но имхо достаточно логичное название :)
вот как пример. в комнатах дома зоны. окна - это outdoor-порталы.
http://www.neoaxisgroup.com/screenshots/outdoorportals.jpg
Мененджмент сцены.
Есть один octree на всю карту.
Вся статика режется на тайлы размерами octree нод. Куски кладутся в octree ноды.
Перед рендером мы весело определяем видимость octree нод.
Т.е. после определения у нас есть данные какая нода видна, а какая нет.
Видимость определяем учитывая octree и перемещяясь по порталам.
Во фрустуме видим порталы и заходим в них. патом в следующие порталы из тех и т.д.
Для динамики принцип почти не отличается.
g-cont
Я говорил о менеджменте сцены.
Про лайтмапы. Лайтмапы можно заимпортить со стороны, а в скором времени можно будет расчитать в редакторе карт.
Сейчас я как раз занимаюсь этим. Будет расчетчик GI прямо в редакторе.
nicksoft
наработки, диздок есть?
betauser
>outdoor-порталами я называю порталы, которые соединяют одну зону и outdoor пространство.
да, теперь ясно :) Outdoor-пространство определяет дизайнер уровня (просто не могу сообразить, как это можно автоматизировать)?
>мы весело определяем видимость octree нод.
эммм... "весело" это используя какую-нибудь форму occlusion culling? (какую именно? =))
>Видимость определяем учитывая octree и перемещяясь по порталам.
А как определяете видимость портала? Находите проекцию в screen space? Или тестом frustum vs aabb/triangle/sphere/obb?
>Во фрустуме видим порталы и заходим в них. патом в следующие порталы из тех и т.д.
Получается такой рекурсивный обход, понятно. А порталы определяет дизайнер уровня? O_o
>Будет расчетчик GI прямо в редакторе
Интересно, а как будет рассчитываться освещение? Редактор ведь WYSIWYG, а тут global illumination..
>Интересно, а как будет рассчитываться освещение
да мне тоже интересно, как это соотносится с тем что карта не компилируется.
лайтмапы в отдельный файл будут писатся или обычными Tgaшками врассыпную?
>да, теперь ясно :) Outdoor-пространство определяет дизайнер уровня (просто не могу сообразить, как это можно автоматизировать)?
нет. outdoor-пространство никто не определяет. оно изначально есть. :)
т.е. то что не indoor-зона, то outdoor-пространство.
>эммм... "весело" это используя какую-нибудь форму occlusion culling? (какую именно? =))
не. я не использовал какой-то известный алгоритм. просто определяю видимость на каждом кадре полностью.
конечно способ не быстрый, но для начала я думаю этого вполне достаточно.
>А как определяете видимость портала? Находите проекцию в screen space? Или тестом frustum vs aabb/triangle/sphere/obb?
я посматривал на эту статью.
Так идея в том, что есть выпуклые портал фрустумы. и для двух таких портал фрустумов можно легко находить общее.
http://www.gamedev.ru/articles/?id=30118
> Получается такой рекурсивный обход, понятно. А порталы определяет дизайнер уровня?
да. расставляет их руками.
хотя есть идея как-то это автоматизировать, но я пока не придумал ничего хорошего.
скажите если есть идеи :)
> Интересно, а как будет рассчитываться освещение? Редактор ведь WYSIWYG, а тут global illumination..
ну зная данные о статичном свете (дизайнер источники наставил),
мы считаем текстуры лайтмапы и натягиваем их на статику.
> да мне тоже интересно, как это соотносится с тем что карта не компилируется.
> лайтмапы в отдельный файл будут писатся или обычными Tgaшками врассыпную?
ну да. складируются в директории в виде файлов (текстуры) и
данных о текстурных координатах для лайтмап слоя.
betauser
ну тогда ждем скринов с проссчитанным освещением :)
betauser
Некоммерческая лицензия (SDK) - огорчила...
Чтоб посмотреть изнутри, научится работать с движком - надо заплатить 130 $
Демка - да все ок (редакторы клас). А вот попробывать его в експлуатации как программист немогу - жаль.
Вот непонимаю немного такого подхода. В таком случае вы лишаетесь (N - ного количества) бесплатных тестеров вашего движка!
betauser
>нет. outdoor-пространство никто не определяет. оно изначально есть. :)
Блин, это я не догадался :)
>скажите если есть идеи :)
Идей нет - где-то читал даже, что это невозможно в сделать в общем случае. Можно, конечно, порталы сделать как "окна" между смежными листьями (я даже делал когда-то такое для leaf BSP), правда, тогда количество порталов и их размер явно проигрывают "ручной работе".
Опа - вот нашел "Automatic Cells-And-Portals Decomposition": http://www-evasion.imag.fr/Publications/2003/LH03/lefebvre-hornus-portals.pdf
Что-то самому интересно стало :)
