Попробовал исходники он NeHe. Немного разочарован. Ибо
#include <gl\gl.h>
#include <gl\glu.h>
#include <gl\glaux.h>
Всё это идёт в старых компиляторах по умолчанию, но вот в VS 2012 этого нет. Погуглив немного нашёл что библиотеки эти глючны, и могут вылететь или покрашить что-нбудь, и что NeHe об этом писали несколько раз, но тому пофиг. В общем ищу уроков годных, таких же как у NeHe только с рабочим кодом.
>>61007
нехе блядь протух
учить опенгл надо не по ссаным урокам в инторнете а по официальной документации
>>61008
Официальная документация - 16 страниц неюзабельного говна с редкими коментариями.
я забался уже постить это - http://www.arcsynthesis.org/gltut/
осильте гугл, дауны, иначе никогда ничего не получится
>>61020
Спасибо няша :3
>>61003
http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039/
Учу по этой книжке, довольно таки полноценное руководство по ОткрытьГЛ.
>>61024
Я в общем то тоже. Вот только замучался подключать разные библиотеки. Особенно напрягали библиотеки из самой книги, которые непонять куда сувать.
А что вы скажете о глут? Ну кроме того, что не свежое говно.
>>61035
Глючен, может внезапно упасть. Старые мануалы обучают работать именно с ним. При нагрузке выдаёт странные ошибки. Настоятельно не рекомендуется использовать в реальных проектах. исключается из использования отовсюду. Не состоит в комплекте компиляторов с 2010 года (VS).
Достоинства.
Слепленный из говна и палок всё-же давал возможность быстро и без гемороя с сотнями матриц получять простенькие фигуры и даже играть с ними.
>>61036
А какую обёртку лучше использовать сейчас? Или вообще чистый опенгл?
>>61037
Сам пока методом проб и ошибок иду.
Пока буду пробовать freeglut.h от кроносов, он вроде новее и гораздо менее забагован. Тем более что у опенов всё загнулось и всем лень.
>>61007
http://www.mbsoftworks.sk/index.php?page=tutorials&series=1
Держи, бро. Правда в туторах используют винапи, так что если у тебя винда, то ок.
>>61037
sdl, freeglut
winapi можно, но некококроссферно же
И это обёртки, обёртки это Tao, OpenTK, lwjgl, jogl, libgdx, PyOpenGL - для язных языков короче.
>>61045
Ананасы, как DDS флипнуть в загрузчике из пятого урока? http://www.opengl-tutorial.org/beginners-tutorials/tutorial-5-a-textured-cube/
Пробовал для DXT1 кодом ниже, но получается пикрилейтед.
unsigned int size = ( ( width + 3 ) / 4 ) * ( height + 3) / 4 ) * blockSize );
if ( blockSize == 8 )
{
for ( unsigned int block = 0; block < size / blockSize; block++ )
{
unsigned char temp;
temp = buffer[block*blockSize+4];
buffer[block*blockSize+4]=buffer[block*blockSize+7];
buffer[block*blockSize+7]=temp;
temp = buffer[block*blockSize+5];
buffer[block*blockSize+5+offset]=buffer[block*blockSize+6];
buffer[block*blockSize+6+offset]=temp;
}
}>>63158
Inversing the UVs
DXT compression comes from the DirectX world, where the V texture coordinate is inversed compared to OpenGL. So if you use compressed textures, you’ll have to use ( coord.v, 1.0-coord.v) to fetch the correct texel. You can do this whenever you want : in your export script, in your loader, in your shader…
>>63159
>Exercices
>The DDS loader is implemented in the source code, but not the texture coordinate modification. Change the code at the appropriate place to display the cube correctly.
Что-то я не вижу в загрузчике привязки к координатам, только саму текстуру. Так что только блоки флипать. Да и с uv как-то некрасиво выходит, лучше текстуру преобразовать.
>>63158
Так, снова выхожу на связь.
Так и должно быть, что рендеринг фрейма с моделькой на пикрилейтед занимает 16мс? Причем, когда подвигаю камеру вплотную к полигону, то уже 25-30мс? Текстура разрешением 512х512 сжатая в DXT1. Индексацию вершин не применяю.
>>66268
Пикчу забыл.
>>66268
16 милисек подозрительно похоже не 60 фпс (vsync может работает?)
без кода карочи нихуя не угадаем мы тут почему у тебя тормоза
>>66270
Это я даун - цикл не в том месте закрыл.
>>66268
Эм, а еще Microsoft Windows по умолчанию (то есть без шаманств) не умеет таймеры меньше 16 мс. А на хабре недавно писали что тот хак который позволяет 1 мс, это лучший способ убить заряд батареи
>>66325
У мну если что ноутбук, и заряд батареи важен, поэтому нехуй всякие хаки делать и добиваться наноскоростей - вот что я хотел сказать
>>66325
Можешь ссылкой на ту статью поделиться? Шиндосовским таймером не пользуюсь, просто беру системное время до и после рендеринга кадра.
>>66328
Он перепутал, скорее всего, и речь была о том, что разброс при Sleep(1) или GetTickCount() может составлять до 15 миллисекунд. Но под виндой есть timeGetTime(), который, вроде, даёт миллисекунду точности и QueryPerformanceCounter(), который считает в наносекундах.
>>66335
Я юзаю glfwGetTime()
>The resolution of the timer is system dependent, but is usually on the order of a few micro- or nanoseconds. It uses the highest-resolution monotonic time source on each supported platform.
>>66328
http://habrahabr.ru/company/intel/blog/186998/
Обратите внимание, что это не вася пупкин писал, а кто-то из intel.
Смысл не в том что вам нужен таймер в 1 мс, смысл в том что программисты забывают вернуть все как было
>>66362
проверил, и таки да, не на пустом месте статья, вот репорт от винды по энергопотреблению
Разрешение аппаратного таймера:Разрешение аппаратного таймера
Установленное по умолчанию разрешение аппаратного таймера, равное 15,6 мс(15 625 000 нс), следует использовать во всех случаях простоя системы. При увеличении разрешения таймера возможно снижение эффективности технологий управления электропитанием процессора. Разрешение таймера может увеличиваться при воспроизведении файлов мультимедиа или анимации.Текущее разрешение таймера (х100 нс) 10000
Максимальный период таймера (х100 нс) 156001
То есть здесь тоже самое говорится
>>66364
Такая же ситуация, причем разрешение таймера меняют aimp2.exe, svchost.exe и firefox.exe
Зачем вообще использовать продукты майкрософта?
Мне интересно есть ли здесь люди, которые могут что-то посоветовать почитать про коллизии? От самых основ в 2D до 3ДЭ? самое главное что-бы подробно
>>66487
Коллизии в 2д, на основе теории разделяющих осей с примерами и теорией. Все в английском, но это не должно быть проблемой :3
Объясните что курить и какой движок взять, только чтоб мультиплатформенный.
>>66487
http://www.amazon.com/Geometric-Computer-Graphics-Morgan-Kaufmann/dp/1558605940
От самых основ, начиная с линейки, очень подробно.
>>66621
>However, a word of caution: this book is full of errors. Every couple of pages I am noting in the margin: did they mean A instead of B? Having encountered so many errors, I am reading every formula with scepticism.
не надо такое дерьмо рекомендовать
>>66635
>However, a word of caution: this book is full of errors.
Проиграл.
Есть какое-нибудь нормальное чтиво по GLSL, а то ничего не понимаю.
>>66679
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html Либо все прочитай, либо, если ты знаешь про конвееры, читай про шейдоры.
>>66683
Хм, интересно. Вот только странно:
1. В основном цикле сначала выполняются шейдеры
glUseProgram(programID);2. Потом для шейдеров указываются ссылки
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, 0, (void*)0 );
glEnableVertexAttribArray(1);
glBindBuffer(GL_ARRAY_BUFFER, uvbuffer);
glVertexAttribPointer( 1, 2, GL_FLOAT, GL_FALSE, 0, (void*)0 );3. А потом отрисовывается сцена
glDrawArrays(GL_TRIANGLES, 0, vertices.size());Пробовал менять 1 и 2 пункты местами, все так же работает. Изначальный порядок и должен быть таким?
>>66765
Когда ты загружаешь и компилишь шейдер, то теде дается его идентификатор programID. Командой glUseProgram ты указываешь какой шейдер сейчас будешь использовать.
>Потом для шейдеров указываются ссылки
Это ты не шейдеру указываешь ссылки, а говоришь OpenGL что сейчас работаешь вот с этими массивами.
После того как ты начал использовать конкретный шейдер ты можешь получать определенные поля из него и устанавливать в них значения используя команду http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml .
>>66774
Спасибо, видимо не так понял абзац. Для нескольких источников света придется передавать все их свойства в один шейдер?
Что-то какой-то глянцевый бетон получился
>>61003
Для 2D-игор стронгли рекомендую SFML. Скоростной и мощный высокоуровневый API с подробной и полной документацией и многочисленным коммунити. Есть куча дополнительных модульных приблуд, вроде звука. Игра видеорелейтед написана с использованием SFML.
>>66883
>Для нескольких источников света придется передавать все их свойства в один шейдер
Да, можешь в шейдер передавать позицию и цвет каждого источника, а внутри считать цвет.
Охуенная игра.
Только что дошло, что башни можно соединять как призму в ред алерте. Пикрелейтед - 205% range, 950% damage.
>>61003
Котаны, такой вопрос. Можно ли рендерить opengl не в окошко, а в массив пикселей?
То есть, у меня есть моя gui-либа, один пиксель - одно 32-битное целое, изображения представлены массивами таких пикселей. Хочу встроить opengl-поле, как элемент гуи, то есть, мне нужно рендерить в массив пикселей. При этом, классический контекст с окошком мне создавать не нужно. Возможно ли это, какие технологии использовать, FBO, PBO?
>>69299
При создании контекста можно указать PFD_DRAW_TO_BITMAP.
у меня постоянно выдает 60 fps как не крути, что я делаю не так?
`void draw()
{
..........
glutSwapBuffers();
fps++;
}
void timerfps(int = 0)
{
cout << fps;
fps=0;
glutTimerFunc(1000, timerfps, 0);
}
int main(int argc, char ** argv)
{
..........
timerfps();
glutIdleFunc(draw);
glutMainLoop();
return 0;
}`
>>69404
vsync выключи и будет тебе счастье для поджарки яиц.
>>69408
отрубил glutSwapBuffers();
врубил glFlush();
fps овер 6к
но отрисовка пропала хз куда
>>69433
Нахуй тебе такой фпс? Большинство мониторов не могут отобразить выше 60, отдельные могут в 75/100/120/200. Человеческий глаз не воспринимает больше 200 (ему и 30 кадров норм, а от 200 некоторых даже тошнит).
Кроме того некоторые интеловские видеокарточки могут СВИСТЕТЬ и отбрасывать копыта из-за такой хуйни. А нормальные будут тупо греться. Ты выжимаешь весь сок там, где это не надо делать.
>>69552
Оно так и было, начала свистеть, посмотрел на фпс и вернул в зад свои 60.
В играх тоже выдавало потолок в 60, а в Geeks3D GpuTest выдавало именно столько сколько заявлено в документации.
И другой вопрос где найти ман по прокручиванию в ГЛ русских шрифтов?
>>69570
Есть всякие FreetypeGL. Они поддерживают юникод и utf-8.
https://code.google.com/p/freetype-gl/
Если не лень ебаться, можешь написать свой генератор на основе freetype'а, это не шибко сложно.
>>69777
че то у меня там хуй ногу сломал
не смог выдернуть рабочий пример
Такой вопрос: чем и как активировать режим WINDOWS_NO_RESIZE? Я хочу фиксированное окно
В глуте нету, в фриглуте тоже не нашел, что делать?
>>71004
если на glfw пилишь, то там перед созданием окна есть glfwwindowhint
>>71518
есть такое:
>glfwOpenWindowHint(GLFW_WINDOW_NO_RESIZE,GL_TRUE);
Да и пилить особо нечего, но там нету управления кнопками.
Во первых, имеет ли смысл сейчас использовать фриглут.
А во вторых, как он совмещается с потоками, я так понял, что defaults, init, display, reshape, keyboard будут вызываться только внутри основного потока? Можно ли сделать, что бы кейбоард вызывался внутри второго потока, а оставшиеся внутри первого?
нашел годноту http://pixelshaders.com/
>>74791
>кейбоард вызывался внутри второго потока
но зачем, омич штоле
Можете пояснить про освещение при помощи шейдеров? Можно обойтись без него старым освещением?
>>77925
Он видимо пльзуется OpenGL<3. Там фиксированный графический конвеер есть.
Ебанутая пробелма. Объясните, где обосрался:
Есть два массива. С вершинами и координатами для текстур. Для сраного квадрата. И почему-то текстура идеально точно дублируется по 4 раза. Сначала думал, что я в коде где-то обосрался, нагугливал варианты - вроде бы нет, всё сходится.
-1,1,0,1,1,0,-1,-1,0,1,1,0,1,-1,0,-1,-1,0 - высоты. Координаты для текстуры - тоже самое, но без Z.
>>78353
UV координаты текстуры (0;0) для левого нижнего угла и (1;1) для верхнего правого угла. У тебя же встречаются -1, отчего текстура тайлится 2 раза.
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-5-a-textured-cube/#About_UV_coordinates
>>78359
Я плохо понял, что ты имел ввиду, т.к. у квадрат из треугольников, а не из квада, но я уже сам разобрался. Но всё равно спасибо.
>>78373
На пике тоже из треугольников.
BUMP
Хотел спросить, но не успел из-за дуддоса.
Как создавать и рендерить отдельные меши? Делать общий массив вершин, индексов и прочего или делать отдельные массивы для каждого меша, а потом отдельно биндить и указывать аттрибуты и рендерить по очереди?
>>83457
Я постоянно сышу на международных сайтах вроде поликаунта про то, что рендеринг одного большошо меша куда легче для видюхи, чем нескольких маленьких, кроме того, в UDK добавлена фича для "склеивания" мешей. UDK, конечно, построен на dirextx, но, возможно, если уж оба движка сваливают эту работу на видюшку, даже на OpenGL комбинирование мешей насколько это возможно будет ускорять рендеринг.
>>83459
Спасибо за быстрый ответ. А как тогда делать чисти-чисти, если меш удаляется? Хранить индексы начала и конца в массивах для каждого меша?
>>83461
А как насчет просто запекания отдельных больших групп мешей в один, потом работа с ним как с совершенно уникальным мешем?
>>83463
Можно, но есть некоторые минусы. Например, меш придется рендерить целиком или просчитывать расстояние до каждого вертекса, если нужна оптимизация со светом.
>>83467
> просчитывать расстояние до каждого вертекса, если нужна оптимизация со светом.
Без фанатизма. В один меш весь уровень не стоит запекать.
А вообще, давай конкретную ситуацию, там можно смотреть, где легче рендерить как.
>>83471
Конкретных ситуаций нет. Поиграюсь с множествами мешей и светом, посмотрю тайминги.
>>83461
Очевидно же, грузи меши как обычно, потом создавай один большой, перед рендерингом смотри, изменилось ли что-то (меш добавился, удалился етц), если да - пересоздавай большой.
Геймдевы, у меня платиновый и тупой вопрос, но гугл молчит, а мне не спится. Почему вообще в геймдеве используется что-то кроме С? Ведь в реалтаймовых 3д-играх всё упирается в производительность, а до меня только и доходят обрывки того, какой С реактивный, а жава тормозит и рядом бенчмарки какого-нибудь цикла. Речь только об играх, где важна МОЩЬ.
Максимально возможная производительность, какой можно добиться, на самом деле различается мало? На С очень сложно разрабатывать? Неудобно? С для петухов? Почему титаны индустрии выбирают менее производительные языки, разрабатывая производительные движки? Или они нагруженные места на сишке всё же пишут? Гугл тупой и не различает c и c++.
>>83561
>Почему вообще в геймдеве используется что-то кроме С? Ведь в реалтаймовых 3д-играх всё упирается в производительность, а до меня только и доходят обрывки того, какой С реактивный, а жава тормозит и рядом бенчмарки какого-нибудь цикла. Речь только об играх, где важна МОЩЬ.
А с чего ты взял, что производительность упирается в язык? Жава расплачивается за кроссплатформенность и другие плюшки производительностью.
>Максимально возможная производительность, какой можно добиться, на самом деле различается мало? На С очень сложно разрабатывать? Неудобно? С для петухов?
Все зависит от железа и кривизны рук. Вон, сырно-анон пилил демку на паскалике и ничего, держится. Если ты бог на питоне, и у тебя получается хороший результат, то зачем делать на чем-то другом?
>Почему титаны индустрии выбирают менее производительные языки, разрабатывая производительные движки? Или они нагруженные места на сишке всё же пишут?
Приведи пример этих титанов. Некоторые места могут на сишке писаться, некоторые на ассемблере пишутся, генераторы рандомных чисел, например, или какие-нибудь защиты от взломов.
>>83561
>Почему вообще в геймдеве используется что-то кроме С?
Потому что скрипты пишут всякие дизайнеры, для них делают скриптовые языки попроще. На плюсах, потому что ООП головного мозга. На всяких жабках, потому что другого ниасилили.
>>83565
>А с чего ты взял, что производительность упирается в язык?
Ну в некоторых-то упирается. Хотя скорее, наверное, в компилятор.
>демку на паскалике
Но на С его демка работала бы чуть быстрее, да и паскаль не настолько высокоуровневый, чтобы на нём было проще делать, чем на С. Короче, не понимаю я его.
>генераторы рандомных чисел
Не, с ними как раз плюсы неплохо справляются, код получается как ручной почти.
>>83565
>А с чего ты взял, что производительность упирается в язык?
С интернетов же.
> Если ты бог на питоне, и у тебя получается хороший результат, то зачем делать на чем-то другом?
То есть будучи питонобогом можно делать настолько же технологические и производительные двиганы какие возможно есть на С?
>Приведи пример этих титанов.
http://en.wikipedia.org/wiki/List_of_game_engines вот тут отсортировать по языку - на си какая-то сущая хуйня, да и то половина старше меня, основная масса на других языках.
>>83574
>Потому что скрипты пишут всякие дизайнеры, для них делают скриптовые языки попроще. На плюсах, потому что ООП головного мозга. На всяких жабках, потому что другого ниасилили.
Так о дизайнерах речи не идёт. Эти ладно, им питона хватит. А ебаные игровые гиганты же на тех же плюсах делают в основном, нет?
Я понимаю, что всё скатится в вялый срач на четыре собщения и одну смешную картинку, но потерпите чуть-чуть, пожалуйста, мне правда хочется разобраться.
>>83574
>Но на С его демка работала бы чуть быстрее, да и паскаль не настолько высокоуровневый, чтобы на нём было проще делать, чем на С. Короче, не понимаю я его.
Это же просто демка. Он хочет попрактиковаться в OpenGL, а не в крестах или другом ЯП.
>Не, с ними как раз плюсы неплохо справляются, код получается как ручной почти.
>некоторые на ассемблере пишутся, генераторы рандомных чисел, например
>>83575
>То есть будучи питонобогом можно делать настолько же технологические и производительные двиганы какие возможно есть на С?
Какие подходят для решения поставленной тобой задачи.
>http://en.wikipedia.org/wiki/List_of_game_engines вот тут отсортировать по языку - на си какая-то сущая хуйня, да и то половина старше меня, основная масса на других языках.
Ты C++ в расчет не берешь что ли? Да и то, там список опенсорсных двигов, ниже - коммерческие, вроде уненжина и крайенжина.
>>83577
>вроде уненжина и крайенжина
А они на С?
>Ты C++ в расчет не берешь что ли?
Отделяю от С и рассматриваю в качестве одного из всех остальных языков.
>>83578
>А они на С?
UnEngine на С++, CryEngine наверняка тоже.
>Отделяю от С и рассматриваю в качестве одного из всех остальных языков.
Ок, а почему именно С высматриваешь, а не бейсик?
>>83582
>Ок, а почему именно С высматриваешь, а не бейсик?
Потому что не слышал, что Бейсик - самый быстрый в мире язык, а про С слышал, причем неоднократно и с такой частотой, что и возник мой основной интерес - какого тогда лешего используют в массе своей что угодно другое.
>>83584
>а про С слышал, причем неоднократно и с такой частотой, что и возник мой основной интерес - какого тогда лешего используют в массе своей что угодно другое
Толстишь же. С++ - наше все, тот же C, только с классами, наследием, перегрузками и другими ништяками.
>>83587
То есть С не стоит рассматривать отдельно от плюсов в игроделе? Кстати, часто именно так и вижу, что пишут "C/C++".
>>83588
С и C++ это разные языки. Между ними нет полной совместимости. К примеру, код на Си вероятней скомпилируется Obj-C компилятором, чем C++ компилятором. С++ изначально и правда задумывался лишь как расширение языка, но потом ушел слишком далеко. А вот Obj-C и расширил сишечку и не потерял совместимость.
C++ это не С с классами. Лишь на самых ранних этапах это было так (был транслятор в Си-код), пока не появился отдельный компилятор. Теперь это новый язык с Си-подобным синтаксисом и некоторой совместимостью с Си-кодом. Фичи С++ это не только классы, фич дохуя на самом деле, особенно в последних редакциях.
С++ язык проблемый, надо признать. Несовместимости компиляторов, стандартов, которые всё время меняются, беднота некоторых мест в библиотеке, создающая необхимость использовать приблуды типа буста.
С++ почти так же производителен как и Си. Но по сравнению с Си позволяет удобно всё организовать в стиле ООП и в итоге писать меньше кода.
Когда кто-то пишет "С/С++" он пишет это только и только потому, что увидел как ещё какой-то долбоёб пишет ту же блядь хуйню. Дебилы сука ёбаные нахуй.
>>83600
Это пример, а пример не показатель. Есть ещё опенсорс от id, весь он старый, сейчас С используется в качестве основного языка даже не могу сказать где, никогда не слышал о чем-то таком. Почему?
>>83602
>Это пример, а пример не показатель.
Хотя, в данном случае он как раз железно опровергает процитированное. Логика не страдает, но я другое имел в виду, выразился как уёбок, так как давно не спал - гложет меня вопрос этот.
>>83599
Писали раньше.
>С++ почти так же производителен как и Си. Но по сравнению с Си позволяет удобно всё организовать в стиле ООП и в итоге писать меньше кода.
>>83604
То есть дело выбора жав, плюсов, шарпов, хаскелля - в удобстве?
>>83605
В конце концов всё транслируется в один и тот же машинный код.
Вон тот же Кармак на Хаскель Вольфенштайн 3д переписывает.
>>83605
Не считая хакселя да. Интерпретируемые языки - говно.
На жаве у тебя будет выше требования к ПЭКА потребителя. На шарпе у тебя будет сперма онли(если не ебатся с моно всякими).
На крестах у тебя будет кросс платформа если захочешь + ебля с указателями и эксепшены там где этого не должно казалось бы быть.
А вообще на юнити посмотри. Написан на крестах редактор и к нему неспешно подцепаются модули, позвоняющие собирать проекты про разные платформы. Скрипты пишутся на шарпе и все красиво.
>>83606
Ну, в общем, не скажу, что действительно узнал ответ на свой вопрос, тем более, что суть разницы в производительности, полагаю, как раз в лишнем машинном коде у менее производительного языка. Но видимо С просто менее читабелен, удобен и многофункционален из коробки, чем его потомки.
>>83607
Я так-то не кодер совсем, мимо шёл, непонятность нашёл.
>>83607
Что-то вы охуели. Это OpenGL тред, а не "Посоветуйте на чем игру делать - на юнити или на юнити?".
>>83577
>некоторые на ассемблере пишутся, генераторы рандомных чисел, например
Ну так я тебе и говорю, что генераторы случайных чисел нет смысла писать на ассемблере, потому что с ними и плюсыхорошо справляются.
>>83608
На самом деле, няшная сишечка ужасна, и называют её няшной только в сравнении с плюсами, иначе я ничего в этом мире не понимаю. C++, конечно, гораздо хуже, но там есть типа "полноценное" ООП, без которого ООП-дебилы жить не могут, а учитывая, что ООП-дебилов с каждым годом всё больше и больше… ну ты понел. А дроп производительности не такой уж и большой.
>>83606
>В конце концов всё транслируется в один и тот же машинный код.
Код совсем не один и тот же, он просто делает то же самое.
>>83612
>Код совсем не один и тот же, он просто делает то же самое.
Это уже зависит от компилятора.
>>83561
>>Геймдевы, у меня платиновый и тупой вопрос, но гугл молчит, а мне не спится. Почему вообще в геймдеве используется что-то кроме С? Ведь в реалтаймовых 3д-играх всё упирается в производительность, а до меня только и доходят обрывки того, какой С реактивный, а жава тормозит и рядом бенчмарки какого-нибудь цикла. Речь только об играх, где важна МОЩЬ.
Потому что для разработчика важна не скорость, а удобство (а то бы до сих пор на асемблере писали). А для директора - дешевизна процесса (читай студенты за еду которые не способны что-то большее освоить)
И уж тогда не Си а С++.... и внезапно все ААА игры пишут на С++, даже этот ваш юнити на нем написан (хотя его это не спасает). Unreal Engine, CryEngine все на С++. И это охуенно
>>83565
>пилил демку на паскалике и ничего
Да, а порисовать никто не хочет ;_;
↖ Ногами не бейте, я старался
>>83574
>Но на С его демка работала бы чуть быстрее, да и паскаль не настолько высокоуровневый, чтобы на нём было проще делать, чем на С. Короче, не понимаю я его.
Сишка действительно может выполняться быстрее, но так исторически сложилось, заколдованный круг "большая кодовая база => дрочим компиляторы => отличные компиляторы, нужно ещё больше кода" — тогда как потенциала для оптимизации у Паскаля побольше, за счёт простоты языка, в основном, но вот ещё пример: то, что для чего в Си нужен квалификатор restrict, в Паскале для open array-параметров можно гарантировать. Нынешние его флагманы этим не особо заморачиваются (или, в случае с Флорианом и K°, заморачиваются меньше, чем могли бы) — что ж, им виднее, для меня это не причина поддерживать языки, которые в 2013 не умеют модульность, используя их в собственных проектах.
>OpenGL thread
>>83619
Куда пропадал? И в треде на ычане долго не появлялся.
>>83619
>Сишка действительно может выполняться быстрее
Скорее даже "будет выполняться быстрее", всё-таки это миллионы человекочасов, вложенных в компиляторы, что меня жутко огорчает.
Хорошая обложка. Мне нравится, к чему это всё идёт.
>>83620
По "делам", каникулы, жара, рисовал, наконец. Впредь постараюсь быть расторопнее. :3
>>83619
Хотел бампнуть твой тред в августе, но оказался настолько слоупочным, что он к тому времени уже утонул.
>>83631
Это ты набежал, тащемта, ньюфажина. Сырна тут сто лет.
>>83651
Да-да-да. Когда я с iichan.ru/to/ делал йоба-тохоту, сырна ещё в пелёнки был укутан.
>>83653
Но на доску ты пришёл из /b/ полтора месяца назад. Такшто.
>>83654
Бэ-бэ-бэ!!!!
аргументы закончились
>>83658
С какой целью интересуешься?
>>83660
Жаль. Проверь на ОПе конкурстреда, там вроде заведомо положительно.
>>83661
Детектирую геев. Гарантия 100%.
Откуда столько аватароблядей набежало, а? Моя не понимай.
>>83663
Это заразно. Эпидемия, YAY!
Я помню появление Эксельки в б Ичана. Это ведь был ты? Это было похоже потоп - ты был повсюду, во всех тредах. Назойливый как Саркози, но не такой остроумный.
Ради чего? Зачем тебе аватарка, ведь большинство твоих постов не несет полезной информации.
>>83682
Потому что могу. Когда я трезвею, мне часто стыдно.
Фактически, МИЗУНЯ на этом и поднялся. В смысле, и на этом тоже.
> Саркози
Оверратед. На нульче был бы рядовым.
Привет, ребята.
Разъясните-ка мне, пожалуйста, за буферы. Вот создаю я индексы при старте программ через glGenBuffers(2, buffer), потом загружаю туда данные через glBufferData(). И пытаюсь я при каждой отрисовке сначала выбирать буффер посредством glBindBuffer(GL_ARRAY_BUFFER, buffers[0]), а потом отрисовывать его через glDrawElements(). Но ничерта не выходит, молвит, что access memory violation. Если же я выношу генерацию индексов буфферов и загрузку их данных в функцию отрисовки окна, то всё работает как надо.
Подсобите советом?
>>83823
Ложная тревога, проблему решил.
Оказывается, я ещё не достаточно понимаю С++.
где можно максимально подробно почитать про то как гл загружает данные из текстуры? у меня опять бармаглот от перевернутых текстур, в этот раз я нихуя не понимаю
итак, якобы гл ждет что 0,0 это левый нижний угол текстуры, а обычные пикчи, которые в пнг и прочем, нужно переворачивать перед аплодом, т.к. у них исходная точка слева-сверху
ок
freetype мне негерит битмапы, которые вроде как уже в нужном формате http://www.freetype.org/freetype2/docs/glyphs/glyphs-7.html однако они в результате отображаются перевернутыми по Y
по X все нормально. с координами факапа не должно быть, т.к. я вывожу прямо в clip-space, вертексы и координаты текстуры задаю с левого-нижнего угла по часовой стрелке (рисую соотв квад двумя треугольниками)
или речь идет чисто о том как располагаются байты в буфере?
перевернул короче руками сканлайны хули
//flip pixel rows (http://www.freetype.org/freetype2/docs/glyphs/glyphs-7.html)
//one pixel == one byte in our case
int pixel_num = g->bitmap.rows * g->bitmap.pitch;
char* texture_data = (char*) malloc(pixel_num);
for (int offset = 0; offset < pixel_num; offset += g->bitmap.pitch) {
memcpy(texture_data + offset, g->bitmap.buffer + (pixel_num - offset - g->bitmap.pitch), g->bitmap.pitch);
}
glTexSubImage2D(GL_TEXTURE_2D, 0, ox, oy, g->bitmap.width, g->bitmap.rows, GL_RED, GL_UNSIGNED_BYTE, texture_data);
>>87445
Ты дурак? Текстурные координаты переключить не додумался?
>>87549 нет ты. это дурацкий костыль, и можно присесть на дилду с ним. лучше переворачивать саму пикчу и кормить глу в нормальнов виде уже
>>87566
Ну ок, только твой велосипед - говно, если на таких простейших вещах тебе приходится мудохаться. А "нормального вида" нет, гпу все равно. Это в твоем велосипеде гвоздями прибиты текстурные координаты и порядок вершин в кваде.
Юнити-Бог ссыт на лицо опущенцам с их проблемами.
>>87600 мудохаться - это веками переставлять руками координаты текстуры по всей программе, вместо того чтобы автоматически перевернуть текстуру так, чтобы она была в очевидной ожидаемой позиции
>>87602 и что юнитибоги делают с отсутвием нормального гуя? или наконец уже завезли что-то юзабельное и не люто тормозящее в последних версиях?
>>87619
Так можно же кастомные юзать. Ну или делать тшри де гуи лол.
другой мимо-юнитихуй
WTF?
Но в то же время...
>>61003
Дорогие, юные Кармаки, привыкайте смолоду писать так:
// тут всякие матрицы-кватернионы
void Update(float dt){...}
void render()
{
// Get the OpenGL transformation
GLfloat mat[16];
body->getGLTransform(mat);
glPushMatrix();
glMultMatrixf(mat);
glutSolidSphere(radius, 20, 20);
glPopMatrix();
}
>>87809
Проиграл с этого учителя.
Об бороду не спотыкаешься?
>>87815
Нет, не спотыкаюсь. Хотя спотыкаюсь, да. О ступеньки в Remedy Entertainment.
>>83457
Посидев 4 дня без интернета, решил снова взяться за OpenGL, правда, забыл все нахуй.
Запилил отдельные объекты с буферами вершин, тк и нормалей. Рендерится каждый объект отдельно, по 1,2к трианглов на каждый, 50 * 50 отрисовок пикрилейтед.
>>89119
Объединил по 10 * 10 моделек в один меш. Итого 120к трианглов на объект, 5 * 5 отрисовок. ФПС не изменился.
>>89120
>ФПС не изменился
Время, затраченное на отрисовку кадра.
И тут же вопрос:
Как правильно в С++ включать заголовочные файлы? Например, есть у меня файл controls.cpp, где я просто вызываю методы для объекта класса Entity. А у этого класса есть член - ссылка на объекта класса Mesh, у которого тоже есть член-ссылка на объект класса Material. Так вот, зачем мне в controls.cpp включать кроме entity.h, еще и mesh.h, и material.h? Реально заебывает, и так нужно делать в каждом файле, где я оперирую объектом Entity.
>>61024
ЫЫЫЫ по ней родимой начинал, сначала запилил двиган который по командной строке берет номер урока и визуализирует. Когда дочитал сделал меню и простенькую навигацию на PNG текстурах.
class GLExampleBase
{
public:
virtual ~GLExampleBase();
virtual bool init();
virtual void reshape( int width, int size );
virtual void update( float dt );
virtual void display();
}; // GLExampleBase
>>61026
не помню особых проблем под cygwin. с сайта книжки можно скачать архив с исходниками, если что.
>>89121
А нахуя ты так делаешь? Если у тебя на меш указатель, и ты его при этом не используешь - тебе достаточно forward declaration'а.
То есть в ентити.х
class Mesh;
class Entity
{
Mesh *mesh;
}
И дальше mesh.h инклюдишь только там, где через этот указатель что-то делаешь.
Вообще на крайняк можно и в хедере заинклудить, но золотое правило - делать так только при необходимости крайней. Иначе можно заебаться с порядком инклудов и циклическими зависимостями.
>>89147
У меня указатель на камеру, которая является объектом класса Camera, который наследуется от класса Entity и я просто от этого объекта (камеры) вызваю метод родительского класса:
pSceneCamera->EntitySetPos();
Если ничего не заинклудить, то выдаст, что класса Camera нет, и метод неизвестный.
Если подключить camera.h, то напишет, что не найден класс Entity.
Если в инклудах есть camera.h и entity.h, опять вывалится ошибка - неизвестный класс Mesh, потому что у класса Entity есть член:
Mesh * m_pMesh;
и так далее.
>>89121
Если ты что-то используешь неизвестное в коде, то ты должен объяснить что это такое, подключив эту хуйню.
Или можешь просто объявить в заголовочном файле, если эти классы нужны просто как упоминания, не трогая их членов и методов.
class Mesh;
class Material;
>>89149
Сам это придумал? Такого быть не может. Как по-твоему скомпилится камера, если в ней не проинклужены её собственные зависимости (энтити и меш)? Никак, так же как оно не компилится у тебя. Получается, что эта камера недописана и не компилится в принципе. Хули ты тогда задаешь вопросы по неработающему коду?
>>89159
>forward declaration - как писал антон сверху.
Почитай про это. А вообще если хочешь равняться на кармаков, то изучай(смотри) их исходники.
https://github.com/id-Software/DOOM-3-BFG
Если найдешь там такую же хуйню, то считай правильно всё.
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/BufferObject.h
Вот например тут сначала говорят компилятору, мол есть такой класс где-то под названием idIndexBuffer, так что если встретишь то не ругайся.
Ну и компилятор такой окей буду думать что есть.
А ты такой хуяк и не просто в коде указываешь idIndexBuffer, а ещё и вызываешь его метод, тут компилятор такой говорит. ТЫ АХУЕЛ? Ладно ты мне скзал что есть такой класс, но блять ты же не сказал что там есть такой метод, я чё, сука, тебе должен на слово чтоли верить? А ну блять быстро подключил в инклюдах заголовок от этого класса, чтобы я проверил есть ли там такой метод или нет.
>>89173
Хоть не очень удачный файл выбрал для примера, в BufferObject.h idIndexBuffer определяется ниже по коду. Но всёравно знай что конпилятов идёт сверху вниз и при компиляции он собирает все твои ашники в один гигантский заголовочный файл и по нему уже определяет где чего не хватает.
>>89174
А всё потому, что пиердолики не осилили многопроходную конпеляцию.
>>61003
OGL-господа, что вы думаете насчет использования Qt (через его OGL-виджет) вместо glut\иного?
>>89173
> Почитай про это. А вообще если хочешь равняться на кармаков, то изучай(смотри) их исходники.
Добавлю пару слов к этому джентльмену.
Сам Кармак говорит, что ему больше подходит/нравится функциональный стиль программирования и дело понятное, что над кодом серьёзные дядьки трудятся годами.
Поэтому мега-йоба-ооп стиля там врятли можно найти Кармак технический директор - как сказал так и будет.
>>89174
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/idlib/precompiled.h
Вот он, кстати, этот файл.
>>89230
>Поэтому
нет не поэтому
локализация и прояснение стейта это не фп а попросту здравый смысл
а фп (форсированная иммутабельность, ленивость) не совместим с областями сводящимися к оптимизированному дрочеву стейта. у него приступ фанбоя, потому что эти языки просто вцелом на порядки объективно удобнее убогого кривого байтодерьма
>>89237
> вцелом на порядки объективно удобнее убогого кривого байтодерьма
А мировые игроделы тупые, всё ещё байтоёбством занимаются.
Один ты умный, на сосаче сидишь.
Поясните за прозрачность. Делаю так
glEnable(GL_BLEND);
glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glBlendEquation(GL_FUNC_ADD);
Всё верно, используется альфа канал исходного изображения.
Но почему тут вместо этого красный цвет http://www.opengl-tutorial.org/wp-content/uploads/2011/05/fontalpha.png? Зачем это. И как взять красный цвет в кач-ве алфа?
Алсо, посоветуйте ресурс с наборами шрифтов.
>>89303
>This texture was generated using CBFG, one of the many tools that generate textures from fonts. If was then imported in Paint.NET where I added a red background (for visualisation purposes only : everywhere you see red, it’s supposed to be transparent ).
У него даже на пикче видно, что он просто слой с красным фоном подставил.
Алсо, с его FontVertexShader будет дерьмецо, как на пикрелейтед.
Где фонты взять не знаю.
>>89307
Спс. Вот тут есть несколько паков http://forum.thegamecreators.com/?m=forum_view&t=74431&b=4.
>>89307
Дать тебе нормальный код для отрисовки шрифтов из BMFont? Недавно писал для себя.
>>89332
Да, дай посмотреть, пожалуйста.
Алсо, подглядел как у MnB дела со шрифтами обстоят, когда кастомные ставил: текстуры со шрифтами и .xml файлы, с указанием кодов символов, высоты, ширины и прочего. Вот только непонятно, как делать шрифты разного размера, ведь уже существующая карта сжимается или растягивается, а когда растеризируется, то получается как-то криво.
>>89333
https://gist.github.com/sorrge/7056735
Шрифты разного размера нужно делать отдельно, под каждый размер свою версию.
Кто-то работал с ортографической проекцией?
glOrtho уже deprecated ведь, написал свой
void applyOrtho(float left, float right,float bottom, float top,float near, float far)
{
float a = 2.0f / (right - left);
float b = 2.0f / (top - bottom);
float c = -2.0f / (far - near);
float tx = - (right + left)/(right - left);
float ty = - (top + bottom)/(top - bottom);
float tz = - (far + near)/(far - near);
float temp_ortho[16] =
{
a, 0, 0, 0,
0, b, 0, 0,
0, 0, c, 0,
tx, ty, tz, 1
};
memcpy(ortho, temp_ortho, 16 * sizeof(float));
}
Шейдеры вот:
const char* vertexSrc =
"attribute vec4 vPosition;"
"uniform mat4 umWorld;"
"void main()"
"{"
"gl_Position = umWorld * vPosition;"
"}";
const char* fragmentSrc =
"precision lowp float;"
"void main()"
"{"
"gl_FragColor = vec4(1.0,0.0,1.0,1.0);"
"}";
Ничего не выводится, хотя с перспективной матрицей корректно отрабатывает.
Дайте какой-нибудь туториал по С++, а том могу только написать Hello world в CodeBlocks написать.
>>89406
Ужс. Делай все, как в http://www.opengl-tutorial.org/
>>89410
Конкретно, что ужасно? По ссылке используется glm, мне не подходит. Надо свои обработчики матриц писать.
>>89413
>Надо свои обработчики матриц писать.
Это и ужасно. Еще не стоит запихивать шейдеры в код, делай их файлами.
>>89413
> Надо свои обработчики матриц писать.
https://github.com/id-Software/DOOM-3-BFG/tree/master/neo/idlib/math
Пользуйся.
>>89419
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/idlib/math/Matrix.h
В чём проблема взять готовое и дописать своё ещё?
Кароче блять с вас толку ноль.
Хотя бы объясни тогда, зачем писать свои обработчики матриц. Тебе советуют самый простой и надежный способ.
Потому что я пишу для на marmalade sdk. Туда геморно подключать сторонние библиотеки. Обработка матриц это ерунда, я же говорил, для перспективы написал. Сделал то же самое для ортогональной, не понимаю в чем косяк, вот и спрашиваю.
>>89431 в чем заключается геморность? трудно представить чтобы подключить либу было геморнее чем навелосипедить лишний раз и наесться говна с багами, даже для динамики обычно всегда есть ffi через который можно дергать какой-нибудь kazmath
>>89431
glm подлючается одними .h файлами, никаких отличий от твоего велосипеда с этой точки зрения нет. Разве что там язык у тебя ограничен как-то.
скажите лучше вот что. как в йобе обращаются с тем что нужно овер дохуя объектов в кадре, и у каждого своя позиция в мире т.е. трансформация? если заливать вертексы в model space и при движении менять только матрицы, это значит что по draw на объект, что вроде как хуево (а может и нет, внятной ясной инфы как-то не приводят, а бенчить непросто и лень. но надо бы, конечно). если заливать уже трансформированные на цпу вертексы, то это дрочево цпу и дрочево канала к видюхе
или как обычно для каждого случая свои костыли типа разного обсчета для персонажей и для пуль, всякие дикие инстансинги и прочее?
>>89455
Ну хуй знает. Вроде проще как все на GPU считать, он же специально заточен под работу с float. Если обсчитывать на CPU, то это надо все эти буферы они же в RAM видеокарты висят? на него сначала передать, потом ему медленней чем GPU обсчитать, а потом обратно на видюшку перекинуть.
>>89455
Вообщем так.
если это дохуя одинаковых объектов, то юзают инстансинг (то есь рисуют один объект в шейдере со сдвигом). Но это вверх шаманства, вон в юнити инстансинг до сих пор разрабы не осилили сделать.
Если это дохуя разных объектов но далеких от камеры, то ебашат из них ипосторы (то есть рендерят меш в текстуру), и снова инстансят либо батчат
Если объектов дохуя, они разные, но у них одинаковый материал (ради этого и придумали текстурные атласы). То все эти объекты объединяются в один объект, тогда будет всего одна матрица трансформации, потому что это будет не дохуя объектов, а всего один огромный объект.
Если материалы разные, сортируют по материалам, чтобы найти те, у кого объекты одинаковые и их батчить.
>>89469
Я думаю:"Бля бабу ебать хочется, может шлюху снять. А может не надо, доррого ещё пару тыщ заработать. А может подрочить просто. Бля ну это не солидно как-то уже. Бля там одна тянк в универе есть она блядь улыбается мне, мне что нужно нахуй её добиваться чтоле. Типо подоходить знакомеца. А ну нахуй пойду погуляю."
>>89459 да нет, многие ПРИОТКРЫВАЮТ ЗАВЕСУ
например http://www.guerrilla-games.com/presentations/Valient_Killzone_Shadow_Fall_Demo_Postmortem.pdf
или http://www.slideshare.net/naughty_dog/uncharted-2-character-pipeline
и в куче пейперов пишут прям "техника разрабатывалась для игры N"
>>89464
>они же в RAM видеокарты висят?
омич, как ты думаешь они там появляются?
>>89467
> ебашат из них ипосторы
а анимация? если объекты в разном состоянии в анимации, это опять же по дроуколлу на объект. или это только для статических? для статики-то подходит да
>То все эти объекты объединяются в один объект
>Если материалы разные, сортируют по материалам, чтобы найти те, у кого объекты одинаковые и их батчить.
погоди, это чтоб шейдеры/текстуры не переключать например. но при чем тут трансформации позиций, ведь они разные. как ни сгруппируй, эти объекты в разных местах → у них разные трансформации
Привет. Изучаю тут геймдев с опенглом.
Вроде общая картина стала более мене понятна, но мне нужны ответы на более специфические нубские вопросы. Да, изучаю пока легаси апи, ибо программабл пайплайн до меня пока слабо доходит.
Есть пара вопросов.
Я как первый проект, где я изучаю основы, гейм луп, бэйсик опенгл, структуру игровых объектов пишу совсем примитивную игру - клон Sokoban. Значит все что мне нужно рисовать это 2d квадраты - тайлы.
Но мне на простой игре хочется изучить хорошие практики. Правильно ли, что карта уровня у меня будет хранится в массиве, и для ее отрисовки я буду проходить по ней циклом, вызывая для каждого игрового объекта (стена, игрок, ящики, пол) буду вызывать метод .draw() ?
Соответственно - правильно ли, что в методе .draw у меня будет что то типа:
draw(int delta){
glBegin(GL_TRIANGLES);
//тут будет координаты двух треугольников, образующих квадрат, привязка текстур
glEnd();
}
или может глБегин глЕнд надо вынести за пределы метода .draw? и вызывать их перед циклом отрисовки карты?
До сих пор не совсем понимаю назначение glPush-PopMatrix(); Нужны ли они в моем случае?
>>91025
>Изучаю тут геймдев с опенглом.
>glBegin glEnd glPush-PopMatrix
>>91037
Никто тебя и не пытался троллировать, просто если ты планируешь в сердце геймдева дальше погружаться, то старайся сразу делать правильно.
>Или вы мне хотите предложить квадратики четырех цветов шейдорами рисовать?
Именно. В шейдерах ничего страшного нет.
Заодно узнаешь, что такое индексация
Видеокарты не нужны.
Гейчую! Только ЦПУ и тормозные облака точек, только хуевая картинка!
>>91058
Двачую. Нехуй кормить пиявок-производителей говнокарточек, которые не могут придумать ничего лучше разогнанного 3DFX-а.
>>91025 ты изучаешь хуйню а не основы. если одна из задач изучения это рендер то нужно сразу изучать нормальный рендер, изучение тухлятины тебе мало что даст, и придется переучиваться (и ты реально будешь всё заново вкуривать), просто просрешь время. если иы хочешь изучить как писать игру вцелом без перекладывания байт и вершин (что ты и должен для начала хотеть), то бери фреймворк в котором уже есть инструменты для отрисовки и играйся с ним
>>91061
Самый норм графон начнётся когда откажемся от растеризации (дебильный брутфорсный уродливый путь фейкования, старый как говно мамонта. Угловатое говнецо + шейдерное мыльцо. Сколько ещё будем жрать это говно? Если откажемся от растеризации и перейдём на лучи, то рулить будут многоядерные процессоры. Сейчас на всяких йобических видюшках уже можно через сверхкривую жопу трейсить, но это как бы использование "3д-ускорителя" не по прямому назначению. Вот на дохуядерных процах трейсить будет поудобнее: доступ к памяти (никаких передач данных через текстуру блядь), стек, никаких ограничений на кол-во операций или на типы инструкций, нормальная совместимость.
Облака точек и мифический гениальный алгоритм это всё заебись, конечно, но интерактивного реализма без лучей добиться будет сложно.
>>91073
>откажемся от растеризации
>и перейдём на лучи
/0 А лучи чем занимаются?
>но интерактивного реализма без лучей добиться будет сложно
Ну и ладно. Можно отказаться от чего-то одного. Реализм ясчитаю - это лишнее мне ирл хватает реализма за глаза, тащить его еще и в виртуальность это слишком.
>>91071>>91055
Вы правы, я не спорю. Но я уже конпелировал шейдоры на плюсах, начинал читать real time rendering и туториалы по модерн опенгл. Но все это довольно сложно сейчас для меня, плюс накладывается что я сам каркас игры то не знал как написать. Сейчас стало более менее понятно. У меня в чек листе есть пункты переноса игры на шейдоры и в 3д. Но сейчас важней всего приучить себя делать что то готовое, доходить до ощутимого результата которого у меня до сих пор не было а потом уже увлекаться графическими изысками.
>>91073 да успокойся уже, до этого еще хз скока лет. вон пацан трейсит http://raytracey.blogspot.ru/ но это все зачатки, пока наступит время когда это все будет полностью юзабельно, можно дохуя нарендерить старым способом, который все равно придется комбинировать для всяких оверлеев и прочего. а щас (и еще долго) это все бессмысленно для неспециалистов-нересёрчеров
>>91080 так я про это и говорю епта - не еби себе мозги выдрачиванием рендеринга (т.е. пиши как попало или возьми фреймворк) и сфокусируйся на остальном
олсо всем пикрилейд пойду выдрачивать аишечку
>>91080
OpenGL подразумевает низкоуровневую работу с графикой, и тред именно об этом. Если тебе абы как лишь бы что-то отобразить на экране, используй какой-нибудь love, флеш, processing, unity3d. Если надо обязательно на крестах зачем-то, то есть sfml, sdl, gdi+.
Ты выбрал неправильный, чрезмерно сложный для тебя инструмент, и никуда дальше не продвинешься, так и будешь глупые вопросы задавать.
>>91092
я выбрал lwjgl и java, плюсы слишком хуево знаю.
Блять, ну я не верю что все вы начинали ебашить на опенгл сходу на шейдерах, и никто не трогал легаси апи и иммидиейт мод.
>>91113
>lwjgl
>java
Исходники Minecraft и Jake II (Java-порт Quake II) тебе в руки. Изучай.
>>91113
Просто, блядь, забей. На кой хер ты вообще слушаешь местных кукаретиков? Хочешь пилить на 1.1 - пили, хочешь на 2.0 - пили на 2.0, хочешь 4.0 - ну ты понел. Это если ты хочешь что-то делать. Если же тебе хочется быть "как все, чё я как лох-то буду" и "чтобы пацаны не засмеяли", то продолжай страдать хуйнёй.
>>91113
Дохуя людей начинали ебошить на 1.0 потому что тогда шейдеров-то и не было. И не умерли и всё заебок. Фиксд пайплайн и правда легче для понимания новичку, так что если хочется - обмазывайся древними туторами и хуярь.
>>91117
>Исходники Minecraft
лалшта? Мало того, что MC не опенсорс, так там еще и лютый говнокод. И ты советуешь ему копаться в деобфусцированном говнокоде?
>>89483
>Qt мне лично не нравится, очень толстый
Ебать дибил. QtCore + QtGui меньше 5 мб весят.
>>91119
Ты осознаешь что в этом нет смысла?
Потому что это не даст никаких плюсов при изучении шейдеров.
Это просто пустая трата времени.
>>91138
Шейдеры потом. Когда получше пайплайн станет. Когда их компилировать можно будет, например. Сейчас пока ещё одними шейдерами нельзя всегда обходиться.
>>91025
Вот хороший понятный и простой набор туториалов с картинками. Почитай на досуге.
http://open.gl/introduction
Чота у меня в шойдере если так написать "gl_Position = mvp_matrix * a_position;", то перспектива исчезает. А так "gl_Position = mvp_matrix * a_position;" норм. Везде пишут, что первый вариант верен. Математики есть?
>>91209
Ты меня секунд на 30 в ступор ввел. Телепатирую, что у тебя в правильном случае "gl_Position = mvp_matrix * vec4(a_position, 1);" ? Гугли homogeneous coordinates.
>>91209
Упс. Короче
"gl_Position = a_position * mvp_matrix;" у меня так работает, но везде пишут, что надо:
"gl_Position = mvp_matrix * a_position;", что у меня разрушает перспективу.
a_position это
"attribute vec4 a_position;"
>>91230
Умножение матрица на вектор некомунитативно. В одном случае результат матрица в другом вектор. И еще ГЛ хз как вектора там обрабатывает наверно как 4-х мерные.
>>91230
Значит, матрицу неправильно сделал, она у тебя транспонированная.
>>91232
>В одном случае результат матрица в другом вектор.
Неверно, вектор в обоих случаях. Если вектор справа, то это должен быть вектор-столбец, и результат - вектор-столбец. Если вектор справа, то и он, и результат - векторы-строки.
>ГЛ хз как вектора там обрабатывает
Как напишешь, так и будет обрабатывать. Поддерживаются все измерения от 1 до 4.
>>91236
>Если вектор справа, то и он, и результат - векторы-строки.
слева
Откуда полосы? что я делаю не так?
>>91348
Пикрелейтед текстура.
Вот массив текстурных координат:
0.0f, 0.0f, 0.33f, 0.0f, 0.33f, 1.0f, 0.0f, 1.0f, // Top
0.33f, 0.0f, 0.66f, 0.0f, 0.66f, 1.0f, 0.33f, 1.0f, // Bottom
0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.66f, 1.0f, // Front
0.66f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.66f, 1.0f, // Back
0.66f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.66f, 1.0f, // Left
0.66f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.66f, 1.0f, // Right
Вроде бы всё правильно
>>91346
Попробуй сделать параметр фильтрации текстуры GL_NEAREST
Если и нужно подчеркнуть пикселизованность текстуры, то тем более меняй параметр.
>>91350
В развёртке между кусками оставь по одному пикселю зазор (того же цвета что и соседний). Или увеличь точность текстурных координат - 0.33 округляются по точности и могут залезать на соседний кусок развёртки. Плюс правильнно сказали - при выборке из текстуры могут учитываться соседнии пиксели текстуры - тоже на границе будет лишняя черта.
Ура
>>91366
Это
0.0f, 0.0f, 0.333333f, 0.0f, 0.333333f, 1.0f, 0.0f, 1.0f, // Top
0.333333f, 0.0f, 0.666666f, 0.0f, 0.666666f, 1.0f, 0.333333f, 1.0f, // Bottom
0.666666f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.666666f, 1.0f, // Front
0.666666f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.666666f, 1.0f, // Back
0.666666f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.666666f, 1.0f, // Left
0.666666f, 0.0f, 1.0f, 0.0f, 1.0f, 1.0f, 0.666666f, 1.0f, // Right
и
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
было GL_LINEAR, стало GL_NEAREST
У меня будет совй дварфач с графином
>>91368
вот дойдешь до физики, ориентации в пространстве и прочих коллизий, вот абасрамс будет.
ГРАФИН 1 ФПС АЗАЗА
>>91368
не забудь про освещение.
>>91374
Как понимать эти формулы в контексте программирования? Где почитать? Я от этого сиграфовы подтирухи не могу читать.
обсраться. моя первая тайловая карта заработала
Тэкс... И как же мне нарисовать 900 000 кубов чтоб не тормозило?
>>91379
Смотри там весь сайтец норм:
http://steps3d.narod.ru/tutorials/lpp-tutorial.html
http://steps3d.narod.ru/tutorials/ds-tutorial.html
Еще была книжка у Борескова по которой я постигал освещение, но я забыл как она называется(что-то "комп графика")
>>91382
Инстансинг.
>>91384
>Отсекай невидимое, видимое объединяй в один меш.
Можно поподробнее о каждом?
>>91386
Если сверху от кубика не пусто, то удаляем те полигоны, которыми рисуется верх. Если снизу от кубика не пусто, то удаляем те полигоны, которыми рисуется низ... Повторить для каждого направления. Потом создаёшь новую мешь и скидываешь в неё всё, что осталось. Если у тебя разные текстуры на кубах, то нужно будет их объединить. А ещё между первым и вторым пунктом можно собрать все полигоны, образующие одну плоскость, и объединить.
>>91390
Так что, потом перегонять меш на видеокарту? Это ж долго
>>91417
Тебе всё равно перегонять, если ты отрисовывать собрался.
>>91432
Так у меня один буфер, я его прибиндил. Потом в цикле смещаю модельную матрицу куда надо, вычисляю мвп матрицу, связываю с шейдером и рисую. Никаких перемещений по шине у меня нету.
Просто погугли "как сделать майнкрафт", есть подробные инструкции.
>>91382
1. Заполняешь буфер трансформациями и атрибутами кубиков, отрисовываешь, в геометрическом шейдере строишь кубик с нужной трансформацией.
2. Заполняешь буфер вершинами кубиков, отрисовываешь.
3. Инстансинг вручную (если объекты сложнее кубика). Суть примерно как у скиннинга. Заполняешь буфер кубиками, для каждой вершины задаешь индекс в массиве трансформаций. Размер буфера - на сколько хватит юниформов. Загоняешь в юниформы массив с трансформациями кубиков, отрисовываешь буфер. Повторяешь сколько надо.
Кароч нахуй опенгл. буду так делать
>>91469
Уже делал. И всякое говно типа ривер рейд и тамагочи. Хочется что-то существенное.
Утренний сап, котики.
Дело вот какое, меня интересует какие операции с матрицами мне нужно реализовать для фпс игорь?
>>91508
Выбирай синюю.
>>91508
Sup :3
Такие же, как и для остальных 3D-игр: умножения, складывания, транспонирования, нахождения обратных матриц всевозможные трансформы, ротации (в углах Эйлера или кватернионах), масшатабирования, матрицы проекций, переводы из глобальных координат в локальные.
>>91508
Гугли Cube Engine. Это открытый движек, компиляется в вижлстудии за 1 клик. Пишется чуваком из крайтека уже 10 лет. Написан в стиле 99х-00х.
А про матрицы тут просто надо теорию изучать, а не спрашивать какие 2-3 формулы испольщрвать, что бы крузис написать.
>>91545
>А про матрицы тут просто надо теорию изучать
Я понимаю. Приобрёл пару учебников по линейной алгебре, сижу читаю ну и плюс кармаковские исходники. Хотя там слишком много наворотов на мой взгляд.
>>91562 не надо это дерьмо читать, вот написали специально http://www.arcsynthesis.org/gltut/Basics/Introduction.html
такой то интерактив http://natureofcode.com/book/chapter-1-vectors/
Ньюфажный вопрос. Как выбрать текстуру из атласа?
биндим верткесный буфер
биндим индексный буфер
биндим картинку атласа
по идее надо прибиндить буфер текстурных координат, если тестура статичная, а при динамичной что?
Изменить тут что-то glVertexAttribPointer(tex_loc, 2, GL_FLOAT, GL_FALSE, 0, 0);?
>>91614
Передавай в шейдер юниформы translation_u, translation_u, scale_u, scale_v текстуры в атласе, соответственно трансформируй аттрибут в шейдере.
>>61003
Не могу разобраться в одной штуке.
Почему-то объекты на заднем плане сферы при определённых условиях не отрисовываются.
Колёсиком делаю приближение/удаление через увеличение/уменьшение некой переменной масштаба.
При отрисовке объектов каждую координату на этот масштаб умножаю.
GL_DEPTH_TEST включен.
Помогите суперньюфагу.
ФАКи читал, туплю. Не идёт OpenGL у меня
>>91641
Z-координаты объектов меньше значения far clipping distance матрицы проекции?
>>91614
Что значит "динамичная текстура"? Это просто одна большая текстура, содержащая все кадры анимации, или множество мелких, но по одному кадру, но это не практично. Например, есть текстура 512х512 пикселей, один кадр занимает 32x32. Предположим, что в анимации всего 24 кадра. Делаем счетчик кадров, и с каждой отрисовкой увеличиваем его на 1. А в шейдер просто посылаем UV-координаты, которые вычисляем простым сдвигом счетчик_анимации * 1.0f / 16 в текстуре помещается 16 кадров в ряд, 512/32 = 16, просто перескакиваем на один ряд вниз, когда берем 17 кадр. Ну ты понел.
>>91669
far clipping distance? Звучит правдоподобно.
Как это поменять в ней?
С этими матрицами не могу разбраться. Вроде и читал кучу всего, а не понимаю.у меня от этого жопа в огне
Ещё не могу биллбоардинг осилить. Опять же, гуглил, читал, но не понял толком.
С этим OpenGL чувствую себя тупым и что зря прогуливал в ВУЗе всякого рода математику.
>>91762 ты читал http://www.arcsynthesis.org/gltut/ ? перечитывай и ковыряйся до порсветления, это вроде единственный тутор где достаточно хорошо подаётся материал, другие тупо пихают вперемешку без объяснений. я тоже не с первого раза въехал но с n-го въехал. главное не спешить и вдумываться
>>91762
Нe дергайся, чувак. Никто с нуля за один-два дня не может начать сразу хорошо разбираться в современной компьютерной графике. Покопаешься с месяц хотя бы, начнешь понимать, что к чему.
>>91779
>Нe дергайся, чувак.
Спасибо, няша. Ты меня успокоил.
>>91767
http://tomdalling.com/blog/category/modern-opengl/
здесь еще офигенно преподносится материал.
Таки отрисовал ~пол миллиона кубов, добавив примитивное освещение.
Реквестирую алгоритм рытья пещер.
>>92219
Perlin Worm гугли, в муникруфте юзается вроде как. Или юзался.
>>92281
Мне не похуй. Я про то, что если бы это был не трап, я бы не фсфапнул.
Стоит учить OpenGL ради 2д графона?
Стоит учить OpenGL ради 2д графона? Если да, то дайте каких-то советов касательно именно 2д.
Вот, например, всякие штуки вроде частиц можно только с помощью открытой графической библиотеки сделать эффективно?
Какие книги по геометрии и алгебре можете посоветовать? Если в контексте разработки видеоигр, то вообще охуенно. Если легко написано, то можно и на английском.
Знаю, что вопрос не очень в тему треда, но здесь должны надеюсь сидеть знающие анончики.
>>92336
Essential Mathematics for Games and Interactive.pdf
Антош, где можно посмотреть на хороший код (и архитектуру) простенькой 3D игры, написанной с использованием opengl на C++, с простенькой физикой, загрузкой моделей?
Есть ли подобные проекты, созданные в обучающих целях? Только без тонны лишнего говна.
>>95014
Там есть опен-сорсные игры, покопайся.
http://en.wikipedia.org/wiki/List_of_OpenGL_programs
>>95016
>Counter-Strike: Source
>Нет сорцев.
Я тред не читал, братишки, дохуя что-то.
Вопрос:
Знаю три способа использования opengl:
1. как в уроках nehe (старье, не подходит)
2. с использованием freeglut. (колбек-ф-ции затрудняют использование ООП)
3. qt opengl. В общем-то заебись, но постоянно тягать с собой библиотеки qt напрягает.
И собственно вопрос: Какие еще есть способы, чтобы без winapi (для линуха надо), с возможностью в ООП.
>>95051
Не понял, что конкретно нужно. ООП обертка над OpenGL? Попробуй http://oglplus.org/
>>95052
Да, тип того.
Спасибо. Попробую заценить на досуге.
>>95051
Срочно санитаров! У него ООП головного мозга с осложнениясми!
Никто не сталкивался с такой проблемой Shadow Map'ов?
Здесь заяц отрендерен так, как его видит источник света, по идее тень должна быть под ним, не видима, но она почему-то смещается по оси Y.
Тесты показали что это как-то связано с размером фреймбуфера для рендеринга геометрии (фб для тени 1024х1024 в текстуру, фб для геометрии 1024х768 на экран). Если подогнять геометрический фреймбуфер до размеров текстурного, то все нормально.
Как с таким бороться?
ПС: пайплайн динамический, вырезки из шейдеров могу приложить
>>96390
Бамп вырезкой из шейдеров. Спасайте, кролик тонет!
/* Vertex Shader */
#version 150
varying vec4 ShadowPosition;
void main() {
/* ... */
ShadowPosition = vec4(position, 1.0) * mModel * mLightView * mLightProjection * mBias;
ShadowPosition = ShadowPosition / ShadowPosition.w;
ShadowPosition.z -= 0.0005;
}
/* Fragment Shader */
#version 150
varying vec4 ShadowPosition;
void main() {
if (texture(shadowMap, ShadowPosition.xy).z < ShadowPosition.z) {
if (ShadowPosition.w > 0.0) {
intensity = 0.1; } }
}
>>96448 да ща тебе за сразу ночью решат все проблемы, все сидят прям давят ф5))) главное не пиши как решил проблему и сагай)))
>>96451
Это была тактическая сага, чтобы тред не всплывал. Проблема-то решена, зачем поднимать его?
>>96451
А проблема решилась сетом вьюпорта для разных фреймбуферов в разное значение.
Бамп.
>>87401
В bmp изображение хранится вверх ногами и отраженное по х.
Привет кирилы, у меня вопрос появился. Вот есть 2д игра и в ней для анимации и прочего используется атлас текстур - это выгодно и быстро, т.к. переключение текстуры занимает нормальное время.
А как делают в современных 3д играх, где текстуры персонажей довольно большие, там по 1 переключению на рендер одного персонажа идет?
>>102756
Биндят все текстуры разом, в шейдер передают номер нужной. На современных карточках можно забиндить 128 текстур одновременно.
Котаны, где почитать про различию row-major и column-major матриц?
>>105201
В любом учебнике по линей алгебре не описываются opengl и почему он такой привередливый к матрицам.
>>105200
row-major - первый индекс - строка, второй - столбец.
column-major - наоборот.
В opengl используют второй вариант.
>>105201
Тут дело скорее в способе представления матрицы в памяти. Память-то линейная.
Это вообще нормально?
#include <GL/glew.h>
int main(int argc, char** argv)
{
glewExperimental = GL_TRUE;
glewInit();
return glGetError(); //0x502
}
>>105588
Все ок, рендер идет, просто ошибку пофиксить хочется.
>>105587
Так, тут ошибка из-за отсутствия контекста, как я понял.
boost::timer::cpu_timer t;
window = wnd;
context = nullptr;
if (!SDL_WasInit(SDL_INIT_VIDEO))
return;
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, major);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, minor);
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
context = SDL_GL_CreateContext((SDL_Window*)wnd->GetSDLPointer());
glewExperimental = GL_TRUE;
unsigned int ret = glewInit();
if (ret != GLEW_OK)
context = nullptr;
const unsigned char* v = glGetString(GL_VERSION);
if (v[0] != major || v[2] != minor)
context = nullptr;
ret = glGetError(); //0х500
А вот в чем тут ошибка хз. Все опять же рендерится.
Ошибки нет, по-моему. Глюинит же не обещет корректно выставлять glGetError, у него свой код возврата. Он там что-то делает внутри, оно фейлится, но ему это ок. Может, экстеншены проверяет какие-то.
>>105591
Ну ок, спасибо. Боюсь просто, как бы в рандомный момент все не наебнулось, мало ли.
>>105590
Не на 100% уверен, но у меня GetError будто бы возвращала ошибку до любых GL-функций при неверной версии контекста или типа того (дальше всё работало как обычно).
>>105598
Так glGetString(GL_VERSION) говорит, что все норм. Ну да ладно, тут вроде как виноват glewInit().
Сап, аноны. Как лучше: создавать 1 VBO для всей инфы или отдельно для координат, отдельно для цвета?
>>105602
Не должно сильно сказаться на производительности. Я бы делал вместе.
>>105602
И следует ли создавать отдельный VAO для каждого меша?
>>105631 дефайн "лучше"
есть единственно-правильный способ разрабатывать что-угодно (при наличии соответствующей цели, естественно): написать так чтобы работало → если тормозит, определить, что именно больше всего тормозит → соптимизировать это
поэтому пиши так, как удобнее
более того, говорят что производительность vao спорная
http://stackoverflow.com/questions/8923174/opengl-vao-best-practices/8927915#8927915
но всё надо лично вдумчиво перепроверять
Кто-нибудь, подскажите, что я делаю не так.
Я решил пройти эти уроки: http://ogltutor.netau.net/. Но я не могу сделать так, чтобы я мог работать с freeglut на Code::Blocks.
Скачал freeglut 2.8.1 MinGW Package отсюда: http://www.transmissionzero.co.uk/software/freeglut-devel/. Поскольку у меня 64-разрядная Windows, сунул соответствующую .dll в SysWOW64, соответствующие .a файлы сунул в CodeBlocks\MinGW\lib, а заголовочные файлы сунул в CodeBlocks\MinGW\include\GL (там, кстати уже есть glut.h, который весит 21 КБ, и я не знаю стоит ли заменять его на тот glut.h, который идет вместе с freeglut и весит 1 КБ).
Пытаюсь скомпилировать следующее:
#include <GL/freeglut.h>
int main() {return 0;}
Выдает такие ошибки:
undefined reference to `_imp____glutInitWithExit@12'
undefined reference to `_imp____glutCreateWindowWithExit@8'
undefined reference to `_imp____glutCreateMenuWithExit@8'
Кстати, в настройках Code::Blocks стоит компилятор GNU GCC Compiler, а MinGW в выпадающем списке нет, хотя я скачивал версию Code::Blocks именно с MinGW. Так и должно быть?
>>107997
Не подключил либу глута. Алсо, глут - говно мамонта.
>>108002
Так это же freeglut. На сколько я понял, это замена старому глуту.
И как это не подключил? Разве это не то: #include <GL/freeglut.h> ?
>>108002
Все, я понял. Спасибо.
Но заработало только когда я подключил либы для 32-разрядной ОС. Это странно, наверное.
>>108005
Нет. Ничего не работает. Но зато компилится. Сейчас я подключил либы для обеих версий ОС. Когда в SysWOW64 лежит freeglut.dll для 64-разрядной ОС, программа после запуска сразу вылетает с ошибкой 0xc000007b, а когда я начинаю использовать dll для 32-разрядной ОС, то просто вылетает без ошибок.
>>108009
Ах да, сама программа вот:
#include <GL/freeglut.h>
static void RenderSceneCB()
{
glClear(GL_COLOR_BUFFER_BIT);
glutSwapBuffers();
}
static void InitializeGlutCallbacks()
{
glutDisplayFunc(RenderSceneCB);
}
int main(int argc, char** argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE|GLUT_RGBA);
glutInitWindowSize(1024, 768);
glutInitWindowPosition(100, 100);
glutCreateWindow("Tutorial 01");
InitializeGlutCallbacks();
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glutMainLoop();
return 0;
}
>>108009
dll не для ОС, а для программы. Твоя, очевидно, х86. "Вылетает без ошибок" - значит просто завершается. Добавь отладочную печать (дебаггер в вашу швабодную ИДЕ не завезли, как я понял?)
>>108013
Нет. Она именно вылетает. После появления консоли появляется окно с белым цветом (разрешение явно меньше 1024 на 768) на некоторое время, а потом появляется пикрелейтед. То есть все таки ошибка. Наверное, я не правильно выразился.
Добрый вечер, играч. Есть одна точка, трехмерные мировые координаты которой надо сконвертировать в экранные. Открыл спецификацию OpenGL, открыл статьи про матрицы и напидорасил такой код в Mathematica. Как легко можно заметить никакие координаты ни во что не приеобразуются. От изменения z-координаты в матрице V (координаты точки) координаты x и y в результирующей матрице (самая последняя) не меняются. В чем может быть проблема? Плачу нефтью.
>>108015
Проверяй коды ошибок, которые возвращают функции.
>>108017
у тебя на главной диагонали MaxtrixForm[0][0] == MaxtrixForm[1][1] == 1.0, конечно они не будут меняться. ты бы осилил сначала умножение матрицы на вектор на бумаге.
Пытаюсь скомпилировать простую программу с использованием freeglut на MinGW в eclipse.
Он в упор не видит ебаный глут, сука. почему?
Либы подключил.
Description Resource Path Location Type
undefined reference to `_imp____glutInitWithExit@12' cpp_test line 620, external location: d:\s\mingw\include\gl\freeglut_std.h C/C++ Problem
undefined reference to `_imp____glutCreateWindowWithExit@8' cpp_test line 622, external location: d:\s\mingw\include\gl\freeglut_std.h C/C++ Problem
undefined reference to `_imp__glutInitWindowSize@8' main.cpp /cpp_test line 9 C/C++ Problem
undefined reference to `_imp__glutInitContextVersion@8' main.cpp /cpp_test line 10 C/C++ Problem
undefined reference to `_imp__glutInitDisplayMode@4' main.cpp /cpp_test line 8 C/C++ Problem
undefined reference to `_imp__glutInitContextProfile@4' main.cpp /cpp_test line 11 C/C++ Problem
undefined reference to `_imp__glutMainLoop@0' main.cpp /cpp_test line 14 C/C++ Problem
undefined reference to `_imp____glutCreateMenuWithExit@8' cpp_test line 624, external location: d:\s\mingw\include\gl\freeglut_std.h C/C++ Problem
>>108891
Иисусе, ну ведь несколькими постами выше точно такая же проблема, неужели нельзя прочитать? При том, что проблема и ее решение гуглятся за несколько секунд.
>Либы подключил.
А если не подключил?
Впрочем, никогда не помешает напомнить, что ГЛУТ - НЕНУЖНОЕ ГОВНО МАМОНТА.
>>61003
https://www.shadertoy.com/view/MdBGzG
нужна игровая видеокарта
заебатый процедурный ландшафт на относительно компактном шейдере
>>108924
ещё один совершенно опизденевший шейдер
этот чувак просто бог процедурной генерации
https://www.shadertoy.com/view/ldj3Dm
>>108903
Видел, просто до последнего момента ебался не в ту дырку. Оказалось то же самое: MinGW стоял 32-битный, а я либы подключал 64-битные.
>>108904
Я freeglut же подключаю. Правильна ли моя мысль о том, что это потом легко будет переписать, к примеру, на GLFW?
Кстати, не знаю, советовали или нет, но нашел книжонку
Interactive Computer Graphics: A Top-Down Approach with Shader-Based OpenGL - 6th Edition
Нравится.
Парни, нужна помощь.
Начинаю учить ОпенГЛ,
Но не могу скомпилить либы. Не знаю как это делаэться.
Скачал GLFW, через cmake сгенерировал какие то файлы а что дальше делать не пойму.
Подскажите кому не трудно.
>>110837
cmake обычно генерирует файлы проектов. открывай их в своей идешечке и пердолься конпеляй
>>110837
гугли что-то вроде "Установка GLFW в Visual Studio",или лучше "SFML и Visual studio"
Есть тут такие, которые ставили GLFW под MinGW?
Помогите, заебашил что то с помощью Cmake, а что дальше делать не знаю, не могу установить.
>>111480
CMake .
make
make install
Если у тебя cmake в самой минжв и ты собирал через сонсолечку msys'а. Я отдельно с симейком собирал только через кутешечкокриэйтор.
>>111528
Алсо, чуть не забыл. Цмейк отдельной прогой обычно собирает под MSVS, и тогда нужно указывать расположение компилятора g++, make, и прочих приблуд ручками.
>>111529
Хм, я собирал в Cmake под MinGW.
Я просто не пойму что делать с файлами, которые мне дал Cmake. Как из них сделать хедеры и либы?
>>111568
> что делать с файлами
C Makefile'ами что ли? Скармливать mingw32-make'у
Но зачем вообще этой херней заниматься, если можно скачать сразу бинарную сборку?
>>111568
CMake собирает make файлы под твой компилятор. Их нужно запустить, тогда только он тебе соберет либы, выдаст хидеры и т.д.
>>111740
Для ОГЛа четкой считается сейчас GLFW. Но они там меняются, как перчатки. Сегодня одна, завтра другая будет в почете.
У меня возник такой вопрос.
Добрался я до момента, когда надо задать вершины объектов, и понял, что совсем не представляю, каких размеров должны быть объекты.
С одной стороны максимальные и минимальные координаты должны соответствовать границам float. Но я боюсь, что эти координаты могут распидораситься при умножении на матрицу в шейдерах и выйти за границы.
На какие числа я должен ориентироваться при задании вершин, и как зависят эти числа от параметров, которые я задаю при создании матриц позиции наблюдения и перспективы?
В принцип работы этих матриц так и не вникнул. Понимаю только то, что тут он крутит и двигает, а тут растягивает в зависимости от расстояния до камеры.
>>115296
До 10000 норм будет. Очень важно задать границы для near/far clipping plane, от этого зависит правильная работа буфера глубины.
>>115304
Спасибо.
Я правильно понимаю, что могут быть излишне маленькие и излишне большие значения для near/far clipping plane соответственно?
>>115308
Важна разница между ними. По сути, чем она больше, тем меньше разрешение по глубине и могут возникнуть артефакты, если объекты расположены очень близко по оси Z. Это происходит из-за ограничений точности чисел с плавающей точкой.
>>115310
И еще раз спасибо. Будем экспериментировать значит.
>>61003
http://www.g-truc.net/post-0642.html
Кто читал о нововведениях в 5ой версии.
Что хорошего/полезного?
Сап, ананасы. Я - рак, который хочет писать игры на Си, пока изучаю основы Керниган и Ритчи, но уже в скором времени хочу учить графон. Вопрос таков: открытыйGL библиотека для Си или Сиплюсплюс.
Написал же, что рак.
>>118161
>писать игры на Си
Вместо игор у тебя будет хорошая, развесистая лапша. Учи C++ или что-нибудь более совершенное и с ООП.
Алсо кресты легко жрут все сишные библиотеки.
>>118161
>открытыйGL библиотека для Си или Сиплюсплюс
Может быть mesa?
мимо эназер рак
Я имею в виду книгу "The OpenGL Programming Guide". Вроде как это официальный гайд по опенглу, но тут его никто даже не упоминал.
Я читать начал - оказалось очень сложно. Что посоветуешь, анон? Превозмогать или начать с чего-нибудь другого?
>>118203
Вот сайт книги
http://www.opengl-redbook.com/
Обложка пикрелэйтед.
Антуаны, киньте аналог книги "Керниган и Ритчи" для С++.
WebGL.
Как переводить 2d координаты мыши в угол поворота объекта?
Двигаем мышь влево - объект поворачивается по часовой по оси Y и т.п.
Есть ли элегантные решения?
>>118367
У меня такзделано:
float Dx = (-MousePosition.X + PreviosMousePosition.X);
float AngleX = (float)Math.Atan(Dx / Magic);
RotateDirection(AngleX, this.UpVec);
MousePosition - оконые координаты
Magic = 100 - коф. плавности
RotateDirection - может вращать все что угодно, но у меня там камера.
Парни, а почему вот в этом туториале http://ogldev.atspace.co.uk/ зачем-то пилят свои собственные матрицы, функции для умножения, транслейта, поворота, проекции, хотя это все реализовано уже в OpenGL? Те же translate, rotate, scale, glOrtho, gluPerspective и т.д. Конечно, интересно и полезно почитать как это вообще работает, но вот какой смысл все это пилить самому? Если уж что-то понадобится сделать с матрицей самому, то ее всегда можно взять и получить, модифицировать и загрузить обратно. Тогда почему? И, да, всякие ответы уровня "так принято", "делай так, а то будут какие-то сферические ошибки в вакууме", меня не устраивает, хотелось бы конкретики, почему конкретный способ хуже/лучше
>>118691
Там - именно с той целью, чтобы читатель сам понял, как это работает. Самому это делать в общем случае не нужно, используй лучше GLM, например. Но без знания того, как это все на самом деле работает, ты будешь как обезьяна в кабине авиалайнера.
>>118691
Потому что translate, rotate, scale, glOrtho, gluPerspective выкинули из стандарта OpenGL 3.3 и выше.
То есть пользоваться этим по стандарту не рекомендуется.. Хотя это же OpenGL, где важна совместимость со всяким древним хламом, поэтому выпили не до конца, а только обозвали их депрекадет, пользоваться можно дальше.
Причина - шейдеры
Вообщем в серьезном мире все пишут свои матрицы. А для школьных подделок и OGL 2 хватает
>>118696
Ну да, почитать было полезно, я и не спорю
>>118704
Догадывался, что deprecated, но почему? Нет, мне не сложно взять и написать/скопипастить код, работу которого я понимаю. Но вот зачем изобретать велосипеды? Чтробы матрица была доступна шейдеру, надо ведь её всего лишь загрузить, то есть, можно взять, сделать все трансформации, получить матрицу и передать ее с помощью gluniform*, разве не так?
>>118713
>сделать все трансформации, получить матрицу
На glGetMatrix не распространяются обычные пенальти производительности glGet＊, т. к. это состояние клиента, но ты вообще понимаешь, насколько это уродливое решение? Реализация выражений вида матрица＊матрица＊вектор (т. е. всего, кроме самого FFP) будет тормозить, можно забыть о многопоточности и тебе будет очень сложно объяснить пользователю, зачем для матричной математики контекст OpenGL.
Разгадка отсутствия подобных функций одна: OpenGL не занимается математикой, так же, как и, скажем, оконной системой, это не его работа.
Парни, а почему получается так, что плохой OpenGL берет и все, что по Z-координате больше 1 выпиливает?
Я ведь делаю gluPerspective(45, 768.0 / 1024.0, 0.1, 100);
То есть, по логике, должно отсекаться все на расстоянии 100, или нет?
>>118783
Или же надо брать и масштабировать координаты? Тогда зачем вообще. Zfar и Znear?
Смотрите, а правильно ли я понимаю, что glLightfv(GL_LIGHT0, GL_POSITION, lightPosition); ставит источник света в позицию, которая является умножением текущей видовой матрицы на lightPosition? Вообще, правильно ли я понимаю, что когда происходит вызов Draw, то делается что-то вроде Model*View*Projection*Position?
Значит ли это, что, в частности, в gluLookAt мы используем базовые координаты, то есть, когда ось z - вглубь экрана?
Что же тогда делать в случае, если я беру, вращаю изначально оси так, чтобы ось z была вертикальна, а ось y - внутрь экрана, так как так удобнее отображать ландшафт, да и просто как-то привычнее. Короче, как вообще лучше работать с камерой? Да, всякие шейдеры и прочее не использую, учусь на старых версиях OpenGL, в том числе и по NeHe, так понятнее, да и мне пока особо крутого ничего и не надо
>>119042
Поэтому у тебя столько бессмысленной дрочьбы вприсядку. Хочешь работать с современной графикой - используй современные средства, хочешь велосипедить - делай софтовый рендер.
Как нормально запилить отображение ландшафта? Сейчас есть пикрелейтед, проблемы в том, что видна угловатость, особенно при освещении, что очень напрягает.
>>119306
Осспади, нормали вершинам сделай как надо. У тебя они сейчас перпендикулярны кваду, а должны быть перпендикулярны поверхности в той точке, где находится вершина.
>>119306
И чего оно у тебя такое шумное? Текстура травы, что ли? Сделай ей мипмапы и линейную фильтрацию.
>>119306
нормаль перестрой:
v1 v2
o-------------------o
\ /
\ /
\ /
\/
v3
cross(v2-v3, v1-v3)
>>119353
Да, один из вариантов - сложить нормали четырех квадов и нормализовать, т.е. поделить на длину.
Кармакач, меня вот тут терзают смутные вопросы.
Допустим-то я пишу обёртки для биндинга/анбиндинга шейдеров да и не только их.
Как лучше передавать переменную по ссылке или по значению?
Вот, что я имею ввиду:
void BindProgram( GLint program )
{
glBindProgram( program );
}или
void BindProgram( GLint &program )
{
glBindProgram( program );
}Ведь при передаче по значению создаётся копия объекта, а если по ссылке то нет.
Но я, вроде, сейчас допёр. Ведь при копирование адрес этой шейдерной программы в драйвере тоже копирнётся и по сути ничего не меняется.
Может я ошибся в чём-то?
>>122499 Если передаешь по ссылке, то получится лишнее разыменование, причем инт может находиться в какой-нибудь заднице мира, и у тебя будет лишний кеш-промах. Если ты задаешь такие вопросы - не пытайся ничего оптимизировать, будет только хуже. Разберись с архитектурой ПК для начала.
>>119355
не просто сложив (иначе нормаль для всего квада будет одна), а умножив на что-то типа барицентрических координат, только для квада
>>122499
передавать по ссылке нужно если ты передаешь что-то большое, копировавание которого стоит дорого (ссылку стоит при этом сделать константной), либо если функция собирается менять значение переданной по ссылке переменной.
Просто всякую мелочевку лучше передавай по значению. Учитывай, что int& занимает как минимум не меньше места, чем int (на x86/x64).
У меня вопрос, перекликающийся с >>122499.
В Паскале способ передачи const-параметра определяет компилятор. Обычно это означает передачу по значению для <= sizeof(pointer) и по ссылке для всего остального.
А что C++? void(const huge_object) отличается от void(const& huge_object)? Если нет, круто, если да — как добиться вышеназванного поведения? Проверять лень :>
>>122571
С++ такого не делает. Передаешь по значению - будет копировать независимо от размера объекта.
Можно, наверно, намутить какой-нибудь враппер на макросах или шаблонах, чтобы было как в паскале, но этого не нужно делать.
>>122636
> С++
> Можно, наверно, намутить, чтобы было как в паскале
> но этого не нужно делать
Глубокая мудрость.
>>122571
if sizeof(Huge_object) < Threshold {void (const Huge_object)}
if sizeof(Huge_object) >= Threshold {void (const& Huge_object)}
как-то так
>>122636
>этого не нужно делать
Где-то я это уже слышал... Оспаривать не буду, но ты не прав.
>>122712
Погуглил и получилось
template<class T> struct iparam
{
typedef const typename std::conditional<(sizeof(T) > sizeof(void*)), typename std::add_lvalue_reference<T>::type, T>::type type;
};
void test(iparam<huge>::type object);Не то чтобы ЭТО использовать, просто забавно.
>>122571
В 11-ых крестах появилось move semantics с rvalue.
Ананасы, поясните. Я не понимаю почему так.
Вопрос на стаковерфлоу:
http://stackoverflow.com/questions/24235050/opengl-lwjgl-gl-quads-behaves-odd
>>122852
Пиздец.
Короче вот код, если убрать херню с секторами - грузит ЦПУ на 50-60%, с ними - 0%. Вся карта перерисовывается каждый тик.
if (needsRecompile) {
needsRecompile = false;
glNewList(terrainList, GL_COMPILE);
int sectors = 2;
for (int k = 0; k < sectors; k++) {
GRenderEngine.startDrawingTriangles();
for (int i = world.xSize/sectors*k; i < world.xSize/sectors*(k+1); i++) {
for (int j = 0; j < world.ySize; j++) {
Tile t = world.getTile(i, j);
t.renderTile(world, i, j);
}
}
GRenderEngine.stopDrawing();
}
glEndList();
}>>122903
Какой тут нахер профайлер, что он мне даст?
Если я делю отрисовку мира 256х256 (ещё х5 благодаря переходам) на 2 drawCallа - всё хорошо, если рисую одним - он мне уебывает производительность до нуля. Я это и без профайлера вижу. Ты мне лучше обьясни как такое может произойти.
>>61003
Наконец-то слез с freeglut'a на glfw.
Но всё время, по ходу чего-то деланья ну это вообще пушка! возникает чувство какой-то не полноценности.
Мол надо переписать всё на WinApi и проч, не использовать glew, а самому все расширения подключить.
Но утешаю себя тем, что я только пытаюсь учиться и лишняя возня сейчас ни к чему.
>>123578
>не использовать glew, а самому все расширения подключить
Но зачем ? Используя glew ты пишешь код, который не потребуется изменять в будущем при переходе на новые версии OpenGL. Я ещё понимаю мотивацию для избавления от рака вроде glu/glut, но glew-то чем тебе не угодил ?
>>123584
Да всем угодил.
Очень полезно и не нужно кропотливой работой заниматься, а берёшь и сразу занимаешься делом.
Просто некое чувство возникает, что если я сейчас упущу этот этап динамического подключения расширений в будущем могут быть какие нибудь проблемы.
>>123585
Ясно. Я в своё время намучался в ручным подключением расширений и определением их доступности на разных ПК, так что для меня glew - манна небесная. Особенно в сочетании с glewinfo и тупыми юзерами.
Возможно имеет смысл поковырять это в целях изучения, чтобы понимать, что делает glew внутри, но в реальном приложении свой велосипед от новичка врядли будет чем-то лучше.
Привет аноны, подскажите нубу, в чем может быть дело...
Вот ситуация на пикрилейдете - пытаюсь запилить меш с числом вершин больше, чем 2^16 - начинается содомия, меш распидошен, и все тормозит, что на интегрированом ядре ноупбука, что на Нвидии. До 2^16 на каждый меш (и еще примерно 520 на тех двух трахающихся голов от поней) - Нвидия даже не считает это за нагрузку, процессорное видео проседает до сносных 40-45 фпс. (считалка фрапсовская на пике, своя считалка ФПС в командной строке те же числа выдает).
Чет я не очень понимаю, чего оно тупить начинает так. Вроде счетчик вершин и остальные индексы unsigned int, sizeof выдает 4 байта...
юзаю glew и glfw.
Сколько вообще прилично на планы и лендскейпы (и многополигональные модельки) тратить треугольников? Просто может оно нафиг не нужно так много делать для ландшафта и для 99% мешей.
>>123599
> тех двух трахающихся голов от поней
Пошёл нахуй с моих двачей, писькин плевок.
>>123600
Спасибо, пошёл и увидел, что индексный буфер 2 байтный оказался. Переделал в uint все заработало хорошо.
А щито за ярость на поней?
Ох как меня немного раздражает этот OpenGL.
Изъёбы с классами это я про с++ удручают.
Зато через одни функции + namespace всё как-то проще становится чем с классами.
Но стараюсь придерживаться правила, что в будущем функционал заверну в классы.
>>124139
>раздражает этот OpenGL
>Изъёбы с классами
Тебя говнокресты раздражают, с божественным OpenGL все в порядке.
>>124158
Удабливаю этого.
НЕ СМЕЙ ОСКОРБЛЯТЬ ОПЕНГЛ, СУКА.
>>123578
>Мол надо переписать всё на WinApi
>>124207
winapi это такой кусок говна, что к нему может прикасаться только поехавший или незнающий. хуже только mfc.
Бида, котаны.
Есть один пиксельный шейдер на GLSL 330
Суть в том, что в нем идет рендер освещения, вплоть до 25 источников одновременно. Есть поддержка теней, т.е. дополнительно заготовлены семлеры для карт теней. Но бида в том, что в случае точечного освещения нам нужно юзать не sampler2D, а samplerCube. Подумал решить проблему, введя отдельно массив для 2Д и отдельно для кубических карт, но вот незадача...
uniform sampler2D TextureShadowMap[29];
uniform samplerCube TextureShadowCube[29];
Шейдер такой код не принимает, т.к. максимально допустимо лишь 32 слота.
Эму пофиг, что забиндить больше 32 я все ровно не смогу.
В общем, что мне делать? Есть идея рендерить разными шейдерами, но это уже крайний вариант.
Анон, что такое Normalized device coordinates(NDC)? Можно ли без этого обойтись?
>>124436
Ахаха, смотрите, тут говно, которое думает, что программисту математика не нужна. Наглядный пример, лол.
- Дед, смотри, NDC боится.
- Лол.
>>124437
А если по существу - это координаты вида
{ 0..1, 0..1 }
Вместо
{ 0..N, 0..M }, где N и M - разрешение экрана для соответствующих осей.
>>124450
Чтобы на разных экранах были одни и те же пропорции.
Ну очевидно же, епт.
Хочу сделать подгрузку текстур в разных потоках, не могу осилить, как решил эту проблему ты, анон, поделись советом. Каким образом можно это реализовать? В другом потоке функции гл отказываются работать, погуглив понял, что нужно переключать контекст из потока в поток, но каким образом это сделать, как узнать в каком потоке я сейчас работаю и как это синхронизировать?
>>124603
Зачем тебе это? Лучше не лезь, если не разбираешься, только хуже сделаешь.
>>124605
Я реализовал загрузку текстур с харда в фоновом потоке, в основном потоке сейчас подгружаю текстуры, но так дела не делаются, было бы намного удобнее подгружать их в фоновом, а не передавать через потоки.
/gd/, как правильно маппить текстурные координаты на сферу? Делаю как говорят интернеты - результат как на пике.
Код:
printf("====BEGIN====\n");
for( int r = 0; r <= rings; ++r) {
theta = M_PI / 2.0 - (deltaTheta * r);
for( int s = 0; s <= sectors; ++s) {
phi = deltaPhi * s;
float x = radius * cos(theta) * cos(phi);
float y = radius * cos(theta) * sin(phi);
float z = radius * sin(theta);
mesh->vertices.push_back(Point3df(x, y, z));
if( s != sectors && r != rings) {
int lt = s + r * (rings + 1);
int rt = (s + 1) + r * (rings + 1);
int lb = s + (r + 1) * (rings + 1);
int rb = (s + 1) + (r + 1) * (1 + rings);
mesh->faces.push_back(Point3di(lt, rt, lb));
mesh->faces.push_back(Point3di(rt, rb, lb));
}
glm::vec3 p = glm::normalize(glm::vec3(x, y, z));
float u = (float)r / (float)rings;//(atan2(p.x, p.z) / (M_PI * 2.0)) * 0.5f;
float v = (float)s / (float)sectors;//(asin(p.y) / M_PI) + 0.5f;
printf("(%f %f %f) %f %f\n",x, y ,z, u, v);
mesh->textureCoords.push_back(Point2df(u, v));
}
}
>>124620
Где-то напортачил, проверяй каждое действие. Мне влом.
>>124603
Почитай "C++ Concurrency In Action"
Потоки - это такая штука, что используя их без достаточного понимания ты превратишь свою жизнь в ад.
>>124630
Чтобы ты, ленивая сука, сам разобрался в своём говне.
>>124629
Спасибо за книгу.
Сделал таки, через два контекста.
Вашу же мать.
Так лень прочитать туториалы, погуглить?
Я хуею с местных альтфаков, которые даже архитектуру не могу выбрать.
Энивей, первое что читаем:
http://ru.wikipedia.org/wiki/Model-View-Controller - вот так выглядит игра внутре.
Далее:
http://www.lighthouse3d.com/tutorials/
http://www.opengl.org/wiki/Tutorials#OpenGL%5F3.2%5FCore%5FProfile
Про ГЛПУШМАТРИКС и иже с ними ЗАБУДЬТЕ.
Все, иммидиейт мод в далеком прошлом, только шейдеры, только рендертаргеты.
Далее - можете пробовать диферд:
http://www.dennisfx.com/wp-content/uploads/2013/02/Report_DRendering_Toufexis_D.pdf
внутре дохуя линков.
Когда нарисуете первый чайник, можете начинать задавать вопросы.
Google, motherfucker, do you use it?
>>124739
>Firefox не может найти сервер www.lighthouse3d.com
>>124745
А ты откуда? Не грузило с украинского и русского айпишников, а вот с американским все грузится.
>>124751
Интересный способ узнать что человек не с СНГ.
Энивей, обмазывайтесь прокси, ибо сайт годный.
>>124620
Этот код правильный, ошибка была в другом месте.
>>124849
Значит ты втройне мудак. Кто-то должен был мудохаться, проверяя твою пасту, при том что облажался ты в своем коде, который ты не показал. Вот сука, а. Сдохни, гандон.
>>124850
Птому отправлять надо сначала РТФМ и проверять свой код, пользоваться брейкпоинтами и дебаггером.
Нормальный ОГЛ на яве имеется, а не поебень лвжгл?
Аноны подскажите пошагово как использовать несколько буферов для 1 меша. Выкурил много манов и переполнение_стека_точка_ком, но так нихуя и не понял.
Как сейчас сделано:
1) Создаются шейдеры и программа
2) Загружаются позиции аттрибутов
3) Создается меш, в конструкторе инициализируется vao
4) Для каждого аттрибута создается буффер, биндится и glBufferBata
5) Во время отрисовки делаю бинд vao, затем
glBindBuffer, glVertexAttribPointer, glEnableVertexAttribArray для каждого аттрибута,
а затем glDrawArrays
У меня такие предчувствие, что я дичайший наркоман и слишком намудрил, я просто не могу понял принцип работы этих буфферов.
>>124947
http://www.amazon.com/gp/reader/0321902947
В этой книжке всё очень просто разжёвано.
>>124947
shader->load("shader.vs","shader.fs");
shader->compile();
pvmMatrixLocation = glGetUniformLocation(shader->id(), "pvm");
...
Mesh* mesh = new Mesh(vert_arr,ind_arr);
//loop:
shader->Bind();
uint s_id = shader->Id();
glUniformMatrix4fv(pvmMatrixLocation, 1, GL_FALSE, &(pvm[0][0]));
...
glBindVertexArray(vao_ptr->id());
glDrawElements(...);
//end loop
glBindVertexArray(0);
И да, все запихни в классы. И еще - будешь использовать депрекейтед - Консорциум тебя покарает.
>>124968
И да, не понял к чему тут код, который не показывает ни работу с буфферами, ни структуру меша
>>125200
> А что из этого депрекейтед?
http://rghost.ru/56797778
>>125201
Mesh:
///
glGenBuffers(1, &vbo_id[0]);
glBindBuffer(GL_ARRAY_BUFFER, vbo_id[0]);
glBufferData(GL_ARRAY_BUFFER, len*sizeof(Vertex), v_array, GL_STATIC_DRAW);
Так цепляешь любой буфер, которые надо.
Бинд:
glBindBuffer(GL_ARRAY_BUFFER, vbo_id[0]);
glVertexAttribPointer((GLuint)0,//этот 0 - тот же, что и индекс vbo_id
sizeof(Vertex)/sizeof(float), GL_FLOAT, GL_FALSE, sizeof(Vertex), 0);
glEnableVertexAttribArray(0);// тот же индекс
Эту поебень надо забиндить в ВАО:
glBindVertexArray(vao_id[0]);
....
Бинд ВБО, что был раньше
....
glBindVertexArray(0);
Теперь в vao_id[0] висит индекс, который биндится glBindVertexArray(...).
А про очищение памяти погугли, полезно будет.
Теперь тебя интересует как это нарисовать?
А вот так:
http://stackoverflow.com/questions/24267069/opengl-mac-osx-vertex-shader-not-linking-to-fragment-shader
Каждый юниформ локейшн это олололо //этот 0 - тот же, что и индекс vbo_id
Посоны, а как сделать тест глубины при выводе фреймбуфера в текстуру?
Вообще непонятно, вроде ставлю glCullFace(GL_BACK), просто в экране все нормально, а при выводе в текстуру ранее отреднеренный обьект или вершины закрываются более поздними.
>>125402
Ну так включи Z-буфер, а фейс-куллинг это вообще из другой оперы - он просто не отрисовывает треугольники, нормаль которых направлена не в сторону камеры.
>>125403
А разве glEnable(GL_DEPTH_TEST); не создает где-нибудь там внутри Z-буфер по умолчанию?
Или надо создать Z-буффер руками? Типа так:
glGenRenderbuffers(1, &testDepthBuffer);
glBindRenderbuffer(GL_RENDERBUFFER, testDepthBuffer);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, screenw, screenh);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, testDepthBuffer);
>>125404
Внезапно, помогло.
Теперь надо придумать, как бы сделать карту теней - почему-то не работает. В цветную текстуру с позиции камеры света все рендерится нормально, а при попытке затащить в еще одну текстуру буфер глубины и просчете его в шейдере теней нет.
манулы наебывают как всегда и где-то недоговаривают.
>>125405
Ебать дебил.
Тебе анон всегда должен гуглить за тебя?
http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/
Во-вторых - там гомоджиниус спейс, правильно тмапь координаты в камера или ворлд спейс и делай тени.
Ебанашки, я вам туториал по модерн опенгл принес:
http://ogldev.atspace.co.uk/index.html
>>125453
Уважаемые пользователи!
Мы приносим свои извинения, но доступ к запрашиваемому ресурсу ограничен.
>>125458
Это у тебя говнопровайдер какой-то. Всё работает.
>>125481
Ебанашка, глат - используется как АПИ для менеджмента окна и т.д.
Так чем не модерн? Тем, что не писали класс контекста под каждую платформу?
>>125531
>GLFW
Враппер вокруг GLEW + платформ-депендент контексты.
Как либа - хорош, но он не для обучения. Это как учится водить машину на симуляторе.
Глат хорош тем, что прячет только самое противное - создание окна и, если ты сам этого захочешь, коллбеки инпута. А трахаться с рендертаргетами/текстурами/гаммакорекцией/да_и_вообще_со_всем придется ручками.
А то вырастают "араграмеры", которые даже не знают что шейдер - эта программа для ГПУ а не ебаные проперти материала из 3ДМакса.
>>125532
Да, под глатом имею ввиду фриглат. Но это, я думаю, очевидно.
Я так понимаю в треде хочет возникнуть нечто, кто считает, что для всего надо использовать либы и врапперы. Отчасти он прав, но надо же мне тоже выебнуться
Так вот, кто хочет быть ТРУ И проебать свое время, но зато понять для вас вот этот линк: http://www.swiftless.com/tutorials/opengl4/1-opengl-window.html
Наслаждайтесь.
Поясните пазязя: чем отличается GL_DYNAMIC_DRAW от GL_STREAM_DRAW? Когда что юзать?
>>125544
GL_DYNAMIC_DRAW - очень часто изменяется VBO и используется много раз.
GL_STREAM_DRAW - изменяется один раз и используется несколько раз.
Это не более, чем подсказки OpenGL.
Я только что перевел свою систему рендера тайлов в редакторе (нужна статичность + динамика для редактирования ландшафта), пробовал оба режима, разницы довольно мало при отрисовке ~200к динамических квадов, вершины которых статичны. Меняется только UV. И то планирую его в шейдер ебнуть, чтобы память не захламлять, если не сильно повредить производительности. Мне просто нужен быстрей рендер большой сцены, это моё эго играет. Меня бесит когда мой редактор лагает, пусть ты и смотришь в реалтайме на 65к тайлов с переходами и меняешь за раз ~200 из них.
>>125546
Я решал схожую проблему, но для изменения цвета.
Все сидит в ВБО/ВАО, меняется только один массив, потом ребиндится ВАО:
glDeleteBuffers(...)
glGenBuffers(...)
glBindBuffer(...)
glBufferData(...)
Дальше ребиндишь полностью ВАО.
Выигрыш по сравнению с полным ребиндом меша - астрономический. Юзаю статик драв.
>>125546
> GL_STREAM_DRAW - изменяется один раз и используется несколько раз.
В смысле один раз за кадр? Или вообще? Чем оно от GL_STATIC_DRAW отличается?
Я правильно понимаю:
динамика -> статика
GL_DYNAMIC_DRAW -> GL_STREAM_DRAW -> GL_STATIC_DRAW
?
>>125547
Я не так делаю.
У меня пока костылем стоит, я для проверки юзал.
Чанки хранят в себе один статичный на всех VBO вершин, который не трогается и юзается для отрисовки вершин чанка (любого, очевидно я задаю перед этим смещение матрицей).
Потом они хранят 4 (костыль) VBO для вершин. Я на хабре описывал статью автотайлинга, вот они хранят квады с текстурами, координаты вернее. При клике\драге мышкой я просто вычисляю координаты мыши в карте тайлов, потом узнаю нужный индекс в VBO:
/*
* float (4 bytes) * 4 points of quad * 2 dimensions (x, y)
*/
int index = 32*tx + 32*(Chunk.XSIZE*ty);
(координаты чанка) tx, ty = x\y (глобальные координаты) % (X\Y)SIZE
А потом туда через glBufferSubData помещаю новый квад из 8 флоатов. Вот так вот.
А 4 VBO там для переходов.
>>125546
>быстрей рендер большой сцены
Всеравно будешь группировать, так что с 5-10 к ВАО будет.
У тебя есть 2 варианта - дерево с группировкой всех ВБО в один ВАО на некотором уровне или же просто разбей пространство на квадратики и молись, что плотность будет однородная и сказать, что каждый квадратих - один большой ВАО. Это эффективнее на относительно малых сценах и модификации объектов в ограниченном пространстве.
>>125552
Я выше уже описал, у меня везде одномерные чанки, у меня всё уже готово и работает.
Мне только перевести систему переходов в человечный код из костыльно-тестового и всё.
>>125551
Так glBufferSubData - следующий шаг от моего примера, так оно и должно быть, если ты можешь гарантировать, что данные всегда меняются последовательно не забывай, что вызов команд тоже стоит времени.
А насчет 4 ВБО не понял, нахрена? Типа ололо AOS?
>>125551
>А потом туда через glBufferSubData помещаю новый квад из 8 флоатов. Вот так вот.
А 4 VBO там для переходов.
Эк меня распидорасило, я так быстро всё писал, что сам теперь путаюсь в логике своего предложения.
Простите, аноны, меня за моё построение речевых оборотов.
>>125556
>А насчет 4 ВБО не понял, нахрена? Типа ололо AOS?
http://habrahabr.ru/post/227205/
Там короче у меня в одном инте хранятся 4 перехода между тайлами:
первые 4 бита - ID тайла, последние 4 - ID перехода, по которому вычисляется индекс текстуры. Т.е. 8 бит на один переход - 32 бита на 4.
И я это в таком виде и кинул опенглу, у него 4 VBOшки, которые хранят нужные координаты из атласа.
Лучше оставить это вершинному шейдеру, да? Мне нужно, чтобы он в реалтайме справлялся с 240к квадами за тик и это без нагрузки на ЦПУ, и желательно, сильной нагрузки на ГПУ.
В игре мне такое, конечно, ни к чему будет.
>>125549
Динамик - будешь часто менять и часто использовать между изменениями.
Стрим - часто менять и использовать пару раз между изменениями. тут запись быстрее чем в динамике, но медленнее чтение, ибо оно почти постоянно буферится по новой.
Статик - когда ты хочешь быстро и эффективно рисовать.
Мы выше с аноном его и используем, ибо меняем мало, но рисуем много, дешевле пересоздать чанку со статиком.
>>125560
Время нового OGL треда, этот уже не бампается.
Да-да, я сам ничего не хочу и не буду. Сделайте, кто-нибудь.
только понял
>>125558
О, неплохо.
Я такого не решал, ибо со спрайтами сильно не работаю, но когда делал бампмап для терейна.
Что ты можешь сделать - хранить офсет бамп-тайла относительно глобальной сетки, и считать в вершинном шейдере, так что да
>Лучше оставить это вершинному шейдеру
>>125562
Разверну - есть позиция текущего тайла, на этом тайле есть линк на бамп, который ты там хочешь отрисовать. С ним ты сохраняешь офсет на левый верхний угол относитльно ВЛУ самого тайла.
Или сделать по-феншую и делать чистый бампмаппинг.
Но тогда тебе придется менять архитектуру, как я понял
>>125565
Гм, хуйню сказал, чистый бамп тебе не подходит.
Инстансед драв пробывал?
>>125565
Ясно, посмотрим, если не будет лень - перепишу на шейдер.
>>125567
>Инстансед драв пробывал?
Смотрел это, но одного статичного VBO на вертексы мне хватает по горло.
Кстати да, про бамп я не вьехал, причем он тут.
>>125571
То, что ты делаешь - похоже на бамп маппинг, но ты хочешь физически задавать позицию каждого бампа, так что тебе это не подходит.
Насчет моего предложения - если есть некое максимальное кол-во бампов, что ты можешь использовать на тайле, и оно малое - делаешь просто большой "вертекс" где сохраняешь офсет+айди бампа. Это позволит тебе иметь бамп де угодно. Но ценою в увеличении потребления памяти.
Так, не спешите делать новый тред, я шапку запилю.
>>125577
http://acko.net/files/fullfrontal/fullfrontal/webglmath/online.html
Вот тебе прикольный линк, авось пригодится.
>>125577
Погоди, не делай тред, а сюда кинь шапку.
Может быть есть добавить и всякое такое.
>>125581
Блин. Просто дописывайте туда пока, следующий запилим уже со всем, что найдем.
>>125560
> тут запись быстрее чем в динамике, но медленнее чтение, ибо оно почти постоянно буферится по новой
Вот так понятно.
Пасяб.
>>125587
Ну, не совсем.
Местные олологеймдевы должны понять, что без математики они хуй что нарисуют. Так что шапка нужна, и как можно полнее.
Альзо,
http://2ch.hk/gd/res/125580.html
Тред для новичков и профессионалов. Помогаем ньюфагам, анализируем код олдфагов. Кидаем полезные ссылки, пишем свои истории. Хвастаемся успешными проектами. Кидаем годную литературу.