Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Программирование графики и GPU » Часто задаваемые вопросы по шейдерам


Часто задаваемые вопросы по шейдерам

Сообщений 1 страница 30 из 33

1

1.Как узнать расстояние до камеры в вершинном шейдере?
vec3 vPos = (gl_ModelViewMatrix*gl_Vertex).xyz;
float DistToCam = length(vPos);

2.Как узнать глобальные координаты вершины?
vec3 GPos = (gl_ModelViewMatrix*gl_Vertex).xyz;

3. Как получить направления взгляда камеры на вершину?
float view_vec = gl_Vertex.xyz-gl_ModelViewMatrixInverse[3].xyz;

4. А наоброт, направление взгляда вершины на камеру?
float view_vec = gl_ModelViewMatrixInverse[3].xyz-gl_Vertex.xyz;

5.Как получить вектор направления зрения?
vec3 viewVec = gl_ModelViewMatrixInverse[3].xyz - gl_Vertex.xyz;

6. Как узнать положение камеры в координатах объекта?
vec3 camPos = gl_ModelViewMatrixInverse[3].xyz;

7. Как получить координату фрагмента (текселя), который сейчас обрабатывается пиксельным шейдером?
gl_FragCoord.x
gl_FragCoord.y

Если у вас ещё есть вопросы для FAQ, пишите ниже.

Отредактировано DungeonLords (2009-12-06 14:41:20)

0

2

Спасибо, это здорово сделать FAQ по шейдерам.
Только если я не ошибаюсь в 5) это будет расстояние вдоль оси Oz

0

3

Steps3D написал(а):

Только если я не ошибаюсь в 5) это будет расстояние вдоль оси Oz

Вы правы, я ошибся. Исправил в первом посте.

"3. Как узнать глобальные координаты вектора?
??? [может вы скажите?]"
Как быть с этим?

Отредактировано DungeonLords (2009-11-09 09:35:25)

0

4

А что Вы понимаете под глобальными координатами,
скорее всего gl_Vertex * gl_ModelViewMatrix

0

5

Steps3D написал(а):

gl_Vertex * gl_ModelViewMatrix

А не наоборот ли часом? Всмысле порядка умножения.

0

6

"А что Вы понимаете под глобальными координатами,
скорее всего gl_Vertex * gl_ModelViewMatrix"
Точно, это то.

crsib, а большая разница?

Обновил FAQ, добавил 6 глупый вопрос с которым однажды один чувак столкнулся. Нужно мне кажется.

0

7

Согласен, ошибся, надо наоборот gl_ModelViewMatrix * gl_Vertex

0

8

Steps3D написал(а):

Согласен, ошибся, надо наоборот gl_ModelViewMatrix * gl_Vertex

Steps3D, crsib, а объясните почему? "От перестановки слагаемых сумма не немяется" - это моё объяснение.

0

9

Есть правила умножения матриц и там порядок существенен.
"От перестановки слагаемых сумма не немяется" - это частный случай, к умножению матриц он не применим.
В общем случае при изменении порядка может вообще операция стать недопустимой - так можно умножит матрицу 4*3 на 3*2 и получить при этома матрицу 4*2, но перемножить эти матрицы в оьбратном порядке просто нельзя 3*2 нельзя умножтиь на 4*3

0

10

Похоже, что это тоже надо добавить в FAQ - основы матрицных операций :))

0

11

А... Не, не надо в FAQ о"сновы матрицных операций", я просто забыл, что gl_ModelViewMatrix - это матрица.

0

12

DungeonLords написал(а):

я просто забыл, что gl_ModelViewMatrix - это матрица.

Учитывая что выше ты приводил матричные преобразования, то странно это слышать...

Steps3D написал(а):

А что Вы понимаете под глобальными координатами

Собственно нужно было бы начать это повествование с того, что такое этот самый gl_Vertex и что это вообще за такая модельная матрица, а то вон, кто-то думает что это и не матрица совсем, а скаляр :)
Вообще тут конечно нужно говорить о глобальных/мировых координатах, мне больше нравится это определение в DX, там используется название более соответствующее смыслу - WorldMatrix, и думаю этот момент нужно особенно выделить, так как из-за этого очень много путаницы.

