Что случилось с процедурно сгенерированными текстурами? [закрыто]

23

Я вспоминаю некоторое время назад, что процедурно сгенерированные текстуры стали большой проблемой, в которой многие люди / компании действительно интересовались некоторыми серьезными преимуществами (небольшие развертывания, потенциально более быстрая загрузка, более высокое качество, масштабируемые текстуры, потенциально более дешевые в производстве и т. Д.). ).

Из того, что я могу сказать, гудение мертвое, и никакие игры на моем радаре не используют их. Что произошло?

Я надеялся, что процедурные текстуры будут такими же, как и у NaturalMotion (медленное, но устойчивое принятие).

textures procedural-generation Стивен Эверс
источник

Ответы:

14

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

Allegorithmic ( http://www.allegorithmic.com/ ) имеет несколько интересных инструментов, которые они разработали, чтобы попытаться сделать процедурные варианты более удобными для пользователя. Хотя я не играл с ними достаточно, чтобы по-настоящему прокомментировать их удобство использования.

wkerslake
источник
1
Allegorithmic была компания, о которой я впервые услышал, когда гудел бомба, и в их списке клиентов есть несколько крупных игроков, но, учитывая то, что они давно работают в бизнесе, он все еще довольно мал.
Стивен Эверс
1
Продукты Allegorithmic's Substance выглядят ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО хорошими. Если вы посмотрите видео, найденные здесь: allegorithmic.com/?PAGE=PRODUCTS.designer
Nailer
4

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

Кая
источник
3

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

Мы могли бы видеть то или иное в движках следующего поколения (Unreal 4 и т. Д.), Но я не думаю, что выигрыш по сравнению с разработкой достаточно велик.

В мире ААА есть примеры, например, Spore процедурно генерировал текстуры и анимацию для созданных вами существ.

Олафур Вааге
источник
3

Процедурная текстура страдает от проблемы, заключающейся в том, что художественный руководитель не может надежно указать на работу художника и сказать: «Пожалуйста, сделайте эту часть немного больше X». потому что процедурная система затенения может не поддерживать X дешево или вообще.

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

Конечно, настоящая текстура может поддерживать все эти вещи, и в этом смысле настоящая текстура превосходит процедурную текстуру.

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

Однако аппаратные средства графического процессора сильно предпочитают процедурность, поскольку память текстур находится на очень большом расстоянии от блоков АЛУ, которые выполняют затенение.

bmcnett
источник
Мне трудно это глотать. Это не ограничение процедурных текстур, что кирпич не может быть другого цвета, чем остальные, это ограничение технологии реализации. Конечно, я мог бы согласиться с тем, что в какой-то момент слишком конкретность перевесит преимущества ведения дел в процессе, но это не так.
Кевин Пено
Один кирпичик мог бы быть плохим примером, но другие его примеры верны. Определить новый алгоритм для небольшого изменения «ощущения» текстуры очень сложно и отнимает много времени, но артисту очень легко и просто внести изменения. Имейте в виду, что инженерам, как правило, платят больше, чем художникам, поэтому время, потраченное на то, чтобы исполнить то, что художник может сделать быстрее, просто глупо.
Шон Миддледич
@SeanMiddleditch, инженеры могут получать больше, чем художники, но разница в том, что как только инженер написал код, его можно использовать вечно, без дополнительных затрат. Поэтому, хотя на разработку процедурного генератора, который можно модифицировать, может потребоваться некоторое время, вплоть до уровня отдельного кирпича, - как только это будет сделано, его можно будет бесплатно использовать. Если компания платит художникам за отдельные изменения, они должны будут продолжать делать это для каждого нового требования к изменению, в отличие от автоматизированного решения.
Циклоп
2
@Cyclops: удачи в этой волшебной супер-процедуре, которая позволяет вам делать точные намеренные детали, которые может сделать художник. Я с нетерпением жду прочтения вашей революционной исследовательской работы, когда она будет выпущена, и в конечном итоге лицензирования вашей устарелой художником über технологии. :)
Шон Миддледич
1

ну, это все еще кажется отличной идеей специально для игр. Поскольку вы можете процедурно генерировать текстуры на лету, чтобы мир вокруг игрока выглядел более естественным. Большие данные не нужны. Это может быть использовано для увеличения даже разрешения

январь
источник
0

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

Jpg загружается быстрее, чем процедурно сгенерированная версия? Скорее всего, да . Если размер файла jpg составляет 2 МБ, и вы загружаете его один раз, почему вы должны беспокоиться о процедурном? Во время выполнения текстура все равно занимает одинаковое количество оперативной памяти (без сжатия и загружается в память графического процессора)

bobobobo
источник
JPEG вряд ли будет загружаться быстрее, чем большинство процедурных текстурных алгоритмов. Время доступа к диску значительно превышает время обработки CPU / GPU, и поскольку никто в здравом уме не использует JPEG для текстур и использует более крупные, но оптимизированные для GPU сжатые текстуры с предварительно вычисленными слоями mipmap, время загрузки диска еще хуже для реальных текстур. Существуют причины, по которым процедурные текстуры отстой (упомянутые в других ответах), но время загрузки, как правило, не является одним из них. Я уверен, что исключения существуют для особенно сложных или неэффективных алгоритмов, конечно.
Шон Мидлдич
Да, как .dds. Я просто использовал JPG в качестве примера. Моя точка зрения заключается в том, что процедурная генерация прохладно выглядящего булыжника, или воды, или деревьев в лесу с использованием L-систем или чего-либо еще занимает больше времени (но умещается в 96 тыс.!), Чем просто загрузка контента на диск, тогда никто не захочет идти этим маршрут, просто чтобы сократить время загрузки.
Бобобобо