Для восхищённых маркетинговыми материалами от создателей этой поделки (leap motion) — вот самое правдоподобное видео которое я видел: bit.ly/1oC1wAU
Взято отсюда: bit.ly/1qx6Qdp
По совету продавца (больше никогда не буду так делать не почитав ревью и отзывы об устройстве в интернете) подарил такой (L800) жене для печати фотографий. Всё было хорошо — качество хорошее, в фото центр бегать не нужно, расход чернил довольно низкий… Но по прошествии двух недель при печати появились полосы, пропал сначала жёлтый цвет а потом и все остальные. Все инструкции по использованию были изучены с самого начала использования. Сначала подумал что проблемы из-за забившихся сопел, но никакие сервисные функции не помогли. Поиск в гугле выдал вагон и маленькую тележку сообщений об аналогичных проблемах, которые вызваны тем что принтер не может затянуть чернила в печатающую головку. После ремонта в сервисном центре проблемы на короткое время пропали, но вскоре всё повторилось. На этом моё терпение кончилось и я вернул сей девайс назад, забрав деньги. Искренне надеюсь что это был единичный случай, но всё же обилие проблем с этим принтером у многих говорит о том, что где-то инженеры Epson сильно просчитались.
Я не хочу своим комментарием развести сейчас флейм так как тема действительно спорная, но на сколько мне известно нежелание использовать сторонние know-how вызвано несколькими объективными причинами:
1. Инертность разработчиков стороннего софта. В случае возникновения каких-либо проблем, до того момента как они будут решены пройдёт гораздо больше времени.
2. Цена решения для наших заказчиков. В случае использования коммерческого middleware вместо all-inclusive решения наши заказчики будут получать решение вида «доплати ещё N тысяч долларов компании M за редактор деревьев чтобы добавить возможность их создания в купленном движке».
3. Лицензирование решения со стороны Unigine. Вряд ли кто-то из разработчиков middleware согласится отдать свой продукт нам за фиксированную цену чтобы мы имели возможность интегрировать его в движок — скорее всего потребуются роялти с продаж.
Один минус подхода с реализацией своих собственных решений — более медленный процесс разработки требующий больше человеко-часов.
Интересно! Но на сколько я понимаю это закрытые тулзы и использовать их не купив движок нельзя, а данные с полученной таким образом модели не запечёшь и соответственно использовать их можно будет только с этим движком.
Спасибо за ссылку!
Но ведь в статье речь идёт не о воксельных движках, а о том, что нет ни одного инструмента для технических художников который позволил бы алгоритмически формировать воксельные объекты и снимать с них необходимую информацию (текстуры, топологию и т.п.).
Вот здесь Владимир Головин (создатель Filter Forge) на вопрос
I would like to know if a Filter Forge GPU based render engine is in the pipeline
отвечает
Currently no, and I can't say anything about future releases. Look at Aperture's problems with their GPU-based photo editing (or was that Lightroom?) — simply put, you have different results on different cards and different video drivers.
Would be nice for preview purposes though.
Хотя да, пост довольно старый (2006 г.) и всё уже скорее всего изменилось много раз.
Вот здесь большая сборка информации по вопросам и официальным ответам от разработчика на эту тему.
Но к сожалению судя по этому списку feature wishlist, основная проблема всё-таки в том, что архитектура Filter Forge не очень ложится на GPU-based rendering.
Нет, не пробовали потому как конечный результат в этом случае будет зависеть от используемой видеокарты :) А это не то, что хочется от процедурных текстур. Плюс каждый раз писать шейдер для реализации нужной текстуры — мягко говоря не практично.
Для условий реального производства игрового контента это должно быть универсальное удобное node-based решение наподобие Filter Forge, но с возможностями hardware ускорения (которые с относительно недавнего времени использует Photoshop).
Взято отсюда: bit.ly/1qx6Qdp
1. Инертность разработчиков стороннего софта. В случае возникновения каких-либо проблем, до того момента как они будут решены пройдёт гораздо больше времени.
2. Цена решения для наших заказчиков. В случае использования коммерческого middleware вместо all-inclusive решения наши заказчики будут получать решение вида «доплати ещё N тысяч долларов компании M за редактор деревьев чтобы добавить возможность их создания в купленном движке».
3. Лицензирование решения со стороны Unigine. Вряд ли кто-то из разработчиков middleware согласится отдать свой продукт нам за фиксированную цену чтобы мы имели возможность интегрировать его в движок — скорее всего потребуются роялти с продаж.
Один минус подхода с реализацией своих собственных решений — более медленный процесс разработки требующий больше человеко-часов.
Но ведь в статье речь идёт не о воксельных движках, а о том, что нет ни одного инструмента для технических художников который позволил бы алгоритмически формировать воксельные объекты и снимать с них необходимую информацию (текстуры, топологию и т.п.).
отвечает
Хотя да, пост довольно старый (2006 г.) и всё уже скорее всего изменилось много раз.
Вот здесь большая сборка информации по вопросам и официальным ответам от разработчика на эту тему.
Но к сожалению судя по этому списку feature wishlist, основная проблема всё-таки в том, что архитектура Filter Forge не очень ложится на GPU-based rendering.
Нет, не пробовали потому как конечный результат в этом случае будет зависеть от используемой видеокарты :) А это не то, что хочется от процедурных текстур. Плюс каждый раз писать шейдер для реализации нужной текстуры — мягко говоря не практично.
Для условий реального производства игрового контента это должно быть универсальное удобное node-based решение наподобие Filter Forge, но с возможностями hardware ускорения (которые с относительно недавнего времени использует Photoshop).