Що сталося з процедурно створеними текстурами? [зачинено]

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

З того, що я можу сказати, гул мертвий, і жодна гра на моєму радарі не використовує їх. Що сталося?

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

Інструменти створення вмісту для процесуального текстурування стали найбільшою перешкодою. Виконавець дуже швидко збирає речі у Photoshop і потенційні вигоди від текстурування процедур не перевищують збільшення часу створення вмісту.

Allegorithmic ( http://www.allegorithmic.com/ ) має кілька цікавих інструментів, які вони розробили, щоб спробувати зробити процедурні параметри більш зручними для користувачів. Не грав з ними достатньо, щоб дійсно коментувати їх зручність.

Втрата художнього контролю та збільшення розмірів варіантів зберігання зробили це важким продажем. Це, плюс вам доведеться перекваліфікувати художників, а ви найняли їх на те, що вони були хорошими в традиційному текстуруванні. Якщо розмір чи унікальна текстура насправді не є проблемою, загалом небажано йти процедурним шляхом.

В основному, великі гармати не підтримують його, тому його не використовують багато. Були круті речі (хоч і трохи старі), як-от .kkrieger, але час завантаження цього (ще в той день) був реально повільним, оскільки він мав генерувати всі текстури під час завантаження.

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

У світі AAA є приклади, наприклад, Spore процедурно створює текстури та анімацію для створених вами істот.

Текстура процедур страждає від того, що художній директор не може надійно вказати на роботу художника і сказати, "будь ласка, зробіть цю частину ще трохи X". оскільки система процедурного затінення може не підтримувати X дешево або зовсім.

Наприклад, цегляний шейдер може підтримувати чисту коричневу цеглу, але може не підтримувати цеглу, яка була пофарбована рекламою 80 років тому та графіті 10 років тому. Або це може не підтримувати наявність однієї фіолетової цегли з 1000 коричневих цеглин. Саме в цьому місці, тому що це сподобається смаку художнього директора.

Справжня текстура може, звичайно, підтримувати всі ці речі, і в цьому сенсі справжня текстура перевершує процедурну текстуру.

Процедурна фактура здійснює художній контроль через перевагу певних випадків використання перед іншими. Справжня текстура мало контролює таке.

Однак апаратне забезпечення GPU має велику перевагу до процесуалізму, оскільки пам'ять текстури знаходиться на стільки циклів від блоків ALU, що роблять затінення.

ну все ще здається чудовою ідеєю для ігор. Оскільки ви можете процедурно генерувати текстури під час руху, щоб світ навколо плеєра виглядав природніше. Не потрібно великих даних. Це можна впевнено використовувати для збільшення навіть роздільної здатності

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

Чи завантажується jpg швидше, ніж процедурно створена версія? Швидше за все, так . Якщо jpg становить 2 Мб, і ви завантажуєте його один раз, навіщо вам заважати процедурним? Під час виконання текстура так чи інакше займає стільки ж оперативної пам’яті (нестиснута і завантажена в пам'ять GPU)