Безшовный мир
04 апреля 2017 08:06
Привет.
Только начинаю изучать возможности движка, подскажите пожалуйста,
очень интересует возможность создавать огромные безшовные карты.
Т.е. можно ли путем загрузки и выгрузки ресурсов сделать огромный мир и чтобы это не сказалось на требованиях к памяти и т.п.?
На пример, планету на миллион квадратных км.
Если такое можно, подскажите куда смотреть?
Только начинаю изучать возможности движка, подскажите пожалуйста,
очень интересует возможность создавать огромные безшовные карты.
Т.е. можно ли путем загрузки и выгрузки ресурсов сделать огромный мир и чтобы это не сказалось на требованиях к памяти и т.п.?
На пример, планету на миллион квадратных км.
Если такое можно, подскажите куда смотреть?
11 апреля 2017 12:19
Уважаемые разработчики, неужели вы оставите без ответа данный животрепещущий вопрос? Хотелось бы узнать таки ваше авторитетное мнение.
12 апреля 2017 11:21
Ну, чтобы не упираться в память, придется делать динамическую подгрузку/выгрузку целых блоков карты. Сама подгрузка описана в этой статье: Меблируем комнату. Часть 1: Динамическая загрузка
Сам процесс подгрузки может занимать ощутимое время, в течение которого будет проседать fps. Он складывется из 2 этапов:
- сначала непосредственно загрузка данных по сети,
- затем подготовка движком объектов/ресурсов для отрисовки
Первый в случае слабой сети всегда будет проблемой - ну, это понятно. Вообще имеет смысл заранее начать грузить данные, ещё до того, как они понадобятся движку, чтобы в нужный момент нам пришлось бы тратить время только на их подготовку, т.е. только на 2 этап. Для этого есть метод prefetch, который просто качает нужные файлы и кладет их в кеш.
Второй зависит от объемов загружаемых данных. Если грузить небольшими порциями или если объекты будут не очень сложными, то, возможно, будет не так заметно.
Вообще под конкретно эту задачу движок не оптимизировался, поэтому трудно сказать, насколько хорошо это будет выглядеть и насколько хорошо будет чувствоваться "бесшовность".
Сам процесс подгрузки может занимать ощутимое время, в течение которого будет проседать fps. Он складывется из 2 этапов:
- сначала непосредственно загрузка данных по сети,
- затем подготовка движком объектов/ресурсов для отрисовки
Первый в случае слабой сети всегда будет проблемой - ну, это понятно. Вообще имеет смысл заранее начать грузить данные, ещё до того, как они понадобятся движку, чтобы в нужный момент нам пришлось бы тратить время только на их подготовку, т.е. только на 2 этап. Для этого есть метод prefetch, который просто качает нужные файлы и кладет их в кеш.
Второй зависит от объемов загружаемых данных. Если грузить небольшими порциями или если объекты будут не очень сложными, то, возможно, будет не так заметно.
Вообще под конкретно эту задачу движок не оптимизировался, поэтому трудно сказать, насколько хорошо это будет выглядеть и насколько хорошо будет чувствоваться "бесшовность".
12 апреля 2017 12:38
Думаю еще придется хорошо продумать LOD-ы на объекты.
Да и миллионы кв метров вручную сложно сделать и дорого![]( "smiling")
. Как вариант можно попробовать использовать процедурную генерацию. А уникальные объекты делать ручками.
Да и миллионы кв метров вручную сложно сделать и дорого
. Как вариант можно попробовать использовать процедурную генерацию. А уникальные объекты делать ручками.
12 апреля 2017 18:36
Ответ на сообщение пользователя Иван Любовников
Ну, чтобы не упираться в память, придется делать динамическую подгрузку/выгрузку целых блоков карты. Сама подгрузка описана в этой статье: Меблируем комнату. Часть 1: Динамическая загрузка
Сам процесс подгрузки может занимать ощутимое время, в течение которого будет проседать fps. Он складывется из 2 этапов:
- сначала непосредственно загрузка данных по сети,
- затем подготовка движком объектов/ресурсов для отрисовки
Первый в случае слабой сети всегда будет проблемой - ну, это понятно. Вообще имеет смысл заранее начать грузить данные, ещё до того, как они понадобятся движку, чтобы в нужный момент нам пришлось бы тратить время только на их подготовку, т.е. только на 2 этап. Для этого есть метод prefetch, который просто качает нужные файлы и кладет их в кеш.
Второй зависит от объемов загружаемых данных. Если грузить небольшими порциями или если объекты будут не очень сложными, то, возможно, будет не так заметно.
Вообще под конкретно эту задачу движок не оптимизировался, поэтому трудно сказать, насколько хорошо это будет выглядеть и насколько хорошо будет чувствоваться "бесшовность".
Думаю топикстартер спрашивал о том, планируется ли опция которая будет разбивать объекты на части , например большие карты которые подгружать частями по ходу перемещения персонажа(камеры) в зависимости от дальности видимости камеры принимая это за радиус вокруг камеры + дельту на загрузку при перемещении. Плюс конечно те объекты которые помещаются в дельту например дальность камеры х2 грузить так же при перемещениях. Тем самым избавить программиста от работы по созданию всей этой однотипной процедуры для каждого приложения и сцены. Присоединяюсь к этому же вопросу.
Денис
12 апреля 2017 19:56
Думаю топикстартер спрашивал о том, планируется ли опция которая будет разбивать объекты на части , например большие карты которые подгружать частями по ходу перемещения персонажа(камеры) в зависимости от дальности видимости камеры принимая это за радиус вокруг камеры + дельту на загрузку при перемещении.пока не планируется
13 апреля 2017 00:13
Ответ на сообщение пользователя Иван Любовников
пока не планируется
очень жаль, как раз недавно обсуждали что надо писать руками, и все делают получается одно и то же..
напрашивается чтоб это было функцией движка..
Денис
17 апреля 2017 20:01
Ни разу не делал ничего подобного, но представляю себе примерно такую схему обобщенно:
- есть заранее отрисованные объекты (все что есть вообще), хранящиеся на сервере по отдельности
- 3х-мерный массив карты с адресацией по осям координат, где лежит тип объекта, то есть json, где по xyz указан тип объекта и его углы направления
- процедура генерации этого массива, которая учитывает свойства каждого типа объекта и их совместимости для склеивания, наложения и т.п.
- сфера видимости камеры помноженная на 1.2 (эта цифра зависит от скорости движения)
- в памяти нужно всегда держать только эту сферу, в виде куска из общего json
- серверный обработчик, получающий абсолютные координаты камеры и отдающий список типов объектов, которые присутствуют в сфере, где координаты камеры в центре, по одному (только в одном экземпляре)
- клиентский обработчик, который грузит в кэш объекты из списка (которых там еще нет), то есть в кэше, всегда лежат объекты в единичном экземпляре, которые присутствуют в сфере
- серверный обработчик, получающий абсолютные координаты камеры и отдающий сферу (кусок json), где координаты камеры всегда в центре
- клиентский обработчик, который обновляет с сервера json (сферы) при движении
- клиентский обработчик, контролирующий чтобы все из сферы было отображено на сцене и удалено лишнее (что за пределами)
- к примеру, есть 4 уровня детализации: с 0 до 0.3 (радиус сферы) - 1 уровень … и с 0.9 до 1.2 - 4 уровень детализации (самые примитивные lod)
Пожалуйста, поправьте, если я что-то не учел и схема не рабочая или дополните или покритикуйте.
- есть заранее отрисованные объекты (все что есть вообще), хранящиеся на сервере по отдельности
- 3х-мерный массив карты с адресацией по осям координат, где лежит тип объекта, то есть json, где по xyz указан тип объекта и его углы направления
- процедура генерации этого массива, которая учитывает свойства каждого типа объекта и их совместимости для склеивания, наложения и т.п.
- сфера видимости камеры помноженная на 1.2 (эта цифра зависит от скорости движения)
- в памяти нужно всегда держать только эту сферу, в виде куска из общего json
- серверный обработчик, получающий абсолютные координаты камеры и отдающий список типов объектов, которые присутствуют в сфере, где координаты камеры в центре, по одному (только в одном экземпляре)
- клиентский обработчик, который грузит в кэш объекты из списка (которых там еще нет), то есть в кэше, всегда лежат объекты в единичном экземпляре, которые присутствуют в сфере
- серверный обработчик, получающий абсолютные координаты камеры и отдающий сферу (кусок json), где координаты камеры всегда в центре
- клиентский обработчик, который обновляет с сервера json (сферы) при движении
- клиентский обработчик, контролирующий чтобы все из сферы было отображено на сцене и удалено лишнее (что за пределами)
- к примеру, есть 4 уровня детализации: с 0 до 0.3 (радиус сферы) - 1 уровень … и с 0.9 до 1.2 - 4 уровень детализации (самые примитивные lod)
Пожалуйста, поправьте, если я что-то не учел и схема не рабочая или дополните или покритикуйте.
18 апреля 2017 00:06
Могу посоветовать не сразу удалять объекты карты, который были загружены, но вышли за радиус сцены. Пользователь может резко вернуться назад и ранее загруженные данные могут быть полезны. Нужно балансировать ,чтобы они не занимали слишком много, но и в то же время, чтобы не нагружать загрузчик туда сюда одним и тем же (юзер стоит на стыке и стрейфится влево вправо входя в зону подгрузки и выходя из неё).
А вообще, как я помню, на геймдеве когда то очень давно (я тогда ещё школу заканчивал) обсуждали тему с бесшовным миром на примере TES Morrowind. Как то я инфу усвоил но до дела руки не дошли, я думаю вам даже удобнее будет на тамашнем форуме такую тему поднять, вам там точно помогут более дельными советами)
А вообще, как я помню, на геймдеве когда то очень давно (я тогда ещё школу заканчивал) обсуждали тему с бесшовным миром на примере TES Morrowind. Как то я инфу усвоил но до дела руки не дошли, я думаю вам даже удобнее будет на тамашнем форуме такую тему поднять, вам там точно помогут более дельными советами)
