Войти
ПроектыФорумУтилиты

UNIGINE - универсальный 3D-движок (5 стр)

Страницы: 14 5 6 726 Следующая »
#60
19:40, 8 июня 2017

binstream
Возможно я немного сумбурно высказался, поэтому покажу на рабочем проекте, что имею в виду(не сочтите за рекламу). У нас в упрощённом виде реализована вышеописанная техника (да и не только она), которая позвляет нам на 32-х битной точности иметь вот такую дальность прорисовки:
Изображение

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

Ты утверждаешь, что это невозможно и практический предел для нас 10 километров - у нас _уже_ мир 21х21 километр, его можно увидеть целиком в кадре. При этом мы даже близко ещё не подошли к лимиту, и это только геймплейное ограничение. С технической точки зрения я, как человек, который проектировал и реализовывал графическую часть этого движка (и многие из упомянутых алгоритмов), не вижу проблем сделать мир до тысячи квадратных километров :)

У вас на сайте висят промо-скриншоты, особенно второй радует:
Изображение
Изображение

Я на них посмотрел, и мне стало интересно, какие именно _алгоритмические_ вещи вы применяете для получения такой эффективности, потому, что лично мне кажется, что переход на 64-битные вычисления, по идее, должен был произойти после исчерпания всех остальных средств достижения желаемого.

#61
22:44, 8 июня 2017

Играл в CRADLE. Либо у разработчика с оптимизацией полный атас, либо движок...одно из двух. И, кстати, камушки, кустики, прорисовываются на такой же дистанции, как то есть в том же Unreal. Для сравнения: на моей железяке QUAKE: Champions, Dishonored 2, Ведьмак 3 идут идеально на максимальных настройках в FullHD. CRADLE же выдает не более 30фпс(а в палатке - и того ниже).

#62
23:21, 8 июня 2017

bazhenovc
> У нас в упрощённом виде реализована вышеописанная техника (да и не только она),

И это без всяких прокси геометрий... Меня вот больше волнует вопрос - используется у них tile resources для ландшафта ? :)

#63
23:24, 8 июня 2017

Shadeborn
> Играл в CRADLE. Либо у разработчика с оптимизацией полный атас, либо движок...одно из двух.
он не для игр предназначен - сказано же было. У него очень качественный графон и симуляция для высокопроизводительных систем.  Да на нем можно делать игры, но производительность будет раза в 2-3 хуже, чем в том же Юнити\Анриле при аналогичной сцене. Там большой упор на качество и на точность просчетов - вот и падения фпс...
вот на этом видео видно, как игра "тормозит" при отрисовке 2х персонажей и парочки замков на заднем фоне (хотя там тормозит все за редкими исключениями), при этом "туман" начинается метров с 50-ти. Если бы еще картинка была сочная или тесселяция присутствовала я бы еще понял чего оно все лагает, а так в целом ничего примечательного:
https://www.youtube.com/watch?v=WN08g6zFOdo
просто движок под игры не оптимизирован. вот и все...

#64
7:27, 9 июня 2017

Shadeborn
> Играл в CRADLE. Либо у разработчика с оптимизацией полный атас, либо
> движок...одно из двух. И, кстати, камушки, кустики, прорисовываются на такой же
> дистанции, как то есть в том же Unreal. Для сравнения: на моей железяке QUAKE:
> Champions, Dishonored 2, Ведьмак 3 идут идеально на максимальных настройках в
> FullHD. CRADLE же выдает не более 30фпс(а в палатке - и того ниже).

Cradle сделан на Unigine 1, плюс сделан не везде оптимально с технической точки зрения.

#65
7:28, 9 июня 2017

bazhenovc

Сделай ради интереса несколько сотен км в своем проекте и посмотри на краях - поймешь, о чем речь.

#66
8:56, 9 июня 2017

binstream

Несколько сотен км это неподъемный фронт работ для большинства инди. Даже ААА проекты сейчас идут по пути уменьшения контента и увеличения реиспользуемости игрового пространства - RE7, Prey и т.д. Производить контент становится всё дороже, а цены на игры не меняются в большую сторону (Только не надо про Ведьмак 3). На большом открытом пространстве сделать интересный геимплей достаточно сложная задача, и она в разы сложнее чем в indoor. Возможно вам стоит подумать над созданием урезанной версии для indie разработчиков с доступной ценой.

#67
11:14, 9 июня 2017

jocker
> Несколько сотен км это неподъемный фронт работ для большинства инди.

Он же про симуляторы, а не игры. Хотя графоний в симуляторах никогда не был главным. Насколько я знаю, в симах самолётов/вертолётов главное полное погружение вплоть до каждой пимпочки на приборной доске.

#68
13:22, 9 июня 2017

innuendo
в серьезных симуляторах настоящие кабины

#69
16:37, 9 июня 2017

binstream
> Сделай ради интереса несколько сотен км в своем проекте и посмотри на краях -
> поймешь, о чем речь.
Уже не 10, уже 100? Но не суть, у нас, если я правильно помню, ранние прототипы 500х500км были, но это не практично - огромное пустое пространство никому не интересно, никто не будет в это играть.

Ты, видимо, не понял, что я в виду имел.Смотри, представь, что у нас есть некий сектор мира размером 5х5км. Внутри него, в его локальной системе координат есть какие-то объекты. Их координаты хранятся относительно центра сегмента, то есть точки (0,0,0).
Изображение

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

Камера находится в локальной системе координат второго сектора, в первом секторе есть смещение относительно первого сектора, значит мы можем для второго сектора построить матрицу перехода в систему координат первого сектора - и сразу их нарисовать, т.к. камера уже в нужной системе координат. Ещё раз повторюсь, центры обеих секторов находятся в точке (0,0,0) и хранят смещение относительно только своих соседей.

