http://acko.net/files/fullfrontal/fullfrontal/webglmath/online.html
Красивая вводная презентация по основам графики со всякой интерактивщиной.
>>125580
Ещё книги по математике:
http://www.amazon.com/Math-Primer-Graphics-Development-Edition/dp/1568817231/
http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Edition/dp/1435458869
Книги по разработке игр:
http://mrelusive.com/books/books.html
Книги по GLSL:
http://www.amazon.com/OpenGL-Development-Cookbook-Muhammad-Movania/dp/1849695040/
http://www.amazon.com/OpenGL-Shading-Language-Cookbook-Edition/dp/1782167021/
>>125580
Математическая библиотека:
http://glm.g-truc.net/0.9.5/index.html
Библиотеки для создания контекста:
http://www.glfw.org/
http://freeglut.sourceforge.net/
Подключение расширений:
http://glew.sourceforge.net/
Ещё тьюториалы:
http://code.google.com/p/gl33lessons/
http://vbomesh.blogspot.ru/
Пмойму мы столько сюда накидали, что тред будет мертв пару недель.
И это даже хорошо чем-то
Охуительные подборки. Ой аноны, ой какие молодцы. В кои-то веки такая стопроцентная годнота на дваче. Поклон и спасибо. К ОП посту - Game Programming Gems есть еще аж 8 http://rutracker.org/forum/viewtopic.php?t=2893913 . А где нарыть Game Programming Gems 5 и 7?
>>125623
У меня нету ни 5ой ни 7ой части.
Может быть на форчонге спросить в разделе торрентов?
>>125623
http://www.lighthouse3d.com/2011/05/game-programming-gems-series/
тут моя любимая фраза про использование гугла, но тут лучше яндекс, гугл последние года 3 удаляет поисковые результаты с файлообменников.
Альзо:
http://www.amazon.com/Computing-Gems-Edition-Applications-Series/dp/0123859638
Ну и глупо не пользоваться тбториалами от Нвидии:
https://developer.nvidia.com/opengl
>>125627
+ годная статья по ССАО:
http://habrahabr.ru/post/204260/
+ пейпер по ССДО http://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf
Он сучка, раньше меня написал. На год. Вы бы знали мой батхерт когда я нашел его пейпер, а у меня такая же идея.
>>125627
>http://www.lighthouse3d.com/2011/05/game-programming-gems-series/
Ну и что это за линк? Краткое содержание всех книг? Спасибо за гугль и яндекс, но я пробовал. На трекерах пусто, на файлопомойках пусто или дохлые линки. Если тебе повезло и ты нашел рабочий линк - кинь сюда.
>>125629
>Годная статья по САСАО
http://www.gametutorials.com/tutorials/opengl-tutorials/
Регистрируйся и качай.
>>125845
>>125839
Обещали уроки, вроде бы, переписать на современный лад.
Осталось только ждать.
http://habrahabr.ru/post/229585/
> Все уроки проверены на совместимость с Visual Studio 2013, в самом ближайшем будущем ожидаются уроки по Unreal Engine и Unity Engine, кроме того, будут обновлены устаревшие уроки по OpenGL и DirectX (сейчас на сайте описана версия DirectX 9).
Как сделать рандомный вектор в сферическом секторе второго рода, как на пикрелейтед? Длина не критична, важно направление. И чтобы можно было задавать форму этого сектора. Пока только мысль о том, что нужно брать рандомный вектор в большем конусе, проверять, находится ли он в меньшем конусе и повторить операцию, если да. Но это, думается мне, плохой метод. Совсем охуенно было бы знание о том, как равномерно распределить n векторов в этом секторе. Я пока знаю, как равномерно распределить по окружности, но хотелось бы по сектору. Нужно для пускания лучей в офлайновом шейдере, но всё равно желательно бы, чтобы побыстрее работало.
>>125895
http://pathtracing.wordpress.com/2011/03/03/cosine-weighted-hemisphere/
x, y - направления на диске, высоту подправь под то, что надо.
>>125896
Оно вроде возвращает вектор в конусе (секторе первого рода)? Мне нужен вектор в зелёной области, то есть "без верха".
>>125897
Почему не взять некторый вектор и повернуть его на рандомные значения допустимых углов по хуz? Для твоего случя допустимыми будут углы x=30-60 y=30-60 z=0-360, например.
>>125908
Дорого. Умножать на матрицы - пиздец.
Можно проще - берем единичный на диске ( рандомного направления ) и поднимаем его на рандомную высоту от 0 до некоего высоты сектора. Все это происходит в однородной системе координат ( или тангент спейсе ), так что правильно ее отмапить в ворлд.
>>125908
Не, так и сделаю, просто думал, что есть какой-то хороший и "правильный" алгоритм. А есть идеи, как добиться равномерного распределения? Равномерно расположить по кругу тривиально, а чтобы по площади сектора? Можно юзать просто большое количество рандомных семплов, 200-300, скажем, но в моем случае лучше обойтись цифрами в 12-48. В случае рандомного поворота семплы будут собираться в сторону полюсов.
>>125913
Там выше я кинул про косайн вейтед семплинг. Он дает то, что тебе надо.
>>125914
В нем можно добиться отсутствия "крышечки" и равномерности нескольких семплов?
>>125916
Во первых - косайн даст равномерное по получсфере, равномерное - равномерное по диску, но не сфере.
"Крышечку" ты уберешь изменим границы высоты - угла Xi2.
Твою же ж мать, читай код и математику.
>>125917
Косайн просто дает большее количество семплов для направленных к камере поверхностях, экономя семплы на касательных. Мне само по себе это без надобности, общая задача такова - расстрелять 6-40 семплов в разные стороны по сектору, чем ближе к полюсу, тем менее интересно, так что можно сэкономить. Так как семплов мало, то велика вероятность, что рандомное распределение сконцентрирует много лучей с одной из сторон и запортачит пиксель на финальном изображении.
>"Крышечку" ты уберешь изменим границы высоты - угла Xi2.
Ага, благодарю. Я не кодер, у меня на разбирание уйдет пара дней, так что нужно было точно убедиться, что это то, что я искал.
>>125918
Почитай про начало про сходимость метода МонтеКарло.
sqrt(N)
>>125922
Что бы понять, что оно будет рандомным с очень низкой сходимостью, и да, при низком количестве семплов у тебя могут все оказаться с одной стороны.
Хотя можешь погуглить, неуч ебучий использовать стратифаед семплинг а так же http://www.cs.rpi.edu/~cutler/classes/advancedgraphics/S08/lectures/17_monte_carlo.pdf
>>125923
>и да, при низком количестве семплов у тебя могут все оказаться с одной стороны.
Дак я это и так знаю. Фундаментальные основы мне без надобности.
Мне, в общем, нужен способ равномерно распределить по сектору небольшое количество векторов. Он есть? Какая-нибудь формула, типа х на у делить на з, где, к примеру, задается количество семплов, углы сектора и что-нибудь, отвечающее за точное направление для этого семпла, целочисленный множитель для угла, например. Для "узких" секторов пойдёт способ рандомного поворота лучей, распределенных по кругу. Но если взять экстремальный случай с полусферой или даже всем шаром, то зоной "повышенного" интереса будут полюса.
Глянул видео про стратифаед семплинг. Предлагается поделить сектор на доли и брать рандомный вектор в нём? Такое можно сделать с тем линком про косайн семплинг, есть там соответствующий параметр для угла? Получится, что у меня гарантированно не будет 8 векторов, смотрящих в одну сторону против единственного в другую. Но тут остается заинтересованность у полюсов, надо как-то её инвертировать к экватору.
>>125924
>Няш, плис, не ругайся.
Я бы на его месте уже докидывал третье ведерко говн. В общем, спасибо вам, буду всё пробовать, если зафейлюсь, приду ныть.
>>125925
Упрощенно:
Есть грид 0-1 на 0-1.
х - угол на плоскости.
у - по высоте.
Делаешь стратифает в той зоне, где нужно - по всему х и по некой части у.
Процесс в 2 этапа - сначала семплы флоатов, потом из них конструируешь вектор по формуле косайн семплинга.
>>125926
+ https://processing.org/download/
Поможет проверить твой семплинг на гриде.
>>125928
Толку мне от твоих ебучих рисованных девок, у меня секса пол года небыло.
>>125925
Чувак, ну считери чтоли. Распредели векторы равномерно по обручу, проходящему через середину твоего сектора. Т.е. угол "от земли" у них будет одинаковый и углы между ними будут равны. Можно покрутить весь веник вместе вокруг Z, чтобы добавить рандомности. Затем каждый вектор отклони на +-random(половина_сектора / 2) от земли и +-random(расстояние_между векторами / 2) "вправо-влево". Подкорректируй коэффиценты. Но такое распределение все равно не будет равномерным. Максимально равномерное распределение дает алгоритм Poisson disc, но он весьма тяжел и для написания и для железа.
Анон, я тут решил обмазаться странным, а именно тем самым OGL времен, когда трава была зеленее, а небо синее.
Короче, дай ссылку на reference 1.1. А то я не нашел. 2.1 не пойдет, нужна именно 1.1 (1.2-1.2.1 в крайнем случае)
Просто хочется обмазаться glBegin, да еще узнать про списки... 2.1 слишком много всяких расширений уже, поэтому и не подходит.
>>126016
1.1 уже слишком стара, вот держи:
http://www.opengl.org/registry/doc/glspec15.pdf
>>126038
спека унылая. Мне нужен референс где описана каждая функция с ее аргументами и багами, при этом чтобы был удобный поиск, а не читать 200 страниц текста с картинками
>>125596
И где там линка? У кого есть пбрт скиньте чтоли на ргхост.
>>126131
Я думал у анона уже есть. Ее не так просто нагуглить.
https://www.dropbox.com/s/ct7a7byynnbm5qf/0123750792Rendering.pdf
Не тонем.
Кто-нибудь знаком с книгой OpenGL Insighs? Годнота?
http://openglinsights.com/cover.html
Я инвалид, но не могу найти формулу, как посчитать вертикальный FOV, зная горизонтальный, аспект ратио экрана и ещё много чего.
>>127199
Всё, не нужно. Нашёл на википедии, лол.
Анон, а есть где-нибудь готовая система батча для OGL?
В своем велосипедном 2D движке столкнулся с проблемой - вывод моих спрайтов тормозит. Хочу сделать батчинг (кто не знает, это собирание всей геометрии в один пакет - в идеальном мире это приводит к тому что на всю сцену можно вывести в один DIP)
Пытался сделать свой велосипед, так он еще больше тормозит чем без него (тормозит на том моменте когда я запаковываю все вершины в один буфер)
Поэтому прошу поделится готовым решением. Вот для DX такое есть (входит в DirectXTK), а для OGL? И не предлагайте списать с DX, я его не знаю и тупо не смогу разобраться (пытался батчинг вытащить из HGE, но не смог)
Второй вопрос, посоветуйте нормальную либу для вывода текста из TTF шрифтов, я пробовал ftgl - но блин, это говно такое. Мало того что оно выводит текст через glBegin/glEnd (хтя может уже исправили? У меня старая версия, но не столь старая - VBO уже было во все поля), так еще и тормозит.. Ну и ломает мне мой собственный рендер.
>>128467
Что мешает использовать один VAO для всех спрайтов и рендерить его каждый раз, но с разными юниформами в шейдере?
только не говори, что используешь тухлый OpenGL 2
>>128467
Что-то ты делаешь не так.
>Хочу сделать батчинг
>(кто не знает, это собирание всей геометрии в один пакет)
Батчинг может быть разным, например.
Геометрю надо собирать в стопки только для 3д - её много и она разная.
Для 2д - геометрия одининакова - всего 4-е вершины (их можно расшарить на все спрайты - читать из одного потока), а вот текстуры у всех разные и их нужно собирать в один атлас(вручную или програмно во время загрузки уровня) - можно читать из другого потока.
Криво пояснил: короч, надо батчить не вершины а уникальные текстуры и врубать инстансинг(не знаю как в гл это сделать) для первого буфера.
Первый буфер
4 вершины
Второй буфер
Х (матрица положения, номер кадра в атласе)
Униформ
Атлас со всеми возможными кадрами
Мимо, знаком только с ДХ
>>128487
Засовывать только одну матрицу и один инт в буфер намного дороже, чем передать юниформом.
>>128493
>одну матрицу и один инт
Не одну же, а столько, сколько спрайтов надо вывести.
>>128487
Все что вы предложили, это только половина решения
>>Что-то ты делаешь не так.
Я поэтому и прошу готовый батчинг.
>>в один атлас(вручную или програмно во время загрузки уровня) - можно читать из другого потока.
Как видишь, на скрине всего одна текстура. Я же говорю, проблема в другом
>>Для 2д - геометрия одининакова - всего 4-е вершины (их можно расшарить на все спрайты - читать из одного потока)
Это я только недавно понял. То есть использовать один вершинный буфер, меняя только мировую матрицу?
>>128603
>Я поэтому и прошу готовый батчинг.
Будь МужикоМ, доделай велик, блеать!
>Как видишь, на скрине всего одна текстура.
Одна текстура это вырожденый атлас(с одним кадром). Когда текстур станет две и больше, тогда придется заморачиваться с их упаковкой.
>То есть использовать один вершинный буфер, меняя только мировую матрицу?
Ага, но мировые матрицы нужно хранить в другом буфере(собирать его каждый кадр, для спрайтов на рендер). И да, матрица это очень жирно для 2д - если не будет поворота/масштаба то хватит всего 2-х флоатов. Тогда вершина буфера будет весить всего 5 флоатов(х, у, хКадраТекстуры, уКадраТекстуры. ИДМатериала). ИДМатериала - это ни к чему не обязывающее число, по которому в шейдоре можно будет отличить тип тайла и сделать ему особенную рисовку - не обязательно карочь.
Выше ссылка сносно поясняет.
>>128617
>>Одна текстура это вырожденый атлас
Так я тебе и говорю - проблема не в этом. Я показал что даже атлас мне сейчас не поможет (конечно же я его сделаю - потом)
>>128617
>>Ага, но мировые матрицы нужно хранить в другом буфере
Епс, не получается. Я забыл, у меня вершины можно подкрашивать (color), а значит для каждого спрайта все одно придется заводить свой буфер вершин (или как-то можно по другому?)
>>И да, матрица это очень жирно для 2д - если не будет поворота/масштаба то хватит всего 2-х флоатов
Я слаб в математике. а если поворот и масштаб, то двухмерная матрица? (видел реализацию у Борескова)
>>Выше ссылка сносно поясняет.
Мне как-то не идет понимание инстансинга. Не, код в вакууме написать могу, а чтобы в движке такое сделать - не получается пока
И в догонку внезапный вопрос, что эффективней для спрайта
- GL_TRIANGLE из 6 вершин
- GL_TRIANGLE_FAN из 4 вершин(glDrawArrays(GL_TRIANGLE_FAN, 0, 4))
Я просто раньше пользовался GL_QUADS. А теперь это deprecated кроме того gDEBugger говорил что квады тормозят и за них нужно растреливать без суда.
И теперь думаю - есть ли преимущества у GL_TRIANGLE_FAN
>>128623
>Мне как-то не идет понимание инстансинга.
>вершины можно подкрашивать (color)
Cуть инстансинга.жпг
Какой хуитой не страдать, лишь бы ничего не делать, лол.
>>128638
Вы че блядь ебанулись применять инстансинг на 4 вершины?
Ох уж эти школогеймдевы блядь, в опенгл полезли, пиздец.
Да только тормознее же будет, повесь все на VBO, аутист ты заклятый.
>>128641
Оно у меня и так на нем (то есть VBO юзается)... Сразу - сейчас у меня 4.4 юзается, без deprecated. А то скоро еще и напишут чтобы не юзал glBegin (его у меня нет если что):-\
>>128641
>>Вы че блядь ебанулись применять инстансинг на 4 вершины?
Но ведь спрайт не один, их сотни.
>>128645
Да похуй же.
Инстансинг применяется если идет большой оверюз вершин.
Это не 4, и не 10, даже не 100. Обычно больше 300-400.
>>128648
А ну да, чтобы не лишний раз на спорить - без инстансинга можно обойтись, но вот от текстурного атласа уже никуда не откосить.
укатился
сосоны что за хуйню вы тут трете? Скока у тя объектов на экране? Обычного общего вбо с координатами вершин и текстур и юниформ матриц хватит вполне даже если овердохуя говна на экране. Что именно тормозит? Покажи выхлоп профайлера
>>128664
Не получится сделать один VBO для всех текстур. Получается только по одному VBO на один спрайт (то есть 1000 спрайтов - это тысяча Draw Call -что уже хуйня на мобилках)
Почему нельзя использовать один готовый VBO меняя только юниформ матрицы (или упомянутый инстансинг). Во-первых у меня еще есть цвет для каждой вершины, значит уже по любому придется либо обновлять данные 1000 раз, либо заводить 1000 буферов.
Но это еще решаемо. А вот не решаемо, это именно атласы. Ведь спрайт, это никак не текстурка в виде
0.0 0.0
0.0 1.0
1.0 1.0
0.0 0.0
1.0 1.0
1.0 0.0
Вот если бы все спрайты имели такие вот координаты, то да, один VBO или инстанс. Но вот хуй. Каждый спрайт имеет свои текстурные координаты согласно расположения на атласе.
>>128664
>>Покажи выхлоп профайлера
Нахуй профайлер? Я тебе говорю, мне нужен батч. Я год пользовался движком в котором на одну спрайт был один дип (атласы есть для того анона который тут в каждом посте их упоминает)
Батчи есть во всех двухмерных движках (начиная с какого-нибудь xna и до всяких любительских поделок), поэтому и я хочу себе такой.
Батч по идее решает все указанные проблемы (особенно с атласами)
Скрин выше тормозит, потому что там говно. Я это только недавно осознал. Я же говорю, это моя попытка создать батч. И там реально все спрайты рисуются в один Dip. Там создается один большой VBO, а обновляю инфу через glBufferSubData
Короче, код того скрина:
if (!m_iscompile)
{
m_compile();
m_iscompile = true;
}
m_update();
glBindVertexArray(m_vao);
glDrawElements(GL_TRIANGLES, m_index.size(), GL_UNSIGNED_INT, 0);
glBindVertexArray(0);
m_compile() - это сборка буфера, один раз
m_update() - а это обновление буфера, ведь спрайты по идее должны двигаться по экрану. Именно оно и тормозит
Ну а рисую, как видиде, тем самым VAO о котором писал анон сверху.
Итог - те самые 9 FPS при 800 на 600 экране
А вот и
void Batch::m_update()
{
if (!m_isupdate)
return;
glBindBuffer(GL_ARRAY_BUFFER, m_vb);
glBufferSubData(GL_ARRAY_BUFFER, 0, m_vertex.size()*sizeof(Vertex), &m_vertex[0]);
m_isupdate = false;
}
Собственно ничего лучше я тогда не придумал.
Резюмирую:
- хватит писать про атласы. Они мне нихрена не дадут сейчас буста, что и показал скрин выше, где всего одна текстура. И для того анона который сейчас ответит "но потом же будет две текстуры" - вот когда две ткстуры будут, тогда и задумаюсь, а сейчас надо решить проблему с одной текстурой
- VAO - я не особо им умею пользоваться, но выше показано что нихуя мне не дало
- один большой VBO - вообще именно в нем я вижу решение, если в моем коде убрать обновление и сделать спрайты статичными, то внезапно будет охрененный прирост FPS. НО ЭТО И ЕСТЬ БАТЧИНГ КОТОРЫЙ Я И ИЩУ - СОЗДАНИЕ ИЗ РАЗНОЙ ГЕОМЕТРИИ ЕДИНОГО ПАКЕТА, А ТАКЖЕ СОРТИРОВКА ПО АТЛАСАМ И СТЕЙТАМ
>>128760
Без vao ты не сможешь ничего сделать в 3.3+ вериил гла
>>128775
конечно же у меня есть один vao. Все как по учебникам. В том числе и то что в учебниках забывают рассказать как им пользоваться кроме как создать при инициализации, забиндить и забыть - я это имел ввиду. То есть он есть, а пользы от него нет
Блядь, зачем столько вариантов работы с VBO?
Короче, сейчас я задаю вершины через glVertexAttribPointer(). При таком макаре всего 6 строчки кода:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, vertexSize, (const GLvoid*)0);
glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, vertexSize, (const GLvoid*)2 * sizeof(float));
glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);
Ну вот, читаю этого http://vbomesh.blogspot.ru/2011/11/vbo_1917.html
У него описан другой спосб где каждый вершинный атрибут в своем буфере. И вот теперь я задался вопросом, для моей задачи какой вариант лучше? Если подумать, то его способ может мне помочь - то есть всего один вершинный буфер с квадом. и меняем только тексткрный буфер:
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, tId);
glTexCoordPointer(2, GL_FLOAT, SizeOf(TAffineVector), nil)
Но хуй знает. Даст ли мне это что-то... Блядь, зачем так сложно
Анон что с двачем? походу его трясет и плющит, оформление (вот сейчас у меня поехала форма постинга по всему экрану) меняется при каждой перезагрузке страницы
>>128777
Это очень затратно по времени каждый раз переключать буферы.
Когда играешься с какими нибудь кубиками, конечно, не будет заметно.
Пацаны, можете подсказать в чем проблема?
>>128820
Я такие вводил.
Анон, не знаю как задать вопрос, но возникла проблема, как задать размер вершинам при выводе спрайта?
Короче, вот у нас OGL работает в координатах [-1;+1]. Так?, допустим вершины я задаю
static const GLfloat quad_data[] =
{
1.0f, -1.0f,
-1.0f, -1.0f,
-1.0f, 1.0f,
1.0f, 1.0f
}
И вот я хочу вывести спрайт размером 300х300. Как это делается?
Или ортогональная матрица мне поможет, и quad_data я должен просто задать нужный размер:
static const GLfloat quad_data[] =
{
150.0f, -150.0f,
-150.0f, -150.0f,
-150.0f, 150.0f,
150.0f, 150.0f
}
Если именно это, то можно ли дать пример?
Дело в том что у меня шейдеры, поэтому надо решить эту задачу
>>128827
Матрицей это делается.
>>128826
Ты уже тут на рисунке допустил ошибку - x с y поменяй местами
0,5 | 1
0 | 1 1 | 1
Вот так надо
текстура кладется так:
0------------------------> X (+1)
|
|
|
|
|
|
|
|
V
y (+1)
>>128836
Вообще нихуя от изменения координат не меняется.
>>128826
Должно быть норм. Значит, они как-то не так читаются или не передаются. Возьми весь код из какого-нибудь туториала.
>>128837
Значит у тебя атрибуты читаются из другой памяти (то есть оно у тебя читает координаты не из текстур, а хуй знает откуда-нибудь из другого места), проверь glVertexAttribPointer (или чем ты там атрибуты шлешь)
Анон, ну я разобрался с вопросом размеров спрайтов, но хочу у тебя спросить, в чем разница между WVP и PVW моделями перемножения матриц?
Ну то есть в DX позиция считается так:
Matrix WVP = objMatrix * CameraView * Projection;
А вот в GLM сделали PVW:
Matrix PVW = Projection * CameraView * objMatrix;
Я думал, это какая-то особенность OGL. Но сейчас у себя попробовал PVW и весь спрайт распидорасило, сделал WVP и все норм.
Так на кой хуй разработчики так выебнулись и сделали PVW?
>>128849
Гугли произведение матриц.
АБ != БА
В ГЛ и ДХ различные представления матриц: гугли row-major и column-major. Из-за этого порядок перемножени разный, Имхо в ДХ удобнее, хотя не суть.
Таки запилил опенгл в sdl2 после долгих мучений.
Теперь есть выбор либо продолжать изучать гл на студии либо с помощью кьюта.
>>128860
Дебажить на мой взгляд со студией удобно (хотя у меня где-то книжка по си завалялась, там описывалось как дебажить с помощью гцц), зато в криэйторе мингв поддерживает гораздо больше фич из c++11 чем студия.
>>128857
Я знаю что АБ != БА. Я это еще из курса математики помню. Я спрашивал про выбор WVP и PVW -не почему он дает разный результат, почему выбирают то или другое?
>>128857
>>гугли row-major и column-major
Ну возможно, но я в шейдерах (где это можно менять) ничего такого не задавал, и тем не менее у меня в OGL 4 не заработал PVW... Или надо звать Traspose у матриц? Я это к чему спрашиваю, если я сейчас попытаюсь заюзать glm - у меня будет фейл
>>128860
Говно, эта ваша кьют. Мне как-то в институте сказали делать лабу на нем - так пиздец я намучался - все глючит... Блядь, да там даже нормально несколько документов нельзя открыть (даже в notepad++ все открытые документы ставятся сверху в виде закладок, а в этом кьют говне, надо лезть в какое-то специальное окно. При этом особенно охуенно заебывает когда работаешь с ui и этого окна просто нет, а переключение превращается в ад)
>>128863
> Говно, эта ваша кьют.
Дак я не кьютишный фреймворк юзаю, а лишь как иде.
Она полегче чем студия.
Анон, как можно безболезненно получить ортогональную проекцию так, чтобы y была сверху вниз? Сейчас у меня снизу вверх (то есть 0 внизу, а например 600 сверху). Дико неудобно для 2D. Вроде бы то что я спрашиваю, зовется экранным пространством, ну так вот - как?
Анон, как можно безболезненно получить ортогональную проекцию так, чтобы y была сверху вниз? Сейчас у меня снизу вверх (то есть 0 внизу, а например 600 сверху). Дико неудобно для 2D. Вроде бы то что я спрашиваю, зовется экранным пространством, ну так вот -
>>128864
Так я и говорю IDE QT - говно. Лучше уж тогда в notepad++ пиши - там больше работающих фич
>>128863
>Я спрашивал про выбор WVP и PVW -не почему он дает разный результат, почему выбирают то или другое?
Ничего не выбирают, а делают как придется, ибо:
W mul V mul P = Transpose(P) mul Transpose(V) mul Transpose(W) или наоборот для ГЛа
mul - умножение(парсер усиленно питатся моими звездочками).
Transpose - транспонирование, оно иногда само при неправильной упаковке матриц в буферы(с униформами кажется все норм).
>>128757
>Нахуй профайлер?
на этом надо было бы закончить разговор но я сегодня у мамки добрый. Прежде чем что-либо оптимизировать, нужно знать что именно тормозит. Профайлер как минимум поможет отсеять лишние места, мало ли скока еще у тебя кода там блять. Ну ладно, допустим ты принтами таймингом или комментами нашел и 100% уверен.
>еще есть цвет для каждой вершины, значит уже по любому придется либо обновлять данные 1000 раз, либо заводить 1000 буферов.
так ты его меняешь постоянно или что?
ваще прежде чем "батчить", сядь и распиши дата флоу. Что и у каких объектов у тебя меняется часто, что не меняется. То, что не меняется, можно сунуть в один большой буфер и юзать его.
а vao не нужно (ну т.е. создал врубил и все). Прошеренный пацанчик говорит что его переключение может быть даже медленнее чем ручное переключение http://stackoverflow.com/a/8927915/1183239
конечно никогда нельзя верить тому что написано в интернетах без самоличной проверки, но в данном случае проверять долго, геморно, и это не даст всё равно такого буста как нормальная работа с буферами
>>128933
>>Прежде чем что-либо оптимизировать, нужно знать что именно тормозит.
В трех строках кода можно визуально определить что тормозит.
>>128933
>>так ты его меняешь постоянно или что?
Допустим нет. Но я тут получил еще одну закавырку:
Вот у меня позиции вершины
static GLfloat quad_data[] =
{
0, 0,
w, 0,
w, h,
0, h,
};
w, h - размеры спрайта в пикселях
И потом вот так я вывожу (шейдером):
gl_Position = ortho_matrix*world_matrix*(vec4(in_position, 0.0, 1.0));
Это тестовое. Так вот, расскажи мне как надо сделать чтобы использовать один квад для разных спрайтов.
Просто я реально не понимаю. Если написать:
static GLfloat quad_data[] =
{
0, 0,
1, 0,
1, 1,
0, 1,
};
То как потом подгонять квад под размеры спрайта? Ведь один спрайт может быть 200х200, а другой спрайт 400х100.
Погуглил, но всех делают именно так как я написал выше - в позицию вершин пишут реальный размер спрайта
То есть когда я писал рассуждения выше, я думал что создам один вершинный буфер, помещу в него квад, и буду только по экрану его гонять (тогда и инстансинг и все прочее). А сейчас сел и тут же возник вопрос, как вывести спрайт 200х100. И мой квад уже не подходит
>>128933
>принтами таймингом или комментами
Один принт будет печататься дольше, чем отрисовываться 20 кадров.
>>128952
Нет чувак, на данный вопрос не отвечали, я его даже не спрашивал
>>Загугли что за матрица и будет тебе просветление.
Ортогональная (ну или не так, но похуй, главное что ведет к ортогональной проекции), я ее вчера писал. И если ты слепой и не увидел ее в моем коде выше, то вот реализация
inline mat4 MyOrtho(const GLfloat left, const GLfloat right, const GLfloat bottom, const GLfloat top, const GLfloat zNear = -1.0f, const GLfloat zFar = 1.0f)
{
return mat4(2.0f / (right - left), 0.0f, 0.0f, -1.0f,
0.0f, -2.0f / (top - bottom), 0.0f, 1.0f,
0.0f, 0.0f, 2.0 / (zFar - zNear), 0.0f,
0.0f, 0.0f, 0.0f, 1.0f);
}
------------------------------------------
А теперь я распишу вопрос
------------------------------------------
В дискуссии выше мы пришли к выводу (ну или я пришел) что все мои спрайты можно вывести ровно одним VBO. То есть создаем эталонный буфер вершин. И юзаем его меняя только позиции на текстуре (в случае атласа) или стейт текстуры (в случае разных текстур)
------------------------------------------
В теории все было замечательно. Ну вот, начал я писать код.........
....
Блядь, мы же забыли - спрайт - это не квадрат, это прямоугольник у которого ширина не всегда равна высоте.
То есть если эталонный буфер будет:
0, 0,
1, 0,
1, 1,
0, 1,
И я решу вывести спрайт размерами 3:1 (например 300 пикселей на 100), то как мне быть, ведь эталонный буфер имеет аспект 1:1. А мне надо 3:1
То есть сейчас (с ортогональной матрицой), я на каждый спрайт использую свой буфер вершин с размерами спрайты.
Если будет 100 спрайтов, то у меня будет 100 буферов вершин, и соответсвенно 100 вызовов glBindBuffer().
НО ВЕДЬ ВЫШЕ МЫ ГОВОРИЛИ ЧТО МОЖНО ОБОЙТИСЬ ОДНИМ БУФЕРОМ ВЕРШИН, МЕНЯЯ ТОЛЬКО ТЕКСТУРНЫЕ КООРДИНАТЫ И ОБЪЕКТНУЮ МАТРИЦУ.
Вот я и спрашиваю - как?
------------------------------------------
Анон, если ты имел ввиду не ортогональную матрицу, а какую-то другую трансформацию, то прошу, распиши. В моем текущем понимании я даже не знаю что гуглить.
>>128777
Если ты еще не понял, то говно, на что ты скинул илнку - это то самое депрекейтед щит, в ответ на которое лично я посылаю нахуй.
Далее:
Создание ВАО:
glGenVertexArrays(1, &vaoID);
Все, нахуй.
Бинд ВБО к ВАО:
glBindVertexArray(vaoID);
vbo.bind();
glBindVertexArray(0);
Как нарисовать ВАО?
glBindVertexArray(vao->id());
glDrawElements( GL_TRIANGLES, vao->size(), GL_UNSIGNED_SHORT, (void*)0);
Все.
Что такое vbo.bind()?
glBindBuffer(GL_ARRAY_BUFFER, vboID);
// set up vertex attributes
glEnableVertexAttribArray(0);
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, _position));
glEnableVertexAttribArray(1);
glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)offsetof(Vertex, _normal));
//и т.д., сколько у тебя там буферов в вертексе.
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, iboID);
//плюс индексы, мы ведь не делаем квады из 6 вершин, когда там 4, правда?
Как создать ВБО?
glGenBuffers(1, &vboID);
glBindBuffer(GL_ARRAY_BUFFER, vboID);
glBufferData(GL_ARRAY_BUFFER, v_sz * sizeof(Vertex), vertexdata.data(), GL_STATIC_DRAW);
...
glGenBuffers(1, &iboID);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, iboID);
// copy data into the buffer object
glBufferData(GL_ELEMENT_ARRAY_BUFFER, i_sz * sizeof(unsigned short), indices.data(), GL_STATIC_DRAW);
Мимо ОП
>>128966
Ебать, я сейчас лицо разобью фейспалмом.
Вкури простую вещь - то, что и как рисуется ПОЛНОСТЬЮ определяется только ТОПОЛОГИЕЙ (взаимным размещением вершин) и МАТРИЦАМИ. сук
Итак, есть 3 СУКА, 3 МАТРИЦЫ - проэктивная - ее ты не трогаешь.
Есть камера - это матрица, переводящая координаты из мирового пространства в пространство камеры.
Есть объектная. Она умеет:
-поворачивать объект
-растягивать
-перемещать
Она работает из локального пространства объекта в мировое.
Твой квадратик в локальном такой:
____
| |
| |
|___|
Ты можешь его об. матрицей растянуть:
____
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|___|
Как?
http://www.mathamazement.com/Lessons/Pre-Calculus/08_Matrices-and-Determinants/coordinate-transformation-matrices.html
Пункт Lecture on Stretches in Two Dimensions
Блять, ну читайте тюториалы, мы там вверху зря с анонами писали?
Вы меня РАЗДРАЖАЕТЕ
>>128975
Был не до конца прав, в той статье сами написали, что в код снипете депрекейтед говно.
Но они не написали, что glEnable(GL_COLOR_MATERIAL)(и т.д.) - это ебаное говно мамонта, которым НЕЛЬЗЯ пользоваться НИКОГДА.
Это говно использовалось в ФФП, когда шейдеры нихуя не умели (ОГЛ 2.0).
>>128978
>>//плюс индексы, мы ведь не делаем квады из 6 вершин,
О, к тебе тогда доп вопрос. Какие проблемы меня ждут при использовании GL_TRIANGLE_FAN? Дело в том что с ним как раз всего 4 вершины без дополнительного буфера индексов.
При учете что я в будущем я хочу еще и шейдеры для спрайтов юзать
>>128977
А хотя, не можешь поделится кодом, как это сделать? Я что-то не додумкал
блядь во упорок. В пизду тебя.
бери нормальный туториал http://www.arcsynthesis.org/gltut/ и дрочи до просветления
>>128984
О, не надо, уже разобрался. Вот так ведь
mat2 nposmat = mat2( 10.0, 0.0,
0.0, 10.0);
vec2 npos = nposmat*in_position;
?
А ведь это же и для текстурных координат можно юзать?
>>128987
Как ты это будешь для текстурных юзать?
Да, умножение правильное.
>>128983
Даже не знаю, вообще это не использую. По описанию должно быть окей. Траблы будут если у тебя в ВБО больше одного кавадрата.
>>128982
Хош ссылку с шапки?
На: http://ogldev.atspace.co.uk/www/tutorial08/tutorial08.html
>>128986
А ты чего злишься? :3
>>128986
В чем упорок? В 90% уроках ничего не сказано Stretching
А я еще не настолько опытен чтобы видеть за кучей матриц трехмерный мир.
>>128986
>>бери нормальный туториал http://www.arcsynthesis.org/gltut
Я его читал и читаю. И например сейчас у меня еще и супербиблия открыта (та которая восьмой редакции на английском по OGL 4.4)
>>128986
>>и дрочи до просветления
Я делаю двухмерный движок. мне половина материалов просто не нужна.
При этом делаю не с нуля. А переписываю свою подделку которую делал год назад - но теперь цель - эффективность, чтобы на андроидах не тупило
>>128991
>>Как ты это будешь для текстурных юзать?
Ну в голове крутится, надо будет попробовать сделать, но после того как сделаю c позициями
>>128991
>>Траблы будут если у тебя в ВБО больше одного кавадрата.
Ну это не страшно, и об этом помню
>>128991
>>Хош ссылку с шапки
Мне вот это помогло
http://mathinsight.org/image/linear_transformation_2d_m2_0_0_m2
С картинками:)
А в glsl есть что-то типа print? Ну чтобы вывести что я там насчитал и проверить правильность. Профайлеры не предлагать, слишком громоздко. glGetUniform (или что-то подобное) тоже лесом, нет гарантии что оно не сломается по пути.
В HLSL такая функция есть - printf. Надеюсь и в glsl она есть
>>128991
>>Хош ссылку с шапки?
Ебаная параша.
<--------------
Анон, кинь мне чего почитать про то, где разбирают матрицы трансформации... Не тупо, а теперь зовем glOrtho, а объясняют, почему в той или иной ячейке матрицы расположены числа.
А то я сейчас хотел добавить двухмерную камеру, сделал Translate, и все куда-то убежало. Теперь пытаюсь осознать, что я сделал не так, и как надо
>>128992
>В чем упорок?
да ты чего-то дергаешься туда-сюда. Велосипедишь матрицы, для этого glm есть.
Не надо торопиться, спешка убийственная для понимания всего этого говна. Сядь и вдумчиво продрочи gltut, там вся необходимая база.
>двухмерный
это не важно, основа общая, они только проекцией отличаются. Просто скипай совсем 3d-only куски, свет
>>129005
>>Велосипедишь матрицы, для этого glm есть.
Просто я сейчас работаю в ортогональной матрице. А беда стандартных ортомтриц (в том числе и glm), в том что у них ось Y расположена снизу вверх (точка 0 расположена внизу). Дико неудобно. Поэтому пришлось написать свою, у которой второй компонет второй строки умножается на -1.
>>129007
Блин, чушь написал. На самом деле я сейчас юзаю готовую математику - из книги red book. Но наверное снова попробую glm (мне она просто не очень нравится после DirectXMath (я до этого и DX изучал)- все как-то не так)
>>129002
>зовем glOrtho
Закрываешь такой тют нахуй.
>сделал Translate
Наверное в цикле, так что в каждом кадре оно еще дальше убегало?
>>129009
Все ахуенно так. ГЛМ одна из самых пиздатых либ для 3Д.
>>128999
Кто будет тебе принтать? ГПУ? Совсем поехал?
А мелкомягкие со своими велосипедами и сокрытием всего и вся что происходит на ГПУ идут нахуй.
Юзай gDEBugger - это профайлер для огл.
>>129026
>>Кто будет тебе принтать? ГПУ? Совсем поехал?
Да хотя бы glDebugMessageCallbackARB, если в OGL нету больше ничего рапортующего об ошибках... хотя как нет, ведь еще есть glGetShaderInfoLog (само название которого говорит что юзаться оно должно на что-то еще кроме поиска ошибок)
>>129026
>>А мелкомягкие со своими велосипедами и сокрытием всего и вся что происходит на ГПУ идут нахуй.
Что именно они скрывают? У них ровно тот же самый уровень доступа что и в OGL. Или ты про говно мамонта под номером девять? Ну так в 10-11 все исправили.
>>129026
>>Юзай gDEBugger - это профайлер для огл.
Юзаю, слишком громоздко и нельзя увидеть в какой момент в шейдере появился мусор
>>129030
glGetShaderInfoLog - лог о компиляции шейдера.
Да, штука полезная, очевидная и совсем не удовлетворяет тому, что тебе надо.
glDebugMessageCallbackARB
http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-12-opengl-extensions/#ARB_debug_output
Таки да. Оно не кор профайл, не знал о таком. Спасибо.
>какой момент в шейдере появился мусор
Что за хрень? Как в шейдере мусор может появиться? Там только то, что ты туда отправил.
Нипонимат.
>>129031
Ну вот смотри, я беру и умножаю в шейдере матрицы, и делаю что-то не так (например row-матрицу умножаю на col-матрицу, забыв транспонировать) - вот это и есть мусор. Конечно gDEBugger мне покажет, что проблема в матрицах. Но он покажет итоговый. Он не покажет, на каком шагу я сделал ошибку. И хорошо матрицы, сколько их там - две, три штуки. А вот серьезные вещи в сотни строк (например реализация физических шейдеров) - это уже довольно сложная тема. И я надеялся что хотя бы тут в OGL что-то есть. Но вообще в OGL почему-то мало средств для дебагинга
>>129031
>>Таки да. Оно не кор профайл, не знал о таком
Да, очень полезная, а самое главное - что не надо руками ее звать (как это было с glError) - сама сообщит об ошибке (и текстом - хотя толку от этого текста ноль)
>>129033
>Там только то, что ты туда отправил
>забыв транспонировать
Ну, кто тебе доктор.
Вот только вопрос - там матрицы 4х4, кто у тебя следит за тем, что ты умножил ров на колон?
Чую я, наебать меня ты желаешь.
>>129033
>например реализация физических шейдеров
Что это?
Я хочу тебя попросить использовать оригинальные названия технологий
Еще, если ты из дизайнероблядков, которые пресет из 3ДМакса называют шейдером - иди нахуй. Шейдер - это программа для ГПУ и делает она только то, что ТЫ написал.
>>129035
Пресет из 3ДМакса и есть программа для ГПУ с вынесенным интерфейсом, валенок.
>>129045
>программа для ГПУ
А впрочем, я тоже валенок. Прежде всего для рендер-движка. Но суть одинакова. Реалтаймовая его версия для отрисовки во вьюпорте напрямую к шейдеру не относится и служит как вспомогательный инструмент.
>>129049
Номинально я же ответил. Я мимодизайнероблядок, не смыслящий в программировании. Возможно, он имел в виду PBR.
>>129052
ЯННП, чего ты от меня хочешь. Ещё раз - я крок и артист, читаю тред с нулевой.
>>129034
>>Вот только вопрос - там матрицы 4х4, кто у тебя следит за тем, что ты умножил ров на колон?
Вот именно - кто? Я вчера из-за этого долго ковырялся в коде, пришлось перхватывать в коде и смотреть что там в матрицах
>>129034
>>кто у тебя следит за тем, что ты умножил ров на колон
Ты не понял. Я говорил не про уможение столбца на колоннку. Я говорил про способ хранения матриц и их расчетов. То есть
column-major или row-major (случайная ссылка чтобы ты понял про что я
http://www.opengl.org/archives/resources/faq/technical/transformations.htm
пункт 9.005 )
Так вот, я пришел их DX там матрицы по другому выравнены в расчетах, поэтому перед отправкой в шейдер их надо транспонировать.
При этом многие считают как угодно, и не всегда можно определить как у них выравненно.
>>129035
physic based shader
>>129035
>>Еще, если ты из дизайнероблядков, которые пресет из 3ДМакса называют шейдером - иди нахуй.
А что такое пресет? Нет, я не из этих - я программист, и под шейдерами я имею ввиду то что пишу на GLSL/HLSL/CG
>>Шейдер - это программа для ГПУ и делает она только то, что ТЫ написал.
Но ведь я же не бог. Я могу допустить ошибку, и шейдер конечно же ее выполнит. А как мне найти эту ошибку, особенно когда в шейдере будет много расчетов?
>>129035
>>Шейдер - это программа для ГПУ и делает она только то, что ТЫ написал.
Код на С++ - это тоже программа для ЦПУ, и делает она только то, что я написал.
Как это отменяет факт того что я как и все - ошибаюсь?
В С++ для этого есть миллион средств.
А в GLSL? Кроме профайлера который показывает только итоговый результат. Вообще реально нужен print
>>129135
>physic based shader
>я имею ввиду то что пишу на GLSL/HLSL/CG
У опенгл есть физикс шейдеры?
>>129146
Это линку я же и вбросил Как и в шапке
Теперь расскажи мне, эти шейдеры делают рейтрейс или фотонмаппинг? Или пастрейсинг?
>>129146
> называю это физическими шейдерами
Пиздец, почему не "pb" или "Physically Based"? Это просто более реалистичный шейдер и всё. А то вот зеленые дибилы уже стали считать, что "физический" это связано с железом, а не с мат-моделью.
>>129149
>физический
Дело не в этом. Если бы ты читал эту книгу, понял бы, что одним шейдером там не обойтись Если только не делать вокселизацию на ГПУ и потом реально это рейтрейсить
Вот потому и спрашиваю - что же ты имеешь ввиду под "физическим" шейдером?
Уже второй день спрашиваю.
>>129149
Давай тогда не будем придираться к моим словам, я говорил про то что дохуя кода в шейдере...
Но так извиняюсь, погугли printf из HLSL - узнал что многие не знают как им пользоваться, нашел статью (в блогах Microsoft) где показано как - но там какой-то непонятный ад.
Так что придется эмипирически гадать когда и что происходит
>>129151
>>Дело не в этом. Если бы ты читал эту книгу, понял бы, что одним шейдером там не обойтись
Это как? Только одна шейдерная программа может стоять. В glsl тоже только одна main.
Если ты про кучу функций в шейдере - то это не отменяет факта что весь код шейдера состоит из сотен строк.
Книгу я не читал. Я смотрел PBS в UE4 и переносил его на CG в юнити, но потом забросил (что-то там не получилось - где-то что-то неправильно посчитал и итог получился хуйней)
>>129151
>>Вот потому и спрашиваю - что же ты имеешь ввиду под "физическим" шейдером?
И если так буквоедствовать, то вообще-то физику тоже можно на шейдере считать. Не знаю как в GLSL, но на HLSL точно и для этого не нужен вычислительный шейдер - хватит пиксельного шейдера с переопределением Stream-Output Stage в массив данных
>>129153
Для того, что делать рейтрейс нужен доступ ко всей сцене, ибо там играут роль все объекты сцены. У шейдеров нету доступа к ним.
Вопрос - как это делать?
%%Под физической имеют ввиду такое: http://en.wikipedia.org/wiki/Rendering_equation%%
>>129153
А вот то, а чем ты говорил:
http://www.livenda.com/candela_ssrr.html
Там рейтрейс в скринспейсе Это не один шейдер. Это - как минимум 2-х этапная обработка, как в ССАО, например
Если бы ты кинул эту линку - вопросов у меня было бы меньше.
Учи матчасть. Тут не тот контингент, перед которым можно просто кидаться красивыми словами. Без алгоритмов и пейперов твои утверждения - ничто.
>>129161
Ты меня с кем-то спутал
Нахуя мне вообще рейтрес сдался? Я анон который пишет двадедвижок:>>128992
И я спросил, есть ли какой-то простой дебажинг шейдеров:>>128999
PBS я привел только в качестве примера дохуя кода на шейдере. Вместо PBS можно что-нибудь другое - например генерацию терейна на вершинном шейдере (видел я и такое дело)
>>129167
PBS - это не "дохуя кода в шейдере", это свойства материала ( сохранение энергии ). И это все-же локал иллюминейшн.
Когда говорят о ПБРТ - говорят о глобал иллюме.
Генерация в вершинном - не совсем так, там геом. шейдер юзается, вот он и стреляет примитивами. Туда же и тесселяция.
Насчет твоего тайлового двигла:
Учитывая, что тебе постоянно нужно апдейтить часть ВБО, это можно так:
glDeleteBuffers(1, &vboID[0]);
glGenBuffers(1, &vboID[0]);
glBindBuffer(GL_ARRAY_BUFFER, vboID[0]);
glBufferData(GL_ARRAY_BUFFER, len*sizeof(Vector), vrt, GL_STATIC_DRAW);
Меняя индекс - апдейтишь любой буффер. Это намного дешевле пересоздания всего ВБО
Не забудь перебиндить ВАО
Еще круче - делать апдейт подмассива, но там чувствительно к выравниванию.
>>129169
>>это не "дохуя кода в шейдере", это свойства материала ( сохранение энергии )
А эти свойства в материалах магическим образом появляются? или их все таки пишут в коде и шейдере?
>>129169
>>PBS - это не "дохуя кода в шейдере"
Это именно дохуя кода
http://pastebin.com/qYj3uN9H
Это шейдер который писал я (переносил PBS из UE4 в unity). Там даже половины функционала еще нет - сейчас только освещение считается (тот есть теперь еще нужен материал
И я повторяю, я писал про PBS - как один пример где есть очень много кода в шейдере в которых можно допустить ошибку, и которую надо как-то ведь искать
>>129169
>>читывая, что тебе постоянно нужно апдейтить часть ВБО, это можно так:
Совершенно не понял как это работает. То есть ты предлагаешь создание нескольких VBO (по одному на каждый атрибут)? Не очень хочу такое. Сейчас у меня один VBO в котором хранится позиция, текстурные и цвет.
>>129182
>в которых можно допустить ошибку
Вот тут согласен.
Но есть техника программирования, где можно точно знать где ты ошибся - итеративная Или СКРАМ, лол
Пишешь 1 ф-ю, тестишь - выдает то, что надо?
Пишешь дальше.
И так ша за шагом, в уверенности в том, что старые части корректны.
Анон, короче фейл пришел. Идея с одним VBO на все спрайты мне конечно понравилась. Но вот я закончил ее делать. Запустил и пиздец
<----------
То есть в релизной сборке всего 15 FPS.
Входные данные -я рисую один (!!!) спрайт 5000 раз (всего блядь, пять тысяч - это копейки)
while ( engine.BeginFrame() )
{
for ( int i = 0; i < SIZE; i++ )
{
int x = rand() % 740;
int y = rand() % 540;
spr.Draw(x, y);
}
engine.EndFrame();
}
Экран - 800х600
Сразу. Какие оптимизации есть.
Во-первых есть кеширование стейта - посмотрите на консоль, видите там надписи типа Texture set 1? - это и есть работат кешера. То есть когда я биню текстуру, оно пишет Texture set 'номер GLuint ресурса'.
Как вы видите - все ресурсы в одном лице, и их смена не происходит.
Что меняется? меняется всего один юниформ - матрица.. Все остальное неизменно.
И все равно 15 FPS. Я же вам говорил - мне батчинг нужен. Потому что сейчас тормозит glDrawArrays(); Только он зовется в цикле (то есть зовется 5000 раз). Ничего больше
Так что анон, снова прошу, накидай чего по батчу (чтобы эти 5000 glDrawArrays превратить в один вызов)... Инстансинг - слишком сложно
>>129219
То есть сейчас нормально я могу один спрайт рисовать только тысячу раз (70 фпс). А когда будут разные спрайты, то вообще придет пиздец
>>129221
Выложи больше релевантного кода. Никто не знает что ты делаешь в функциях StartFrame, Draw, EndFrame. Может ты там лютой хуйни нагородил?
>>129219
Ха-ха, лох соснул мраз)
Ты что блядь долбоеб? Конечно у тебя тормозит, ты 5 тысяч draw callов делаешь, мудак блядь! Кто тебе такой хуйни-то насоветовал?
>>129219
>сейчас тормозит glDrawArrays(); Только он зовется в цикле (то есть зовется 5000 раз)
Ты что, поехал?
>>129219
Тебе советовали glDrawArraysInstanced с одним VBO, а не glDrawArrays.
>>129224
Вот на пикче, я закоментировал glDrawArrays(), и как видишь - ничто не тормозит. Хотя все тоже самое (в том числе и установка стейтов)
Но ладно, вот код
http://pastebin.com/zpA7kQDG
>>129225
Согласен. Когда я сюда пришел и сказал что мне нужен батч. Цель батча именно в том чтобы DC уменьшить. Ну мне стали говорить что VAO хватит... Но самом деле я им благодарен - написал неплохой VBO. Но вот поставленную задачу все еще не решил.
Но тут еще что хочу сказать что когда я начал эту дисскускию - никакого кода не было. То есть эти три дня я пишу код с нуля
>>129232
А я говорил - я не понимаю инстансинг, поэтому лучше посоветуйте почитать про объединение геометрии
Вообщем ладно, посоветуйте хорошую статью про реализацию инстансинга. Потому что те что я вижу - это огромная куча лишнего кода из-за которого код инстансинга просто не видно
>>129234
Самое простое - забиваешь все матрицы трансформации в буффер, делаешь для него вертексный аттрибут worldMatrix под layout X, делаешь ему glVertexAttribDivisor(X, 1) а в шейдере пишешь position*worldMatrix.
>>129235
Вот тут чувак объясняет нормально
http://www.youtube.com/watch?v=dMVhGJkALW0
>>129233
Следи за руками:
При условии что у тебя видеокарта умеющая в геомшейдеры
Генеришь вертексы с позицией в центре тайла + что там тебе еще надо.
Пакуешь в ВБО так, как я говорил - геометрия отдельно, все остальное отдельно.
То, что тебе надо апдейтить каждый фрейм - только ты и апдейтишь (см. выше)
В геомшейдере анврапишь вертекс в квад - ПРОФИТ.
Если нету геомшейдеров:
Генеришь всю геометрию. На каждый вертекс квада добавляешь еще один параметр (кроме цвета) - текс. айди.
Они идут линейно. у 4 вертексов составляющих квад один и тот же айди.
Создаешь текстуру РГБА флоат, туда пихаешь свою матрицу ( если она у тебя 2х2 ). Если она 4х4 - так же пихаешь, но используешь 4 пиксела.
Текстура БЕЗ компресии/клемпа/фильтеринга.
В вершинном шейдере, по пришедшему тебе, фетчишь текстуру, получаешь матрицу - ПРОФИТ.
Так в текстуру можешь запаковать что угодно ( моно и через ВБО, но тогда больше в 4 раза памяти надо под матрицы. )
Или заебень таки инстансинг.
И еще - попробуй не делать ранд ( ибо это ОЧЕНЬ дорогая операция ) - и посмотри на свой ФПС.
Это вообще ты должен сделать в первую очередь. 5к дравколов - это ничто (хотя когда как), не слушай петушков.
>>129240
>Это вообще ты должен сделать в первую очередь. 5к дравколов - это ничто (хотя когда как), не слушай петушков.
петушков вроде тебя?
>>129240
Ах да:
Render::Get().GetOrthoMatrix()*Camera2D::Get().GetViewMatrix()
Лишнее умножение.
Еще - профайльни, надо убедится что именно отрисовка кушает много.
>>129241
Да, однозначно.
Мой рендер загибался только от 16к дравколов, 650М
>>129244
Но ты даже не знаешь, какой у него ГПУ. Как можно делать такие заявления про количество дравколов?
>>129246
Если у него 5к объектов - то это далеко не мобильная игрушка планируется.
Вы хоть представляете себе 5к объектов?
В 3-м думе было меньше в одном кадре.
>>129251
Джаст фо фан убери рандом координат - выведи все в одной точке, и глянь ФПС.
>>129243
Почему лишнее? И как тогда убрать. Камера меняет позицию, вразается, зумируется. проекционная матрица тоже нужна (кроме того она меняется при ресайзе).
>>129240
>>И еще - попробуй не делать ранд ( ибо это ОЧЕНЬ дорогая операция ) - и посмотри на свой ФПС.
Конечно же я пробовал - никакого влияния
>>129262
Запусти через Гдебагер, нужно посмотреть что именно кушает.
http://www.opengl.org/sdk/tools/gDEBugger/
>>129256
>>Джаст фо фан убери рандом координат - выведи все в одной точке, и глянь ФПС.
Никакого влияния на ФПС - теже 15
Я повторяю, тормозит по явным причинам именно DrawArrays. И надо теперь думать или об инстансинге или об объединении геометрии о чем я вашу прошу уже третий день подкинуть хорошее чтиво:)
>>129268
В том-то и дело, что чтива мало по объединению.
Еще - выруби полностью апдейт юниформов. Так узнаешь, это из-за отрисовки, или из-за апдейта.
А так же скажи что у тебя за видеокарта
>>129270
Как объединить - я уже говорил.
Так, как я говорил, я рисовал в 20 милисек воксельную графику в 65к объектов Хотя там я групировал в тайлы по 32
>>129246
Скриншот же был, у него HD 6300M ноутовское говно
Некоторым основам opengl'a учился на vs2012, а она не все фичи нового стандарта поддерживает.
Решил попробовать с mingw поиграться да и иде хорошая qt creator.
Подключил либы, всё заработало.
Вот думаю на криейторе остаться или на студию вернуться?
>>129313
Поставил Compiler November 2013 CTP.
Студия, да 13ая.
Написано, что constexpr функции доступны, но кроме как члены классов и структур.
Создал отдельную функцию и нифига.
>>129320
Нашёл.
https://ideone.com/vb0BHU - main
https://ideone.com/ouk0zA - TriangleShaderVS
https://ideone.com/X2XIJ0 - TriangleShaderFS
https://ideone.com/Bt9tif - Vertex.h
https://ideone.com/BsAaIN - shaers.cpp
https://ideone.com/nhz8u8 - shaers.h
Как правильно прикрутить мультитекстурирование?
struct Vertex
{
Vector3 pos;
Vector3 color;
Vector2 uv0; // первая текстура
Vector2 uv1; // вторая
Vector2 uv2; // третья
Vector2 uv3; // 100500
};
// -- в шойдере --
//обьявить дополнительные УВ:
varying vec2 v_uv;
// эту можно оставть одну если атлас
// или обьявить по кол-ву текстурных координат
uniform sampler2D u_s_texture;
// -- в PS --
texel2 = texture2D(mask, v_uv0) * texture2D(mask, v_uv1) * ... и т.д.;
ААА написал хуиты лень стирать.
Разобрался, тебе просто надо:
gl_FragColor = vec4((texel0 * texel1).rgb, texel2.a);
или
gl_FragColor = texel0 * texel1 * texel2;
gl_FragColor.a = texel2.a;
>>129428
http://www.opengl.org/wiki/Multitexture_with_GLSL
Это я и сам нашел, что в мейне прописать никак не пойму.
>>129446
>что в мейне прописать
texel0 = texture2D(mask, v_uv0)
texel1 = texture2D(mask, v_uv1)
texel2 = texture2D(mask, v_uv2)
gl_FragColor = texel0 * texel1 * texel2;
>>129446
mix == lerp in hlsl походу
https://www.opengl.org/sdk/docs/man/html/mix.xhtml
Для цветов смысла применять его нет, ибо они и так в диапазоне 0-1, можно просто перемножить жи.
мы сидели и тупили
>>129470
Я имел в виду мейне главного файла проекта, а не шейдера, шутник.
>>129503
Биндищь 3 текстуры вместо одной.
Передаешь их юниформом
mask[0] - первая, mask[1] - вторая, и т.д.
вощемта эта называется, такой вопрос у меня:
реально на OpenGL заниматься профессионально геймдевом (мне чем приглянулся OGL, так это тем, что кроссбраузерность, ага), либо же если хочешь в этой сфере зарабатывать на жизнь и возможно создать свой наимоднейший движек на почти ванильном OGL и свою версию WoW/La2/Doom3 (нужное подчеркнуть), то нужно таращиться в сторону адового DirectX на пример?
мимовсепропил рубист вибдивилаперщик на пример с самого раннего детства интересующийся гимдевом на пример
>>129568
Заниматься можно. OpenGL это Play Station 1-2-3-4.
> рубист вибдивилаперщик
Давай проведем ассоциативный ряд:
Руби - скриптовый язык - скриптер
Итого: скриптер хочет в рендер.
У тебя нету 3-5 лет свободного времени, что бы сидеть у мамки на шее и еще одной копии кармака-баткина-капулькина под боком что бы уйти с ним в дебри OpenGL и линейной алгебры и стать рендерщиком.
> возможно создать свой наимоднейший движек
Unigine писали свой движек 10 лет. Вопросы?
Итого: С++ ты не знаешь, ООП ты не знаешь, рендер ты не знаешь, линейную алгебру ты не знаешь. Ничего кроме генератора HTML-верстки ты не писал. Не потянешь. Для тебя нужно будет начинать всё с начала, скриптер захотевший в рендер.
inb4: я знаю С++! я в универе лабы сдавал!
Вот тебе челленж, простой челленж. Напиши физический движек. Уровня начала 2000х.
https://graphics.stanford.edu/courses/cs468-03-winter/Papers/ibsrb.pdf вот и теория тебе
>>129571
этсамое
вопервих
я еще до руби и вообще веба занимался DirectX с C++ (дошел до уровня сцены с загруженной и оттекстуреной модельки с подвижной камерой и анимацией, даже книжку помню покупал бумажную), а до этого пилил наимоднейший вощемта WinAPI, параллельно юзая адовый Delphi с каким то там готовым движком.
вофторих
ООП я знаю, я же рубист :DxD
ну вообще я тебя поняЛ, конечно правда в твоих словах например есть, но блять, кризис проф. принадлежности заебал. А то, чем я интересовался в 10 лет, интересует меня и сейчас - ГД. От сюда такие выводы и такие вопросы БРО
>>129576
> ООП я знаю
Александреску почитай, сразу поймешь, что ничего из ООП ты не знаешь. А шаблоны в С++ спасают очень сильно, особенно от оверхеда виртуальных функций.
p.s. ты знал, что в геимдеве борются даже за уменьшение в размерах екзешника, в крупных компаниях на это может целый месяц-2-3 отвеститсь перед релизом.
> кризис проф. принадлежности
в геимдеве кризис был всегда, очень рискованная область
Ты зря продинамил мой челленж, скриптер.
Junior Game Logic Programmer (C++)
• Знание C++
• Знание ООП
• Знание вычислительной геометрии
• Коммуникабельность
• Знание технического английского
• Желание работать в индустрии компьютерных игр
Тестовое задание
Дан список отрезков (стен), заданных координатами двух точек на двухмерном пространстве. Нужно написать класс BulletManager, который будет включать такие функции:
• void Update(float time), где time — глобальное время апдейта в секундах. Функция просчитывает траектории пуль в заданное время и при попадании в стену, удаляет её из списка отрезков. При этом попадая в стену, пуля отражается.
• void Fire(float2 pos, float2 dir, float speed, float time, float life_time), где pos — вектор из двух флотов, стартовая позиция пули в метрах, dir — направление, speed — скорость в метрах в секунду, time — время выстрела в секундах, life_time — время до самоуничтожения пули. Функция добавляет пулю в менеджер для дальнейшей обработки при апдейтах.
Примечание — функция апдейта вызывается из главного потока, функция выстрела из произвольного.
Для выполнения задания желательно использовать Microsoft Visual Studio Express 2013 for Windows Desktop.
Решение тестового задания и резюме, пожалуйста, высылайте на [email protected]
>>129578
да, тестовое я не осилю. Эх не заниматься мне видимо тем, что интересно на протяжении последних 14 лет... А скриптинг этот ебаный заебал, веб дев еще больше (3 года уже делаю ебаные сайты)..
>>129578
> борются даже за уменьшение в размерах екзешника
А зачем?
>>129571
Ты себе и представить не можешь какой катастрофичекий эффект твой пикрилейтед производит на артиста-гуманитария. Можно моар такого? Это лучше чем винт, крокодил и шалфей вместе взятые.
мимо артист-гуманитарий
>>129580 это один из местных поехавших. Детектится по пафосу, фапанью на баткиных, экстремальную байтоеблю, велосипежение физики, и несет всякую хуйню
>>129598
Я не настолько вхож. Просто артист с нулевой. Просто интересно, в чем смысл данной оптимизации вообще, не экономия места на винте же.
>>129578
Это какая-то очень джуниорская задачка на линейную алгебру
>>129601
Грубо говоря: больше экзешник -> больше памяти требует -> выше вероятность того, что часть страниц, занятых программой, отправится в своп -> тормоза.
>>129571
>>Заниматься можно. OpenGL это Play Station 1-2-3-4.
Откуда корни этого заблуждения? На PS всегда был свой GAPI сильно отличающийся от OGL. Скачайте блядь PS SDK у пиратов и посмотрите сами если не верите. А те долбоебы которые пытались писать на OGL для PS - делали тормозное говно, ибо OGL там был прилеплен сбоку (как в winxp без драйвера)
>>129640
>больше экзешник -> больше памяти требует
Ебать дебил.
>>129650
>ну докажите обратное
Да нет, все верно - больше exe -> больше памяти для хранения инструкций требуется, но это настолько незначительно в современных системах, что аж смешно. Понятно, что если убрать например все инлайны, то бинарник будет меньше по объему, зато будет юзаться больше стека и добавится лишний call. Короче оптимизировать размер exe-шника это откуда-то из 90-х.
>>129652
>оптимизировать размер exe-шника это откуда-то из 90-х
А как же вредоносные программы и вставки?
Вы бы оперативку насиловали во все дыры, а не экономили мегабайты на экзешнике! Я ещё пару планок на помойке найду по такому случаю.
>>129578
Бороться с размером экзешника - это ебанизм.
Нет, просто ебанизм, без никаких "но" и "если".
По поводу ТЗ:
Класса "Updatable" в форе еще не придумали?
>>129657
Тоесть, ты думаешь, что напишешь игру размером в L3?
Дебил х9000.
>>129657
Суть в том, что не надо оптимизировать то, что не тормозит. Размер исполняемого файла - последнее, что тебя должно волновать.
>>129661
Он сейчас начнет затирать про кэши, забыв что почти весь геймдев - это тасование байтиков туда-сюда, вот для данных мемалайн важен. Хотя если он ВДРУГ вспомнит про деревья, он вообще загнется
>>129660
>игру размером в L3?
.product
Впрочем, местным кирилл-дебилам о таком даже мечтать - уже даже не смешно.
Так что помните свое место, безмозглые животные.
^_^
>>129663
>.product
Скачай, запусти, и посмотри сколько оперативы оно сожрет.
Еще раз, размер ехе - хуйня, важен размер в оперативе и выравнивание данных.
>>129664
> >речь про размер кода
>сколько оперативы оно сожрет.
Феерический дебил.
Тут как никогда более уместен гимн - как раз про тебя.
>>129667
Твой эфемерный КОД не в оперативе сидит? Не компилится для платформы? Не грузится в КЭШ для ИНСТРУКЦИЙ? Не юзается на массивах данных одним лупом?
Говорю ведь, ты дебил х9000, считающий что демосцена показательна.
>>129668
>КЭШ для ИНСТРУКЦИЙ?
Размер кода ~ размер ехе, опять же .product.
Хотя там уже скорее L2, если не L1 - по коду, разумеется.
Но ты умственно неполноценен, тебе не понять - про тебя вон песенка.
Так-то.
>>129671
http://upx.sourceforge.net/
А теперь ты идешь нахуй.
>>129670
Пиздец. Типичное описание гд-треда с вопросами новичка:
-- Хочу в геимдев! Как быть! Что делать! Рендер! Батлфилд! Олололо!
-- Иди учи архитектуру ЭВМ, кэши, алгоритмы, структуры данных, методы оптимизации, линейную алгебру и прочее. Ну и задание сделай.
-- ХУЛИ ТАК СЛОЖНО БЛЯТЬ!
-- Ну, как есть.
-- ТЫ ПРОСТО БОЛЕЗНЕННОЫЙ ПИДАРОДРЕЧЕР! РЯЯЯЯЯ! УМРИ! РЯЯЯЯЯ!
>>129578
Чувак, а ну ка скажи где эта вакансия, а то на оффсайте не нашел. Это же блин детское, а не джуниорское тестовое задание (надо всего-то загуглить столкновение точки и отрезка для тех у кого проблемы с геометрией), тем более на 2D
>>129673
>excellent compression ratio: typically compresses better than WinZip/zip/gzip
Учитывая что зип жмет ехе процентов на 30, примем что это говно жмет в 2 раза.
То есть .product все равно, в любом случае, по коду помещается в L2.
А разгадка проста - ты смотришь размер кода по размеру занимаемой процессом памяти, как настоящий Кирилл Дебилович.
Такие дела.
>>129674
Что ты несешь? Ты еще мне ССЕ с СИМД затри.
Абу надо бы добавить метку ОПа в /ГД -_-
>>129674
Но ты на самом деле болезненный пидадрочер. Нахуй никому уже не нужны твои кеши и ЭВМ. Наоборот, сейчас оптимизации уровня кеша - вредны, компилятор лучше справляется (знаю по личному опыту - начитался книгу Касперского про работу и оптимизацию с процессорами, стал писать его код, а потом решил написать без оптимизации - мое быстрее и эффективнее работало - замерял в профайлере)
И вообще вот ты говоришь, экономить на exe. Но блядь никто никогда не экономит на этом - посмотри размер exe 3ds max. Или на худой конец на размер exe того же UE4
>>129677
Ну че ты как баба-то. не можешь решать вопросы, сразу абу-кокококококо?
>>129681
У меня простой вопрос- что ты несешь? Тоесть, в чем смысл, зачем ты это несешь?
>>129679
>начитался книгу Касперского
Так ты же дебил, тебе не нужно читать умных книг - Крис не для таких как ты пишет.
Лучше спой песенку.
>>129679
Иди это своему преподавателю в -ПТУ- колледже рассказывай, а не здесь, окай? Или в DICE напиши. Ответ потом прикрепишь.
>>129684
Давай ты сам отправишь про свои мегаоптимизации?
Мимоработаю в DICE|Stockholm
>>129682
Иди свой тредик в /д бампай, а то что-то моча совсем не реагируют, не защищают обиженного тебя.
>>129685
http://alenacpp.blogspot.ru/2009/05/2009.html доклад от "Арсений Капулкин (AKA Zeux), Creat Studios"
>>129685
>/гыды
>Мимоработаю в DICE|Stockholm
Ясно.
>>129687
>AKA Zeux
Школьник какой-то, даже читать не буду.
>>129685
Как происходит синхронизация PPU и SPU. У них PPU всегда ждет SPU. А SPU - достаточно быстрый.
Этап занял 3 дня. Время рендеринга 25 ms.
Оптимизация данных
Синхронные DMA вызовы, понятное дело, тормозили.
Начали они с того, что переуложили данные, чтобы их можно было загрузить все за один запрос. Сделали software cache. И сделали вызовы DMA асинхронными. В процессе работы время рендеринга уменьшилось сначала до 12ms, потом до 8ms. Сколько времени заняла работа не помню, по-моему тоже 3 дня.
Оптимизация кода.
Использовали SNTuner, SPUsim.
Этот кусок доклада похож на экскурсию в восьмидесятые. Использовали loop unrolling, branch flattering, ибо ветвления дорогие и они пытались уменьшить их число. Заменили switch по числам 0..N на function pointer table, получили ускорение в полтора раза.
Еще использовали branch hinting, который Zeux назвал шагом отчаяния и который принес десятипроцентный прирост производительности. Для branch hinting есть такой gcc-specific синтаксис, который говорит, что "вот этот if скорее всего не сработает".
Меняли работу с LS. Запись/чтение только по 16 байт.
Времени это у них заняло 5 дней. Время рендеринга стало 2 ms.
>>129691
Вопрос в том, что они туда перенесли. Не растеризацию и тексмаппинг. Я вон тоже получил 10мс перенеся ССАО на СПУ.
>>129690
>/гыды
>переносил я ССАО с ППУ на СПУ
Этот школьник совсем замечтался, уносите.
>>129693
>/гыды
>рассказываю о чужих докладах по оптимизации
>>129694
>/гыды
>этот шкальник-максималист-мамкин бунтарь против системы
Да, ты пришел туда. Оставайся.
>>129692
Сразу видно местного кирилла-дибилла. Не 10мс они получили, а x12.5 скорости.
>>129698
ССАО с 12 до 1.8 мс. Да, получил 10.2 мс. Или 6.6(6)%
Не могу понять, чего ты добиваешься
>>129700
>Не могу понять
кирилл.мп3
Очевидно что твое кукареканье и фантазии говна не стоят, школьничек с говнофорума для детей-дебилов.
Лучше я почитаю доклады не-дебилов - больше пользы будет.
эти школьники сломались, эвакуируемся из треда
>>129712
>этот проецирующий мелкобуквенный школодебил
Ясно.
заебали писькомерица, от вашего срача четь менее, чем нихуя профита для анонов.
Вопрос назрел еще нубский один: имеет ли смысл лезть в ГД вообще если за плечами нихуя фундамента математического (ни ВО нихуя)? Т.е. к примеру в вебдеве я справляюсь норм, хотя и то бывает изредка подпирает незнание самых основ первых курсов ВУЗА..
>>129752
Можешь за ближайший полгода-год задрочить С++, алгоритмы/структуры данных и линейную алгебру. Пойти в мобилный геимдев. А там уже сориентируешься.
Или иди тестером в геимдев. А там спросишь как пробиться в скриптеры, мол с программированием ты знакомы. Вот это работает, 100%.
Котаны, а что если запилить список книжек как в программаче http://i.imgur.com/YXDLSlJ.jpg
Или, например, сделать в гугло доксе, а конкретно в таблицах, список книг, статей, библиотек, репозиториев и прочего полезного?
>>129783
Хуита эти списки. Перечень не годноты, а что вообще асилили составители.
Аноны, есть желание перевести OpenGL Programming Guide на notabenoid?
>>129889
Лучше Super Bible 6 часть.
Она получше для начала.
>>129890
Го, я создал http://notabenoid.com/book/54048
>>129896
Кстати, зачем 6-ю переводить? Есть же 8-я у тебя, лучше ее.
>>129936
OpenGL Programming Guide. 8th и OpenGL SuperBible (6th Edition) разные книги.
SuperBible, сказали, лучше.
>>129941
Она для начала лучше.
Я имею ввиду для изучения опенгла.
>>129941
лучше. Оно по крайней мере правильно написано. А то я попытался разобраться в коде примеров OpenGL Programming Guide - блядь, да там сплошные ошибки
Допустим открываю код ch03_drawcommands
И там такая вот строчка
glUniformMatrix4fv(render_model_matrix_loc, 4, GL_FALSE, model_matrix);
Я хуй знаю что они хотели здесь сделать. Кто не увидел подвоха - ошибка в '4'. Идем читаем спеку - там четко и ясно сказано что это для передачи массива матриц. Идем смотрим код:
GLint render_model_matrix_loc;
Никакого блядь массива здесь нет.
Правильно:
glUniformMatrix4fv(render_model_matrix_loc, 1, GL_FALSE, model_matrix);
И это не очепатка - там сплошь везде стоят эти самые четверки. А я потом ебался пытаясь понять почему у меня не работает. Хорошо что я не нуб, и нашел эту проблему.
И это не единственное что там проблемно, но остальное полегче (но опять же - не каждый нуб сможет починить остальные проблемы)
>>129949
> GLint render_model_matrix_loc;
> Никакого блядь массива здесь нет.
Эта переменная не массив матриц, а своего рода указатель где в шейдере находится переменная.
К слову, gl 4.5 вышел.
https://www.opengl.org/registry/doc/glspec45.core.pdf
Также планируется редизайн api
http://www.anandtech.com/show/8363/khronos-announces-next-generation-opengl-initiative
>>129950
нифига тебя не понял.
>>где в шейдере находится переменная.
Вот именно - ОДНА переменная в шейдере.
А 4 означает что в шейдере должен быть массив из 4 матриц (а там одна)
>>129954
ИТС ХАББЕНИНГ
Редизайн АПИ, если он таки состоится, вынесет ОГЛ на вершину графономанства - слишком много ОГЛ пока скрывает за собой думаете почему ньфани так сильно не могут начать его учить? Многие вещи не понятны, пока их не поймешь.нувыпонели.
>>129955
glUniformMatrix4fv(location_MVP, 1, false, glm::value_ptr(MVP);
Как-то так.
>>129958
Просто запомни, что ГПУ - тупой. Реально тупой. Но мощный. И именно поэтому нужно задавать все параметры, что бы ГПУ не страдал хуйней, а ИПАШИЛ
>>129960
Это поэтому некоторые игры с хуевым графоном так тормозят, а в рекомендуемом указаны последние йоба-железяки?
>>129966
Тут есть два нюанса - понятие хуевого графона не однозначно - ты можешь рисовать ссаные кубики, но из-за всяких дополнительных эффектов оно будет тормозить просто потому, что эти эффекты дорогие. С другой стороны - да, ты можешь рисовать простую графику, но у тебя тормозит потому, что ты не умеешь пилить двигло/сортировать дравколы/группировать данные.
Но и крайний случай, прямой ответ на твой вопрос - да, оно может тормозить потмоу, что ты в душе не ебешь как нужно передавать данные ГПУ при больших нагрузках.
Полезно смотреть профайлир и сравнивать объем данных, которые ты шлешь ГПУ за кадр и сколько раз ты шлешь. Каждая посылка - это точка синхронизации, что плохо для ГПУ. В идеале ГПУ работает полностью ассинхроно от главного потока (тут и появляется понятие "поток рисования")
Как вам новое расширение ARB_direct_state_access?
>>130014
Да такое, лично я трансформфидбеком не пользуюсь пока.
>>130061
Лол, блять, ты первые 2 строчки только прочитал?
>>130014
А что в нем нового? ну было раньше расширением (EXT) теперь стандарт.
http://steps3d.narod.ru/tutorials/dsa-tutorial.html
http://www.geeks3d.com/20101228/opengl-direct-state-access-dsa/
Красиво, да... Как в DirectX сделали.
>>130070
>http://steps3d.narod.ru/tutorials/dsa-tutorial.html
Описывает устаревшее говно.
>>130072
И? Я и писал - что нихрена оно не новое. Только теперь оно вошло в Core(не прошло и ста лет)
Кроме того статья показывает идею - зачем оно надо
А еще они Reference Pages обновили, теперь там есть табличка, которая показывает с какой версии поддерживается та или иная функция.
>>129896
Совсем чуть-чуть начал перевод 3ей главы.
Сегодня продолжу ещё.
>>130255
Ещё немного перевёл.
Закавыка на Interface Blocks.
Как это правильно перевести?
>>130314
С терминами, вообще кошмар, пока можно дословно переводить, а потом на стадии редактирования исправить, когда будет видна общая картина.
Всё.
Заебалось переводить.
Пойду спать.
>>129896
Кто владеет переводом, пусть в главу Data добавит текст англ.
Я его буду переводить.
Вообщем анон, снова я (я тот кто пишет 2D движок и выше задавал вопросы)... Короче, я разобрался с инстансингом (оказалось что вообще элементарщина и больше требует логику чем OGL), делал еще Font.
Ну вот, а теперь я хочу спросить следующее. Вот у меня вершина описана позицией, текстурной координатой и цветом. Сейчас создается один VBO. Но позиция теоретически может меняться каждый кадр, текстурные координаты всего один раз при создании, цвет чуть реже но тоже до кадра.
И мне пришла мысль, создать не один VBO, а три. А теперь ответь, в чем между этими подходами разница? они реально дают буст? А какая ложка дегтя? Чем придется платить?
И вопрос про VAO - че в нем хранится? Я так понял, что все VBO, IBO и vertex atrib. то есть можно создать VAO, создать VBO, IBO, описать и активировать вершинные атрибуты, и затем только биндить VAO без бинда VBO, IBO и vertex atrib?
Почему это не работает с шейдером? Я сейчас попробовал, при бинде VAO приходится потом еще биндить шейдерную программу (если этого не сделать, будет пустой экран)
>>130398
Ладно, вечерком добавлю, а ты осилишь эту главу целиком?
>>130414
3 буффера даже лучше, учитывая что позиция будет меняться часто. GL_DYNAMIC_DRAW в поле usage может дать прирост в производительности при таком раскладе.
В VAO хранится state вертексных аттрибутов. Без VAO ничего не работает (если ты его не использовал, значит драйвер использовал свой VAO по умолчанию). VAO используется для быстрого переключения этого самого state'a.
А есть инфа когда ждать этот OpenGL NG? В необозримом будущем?
>>130464
http://opennet.ru/opennews/art.shtml?num=40370
>Спецификацию обещают выпустить до конца 2014 года.
Я так понял, что это в перспективе будет замена самому опенглу?
>>130465
Пиздец. Вот откуда школьники берут эти понятия: ЗАМЕНА! УБИЙЦА! Пиздец какой-то. Нет, это не замена и не убийца. Это просто новая версия и всё. Темболее опенгл живет только на мобилках. На ПК и боксе - директикс, на плейстейшнах свой монстр.
>>130466
> Темболее опенгл живет только на мобилках.
Ловите долбаёба.
На макинтоше и линухса опенгл.
>>130465
Так это, мне что, учить текущую версию не нужно, ждать новую, ведь там какой-то йоба редизайн обещают?
>>130503
У гейба есть стим, л4д и недоделанный хл2. Они скоро станут казуалами. Хотя стали уже. Игры не изменились со времен первого портала.
Аноны, почему во 2 случае все слетает к хуям?
>>130518
Потому что в параметрах написана хуйня.
https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml
>>130505
Игры не меняются потому, что последние 5 лет их делают под консоли.
Гл4 И Х11 предлагают одинаковый функционал.
>>130582
А то я маны не читал перед тем, как спрашивать.
stride
Specifies the byte offset between consecutive generic vertex attributes.
Что не так?
>>130583
Да, понял твой вопрос.
Допиши страйд в первый пример (3*sizeof(float)).
Я пока не пони.
>>130584
Эм. Первый пример выводится правильно. И зачем там страйд=3, если это равносильно 0?
>>130585
Проверить. Да, там нулевой страйд из-за указанного размера структуры. Но я подозреваю выравнивание в памяти, оно может как-то нагибать.
Второе что проверить надо - передай все 4 параметра в шейдер (не дели на w - присвой 1.).
>>130587
3*sizeof(float) работает правильно.
Далее передаю все через 1 атрибут - результат, как на 2 скрине.
Алсо, сам 4 параметр, как его не меняй, не влияет на координаты вершины.
>>130589
Он не меняет только в твое случае. если передать все 4 флоата (и их принять) - то придет в вершинный вертекс, который потом будет поделенный на 4-ю компоненту.
В душе не ебу почему они разные. Такое впечатление, что в последний вертекс попадает 0.8 0 0б что капельку абсурд
>>130588
>Далее передаю все через 1 атрибут - результат, как на 2 скрине.
Можно капельку детальней с этого места?
>>130591
glVertexAttribPointer(prog.attrib("position"), 4, GL_FLOAT, GL_FALSE, 0, 0);
#version 330 core
in vec4 position;
out vec2 second_param;
void main() {
second_param = vec2(position.z, 0);
gl_Position = vec4(position.x, position.y, position.z, 1);
}
>>130592
Надеюсь я правильно понял про передать через 1 параметр.
>>130592
>gl_Position
Не валидная хуйня. передай через
out vec4 out_position;
>>130593
А так да, все АБСОЛЮТНО правильно. Так что или говно в отправке параметров, или в gl_Position.
>>130594
Погуглил, вроде не нашел упоминаний про неработоспособность.
>out
Хм, а как указывать, что это именно позиция, а не что-либо другое?
>>130596
Забей, я хуйню спизданул. Перепутал с gl_FragColor
Короче говоря, я в душе не ебу, почему вывод разный. Абсолютно.
>>130597
Я тоже хуйни понаделал, проблема была в glBufferData. Столько ебался, а проблема как всегда в опечатке. Звиняйте.Но тебе все равно добра.
>>130598
Ради интереса, скинь код буферизации до/после.
Зато в пиксельном юзается out vec4 color :3
>>130599
>out vec4 color
Ну пиксельному не надо дальше передавать и там все однозначно.
>буферизация
Да я забыл добавить новый параметр просто, лол. В итоге передавалось что-то вроде:
glBufferData(GL_ARRAY_BUFFER, sizeof(float)*3*triangle_count*3, data, GL_STATIC_DRAW);
Теперь подумываю разделить все параметры по разным буферам для удобства.
>>130600
Пока пришлось сделать просто data_size 2 аргументом.
Анон, а есть ли какие-нибудь нормальные книги по OpenGL, но с упором на 2d. А то я начач читать супербайбл, так там матан какой-то пошел, трансформации, с какой системы в какую, нахуя они вообще есть? Или с таким подходом я далеко не уйду?
>>130713
OpenGL - это АПИ для рисования. Чтобы решить, что гарисовать, нужен матан, без него в 3d никак.
>>130713
Попробуй либу SFML.
Она, вроде как, рисует при помощи OpenGL.
>>130729
SDL вроде тоже в гл может.
А вообще в чем проблема? Просто рисуй квады и все, z используй для сортировки.
>>130600
>Ну пиксельному не надо дальше передавать и там все однозначно
Нет, если ты делаешь диферд, у тебя все пишется в текстуры - так что аут надо добавлять. Да и по хорошему и без него тоже надо.
Анон, а есть ли какой-нибудь учебник по OpenGL более практически ориентированный чем SuperBible? А то там какие-то буферы, униформы, а как мой треугольник раскрасить я так и не понял. Только для последних версий.
>>131229
Выглядит довольно наглядно, спасибо. Завтра буду читать.
>>131232
Для понимания основ дико рекомендую http://tomdalling.com/blog/. Сам сначала многое не понимал, с этим сразу разобрался.
GLEW уже прихуячил поддержку 4.5, а ебучие AMD все никак не обновят свой драйвер.
Презенташки с SIGGRAPH выложили
https://www.khronos.org/developers/library/2014-siggraph-bof
Как адекватней перевести tessellation factor?
Коэффициент тесселяции
Всё-таки хуёво русский язык придумали, не зная, что переводные термины будут превращаться в малозапоминающийся, нерельефный техножаргон двухкратной длины. Я бы все термины давал в двойном написании "Коэффициент тесселяции (tessellation factor)".
мимопетух
Проблема только в том, что все запоминают tesselation factor и не ебут себе мозг с отставшим наглухо рюзге программированием. А перевод терминов нахуй не нужен, чтобы не возникали долбоёбы с "физически верными шейдерами".
С математикой та же хуйня. Чего стоят Domain и Range.
Дайте гайд, как загрузить и отрисовать .nfg модель.
>Вот тебе челленж, простой челленж. Напиши физический движек. Уровня начала 2000х.
>https://graphics.stanford.edu/courses/cs468-03-winter/Papers/ibsrb.pdf вот и теория тебе
Реально такое нубу за неделю сделать?
Нет.
Я буду стараться.
Не будешь ты стараться. Ты даже не начнешь.
Ты прав. Пойду повешусь.
Бамп нахуй блять.
Тут просто тред еретиков появился, где говорят что ОГЛ - это сложно, нинужно и вообще надо учить линейку для него.
А также теорию семплирования и уравнения освещения.
Скомпилировал hello world с glfw, посмотрел зависимости и увидел там зависимости от библиотек nvidia, это как так? Значит ли это, что эта моя сборка будет запускаться только на моей пекарне? Или я просто что-то не понимаю и всё в порядке вещей?
нет, это выбор нужных графических либ для линковки. Т.к. тебя стоят нвидевские дрова для видюхи, вместо месаговна выбрались нвидиа либы, скорее всего в виде динамически загруженных зависимостей libgl. Откуда им еще взяться если ты не линковался руками с ними.
Зачем ты вообще туда смотришь? Чтобы удостовериться что твой шедевр работает на других окружениях, его надо почаще проверять на других окружениях, и никак иначе.
Зачем ты вообще туда смотришь? Чтобы удостовериться что твой шедевр работает на других окружениях, его надо почаще проверять на других окружениях, и никак иначе.
Объясните кто-нибудь тупому, как работает glVertexAttribLPointer().
Вот допустим:
glEnableVertexAttribArray(0); // тут ясно
glBindBuffer(GL_ARRAY_BUFFER, VBO); // забиндил буфер с вершинами
glVertexAttribPointer(0,3,GL_FLOAT,GL_FALSE,sizeof(glm::vec3),0); // ну и как эта функция понимает, что я хочу именно координаты вершин в буфер отправить?
Вот допустим:
glEnableVertexAttribArray(0); // тут ясно
glBindBuffer(GL_ARRAY_BUFFER, VBO); // забиндил буфер с вершинами
glVertexAttribPointer(0,3,GL_FLOAT,GL_FALSE,sizeof(glm::vec3),0); // ну и как эта функция понимает, что я хочу именно координаты вершин в буфер отправить?
Таким, что ты биндишь перед этим буфер, а это функция действует на активный буфер.
кермак
State machine жи
Первые 4 главы на русском.
http://rghost.ru/57944705
http://rghost.ru/57944705
Бамп нахуй!
Не слушай ебланов и
Функция сама нихуя не понимает.
Просто у тебя в шейдере написано
in vec3 vertex;
in vec2 texCoord;
in vec3 normal;
что раскрывается в
layout(location = 0) in vec3 vertex;
layout(location = 1) in vec2 texCoord;
layout(location = 2) in vec3 normal;
так вот, аргумент glEnableVertexAttribArray и первый аргумент glVertexAttribPointer это и есть location.
Лучше вообще делай вот так:
GLint verticies = glGetAttribLocation(program, "vertex");
glEnableVertexAttribArray(verticies);
...
Вообще-то лучше не так делать.
Лучше для шейдера хранить в отдельном файле все атрибуты и юниформы.
Ну что вы, Кармаки?
Game Engine Architecture, Second Edition уже на торрентах!
http://kickass.to/game-engine-architecture-second-edition-2014-t9574312.html
Game Engine Architecture, Second Edition уже на торрентах!
http://kickass.to/game-engine-architecture-second-edition-2014-t9574312.html
Ну хуй знает, реально. Там нету ни SIMD-mathlib, ни примеров кода, ни оптимизации шейдеров. Больше похоже на введение для джуниоров-скриптеров.
Может быть тебе в книжке про архитектуру движка еще устройство шейдерных процессоров разжевать, причем с указаним назначения каждого транзистора?
Годное чтиво
Uniform перевести как юниформ?
Да лучше так и оставить юниформы.
http://www.slideshare.net/cellperformance/data-oriented-design-and-c
Алсо, годная и большая презентация.
Uniform (рус. Юниформ)
>перевести
ты кириллицей написал, а не "перевел". лучше пиши как есть без таких "переводов".
Пролистал до половины - одна вода.
Покажи свою тогда.
Посоны, вопрос года.
Есть 2д игра, вид сбоку, шутер, можно сказать. Х
очу вот сделать прицеливание, типа нажал ПКМ -> появилась такая хрень типа пикрилейтед1, в которой показывается то, что вдали.
Но как уместить туда все, но и сфокусироваться на чем-то? Может шейдером, или отрендерить карту в текстуру, а потом текстуру нарисовать на сетке измененными текстурными координатами (точки красной зоны останутся неизмененные, о остальные будут сплюснуты, получится такая типа сплюснутость по краям, как в прицеле в dead floor (пкрлд2))?
Есть 2д игра, вид сбоку, шутер, можно сказать. Х
очу вот сделать прицеливание, типа нажал ПКМ -> появилась такая хрень типа пикрилейтед1, в которой показывается то, что вдали.
Но как уместить туда все, но и сфокусироваться на чем-то? Может шейдером, или отрендерить карту в текстуру, а потом текстуру нарисовать на сетке измененными текстурными координатами (точки красной зоны останутся неизмененные, о остальные будут сплюснуты, получится такая типа сплюснутость по краям, как в прицеле в dead floor (пкрлд2))?
Ну это то понятно. Просто есть проблема: между игроком и конечкой целью есть слепая зона, которую тоже должно быть видно (а также между конечной челью и максимальной дистаницей прицеливания).
Меняй FOV.
Конечно.
Ни грамма воды, всё чётко и по существу.
Насколько знаю, FOV имеет отношение к триде?
Ну не очень годная. Её можно назвать "глубокий менеджмент кода". Новичку она нахуй не нужна. Её нужно читать техдирам и енжн-лидам. Её даже пишет енжн-директор.
Если у тебя перспективная проекция - фов есть, с ним и играйся.
Ортогональной посрать, но ты всегда можешь уменьшить физический размер окна при неизменном актуальном на экране.
Это и есть зум, а не транслейтнуть камеру.
А вообще - учись гуглить.
https://www.google.se/search?q=camera+zoom+in+2D+game
У меня 2Д, и AFAIK, FOV неприменим.
Отклеилось.
Ну если нельзя камеру приблизить к цели без потери части обзора, то можно преблизить призрак цели в начало предполагаемого обзора.
Ты не понимаешь, правда?
НЕТУ НИКАКОГО ПЕРЕМЕЩЕНИЯ
http://www.opengl.org/wiki/Viewing_and_Transformations
Зум- это зум. Скейл, мать его.
Когда в сантиметре перед камерой объект, он будет перекрывать скрин независимо от зума.
Посоны, посоны. У меня 2Д, блядь. Вид, блядь, сбоку! Какой нахуй FOV, какой, нахуй, объект в сантиметре перед камерой? В чё, ебанутые? Чё вы там делаете?
>В чё, ебанутые?
Нет ты. Ебись конем, короче.
Охуитедьные у него истории, такую хуиту простейшую не зделоть, пиздец дожили.
А ты чего рвешься? Можноже крутить камерой, а можно обьектами перед ней.
>с артефактами искажения по краям
Охуенно зарешал, только если не пояснишь, что за это за хуйня, то я предполагаю, что это будет выглядеть так.
Макакак все не уймётся, пикчи отклеивает.
https://www.google.se/search?q=opengl+lense
А вообще - лучше не занимайтесь графикой, вам это слишком тяжело.
Вот это по делу. Thanks a lot.
Аноны, перевожу свой 2д рендер с SDL на чистый OpenGL. Сделал так:
Есть меш-квадрат со сторонами 1.0. Вовремя рендера тайла делается translate, scale и накладывается текстура.
Но я не совсем понимаю, как надо делать скейл, чтобы тайл выводился, например, ровно 16х16 пикселей.
Есть меш-квадрат со сторонами 1.0. Вовремя рендера тайла делается translate, scale и накладывается текстура.
Но я не совсем понимаю, как надо делать скейл, чтобы тайл выводился, например, ровно 16х16 пикселей.
Нах?
Рисуй полноэкранный квад, на него натягивай нужное количество тайлов пиксельным шейдером.
Ещё мип-мапы используй, чтобы при большом отдалении не было артефактов.
А так быстрее будет? А то у меня кроме тайлов еще и юниты и гуи.
тогда-с
glOrtho2D(0, width, height, 0, -1, 1);
дальше размеры квадов задаются в пикселях.
через шейдер только тайлы действенно прогонять
>glOrtho2D
депрекейтед?
> говорит про deprecated
> не может перевести координаты в экранные
ясно.
В OpenGL 4 при использовании `glPolygonMode(GL_FRONT_AND_BACK, GL_LINE)` контуры рисуются чёрным цветом. Можно ли как-нибудь изменить этот цвет на другой? Запись в `out vec4` во фрагментном шейдере при том режиме даёт нулевой эффект
>Запись в `out vec4` во фрагментном шейдере при том режиме даёт нулевой эффект
Ой, похоже я нап...ел. Выхлоп фрагментного шейдера меняет цвет линий как и положено. Проблема оказалась с проброской интерфейс-блока с цветом (после смены режима glDrawArrays с GL_TRIANGLES на GL_PATCHES в конвеер включились околотесселяционные шейдеры и видимо из-за этого связь вертексного и фрагментного шейдера через тот интерфейс-блок нарушилась). А чёрный походу берётся, если никакого цвета снаружи не пришло
Bump.
Поясните за blending. Включаю GL_BLEND, в шейдере делаю
[code]final_color = texture(tex, out_coords)out_color;[/code]
Передаю 1.0, 1.0, 1.0, 1.0 в цвет, а меш все равно полупрозрачный.
[code]final_color = texture(tex, out_coords)out_color;[/code]
Передаю 1.0, 1.0, 1.0, 1.0 в цвет, а меш все равно полупрозрачный.
Проебал разметку, ну да ладно.
>Blending is the stage of OpenGL rendering pipeline that takes the fragment color outputs from the Fragment Shader and combines them with the colors in the color buffers that these outputs map to.
Понял, что хуйни натворил.
Люблю я этот тред. Как только спросят хуйню - сами потом и пишут, где обосрались.
П оделу - Передашь 1 альфу - будет просто непрозрачный материал, блендинг не пройдет, считай.
На самом деле пройдет, просто фон умножится на 0.
Анончик, помоги с выводом текста, двое суток в гугле копаюсь. Нельзя использовать ничего объектно ориентированного.
bmfont
Пробовал через стандартные средства OpenGL, но при выводе текста когда пытаюсь установить текст, потом все текстуры выходят забитыми этим цветом.
Cпасибо, уже решил проблему с glutStrokeCharacter().
>glut
>2014
Еще небось рисуешь через glBegin/glEnd?
Объекты и ОГЛ, или как Кирил пишет графику
http://jonmacey.blogspot.de/2011/10/text-rendering-using-opengl-32.html
И да, когда придет время переката, кто будет его делать - соберите все линки с треда в шапку.
Тут уже все что можно было вкинуто, ИМО.
Тут уже все что можно было вкинуто, ИМО.
Кстати, глат для контекста - не худший вариант.
Но зачем, если можно все ручками написать :3
https://www.opengl.org/wiki/Creating_an_OpenGL_Context_(WGL)
> Но зачем, если можно все ручками написать
Ты опять выходишь на связь?
У тебя с этим проблемы?
Хуесосина, ты-то куда лезишь?
A tu, Kiril, 4ego tut sresh'?
Здравствуйте, glисты. Открываю окно через glfw по этому тутору http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window/
Все собирается, но между запуском приложения и отображением окна проходит достаточно много времени (20-30 секунд). Нагуглил лишь, что тормозить может ChoosePixelFormat(). Как это исправить?
Версия glfw: 3.0.4
Видеокарта: GeForce 9800GT
Все собирается, но между запуском приложения и отображением окна проходит достаточно много времени (20-30 секунд). Нагуглил лишь, что тормозить может ChoosePixelFormat(). Как это исправить?
Версия glfw: 3.0.4
Видеокарта: GeForce 9800GT
Профайлер.
Код покажи.
Как нагуглю как его пользовать, так сразу.
http://rghost.ru/58827580
Проект кодоблоков.
Ещё одна странность: когда рисую треугольники по второму уроку, они получаются чёрными, хотя вроде должны быть белыми.
Собрал проект на Radeon HD 4600. Запускается сразу и треугольники белые, похоже невидиа-проблемы. До своего компьютера, чтобы запрофайлить, доберусь только через день.
- кун
- кун
Мне кажется, что ты используешь GL функции ещё до инициализации либы glew.
У меня была такая проблема, когда я для класса работы с шейдером запихал в конструктор gl функции.
http://pastebin.com/M7tWMhCr
У меня вот такая логика работы и всё нормально.
Привет.
Проблема такова: я рисую несколько треугольников(из трех линий, просто) в 3d пространстве, потом рисую такие же с заливкой. Но они почему-то все прозрачные(и линии, и полигоны). На пике сама графика, код инициализации и код метода redisplayFunc(). Помогите пожалуйста сделать это всё не прозрачным.
Проблема такова: я рисую несколько треугольников(из трех линий, просто) в 3d пространстве, потом рисую такие же с заливкой. Но они почему-то все прозрачные(и линии, и полигоны). На пике сама графика, код инициализации и код метода redisplayFunc(). Помогите пожалуйста сделать это всё не прозрачным.
Там где аргументы alpa 0.5 и 1.0, я пробовал ставить разные, но всё-равно не помогало.
Ты долбоеб или прикидываешься?
Полигонмод проверь свой.
Не говоря еще о том, что это сраный депрекейтед.
>deprecated shit уже нинужно
Согласен с этим говнометом
Делай по этим гайдам http://www.opengl-tutorial.org/ (есть перевод на русский, но там с макросами немного проебались)
Потом загружаешь вершины своих треугольников в VAO и рисуешь.
Надо инкорпорировать и ВЕБГЛ в наш уютный чятик:
http://zephyrosanemos.com/
http://zephyrosanemos.com/
очень сомнительная технология. Он сырой, с убогим тормозным жсом, с уебищностью браузерной платформы, ебанутой безопасностью (прямой доступ к гпу с сайтов, это же пиздец)
>прямой доступ к гпу с сайтов, это же пиздец
Все игры, которые ты запускаешь имеют прямой доступ к ГПУ.
Более того, браузер имеет доступ к ГПУ.
Более того, "прямой доступ" - это всеголишь исполнение ОГЛ кода, причем в сендбоксе.
>причем в сендбоксе
Нит. Уронить винду некорректным вызовом драйвера можно. Проверял - падает. Причем корректность целиком на совести програ webGL'а на том конце сайтика.
>Все игры, которые ты запускаешь
при чем тут все игры? Все игры поступают из доверенных источников (стим, гог, коробки и т.д., пиратов очевидно не рассматриваем), а не с левых сайтов автоматически при заходе. Самое смешное, что уже щас можно стабильно крашнуть браузер (просто так валился на обычной демке) как минимум, просто разместив код на сайте и пустив на него трафик, т.е. оно даже не спрашивает "хотите ли вы поработать для васяна майнером или дос-ботнетом" а просто берет и ебошит. Это фантастика, я не понимаю как кодерки могут быть настолько тупыми. Уверен, им отрубят руки, и всю эту лавочку обвешают пачкой подтверждений и ограничений, оно будет еще больше тормозить, и запустить будет не особо проще чем скачать инсталлятор
Суп, gl-исты, есть одно GLFW-окно кодрилейтед http://pastebin.com/Htx4TRjf
Суть в том, что при переключении полноэкранного/оконного режима пропадает вся рисуемая графика. В чем может быть дело?
Суть в том, что при переключении полноэкранного/оконного режима пропадает вся рисуемая графика. В чем может быть дело?
> gl-исты
> глисты
А по-моему звучит.
Я так понял что у меня вместе с удаляемым окном убивается и контекст со всеми вытекающими. Как сохранить контекст?
Вроде нужно создать невидимое окно, которое будет содержать контекст и в которое буду загружать ресурсы, чтобы затем расшарить его на видимое окно, но не понимаю как работает это расшаривание.
Когда меняется размер окна, нужно же glViewport переустанавливать, не?
Я и не меняю размер окна, а создаю заново. GLFW может либо создать окно в полноэкранном режиме если указать монитор, или в оконном если не указать. Там при создании окна есть ещё параметр GLFWwindow share, но я не понимаю как его использовать.
Пацаны. А как мне отрисовывать 2 объекта сразу? Ну может я не правильно выражаюсь конечно, но вот суть:
Есть 2 функции [CODE]void ball()[/CODE] и [CODE]void circle()[/CODE]. Они описаны.
Как мне сделать так, чтобы при нажатии на F5 мне выводилось одновременно 2 этих изображения в 1 окне?
Так не робитЕстественно:
[CODE]// инициализация
glubDinsplayFunc(ball);
glubDinsplayFunc(ball);
/функция инициализации/
[/CODE]
Помогите пожалуйста.
Разметочка проебалась:(
Лучше скрин код выложи.
И используй лучше gl 3.3+
> Лучше скрин код выложи.
>glutDinsplayFunc(planet);
>glutDinsplayFunc(orbit);
что по-твоему делает glutDinsplayFunc ?
Окно вызывает. Я же сказал, что не правильно. Я спросил, как сделать правильно.
И? Что ты рисуешь?
Ничего. Там белое окно. А рисоваться должна сфера, которая будет двигаться по определенному закону и просто кривая, которая как бы описывает её орбиту. По отдельности работает. А так белый экран.
Двигается сфера и помощью таймера и изменения координат и вертится с помощью glrotatef. Но вся беда в том, что крутиться не только сфера, но и линия. А нужно чтобы только сфера.
Думаешь не гуглил? Там либо устаревшие процедуры glfwOpen/CloseWindow или предложением лососнуть тунца. Так что либо перезагружать все связанные с контекстом ресурсы, либо ждать новой версии glfw, вроде обещают добавить glfwSetMonitor.
А теперь перепиши это нормально.
И покажи код рисования, а то чую я что первый вызов рисует, а второй очищает и опять что-то рисует.
Пацаны, а как нарисовать например 100 сфер.
я пробовал в цикле вызывать gluSphere(...) с разными координатами. Но оно так не работает как видимо. Помогите, пожалуйста.
я пробовал в цикле вызывать gluSphere(...) с разными координатами. Но оно так не работает как видимо. Помогите, пожалуйста.
Забудь ты эту старую парашу.
Юзай opengl 3.3+
И как мне её юзать?
В ОП посте ссылки для кого, мудила?
Анон, вопрос по FreeType. Правильно ли я понимаю, что для вывода надо кэшировать символы, а потом просто во время вывода меша/в шейдере подставлять нужную текстурку?
Да, как один из способов.
Альтернативно - строить меш полсность в строку, в w координату вертекса пихать айди текстуры, разворачивать это дела на вертекс шейдере и w = 1 в нем не забудь.
Геометрия - БЕЗ индексов, тоесть с дублированием вершин.
Тогда всю строку в один дравкол нарисуешь.
Спасибо.
Не совсем только понял, можно ли это на 1 квад натянуть?
No.
Аноны, какой курсач взять на OpenGL? Хотелось бы, наконец, погрузиться с головой в 3D. Опыт разработки двухмерных игрушек есть, писались они, естественно, на новом OpenGL.
Напиши простую 3д игру.
То есть меш все равно придется динамически загружать? Жаль.
>динамически загружать
Что загружать? Не будь динамопетушком, заведи статически буфер на 9000 квадов и рисуй сколько реально надо, подставляя нужные значения текстурных координат.
>подставляя нужные значения текстурных координат
Как?
В моем проекте возникла проблема - низкое fps (10-30 на моем ноутбуке - он конечно совсем не игровой, но всеже).
Нужно оптимизировать.
Проект (клон df) - это двухмерная игра с видом сверху. Вся графика спрайтовая.
Что смог, я уже оптимизировал. Теперь дошло до уровня OpenGL.
Тут нужна помощь - куда лучше копать, чтобы выжать еще больше fps.
Код здесь
https://code.google.com/p/clone-df/
Вот как я рисую карту
http://pastebin.com/LhjPP7qh
Вот весь код квада (с шейдером)
http://pastebin.com/LuTMtBd3
Смысл тут в следующем. есть видимая область. Берем из массива карты тайлы попавшие в видимую область. Рисуем.
Далее, если это специальный блок пустоты, берем тайл в той же позиции из карты ниже, и так до самого дна.
Высоко в воздухе fps падает до 10. Что логично (получается что рисую n число тайлов до 10 раз)
Буфер глубины включен(!!!). Рисую от ближнего, к дальнему (то есть фрагментный шейдер не является узким местом)
спрайт - это квад. При этом в движке есть только один квад который и используется всеми спрайтами (зачем куча квадов ,если одного хватит?)
Тормозным местом всеже является DIP.
если честно, я не знаю куда лучше идти. Батчи - но я тут давно уже спрашивал - никто не помог. Инстансинг - я что-то там пытался, но пока не осилил.
Может кто поможет?
Нужно оптимизировать.
Проект (клон df) - это двухмерная игра с видом сверху. Вся графика спрайтовая.
Что смог, я уже оптимизировал. Теперь дошло до уровня OpenGL.
Тут нужна помощь - куда лучше копать, чтобы выжать еще больше fps.
Код здесь
https://code.google.com/p/clone-df/
Вот как я рисую карту
http://pastebin.com/LhjPP7qh
Вот весь код квада (с шейдером)
http://pastebin.com/LuTMtBd3
Смысл тут в следующем. есть видимая область. Берем из массива карты тайлы попавшие в видимую область. Рисуем.
Далее, если это специальный блок пустоты, берем тайл в той же позиции из карты ниже, и так до самого дна.
Высоко в воздухе fps падает до 10. Что логично (получается что рисую n число тайлов до 10 раз)
Буфер глубины включен(!!!). Рисую от ближнего, к дальнему (то есть фрагментный шейдер не является узким местом)
спрайт - это квад. При этом в движке есть только один квад который и используется всеми спрайтами (зачем куча квадов ,если одного хватит?)
Тормозным местом всеже является DIP.
если честно, я не знаю куда лучше идти. Батчи - но я тут давно уже спрашивал - никто не помог. Инстансинг - я что-то там пытался, но пока не осилил.
Может кто поможет?
Во первых, нехуй рисовать по одному кваду - сгенерируй VBO и VAO размером, например, в 16х16 блоков. Или сразу размером со всю карту, если она не очень большая. Чтобы сократить число драукалов.
Во вторых, если карта сильно больше экрана, реализуй тот же квадтрии для быстрого отсечения ненужных областей.
В третьих, особо не вникал, но ты там для каждого квада текстуру переключаешь? Лучше загони все тайлы в одну текстуру и изменяй текстурные координаты в VBO для выбора необходимого.
>Во вторых, если карта сильно больше экрана, реализуй тот же квадтрии для быстрого отсечения ненужных областей.
Зачем? Там и так есть отсечение со сложностью O(1) (доступ к элементу массива по индексу). Я повторю - рисуется только те тайлы, которые реально находятся на экране.
Беда именно в том что рисуется не двухмерный набор тайлов, а трехмерный (то есть еще и в глубину, и если будет яма глубиной в 20 тайлов, то все 20 тайлов в глубину на месте одного оно и нарисует (нет, не карту 20 раз, а только тайл, но таких тайлов много, и в самом худшем варианте вполне и 20 карт нарисовать может)
>>В третьих, особо не вникал, но ты там для каждого квада текстуру переключаешь?
Атлас сделаю потом. На руках порезаные тайлы, а генерацию атласа из кода я не умею (в фотошопе некогда)
Алсо, построй двухмерный массив размером с карту и скидай туда максимальные индексы непустых тайлов - этакую карту высот. И при выводе сразу бери нужный тайл по высоте, а не пробегай весь столбец.
А обновлять этот массив нужно будет только при изменении карты.
А обновлять этот массив нужно будет только при изменении карты.
Это не верное решение. Визуально не сможешь понять где ямы. Надо рисовать каемку. Сейчас, мой пустой блок заменяет то что в будуем и будет каемкой.
Но да, сейчас чуток переделал. теперь рисуется верхний прозрачный тайл, и самый нижний (сейчас наверное уберу и перебор карт - карта высот у меня и так есть).
fps выросло всего на 7.
Наверное придется атлас пилить, хотя и это не даст больше 10 fps (проверил на тех местах где только одна текстура (у меня оно кешируется)
Вообщем переделал - теперь не перебираю вниз все карты до плотного блока, а сразу рисую блок текущей карты и плотный блок с самой нижней карты.
fps выросло на 5.
Этот специалист прав. Надо буфер размером с вид камеры в тайлах и тайлсет паковать в атлас.
>Я повторю - рисуется только те тайлы, которые реально находятся на экране.
Рисуются по одному за раз - вместо складывания их в буфер с параметрами и отправкой на отрисовку один раз.
>Беда именно в том что рисуется не двухмерный набор тайлов, а трехмерный
Похер в вершины квада можно сохранить до 16 ID используемых тайлов и в шейдере их уже последовательно замешивать.
Анон, помоги разобраться. Читаю статью (http://www.songho.ca/opengl/gl_projectionmatrix.html), там говорится, что для применения матрицы проецирования подготавливает специальное пространство камеры - которая смотрит на точку не положительной осью координат а отрицательной. Помимо этого само пространство (камеры) имеет RH ориентацию. После применения матрицы проецирования это пространство камеры переходит в LH пространство (единичный куб).
У меня вопрос - правильно ли я представил на рисунках ИЗНАЧАЛЬНУЮ систему координат (я ее назвал "глобальная" и она изображена как LH-ориентированная) и систему координат камеры относительно нее? (будем считать камера находится в точке (0, 0, a), где а - положительно число, а точка, на которую смотрит камера - начало координат (0, 0, 0) )
У меня вопрос - правильно ли я представил на рисунках ИЗНАЧАЛЬНУЮ систему координат (я ее назвал "глобальная" и она изображена как LH-ориентированная) и систему координат камеры относительно нее? (будем считать камера находится в точке (0, 0, a), где а - положительно число, а точка, на которую смотрит камера - начало координат (0, 0, 0) )
Ананасы. Меня вот интересует такой вопрос.
Скажем, перед началом рендеринга я устанавливаю цвет буфера для очищения экрана, включаю тест глубины и тд.
Но вот глящу какие-то уроки/ролики по гл и вижу, что это всё делаю уже в самом цикле рендера, а не перед ним.
Как я понял, если так поступать, то в конце кадра надо отключать, наример, тест глубины?
Скажем, перед началом рендеринга я устанавливаю цвет буфера для очищения экрана, включаю тест глубины и тд.
Но вот глящу какие-то уроки/ролики по гл и вижу, что это всё делаю уже в самом цикле рендера, а не перед ним.
Как я понял, если так поступать, то в конце кадра надо отключать, наример, тест глубины?
Не знаю, я тоже перед началом всегда включаю, а во время вывода 2д дизейблю. В теории включение во время цикла пригодится, если ты забудешь после вывода 2д обратно включить.
Мимо-не шарю.
Ты гарантируешь что профайльнул код и у тебя рекурсивная часть рисования не генерирует овердохуя мисдиректов?
Как проверить - захачь реальное рисование ноупом, и профайльни.
Если будет мало фпс - ты явно сделал велосипед.
Своп осей происходит исключительно после проэцирования.
Переключить ничего не надо, если во время фрейма ты не нуждаешься в переключении стейта.
Как ты что-то выставил при инициализации, так оно и будет до конца.
Но если ты поменял что-то, будь добр верни его взад как только оно больше не нужно.
инт Рисуй (0)
если(таки_рисовать)
делать нихура;
вернуть рандом;
иначе
вернуть sub. Рисуй + 1;
Как-то так, чтобы компаилер не с оптимизировал. Если таки с оптимизирует - ранд вместо 1.
Ошибка постинга: В сообщений присутствует слово из спам листа.
Сказали бы какое, уебаны
эти уроки написаны для обучения и идеалом не являются. Вендоры заявляют что нужно кешировать стейты и стараться их не менять (в идеале вообще ничего не трогать).
То есть включение/отключение буфера глубины (стейт - state) каждый кадр - это тормоза на пустом месте
Но ведь для каких-то определённых моментов всё равно придётся отключать?
Ну, это очевидно блять. Посыл в том, чтобы делать это как можно реже.
Пример:
Ты рисуешь свою поебень, но рисуешь ты деферед - а значит у тебя будет переключение стейтов для альфаблендинга ( вкл альфу, откл з-врайт ). Когда ты их (прозрачные объекты) нарисуешь - щелкнишь назад.
Но если ты будешь щелкать стейтами для каждого второго объекта в сцене - тебе пиздец, игра твоя - говно, а сам ты - ебаный кирил
Напоминаю, перекат не за горами, кто будет делать - соберите линки по треду в шапку, это займет время. Благодарю.
Очередной, нежный, любимый.
Хотите сдать лабу? Понять как использовать GLPushMatrix?
Идите нахуй. Лабы есть в интрнетах, и в гугл мы посылаем в первую очередь, а deprecated shit уже нинужно.
Туториалы:
http://www.swiftless.com/
www.lighthouse3d.com/tutorials/glsl-core-tutorial
http://www.opengl-tutorial.org/
http://ogldev.atspace.co.uk/index.html
Книга:
http://www.amazon.com/gp/reader/0321902947
Залезть в дебри графона:
http://www.pbrt.org/
Математика:
http://www.essentialmath.com/tutorial.htm
http://chortle.ccsu.edu/vectorlessons/vectorindex.html
Архитектура:
Хоть и старое http://worldtracker.org/media/library/Physics/Game%20Development%20Guides/Morgan%20Kaufmann%20Publishers/3D%20Game%20Engine%20Architecture.pdf
Вся серия Game Programming:
http://rutracker.org/forum/viewtopic.php?t=625086