Флейм
GameDev.ru / Флейм / Форум / Практика процедурного текстурирования

Практика процедурного текстурирования

Поделиться

Страницы: 1 2 3 4 ... 12 ... 21 22 23 Следующая

FordPerfectПостоялецwww2 сен. 201723:10#0
Было несколько похожих тем, но там больше разговоры о ссылках на алгоритмы.

Эта - для того, чтобы постить картинки, приёмы, и болталка на тему.

Вон Mikle недавно текстуры камня/кирпича показывал, довольно красивые.
Можно запостить сюда, дабы не потерялись, и заодно краткое описание. Теоретических откровений там вряд-ли есть, а вот приёмы - интересно.

ТатаринПостоялецwww2 сен. 201723:22#1
репозиторий: https://github.com/schalkt/tgen
демка: http://seamless-texture.com/generator/
клевая штука я через нее себе текстуры планет сделал.
FordPerfectПостоялецwww3 сен. 201717:10#2
Немного о дизайне своего генератора.
И исходник, если кому охота попробовать, а свой писать лениво.
Он не сложный, 1 файл.

Генерируется кодом, на C++. Языка описания, GUI - нет; все примитивы - в виде функций на C++.
Все рабочие поверхности - во float. Преобразование в uint8_t - только на финальном этапе, собственно сборки поверхности.
Все операции - одноканальные. Если захочется параллелить - так обработка одного канала тоже замечательно параллелится. А ограничения - нафиг. Далеко на всегда канала 4. Есть карты высот, сплаттинга, и т. д..
Поверхности описываются surface_view (FTexRef в коде), который чисто задаёт размер/страйд/данные. Хранением/владением не заведует, вообще. Хранением вообще не заморачиваюсь, одна арена на всё.
Встроенного clamp на рабочих поверхностях нет. Надо - пользователь сделает явно. Clamp на этапе преобразования в текстуру (byte) - есть.
Базовые примитивы генерации (tex_gen_*):
tex_gen_f - сгенерировать из явной формулы от (u,v).
tex_gen_cell - сгенерировать клеточную текстуру (по мотивам https://fgiesen.wordpress.com/2010/03/28/how-to-generate-cellular-textures/ , https://fgiesen.wordpress.com/2010/03/29/how-to-generate-cellular-textures-2/)
в общем на этом генераторы заканчиваются. Константа, Перлин, fBm выражаются через tex_gen_f.
Операторы:
tex_op_f1 - одноаргументный. Поэлементная функция над текстурой. На её основе сделаны tex_op_copy (dst[u,v] <- src[u,v]), tex_op_scale (dst[u,v] <- a*src[u,v]), tex_op_lin (dst[u,v] <- a*src[u,v]+b)
tex_op_f2 - двухаргументный. Поэлементная функция над 2-мя текстурами. На её основе сделаны tex_op_add, tex_op_weighted_add, tex_op_lerp.
tex_op_f3 - трёхаргументный. Поэлементная функция над 3-мя текстурами. На её основе сделана tex_op_mix (dst[u,v] <- src0[u,v]*(1-mix[u,v])+src1[u,v]*mix[u,v]).
tex_op_light - ламбертовское освещение карты высот.
tex_op_blur - размытие (по мотивам https://fgiesen.wordpress.com/2012/07/30/fast-blurs-1/ , https://fgiesen.wordpress.com/2012/08/01/fast-blurs-2/ )

Вот с этим оно и живёт.
Между скоростью и общностью - выбор типично в сторону общности. Творческий процесс, итеративность, большинство времени - на поиск удачной текстуры. Когда нашли можно уже оптимизировать (инкрементально, смотря на сколько отошли от найденной). Ну не доводя до крайностей, когда сам поиск тормозит.

Код:
gen_tex

Функция texture_generate выдаёт такую картинку:

+ Показать

набросок какой-то ткани (джинсовая, брезент).

clcПостоялецwww3 сен. 201718:52#3
два вопроса без наезда:
- почему не на шейдертое или подобном
- почему не генерируемые

по-моему прикладные генерируемые текстуры более нужны

FordPerfectПостоялецwww3 сен. 201719:34#4
clc
Это ко мне вопросы?
https://www.shadertoy.com/ вполне ок, удобная платформа, чтобы постить примеры. Конкретно мой генератор плюсовый, на CPU - так это мне удобнее, для моих демок.
>почему не генерируемые
В смысле? В чём по твоему разница между "процедурные" и "генерируемые"?
clcПостоялецwww3 сен. 201719:59#5
процедурные - реалтайм
FordPerfectПостоялецwww3 сен. 201720:48#6
clc
А, нет, такого смысла я в него не вкладывал.
Т. е. реалтайм - совсем не обязательно.
foxesПостоялецwww3 сен. 201723:30#7
Последнее время склонился к тому чтобы не делать генератор с отдельными методами, которые потом таскать везде. А на том же аналоге shadertoy или прям в заготовочном коде, тестировать разные миксы алгоритмов, заново собранных переписанных и/или оптимизированных. В некотором роде даже сошел на использование только отфильтрованного шума в фотожабе и других редакторах. Чисто поэкспериментировать весьма интересно. В результате находишь дополнительные альтернативы для генерации текстур.

Например я заметил очень пригодную вещь при использовании октавного шума или Перлина, что его можно фильтровать как Out=(1.0-abs(In*Scale-Div)) (при условии что 1.0 максимальная яркость). Получая в последствии основу для интересных эффектов. Можно также применять несколько раз.

Здесь например в последствии был сделан Emboss, вычитание первой текстуры из второй и замена цвета. Это все легко реализуется кодом.

generaterock0002 | Практика процедурного текстурированияgeneraterock0003 | Практика процедурного текстурированияgeneraterock0004 | Практика процедурного текстурированияgeneraterock0001 | Практика процедурного текстурирования

Правка: 4 сен. 2017 1:10

clcПостоялецwww3 сен. 201723:59#8
каменистая почва. Если чутка поиграться, то получится ржавчина, облупившаяся краска, песчанник. Такое нужно
gammakerПостоялецwww4 сен. 201712:02#9
foxes
> Здесь например в последствии был сделан Emboss, вычитание первой текстуры из
> второй и замена цвета. Это все легко реализуется кодом.
Ух ты, круто! Надо это добавить в мою копилку методов процедурных текстур. Поскольку мой движок мёртв, я хочу сделать браузерную генерилку текстур на WebGL, чтобы можно было прямо в браузере экспериментировать. Насколько я понимаю, shadertoy ограничен одним проходом и на выходе может выдавать только одну картинку. Поэтому надо делать своё.
gammakerПостоялецwww4 сен. 201722:13#10
Приступил к реализации онлайн генерилки процедурных текстур на WebGL для экспериментов. Идея такая:
1) На странице два текстовых редактора. Один для управляющего JavaScript кода, а второй для библиотечного кода шейдеров. Пока ограничусь < textarea >, потом прикручу какой-нибудь нормальный редактор с подсветкой синтаксиса типа Ace.
2) Код шейдеров представляет собой библиотеку функций, общую сразу для всех генерируемых текстур - без функции main. Он может быть даже пустым, если не нужен кастомный код, а достаточно встроенных шейдерных функций.
3) Управляющий код создаёт текстуры вызовом функции TextureFromShader, передавая в качестве первого параметра произвольное GLSL-выражение от TexCoord - это может быть формула или просто вызов функции из библиотеки функций. Вторым параметром идёт ассоциативный массив со значениями uniform переменных, включая другие текстуры с предыдущих этапов, если они используются. Третим параметром идёт формат создаваемой текстуры в виде строчки типа "byte3", "float4", "half3" и т.п..
4) Куча встроенных GLSL функций для генерации кирпичного узора, перлина, ячеистого шума, размытия, преобразования цветовых пространств, фильтров свёртки, генерации нормалей по высотам, дифференцирования и даже signed distance field для основных геометрических фигур. Благодаря им, во многих случаях код шейдеров даже не придётся писать.
5) Получившиеся текстуры в управляющем JS коде делаются видимыми вызовом ExportTexture(tex, name). В результате можно будет видеть несколько текстур или даже их наборов, содержащих, диффузные текстуры, карты нормалей, высот и чего угодно ещё.
6) После того, как всё это реализую, можно будет сделать возможность визуализации того, как выглядит текстура на 3D модели с освещением.

