Процедурное текстурирование: генерация текстуры булыжника

[@Shekeen]

Хорошо бы исходники на гитхабе, было бы гораздо удобнее.

[@fshp]

Или на битбакете.

[@Torvald3d]

Готово, залил на гитхаб

[@sdevalex]

Почему не используете libnoise или Accidental Noise Library?

[@Torvald3d]

Потому что люблю изобретать велосипеды. Интересно самому все написать, изучить, а вызов готовых функций мало чему учит.

[@SHVV]

Не плохо было бы реализовать всё тоже самое, но на GPU.
Скорость должна увеличиться на порядок, а то и два.

[@Torvald3d]

А я и хотел сначала сделать это на гпу. Но после того как увидел на сколько сильно может отличаться результат на разных гпу, передумал.

[@w23]

Для данной задачи результат на разных гпу должен быть едва ли не bit-perfect одинаковый.
Разное получается, если выпендриваться.

[@Torvald3d]

Ну так я и выпендривался…
Простая формула гпсч: fract(sin(dot(gl_FragCoord.xy ,vec2(12.9898,78.233))) * 43758.5453)
Результат: интегрированный гпу (какой то старый офисный селерон) и GeForce GTX460 (справа)

[@w23]

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

[@w23]

Не на гпу такие штуки делать просто бессмысленно. Это дороже-дольше и в прототипировании, и в исполнении.
Современные гпушечи трассируют лучи через синтезируемого в реальном же времени Вороного в 3D на пофиг, если говорить про производительность.

[@Torvald3d]

Я рассматривал такой вариант. Диаграмма Вороного хорошо бы подошла для раскраски, но ячеистая текстура больше подходит для создание рельефности и теней между камнями.

[@SHVV]

Используемая в статье ячеистая текстура (одна из вариаций Cellular или Worley noise) получает интенсивность как разницу расстояний между второй и первой ближайшей контрольной точкой. В результате 0 (чёрный цвет) получается как раз на границе ячеек диаграммы Вороного. Но кроме границ, получаются еще и холмы в центре ячейки. К тому же алгоритм идеально ложится на GPU.

[@w23]

Крутяк!
Однако, отмечу, что то, что вы называете шумом Перлина, таковым не является. На самом деле у вас фрактальный value noise, а оригинальный шум Перлина несколько сложнее.

Кроме того, у вас довольно странные места в коде, много их.
Например, вот это

delete[] interpolateTable;
interpolateTable = new float[f];

значительно и непредсказуемо дороже, чем просто при надобности делать

(1.0f-cosf(a))*0.5f

[@Torvald3d]

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

[@w23]

Потому что это потенциальное прерывание и уход в ядро на неизвестно сколько миллисекунд. Высвобождение памяти тоже может быть очень не бесплатным.
Если и предрассчитывать таблицы, то где-то заранее и (квази-)статичного размера. При этом надо иметь в виду размер кэшей, промах по которым может нарушать «Доступ к переменной дешевле чем вычисление».

[@Ckpyt]

… только в том случае, если не используешь свой аллокатор.
В противном случае, у меня выделение/освобождение памяти занимает 5 тактов. Плюс поток контроллера ОЗУ, он же пишет на HDD.

[@beliakov]

Вспомнил про шикарный генератор рельефа в Space Engine: