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

Выбор специфичного околоигрового движка (4 стр)

Страницы: 1 2 3 4
#45
4:30, 27 янв. 2015

Потестил все три движка в полевых условиях кодом:

1) Osg. Очень противоречивые впечатления. С одной стороны, легко и без зависимостей собирается. С другой стороны, собирается около 3 часов. С одной стороны легко создать минимальную сцену и начать что-то писать, с другой - оказывается, что без зависимостей он половину форматов текстур, шрифтов и моделей не поддерживает. Многие примеры настолько кривые, что не всегда понятно, то ли он глючит, то ли работает верно. На удивление неудобная организация примеров, которые ищут ресурсы только через переменные окружения, просто запустить исполняемый файл примера нельзя(он не найдёт какие-нибудь текстурки). Все примеры выглядят как чёрт знает что и явно не являются демонстрацией возможностей движка. Вроде бы нормально структурированный и оформленный код, но местами архитектурно держится на костылях. Вообще сама концепция scene graph'а, где любая сущность впиливается в этот граф, изначально порочна. Например, если добавить в граф источник освещения, то потом при смене координат его ноды изменения никак отражаться не будут. Тени припилены совершенно сбоку и плохо вписываются в концепцию графа, плюс плохо соотносятся источники освещения для отбрасывания теней и источники, собственно, освещения. Код изобилует динамическими выделениями памяти и совершенно не очевидным её дальнейшим менеджментом. Что когда нужно удалять? - по коду далеко не всегда можно сказать. Многие сущности кажутся избыточными, либо их смысл совершенно не интуитивен, например чем может отличаться osg::Light от osg::LightSource? osg::Geode от osg::Geometry? Очень много всего происходит за спиной пользователя: установка дефолтного освещения, обработка клавиатуры, итп. В результате получается так, что начать работать и получить минимальный результат - очень легко, а получить что-то путёвое - несравнимо сложнее.

В общем сложилось такое впечатление, что Osg хорошо подходит для научной визуализации, в нём много, вероятно, полезных функций для работы с самыми разными данными, но слишком уж много архитектурных косяков и вопросов.

2) BGFX. Забавный движок, приятные примеры, поддерживает, вроде бы, примерно все функции, которые мне нужны. Но демон кроется в деталях - например, движок не так-то просто отделить от своих исходников и примеров, чтобы использовать просто хедер и либы. Местами неопрятно оформленный код(счётчики циклов вроде ii, например), в сам движок не включена нормальная реализация тех же shadow volumes, но есть пример, в котором эта техника реализована очень скромно. То есть вроде бы и есть, но пользоваться всё равно нельзя, придётся самому писать. Полностью отсутствует документация как класс. Очень мало кто пользуется движком, поэтому нет даже форума, где его бы обсуждали. Движок ещё не успели нормально обкатать на серьёзных проектах. Так что для побаловаться или для домашнего проекта - вполне отличный вариант, рекомендую попробовать тем, у кого есть время.

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

+ Показать

Напрочь и повсеместно встречается мешанина из табов и пробелов разного размера. Это такое жуткое дилетантнство, что я реально не мог поверить, что такое вообще возможно.

Но есть и приятные моменты, которые меня сильно удивили. Например, у огра очень хорошая документация, внятные примеры, в которых рассказывается не просто как сделать то-то, а как это сделать всеми возможными способами, потому что API позволяет с помощью разных вызовов использовать одну и ту же функциональность, которые окажутся кстати в различных сценариях использования. Существенное коммьюнити, которое за годы существования скрестило ogre с чем только можно: Qt, wxWidgets, CEGUI, SDL. Прямо в репозитории есть примеры обвязки. Некоторая функциональность несколько перегружена семантически по не совсем очевидным причинам. Например, чтобы просто загрузить текстуру, нужно инициализировать менеджер ресурсов, создать группу ресурсов, указать, где её искать, создать материал, назначить ему текстуру итп. Но, в отличие от osg, обычно такая функциональность вполне оправдана, просто причины реально не на поверхности. С теми же текстурами, например, семантика усложняется из-за их кэширования и стриминга. Много очень крутых архитектурных решений, которые я больше нигде не встречал. Могу рассказать, какие именно, но лучше ещё познакомлюсь с движком и составлю более полный список.

