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

Вышел NeoAxis Engine 2019.3 (4 стр)

Страницы: 13 4 5 652 Следующая »
#45
17:07, 18 мар. 2007

betauser
а про свой формат можно поподробнее? бсп-древо или порталы?


#46
17:14, 18 мар. 2007

betauser
судя по цене некоммерческой (демки\учебной) лицензии - о стоимости полноценной [а возможно она еще будет привязана и количеству проектов...рабочих мест...блаблабла...и роялти не исключаются возможно] можно уже догадаться =). а функциональность  будет где-то в районе как у платной "демки" Unigine - то есть можно побаловаться со скриптами [возможно их политика уже изменилась, не знаю, уже неинтересно] или побогаче ? =)...

для кого делаете-то? для русских одиночек\мелких конторок, которым непосилен в принципе Unreal Warfare\Gamebryo\Source или для компаний (которые ранее перечисленные движкив состоянии спокойно купить).

уж лучше (в который раз) обратиться НЕ к отечественным разработчикам, ибо от них одни  разочарования\обломы (за масюсенькими исключениями, которые пока что еще есть - но это из области обычного софта).
P.S. в общем безрадостно как-то. не обижайся и не сочти за флуд.

#47
17:25, 18 мар. 2007

и еще важный вопрос - что там с мультиплеером.
хотя бы по обычной локалке?

#48
17:37, 18 мар. 2007

g-cont
Формат карты, грубо - это список сущностей расставленных на карте.

На основе сущностей построен менеджер сцены.
Сейчас реализована портальная система. Можно смешивать indoor и outdoor пространства (ставя т.н. outdoor порталы).
Также можно расставлять окклюдеры (которые перекрывают порталы).
Полностью динамическая система. не нужно предрасчетов как в bps.
+ вся статика режет на тайлы (octree)
для определения видимости мы бегаем по octree и порталам.

включите в игре FrustumTest режим (в Menu->Debug->Frustum Test).
так будет нагляднее.

froqus
SDK - это не побаловаться со скриптами.
Это полноценный API для разработчика.

Вся демка которую вы видели (все тематические комнаты) сделаны на основе NeoAxis API.
Т.е. если эти демки на ваш взгляд - так.. баловство, то да. вы правы. :)

#49
17:54, 18 мар. 2007

g-cont
Поддержки сети пока нет.
Она будет несколько позже.

#50
20:20, 18 мар. 2007

Без сети такой движок не может стоить 7000 долларов.
А когда вы введете сетевой код наружу всплывет масса мелких пакостей, вплоть до тех, которые пойдут вразрез с архитектурой движка. Например очень интересно посмотреть как будет работать ODE в условиях сетевых лагов.

#51
6:42, 19 мар. 2007

betauser
Можно про outdoor-порталы ссылочку?
>Полностью динамическая система. не нужно предрасчетов как в bps.
"Динамическая система" это комбинация octree + еще что-то? Или это BVH?
>+ вся статика режет на тайлы (octree)
В случае, когда примитив пересекает границы узла, режете его на части или используете mailboxing? Интересно что-то :)

#52
13:20, 19 мар. 2007

и еще вопрос. Если карты у нас не компилируются, то как свет считать? или там реалтайм попикселка?
онож тормозит на слабых машинах, а коммерческий движок должен иметь вполне определенную минимальную конфу и чем она слабее, тем лучше для движка.

#53
13:47, 19 мар. 2007

chiaroscuro
outdoor-порталами я называю порталы, которые соединяют одну зону и outdoor пространство.
indoor-порталы (или просто порталы) соединяют две indoor зоны.
не знаю, может кто еще так говорит, но имхо достаточно логичное название :)

вот как пример. в комнатах дома зоны. окна - это outdoor-порталы.
http://www.neoaxisgroup.com/screenshots/outdoorportals.jpg

Мененджмент сцены.
Есть один octree на всю карту.
Вся статика режется на тайлы размерами octree нод. Куски кладутся в octree ноды.

Перед рендером мы весело определяем видимость octree нод.
Т.е. после определения у нас есть данные какая нода видна, а какая нет.
Видимость определяем учитывая octree и перемещяясь по порталам.
Во фрустуме видим порталы и заходим в них. патом в следующие порталы из тех и т.д.

Для динамики принцип почти не отличается.

g-cont
Я говорил о менеджменте сцены.
Про лайтмапы. Лайтмапы можно заимпортить со стороны, а в скором времени можно будет расчитать в редакторе карт.
Сейчас я как раз занимаюсь этим. Будет расчетчик GI прямо в редакторе.

nicksoft
наработки, диздок есть?

#54
14:48, 19 мар. 2007

betauser
>outdoor-порталами я называю порталы, которые соединяют одну зону и outdoor пространство.
да, теперь ясно :) Outdoor-пространство определяет дизайнер уровня (просто не могу сообразить, как это можно автоматизировать)?
>мы весело определяем видимость octree нод.
эммм... "весело" это используя какую-нибудь форму occlusion culling? (какую именно? =))
>Видимость определяем учитывая octree и перемещяясь по порталам.
А как определяете видимость портала? Находите проекцию в screen space? Или тестом frustum vs aabb/triangle/sphere/obb?
>Во фрустуме видим порталы и заходим в них. патом в следующие порталы из тех и т.д.
Получается такой рекурсивный обход, понятно. А порталы определяет дизайнер уровня? O_o
>Будет расчетчик GI прямо в редакторе
Интересно, а как будет рассчитываться освещение? Редактор ведь WYSIWYG, а тут global illumination..

#55
14:53, 19 мар. 2007

>Интересно, а как будет рассчитываться освещение
да мне тоже интересно, как это соотносится с тем что карта не компилируется.
лайтмапы в отдельный файл будут писатся или обычными Tgaшками врассыпную?

#56
15:36, 19 мар. 2007

>да, теперь ясно :) 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шками врассыпную?
ну да. складируются в директории в виде файлов (текстуры) и
данных о текстурных координатах для лайтмап слоя.

#57
23:14, 19 мар. 2007

betauser
ну тогда ждем скринов с проссчитанным освещением :)

#58
2:53, 20 мар. 2007

betauser
Некоммерческая лицензия (SDK) - огорчила...
Чтоб  посмотреть изнутри, научится работать с движком -  надо заплатить 130 $
Демка - да все ок (редакторы клас). А вот попробывать его в експлуатации как программист немогу - жаль.
Вот непонимаю немного такого подхода.  В таком случае вы лишаетесь (N - ного количества) бесплатных тестеров вашего движка!

#59
6:55, 20 мар. 2007

betauser
>нет. outdoor-пространство никто не определяет. оно изначально есть. :)
Блин, это я не догадался :)
>скажите если есть идеи :)
Идей нет - где-то читал даже, что это невозможно в сделать в общем случае. Можно, конечно, порталы сделать как "окна" между смежными листьями (я даже делал когда-то такое для leaf BSP), правда, тогда количество порталов и их размер явно проигрывают "ручной работе".
Опа - вот нашел "Automatic Cells-And-Portals Decomposition": http://www-evasion.imag.fr/Publications/2003/LH03/lefebvre-hornus-portals.pdf
Что-то самому интересно стало :)

Страницы: 13 4 5 652 Следующая »
ПрограммированиеФорумОбщее