DungeonLords, то что ты скопировал (http://www.glscene.ru/forum_viewtopic.php?15.38304) - далеко не все что я писал о матрицах трансформации, как и о матричных преобразованиях, мог бы постараться и выбрать из написанного ключевые моменты, так как эти советы, будучи выдранными из контекста, могут быть абсолютно бессмысленными без понимания основ.  Взять к примеру координаты камеры - я вот утверждаю что они всегда (0,0,0), а ты вон, какие-то обратные матрицы применяешь для их вычисления... Или взять направление зрения - я вот всегда считал что камера смотрит в направлении (0,0,-1), а ты вон тоже какие-то ужасные формулы приводишь. Кто ж из нас прав? ;)

Есть хорошая поговорка - "инициатива наказуема исполнением", сам просил "Если у вас ещё есть вопросы для FAQ, пишите ниже." - теперь вот отвечай :)

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

Отредактировано Fantom (2009-11-12 07:15:08)

0

13

Fantom
А самому есть что сказать насчёт последнего поста: http://www.glscene.ru/forum_viewtopic.php?15.37784.20

Fantom написал(а):

я вот утверждаю что они [координаты камеры] всегда (0,0,0)

Ну да, камера - пуп земли и всё такое. Но взять хотя бы нашу GLScene, там расстояние до камеры вполне конкретое число. Весь прикол этого финомина в том, что GL_ModelViewMatrix преобразует все координаты графических объектов в координаты "от камеры". Пример:  в точке (0;0;0) есть куб, камера в точке (10;10;0); мы применяем мировую матрицу и БАХ, камера в (0;0;0), куб в (10;10;0).

Та же фитча и с углом зрения.

Отредактировано DungeonLords (2009-11-13 22:00:43)

0

14

DungeonLords написал(а):

А самому есть что сказать насчёт последнего поста: http://www.glscene.ru/forum_viewtopic.php?15.37784.20

Есть - не копируй чужие посты, и не будет повода возмущаться что там ошибка. Многие вещи писались на заре моего изучения OpenGL/GLSL, потому там очень много неточностей. А возмущаюсь я именно потому, что ты копируешь все без разбора. Коль копируешь - хоть бы корректировал написанное.

Что же касается самой записи: gl_FragCoord.z/gl_FragCoord.w - вот выписка из спецификации GLSL:

"The variable gl_FragCoord is available as a read-only variable from within fragment shaders and it holds the window relative coordinates x, y, z, and 1/w values for the fragment. The z component is the depth value that would be used for the fragment’s depth if no shader contained no writes to gl_FragDepth."

Тоесть z - это у нас нормированная глубина сцены в данной точке, деление на w переводит координаты из оконных в глобальные (мировые).
На сколько мне известно - глубина сцены в данной точке это ничто иное как расстояние от точки наблюдения до точки пространства, тоесть расстояние от точки до камеры. Поправьте меня, если я не прав.

+1

15

Fantom написал(а):

Поправьте меня, если я не прав.

Поправь меня, если я неправильно написал в первом посте.

0

16

Не хочу влезать в горячую дискуссию двух мэтров 3d графики, познавших всю мощь glscene и выдержавших 10-ки боев друг с другом на его русскоязычном форуме (хорошая замена башу, особенно когда смотришь на дату постов). Но объясните мне, что вы понимаете под камерой.
Если она у вас "точечная", то как может быть

Fantom написал(а):

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

Если она не "точечная", то расскажите какая и какой смысл имееют координаты ее положения, которые вызывают у вас столько вопросов?

0

17

crsib написал(а):

Не хочу влезать в горячую дискуссию двух мэтров 3d графики

Не стесняйся, влезай. Лично для меня важнее истина.
Что же касается замечания о "мэтрах" откуда такие выводы? Наоборот, меня очень смущает что мои посты, в которых куча ошибок куда-то выкладываются, темболее на основе этих ошибок предлагается сделать фак. Особенно меня удивляет тот факт, что вы это поддерживаете.
Так же заставляет улыбнуться фраза "познавших всю мощь glscene", вы думаете что OGL в сцене отличается от OGL в вашем фрэймвоке? Или может думаете что что-то б изменилось будь я зарегистрирован на GameDev? Извините уважаемый, но это глупости, потому давайте впредь разговаривать по теме.