#46
4:49, 27 янв. 2015

Suslik
> Потестил все три движка в полевых условиях кодом:
ну можешь глянуть еще эти:

PixelLight - http://www.pixellight.org/_temp_site/
У них вполне крутая демка для опенсурса (я больше ни у кого не видел такого графона из бесплатных). Но с другой стороны разработчики разбежались (. Уже год один энтузиаст пытается поднять движок и начать PixelLight 2 (и даже сайт вот переделали). Но как-то пока никак. Но это если я правильно понял, надо cin спрашивать что там сейчас

SoftPixel Engine - http://softpixelengine.sourceforge.net/
один из стариков. Чем-то похож на irrlight (по коду, наверное писался на его основе). Есть много всего. Но автор прекратил разработку.

KlayGE - http://www.klayge.org/
Пилит китаец. Демки раньше были прикольными (сейчас графон уже не торт конечно). Код завален бустом и STL и довольно тяжел (при этом умудряется не тормозить на моем слабом ноутбуке, что вызывает странные впечатления
Пилит активно, недавно новую версию сделал.
На своем китайском пишет неплохие технические статьи-разборы всяких технологий

#47
8:41, 27 янв. 2015

Suslik
> Много очень крутых архитектурных решений, которые я больше нигде не встречал.
Каких например? Просто интересно.

#48
8:50, 27 янв. 2015

Suslik
> Вообще сама концепция scene graph'а, где любая сущность впиливается в этот
> граф, изначально порочна. Например, если добавить в граф источник освещения, то
> потом при смене координат его ноды изменения никак отражаться не будут. Тени
> припилены совершенно сбоку и плохо вписываются в концепцию графа, плюс плохо
> соотносятся источники освещения для отбрасывания теней и источники, собственно,
> освещения.

Это почему порочна ? Это классика.
Про лайт и изменения не понял.
Почему тени плохо вписываются ?

>В общем сложилось такое впечатление, что Osg хорошо подходит для научной визуализации, в нём много, вероятно, полезных функций для работы с >самыми разными данными, но слишком уж много архитектурных косяков и вопросов.

osg -это open source от Open Inventor, промышленного продукта для визуализации - можно подумать, что в  OGRE нету косяков и вопросов ?

#49
13:38, 27 янв. 2015

j7wk
> Каких например? Просто интересно.
например, в разных библиотеках всегда по-разному решается вопрос того, как создавать рендер-контекст для уже существующего окна, созданного пользователем. нужно каким-то образом в библиотеку передать идентификатор окна, который для каждой платформы задаётся по-своему. под виндой это HWND, под линуксом - ещё что-то, итп. вместо того, чтобы городить в интерфейсе #ifdef WIN32, контекст при создании принимает т.н KeyValuePair, который по сути является хэш-таблицей, где и ключом и значением является строка. Поэтому HWND просто переводится средствами огровских строк в строковое представление и кладётся в хэш-таблицу, с ней передаётся. Вообще вся функциональность в интерфейсе обычно дублируется, например, так:

Ogre::Mesh *mesh = meshManager->createManual("Mesh name", ...);
Ogre::Entity *entity = sceneManager->createEntity("Entity name", mesh);
и так:
Ogre::Mesh *mesh = meshManager->createManual("Mesh name", ...);
Ogre::Entity *entity = sceneManager->createEntity("Entity name", "Mesh name");
То есть указывать меш можно как по указателю, так и по его имени. Вообще для указания сущностей по имени используется удобный функционал т.н. групп ресурсов, чтобы имена не пересекались, каждый ресурс помещается во что-то вроде неймспейса, который, как и в C++, можно не использовать, тогда ресурс будет в глобальном неймспейсе. И так сделано по возможности большинство систем. В интерфейсе практически нет уродских dynamic_cast'ов, потому что "плохие случаи" каста сущностей к внутреннему формату просто разрешаются через аналог std::map<std::string, ImplementationType *> при обращении по имени. Вообще я занимался велосипедированием мультирендера и, конечно, архитектурные вопросы всегда были самыми сложными, потому что однозначного ответа на них быть не может. И Ogre оказался единственным движком, читая интерфейс которого я либо думал "да уж, действительно, надо было делать так", либо "я пока ещё не понимаю, зачем надо было делать именно так, но со временем станет ясно".


innuendo
> osg -это open source от Open Inventor, промышленного продукта для визуализации - можно подумать, что в OGRE нету косяков и вопросов ?
безусловно, в огре тоже косяков хватает(в основном это табы и пробелы, лол), но мне лично по внутреннему ощущению он показался больше продуманным и цельным, чем osg. у меня сложилось впечатление, что простая функциональность в OSG делается очень просто, а чуть сложнее - сразу существенно сложнее.
Например, просто создать окно - очень просто:

osgViewer::Viewer viewer;
А просто создать окно с отключенной вертикальной синхронизацией сразу непонятно сложнее:
  osgViewer::Viewer viewer;
  osg::ref_ptr< osg::GraphicsContext::Traits > traits = new osg::GraphicsContext::Traits(*(viewer.getCamera()->getGraphicsContext()->getTraits())); 
  traits->vsync = false; 
  osg::ref_ptr< osg::GraphicsContext > gc = osg::GraphicsContext::createGraphicsContext( traits.get() ); 
  viewer.getCamera()->setGraphicsContext(gc);
Зачем нагородили эти Traits, эти GraphicalSettings, почему их не объединить, как сделано в огре, где при создании окна просто указывается:
NameValuePairList options; 
options["vsync"] = "true";  //хэш-таблица с какими угодно параметрами
RenderWindow* renderWindow = root->createRenderWindow("Window name", 100, 100, false, &options);
Да и масштабируемость у такого подхода лучше - никогда заранее не знаешь, какие новые параметры появятся у окна в новом оконном мендежере, поэтому тут интерфейс даже менять не придётся.

innuendo
> во-первых, osg является фактически обёрткой вокруг opengl, поэтому сложных архитектурных решений для мультирендера в нём в принципе не требуется, ну, потому что рендер всего один.
> Это почему порочна ? Это классика.
пока писал этот пост с объяснением, нашёл баг с лайтом на своей стороне, так что косяк был мой. но вызван он вполне не иллюзорной путаницей между osg::Light и osg::LightSource, которые везде, даже в самом OpenGL, логически объединены в одну сущность. про "изначально порочна", возможно, я немного погорячился, буду ещё тестировать.

#50
14:46, 27 янв. 2015

Suslik
> возможно, я немного погорячился, буду ещё тестировать.

Ещё можно Coin3D посмотреть - тот ближе к OpenInventor

#51
22:07, 27 янв. 2015

Работаю с osg уже лет 8. Из достоинств могу отметить кроссплатформенность. Да конечно по современным меркам он не очень, но если вникнуть то очень даже. Есть даже пример с MultiDrawIndirect. Конечно он разрабатывался под OpenGl 2.0 но без труда в рамках osg работаю в 3.3 и opengles20. Большим достоинством является мультиформатность. Может читать и записывать кучу форматов. Например я сейчас проекты из unity перегоняю в осг. К сожалению нет редактора как в юнити, а хотелось бы. Если не нужна кросплатформенность и opengl  то наверное можно поискать другое. Но мне например для моих задач нужен теперь в сложившейся обстановке только AstraLinux и перевод моего приложения,написанного под осг у меня занял около часа, в основном делал настройку ОС и качал депендансы. Основное достоинство опенсоурс это возможность дописать код. Вот мне например нужно было воспользоваться glx_swap_control_tear, пару строчек и пожалуйста. Какой проприетарный игровой движок даст мне такую свободу?

#52
22:15, 27 янв. 2015

Adun
> Есть даже пример с MultiDrawIndirect.

Который на 5 строчек ? Про тени расскажи - что и как? Стримминг текстур есть ?

#53
22:48, 27 янв. 2015

Вот блин. Чем мне не нравится osg - это тем, что он напрочь непредсказуемый. Иногда напишешь какую-нибудь ерунду, а она работает.. странно. Иногда напишешь что-то, вроде бы, нормальное - оно не работает. Опять странно. Вот простой код:

  osg::Sphere *sphereMarker = new osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f), 20.0f); 
  osg::ShapeDrawable *drawableMarker = new osg::ShapeDrawable(sphereMarker);
  sceneGeode->addDrawable(drawableMarker);
  root->addNode(sceneGeode);
  int frame = 0;
  while(1)
  {
    frame++;
    sphereMarker->setCenter(osg::Vec3(frame * 1e-4f, 0.0f, 0.0f));
    viewer.frame();
  }