Как вам идея? Кому-то нужно кроме меня?

*Lain*Забаненwww5 сен. 20171:27#11
gammaker
> Надо это добавить в мою копилку методов процедурных текстур
+100500 к потере точности
ТатаринПостоялецwww5 сен. 20178:27#12
gammaker
> Как вам идея? Кому-то нужно кроме меня?
Если честно то никакого толку от процедурных текстур нету, 99.9% в реальный проект не перенести потому что сразу видно что текстура гамно, очень редкий случай когда она понадобится да и в итоге там 1 процедурная на 1000 не процедурных текстур - шкурка выделки не стоит. Ты сделаешь очередной никому не нужный редактор коих тысячи) Безисходность)
*Lain*Забаненwww5 сен. 201710:50#13
Татарин
> сделаешь очередной никому не нужный редактор
Не сделает. Бросит вслед за движком
gammakerПостоялецwww5 сен. 201711:40#14
*Lain*
> +100500 к потере точности
Какой ещё точности?

Татарин
> Если честно то никакого толку от процедурных текстур нету, 99.9% в реальный
> проект не перенести потому что сразу видно что текстура гамно, очень редкий
> случай когда она понадобится да и в итоге там 1 процедурная на 1000 не
> процедурных текстур - шкурка выделки не стоит. Ты сделаешь очередной никому не
> нужный редактор коих тысячи) Безисходность)
Как минимум, пригодится любителям создания 4K\64K демок, к которым отношусь я, ТС, Mikle и другие с этого форума. Мой редактор ориентирован на внедрение разработанных в нём алгоритмов в игру, поэтому генерацию текстур будет легко перенести туда и место занимать не будут. Процедурные текстуры могут быть сгенерированы любого размера.
В моём движке процедурные текстуры я считал одной из главных фич, отличающих его от других движков. Там много что было сгенерировано процедурно, неплохо выглядело и всё умещалось в небольшой бинарник. Поскольку движок умер, но хочется развивать это направление, я сделаю редактор. В нём будет удобнее экспериментировать, чем то, как я экспериментировал в движке без редактора, перекомпилируя всё каждый раз. А потом перенесу это в Godot, на котором делаю игру.
Легковесных онлайн-редакторов тоже тысячи?
В моих играх коэффициент процедурных текстур будет побольше. Непроцедурными будут только текстуры, которые идут вместе с 3D-моделями.

*Lain*
> Не сделает. Бросит вслед за движком
Там работы на 3 дня наверное, а не на 7 лет, которые я делал движок. Движок я бросил исключительно из-за того, что у меня нет в запасе ещё нескольких лет достаточного свободного времени, чтобы его писать. А несколько дней на редактор я найду. Заодно прокачаю свои навыки JavaScript.

Правка: 5 сен. 2017 11:42

Страницы: 1 2 3 4 ... 12 ... 21 22 23 Следующая

/ Форум / Флейм / Программирование

2001—2017 © GameDev.ru — Разработка игр