Каковы плюсы / минусы трех?
Каковы плюсы / минусы трех?
Ответы:
Coderanger прав в том, что HLSL для DirectX, GLSL для OpenGL и CG доступны с обоими интерфейсами.
Однако есть и другие вещи, которые следует учесть (узнал на форуме OGRE):
Так что, если вы не используете последние функции шейдеров, CG кажется хорошим выбором. GLSL, кажется, лучше, если вы собираетесь использовать OpenGL. HLSL, если вы собираетесь исключительно на платформах Microsoft.
Теперь сначала разработка HLSL для Windows для использования DirectX, а затем преобразование в GLSL для Linux и Mac может стать лучшим решением, чтобы быть уверенным в производительности и иметь больший набор доступных функций шейдеров. Однако это может быть много работы (не делал это сам, поэтому я не могу сказать). Графический движок OGRE (и другие движки) позволяет использовать любой API (DirectX или OpenGL или другие), так что это помогает, но есть шейдерный код, который нужно преобразовать, если вы пойдете этим путем.
Вот и вся информация, которую я собрал при выборе языка шейдера (пока я не принял решение).
Обновление: Valve конвертировал одну из своих игр в OpenGL и не нашел способа сделать версию DirectX быстрее, чем версия OGL . Так что имейте в виду, что состояние реализации драйверов, качество API и т. Д. Все это слишком сильно меняется каждый год, чтобы вы полностью полагались на необработанную производительность в качестве аргумента при выборе того или другого. Имея это в виду, выберите OpenGL / GLSL, чтобы упростить свою жизнь при работе (или с планами или надеждами на работу) с другими платформами, отличными от Windows, используйте DirectX / HLSL, если вы действительно хотите использовать только платформы Microsoft и сосредоточиться, и, возможно, иметь некоторые хорошие API работает быстрее, чем OpenGL (сейчас все наоборот, поэтому не рассчитывайте на это); используйте CG, если вы хотите предоставить обе возможности пользователю, но если у вас есть рабочая сила (и инструменты) для этого, использование GLSL и HLSL также может быть жизнеспособным решением.
Обновление (2012): важно отметить, что CG больше не поддерживается и больше не поддерживается или активно не работает над Nvidia. Nvidia рекомендует всем пользователям переключаться на комбинацию GLSL и HLSL или на более новую библиотеку, такую как nvFX (на github). Это потому, что было слишком сложно поддерживать совместимость функций между GLSL и HLSL.
Я могу говорить только о CG против HLSL, потому что это те 2, которые я использовал до сих пор.
Cg - это не то же самое, что HLSL.
В Cg NVIDIA отлично поработала над созданием очень чистого синтаксиса шейдера. Это очень похоже на HLSL.
Но связывание с D3D9 / D3D11 (код инициализации, код компиляции шейдера) на HLSL намного чище, чем на Cg. -1 Cg. Cg имеет неприятный стартовый код, который вам даже не нужен для HLSL по сравнению с D3D.
В Cg вам нужно «cgGetNamedParameter» для каждой uniform
переменной шейдера, которую вы хотите установить / изменить. И вы должны поддерживать CGparameter
ссылку в вашем коде для этой переменной
// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" );
CG::getLastError("Getting modelViewProj parameter"); // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ; // setting the matrix values
В HLSL все получается намного чище - всего одна строка, и вам не нужно поддерживать эту CGparameter
переменную.
// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;
Выше, DX_CHECK
это просто простая функция, которая проверяет HRESULT, который возвращается из SetMatrix
вызова. Код выше d3d9 . D3D10 и 11, конечно, намного более болезненны (поскольку нет объекта ID3DX11Effect).
До того, как я начал использовать HLSL, я обычно смотрел на этот код и действительно завидовал .
Хотя NVIDIA сделали все возможное , чтобы сделать общий интерфейс для Cg между OpenGL / D3D, практически говоря его не тот путь, и у вас есть cgGL*
, cgD3D9
, cgD3D10
,cgD3D11
функциональные группы , чтобы бороться с. Так что все это работает для OpenGL и D3D! претензия заходит так далеко. Вам все еще нужно объединить все в #ifdef
группы типов OpenGL / D3D, чтобы это работало на разных платформах. -2 Cg.
Кроме того, недавно у меня был плохой опыт работы с картами Cg / ATI, и я уверен, что это не плохо. (Кто-нибудь еще попробует?). Я думаю, что это может быть правдой, что NVIDIA не полностью тестирует карты ATI, как утверждает Клайм. Или что ATI не тестирует на Cg. Так или иначе, есть несоответствие и какой-то конфликт интересов. -3 Кг.
В целом я предпочел Cg. Его синтаксис и наименование шейдерного кода чистые, приятные и аккуратные. Это слишком плохо, у него есть эти другие проблемы.
Я очень хорошо понимаю, что HLSL предназначен только для DirectX, а GLSL - только для OpenGL. Cg в основном тот же язык, что и HLSL, но может использоваться как с DirectX, так и с OpenGL (хотя и с помощью другого кода времени выполнения).
Другое принципиальное различие между HLSL и GLSL (я не знаю CG, поэтому не могу говорить за него) состоит в том, что с HLSL Microsoft предоставляет компилятор шейдеров как часть времени выполнения D3D, тогда как с GLSL ваш поставщик оборудования предоставляет его как часть своих Водитель.
Это имеет свои преимущества и недостатки с обеих сторон.
С помощью метода GLSL поставщик может настроить компилятор на возможности своего оборудования. Они лучше знают свое собственное оборудование, знают, что делать, а что нет. С другой стороны, недостатком является то, что - в мире, где есть несколько поставщиков оборудования, - у вас есть ситуация, когда между шейдерными компиляторами могут быть несоответствия, и у поставщика также есть полное свободное господство, чтобы облажаться.
С помощью метода HLSL Microsoft управляет компилятором. У всех есть постоянная техническая база, и если шейдер успешно компилируется в одном месте, то разумно предположить, что он будет компилироваться везде. Один и тот же шейдер будет выдавать один и тот же скомпилированный вывод независимо от поставщика (конечно, при прочих равных условиях). С другой стороны, HLSL-компилятор должен быть «работающим согласованно на всем», поэтому он не может использовать какие-либо специальные приемы, специфичные для конкретного производителя, чтобы получить последние несколько капель сока из бака.
Если мне кажется, что у меня есть предпочтение взглянуть на мир с помощью HLSL, то это потому, что я это делаю. Раньше меня сильно укусило дико непоследовательное поведение на разных платформах, и в одном случае даже пришлось откатить загрузку GLSL обратно в ARB ASM только для того, чтобы получить базовый уровень, который работал. GLSL-компилятор NVIDIA может рассматриваться здесь как особенно известный - он даже примет синтаксис HLSL и ключевые слова, а это означает, что если вы не будете осторожны, вы можете получить шейдеры, которые будут работать только на NVIDIA и ничего больше. Это джунгли там.
Возможно, вы захотите взглянуть на RTSS (Run Time Shader System), которая также поставляется с Ogre. Это довольно новое, но вы в основном пишете шейдеры в коде, а не во внешних файлах. Я еще не реализовал это, но определенно планирую использовать это, когда придет время.
Вот огромная серия учебников по вики Ogre, а также для написания шейдеров. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide
Что касается вашего исходного вопроса, как сказал Претор, на самом деле это не вопрос плюсов / минусов, это вопрос, какую систему рендеринга вы собираетесь использовать. Поскольку использование DX / OpenGL с Ogre - это всего лишь вопрос загрузки плагина, вы, скорее всего, захотите использовать формат .cg.