Вася УткинВ какие 3Д-движки легче всего закинуть собственный 3Д мир, с его хорошо документированным входным форматом 3Д мира ?
Преобразование из имеющихся у меня данных 3Д мира в необходимый входной формат для движка я реализую, главное чтобы он был хорошо документирован и максимально прост!
Предпочтительно C/C++, но не обязательно. Win или Linux - не имеет принципиального значения.

3D движки не понимают миры.

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

Практически все уважающие себя движки умеют импортировать
обьекты из skp файлов

maytonЯ думаю сабж - это уравнение со многими неизвестными. И хуже того автор стыдливо прячет
свои собственные спецификации за загадочными метафорами типа "собственный 3д мир".

Что из себя представляет этот мир - остаётся только догадываться. Может он описан
литературно. Типа ... "смеркалось". Или "листья поблекнуть еще не успели"... Вобщем - зогадка.


Нашел прикольную разноплановую модель мира
Я думая врядли показанный в ней мир можно просто так взять и конвертнуть.

maytonлитературно. Типа ... "смеркалось". Или "листья поблекнуть еще не успели"... Вобщем - зогадка.

Кстате "смеркалось" и "поблекнуть" не есть свойствами мира , а свойствами освещения сцены.

У каждого рендера движка для этого свой API.
Движки сильно отличиются набором алгоритмов расчета теней.
Одни делают лучше но дольше , другие хуже и быстрее,
некоторые могут иметь выбор алгоритмов для оптимизации.

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

Параметры освещенности прийдется полностью заново создавать
и обьекты менять, что бы на новом движке реализовать
реалистичный оптический обман зрения.

ДохтаРЕсли в оригинальном обьекте гладкость поверхности не есть
параметром обьекта, жестко зашита в текстуру,
то пересчитать отражение движек не сможет.


Попытка из дневной сцены сделать "смеркалось" даст откровенно нереалистичный рендеринг,
и сцену придется переделавать заново под смеркалось,
Подбирая десятки источников света разной интенсивности за кадром.
Или дополнять обьекты мира свойствами материалов и гладкости поверхности понятные
конкретному 3D движку.

Под нормальный навороченный движек, нужно рефакторить обьекты реального мира.
Сложную 3D модель компоновать из частей с разными свойствами.
Дерево делать деревом , металл металом , стекло стеклом.
И собирать модель из запчастей как на заводе.

Либо играться с множеством искуственных источинков света в каждой сцене.

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

maytonПускай Уткин озвучит как у него сцена описана.

Пусть опишет , как она освещена.
Сколько источников света за кадром он использует .

В зависимости от этого можно будет советовать конвертацию , или создание мира заново.

Возможно создать все заново будет проще.

maytonПускай Уткин озвучит как у него сцена описана.


прикольная простенькая мультяшная сцена.

ДохтаРmaytonПускай Уткин озвучит как у него сцена описана.

Пусть опишет , как она освещена.
Сколько источников света за кадром он использует .

В зависимости от этого можно будет советовать конвертацию , или создание мира заново.

Возможно создать все заново будет проще.

Ответ на выделенный вопрос зависит от имеющихся вычислительных ресурсов.

множество источников света рендерится гораздо быстрее ,
чем параметризованные под движок обьекты.

Но при правильно созданных обьектах под движок
качество редеринга обектов на разных сценах более предсказуемо и маштабируемо .

Если мир маленький , то можно играться с источниками света , но когда то наступает
предел и нужно заставлять работать 3D движок в полную силу , а вместо подбора
освещенности под каждую сцену пить пиво :)

Вася УткинИли например в minecraft залили свою комнату: камера -> OpenCV 3d-reconstruct -> Point Cloud Library -> 2Schematic -> mcedit -> Minecraft

Прям в игре это круто (хотя игра хрень), но качество конечно плохое, в последнем ролике предыдущего поста выглядит гораздо лучше.

Маркетинговый совет :)

Игры с качественной графикой как правило имеют
более затемненные сцены, что бы движок в реалтайме оптимизировал рендеринг теней
которых не видно и успевал рендерить сюжет.

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

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

Рекламные ролики нужно рендерить с более яркой освещенностью сцены ,
Клинету пофик сколько рендерился ролик который он смотрит на ютубе.

maytonДок. Не знаю как сейчас но уменьшение деталей сцены лет 5 назад достигалось
за счёт LOD, MIP, Megatexture и PVS.

Мне очень сомнительно что свет в сцене ставит разработчик. Как правило это делают
дизайнеры сцены а у них свои цели и задачи.

Не совсем понял причем тут детали ( элементы) сцены.
Движку всеравно какой свет.

Свет подбирает дизайнер под нужное качество картинки и скорость редеринга.
Тут точно также как в фотографии ,
управление светом ключевой инстумент изменения качества картинки.

вот урок по одному из возможных современных методов текстурирования для игр.