RGB-массив загнать в Direct3DTexture8

[Mikle]

Шейдер - это просто замена FFP, позволяющая более тонко управлять текстурированием, считать свет, туман и т. п. Это не инструмент доступа к текстуре, рендер в текстуру делается с одинаковым успехом и шейдерами, и FFP. Единственное, чем шейдер превосходит FFP в плане твоих задач - это VTF (vertex texture fetch) - это возможность читать текстуру в вертексном шейдере, то есть возможно использование текстуры в качестве массива данных вертексов. Я это использовал в игре Школа пилотов для реализации бесконечного ландшафта, то есть у меня там вообще нет меша с сеткой ландшафта, вместо этого используется фрагмент затайленной текстуры. Но это доступно только начиная с SM_3_0.

[Old_Maple]

...вместо этого используется фрагмент затайленной текстуры.

Но, как я понимаю, сам фрагмент был создан изначально и потом подгружался...
VB6 хороший инструмент для проверок самих идей. Понимаю, что для быстрой реализации необходимы другие инструменты. Для меня сейчас важно понять, как можно это реализовать в DirectX посредством VB6. Ну а дальше встраивать процедуры, где требуется колосальный объем вычислений и рекурсий, использующие мощность графического процессора. Ну и конечно, чтобы данные не гонять туда-сюда из оперативной памяти в память графической карты.

[Mikle]

сам фрагмент был создан изначально и потом подгружался

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

[Old_Maple]

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

Понял.
Но интереснее, все-таки, чтобы все создавалось "на лету". Ландшафт, лес, реки... Причем, тот же самый ландшафт.
Кстати, Mikle, а не пробовал реализовать алгоритм постройки ландшафта на шейдерах? Причем, бесконечный... Но, чтобы вернувшись в любую точку, где был ранее, ландшафт был в точности такой же? И, разумеется, без сохранений на жестком диске.

[The trick]

Шейдер - это просто замена FFP, позволяющая более тонко управлять текстурированием, считать свет, туман и т. п. Это не инструмент доступа к текстуре, рендер в текстуру делается с одинаковым успехом и шейдерами, и FFP. Единственное, чем шейдер превосходит FFP в плане твоих задач - это VTF (vertex texture fetch) - это возможность читать текстуру в вертексном шейдере, то есть возможно использование текстуры в качестве массива данных вертексов. Я это использовал в игре Школа пилотов для реализации бесконечного ландшафта, то есть у меня там вообще нет меша с сеткой ландшафта, вместо этого используется фрагмент затайленной текстуры. Но это доступно только начиная с SM_3_0.

Майкл, а разве в шейдере нельзя сгенерировать текстуру? У меня есть пример Raymarching'а на пиксельном шейдере генерируется изображения. Тут просто вывод на экран можно изменить на вывод в текстуру, а эту текстуру уже потом использовать.

[Mikle]

Майкл, а разве в шейдере нельзя сгенерировать текстуру?

Можно. Я писал, что шейдеры не дадут какого-то нового доступа к текстурам. Получим прирост скорости, да, но в плане реализации алгоритмов получим больше головной боли.
Нужно рассматривать более конкретные примеры, чтобы решить, на чём удобнее генерировать. Например, анимировать водную поверхность лучше на шёйдере, а вот генерацию практически всех примеров из TFScript на шейдер будет очень сложно перенести.

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

Это не сложно, но только для случая простого ландшафта, без эрозии и т. п. эффектов.

[Old_Maple]

а вот генерацию практически всех примеров из TFScript на шейдер будет очень сложно перенести.

Насколько я понимаю, генерация шума и прочие фильтры, которые применяются в TFScript наоборот будет проще реализовывать в вертексном шейдере, поочередные проходы. Избавишься от множества вложенных циклов. Внутренний цикл можно реализовать посредством ядер GPU, как было сделано на Nvidia CUDA в реализации "Diamond-Square". Вертексные шейдеры, думаю, используют те же ядра. Или нет?

[Mikle]

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

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

[Old_Maple]

Когда я говорю о трудностях, я в первую очередь имею ввиду отсутствие глобальных переменных, которые можно использовать и менять из шейдера. В моих примерах TFScript примерно треть команд - это обычная нормализация. Нужно пробежаться по массиву, найти наибольшее и наименьшее значение, затем домножить и прибавить ко всем элементам вычисленные значения, чтобы привести диапазон значений к нужным границам. На шейдере это простейшее действие - тупик. И это не единственная проблема, просто это наиболее удачный пример проблем, которые тянут за собой шейдеры.

К моему глубочайшему сожалению, Mikle, мне абсолютно нечем тебе возразить, ибо работу шейдеров я понимаю весьма поверхностно. Но, надеюсь, я когда-нибудь разберусь с этим. А сейчас пока внимаю твоим словам.