Тут возникает несколько проблем:
1) Precompute. Создание качественного BVH или Kd-дерева для сцены с большим количеством полигонов – не быстрый процесс. У нас на создание BVH для сцены с 2млн полигонов уходит 300-600 ms. А что если сцена намного больше и меняется каждый фрейм, что и происходит в играх? Тут с фреймрейтом все плохо. А ведь мы еще и до рендеринга не добрались. Мы сейчас работаем над распределением построения BVH на все ядра CPU. Это должно ускорить процесс, но не так значительно, как хочется.
2) Rendering. Можно очень быстро отрендерить несколько самплов и получить шумную картинку. Если хочется лучшего качества, нужно увеличивать количество самплов рендеринга. Это линейно увеличивает время. Тут можно применять умные техники фильтрации, которые, к слову, тоже не самые быстрые.
Если грамотно распределить эти задачи между устройствами, то можно добиться хороших результатов. Тут важно, чтобы устройства в облаке были очень близко или имели быстрый доступ друг к другу. Но передача изображения по узкому каналу пользователя сведет на нет работу даже очень близко расположенных сильных устройств. В этом можно убедиться на примере сервиса OnLive.
Думаю, нет. Создание плагина под редактор – огромная работа. Над этим проектом всего 2.5 человека работает :) Если есть желание им заняться, присоединяйтесь!
Анимацию пока нет. У нас со статикой-то проблемы возникают. Код Autodesk — такой кусок говна. 3ds Max SDK и создание плагина вызвало у нас больше проблем, чем создание самого рендера.
На ARM без проблем, про мирсы речи не было. Так C++ AMP работает, берет GPU код и транслирует его на каждую поддерживаемую платформу (x86, x64, ARM). Эта фича WARP, заложенная в DirectX 11.
OpenGL, в том числе ES, можно использовать только для простых алгоритмов рендеринга. Они просто не были созданы для такой производительности, которая требуется для unbiased рендеринга.
Ого) 100 Core i7 + GTX 570 звучит… дорого :)
Очень интересная возможность, но на разных машинах пока проблематично. Мы только проверили концепт, что так можно сделать, но до хорошего автоматизированного решения руки еще не дошли. Можно запустить рендер на всех машинах машинах, но результат пока придется собирать руками. Вот если у вас много GPU+CPU в одной машине, то тут без проблем.
Если карта слабая или сцена очень тяжела, то Watchdog ругается и сбрасывает рендер. В таком случае Timeout Detection and Recovery можно отключить. При установке плагина сделаем опцию отключения. Но вообще не рекомендуют это делать. Хотя ничего страшного в этом нет, карта не сгорит :)
По факту, финальный рендер лучше осуществлять без интерактивного отображения в окно. Для этого можно отключить timeout и поставить карту работать. Проверено, что рендер в таком случае может быть до 2-2.5х раз быстрее.
Поясните пожалуйста, что такое рантайм? Работать в 3ds Max'е, и получать моментальный отклик рендера, который рассчитывается в облаке? Не совсем понял.
да, это движок Brigade. Подразумевается, что он будет игровым. Наша разработка тоже в эту сторону движется, но лишь как очень-очень ранний прототип. До игр еще далеко.
для игр multi-GPU используют через SLI или Cross-Fire, когда устройства логически объединяются в одно. Чтобы делать рендеринг на нескольких картах, надо значительно перерабатывать игровой движок и тратить много сил на коммуникацию между GPU. На старых поколениях это был гемор. На новых намного легче, но мало кто это будет делать в ближайшее время, рынка нет для этого.
У последних поколений видеокарт NVIDIA и AMD есть фича, которая позволяет одному GPU перекидывать память в другой минуя системную память. Если собрать ящик из 6-8 таких GPU, то фреймрейты будут что надо, и картинка будет хорошей. Вопрос только зачем это? Для студии анимации это имеет смысл, чтобы сократить время на настройку сцен. Для игр — не понять. Установка слишком дорога, чтобы найти масс-маркет.
После геймдева первый курс любого технического вуза заходит с восторгом и чистым понимаем. Матан + аналит после графики, физика (теор. мех) после копания с любой физической либой. Благодаря геймдеву был отличником на первых курсах.
А какже самый главный хак??! Найти в папке Windows конфиг файл сапера, открыть его в блокноте, руками прописать себе 15 секунд на профи и показывать друзьям потом :-)
лет 9 назад папа привез из Китая набор «LEGO» из которого можно было собрать танк. Детали подходили к LEGO отлично, а вот между собой их приходилось «скреплять» молотком… и не сразу получалось еще)
Вполне себе сносно. Не знаю случая, когда пара человек очень активно делает центральные коммиты. Предполагается, что разработка и хранение локальных изменений происходят на машинах разработчиков, а push делается для проверенного изменения в центральный репозиторий. Даже в случае гипотетической потери все легко откатывается обратно.
1) Precompute. Создание качественного BVH или Kd-дерева для сцены с большим количеством полигонов – не быстрый процесс. У нас на создание BVH для сцены с 2млн полигонов уходит 300-600 ms. А что если сцена намного больше и меняется каждый фрейм, что и происходит в играх? Тут с фреймрейтом все плохо. А ведь мы еще и до рендеринга не добрались. Мы сейчас работаем над распределением построения BVH на все ядра CPU. Это должно ускорить процесс, но не так значительно, как хочется.
2) Rendering. Можно очень быстро отрендерить несколько самплов и получить шумную картинку. Если хочется лучшего качества, нужно увеличивать количество самплов рендеринга. Это линейно увеличивает время. Тут можно применять умные техники фильтрации, которые, к слову, тоже не самые быстрые.
Если грамотно распределить эти задачи между устройствами, то можно добиться хороших результатов. Тут важно, чтобы устройства в облаке были очень близко или имели быстрый доступ друг к другу. Но передача изображения по узкому каналу пользователя сведет на нет работу даже очень близко расположенных сильных устройств. В этом можно убедиться на примере сервиса OnLive.
OpenGL, в том числе ES, можно использовать только для простых алгоритмов рендеринга. Они просто не были созданы для такой производительности, которая требуется для unbiased рендеринга.
Очень интересная возможность, но на разных машинах пока проблематично. Мы только проверили концепт, что так можно сделать, но до хорошего автоматизированного решения руки еще не дошли. Можно запустить рендер на всех машинах машинах, но результат пока придется собирать руками. Вот если у вас много GPU+CPU в одной машине, то тут без проблем.
По факту, финальный рендер лучше осуществлять без интерактивного отображения в окно. Для этого можно отключить timeout и поставить карту работать. Проверено, что рендер в таком случае может быть до 2-2.5х раз быстрее.
своего bro-шара для тестовых рендеров пока нет
Если над проектом работает пара человек, то вполне сносно.