Как я могу включить физику в процедурный мир из геометрического шейдера?

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

Это нормально и все. Но я также хочу динамически деформировать мир в режиме реального времени. Как только я дошел до этого момента, у меня возникла проблема с попыткой вернуть вершины в ЦП, чтобы выполнить такие вещи, как обнаружение столкновений и все игровые вычисления, которые я хочу задействовать на ЦП, а не на ГП.

Таким образом, вопрос заключается в следующем: как я могу вернуть подмножество вершин обратно в ЦП для решения конфликтов между прочим?

И еще один вопрос: есть ли простой способ взять набор вершин и сгенерировать из них индексы на GPU?

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

Я использую C # 4.0, .NET 4.0 и XNA Game Studio 4.0.

c# xna shaders

— Майкл Дж. Грей
источник

Вы говорите, что в названии используете геометрический шейдер, но вы также говорите, что используете XNA4.0, насколько мне известно, для XNA 4.0 требуется DirectX 10 (чтобы упростить разработку для более унифицированной платформы), но поддерживает только функции SM3.0, поэтому геометрический шейдер отсутствует. forums.create.msdn.com/forums/p/31369/178924.aspx

— Рой Т.

И теперь я больше не буду использовать XNA или переделывать свой дизайн. Спасибо что подметил это. Я изучал это и не осознавал этого ограничения (нет SM 4). Я предполагаю, что вопрос все еще остается, хотя, без рассмотрения XNA. Так, с точки зрения только DirectX, есть ли способ сделать то, что я хочу? Или, возможно, с вершинным шейдером в XNA?

Что ж, XNA все еще пригоден для использования, если только у вас нет проверенного тестового примера, где деформации и генерация слишком медленные. И что вы доказали в другом тестовом примере, что графическая деформация + генерация и последующая передача данных в процессор быстрее :)

— Рой Т.

Верно. Мы обнаружили, что использование XNA и хранение всего на процессоре дало нам около 1 миллиона вершин примерно за три минуты на Core i7 с 8 ядрами и 8 потоками, распараллеливающими несколько участков ландшафта на поток. При попытке сделать это в режиме реального времени и, надеюсь, рендеринга ландшафта до того, как игрок сможет его увидеть, мы достигли примерно 20 кадров в секунду. Итак, контрольный пример определенно соответствует каждому из методов.

— Майкл Дж. Грей

Поскольку XNA не поддерживает геометрические шейдеры, я отвечу так, как если бы вы использовали DX 10. У вас по сути есть три варианта.

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

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

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

Пиксельные шейдеры Последний вариант, который вы также упомянули в своем вопросе: создайте плотности в пиксельных шейдерах и запишите их в 3D-текстуру. Вы можете получить доступ к этому из процессора и шейдеров довольно безобидно. Пиксельный шейдер идеально подходит для этой задачи, но у этого метода много накладных расходов. Рендеринг текстуры объема, а также выборка из in в вершине и гео. шейдеры и необходимость читать текстуры на процессор.

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

— Hannesh
источник

Основной проблемой у нас был барьер между GPU и процессором. В смысле, как только мы генерируем и визуализируем ландшафт на графическом процессоре, как мы выясним, как выглядит ландшафт на стороне процессора, чтобы делать столкновения и другие вещи. Я полагаю, ваша мысль о том, чтобы сохранить его на процессоре, верна. Я имею в виду, что мы, возможно, можем немного оптимизировать наш алгоритм и создать меньше рельефа. Я отмечу ваш ответ как решение через день или два, чтобы посмотреть, есть ли у кого-нибудь еще ответ. Спасибо за провокацию альтернативных мыслей.

— Майкл Дж. Грей

С вашим примером плавания, вы не могли бы легко соединить результат формы волны, когда лодка плывет по волнам, к графическому процессору, верно?

— замедленная

Вы можете сохранить ту же систему рендеринга, то есть генерировать и рендерить ландшафт на GPU, но отражать части ландшафта, которые вам нужны на CPU. Используя тот же алгоритм и те же параметры, вы получите ту же местность на процессоре, что и на экране.

— Ханнеш

@Daniel Не напрямую с волновым алгоритмом, но возможно деформировать сетку воды в соответствии с движением лодки с помощью текстуры смещения, которую каждая лодка «тащит» за собой.

— Ханнеш

Ах! Это отличная идея :). Но он, вероятно, не очень хорошо поддерживает несколько судов.

— замедленная