Ну и абсолютно аналогично это всё расширяется и масштабируется дальше и дальше.
Изображение
Все 4 соседних сектора рендерятся относительно сектора с камерой, т.е. максимальное расстояние, с которым мы работаем, не превышает 10км.

А теперь следи за руками:
Изображение

Мы можем поставить камеру в любую точку этого безумия, и где бы она не стояла - везде мы будем работать с достаточно маленькими числами, потом, что всё кодируется относительно текущего сектора.

Да, безусловно, дальность видимости ограничена точностью - но в этой системе дальность отрисовки в любой точке карты будет составлять 3-4 сектора, т.к. именно вот на этом моменте начинаются проблемы с точностью. Но и для этой проблемы тоже есть разные решения :)

#70
17:01, 9 июня 2017

bazhenovc
так, как вы это описали работать корректно не будет. Представьте, что Ваша камера должна захватывать объект, находящийся в 50-и секторах от сектора, в котором расположена собственно камера. Вы тут же попадаете на точность матрицы проецирования.
Т.е. Ваше решение по сути не решает проблемы взаимодействия объект-камера, которые могут быть расположены на большом расстоянии друг от друга и, следоваетльно, не подходит для симуляторов. Хотя да, вы так можете описать достаточно большой мир
без проблем с точностью. Но это довольно известный и идейно примитивный прием.

Вообще, такие задачи не решаются легко. Помимо реализации 64-рязрядной линейной алгебры, есть еще буфер глубины, который, как ни крути, 32 бита. И вот попадать в его точность, имея удаленные объекты: вот это уже намного сложнее. Здесь
прийдется делать что-нибудь типа разбиения сцены на каскады и рендеринга каскадами с несколькими depth-тестами.

#71
17:23, 9 июня 2017

bazhenovc
Технология смещения камеры понятная, но она дает щелчки при пересечении границ секторов (а на сверхзвуке они будут быстро пролетаться), плюс она никак не решает проблему с точностью позиционирования объектов. Хочется попадать по танку противника, а не в соседний сарай.

#72
17:52, 9 июня 2017

lexer42152
> так, как вы это описали работать корректно не будет.
Я описал идею очень упрощённо и сумбурно, но у нас оно уже работает на шипнутом проекте :)

lexer42152
> Представьте, что Ваша камера должна захватывать объект, находящийся в 50-и
> секторах от сектора, в котором расположена собственно камера. Вы тут же
> попадаете на точность матрицы проецирования.
Матрица проекции тут совершенно не при делах, корень проблемы будет в относительном расстоянии в 50 секторов, из которого в свою очередь начинает вылазить всё остальное. И для решения этой проблемы тоже есть отдельные методы, и они тоже довольно простые, иногда даже очевидные :)

Если у вас камера будет на расстоянии в 5000 секторов, вас 64 битная точность тоже не спасёт.

lexer42152
> Ваше решение по сути не решает проблемы взаимодействия объект-камера, которые
> могут быть расположены на большом расстоянии друг от друга и, следоваетльно, не
> подходит для симуляторов.
Не решает, я вроде так и написал :)

lexer42152
> Но это довольно известный и идейно примитивный прием.
Да, простой, как топор :)

lexer42152
> Помимо реализации 64-рязрядной линейной алгебры, есть еще буфер глубины,
> который, как ни крути, 32 бита. И вот попадать в его точность, имея удаленные
> объекты: вот это уже намного сложнее. Здесь
> прийдется делать что-нибудь типа разбиения сцены на каскады и рендеринга
> каскадами с несколькими depth-тестами.
Ещё есть reverse depth, и ещё десяток трюков обхота аппаратных ограничений - я про это тоже писал.

lexer42152
> Вообще, такие задачи не решаются легко.
Вот я именно на эту тему и хочу подискутировать :) Это же интересно и познавательно, но Дэн почему-то отмахнулся фразой "иди сделай мир 100х100км"

binstream
> Технология смещения камеры понятная, но она дает щелчки при пересечении границ
> секторов
Она не даёт щелчков, при переходе из одной системы координат в другую обычно оперирует числами допустимой разрядности, т.к. все значения локальны для сектора. Разумеется, важно правильно подобрать размер сектора.

> (а на сверхзвуке они будут быстро пролетаться)
Ну и что?

binstream
> плюс она никак не решает проблему с точностью позиционирования объектов
Нет, она решает проблему с точностью позиционирования. Она не решает проблему максимальной дальности отрисовки.

К слову, 64 битные координаты тоже не решают эту проблему :) Они её отодвигают. Достаточно далеко, но тем не менее. Площадь нашей планеты - 510 миллионов квадратных километров, чтобы адекватно представть её - простого перехода на 64 битные координаты будет недостаточно ;)

На всякий случай добавлю - мне не интересен срач, я хочу просто подискутировать на интересную техническую тему и, возможно, узнать для себя что-то новое, поэтому давайте попробуем говорить конструктивно :)

#73
18:23, 9 июня 2017

binstream

Я так понял и depth buffer тоже 64 битный ?

#74
19:25, 9 июня 2017

bazhenovc
Денис ведь директор, он не обязан знать детали реализации.
Потому и показывает картинки "Unigine vs обычное моющее средство" и рассказывает о том, как самолеты бороздят просторы 64-х битного пространства на сверхзвуковых скоростях.

Страницы: 14 5 6 726 Следующая »
ПроектыФорумУтилиты