и этот код не работает - маркер просто висит в той точке, где его изначально создали. где логика? каким образом я должен изначально понять, корректен ли такой код и как его сделать корректным?

#54
23:05, 27 янв. 2015

Почему на 5 строчек? Там отдельный пример osggpucull. Да модели с текстурами не стримятся. Но есть решение записывать их  Texture2dArray ну и читать их по индексу. Тени есть, много техник. Можно в гите osgShadow посмотреть. Знаю что даже каскады сделали во flightgear. GI  нет из коробки. Пока думаю может рассчитывать light probes в юнити и накладывать их в осг. Но для моего приложения это не особо важно. Вот например я сейчас думаю как по топографическом данным в автомате дома и лес восстанавливать. А ты говоришь про тени. :) Кстати тут нвидия для линукса physx сделала. Пойду завтра попробую частицы и машину сделать. Ну и на повестке дня у меня стоит доделать модель плавучести судна. А ты говоришь про графику :).  Ну или вот например мне тут заявили что мне надо в приложении учитывать МДВ (метерологическую дальность видимости). В визуальном канале сделал так как есть модель О'Нила ну и подработал туманом, но ведь надо ещё и в тепловом сделать и не просто сделать а ещё и доказать на испытаниях.

#55
23:13, 27 янв. 2015

