Войти
ПрограммированиеФорумГрафика

GLSL: о причине, по которой glGetUniformLocation() может вернуть -1 (комментарии) (2 стр)

Страницы: 1 2
#15
15:57, 29 янв. 2013

ALPINE
Мы вроде про юниформы говорим.
Если говорить о атрибутах, то ИМХО логичнее сделать проверку в коде, а не городить велосипеды в шейдерах.
Но тут я думаю косяк в спецификации, так как location int, а функция glVertexAttribPointer принимает uint, в итоге получается большое число из-за которого и ошибка.
Лучше использовать glBindAttribLocation на мой взгляд.

#16
16:06, 29 янв. 2013

ALPINE
> При выполнении
> glVertexAttribPointer(a_uv, 4, GL_FLOAT, GL_FALSE, 12 * sizeof(float), data + 4 );
> получаю GL_INVALID_VALUE, поскольку a_uv = -1.
Зачем так делать?

#17
16:27, 29 янв. 2013

ALPINE

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

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

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

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

Но это опять же мое ИМХО, я бы как-то по другому назвал бы статтю, например: "Автоматическое исключение неиспользованных переменных в GLSL во время компиляции и его последствия."

#18
16:37, 29 янв. 2013

Executor
> Мы вроде про юниформы говорим.
А. Ну и про них, и про аттрибуты. Не стал загромождать заголовок статьи, наверное, это мой косяк.

> ИМХО логичнее сделать проверку в коде
Когда шейдер будет дописан и отлажен (читай: в релизе), таких ситуаций в принципе быть не может. Поэтому проверку и не делал.

SNVampyre
> Зачем так делать?
Написал же - разрабатываю шейдер, экспериментирую, дописываю строчки, комментирую старые... и тут бац - получилось, что результат вычислений затёрся (или вообще закомментирован). Отсюда location = -1.

Cyber_Wanderer
> С таким же успехом можно сказать, что никто в здравом уме не будет объявлять
> переменных, которые потом не собирается использовать.
Написал же - разрабатываю шейдер, экспериментирую, дописываю строчки, комментирую старые...

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

#19
17:30, 29 янв. 2013

ALPINE
> > Мы вроде про юниформы говорим.
> А. Ну и про них, и про аттрибуты.

э... это очень сильно разные вещи и их нужно готовить раздельно :)

> и тут бац - получилось, что результат вычислений затёрся (или вообще
> закомментирован). Отсюда location = -1.

1) Делай гибкую систему, чтобы обрабатывала -1 как нормально. Типа есть список общих юниформов на все случая жизни и их нужно почекать 1 раз
2) Делай UBO или его аналог с массивом
3) Ничего не делай ... самое полезное

Прошло более 10 месяцев
#20
21:16, 25 ноя. 2013

странно, что в подсказке не сказано, что юниформы не выкинутые компилятором называются активными
и их список можно получить с помощью функции glGetActiveUniform

Страницы: 1 2
ПрограммированиеФорумГрафика

Тема в архиве.