- romanshuvalov
- Модератор
ALPINE
Мы вроде про юниформы говорим.
Если говорить о атрибутах, то ИМХО логичнее сделать проверку в коде, а не городить велосипеды в шейдерах.
Но тут я думаю косяк в спецификации, так как location int, а функция glVertexAttribPointer принимает uint, в итоге получается большое число из-за которого и ошибка.
Лучше использовать glBindAttribLocation на мой взгляд.
ALPINE
> При выполнении
> glVertexAttribPointer(a_uv, 4, GL_FLOAT, GL_FALSE, 12 * sizeof(float), data + 4 );
> получаю GL_INVALID_VALUE, поскольку a_uv = -1.
Зачем так делать?
ALPINE
А в первых двух случаях ошибок разве никаких нет? В первой уж точно должна быть - статус соответствующий будет, валидация не пройдёт.
Я тебя понял, ты хочешь сказать, что первый пункт можно отсечь с помощью специального функционала, который нам скажет о невозможности сбилдить шейдер. Но в любом случае glGetUniformLocation() возвращает -1 ко всем переменным несозданного шейдера. Так что я не мог выбросить этот пункт.
Про второй случай вот не знаю, но никто в здравом уме не будет искать отсутствующую переменную, так ведь? А вот в третьем случае однозначно не скажешь, что переменная отсутствует - ты её определил и вроде как даже использовал. А её нет. Именно из-за этого ситуация несколько сбивающая с толку и именно из-за этого я о ней и рассказал.
С таким же успехом можно сказать, что никто в здравом уме не будет объявлять переменных, которые потом не собирается использовать. Ошибка способна закрасться везде, так что, лучше вооружиться достоверной информацией. Например, банальная подмена шейдера относительно материала или наоборот, приведет к злосчастной -1-це и думай потом, что все переменные кагбэ на месте, шейдер сбилдился, откуда -1?
Но это опять же мое ИМХО, я бы как-то по другому назвал бы статтю, например: "Автоматическое исключение неиспользованных переменных в GLSL во время компиляции и его последствия."
Executor
> Мы вроде про юниформы говорим.
А. Ну и про них, и про аттрибуты. Не стал загромождать заголовок статьи, наверное, это мой косяк.
> ИМХО логичнее сделать проверку в коде
Когда шейдер будет дописан и отлажен (читай: в релизе), таких ситуаций в принципе быть не может. Поэтому проверку и не делал.
SNVampyre
> Зачем так делать?
Написал же - разрабатываю шейдер, экспериментирую, дописываю строчки, комментирую старые... и тут бац - получилось, что результат вычислений затёрся (или вообще закомментирован). Отсюда location = -1.
Cyber_Wanderer
> С таким же успехом можно сказать, что никто в здравом уме не будет объявлять
> переменных, которые потом не собирается использовать.
Написал же - разрабатываю шейдер, экспериментирую, дописываю строчки, комментирую старые...
Подытоживая последние несколько сообщений - я показал, откуда могут возникнуть подобного рода ошибки, т.к. увидев замусоренный лог далеко не сразу разобрался, в чём дело. Теперь, когда я знаю, что такие вещи бывают, я при подобных ситуациях ошибку найду быстрее. Поэтому и решил поделиться опытом в надежде, что это поможет кому-нибудь сократить время на поиск ошибки.
ALPINE
> > Мы вроде про юниформы говорим.
> А. Ну и про них, и про аттрибуты.
э... это очень сильно разные вещи и их нужно готовить раздельно :)
> и тут бац - получилось, что результат вычислений затёрся (или вообще
> закомментирован). Отсюда location = -1.
1) Делай гибкую систему, чтобы обрабатывала -1 как нормально. Типа есть список общих юниформов на все случая жизни и их нужно почекать 1 раз
2) Делай UBO или его аналог с массивом
3) Ничего не делай ... самое полезное
странно, что в подсказке не сказано, что юниформы не выкинутые компилятором называются активными
и их список можно получить с помощью функции glGetActiveUniform
Тема в архиве.