Suslik
А сам то что хотел от этого кода? Вместо while надо было как в примерах написать viewer.run() тогда бы подключился обработчик клавиатуры и мыши ну и водил бы мышью и камера бы перемещалась. Ну и для движения надо было бы использовать updatecallback - посмотри примеры.

#56
23:26, 27 янв. 2015

Adun
да стоит там .run(), не в камере дело. а в том, что позиция маркера не обновляется. а вот updatecallback - опять какие-то сложности на ровном месте, зачем это надо?

#57
23:32, 27 янв. 2015

Да и для того чтобы выставить позицию или поворот объекта надо бы использовать osg::MatrixTransform а так ты объект не двигаешь, а только смещаешь его центр масс.

#58
23:37, 27 янв. 2015

Updatecallback нужен для того чтобы ты в одном потоке ты позиции выставлял, в другом потоке отсекал, в третьем рисовал. Ну чтобы использовать по максимуму ЦПУ. А так ты перед каждой отрисовкой будешь считать позицию, а например она будет обновляться раз в секунду. Вот для этого нужен граф сцены.

#59
1:00, 28 янв. 2015
Что насчёт его архитектуры, можно ли малой кровью найти для него реализацию хороших stencil soft shadows?

http://blog.bonzaisoftware.com/gldemos/soft-stencil-shadows/ посмотри тут демка.
а тут тема на самом OGRE форуме, но уже довольно-таки древняя: http://ogre3d.org/forums/viewtopic.php?f=11&t=39809&sid=1… &start=75
Страницы: 1 2 3 4
ПрограммированиеФорумГрафика

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