Теперь по теме вопроса:

Что такое камера? Это точка наблюдения имеющая координаты x,y,z, вектор, задающий направление наблюдения, и пирамида видимости, задаваемая через FOV (или же параллелепипед, в случае ортогональной проекции). Так же у нас имеется понятия ближней и дальней плоскости отсечения, при этом предполагается что плоскость экрана у нас соответствует ближней плоскости отсечения, задаваемой через ZNear.
В случае ортогональной проекции все понятия совпадают - глубина сцены = расстоянию объекта вдоль оси Z до плоскости камеры, как и писалось выше.
В случае перспективной проекции - понятие точки наблюдения и плоскости экрана уже не совпадают. Как по мне - вопрос не принципиальный, но раз уж его подняли - давайте разберемся, что ж именно возвращается в gl_FragCoord.z/gl_FragCoord.w, возможные варианты:
Предположим что камера находится в начале координат (0,0,0)
1. Расстояние от фрагмента объекта до точки наблюдения (gl_FragCoord.z/gl_FragCoord.w==sqrt(x*x+y*y+z*z))
2. Расстояние от фрагмента объекта до плоскости отсечения (gl_FragCoord.z/gl_FragCoord.w==sqrt(sqr(x*x+y*y+z*z)-zNear)
3. Расстояние от фрагмента объекта до точки пересечения с плоскостью отсечения (gl_FragCoord.z/gl_FragCoord.w==sqrt(sqr(x*x+y*y+sqr(z-zNear))-zNear)

В первом и третьем случае мы сразу получаем расстояние до точки наблюдения (+/-zNear), во втором случае - нам нужно учесть так же координаты фрагмента x,y, предварительно сделав процедуру UnProject.
Спрашивается - какой именно вариант тут работает? Ну или предложите свой.

0

18

Fantom написал(а):

Или может думаете что что-то б изменилось будь я зарегистрирован на GameDev

Вы зарегистрированны на gamedev. Если не ошибаюсь, как Fantom09.

Fantom написал(а):

Особенно меня удивляет тот факт, что вы это поддерживаете.

Что я поддерживаю? О_О

Fantom написал(а):

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

В чьем фреймворке? Напротив, у меня сложилось впечатление, что большая часть населения Вашего форума (я о нем узнал по ссылке в теме, а потом долго и увлеченно читал) считает OpenGL каким-то шаманством. При этом на форуме есть несколько шаманов, которым подобные Вам пытаются помочь, а подобные DungeonLords на них, гм, орут (что, кстати, явно наблюдается на этом форуме. Главный шаман тут, в данной терминологии, - Алексей)

Конкретно по "теме" вопроса. Для начала, мне не понятно, что имеется ввиду под x,y,z. Во всяком случае, если это координаты фрагмента, то:
Утверждения 1, 2, 3 не верны. 1 хотя бы осмысленно с точки зрения математики (но не с точки зрения поставленного вопроса). 2 и 3 - тупо по соображениям размерности

Хотя возможно моих тп способностей не хватило понять, что имеется ввиду в формулах 2 и 3

UPD. На всякий случай уберем элемент шаманства:
маленкая статья о сути перспективного преобразования координат

Отредактировано crsib (2009-11-15 00:21:39)

0

19

crsib написал(а):

Вы зарегистрированны на gamedev. Если не ошибаюсь, как Fantom09.

Действительно, зарегистрировался 2 дня назад, исключительно по причине упоминания моей статьи и мой темы DL.
Сомневаюсь что я в ближайшее время еще что-то там напишу, потому считайте что этого аккаунта нет и я там не зарегистрирован.

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

Теперь по теме:
"Утверждения 1, 2, 3 не верны"
В формулах действительно есть ошибки (мне лень было выводить формулы для описания бредовых вариантов), но я вас не просил написать что это бред - я вас просил рассказать что же именно возвращает gl_FragCoord.z/gl_FragCoord.w и как из этого получить расстояние от объекта до точки наблюдения, вы же опять ушли от ответа.
Что же касается вариантов - можно было бы догадаться, мы здесь не на литературном форуме и вы, надеюсь, не DungeonLords, чтоб разжевывать каждое слово, потому воспринимаю это либо как стёб либо как уклонение от ответа.

Хорошо, перефразирую еще раз:
Что же касается первого выражения - вы будете оспаривать теорему пифагора? И будете утверждать что расстояние между точками вычисляется по другим формулам? Заметьте - я не написал знак присвоить, я написал знак равенства (знака эквивалентно здесь нет).
Тоесть gl_FragCoord.z/gl_FragCoord.w является искомым решением (расстоянием от фрагмента до точки наблюдения).

Второй вариант -

Steps3D написал(а):

Только если я не ошибаюсь в 5) это будет расстояние вдоль оси Oz

Относился к этому утверждению, действительно, там нужно было бы записать gl_FragCoord.z/gl_FragCoord.w==Z-ZNear(или просто Z?), но до этого можно было бы догадаться исходя из описания. В этом случае, прежде чем определить расстояние до точки наблюдения (у нас ведь имеется лишь координата Z, а координаты X,Y у нас все еще оконные) нам придется выполнить обратную процедуру, тоесть домножить на w, после чего домножить на обратную проекционную матрицу (модельную и видовую трансформацию можно не производить, так как по условию камера находится в координатах (0,0,0)). И лишь после получения этих координат мы будем иметь право вычислить расстояние до точки наблюдения.

Третий пункт - если из точки наблюдения провести отрезок к объекту (в точку x,y,z), то он пересечет плоскость z=zNear в точках Xnear,Ynear,Znear, в этом случае, если (обращаю внимание на то, что я предлагаю варианты а не утверждаю) gl_FragCoord.z/gl_FragCoord.w есть ничем иным как расстоянием между точками A(x,y,z) и B(Xnear,Ynear,Znear), то расстояние до точки наблюдения будет вычисляться как:
Distance=sqrt(Xnear^2+Ynear^2+Znear^2)+gl_FragCoord.z/gl_FragCoord.w

Надеюсь так будет понятнее о чем я говорил, если нет - не стесняйтесь, спрашивайте.

Так же напоминаю - есть еще Ваш вариант, где я Вам предлагаю записать так как это будет правильно.

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

Отредактировано Fantom (2009-11-15 01:45:39)

0

20

Алексей уже написал, что есть gl_FragCoord.z/gl_FragCoord.w. Я привел ссылку на статью, с подробным объяснением как осуществляется переход в Normalized Device Coordinates, которые, по сути, и попадают на вход фрагментного шейдера. Вы продожаете, однако, настаивать, что это каким-то образом является расстоянием от точки до точки. Да, если x,y фрагмента равны 0, то это так. В остальных случаях, расстояие от (0,0,0) до фрагмента действительно будет вычисляться как sqrt(x^2 + y^2 + z^2), но это будет не равно и не присвоенно значению z/w за исключением вышеописанного вырожденного случая.

Fantom написал(а):

Не стоило. Я вот тоже так предполагал, что FragCoord.z есть ни что иное как координата z после применения перспективной матрицы, пока не прочитал что об этом написано в спецификации GLSL, теперь мне требуется аргументы по существеннее матриц трансформации, и я очень надеюсь получить их от вас.

Не умение читать (особенно с такой любовью к цитированию) до добра не доводит:
This value is the result of the fixed functionality that interpolates primitives after vertex processing to generate fragments.

Для получние корректности определения самого понятия камеры вершинный шейдер должен выполнить преобразование World -> View -> NDC. Перед растеризацией выполняется линейное пребразование во вьюпорт координаты (так как от этого зависит колличество фрагментов на растеризации).
Window Coordinates result from scaling and translating Normalized Device Coordinates by the viewport. The parameters to glViewport() and glDepthRange() control this transformation. With the viewport, you can map the Normalized Device Coordinate cube to any location in your window and depth buffer.

Советую почитать целиком пункт 9.011

0

21

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

FragCoord.z=depth
FragCoord.w=1/Wc
где
depth = -(ZFar+ZNear)/(ZFar-ZNear)+2*ZFar*ZNear/(ZFar-ZNear)/Zeye
Wc = -Zeye

Вот отсюда видно, что наш FragCoord.z содержит нормированные координаты устройства (NDC), тоесть выражение FragCoord.z/FragCoord.w ничего нам не даст (мы получим лишь координаты в пространстве отсечения Zc), а расстояние до точки наблюдения вдоль оси Z, о котором писал Алексей, это просто -1/FragCoord.w

Неужели было так сложно сразу это написать?
И, кстати, об этом даже написано в статье Алексея: http://www.steps3d.narod.ru/tutorials/d … orial.html

Отредактировано Fantom (2009-11-15 14:11:38)

0

22

Fantom написал(а):

Неужели было так сложно сразу это написать?

Вы спрашивали не об этом. Вас интересовало расстояние от фрагмента до камеры.

Я вам привел статью, которая очень детально разбирает, как переходит преобразование в NDC. У Вас возникли вопросы касательно спецификации GLSL. Я Вам объяснил что приходит в gl_FragCoord.

Так или иначе, вы смогли сделать почти верный вывод (или же воспользовались помощью статьи Алексея). Вот только в gl_FragCoord приходят несколько другие данные. Их можно использовать как некую оценочную характеристику для выборки lod'a во фрагментном шейдере (вот только как делать выборку лода (до SM40), да и зачем, мне непонятно)

Если бы Вы более внимательно читали статью Алексея, то вы бы поняли, что он описывал, как восстановить по значению буффера глубины координаты во view-space.

0

23

crsib написал(а):

Вы спрашивали не об этом
Я вам привел статью, которая очень детально разбирает, как переходит преобразование в NDC

Все верно, я спрашивал не об этом.

crsib написал(а):

Я Вам объяснил что приходит в gl_FragCoord.

Извините, но вы ничего не объяснили, вы привели ссылки на статьи, по которым вы бы и сами не поняли о чем речь. Чтоб понять что приходит в gl_FragCoord нужно было вначале открыть спецификацию GLSL и найти уточнения что gl_FragCoord.z является координатой в пространстве NDC (а ведь там могли быть и координаты в пространстве отсечения), это нужно было просто знать, а в указанных вами ссылках об этом ничего не сказано. Узнать об этом можно было из спецификации OpenGL (главы 2.16, 3.12) где расписывалось что же все-таки туда приходит, вот только после этого можно было открывать статью по матрицам трансформации, и потерять недельку времени на изучение вопроса (если учитывать что некоторые из присутствующих здесь считают что от перестановки слагаемых сумма не меняется), вот только потом, записав соответствующие преобразования увидеть что же все-таки там хранится.

Весь фокус в том, что по вашим советам найти ответ сможет только то, кто сам знает ответ (вы же не думали что я начал этот разговор не зная ответа?). К тому же ваши выводы тут так же были ошибочными, так как FragCoord.z/FragCoord.w возвращает расстояние вдоль оси Z до точки наблюдения только в одном случае - когда ближняя плоскость отсечения проходит через Z=0, но в этом случае Zeye будет как раз равно расстоянию между точкой наблюдения и объектом (сами подумайте почему так, можете заглянуть в статью по формированию проекционной матрицы, и посмотреть что будет если ZNear приравнять к нулю, особенно обратите внимание на то, что случается с координатами Xс,Yс).

crsib написал(а):

Если бы Вы более внимательно читали статью Алексея

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

Мне вот интересно - сколько бы еще прошло времени, прежде чем вы все-таки объяснили "идиоту с GLScene.ru" о том, что-же все-таки передается в gl_FragCoord.z...
А ведь этот сайт вроде как посвящен первым шагам... а топик вообще посвящен людям, впервые столкнувшимся с GLSL и не имеющим понятие о том что вообще такое gl_FragCoord, не говоря о матрицах преобразования и каких-то нормированных координатах устройства...

Ну и напоследок:

crsib написал(а):

вот только как делать выборку лода (до SM40)

Texture2DLod, Texture2D(sampler,coord,bias), Texture2DGrad

Отредактировано Fantom (2009-11-15 17:26:36)

0

24

Мда. Пошел жесткий флуд. Впрочем, это было на 100% ожидаемо

Fantom написал(а):

Texture2DLod

The built-ins suffixed with “Lod” are allowed only in a vertex shader.  For the “Lod” functions, lod is directly used as the level of detail. . В GL_ext_gpu_shader4, правда есть строчка:

Remove the first sentence in the last paragraph:

    "The built-ins suffixed with "Lod" are allowed only in a vertex shader.".

Соответсвенно в случае не SM4.0 карт во фрагментном шейдере нельзя явно указывать Lod. Более того, ситуции когда это нужно "очень" специфичны и сравнительно редки.

Fantom, пожалуйста, еще раз внимательно перечитайте нашу с Вами дискуссию. Последний пост дает мне почти полную уверенность, что из моих постов Вы вырываете отдельные фразы *вне* их контекста.

Например, если бы Вы внимательно читали пост номер 20, вы бы знали, что gl_FragCoord находится в sreen-space, а не является NDC. Если бы вы прошли по ссылке 18 поста, то знали бы что gl_FragCoord.w = -1/z_eye. Правда Вы видимо не понимаете, что z_eye является z координтой вершины во View space, а не расстоянием до камеры. По ссылке в посте 20 вы бы получили выдержки из 2.16 и 3.11.

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

0

25

crsib написал(а):

The built-ins suffixed with “Lod” are allowed only in a vertex shader.  For the “Lod” functions, lod is directly used as the level of detail.

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

Если вы не пробовали - скажу что это прекрасно работает на всех видеокартах. Кроме нее я вам так же привел еще две функции - в обычном Texture2D можно указать смещение от начала ЛОДа, тем самым можно так же контролировать процесс смены мип уровней.

Так же, благодаря расширениям GL_ARB_shader_texture_lod и GL_ATI_shader_texture_lod мы можем вручную задавать не только лоды, но и градиенты.

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

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

Давайте сразу на любой вопрос давать ссылку на Opengl.org, спецификацию OpenGL2.0/3.x GLSL 1.2/1.5, ведь там все есть!!! Зачем вообще трудиться и записывать 3 строчки кода!!! Читайте товарищи, читайте!!! Зачем форумы, зачем ФАК, зачем статьи - сидите, выводите формулы, читайте англоязычные спецификации, а мы будем тут сидеть и делать умный вид... 

crsib написал(а):

Если бы вы прошли по ссылке 18 поста, то знали бы что gl_FragCoord.w = -1/z_eye

Угу, как раз в матрице перспективной трансформации записано что gl_FragCoord.w = -1/z_eye, долго думали?
В матрице перспективной трансформации записано лишь что wc=-zeye и не более того.
К тому же перечитайте 21-й пост:
FragCoord.w=1/Wc
Wc = -Zeye
Видно подставить вместо Wc его значение выше ваших сил... Как впрочем и явно записать чему равно gl_FragCoord.w, конечно, проще с умнім видом послать разбираться в математике перспективной проекции.

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

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

0

26

Fantom написал(а):

Угу, как раз в матрице перспективной трансформации записано что gl_FragCoord.w = -1/z_eye, долго думали?

Ваше неумение (иле нежелание) читать делают эту дискуссию абсолютно бессмысленной.

Я великолепно знаком с texture2DLod. Все приведенные вами примеры ее необходимости во фрагментном шейдере ведут к dynamic branch'ингу. И реально дешевле переделать атлас (и гораздо правильней) чем нагружать фрагментный шейдр бранчингом. То же относится по сути и к "выбору" шейдера на лету. Почитайте пейпры той же nVidia на тему почему dynamic branch это плохо, особенно на уровне фрагментного и compute shader'a (/CUDA/OpenCL kernel'a)

0

27

crsib написал(а):

Почитайте пейпры той же nVidia

Ну вот, опять по новой... Типа раз вам делать нечего - перечитайте 20 публикаций NVidia, где встречаются слова "dynamic branch", может что-то и найдете...

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

А из того что я видел, к примеру это:
http://developer.nvidia.com/docs/IO/823 … haders.pdf
Так тут наоборот - хвалятся какую крутую штуку они сделали.
Старая статья? Дайте ссылку на новую.

0

28

Такс, вопрос является Oz в записи:
float Oz = gl_FragCoord.z/gl_FragCoord.w;
расстояние от точки O до камеры был задан на официальном форуме opengl, короче пришлось привлекать иностранных коллег. Ответ пришёл от " Тёмного Фотона" ("Dark Photon") и был НЕТ! И много чего ещё по английски:

>>Please say, is gl_FragCoord.z/gl_FragCoord.w a distance from the point to camera?
Nope. Check the spec.

gl_FragCoord is window-relative (screen) coordinates. .xy is pixel units of the center of the fragment. .z is the depth value that'll be written to the depth buffer (0..1). .w is 1/clip_space.w, where (for perspective projections only!!) clip_space.w is -eye_space.z, so: gl_FragCoord.w = -1/eye_space.z ... for perspective projections only!

For orthographic projections, gl_FragCoord.w should just be 1 (i.e. 1/clip_space.w, i.e. 1/eye_space.w, where eye_space.w == 1).

For confirmation, see the last row of the perspective and orthographic projection transforms in Appendix F of the Red Book.

So for a perspective projection, you probably want -1/gl_FragCoord.w. Keep in mind this gives you eye-space Z, where values in front of the screen are negative. If you want positive, don't negate.

Also, you said you wanted a distance from the point to the camera (eyepoint, presumably). This is not what eye_space Z is! eye_space Z is a minimum distance from the XY plane in eye-space to the point, not a radial distance from the eyepoint (0,0,0) to the point. This is the same concept as between EYE_PLANE fog coordinate mode and EYE_RADIAL fog coordinate modes, from the pre-shader days.

Как вы видите, он отсылает нас к спеку. Ну да ладно, вот перевод:
gl_FragCoord это оконные (экранные) координаты. [далее до конца предложения перевод какой-то сомнительный] .xy это пиксели центра фрагмента. .z это глубина, она будет записана в буфер глубины (0..1). .w это 1//clip_space.w, где (только для перспективной проекции!) clip_space.w это -eye_space.z, так: gl_FragCoord.w = -1/eye_space.z ...

Для ортогональной проекции gl_FragCoord.w будет 1 ((т.e. 1/clip_space.w, i.e. 1/eye_space.w, where eye_space.w == 1).)

Для подтверждения [дальше сами - see the last row of the perspective and orthographic projection transforms in Appendix F of the Red Book.]

Так для перспективной проекции ты наверное хочешь -1/gl_FragCoord.w. Имейте в виду, это дает вам направление пространства Z, где значения в передней части экрана отрицательные. Если вы хотите положительные, [дальше сами - don't negate].

Так же вы сказали что хотели получить дистанцию от точки до камеры. Это НЕ This eye_space Z! eye_space Z это минимальная дистанция от XY плоскости в пространстве камеры [eye-space] до точки, не радиальное расстояние от eyepoint (0,0,0)  до точки. is the same concept as between EYE_PLANE fog coordinate mode and EYE_RADIAL fog coordinate modes, from the pre-shader days.

В общем как-то так. Правки для перевода приветствуются.

0

29

Все это было многократно сказанно выше.

crsib написал(а):

чем нагружать фрагментный шейдр бранчингом

Приношу свои извинения. На ATI все работает круто (особенно если бранчинг используется для раннего выполнения discard). А вот NVidia до сих пор во всех пейпрах по GPGPU (особенно по CUDA и OpenCL) не рекомендует dynamic branching. И реально по тестам все новые ускортели системы себя так (на gf6 и gf7 все было лучше), будто выполняют весь код шейдера/кернела. Будем надеятся что Fermi будет вести себя более адекватно...

Отредактировано crsib (2009-11-20 12:01:50)

0

30

Переписал 1-ый пост. Спасибо Fantom.

0


Вы здесь » Компьютерная графика » Программирование графики и GPU » Часто задаваемые вопросы по шейдерам


создать форум