Двач.hk не отвечает.
Вы видите копию треда, сохраненную 30 октября 2015 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
27 Кб, 475x457
OpenGL thread #141146 В конец треда | Веб
Старый тонет, пора делать новый.

Спрашиваем, сами же решаем проблему, сами же отписываемся. Постим книжечки, гуглим, учим математику. Посылаем нахуй за легаси.
Добро пожаловать.

http://arhivach.org/thread/28624/ - Первый
http://arhivach.org/thread/47586/ - Второй
Доки:
https://www.opengl.org/sdk/docs/man2/ - OpenGL 2.1
https://www.opengl.org/sdk/docs/man3/ - OpenGL 3.3
https://www.opengl.org/sdk/docs/man4/ - OpenGL 4.5
https://developer.nvidia.com/opengl
https://www.opengl.org/wiki/Main_Page

Туториалы:
http://en.wikibooks.org/wiki/Category:OpenGL_Programming
http://www.gametutorials.com/tutorials/opengl-tutorials/
http://www.opengl-tutorial.org/
http://www.tomdalling.com/blog/
https://code.google.com/p/gl33lessons/ -
http://steps3d.narod.ru/articles.html - много статей по расширениям
http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/ - GLSL туториалы
http://ogltutor.netau.net/index.html
http://www.arcsynthesis.org/gltut/

Книги:
https://www.dropbox.com/s/ct7a7byynnbm5qf/0123750792Rendering.pdf
http://mrelusive.com/books/books.html - большой список книг по геймдеву
http://rutracker.org/forum/viewtopic.php?t=625086 - GPG 1-6 части
http://www.amazon.com/Computing-Gems-Edition-Applications-Series/dp/0123859638
http://www.amazon.com/gp/reader/0321902947 - Superbible
http://kickass.so/game-engine-architecture-second-edition-2014-t9574312.html - Game Engine Architecture

Maths:
http://www.amazon.com/Math-Primer-Graphics-Development-Edition/dp/1568817231/
http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Edition/dp/1435458869

по GLSL:
http://www.amazon.com/OpenGL-Development-Cookbook-Muhammad-Movania/dp/1849695040/
http://www.amazon.com/OpenGL-Shading-Language-Cookbook-Edition/dp/1782167021/

Презентации, слайды:
Красивая вводная презентация по основам графики со всякой интерактивщиной:
http://acko.net/files/fullfrontal/fullfrontal/webglmath/online.html

http://www.slideshare.net/TiagoAlexSousa/secrets-of-cryengine-3-graphics-technology
http://www.slideshare.net/cellperformance/data-oriented-design-and-c - Data-oriented Design
https://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/

Надеюсь, ничего не забыл.
>>141149>>141290>>141858>>141864>>148724>>153858>>156745>>158911>>160458>>172800
#2 #141149
>>141146
Что же мы рисуем?
http://en.wikipedia.org/wiki/Rendering_equation
http://en.wikipedia.org/wiki/Bidirectional_reflectance_distribution_function

Математика онлаен:
http://www.essentialmath.com/tutorial.htm
http://chortle.ccsu.edu/vectorlessons/vectorindex.html

Математическая библиотека:
http://glm.g-truc.net/

Библиотеки для создания контекста:
http://www.glfw.org/
http://freeglut.sourceforge.net/

Подключение расширений:
http://glew.sourceforge.net/

Ещё тюториалы:
http://code.google.com/p/gl33lessons/
http://vbomesh.blogspot.ru/
https://developer.nvidia.com/opengl
http://ogldev.atspace.co.uk/
http://www.tomdalling.com/blog/

ТЕХНОЛОГИИ

Диферд
http://www.neuroproductions.be/opengl/making-a-3d-game-with-opengl-deferred-shading-and-stuff/
http://onlygraphix.com/2014/01/18/oglplus-tutorialdeferred-renderer/
http://steps3d.narod.ru/tutorials/lpp-tutorial.html
http://steps3d.narod.ru/tutorials/ds-tutorial.html

ССАО/ССДО
http://habrahabr.ru/post/204260/
http://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf

Инстансинг
http://ogldev.atspace.co.uk/www/tutorial33/tutorial33.html
https://www.youtube.com/watch?v=dMVhGJkALW0

Двигло
http://www.slideshare.net/cellperformance/data-oriented-design-and-c
http://www.slideshare.net/TiagoAlexSousa/secrets-of-cryengine-3-graphics-technology

Нарисовать текст в ОГЛ
http://jonmacey.blogspot.de/2011/10/text-rendering-using-opengl-32.html

Добавочка
#2 #141149
>>141146
Что же мы рисуем?
http://en.wikipedia.org/wiki/Rendering_equation
http://en.wikipedia.org/wiki/Bidirectional_reflectance_distribution_function

Математика онлаен:
http://www.essentialmath.com/tutorial.htm
http://chortle.ccsu.edu/vectorlessons/vectorindex.html

Математическая библиотека:
http://glm.g-truc.net/

Библиотеки для создания контекста:
http://www.glfw.org/
http://freeglut.sourceforge.net/

Подключение расширений:
http://glew.sourceforge.net/

Ещё тюториалы:
http://code.google.com/p/gl33lessons/
http://vbomesh.blogspot.ru/
https://developer.nvidia.com/opengl
http://ogldev.atspace.co.uk/
http://www.tomdalling.com/blog/

ТЕХНОЛОГИИ

Диферд
http://www.neuroproductions.be/opengl/making-a-3d-game-with-opengl-deferred-shading-and-stuff/
http://onlygraphix.com/2014/01/18/oglplus-tutorialdeferred-renderer/
http://steps3d.narod.ru/tutorials/lpp-tutorial.html
http://steps3d.narod.ru/tutorials/ds-tutorial.html

ССАО/ССДО
http://habrahabr.ru/post/204260/
http://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf

Инстансинг
http://ogldev.atspace.co.uk/www/tutorial33/tutorial33.html
https://www.youtube.com/watch?v=dMVhGJkALW0

Двигло
http://www.slideshare.net/cellperformance/data-oriented-design-and-c
http://www.slideshare.net/TiagoAlexSousa/secrets-of-cryengine-3-graphics-technology

Нарисовать текст в ОГЛ
http://jonmacey.blogspot.de/2011/10/text-rendering-using-opengl-32.html

Добавочка
>>141171
138 Кб, 1280x720
#3 #141161
Освящаю. Остальные пока что рендерятся.
#4 #141171
>>141149
Ты бы хоть шапку почитал бы, а так спасибо.
#5 #141184
Аноны, такой вопрос: создаю пустую текстуру, потом уже загружаю туда данные через subimage. Что будет в пустых областях?
>>141186
#6 #141186
>>141184
то что записал, то и будет. Если ничего не записывал, будет мусор, записывай нули
>>141187
#7 #141187
>>141186
Спасибо.
#8 #141214
Попробовал библиотеку stb.
https://github.com/nothings/stb
Очень годная.
Автора её Кармак готов пригласить в Окусул. Так что тру.
25 Кб, 748x633
#9 #141276
Гуй перекрывается мешем, что делать?
>>141278>>141287
#10 #141278
>>141276
Рендери отдельно сцену и отдельно гуй в картинку с прозрачностью. Потом мерджи обе картинки в одну, как в фотошопе.
мимо вообще ниибу в огл
#11 #141287
>>141276
Нонсенс.
Рисуешь сцену.
Выключаешь з-тест.
Рисуешь гуй.

Это не первый тупорылый вопрос в ОГЛ тредах, зачем ты это делаешь?
>>141291
#13 #141291
>>141287
Вот я ебнутый, был же уверен, что отключил, спасибо, няш :3.
#14 #141319
Сап, ананасы. В общем, проблема такая.
Когда пробовал и изучал гл по началу, то для вершин, текстурных координат заводил новый vbo и, соответственно, с атрибутами у меня было меньше возни. Ну то есть для вершин, текстурных координат был свой vbo и начало данных в атрибутах я ставил 0.
Проблема такая. Как в один буфер поместить все данные и выставить атрибуты правильно?
>>141350
#15 #141350
>>141319
Разобрался.
Тащемта, нужно в начале узнать сколько данных в байтах нам надо засунуть в буфер, но не заполнять его данными, а потом через BufferSubData пихать.
Примерно так:

offset = 0;
BufferData( sizeof( position ) + sizeof( tex_coord ), null );
BufferSubData( sizeof( position ), position, offset );
offset += sizeof( position );
BufferSubData( sizeof( tex_coord ), tex_coord, offset );

и тд
Новичек #16 #141454
Имеется задача: нарисовать в 3d ландшафт. Я реализовал это с помощью старых glBegin/glEnd/glRotate, вот это всё. (Ну, отрисовал треугольниками карту высот)
Теперь решил переделать с шейдерами и добавить текстуры.
Собственно вопросы:
1) Мне теперь придется самому реализовывать все повороты/увеличения с помощью матриц?
2) Как лучше всего отрисовывать ландшафт?(Имеется карта высот)
3) Какую версию OpenGL юзать? Я читал, в 4+ там появились какие-то еще шейдеры. Они мне нужны вообще?
4) Как мне научиться писать шейдеры? Что лучше прочитать? В основном попадаются просто абсолютно бесполезные статьи, из которых ничего не понятно.

Я понимаю, что вопросы, наверное, очень глупые, но я я буду благодарен, если кто-то пояснит.
>>141456>>141464
#17 #141456
>>141454
Лучше загугли готовое, разберись и перепеши с нуля. Велик шанс, что ты забудешь какую-нибудь фигню и потом будешь всем мозги ебать.
http://www.mbsoftworks.sk/index.php?page=tutorials&series=1&tutorial=24
>>141459
#18 #141459
>>141456
Ладно, я подумаю. Спасибо.
#19 #141464
>>141454
В отрисовке ландшафта главное запилить алгоритм LOD, а это задача по сложнее чем просто нарисовать треугольники по карте, особенно если нужен большой ландшафт и качество.
61 Кб, 320x240
VBO #20 #141470
Пасаны, я, как узнал про VBO, помешался на нём совершенно. Теперь мне думается, что все объекты даже небо, даже Аллах должны быть сохранены как вершинные буферные объекты, чтобы повысить скорость отрисовки до небес нахуй.
Неужели в геймдеве используют только это? glBegin и glEnd же устаревшее говно, которое уже давно никому не сдалось.
У меня сомнения насчёт эффективности VBO, когда дело касается динамических объектов. На статичную карту-то похуй, а вот персонажей я захочу сделать двигающихся или там кубик повертеть, мне же придётся сперва себя на хую вертеть и в бубен бить, долго ебаться с установкой всяких указателей на нужные вершины. Развейте мои сомнения насчёт затратности VBO в динамике.
И что делать, если я хочу для 1000 кубов создать уникальный VBO, а потом крутить, вертеть кубы, хехей?!
Какой максимум на количество VBO объектов определён? На opengl.org что-то читал про 4Mb, но я так понял, это рекомендуемый максимум только на один объект VBO?
>>141474>>141480>>141488
#21 #141474
>>141470
Что-то я проиграл с твоего поста.
Алсо, я вот изучаю код Дума 3, ну который бфг - он переписан на гл 3.3.
Так вот я там заметил класс который хранит данные для уровня, ну то есть та геометрия которая не меняется и для данных динамических - противники, оружие и тд. Может быть это оно.
Но я вот я уже давно их изучаю да и с гл тоже не первый день, но всё равно не понимаю многого оттуда.
https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/VertexCache.h#L75
#22 #141480
>>141470

>И что делать, если я хочу для 1000 кубов


Рисуешь куб 1000 раз с 1000 разных матриц.

>максимум только на один объект VBO


Да.

>что все объекты должны быть сохранены как вершинные буферные объекты


А кроме ВБО нету способа что-либо нарисовать в ОГЛ 3.2+. ГлБуферСабЭррей тееб в помощ.
#23 #141481
Запутался с матрицами совершенно. Есть сцена, с расположенными на ней объектами. Меняется позиция и угол вращения камеры. Код http://pastebin.com/a5sSYqZ0

Вращение объектов происходит относительно глобального центра, а не вокруг собственной оси. Пробовал перемещать позицию игрока в центр и сбрасывать угол камеры, потом крутить объект, перемещать его и возвращать обратно позицию игрока и угол камеры. В итоге не работало. Не понимаю логики работы.
>>141514
#24 #141488
>>141470
В Super Bible 6 издании на странице 125 твой ответ.
#25 #141511
Начал изучать opengl 3.3 и столкнулся с непоняткой. Читаю сейчас
http://www.gamedev.ru/community/ogl/articles/lesson02
и в конце, когда делается рендеринг я вижу вот такую строку
glDrawArrays(GL_TRIANGLES, 0, vertexCount);
Как определяется что именно отрисовывается? Ну например у меня есть массив не из 3, а из 9 элементов. Как они нарисуются? Что мне сделать, чтобы нарисовать, к примеру, куб, который строится по 4 точкам?
>>141513
#26 #141513
>>141511

>Как определяется что именно отрисовывается


glBindBuffer(GL_ARRAY_BUFFER, meshVBO);

>4 точкам


Индексы.
>>141515
#27 #141514
>>141481
Сначала поворачиваешь, потом мапишь из локал в ворлд, ан е как ты - сначала в ворлд потом ротейт.
#28 #141515
>>141513
Треугольники рисуются просто поочереди? То-есть 0, 1, 2 элемент - первый треугольник и 3, 4, 5 - второй? Просто по-порядку каждые 3 вершины?
>>141516>>141517
#29 #141516
>>141515

>просто поочереди


Почти всегда - нет. Ибо сейчас унифицированые процессоры, так что пара сотен треугольников за раз.
#30 #141517
>>141515
Всё, почитал про индексы. Тогда получается, мне нужно создавать еще огромный массив, в котором будут индексы?
>>141518
#31 #141518
>>141517
Смотри.
Есть куб, у него 8 вершин.
Но если делать его треугольниками, то будет 66 = 36 вершин.
36 вершин == 363 == 108 флоатов == 432 байта.

Если делать индексами - будет 8 вершин == 24 флоата
и 123 == 36 инедксов == 36 уинта == 72 байта.
В сумме - 96 байт против 432.
>>141519>>141520>>141521
#32 #141519
>>141518
Умножения проебались. Слава абу, блядь.
>>141522
#33 #141520
>>141518
И я там не уинты, а ушорты поситал, но тебе пока хватит 65к индексов.
#34 #141521
>>141518
Окей. Я понял.
А что такое 363 и 123? Как ты перешел к ним?
>>141522
#35 #141522
>>141521
>>141519
ок
#36 #141858
>>141146
Кто-нибудь может объяснить почему сглаженные полигоны делаются с помощью какого-то там мультисэмплинга, а не просто алгоритмом Ву? Чего я не улавливаю?
>>141868>>141872>>141878
246 Кб, 1147x1024
#37 #141864
>>141146
Сап, гдач.
Начал читать вторую книгу из раздела Maths.
Вначале книги говорят о том что читатель должен знать как строятся модели из вершин и полигонов. Так вот, я этого не знаю, что почитать кроме страницы в википедии? Вообще стоит ли мне это изучать, если я не делал ничего кроме тетриса в готовом движке? Мне 21, из Дефолт-сити, нехиккан и я сижу дома, так что время свободное есть, и могу в общение. Наверно таких как я миллион.
>>141865
#38 #141865
>>141864

>знать как строятся модели из вершин и полигонов


Чего там знать то?
>>141867
#39 #141867
>>141865
Ну я тупой. Я хоть и переиграл в кучу игр и немного умею в программирование, не совсем понимаю что значит это. Есть вершины в модели и они соединены полигонами, которые представляют примитивные фигуры?
>>141869>>141876
sage #40 #141868
>>141858

>алгоритмом Ву


Для каждого внешнего пикселя полигона нужно посчитать растояние до его ближайшей прямой контура полигона и сделать его полупрозрачным. А если считать что полики рисуются в несколько ядер по сетке, то вангую ошибки смешивания полупрозрачных контуров.
А он более затратен, чем простая отрисовка в больше разрешении и масштаб с мультисемплингом.
#41 #141869
>>141867

>они соединены полигонами


Полигоны состоят из вершин.
Все иди читать совою Maths.
#42 #141872
>>141858
Студент 1 курса узнал про алгоритмы арстеризации? Окай, лет через 10 и до шейдеров дойдешь такими темпами.
#43 #141876
>>141867
Представить что такое полигон - гугли "карта высот".
Представить что такое 3Д фигура - нарисуй куб.
Понять - гугли "постоение моделей из треугольников."
#44 #141878
>>141858
А какое значение З-буфера ты запишешь в пиксель с полутоном?
139 Кб, 800x600
#45 #141995
Сап, gl-ушаки, как пользовать долбаный индексированый VBO?
Есть одна obj модель из которой я вытаскиваю всякие потроха в виде:
vector<short> v = {v1.x, v1.y, v1.z, v2.x ... }
vector<short> n = {n1.x, n1.y, n1.z, n2.x ... }
vector<unsigned short> t = {t1.u, t1.v, t2.y ... }
И индексы:
vector<unsigned short> e = {V1, N1, T1, V2, N2, T2 ... }

Рисую так:
[CODE]
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, mdl->VertexBuffer());
glVertexAttribPointer(0, 3, GL_SHORT, GL_TRUE, 0, nullptr);

glEnableVertexAttribArray(1);
glBindBuffer(GL_ARRAY_BUFFER, mdl->UVBuffer());
glVertexAttribPointer(1, 2, GL_UNSIGNED_SHORT, GL_TRUE, 0, nullptr);

glEnableVertexAttribArray(2);
glBindBuffer(GL_ARRAY_BUFFER, mdl->NormalBuffer());
glVertexAttribPointer(2, 3, GL_SHORT, GL_TRUE, 0, nullptr);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mdl->ElementBuffer());
glDrawElements(GL_TRIANGLES, mdl->ElementsSize(), GL_UNSIGNED_SHORT, nullptr);
[/CODE]

И получаю пикрелейтед. Что делаю не так?
139 Кб, 800x600
#45 #141995
Сап, gl-ушаки, как пользовать долбаный индексированый VBO?
Есть одна obj модель из которой я вытаскиваю всякие потроха в виде:
vector<short> v = {v1.x, v1.y, v1.z, v2.x ... }
vector<short> n = {n1.x, n1.y, n1.z, n2.x ... }
vector<unsigned short> t = {t1.u, t1.v, t2.y ... }
И индексы:
vector<unsigned short> e = {V1, N1, T1, V2, N2, T2 ... }

Рисую так:
[CODE]
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, mdl->VertexBuffer());
glVertexAttribPointer(0, 3, GL_SHORT, GL_TRUE, 0, nullptr);

glEnableVertexAttribArray(1);
glBindBuffer(GL_ARRAY_BUFFER, mdl->UVBuffer());
glVertexAttribPointer(1, 2, GL_UNSIGNED_SHORT, GL_TRUE, 0, nullptr);

glEnableVertexAttribArray(2);
glBindBuffer(GL_ARRAY_BUFFER, mdl->NormalBuffer());
glVertexAttribPointer(2, 3, GL_SHORT, GL_TRUE, 0, nullptr);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mdl->ElementBuffer());
glDrawElements(GL_TRIANGLES, mdl->ElementsSize(), GL_UNSIGNED_SHORT, nullptr);
[/CODE]

И получаю пикрелейтед. Что делаю не так?
>>141998>>142091
#46 #141998
>>141995
И буферы генерирую так:
[CODE]
glGenBuffers(1, &_vertexBuffer);
glBindBuffer(GL_ARRAY_BUFFER, _vertexBuffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(short) _vertexes.size(), &_vertexes[0], GL_STATIC_DRAW);

glGenBuffers(1, &_uvBuffer);
glBindBuffer(GL_ARRAY_BUFFER, _uvBuffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(unsigned short) _uvs.size(), &_uvs[0], GL_STATIC_DRAW);

glGenBuffers(1, &_normalBuffer);
glBindBuffer(GL_ARRAY_BUFFER, _normalBuffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(short) _normals.size(), &_normals[0], GL_STATIC_DRAW);

glGenBuffers(1, &_elementBuffer);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, _elementBuffer);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned short) _elements.size(), &_elements[0], GL_STATIC_DRAW);
[/CODE]
>>142003>>142004
#47 #142003
>>141998
struct vertex
{
float[3] v;
float[3] n;
float[2] t;
}
....
glBufferData(GL_ARRAY_BUFFER, sizeof(vertex) _vertexes.size(), &_vertexes[0], GL_STATIC_DRAW);
>>142006
#48 #142004
>>141998
or
struct point
{
float[3] v;
}
struct normal
{
float[3] v;
}
struct uv
{
float[2] v;
}
....
glBufferData(GL_ARRAY_BUFFER, sizeof(point) _vertexes.size(), &_vertexes[0], GL_STATIC_DRAW);
...
glBufferData(GL_ARRAY_BUFFER, sizeof(normal) _normals.size(), &_normals[0], GL_STATIC_DRAW);
>>142006
#49 #142006
>>142003>>142004
Не до конца понимаю чем оно отличается от того что у меня.
В https://www.opengl.org/wiki/Vertex_Specification_Best_Practices#Formatting_VBO_Data
Написано, что что индексы можно представлять в разных видах (VVVV) (NNNN) (CCCC), (VVVVNNNNCCCC) или (VNCVNCVNCVNC). Как передать openGL какого формата данные я в него заливаю?
>>142008
#50 #142008
>>142006
vector<unsigned short> e = {V1, N1, T1, V2, N2, T2 ... }
That's a bullshit.
vector<unsigned short> e = {e1,e2,e3,.... }
>>142010>>142012
#52 #142012
>>142008
Кжц, это прав.
Индекс это всего одно число.
Вершина (v[e], n[e], t[e])
#53 #142023
http://simonschreibt.de/gat/renderhell/
Вот тут годно и наглядно поясняется принцип рендеринга.
Думаю стоит добавить в шапку.
>>142024>>142028>>143501>>143634
#54 #142024
>>142023
Да, годнота.
#55 #142028
>>142023
Креативщик ёбаный.
>>142029
sage #56 #142029
>>142028
Чего-то не нравится?
#57 #142040
Ананасы, как сделать камеру при помощи glm?
http://opengl-tutorial.blogspot.ru/p/6.html
Пытался вот по этому уроку делать. Попробовал сделать без движения, просто обзор мышкой. Вышла хуита даже не похожая на камеру.
Начинать изучение гла я начинал вот по этим урокам:
https://code.google.com/p/gl33lessons/wiki/Lesson04
И вот дошёл до 4 и там как раз камера, но используется своя мат библиотека и соответственно функции немного различаются. Например поворот матрицы.
>>142097
#58 #142062
Ребяты, хочу пилить двумерный движок, в шапке не нашел ни одной статьи и по теме. Прочел пару книжек про ОпенГЛ, но ничего там блядь, про написание графических движков нет.

Знаю про вертексы, знаю про текстуры. Разжился знаниями по ВБО. Хочу собрать их в хорошую, но не шибко сложную архитектуру.

Пробовал читать исходники, но они часто бывают наполнены магическими числами, которые ничего не объясняют.

Хочется какую-нибудь статейку хотя бы с разбором внутреннего содержимого двигла, так чтобы хотя бы с куском теории о том как и зачем все это было написано.
>>142075
#59 #142075
>>142062
всё уже придумано до тебя
>>142076
#60 #142076
>>142075
Ну началось. Ясен хуй, что все придумано до меня, но я хочу знать, что же там блядь, придумано. Я хочу разбираться в том, что там внутри, как оно работает и почему оно так работает.

Конечно, давайте опять пообсасываем тему того, что нужно использовать движки.

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

Как же надоели эти кукарекания.
>>142077>>142078>>142080
#61 #142077
>>142076
Почитай исходники опен-сорцного движка.
#62 #142078
>>142076
В шапке же ссылки.

вот книжка
http://kickass.so/game-engine-architecture-second-edition-2014-t9574312.html

вот сайт не из шапки
http://gameprogrammingpatterns.com/

все же написано, глаза разуть лень. гугл есть. или ты думаешь тебе первому в истории надо разобраться как же движок работает.
>>142084
#63 #142080
>>142076
Так ты используешь физический движок юнити для арканоида?!
>>142082
#64 #142082
>>142080
какая пизда только тебя, блядь, выродила, такого тупого
>>142086
#65 #142084
>>142078
Не лень. Я прошелся по ссылкам.

Название "Game Engine Architecture" мало говорит о том, что речь пойдет именно о разработке графического движка.

Не говоря уже о "Game Programming Patterns" ведь паттерны в играх встречаются тоже разные.

Но как бы там ни было, спасибо.
#66 #142086
>>142082

>сказал долбоебик после своего истеричного нелогичного высера про арканоид

#67 #142091
Снова выхожу на связь со своими ВБО >>141995-кун. Пересмотрел тутор с opengl-tutorial.org и приуныл. Если я правильно понял, индексируются только одинаковые комплексы атрибутов вершин [координаты, нормаль, текстурные координаты]. Получается, что если даже если на каждую вершину натягивается только одна текстурная координата, из-за нормалей (которые одинаковы для треугольников, а не вершин) эти комплексы будут разные. После индексации мы получим массивы проиндексированных атрибутов, которые по размеру равны неиндексированным. Плюс перерасход памяти на массив индексов.
Может можно как-нибудь привязать атрибуты раздельно?
ARB_vertex_attrib_binding вроде только с opengl 4.2, а моя говнокарта может только в 3.3.
>>142096
#68 #142096
>>142091
Ты нихуя не понял, читай еще.
Я тебе уже пояснил и с кубиком и хуюбиком и тыкнул в то, что у тебя структуры ВБО - говно. Короче, пиздуй читать еще.
>>142110
#69 #142097
>>142040

>Например поворот матрицы.


Хм.. вектора же.

Есть вектор, который нужно вращать в системе координат камеры пропорционально dx и dy курсора мышки. Вращать можно последовательно вокруг "верха"(UpVec) на dx, затем "бока" (StrafeVec) на dy.
После того как повернутый вектор найден нужно заново
расчитать матрицу вида mLookAt(куда).
И еще есть морока с определением нового базиса камеры. Камера может "завалится", для избегания этого я всегда беру как ось верха "Y+" вне зависимоти от реального верха как cross(X, Z).
>>142098>>142099
#70 #142098
>>142097
Еще забыл добавить, во второй статье рекомедуют на колесо повесить изменение fov'а для приближения без измения позиции. Это требует каждый кадр пересчета матрицы прекции(не как что-то плохоe).
Но имхо не очень удобно, у меня по колесу изменение позиции наблюдения вдоль вектора "вперед", т.е. камера приближаться к центру вида.
#71 #142099
>>142097
Из меня обеснялка никакая.

>Есть вектор


Это вектор вперед в системе координат камеры или normalize(DirOnTarget).
13 Кб, 250x150
#72 #142110
>>142096

>Ты нихуя не понял


Иначе бы не спрашивал.

>читай еще.


Пять раз перечитал, не понимаю.
Вот результат индексации из того примера с кубом, вершин стало использоваться меньше, но почему их осталось 28, а не 8?
>>142113
#73 #142113
>>142110
Потому что при индексировании считается уникальность по всем атрибутам.
v(p1, n1, t1) != v(p1, n1, t2) - в индексе такие вершины будут считаться разными.

Для куба хватает 8 позиций которые образуют 12 треугольников или 36 вершин. Внимание вопрос: сколько для куба надо различных нормалей и текстурных координат?

Допустим нормалей тоже 6. Это нормали к грани, а не к вершине.
Тогда одна грань куба будет:
v(р1, n1) v(р2, n1) (р3, n1) - первый треугольник
v(р3, n1) v(р2, n1) (р4, n1) - второй треугольник
Занимает 4 вершины в индексе, итого 24 вершины для куба.

Теперь если добавить текстурные координаты у тебя вылезет еще 4 уникальных вершины. Хз почему, зависит от степени ебанутости экспортера и артиста который делал развертку.
>>142115
#74 #142115
>>142113
Вот именно это меня и напрягает, на нормальных моделях экономия при индексации почти никакая, какой толк тогда, если можно пилить VAO и не париться? Или есть другие подходы к этому вопросу?
>>142116
#75 #142116
>>142115
Да можно на простых моделях типа куба особо нет разницы рисовать в лоб 36 вершин или 24 через индекс. Но попрошу заметить, что ультра хардкор сжатие это рисование куба всего за 8 вершин вида v(pN, nN, tN). - сглажениые нормали(четкие грани редко когда нужны) и впритык заполненое текстурное пространство(на это влияет кол-во швов у модели, чем меньше тем меньше дублей вершин по текстурам).

>на нормальных моделях экономия при индексации почти никакая


Наоборот максимальная. У твоего сферического примера четкие грани и я нащитал(могу ошибисться) 14 швов. УГ кароч.
>>142117
#76 #142117
>>142116
Ок, теперь все ясно, спасибо!
>>142118
7 Кб, 275x183
#77 #142118
>>142117
Пжлс.
Хотел еще сказать - не заморачивайся байтоеблей и рисуй все через индекс. Индекс ебут 3д-редакторы и руками строить его не нужно, памяти у видеокарт от 1 гига и дай б-г если 10% ее заполнено сетками и шейдерами, а все остальное тонет в full-hd текстурах. Бери проще!
90 Кб, 1400x827
#78 #142283
Хорошую картинку откопал.
Какой-то гуру освещения рисовал.
>>142324
#79 #142324
>>142283
Больше таких картинок.
#80 #142519
Зимний бамп.
#81 #143496
Спижжено с прикрепленого.
http://tfpsly.free.fr/bookmarks.html
#82 #143501
>>142023
Кончил с анимаций.
#83 #143634
>>142023
Запиливается перевод
http://habrahabr.ru/post/245713/
Следите
>>143660
sage #84 #143660
>>143634

>2014


>перевод с английского


>бутылочное горлышко


Хабрадебилы невер чейнжс
>>143767
#85 #143766
Поцоны, объясните мипмапы.
Не совсем понимаю что с ними делать. Сейчас, когда изучаю, рисую простые кубики и понятное дело можно с мип уровнями не возиться. Но надо будущее надо учесть.
Вот есть функция glGenerateMipmap, мне её нужно применять, наверное, не для всех текстур например к текстуре оружия нет, он и так постоянно рядом с near plane.
Я так понимаю драйвер сам будет выбирать какой мип уровень использовать?
>>143769>>143880
#86 #143767
>>143660
Такой умный - укажи на ошибку переводчикам. Ой, погодите-ка! Ты местный школьник-циник, ты не опустишься до помощи другим.
#87 #143769
>>143766

> драйвер сам будет выбирать


Да.

>glGenerateMipmap, мне её нужно применять, наверное, не для всех текстур


И да и нет. Если оружие под углом к плоскости экрана - то мипы нужны.
>>143776
#88 #143776
>>143769
А где про них ещё почитать?
Как генерировать? Сколько уровней задавать для текстуры? Удаление их из памяти?
Ну в общем пока вот такие вопросы.
>>143877
#89 #143877
>>143776
Шапку для кого писали?
Мипы генерятся автоматически.
sage #90 #143880
>>143766
Если у тебя в работе планируется "использовать" текстуру на разных от камеры расстояниях, то для нее мипмапы нужны.
Обычно мипмапы генерируют при сохранении текстур, типа DXT.
Драйвер по умолчанию сам выбирает, но можно и самому указывать.
ПОИСК КНИГИ #91 #143881
Привет. Есть какая-то русскоязычная книга по OpenGL 3.3+(чтобы обязательно про программирование шейдеров было)? Я могу читать какие-то статьи на английском, но это происходит очень долго. Поэтому хочу почитать русскую книгу. Лучше бы это был перевод, но русский автор тоже пойдёт.
Буду рад, если что-то подскажете.
Спасибо.
>>143955
sage #92 #143955
>>143881
ОП пост для кого, сука тупая?
>>144153>>144282
#93 #144148
Посоны, поясните.

Раньше делали отрисовку в glBegin/glEnd. Потом через буфер (VBO, VAO - всё такое).

gluSphere - какой вариант использует? Если первый - какой тогда вариант есть отрисовки через vertex buffer, кроме как самому генерить вершины(т.е. есть ли стандартые функции)?
>>144153
#94 #144153
>>144148
>>143955
#95 #144282
>>143955
Ну и где там, блять, книги на русском?
>>144283>>144299
sage #96 #144283
>>144282
Боресков, блять.
#97 #144299
>>144282
http://ogltutor.netau.net/index.html
сука слепая.
3 Кб, 256x256
2 Кб, 256x256
#98 #144361
Как запилить такое преобразование на чистом GLSL?
>>144397>>144411>>144415
#99 #144397
>>144361
Нихуя нипонел - какое такое?

Еcли нужно преобразовать первый пик во второй, то нужно сделать дополнительную одномерную текстуру маски по Х c со значением (начало затенения по Y). Это можно сделать через свертку, отдельным проходом.

Затем уже делать чистый проход типа:
if (TexCoord.v - Tex1D(TexCoord.u) > 0)
FragColor = Белый;
else
FragColor = Чорный;

мимо диван
>>144411>>144417
#100 #144411
>>144361
Только постпроцесс как тут описано >>144397
>>144417
338 Кб, 256x256
#101 #144415
>>144361
О, я нашол что мне товй пик напоминал.

Суть это графическое представленя построения одномерной теневой карты, для затенения в двумерном пространстве.

Строится так:
Оределяется шаг в градусах как (TexResolution / 2pi)
Трасируется луч(начало - позиция ИС, с шагом угла)
Ищется пересечение с 2d геометрией.
Растояние заносится в тектуру как Tex[CurrentAngle] = Distance(или MaxLightDistance, если нет пересечения ни счем).

Потом, при отрисовке геометрии, растояние из текстуры сравнивается с растоянием текущего пикселя до ИС по заданому углу - елси больше то пиксель в тени, иначе он на свету.
>>144417
#102 #144417
>>144397
>>144411
>>144415
Ну значит будем так делать. Вот преобразования в и из полярных координат. Я всё правильно сделал?

void to(in vec2 uv, out vec2 cart) {
float theta = uv.x 2.0 PI;
float r = uv.y;
cart = vec2(-r sin(theta), -r cos(theta));
cart = (cart/2.0) + 0.5;
}

void from(in vec2 cart, out vec2 polar) {
vec2 p = ((cart-0.5)2.0);
float r = length(p);
float theta = atan(p.y, p.x);
polar = vec2(-theta, r);
polar.x = (polar.x-PI/2.0)/(2.0PI);
if(polar.x < 0.0) polar.x+= 1.0;
}
>>144423
#104 #144426
>>144423
Я именно это и курю. Только мне ещё надо разобраться с самими шейдерами. Надо бы прочитать весь этот гайд от начала. Пользы больше будет.
>>144439
sage #105 #144437
>>144423
Ниблохо. Осталось понять теорию о 1Д радиальном луче Ведь можно просто топ-даун сканлайном пройтись.
>>144438
#106 #144438
>>144437
Сажа прилипла.
#107 #144439
>>144426
Вот тут ещё по 2д теням.
http://habrahabr.ru/post/204782/
#108 #144540
А правда, что в 2015 году выйдет новый API?
Если сейчас начну учить, не придется все заново переучивать потом?
>>144543
#109 #144543
>>144540
Учится пайплайн и технологии а не спецификация.
Да, планируется, на основе Мантл
>>144588
#110 #144588
>>144543
Ну тогда я наверное годик подрочу СДЛ, потом видно будет.
>>144616
#111 #144616
>>144588

>Ну тогда я наверное годик подрочу СДЛ, а завтра меня собьет автобус.

#112 #144643
Пасаны, сел я тут шейдера осиливать, а там GLSL.

В общем, подскажите, как запилить инвертирование цветов из фоновой текстуры.

Допустим, если на фоне чёрный цвет, то мне нужно окрасить свою текстуру в белый.
>>144645
817 Кб, 1088x464
#114 #144652
>>144645
Не-не-не, ты не понял.
Вот смотри, есть рандомная фоновая картинка. С цветом, и прочим. Например, горелый дарт вейдер.
Есть текстура с отрендеренным туда текстом. Прозрачный фон, чёрный текст.

Что делает шейдер:
1) Берёт пиксель из дарта вейдера
2) Инвертирует ему цвет
3) Присваивает этот цвет пикселю, который находится уже в текстуре с текстом.

Таким образом, текст должен быть виден на любом фоне и поебать на цвет фона.
>>144656>>144680>>144685
#115 #144653
>>144645
Не переходите на главную, если у вас Firefox - виснет.
#116 #144656
>>144652
(как это сделать?)
#117 #144680
>>144652
Че ты несешь, поехавший? Тебе дали шейдер, рендери с ним в текстуру все, что хочешь.
19 Кб, 640x499
#118 #144685
>>144652
Ну бля
https://www.shadertoy.com/view/llX3zM
На шейдер той нельзя запилить свою пикчу, но я подобрал шахматную доску и сделал ее белый прозрачным, типа чёрные кубики получились.
>>144695
#119 #144695
>>144685
Пикча полностью описывает мою реакцию на этот сайт >https://www.shadertoy.com/
>>144697
#120 #144697
>>144695
Хотя как тулзень - штука годная.
Но отсутствие скрола и автопроигрывание с открытия - это пиздец.
#121 #145074
Аноны, а что делать надо? Хочу игру сделать, а не знаю как.
>>145079
#122 #145079
>>145074
1) Программа стартует.
2) Загружает необходимые данные для уровня, например.
3) Запускается главный цикл.
4) Считывает данные с клавы/мыши.
5) Расчёт игровой логики/мира.
6) Рендеринг
7) Goto 4
#123 #145182
Подскажите саму концепцию разработки с опенгл. Я вот заметил что с его помощью можно обрабатывать столкновения объектов. Но стоит ли так делать? Ресурсоёмко ли это?
>>145321
#124 #145321
>>145182

>заметил что с его помощью можно обрабатывать столкновения объектов


>заметил


>обрабатывать столкновения объектов


Где?
214 Кб, 816x638
#125 #145564
Сап ананасы.
У меня вопрос.
Изучаю освещение по уроку
https://code.google.com/p/gl33lessons/wiki/Lesson04
И не могу понять, почему на теневой стороне тора есть свет?
Код шейдеров один и тот же.
>>145569>>145570
#126 #145569
>>145564
ИМХО это спекуляр вылез с обратной стороны. Где-то минус потерял или что-то такое.
>>145732
Аноним #127 #145570
>>145564
либо кросспродакт не в том порядке, либо минус у дота потерял
>>145587>>145732
#128 #145587
>>145570
If на знак результата поставь.
#129 #145732
>>145569

> это спекуляр вылез с обратной стороны


Да, это был он. Я убрал передачу его в шейдер и всё ок заработало, но, понятное дело, это не решение проблемы.
>>145570

>либо минус у дота потерял


Зыс.
Я использую GLM, а в тех уроках юзается самописная либо.
Так вот, я шейдере ( который у урока, а не мой ) поставил у дота поставил минус и стало также как и у меня!
Ну и я, соответственно, поставил у себя минус и у меня эта проблема пропала.
Вот эта строка:
https://code.google.com/p/gl33lessons/source/browse/tags/lesson04/data/lesson.fs#61

Если данные входные одни и те же, даже шейдеры ( ну почти ) идентичны, то думаю проблема в математической либе.
Это ещё и подтверждается тем, что начальные координаты камеры тоже идентичны, однако моя камера стартует где-то в жопе сцены, а в уроке всё норм!
>>145745
#130 #145745
>>145732

>однако моя камера стартует где-то в жопе сцены


Ты их каждые фрейм передаешь в шейдер?
Матрицы пересчитываешь?
>>145747
#131 #145747
>>145745

> Ты их каждые фрейм передаешь в шейдер?


Да, а как ещё?

> Матрицы пересчитываешь?


Всмысле?
>>145762
#132 #145762
>>145747

>Матрицы пересчитываешь


При каждом изменении их надо пересчитывать.
В шапке в одном из туториалов пояснено за класс камеры.
>>145773
#133 #145773
>>145762
Ну дак это я знаю.
Перед отправкой их в шейдер view на projection умножаю.
Передаю матрицу модели и матрицу нормалей этой модели ( это для освещения ).
Ещё эти пляски с освещением не нравятся:

> Стоит отметить, что при использовании FFP OpenGL освещение рассчитывалось не в мировой системе координат, а в видовой. На мой взгляд это не очень удобно, т.к. видовая система координат связана с камерой, а источники освещения удобно задавать в мировой системе координат и именно там и производить весь расчет.

>>145833
#134 #145833
>>145773
Ты можешь считать в любой системе в какой нравится.
Но в общем освещение считают во вью спейсе, а перевести из мира в вью спейсе - это совсем не проблема.
FFP уже лет 10 используется. ВЫкинь нахуй туториал.
>>146230
#135 #146230
>>145833

> не используется

#136 #146422
Анон, вопрос насчет процесса разработки, гугление на русском и английском не даёт результатов.

Начал изучать OpenGL 3.3 по туториалам с http://opengl-tutorial.org
Всё нормально компилируется, но при отладке даже самой первой программы в Visual Studio программа не работает как надо, потому что использует интегрированное видео вместо моей GT630M на ноуте. Как заставить программу использовать дискретное видео по-умолчанию? Неужели для каждого туториала придётся в панели управления видеокарты устанавливать для каждой программы использование GPU вместо CPU?
>>146423>>146424
#137 #146423
>>146422
Забыл упомянуть, драйвера на ПЕЧ стоят последние. Может где нужно включить опцию автоматического использования карточки при вызовах процедур OpenGL 3.X?
>>146424
#138 #146424
>>146422
>>146423
А, всё, надо было сразу полезть в панель управления. Выставил GPU предпочтительным графическим процессором, всё заработало как надо.
>>146430
#139 #146430
>>146424
Чтобы работало всегда - запускай саму студию с поддержкой дискретки. дебагер как чайлд запустится тоже с интегрированой.
>>146431
#140 #146431
>>146430

> дебагер как чайлд запустится тоже с интегрированой


С дискретной, ты наверно имел в виду?
Да, я как раз подумал об этом, потому что при автовыборе дискретки все кому не лень будут использовать её. Однако опять же при запуске скомпилированного приложения не из студии придётся делать лишние движения для запуска приложения с поддержкой GPU. Думаю, на время разработки можно оставить автовыбор GPU.
>>147336
#141 #147336
>>146431
Ну, да.
#143 #148298
Начинается интересная серия статей:

Краткий курс компьютерной графики: пишем упрощённый OpenGL своими руками
http://habrahabr.ru/post/248153/
>>148310>>148318>>148345
#144 #148310
>>148298

>Начинается


>из песочницы


Мечтай. Теперь у него есть инвайт - одной статьёй всё и ограничится.
#145 #148318
>>148298
Нахуй ты это говно с хабра тащишь?
>>148330
#146 #148330
>>148318
Чтобы тебя, тупого пидараса, бесить.
>>148333
#147 #148333
>>148330
От тебя один негатив.
#148 #148345
>>148298
http://joshbeam.com/articles/simple_line_drawing/
http://groups.csail.mit.edu/graphics/classes/6.837/F02/lectures/6.837-7_Line.pdf
Уже все давно написано, идите нахуй с "преподами" для школьников c их переводом статей на руSSкий.
#149 #148552
Посоветуйте пожалуйста что-то почитать по теме.
В общем: Использую ogl3.3. Научился генерировать ландшафт, научился настраивать текстуры, двигать камерой, масштабировать, вот это всё. Теперь я хочу научиться, например, создавать шар и двигать его по ландшафту. С чего мне начать? Как происходит взаимодействие шара с ландшафтом (Имеется карта вершин).
>>148659
#150 #148659
>>148552
Ты про коллизии? Это уже не к огл. Не знаю, почитай про буллет какой-нибудь.
#151 #148724
>>141146
Есть ли игровой фреймворк для OpenGl. Именно заточенный под графику, а не Qt.
>>148728
608 Кб, 1366x768
#152 #148728
>>148724
Самое главное то забыл для js. То есть чтобы я мог в браузере opengl вертеть, чтобы делать вещи типа прилеплейтеда без всяких плагинов, но и без низкоуровневых матриц
http://play.ironbane.com/
>>148746
#153 #148746
>>148728
three.js
9 Кб, 375x70
#154 #148883
Аноны, генерирую атлас с символами с помощью freetype, пихаю, соответственно в текстуру формата GL_RED. Какие BlendFunc выставлять, чтобы с прозрачностью выводилось? И самое главное непонятно, как определять какой у меня формат, чтобы менять блендинг. И вообще поясните за смешивание, весь гугол прочитал, не могу понять, что и как.
>>148904>>148919
#155 #148904
>>148883

>BlendFunc


Пиздуй нахуй со своим Блендом, в шейдере обрезай по значению.
Или же делай правильный порядок вывода, чтобы бленд сработал, ато ты рисуешь сначала шрифт а потом остальное.
>>148933
sage #156 #148919
>>148883
if (color.r < 0.001) discard;
>>149179
#157 #148933
>>148904
Да говорю же, не разобрался еще с ним. Если можно заменить шейдером, то заебись.
>>148945
#158 #148945
>>148933

>заменить шейдером


Так ты еще и на легаси пишешь?
Да пойди ты нахуй, тут ОГЛ ниже 3.2 не обсуждается.
>>149065
#159 #149065
>>148945
Ты детектор чини, я ж говорю, блендинг не юзал ни разу, пишу на 3.3+, пытаюсь понять нахуя он нужен.
>>149100
#160 #149100
>>149065
Тогда что значит "заменить шейдером"?
>>149113
#161 #149113
>>149100

>Если тот же функционал можно перенести в шейдеры, а не ебаться с непонятной хуйней, то заебись.

>>149179
#162 #149179
>>149113

>тот же функционал


Какой "тот же", блять.
Блендинг состоит из двух частей, мать вашу:
Задать в коде програмы:
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

В шейдере:
>>148919
>>149181
#163 #149181
>>149179
+ в шейдере:

...
return vec4(1,0,0,color.r)
#164 #149185
Ребята, я, наверное, уже тут всех заебал, но у меня так и не вышло нормально задать текстуры. В интернете примеры только со старым ogl и они там просто делают это функцией.
Расскажите кто-нибудь, как вы устанавливаете проективные текстуры? Или покажите код.
Какой-то анон посоветовал:

>Передавать в текстурные координаты нужно только вертексные координаты, умноженные на model матрицу.


но это похоже на неправду. Или я просто не понял. Или другой пайплайн.
Вот мой тред: https://2ch.hk/gd/res/148803.html
Я уже заебался. На стаковерфлоу постоянно кидают эту статью http://home.xyzw.us/~cass/qcoord/, но она нихуя не очевидная. Какие-то вертексы задают vec4 векторами.
>>149188>>149262>>149263
#165 #149188
>>149185
Сюда пришел.
Куб из туториала написал?
>>149198
#166 #149198
>>149188
Да, но там координаты заданы уже.
#167 #149262
>>149185
Объясню популярно еще раз. Итак, для чистоты эксперимента ты будешь передавать в шейдер только координаты вершин. Текстурные координаты оставь в стороне, закомменть. В шейдере, до перемножения на всякие матрицы, ты присваиваешь текстурным координатам (которые vec2) два координаты из позиции вершины (поиграйся со значениями, xy, yz, xz, я хз какая у тебя там система отсчета). Потом ты накладываешь текстуру с помощью этих самых полученных координат и выкладываешь скрины.
>>149263>>149277
#168 #149263
>>149262
>>149185
И не забудь про
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
>>149277
3358 Кб, 1911x966
#169 #149277
>>149262
>>149263
Идеально работает, если просто передаю position.xz . Пока оставлю так.
Спасибо.
>>149282
3515 Кб, 1916x1011
2534 Кб, 1912x1012
#170 #149282
>>149277
А нет, как-то странно просвечиваются некоторые части.
Вот на пике пример. Вот это странное пятно - это бугор, который на ландшафте там дальше находится. То-есть, видно его часть снизу-вверх.
По-хорошему, нужно сначала освещение сделать, а то хуево видно всё это.
Я может напишу еще как-нибудь.
>>149285
#171 #149285
>>149282
glEnable(GL_DEPTH_TEST);
#172 #149493
Сап, ГЛьщики.
Решил давеча сделать отражения в экранном пространстве, но столкнулся с тем, что трейсинг стреляет уж очень не точно - малейшее движение и пиксели на отражении скачут как кролики весной.
Есть у кого идея или статья какая, где описано решение?
>>149497
#173 #149497
>>149493
В дум3 бфг посмотри.
>>149500
#174 #149500
>>149497
Там нету рефлекшена.
#175 #153133
Сап, только начинаю изучать, стоит ли ебаться с Qt, чтобы кроссплатформенность, или как?
>>153220
#176 #153153
Блин, ребятки, какая крутота http://youtu.be/rL8zDgTlXso, я аж прослезился! Может есть у кого-то статья, туториал, видеоурок, как сделать подобное? Нет, не хочу сделать тутор по такому, хочу кубики создавать.
>>153220
#178 #153221
>>153220
+http://webstaff.itn.liu.se/~stegu/TNM084-2011/
Тут курс с той видяшки.
#179 #153779
Пагни, подскажите алгоритмы детекции точных коллизий 3д моделек, не сферами.
Cпасибо.
>>153785
#181 #153788
>>153785

>не сферами


Парашу вроде aabb по первым ссылкам в гугле я уже нашел без твоей язвительности.
>>153813
#182 #153813
>>153788

>Парашу вроде aabb


>Парашу


>aabb


Может тебе еще и окттри с BVH параша?
#183 #153842
Я охуел с вашей шапки. Ну-ка, ткнули меня носом в самый заебенный гайд по самому последнему глу! Быстрабля, пожалуйста
>>153843>>153845>>153851
#184 #153843
>>153842
porn.md
>>153844
#185 #153844
>>153843
Нормально ответить можешь? А то я нашел гайдики на 3.3, но они морально устарели, это не говоря о том, что у меня cmake отказывался что-то там конфигурировать (я нихуя не понел, гугел не помог)
#186 #153845
>>153842

>Ну-ка, ткнули меня носом


Могу ткнуть в говно.

>меня cmake отказывался что-то там


и послать нахуй.
# OP #187 #153851
>>153842
Что тебе в тех туториалах не нравится? С 3.3 в пайплайне ничего принципиально не поменялось. Учи базу по этим, дальше уже расширениями и тесселяцией обмазывайся, если так надо.
>>156375
1485 Кб, 231x166
#189 #154045
Суп велосипедистам. Сам велосипедист.
Хочу поделиться с аноном своей маленькой находкой, которая возможно не всем очевидна.

В своем велосипеде я хочу дать возможность пользователю легко переключаться между оконным и полноэкранным режимами.

Проблема №1. В винде стандартное окно (с рамкой и заголовком) и для полноэкранного режима (без ничего) - две большие разницы, поскольку нельзя сделать из одного другое после создания.
Решение: создавать два окна и переключаться между ними по команде (например в крузисе по wm_maximize для первого и wm_restore для второго, лoл).

Проблема №2. Для первых экспериментов ещё куда ни шло завязывать процедуру рендера на оконные сообщения типа wm_paint, wm_timer, но теперь это мягко говоря странно. Плюс создавать по контексту на каждое окно и потом расшаривать между ними объекты. Гемор наверняка тот ещё будет.
Решение: по наденным в инете рецептам видно, что вполне нормально использовать один контекст рендеринга по необходимости переключаясь между несколькими контекстами устройства (окнами). Тогда выносим весь код рендера в отдельный поток, и туда же можно код создания контекста - чтоб оконные потоки уже этим не занимались. Остается только вовремя подавать потоку рендера сообщения о смене контекста устройства и изменении размера окна.

Проблема №3. Первое окно работает, из второго сыплется ошибка 2000 - неправильный формат пикселя.
Преамбула: изучение OpenGL ещё во времена 1.1-1.2, привычка писать в одну харю одно окно, спагетти и т.д. Короче процедура создания контекста тогда состояла из установки формата пикселя в контексте устройства и создания контекста рендеринга, и была слеплена воедино, а ныне добавилось еще объявление реального контекста для третьей или более новой версии. Решение: отделяем установку формата пикселя из общей процедуры создания контекста в потоке и переносим ее в обработчик wm_create для каждой формы, а передача контекста устройства при смене окна уже работает.

Итог: рендер работает в собственном потоке независимо от окон (их можно теперь насоздавать пачками), ну и не забываем при закрытии окон сначала завершить поток рендера, освободить ресурсы и закрыть контекст.

Надеюсь кому-то поможет.
P.S.: gDebugger - сила.
1485 Кб, 231x166
#189 #154045
Суп велосипедистам. Сам велосипедист.
Хочу поделиться с аноном своей маленькой находкой, которая возможно не всем очевидна.

В своем велосипеде я хочу дать возможность пользователю легко переключаться между оконным и полноэкранным режимами.

Проблема №1. В винде стандартное окно (с рамкой и заголовком) и для полноэкранного режима (без ничего) - две большие разницы, поскольку нельзя сделать из одного другое после создания.
Решение: создавать два окна и переключаться между ними по команде (например в крузисе по wm_maximize для первого и wm_restore для второго, лoл).

Проблема №2. Для первых экспериментов ещё куда ни шло завязывать процедуру рендера на оконные сообщения типа wm_paint, wm_timer, но теперь это мягко говоря странно. Плюс создавать по контексту на каждое окно и потом расшаривать между ними объекты. Гемор наверняка тот ещё будет.
Решение: по наденным в инете рецептам видно, что вполне нормально использовать один контекст рендеринга по необходимости переключаясь между несколькими контекстами устройства (окнами). Тогда выносим весь код рендера в отдельный поток, и туда же можно код создания контекста - чтоб оконные потоки уже этим не занимались. Остается только вовремя подавать потоку рендера сообщения о смене контекста устройства и изменении размера окна.

Проблема №3. Первое окно работает, из второго сыплется ошибка 2000 - неправильный формат пикселя.
Преамбула: изучение OpenGL ещё во времена 1.1-1.2, привычка писать в одну харю одно окно, спагетти и т.д. Короче процедура создания контекста тогда состояла из установки формата пикселя в контексте устройства и создания контекста рендеринга, и была слеплена воедино, а ныне добавилось еще объявление реального контекста для третьей или более новой версии. Решение: отделяем установку формата пикселя из общей процедуры создания контекста в потоке и переносим ее в обработчик wm_create для каждой формы, а передача контекста устройства при смене окна уже работает.

Итог: рендер работает в собственном потоке независимо от окон (их можно теперь насоздавать пачками), ну и не забываем при закрытии окон сначала завершить поток рендера, освободить ресурсы и закрыть контекст.

Надеюсь кому-то поможет.
P.S.: gDebugger - сила.
>>154068>>154086>>154110
#192 #154090
>>154086

>удалять окно и создавать новое


Вот это точно не нужно.

>SetWindowLong


У меня ещё ни разу не работало, не знаю, что я не так делал.
>>154106
#193 #154106
>>154090
Udalenie okna ne vedet k invalidacii konteksta.
Prost sdelay eto pravilno.
#194 #154110
>>154045

>В винде стандартное окно (с рамкой и заголовком) и для полноэкранного режима (без ничего) - две большие разницы


Это враньё.
13 Кб, 200x218
#196 #154758
>>154713
#197 #154854
Киньте уёбку гайды по OpenGL на русском, пожалуйста.
Я знаю инглиш на некотором левеле, но русский куда приятнее
>>154862
#198 #154862
>>154854
В ОП посте ссылки на тьюториалы на русском, полуёбок.
#199 #154938
>>153220
Ребята, я конечно понимаю, что вопрос тупой, но вот в этой статье код написан на питоне, в чем его можно компильнуть? В статье, я так понял, он работает на Линуксе и начал туда особых Линукс онли ИДЕ, а для Вин64 какие есть аналоги?
>>154954>>155051
#200 #154954
>>154938

> но вот в этой статье код написан на питоне, в чем его можно компильнуть?


Питон это интерпретируемые язык программирования.
>>154964
#201 #154964
>>154954
Дело в том, что там библиотеки подключаемые, как ты их без питона интерпретируешь?
#203 #155356
На русском по 3d и матану есть что-нибудь? Хочу книгу чтобы в руках держать и читать.
>>155364>>155406
#204 #155364
>>155356
Боресков и Шикин "Компьютерная графика. Полигональные модели."
#205 #155389
Объясните пожалуйста, как нужно делать разные текстуры для разных объектов? Я имею ввиду, нужно передавать в шейдер несколько текстур и там как-то выбирать? Или можно как-то хитро назначить разные текстуры перед отрисовкой? Пытался найти в туториале каком-то, но задолбался разбираться в убогой архитектуре и какой-то виндоус-дрисне.
Подскажите пожалуйста.
>>155401
#206 #155401
>>155389
Назначают текстуры. Примерно так
- Для каждого объекта
-- Для каждой части
--- Поставить текстуры
--- Нарисовать
>>155403
#207 #155403
>>155401
Всмысле, в методе отрисовки меняют их много раз?
>>155406
#208 #155406
>>155356
Купи читалку и выучи английский.

>>155403

>в методе отрисовки


Забиндил - нарисовал.
Если много текстур для одного объекта - гугли "мультитекстурирование".
#209 #156357
Почоны, есть ли какая-нибудь книжка по OGL 4 на русском, которая охватывала бы самые простые и общие принципы, чтобы я мог сразу начать писать двигло без вкуривания деталей?
Алсо, пешу на кьютэ.
>>156375>>156395
#210 #156375
>>156357
>>153851
#211 #156395
>>156357

>писать двигло без вкуривания деталей


Иди нахуй.
>>156648
#212 #156506
Поцоны, есть одна прога, в ней у меня вращается кубик. Почему-то при уменьшении размера окна кубик начинает вращаться быстрее. Это норма?
>>156508>>156514
#213 #156508
>>156506
И это gd
>>156510
#214 #156510
>>156508
В самом деле, что я делаю не так? Как зафиксировать вращение?
>>156528
#215 #156514
>>156506
Тайминги, сука! Ты проебался с таймингами в главном цикле!
>>156560
62 Кб, 614x382
#216 #156528
>>156510
Подозреваю, что отрисовка вместе с изменением угла забита тупо в бесконечный цикл. Прибавляй к углу вместо простой константы константу умноженную на время с момента предыдущей итерации.
Псевдокод:
Перед циклом:
OldTime = GetTickCount
В цикле:
Time = GetTickCount
Angle = Time - OldTime * X
OldTime = Time

X подбирай изходя из необходимой скорости вращения, в зависимости от того, в градусах или в радианах углы используешь, и с учетом, что GetTickCount возвращает миллисекунды.
>>156560
5676 Кб, 900x700
#217 #156536
А софтварным рендером никто не упарывается?
>>156547>>156551
#218 #156547
>>156536
Нет. Если есть время/студент - пиши, поймешь много. А так - читай теорию и доки.
521 Кб, 780x614
#219 #156551
>>156536
Упарывался раньше. Не треугольниками, конечно, ведь это бессмысленно. Софтрендер - это воксели, безграничная деталь и все такое. Тут раньше треды были, но постепенно кроме меня все забросили.
>>156563>>156595
#220 #156560
>>156514
>>156528
Ясно, спасибо.
#221 #156563
>>156551
Я в /гд/ недавно, скажи, сам упарывал воксели или на БесконечноДетальный фапал?
>>156564
#222 #156564
>>156563
И то, и другое.
#223 #156595
>>156551
Жаба?
#224 #156648
>>156395
Задроту НЕПРИЯТНО.
>>156737
#225 #156737
>>156648
Да не, он прав. Без вкуривания деталей - это тебе в юнити тред надо, иди туда и не отсвечивай больше тут.
96 Кб, 750x600
#227 #156784
Анонасы, знаю что вопрос совсем говно, но уж извиняйте. Сидел 5 лет на с++, щас захотел новых анальных ощущений, хочу перекатиться в ОпенГЛ. И ВНЕЗАПНО огромное количество библиотек для одного и того же. Какую выбрать для нормального изучения? Чтобы и туторов было не 1.5 штуки, и не совсем старье.
>>156793>>156800>>156819
#228 #156793
>>156784

>перекат из c++ в opengl


Уебывай из профессии.
>>156796
#229 #156796
>>156793
А что не так то? Ну может не перекат, синтаксис тот же, но материал то новый.
#230 #156800
>>156784
Библиотека для чего тебе, блять?
ОП пост для кого составлен, хуила?
>>156926
#231 #156819
>>156784
Двачую предыдущих, ты объясни, что хоть тебе надо.
>>156926
#232 #156926
>>156800
>>156819
Так я ж говорю, для базового изучения. А то я нашел какие то GLUT, GLEW, и еще какие то. Так вот и вопрос, если они все одно и то же делают, то что выбрать то? Или они все разные а я в глаза ебусь?
>>156944>>157002>>157093
#233 #156944
>>156926
Тебе нужен и GLUT, и GLEW. Почитай Orange Book.
>>157002
#234 #157002
>>156944
>>156926
GLUT, FreeGLUT говно мамонта.
Бери GLFW, SDL2, SFML для создания контекста.
GLEW для подключения расширений чтобы ручками ничего не делать.
GLM для математики.
Хули тут читать-то?
>>157017>>157023
#235 #157017
>>157002
Ну наконец-то. Спасибо. А то в шапке туториалов куча, а половина ниочем.
>>157022
#236 #157022
>>157017

>а половина ниочем.


И какая же?
>>157025
#237 #157023
>>157002

>для создания контекста.


Под Шиндовс еще так можно:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd374379%28v=vs.85%29.aspx
>>157191
#238 #157025
>>157022
А вот эта:

>>https://www.opengl.org/sdk/docs/man2/ - OpenGL 2.1


>>https://www.opengl.org/sdk/docs/man3/ - OpenGL 3.3


Старые доки впринципе не нужны, плюс туториалы по старым хуитам ненужны.
>>157029
#239 #157029
>>157025
Ясно.
#240 #157093
>>156926
GLFW + сырой OpenGL
#241 #157191
>>157023
Ага, и придётся юзать огл2.
Охуенная история.
>>157218>>157219
#242 #157218
>>157191
Идиот.
#243 #157219
>>157191
https://sites.google.com/site/opengltutorialsbyaks/introduction-to-opengl-3-2---tutorial-01
В догонку. И перестань уже кукарекать без знания матчасти.
>>157271>>158268
33 Кб, 358x504
#244 #157271
>>157219

> матчасти


> калоотстойник с winapi

>>157276
#245 #157276
>>157271
красноглазый ублюдок, твое мнение никого не волнует, ползи обратно в свою парашу
Аноним #248 #157482
>>157459
Ждем толпу неосиляторов. Ты это хотел сказать?
>>157486>>157502
#249 #157486
>>157482
Драйвера уже накатил?
#250 #157502
>>157482
Сейчас куча врапперов появятся. Точно всякие юнити будет первыми, так что первые набигатели будет из юнититреда, а так же всякое школие.

В любом случае, скоро ОГЛ, каким мы его знали, исчезнет Как только выйдет железо под некст заточеное..
>>157506>>157511
#251 #157506
>>157502
Железо уже давно есть. Главный вопрос конечно в том когда будут драйвера.
#252 #157511
>>157502

>скоро ОГЛ, каким мы его знали, исчезнет


Шо, опять?! Еще одного фокуса с исчезновением он может и не пережить. Как бы навеки не исчезнуть.
>>157522
#253 #157522
>>157511
Явно это произойдёт не скоро.
Может несколько лет. Хуй знает, короче.
#254 #157584
Посоветуйте какую-нибудь либу для создания окошка, обработки инпута и по возможности аудио.
SDL не предлагать, он какой-то ебанутый, хз как его параллелить.
>>157600>>157604>>157630>>157669>>157673>>157715
sage #255 #157600
>>157584
SFML
>>157601
#256 #157601
>>157600
приклеилась
#257 #157604
>>157584
Qt
#258 #157630
>>157584
А что за проблемы с SDL?
#259 #157669
>>157584
Его не надо параллелить. Он просто универсальная прослойка между игрой и железом, позволяющим забыть про тонкости устройства конкретной ОС.
#260 #157673
>>157584

>параллелить окошко


Ебанутый? Ебанутый.
Winapi, если спермолох, голые иксы, если линуксогосподин. GLFW если кроссплатформа-бог.
>>157676>>157681
#261 #157676
>>157673
Не понимаю, зачем кому-то нужно что-то еще, когда есть GLFW.

>голые иксы


Значение знаешь?
>>157681>>157874
#262 #157681
>>157676
>>157673
Qt более кросплатформа.
>>157682>>157874
#263 #157682
>>157681
Кутэ это какой-то мамонт со своими строками и прочим ненужным хламом.
#264 #157713
Нужно запилить программу которая отрисовывает трехмерный объект из файла obj оси координат и плоскость. Должна быть возможность вертеть сцену мышкой. Как трудно такое сделать?
>>157723
#265 #157715
>>157584
GLFW + OpenAL
#266 #157723
>>157713
Часа 3. Но тебе мы рекомендуем пройти нахуй, тут лабу тебе делать никто не будет.
>>157909
#267 #157874
>>157681
Кут слишком тяжеловесное говно. 50 мегабайт для пустого окошка? Как-то дохуя. Нет, он хорош, тут не поспоришь. Но не для геймдева. Для энтерпрайза, для тяжелых гуёв. Но для геймдева - очень плохой вариант, ты фактически будешь использовать 5% функциионала, но заплатишь всю цену в виде огромного дистрибутива, недостатка скорости в критичных местах и долгой компиляции проекта.
>>157676
Иксы полезно покопать чисто в образовательных целях, когда хочется поближе понять систему, и кроссплатформа не нужна. Для кроссплатформы да, GLFW рулит, тут спору нет.
>>157879
#268 #157879
>>157874
Ну, есть еще старые добрые виджеты.
https://www.wxwidgets.org/
#269 #157909
>>157723
Я и не просил писать лабу, я хотел узнать как много мне нужно знать чтобы сделать это и основываясь на этих знаниях поставить сроки. Проебусь конечно, как всегда
>>157910
#270 #157910
>>157909
Тебе нужно знать как загрузить модель, как ее перевести в ВБОи как этот ВБО нарисовать. Потом тебе нужен класс камеры.
Плюс нужен ВБО с осями и ВБО с плоскостью Аж 2 треугольника.
А, еще шейдеры, да.
Все.
>>157965>>158073
#271 #157965
>>157910
Спасибо анон!11
Мог бы поблагодарить.
#272 #158015
Тебе нужен класс для загрузки модели, класс для перевода в в ВБО, и ВБО тоже в классе должен храниться, как этот ВБО нарисовать тоже должен класс делать. Потом тебе нужен класс камеры. И класс мышки. И класс клавиатуры.
Плюс нужен класс ВБО с классом осей и класс ВБО с классом плоскости. Аж 2 класса треугольников.
А, еще класс для шейдеров, да.
Все.

Время идёт, крестобляди не меняются.
>>158037>>158101
#273 #158037
>>158015
Тащемта, ты описал жабу.
>>158058
#274 #158058
>>158037
Тогда это был бы "xml для загрузки модели…" етц. У жаборабов выбора нет, да и не лезут они со своими классами куда попало. А вот крестобляди всегда всё начинают с классов. В жопу алгоритмы, в жопу проектирование, в жопу структуры данных - у нас будет класс для хранения вот этой хуйни и ещё класс для обработки вон той хуйни.
Повбiвав би.
>>158090
#275 #158073
>>157910
Спасибо добрый человек. Отвечаю на сообщения раз в 2 дня
#276 #158090
>>158058
Хуевые крестобляди тебе попадались.
#277 #158101
>>158015

>класс


>класс


>класс


>класс


>класс


Нассал в рот за такое программирование.
12 Кб, 200x200
25 Кб, 1086x474
#278 #158203
Тащемта, пока идёт стандартизация можно на годик-полтора забыть о публичных драйверах.
Даже сейчас хеллоу ворлд из одного треугольника занимает несколько сотен строк.
>>158211
#279 #158211
>>158203

>Даже сейчас хеллоу ворлд из одного треугольника занимает несколько сотен строк.


Это так уже со времен перехода на шейдеры. Ничего не поделаешь, технология усложняется ради повышения производительности. Для упрощения есть движки, конструкторы. А ГЛ всегда был крайне низкоуровневым.
>>158212>>158218>>158224
#280 #158212
>>158211

>крайне низкоуровневым


Нет. У него была и пока есть абстракция со стейтами.
>>158218
#281 #158218
>>158211
>>158212
Не, тут фишка будет в другом.
Теперь драйвер будет ещё меньше сам что-то делать.
Теперь программист сам будет решать что, как и когда.
То есть работы будет ещё больше.
>>158219>>158291
#282 #158219
>>158218

>работы будет ещё больше


Вот это да. И что самое приятное - порог вхождения повысится. А значит и наши з/п :3
#283 #158224
>>158211
Я начинал его осваивать когда треугольник можно было отрисовать кодом умещавшимся в экран тех же времен. Сейчас в принципе так же, только монитор нужен WQXGA.
#284 #158233
Рисую OpenGL в WinAPI окно. Сообщения клавиатуры/мыши думаю обрабатывать тоже средствами WinAPI, а потом уже отправлять в заранее приготовленные функции OpenGL. Какие могут быть подводные камни? (просто в туториалах везде создают окна средствами OpenGL, а не WinAPI, поэтому засомневался).
>>158236>>158246
#285 #158236
>>158233
ОГЛ не умеет делать окна.
>>158246
#286 #158246
>>158233
Не ссы, все норм будет. Только рекомендую подумать заранее о делении всего этого добра на потоки. Меньше лагать будет когда разжиреет.

>>158236
Он имел в виду всякие врапперы типа GLFW. Я сам когда-то с glScene начинал, а потом понял, что мне не нужен код, который влияет на производительность, который я не контролирую, и который в принципе могу убрать.
#287 #158256
Сначала ковырялся с glBegin .. glEnd, но решил перейти на новый способ. Сейчас по туториалам пытаюсь открыть контекст устройства, см. ссылку http://ideone.com/4oKHdK.
wglGetProcAddr возвращает NULL, т.е. в драйвер видеокарты не имеет эту функцию. Драйвера последние (2009), видеокарта древняя Intel GMA 3100. При этом старым способом, glBegin glEnd нормально всё рисует. Кто-нибудь сталкивался с таким?
>>158257>>158265
#288 #158257
>>158256
Правильная ссылка на код:
http://ideone.com/4oKHdK
>>158259>>158267>>158268
#289 #158259
>>158257
Если видеокарта не поддерживает GLSL, то кроме как покупать новый ПК выхода нет?
>>158266
#290 #158265
>>158256
Педивикия вангует, что твой потолок на этой карте - OpenGL 1.4, то есть чуть-чуть выше dniwa ebanogo. Это эквивалент nVidia 2002-2003 года выхода. Купи себе хотя бы хотя бы GeForce 210 (самая дешевая с поддержкой OpenGL3), полтора килорубля. Можешь потратить больше - ищи по яндекс-маркету.
>>158289
#291 #158266
>>158259
Можно купить новую видяху.
Причем самую дешевую.
>>158289
#292 #158267
>>158257
Ты тут вызываешь команды ГЛ еще до того, как щакончишь с контекстом.
Сначала создай контекст потом давой ГЛ.
Еще - подключи GLEW - позволит юзать расширения без мозгоебство.
>>158289
#293 #158268
>>158257
И еще >>157219 глянь.
Зону с выдиранием адресов для ГЛ функций можно опустить если будешь использовать ГЛЕВ.
>>158289
#294 #158289
>>158267
Вот эти?
glShadeModel(GL_SMOOTH);
glClearColor(0.0f,0.0f,0.0f,0.5f);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
>>158265
>>158266
Понял. У меня старый ноут, отдельно нельзя. Вот и повод поменять, давно думал об этом.
>>158268
Тру хакеры всё делают вручную )))
>>158298>>158300
#295 #158291
>>158218
Правильно.
Ебаная нвидия уже заебала со своими кривыми, сука, драйверами.
>>158297
#296 #158297
>>158291

>нвидия


И тем не менее, у них - лучшие дрова.
#297 #158298
>>158289

>Вот эти?


Да.

>glShadeModel


Устарело.
http://en.wikibooks.org/wiki/OpenGL_Programming/Migrating_from_1.x_to_2.x
Только с 1 до 2, но идея понятна, а в тексте детали.
Целься на ГЛ 4+
На самом деле 3.2+ дальше только различия в фичах.
#298 #158300
>>158289
Наконец перестали шатать яндекс-капчу.
Есть вариант для мсье знающих толк: Mesa 3D. На офсайте даже написано, что OpenGL 3.3 может, и что под даже под Windows можно поставить.
>>158301
#299 #158301
>>158300
Если у нашего комрада нету бабла на новое железо А я подозреваю что он студент то твой вариант не худший, особенно учитывая некоторое повышение цен на железо и ноуты.
Но это надо быть полностью знающим толк
#300 #158307
Есть смысл изучать OpenGL сейчас или можно подождать Вулкан? Он же сильно измениться?
>>158308
#301 #158308
>>158307
Во-первых, до вулкана ещё как до китая раком. Лет через 5 только девайсы появятся.
Во-вторых, «старые» девайсы на ogl4 будут жить ещё долго, а дюк нюкем должен умереть
>>158310
#302 #158310
>>158308

> Во-первых, до вулкана ещё как до китая раком. Лет через 5 только девайсы появятся.


Смотрим на сайте Кроноса:

> Will work on any platform that supports OpenGL ES 3.1 and up


Смотрим в вики про OpenGL 3.1:

> Supported by Windows, Linux, Android (since Lollipop) on devices with appropriate hardware and drivers, including:


> Nvidia GeForce 400 series onwards (Windows)


Вывод?
>>158314>>158318
#303 #158314
>>158310
Да никакого, кроме того, что ждать придётся на год меньше.
Я сейчас в том же положении, что и ты, но 5 лет ждать новый стандарт не собираюсь, и учу OGL сейчас.
#304 #158318
>>158310
Если железка поддерживает gl4.3/es3.1 то вулкан пойдёт.
Ждите.
#305 #158324
Как думаете, кошерно ли использовать ddx текстурки вместе с опнглом?
Я не в плане совместимости. Всё равно это всего лишь просто данные.
>>158330
#307 #158331
>>158330
Да я уже gli попробовал.
Хорошее.
#308 #158844
Сап анон. Как мне нормально сделать скрытие невидимых граней в кубическом (аки минекруфт) мире?
>>158865
#309 #158865
>>158844
Octree, Frustum culling
>>158870
#310 #158870
>>158865

>Octree, Frustum culling


Я туториалы читал, ни хуя не взлетело. Поясни, как делать или туториал ссылку дай
>>158872>>158873
#312 #158873
>>158870
http://www.gamedev.ru/code/forum/?id=161884
Вот ещё мега тема.
Листай и ищи.
#313 #158874
>>158872
Ай, спасибо
33 Кб, 601x437
#314 #158911
>>141146
Что я сделал не так?
>>158919>>159159
#315 #158919
>>158911
glEnable(GL_DEPTH_TEST);
>>158973
#316 #158973
>>158919
пасиба
#317 #159159
>>158911
Родился.
#318 #159678
Двощ, как организовать камеру?
Я так понимаю, перед отрисовкой опенгл-ом, нужно пошаманить с координатами камеры и объекта, а то, что получилось, совать в опенгл?
чукча нечитатель
>>159693
#319 #159693
>>159678
Матрицы.
>>159708
#320 #159708
>>159693
И ещё вопрос: как организовать мультипоточный рендер?
Всё гарантированно же пойдёт по пизде, если один поток рисует жирную модельку белым цветом, а другому потоку в это время приспичило нарисовать модельку зелёным.
>>159710
#321 #159710
>>159708
Для этого тебе будет нужно создавать несколько контекстов отрисовки.
#322 #159983
Кирилл, как начать изучение опенГЛ? Что лучше учить - опенГЛ или Глут или СДЛ?
>>159984>>159996
#323 #159984
>>159983
учи юнити
>>159991
#324 #159990
Призываю знатоков glm.
Суть токова.
Нужно lookAt матрицу перевести в vec3 для view матрицы.
>>160051>>160345
#325 #159991
>>159984
Пока что могу только в С++, да и хочу заниматься не только игорами, но графикой в принципе
#326 #159996
>>159983
Ты чет хуйню написал.
ОпенГЛ - либа рисования 3д и соответственно 2д графики. Альтернатива - Direct3D.
GLUT - кросплатформенная либа для создания окон с глконтекстом и получинем инпута.
SDL - делает тоже самое что и GLUT только есть еще возможность рисования 2д спрайтов в общем, на ней можно сделать платформер без использования опенгл. Так же в сдле еще куча хуйни типо звуков, сети и так далее, никогда ими не пользовался.
Я считаю, что и GLUT, и SDL устарели, протухи и нахуй не нужны. Можно самому создавать окна и получать инпут. Благо, операционных систем всего 2.5, не много переписывать придется
Тебе скорее всего нужен графон, следовательно OpenGL. Сразу рекомендую туториал: http://ogldev.atspace.co.uk/
>>159997>>160000>>160004
#327 #159997
>>159996
Благослови тебя господь, спасибо что всё разъяснил. Улетел читать тутор.
#328 #160000
>>159996

>Можно самому создавать окна и получать инпут.


А можно взять SFML и не париться. Тамошнее окошко и в мультитрединг может, да и код для обработки инпута писать не надо.
>>160004
#329 #160004
>>159996
В этом туторе же ГЛУТ используют.
>>160000
Не путайте меня. Что лучше пердолить - ОПЕНГЛ или СФМЛ?
>>160005>>160049
#330 #160005
>>160004
SFML - аналог GLUT и SDL. У OpenGL считай всего один аналог - DirectX.
>>160007
#331 #160007
>>160005
FreeGLUT и GLUT - говно мамонта. На свалку их.
SDL2/GLFW/SFML - это всё хорошо.
#332 #160049
>>160004
Не смотри на уроки с GLUTом это вроде только первый урок, создай окно с глконтекстом другим путем и иди по туториалу дальше.
#333 #160051
>>159990
Какой нахуй vec3?
lookAt не юзал.
16 Кб, 200x200
#334 #160112
Сука!
Полтора дня ебался lookAt!
Оказывается формула та что в тьюториале и в glm отличаются!
Просто пиздос!
>>160201
#335 #160201
>>160112
Ты бы нормально объяснил, сразу бы ответил. А так нихуя не понятно.
>>160283
#336 #160283
>>160201
Это просто ты ничего не понимаешь.
Если ты не знаешь, что такое vec3, lookAt матрица и тд, смысл тебе что-то объяснять.
>>160308
#337 #160308
>>160283
Я знаю что такое vec3 и lookAt матрица, только не могу понять как и нахуя тебе ее переводить в вектор.
>>160316>>160345
#338 #160316
>>160308
Для шадоу маппинга нужна камера из источника освещения.
>>160345
#340 #160347
>>160345
Я знаю это.
Но в моей камере есть матрица проекции 4х4 и 2 вектора: углы поворота и положение в пространстве.
Не хотел ещё одну матрицу под вид.
#341 #160456
Использую glfw.
Так вот когда я не в фуллскрине, то примерно 20-30% процессорного времени отжирается.
Когда же я включаю фуллскрин, то там доходит до 50% и больше.
Как решить эту проблему?
Менял pollEvents на waitEvents и вообще ничего не меняло.
#342 #160458
>>141146
Есть тут люди кодящие на FPC в лазарусе под линя? Не могу найти как к нему цепляются библиотеки опенгла. Даже не понимаю, цепляются ли они как внешние .so или там в палитру надо что-то добавлять, или пакеты к ide (как castle_egine), а может как под виндой (там через winAPI) как-то. Короче, кто в теме, поясните мне по хардкору.
>>160464
#343 #160464
>>160458
Цепляются через стандартные модуди gl и glext. Но сейчас есть одна проблема: поменялась спецификация вызова glGetString, из-за этого glext.pp надо переписывать. Раньше glGetString(GL_EXTENSIONS) выдавал цельную строку, которую надо было парсить, сейчас эта функция выдает названия расширений по одному, надо только указать номер расширения в последовательности. У себя я эту проверку вырезал нафиг и тупо гружу все подряд под OpenGL 3.3, хотя формально это неправильно.
Хотя я под вендой работаю, не думаю, что под линем будет что-то иначе в этом плане.
>>160494
#344 #160494
>>160464

>Цепляются через стандартные модуди gl и glext


Вот это и вызывает у меня непонятки, на вики пишут:

> OpenGL units in Lazarus


>Lazarus includes a TOpenGLControl - a LCL control with an OpenGL context. The Lazarus package >LazOpenGLContext can be found in lazarus/components/opengl/lazopenglcontext.lpk. An example can be found in lazarus/examples/openglcontrol/openglcontrol_demo.lpi.


>If you want to modify TOpenGLControl implementation, for example to add new properties like ColorBits and AuxBuffers, see Extending TOpenGLControl.


Third party OpenGL units

>GLScene is a Lazarus package with lots of extra features for OpenGL applications.


>Castle Game Engine allows you to navigate and render 3D worlds (in VRML, X3D and other 3D formats).



Т.е. под LCL есть стандартные компоненты, под GLUT есть 3парти, второй я попробовал, там фактически готовый 3д движок, не то, что я хотел. Под GLUT я не вижу стандартных компонент. Сам freeglut у меня установлен, вместе с пакетом никаких пакетов самого лазаруса не шло (во всяком случае я не нашел в папках куда он поставился). Вот я и не врубаюсь, как оно цепляется.
>>160502
#345 #160502
>>160494
Вики у лазаря вообще тухлая какая-то, видимо основная аудитория - соскочившие с дельфей где-то около 7 версии, уже научившиеся всему более-менее нужному, и бомбящие от того, что уютная идешечка превратилась в монстростудию.

Ты сначала gl и glext подруби и попробуй создать контекст. Готовые библиотеки и компоненты (ох, как же припекало от запросов "кокой компонент скочать шоб было заебись?") конечно есть, но лучше не надо. GLScene - это наверное уже какой-то недоюнити стал, я помню его ещё году в 2006 щупал. Хотя было зашибись из первой халфы модельки в него пихать и анимацию гонять.

И лучше потрать недельку чтоб понять как оно изнутри фурычит, хотя бы как инициализируется, чем с места, в карьер, да по компонентам. В принципе ничего сложного нет, я даже когда-то писал лапшу из ifdef-ов, и в результате имел недовелосипед (под OpenGL 1.1, лoл), который успешно компилировался сразу и под виндой и под линем. Самое сложное было - заделать кросплатформенно обработку мыши и клавиатуры - у winapi и Хserver отличаются принципы работы с вводом.

Посмотри вот это: http://andru-kun.inf.ua/articles/linux_opengl_fpc_part1.html
Заодно сравни с инициализацией под виндой, для просветления.
>>160510>>160511
#346 #160510
>>160502

>Ты сначала gl и glext подруби и попробуй создать контекст


Да емае, я это и пытаюсь сделать. Я раньше на DevC ебашил на опенгл, там вообще хидеры подцепил и понеслась. Как в лазаре это делается не пойму хоть убей. Под спермой, через винапи можно ддлку опенгла подключить динамически и оттуда невозбранно вызывать что тебе надо, в лине .so также цеплять или что?

>И лучше потрать недельку чтоб понять как оно изнутри фурычит


Да я только за, с удовольствием поковыряю, только нет годного гайда. Есть старые православные уроки нехе, как раз по глуту, но они как я понимаю протухли. Конкретно в лазаре все гайды выглядят так, "Создаем приложение - Подключаем опенг компоненты - Ебашим код" и дальше листинг кода, а как все подключается нигде, сука, не написано. Или может я какой-то деревенный?

>Посмотри вот это: http://andru-kun.inf.ua/articles/linux_opengl_fpc_part1.html


Чет мертвая ссыль, не открывается.

>который успешно компилировался сразу и под виндой и под линем


Я поэтому лазаря и мучаю, он умеет сразу под кучу платформ без гемороя компилить, типа один раз написал и сразу кросплатформа сплошная.
>>160518
#347 #160511
>>160502
Распиши по шагам если не сложно или ссыль на почитать, будь любезен.
#348 #160518
>>160510

>я это и пытаюсь сделать


И что? Неужели пишет "модули не найдены"? Но они же входят в стандартную поставку freepascal.

Модули gl и glext собственно и занимаются динамическим подключением, и сами выбирают через проверку платформы (в compile-time) dll тягать или so. Надеюсь у тебя стоят свежие проприетарные дрова, и ты не будешь мучать проц месой.

А ссылка живая, я спецом для тебя в гугле за минуту нашел ее. Может у тебя особый провайдер, который считает, что лазить в домен ua - instant zashquar? Тогда вот тебе другая ссылка, там статья №1 та же, но теперь кури все три: https://mirgames.ru/topics?tag=freepascal

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

Через год-два у нас будет Vulkan, от этой инфы останется только как создать окно и отдать драйверу ссылку на его контекст.
>>160521
1 Кб, 332x36
140 Кб, 1268x863
7 Кб, 871x71
#349 #160521
>>160518

>Неужели пишет "модули не найдены"?


Да нет же. Ну как-то так, как на пикрелейтед.

Установил фриглут, смотрю список пакетов - его там нет, смотрю стандартную панельку лазаря, там только LCL компонент. Что, куда и как ставить и подключать, вот в чем вопрос. Посмотрел папки с фриглутом, там дохуя разных .so и конфигурационных файлов, .lpk файлов нет.

>Может у тебя особый провайдер


Через тор тоже не показывал, а заблоченые сайты подругому отображаются. Впрочем спасибо за ссылку, тоже почитаю обязательно.
>>160522
#350 #160522
>>160521

>Да нет же. Ну как-то так, как на пикрелейтед.


Yoptvojmatt...

uses
gl, glext, glx, x, xutil, xlib;

begin
end.

Вот этот код компилится или нет?
>>160523>>160525
#351 #160523
>>160522

>gl, glext, glx, x, xutil, xlib


Да компилится. Только он нихуя не видит функций глута, ни glutSwapBuffers, ни glutInit.
Но я тебя понял, тупо хидерами значит цепляется, спасибо просветелел.
>>160524>>160525>>160526
#352 #160524
>>160523
А все, uses glut и все дела. Пиздец, все так просто оказалось лол.
>>160525
#353 #160525
>>160522
>>160523
>>160524
Раз уж такая пляска, я тут читаю везде говорят глут говно мамонта и на нем кроме простейших вещей ничего не запилить. С чем вообще тогда серьезные пацаны работают, которые на опенгл игрища и прочие ништяки делают?
>>160531
#354 #160526
>>160523
Glut просто ненужен.
Читай те статьи и применяй на практике.
Для OpenGL от третьей версии и выше (надеюсь ты не будешь топтаться в 1.х, legacy и FFP), ты будешь делать всё это своими руками сам.
#355 #160531
>>160525
SDL
#356 #160705
Помогите аноны, ищу не столько готовое решение, сколько теоретические пояснения.
Практически все уроки ограничиваются тем, что "создаем шейдер, VAO, VBO, IBO, и рисуем один треугольник/квадрат/куб". Но что делать если я хочу рисовать несколько разных VBO с одним шейдером, или один и тот же VBO с разными шейдерами за кадр?
Меня сильно смущает следующее (подозреваю последствия бездумного копирования и безумные умения в говнокоде):
в процессе создания VAO-VBO-IBO надо получить из текущей шейдерной программы входные атрибуты для свойств вершин (XYZ, UV, нормали, цвета), и по сути привязать их к VBO. Почему привязать? Ну потому что в glVertexAttribPointer надо указать свойства массива с данными вершин - размер записи по одной вершине и смещение в записи для определенного свойства. И не забыть еще glEnableVertexAttribArray.

Правильно ли я понимаю, следующее:
1) glGetAttribLocation надо выполнить один раз на каждый входной атрибут для каждой шейдерной программы и сохранить в записи/объекте, который будет представлять этот шейдер в моем велосипеде;
2) при создании в runtime уникального объекта, в котором будут храниться ссылки на VAO-VBO-IBO (от уже неуникального меша) надо создать новый VAO, забиндить старые VBO и IBO, и заново привязать атрибуты шейдера к VAO через glVertexAttribPointer;
3) при рисовании не потребуется ничего более, кроме как забиндить соответствующие VAO и шейдер.
>>160742
17 Кб, 1040x141
2 Кб, 319x55
6 Кб, 450x133
#357 #160742
>>160705

> 1) glGetAttribLocation надо выполнить один раз на каждый входной атрибут для каждой шейдерной программы и сохранить в записи/объекте, который будет представлять этот шейдер в моем велосипеде;


Можно при заполнении буфера установить адреса атрибутов.
Гляди пикчи.

> 3) при рисовании не потребуется ничего более, кроме как забиндить соответствующие VAO и шейдер.


Смотря, что ты рисуешь.
Может быть ты рендеришь в текстуру, то для начала надо забиндить текстуру ( ну это для построения теней, например надо )
А так да.
>>160745
#358 #160745
>>160742
Я имел в виду, что хочу по возможности использовать разные VBO с одним шейдером, и наоборот, один VBO с разными шейдерами, и все это в одном кадре. При этом в вершинном "супе" могут быть заданы UV, цвета, нормали, могут быть не заданы (соответственно разные смещения). Я правильно понимаю, что glVertexAttribPointer устанавливает связь между конкретным VAO и конкретным шейдером или нет?
Рендерить в текстуру пока не планирую, но вроде там не должно быть больших подводных камней?
>>160752
#359 #160752
>>160745

> Я имел в виду, что хочу по возможности использовать разные VBO с одним шейдером


Можно.
Например какой-нибудь шейдер для освещения, а там всё равно на что светить. Кубили или шарики.

> и наоборот, один VBO с разными шейдерами


Можно.
Например. Рендерить тот же свет с тенями и без теней. С картами нормалями и без них и тд.

> Я правильно понимаю, что glVertexAttribPointer устанавливает связь между конкретным VAO


Да, типа того.
Но перед рендерингом можешь отключать не нужные атрибуты
Типа так:
vao.Bind();
glDisableVertexAttribArray( адрес_атрибута );
glDraw...
vao.Unbind();

> конкретным шейдером


Если ты при написание шейдера не установил явно номер атрибута ( как на 3ей пикче выше ), то видеокарта это сделает за тебя.
>>160760
#360 #160760
>>160752
Ага. То есть по сути надо биндить каждого с каждым заново. Последний тогда вопрос (на закрепление понимания): куча VAO, каждый со своим шейдером, но все с одним VBO-IBO - будет нормально работать как масса объектов с одним мешем и разными материалами, или надо из RAM под каждый VAO заново загонять меш в отдельный VBO-IBO?
>>160764
#361 #160764
>>160760

> То есть по сути надо биндить каждого с каждым заново


Не обязательно.

> куча VAO, каждый со своим шейдером, но все с одним VBO-IBO - будет нормально работать как масса объектов с одним мешем и разными материалами, или надо из RAM под каждый VAO заново загонять меш в отдельный VBO-IBO?


Я нихуя не понял.
Чего ты хочешь?
https://code.google.com/p/gl33lessons/
Вот эти уроки посмотри.
>>160766
#362 #160766
>>160764
Вот как раз смотрю. Ладно, вроде бы что-то доходит. Спасибо за поддержку, анон.
712 Кб, 1040x806
#363 #160820
Сука!
Ведь не похоже на карту нормалей?
>>160851
427 Кб, 1040x806
#364 #160851
>>160820
Проебался с этим говном.
Ну теперь всё нормально.
>>160852
404 Кб, 1040x806
#365 #160852
>>160851
Немного крипоты.
#366 #161045
Как вытащить текстуру из видеопамяти? Отрендерил сцену через фреймбуфер в неё, теперь хочу сохранить как bmp.
>>161049>>161050
#368 #161050
>>161045
Нашел glGetTexImage(). Надо таки прочитать все доки.
9 Кб, 299x138
#369 #161488
Чуваки я тут задумался о такой вещи.
Что видеокарте отрисовать проще один quad с пустыми участками в текстуре или десяток другой полигонов образующие контур тех мест что заняты на текстуре.
>>161491>>161495>>161548
#370 #161491
>>161488
смотря который шейдер жырнее.
#371 #161495
>>161488
Ставлю 16 пикселей на квад.
#373 #161551
>>161548
значит особой разницы нет, что рисовать два трингла(quad) как плоскость для всей картинки, или произвести отсечение пустых участков образуя контур картинки с помощью полигонов.
18 Кб, 622x379
#374 #162860
Всем привет.
Кто-нибудь может пояснить за order independent transparency? Какой самый простой алгоритм, и реально ли новичку реализовать его в программе на opengl? (и обязательно ли для реализации алгоритма работа с шейдерами?)
>>162909
#375 #162909
>>162860

> Какой самый простой алгоритм


Сортировка по глубине на цпу. Самописные шейдеры ненужны. Баги у пересекающихся полупрозрачных квадов/мешей.
#376 #163000
Ребята, доставьте пожалуйста что-то про WebGL, чтобы я прочел и смог делать такое: http://madebyevan.com/webgl-path-tracing/
>>163099
#377 #163099
>>163000
Когда webgl будет в продакшене, маня?
>>163508
#378 #163508
>>163099
а что мешает его юзать ? все браузеры уже поддерживают. куча библиотек тоже есть.
>>163712
#379 #163712
>>163508
0.00000000000000000000000000000000 практической пользы
>>164837
sage #380 #163736
Аноны, подскажите, пожалуйста!

Был у меня тупой процедурный код, рисовавший один квад, все как положено: vertex array object, vertex buffer object, index buffer object, шейдерная программа (OpenGL 3.3).

Стал я заворачивать все в объекты.
Текстура: пиксельный массив (хранится до передачи на видеокарту) и параметры, включая текстурный объект.
Материал: шейдерная программа и ссылки на текстуры;
Меш: вершины, индексы, vertex buffer object и index buffer object;
Модель: ссылки на материал и меш, vertex array object, атрибуты для шейдерной программы.

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

Пока все это барахло писал, ни разу естественно не запускал на отрисовку, только отлаживал взаимодействие между объектами и потоками. Сейчас перенес кусок кода из старой процедуры в метод отрисовки модели и обломался. Ловлю SegFault на вызове glDrawElements/glDrawArrays (однофигственно). Даже попытка вызвать через них отрисовку только первого треугольника падает. Сижу второй день, отлаживая в gDEBugger, он мне показывает, что вроде бы сейчас все норм, все буфера правильно заполнены (была например тупая ошибка экспорта меша, когда я забыл правильно выставить endianness, и еще более тупая, когда не в том порядке читал данные из файла), правильно прицеплены, и т.д. Надеюсь, что gDEBugger доверия заслуживает, и что правильно показывает данные,

которые уже в видеопамяти.

Я даже попробовал вместо загрузки модели из файла заполнить ее буферы с помощью старого кода на один квад (4 вершины по 3 флоата на координаты и 2 на текстурные координаты, 6 индексов - целое без знака). Результат тот же самый - Segmentation Fault. Кто выбивает его? Не понимаю вообще.

Вот тот метод отрисовки: http://pastebin.com/mAvkBjUC

Кто-нибудь ещё сталкивался с такой проблемой?
sage #380 #163736
Аноны, подскажите, пожалуйста!

Был у меня тупой процедурный код, рисовавший один квад, все как положено: vertex array object, vertex buffer object, index buffer object, шейдерная программа (OpenGL 3.3).

Стал я заворачивать все в объекты.
Текстура: пиксельный массив (хранится до передачи на видеокарту) и параметры, включая текстурный объект.
Материал: шейдерная программа и ссылки на текстуры;
Меш: вершины, индексы, vertex buffer object и index buffer object;
Модель: ссылки на материал и меш, vertex array object, атрибуты для шейдерной программы.

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

Пока все это барахло писал, ни разу естественно не запускал на отрисовку, только отлаживал взаимодействие между объектами и потоками. Сейчас перенес кусок кода из старой процедуры в метод отрисовки модели и обломался. Ловлю SegFault на вызове glDrawElements/glDrawArrays (однофигственно). Даже попытка вызвать через них отрисовку только первого треугольника падает. Сижу второй день, отлаживая в gDEBugger, он мне показывает, что вроде бы сейчас все норм, все буфера правильно заполнены (была например тупая ошибка экспорта меша, когда я забыл правильно выставить endianness, и еще более тупая, когда не в том порядке читал данные из файла), правильно прицеплены, и т.д. Надеюсь, что gDEBugger доверия заслуживает, и что правильно показывает данные,

которые уже в видеопамяти.

Я даже попробовал вместо загрузки модели из файла заполнить ее буферы с помощью старого кода на один квад (4 вершины по 3 флоата на координаты и 2 на текстурные координаты, 6 индексов - целое без знака). Результат тот же самый - Segmentation Fault. Кто выбивает его? Не понимаю вообще.

Вот тот метод отрисовки: http://pastebin.com/mAvkBjUC

Кто-нибудь ещё сталкивался с такой проблемой?
>>163747
146 Кб, 500x500
43 Кб, 600x540
#381 #163747
>>163736
ГДач! Ты резиновая уточка!
Я потратил два дня на отладку, полчаса на вдумчивое описание проблемы, а через десять минут заметил, что в методе загрузки модели на видеокарту (то место, где связываются меш и шейдер) ПРОСТО ОТСУТСТВУЕТ привязка входных атрибутов шейдера к непосредственно разреженным данным в вершинном супе (glVertexAttribPointer). Разумеется glDrawArray/glDrawElements охреневает от моей попытки послать его читать неопределенный указатель.
Всем удачи, успехов, и тоже быть повнимательнее!
#382 #164269
Ребята!

Почему в доках для OpenGL ES 2 написано, что glVertexAttribPointer можно кормить всякими приколюхами таких типов: GL_BYTE, GL_UNSIGNED_BYTE, GL_SHORT, GL_UNSIGNED_SHORT, GL_FIXED, GL_FLOAT.

А в доках для GLSL 1.0 (который юзается в этом огл), написано что есть только такие типы: bool, int, float.

Есть какой-то смысл, чтоб скармливать glVertexAttribPointer GL_UNSIGNED_BYTE, GL_SHORT etc, или есть смысл кормить только GL_FLOAT?
>>164278>>164295
#383 #164278
>>164269

> написано что есть только такие типы: bool, int, float.


Это в шейдере.

> Есть какой-то смысл, чтоб скармливать glVertexAttribPointer GL_UNSIGNED_BYTE, GL_SHORT etc, или есть смысл кормить только GL_FLOAT?


Обычно да, юзается gl_float, но можно попробовать упаковывать эти самые флоаты в инты для передачи в шейдеры и там распаковывать
>>164835
#384 #164295
>>164269
ты не путаешь названия типов с именами констант?
#385 #164659
Еще раз всем привет.
Как замерить fps у своей opengl программули?
>>164661
#386 #164661
>>164659
glFinish и около него считай фпс юзая время из стандартной либы твоего языка
>>164833
#387 #164831
Я нарисовала 2 ёбанных треугольника в распрекрасном С++ OpenGL я БАГИНЯ о лол. я БАГИНЯ!!!
а ещё и дя, я пидараск, лол, :3
64 Кб, 586x604
#388 #164832
Сегодня графонорождённый одногрупник сказал, что опенжл НЕНУЖЕН. И, вообще, на нём никто не работает и йобу на нём не делают, ведь для этого есть директХ. Я всё.
>>164839>>171446
#389 #164833
>>164661
я юзаю примерно такой код.
\tglutSwapBuffers();

\tglFinish();

\tFPS();

рисую 2 ёбанных треугольника . фпс в Release-e без glFinish примерно 6000-7000.

с финиш до SwapBuffers примерно 4000
с финиш после SwapBuffers примерно 3700
если я вызываю 3 Finish после SwapBuffers фпс проседает до 2000. почему так?
#390 #164835
>>164278

>упаковывать эти самые флоаты в инты


может инты в флоаты? зачем флоаты в инты упаковывать?
#391 #164837
>>163712
поцчеиу ви таг считаете?
#392 #164839
>>164832
вот на самом деле тоже интересует этот вопрос. почему все ноют о том что OpenGL нинужен. Насколько я знаю и представляю OpenGL используется в слабых смартфонах, высокопроизводительные смартфоны Android ные смартфоны поодерживают DirectX? На ИФоны есть Metal вроде как уже. Хотя вопрос с DirectX тоже стоит. Он там есть? Или может все юзают CoreGraphics? Или может всем похуй и все юзают Сасоs2Д? Или можэт вапще мёртворождённый Флешь? Или все писают кипятком от каробки Unity. Или таки удобнее юзать OpenGL?

OpenGL по идее везде работает. Почему все ноют, что на нём всё так плохо. Куча подявзок на многие языки. В Android ной Jav-е есть аж 3 вида подвязок. из пэкиджа com.android, com.khronos и в NDK. Всякие там приставки хуеставки его тоже поддерживают вроде как. В Цпп родной интерфейс. Под сладкий-тупой-медленный Python есть подвязки. Этот ваш не нравящийся вам WebGL вполне себе на OpenGl основан. Вай соу сериоуз?

Чем ДиректХ так лучше OpenGL?
9 Кб, 440x560
425 Кб, 1023x1022
65 Кб, 359x347
#393 #164856
В общем тема такая охуел от шейдеров немного не понял в GLSL хочу сделать маску. Имеем изображение (фигуру) и какой нибудь бесшовный фон. в Итоге получаем фигуру окрашенную этим фоном.
Хуй знает как но сделал кое какой код:
fragmentShader:
[CODE]#ifdef GL_ES
precision mediump float;
#endif

varying vec4 v_color;
varying vec2 v_texCoords;
uniform sampler2D u_texture;
uniform sampler2D u_maskTexture;

void main() {
vec4 color = v_color texture2D( u_texture, v_texCoords );
\tvec2 maskCoords = vec2(v_texCoords.x 2.0, v_texCoords.y 12.0);
vec3 mask_color = texture2D(u_maskTexture, maskCoords).rgb;
if( color.a == 0.0 ) gl_FragColor = vec4( color.r, color.g, color.b, color.a );
else gl_FragColor = vec4( mask_color.r, mask_color.g, mask_color.b, color.a );
}[/CODE]

vertexShader:
[CODE]attribute vec4 a_position;
attribute vec4 a_color;
attribute vec2 a_texCoord0;
attribute vec3 a_maskTexture;

uniform mat4 u_projTrans;

varying vec3 v_maskTexture;
varying vec4 v_color;
varying vec2 v_texCoords;

void main() {
v_color = a_color;
v_maskTexture = a_maskTexture;
v_texCoords = a_texCoord0;
gl_Position = u_projTrans a_position;
}[/CODE]

Не особо понял что такое v_texCoords и что вместо него передать надо. Плиз гдач выручай
9 Кб, 440x560
425 Кб, 1023x1022
65 Кб, 359x347
#393 #164856
В общем тема такая охуел от шейдеров немного не понял в GLSL хочу сделать маску. Имеем изображение (фигуру) и какой нибудь бесшовный фон. в Итоге получаем фигуру окрашенную этим фоном.
Хуй знает как но сделал кое какой код:
fragmentShader:
[CODE]#ifdef GL_ES
precision mediump float;
#endif

varying vec4 v_color;
varying vec2 v_texCoords;
uniform sampler2D u_texture;
uniform sampler2D u_maskTexture;

void main() {
vec4 color = v_color texture2D( u_texture, v_texCoords );
\tvec2 maskCoords = vec2(v_texCoords.x 2.0, v_texCoords.y 12.0);
vec3 mask_color = texture2D(u_maskTexture, maskCoords).rgb;
if( color.a == 0.0 ) gl_FragColor = vec4( color.r, color.g, color.b, color.a );
else gl_FragColor = vec4( mask_color.r, mask_color.g, mask_color.b, color.a );
}[/CODE]

vertexShader:
[CODE]attribute vec4 a_position;
attribute vec4 a_color;
attribute vec2 a_texCoord0;
attribute vec3 a_maskTexture;

uniform mat4 u_projTrans;

varying vec3 v_maskTexture;
varying vec4 v_color;
varying vec2 v_texCoords;

void main() {
v_color = a_color;
v_maskTexture = a_maskTexture;
v_texCoords = a_texCoord0;
gl_Position = u_projTrans a_position;
}[/CODE]

Не особо понял что такое v_texCoords и что вместо него передать надо. Плиз гдач выручай
>>166850>>167948
#394 #164898
Господа, доставьте туторы по WebGL, с легкой руки взял как тему на диплом WebGL, а придумать, что вообще делать, как-то никак. Может есть у кого-то идея или уроки, по которым можно что-то эпическое сделать?
>>164942>>164959>>164962>>164978
#395 #164942
>>164898
В инете полно эпичных демок и даже с пояснениями, неужели не нагуглил?
>>165008
#396 #164959
>>164898

> с легкой руки взял как тему на диплом WebGL


Лошара!
>>165008
#397 #164962
>>164898
http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/
Вот тебе эпическая шняга, с разъяснениями, осилишь сам такую сделать?
Только в чем смысл диплома? Бакалаврский курсач что ли?
>>165008>>169729
#398 #164978
>>164898
держи охуенны тут. всё по шагам. и всё такое.
http://www.webglacademy.com/courses.php?courses=0|1|20|2|3|4|23|5|6|7|10#0
>>165008
#399 #165008
>>164962
>>164978
Ничего себе, спасибо большое, то что надо, придется потеть. Ну да, бакалаврский, баловство конечно, но всё равно важный шаг на жизненном пути.

>>164942
Демки крутые нагуглил, а пояснения только к совсем энтри левелу.

>>164959
Бывает.
Нарисовать сферу. #400 #165163
Как я могу сгенерировать сферу в OpenGL с заданным радиусом (получая на выходе набор вертексов и набор индексов, по которым отрисовывать треугольники)?
>>165166>>165277
#401 #165166
>>165163
Ебанутый? В гугле забанили? Формулу сферы не знаешь? Найти не можешь? Пиздец.
>>165173>>165277
#402 #165173
>>165166
Там не так всё просто, сучара.
>>165176
# OP #403 #165176
>>165173
Ну пиздец. Берешь формулу, проходишь по ней циклом с нужным шагом. Триангулируешь. Готово!
>>165277
sage #404 #165277
>>165163
>>165166
>>165176

Никак. Это только через библиотеку glu.
Гугли функцию gluSphere.
#405 #166850
>>164856
Ну и че, где прокодеры двача?
>>167084
#406 #167084
>>166850
Залей на пастбин какой-нибудь, я слепой и непонятно нихрена без подсветки и отступов нормальных.
А еще поставь себе RenderMonkey, он хоть и старый, но довольно годный для быстрой обкатки шейдеров на GLSL.
>>167948
#408 #169729
>>164962
Вот это просто запредельная штука, ребята, а есть такая же, но с видео-туториал на 10 часов, где всё наглядно объясняется?
#409 #169732
>>167948
Юзай лучше glsl 330
32 Кб, 800x600
#410 #170449
Я тут думал-думал и вот что надумал: как в диабло-3D-дрочильнях с видом сверху обрезаются спрайты и объекты за стенами? Пикрелейтед.
Что если партиклы от эффектов считаются на ГПУ? Заранее вычисляются препятствия на ЦПУ? Или что-то передается в шойдеры?
>>170456>>170463
#411 #170456
>>170449

> Я тут думал-думал и вот что надумал: как в диабло-3D-дрочильнях с видом сверху обрезаются спрайты и объекты за стенами?


Z-Buffer
>>170465
sage #412 #170463
>>170449
Occlusion Culling
>>170465
43 Кб, 680x270
49 Кб, 640x480
#413 #170465
>>170456
>>170463
Для этого надо, чтоб загораживало что-нибудь, черный плейн но если встать рядом со стеной, то персонаж и область вокруг него просвечивается. Скриншеты, например.
>>170469
sage #414 #170469
>>170465
Как в д2 просто if пл draw orderу, если тип спрайта стена и его порядок отрисовки выше чем у героя, то рисовать с прозрачностью. Как в ф2 так же, просто в 2 драв кола, рисуешь все что ниже героя и героя, потом меняешь шейдер на другой с яйцом и дорисовываешь остальное (в шейдер передаешь координаты героя и радиус).
>>170471
sage #415 #170471
>>170469
Ну это все о 2д спрайтовые изометрию. Как в 3д окружении сделать хз.
>>170526
#416 #170526
>>170471
Wasteland 2 на том же хуюнити, расковыряй его да посмотри.
#417 #170566
Что читать, чтобы научиться делать годноту как тут: http://glslsandbox.com/ ? Пробую разбирать понравившиеся примеры - ето пиздец, я тупой и дунно как такое писать.
>>170571
#418 #170571
>>170566
Матешу.
http://glslsandbox.com/e#24995.1
#419 #171372
Братцы, заебался с камерой. Мне нужно чтоб она крутилась на все 360 градусов мышкой во все стороны.
Сделал 2 вектора up и right, и вращаю их друг относительно друга пропорционально перемещению мыши, а направление получаю как cross(up, right), по началу ок, но беда в том, что через некоторое время эти вектора становятся не перпендикулярными, понимаю, что это из-за погрешностей floating point, но сука, как побороть? Мне нужно именно вращение камеры именно относительно ее предыдущего положения, а не как в шутерах.
>>171374>>171416>>171475
#420 #171374
>>171372
Зачем тебе right? Он тупо без задачь.

Попробуй (dir, up), dir - вращай пропорционально мышке.
>>171380
#421 #171380
>>171374
Если, dir буду вращать вокруг up для того чтоб смотреть влево-вправо, то вокруг чего вращать up чтоб смотреть вверх-вниз?

Подчеркиваю, мне ненужно чтоб камера сохраняла ориентацию относительно какой либо плоскости, пусть заваливается в любые стороны, но нужно свободное вращение без ограничений.
>>171402
sage #422 #171402
>>171380

>то вокруг чего вращать up чтоб смотреть вверх-вниз?


относительно cross(up, dir)
форман.жпг
#423 #171416
>>171372
Что тебе мешает вместо двух векторов изменять view-матрицу и хранить каждое ее состояние?
То есть у тебя есть изначальное положение и view-матрица для каждого состояния камеры. Таким образом вектора всегда будут перпендикулярны и предыдущее состояние будет так же задаваться view-матрицей.
>>171418
#424 #171418
>>171416
То, что ньюфажина, и не понимаю как это сделать. Точнее я понимаю, как сделать матрицу поворота, но как ее менять нужным мне образом уже не понимаю. Будь няшей, поясни или ссылочку дай.
#425 #171446
>>164832
Какая специальность?
#426 #171474
У меня вот так:

float[] c = camera.getCamera();
float[] u = camera.getUp();

float[] orto = Vector3f.crossProduct(u, c);
Vector3f.normalize(orto);

Quaternion q = Quaternion.product(
Quaternion.fromAxisAndAngle(u, cameraLeftRight_),
Quaternion.fromAxisAndAngle(orto, cameraUpDown_));

c = Quaternion.rotate(c, q);
Vector3f.divLength(c, cameraRadius_);
camera.setCamera(c);

float[] t = camera.getTarget();
t = Quaternion.rotate(t, q);
camera.setTarget(t);

u = Quaternion.rotate(u, q);
camera.setUp(u);

Здесь еще таргет поворачивается и меняется расстояние между камерой и таргетом. Все на float, вращал много но проблем не было.
Возможно нужно пересчитывать up не поворотом старого а произведением orto x up
>>171475>>171482
#427 #171475
>>171372 -> >>171474
#428 #171482
>>171474
Кватернионы-кватерниончики. Спасибо анон, покурю.

Впрочем мой способ тоже заработал, когда я стали пересчитать не оба вектора от старых значений, а последовательно.
#429 #171491
Ребята, зачем вы апи насилуете, просто интересно. Вы хотите игры делать или вас просто прет от графона?
>>171493>>171495
#430 #171493
>>171491

Мне это показалось проще чем разбираться с движками. Сейчас думаю попробовать какой-нибудь но хер же выберешь.
>>171520
#431 #171495
>>171491
Чтоб разобраться в основах. Начав с самого верха, часто сталкиваешься с непониманием, откуда взялся косяк и как его победить.
>>171520
#432 #171520
>>171493
Юич бери. Бесплатный и мощный.
>>171495
Это если бы ты начал дом строить с добычи руды для выплавки молотка.
>>171529>>171646>>171648
#433 #171529
>>171520

>Это если бы ты начал дом строить с добычи руды для выплавки молотка.


Если бы я лез под капот opengl, то аналогия была бы верной.
А так скорее изучение материалов, методов строительства, инструментов.
>>171534
#434 #171534
>>171529
Тебе бы векторов хватило и тригонометрии.
>>171647
#435 #171646
>>171520

Шарповый :/
#436 #171647
>>171534
Если придётся заниматься какой-то просто задачей, то монструозный игровой движок, конечно хорош, но слишком большой для такого дела.
Также не стоит забывать про OpenGL ES.
#437 #171648
>>171520

>Это если бы ты начал дом строить с добычи руды для выплавки молотка.


С изучения сопромата, изучения разных материалов типа кирпича, газобетона и всей подобной хуйни для нормального рассчёта нагрузки на разные части здания.
Выплавка молотка — это свой софтверный рендер городить.
#438 #171723
Помните, в Морровинде интериоры строились из блоков пикрелейтед? Так вот, как отрисовывать геометрию: каждый блок рисовать по отдельности или создавать один буфер и записывать туда вершины и аттрибуты? каждого уже трансформированного блока то есть если уровень состоит из блоков А B C A, то в буфер записываются сначала все вершины блока А после трансформации, потом пишем вершины блоков В, С и А?
>>171731>>171760
#439 #171731
>>171723
Первое. Так ты можешь заранее определять, что какая-то часть интерьера в принципе рисовать бессмысленно.
>>171751
#440 #171751
>>171731
А вот у таких блоков есть прикол, что два соседствующих ребра двух моделек хоть вроде и имеют одинаковые координаты, на стыке этих двух ребер появляется просвет в виде точечек или небольших отрезков. Как с таким бороться?
#441 #171760
>>171723
Когда игру-то делать начнешь?
>>171778
#442 #171778
>>171760
Уже делаю.
#443 #172300
Привет. Есть один маленький, но очень важный для меня вопрос. Сейчас я разрабатываю одну игру на пека (с перспективой ее же разработки под iOS и Android), причем ориентирована она больше на сенсорное управление, хотя и мышкой тоже вполне себе нормально будет управляться. С выором языка программирования проблем не возникло. Так как разрабатывать собираюсь и под мобильные платформы чуть позже, предпочел выбрать OpenGL, а не DirectX. Но тут передо мной встал вопрос: а какую его версию использовать? 2., 3. или 4.*? Весь казус в том, что слабенькие видеокарты не поддерживают 4 версию, а некоторые не поддерживают и третью. А на виндопланшеты ставят как раз всякие атомы и, изредка, i3/i5. Как думаете, аноны, под какую все-таки версию OpenGL заточить свою игру?
>>172301>>172303
#444 #172301
>>172300
2., 3., 4.*
Фикс
#445 #172303
>>172300
Без заточки. На пека ориентируйся на 3.3, на ES - 2.0
>>172385
#446 #172385
>>172303
А будет ли 3.3 работать на виндопланшетах на атоме? Просто я так мельком посмотрел все атомы, и все они вроде бы (я могу ошибаться), не поддерживают 3 версию. Из-за этого я и не могу определиться. Ибо для меня сенсорные устройства все же приоритетнее, да и сама по себе игра не шибко требовательна к графике. Другое дело что я могу ошибаться насчет атомов и поддержки на них версии 3.3
>>172414>>172424
#447 #172414
>>172385
Ты смотри что за железо в этих атомах и смотри драйвера к нему.
#448 #172424
>>172385
ОГЛ - набор расширений, каждая новая версия добавляет какие-то свои новые расширения. Если, например, использовать только расширения начальной версии ogl 2.0, то приложение будет работать на любой версии. Если использовать расширения, которые не входят в состав начальной версии, то приложение будет на любой версии, в состав которых входят используемые расширения.
#449 #172800
>>141146
Годнота и с примерами кода.
http://docs.gl
>>173295>>173348
sage #450 #173295
>>172800
Потом добавим в шапку, спасибо.

офтоп
Бже, сколько же кириллов повсплывало в ГД, я хуею.
Хорошо хотьв уютный ОГЛ тредик не лезут.
>>173339>>173348>>173369
12 Кб, 200x200
sage #451 #173339
>>173295
Я тут)))0
Просто тут байтоебы тупые хуйней страдают вместо того чтоб игры делать и вообще тут все дохлое и тухлятиной воняет)) Пошел на хуй мамку таою ибал азазаз))0
>>173407
# OP #452 #173348
>>172800
Таки действительно годнота.

>>173295
Да, но с другой стороны, если бы тут народу было как год назад, то нас бы пидорнули, как остальную тематику.
>>173443
sage #453 #173369
>>173295

>Хорошо хотьв уютный ОГЛ тредик не лезут.



Невостребованное говно снова мнит себя илиткой?
sage #454 #173407
>>173339
Но ведь байтоебам действительно не место в этом разделе.
Надо поднять вопрос о переселении этих петухов куда-нибудь подальше отсюда, так как их фактическая деятельность к тематике раздела относится чуть более чем совсем никак. Рисование квадратиков и верчение кружочков по полтора года - это не геймдев.
#455 #173443
>>173348

>пидорнули, как остальную тематику


Падажжи, ебана.

Тоесть основной да-да, основной и единственный тред по АПИ для мобильных устройств пидорнут из /гд? Учитывая что сейчас все уходит в мобильное
Как-то глупо получается.
>>173509
#456 #173509
>>173443
Имел в виду, что если бы было мало посещений, то убрали бы доску из списка досок, как многие другие.
6 Кб, 92x116
#457 #173510
Привет, glАнтоны. Хотел спросить, как лучше хранить меши в бинарниках, чтобы читать их как можно быстрее и проще. Допустим, модель имеет только один материал (т.е. индексы материалов на треугольниках мы в файле не храним).
Первые 2 int в файле это количество вершин и количество треугольников.
Далее подряд идут координаты вершин (по 3 float), за ними нормали (по 3 float), и после них текстурные координаты (по 2 float). После этого идут индексы вершин, образующих треугольники (по 3 int на треугольник).
Нормально ли так делать или можно придумать что-нибудь получше?
>>173544
12 Кб, 200x200
#458 #173544
>>173510
Зависит от того, как ты биндишь аттрибуты. Если все в один буфер, но локаторы аттрибутов линкуешь через смещения, то оставляй как есть. Если биндишь типы аттрибутов в отдельные буфера, то сначала идут n-значений одного типа аттрибутов, потом другого. Помести в начало заголовка инфу, что этот бинарник хранит меш. Если хочешь еще больше ускорения, то склеивай все меши в один файл, не забыв поместить в заголовок названия каждого меша и смещения головы и хвостов.
>>173546>>173557>>173806
#459 #173546
>>173544
Бля, это кукла картинку прицепила))
#460 #173557
>>173544
Спасибо, подумаю.
#461 #173806
>>173544
Для когерентности доступа лусше пихать все в один буфер но не со смещениями, а структурой ( со всеми атрибутами пер обджект).
561 Кб, Webm
522 Кб, Webm
#462 #174119
OGL ES. Без теста глубины, с тестом глубины. В чем может быть причина? Z-координаты вершин 0.2 + 0.1n (где n - номер треугольника, 1-4)
>>174123>>174137
#463 #174123
>>174119
Код давай.
Шейдеры, судя по всему, одинаковые?
>>174127
#465 #174137
>>174127
>>174119
Кажется разобрался. glClear(GL_DEPTH_BUFFER_BIT) обязательно вызывать при каждой отрисовке кадра?
>>174138>>174177
#466 #174138
>>174137
Обязательно. Спасибо.
#467 #174177
>>174137
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
#468 #175349
Есть какие-нибудь практические ништяки, доступные нубу, из-за которых имеет смысл выбирать OpenGL а не DirectX? Я имею ввиду вроде убер-графона в три строки, или еще чего. Кроссплатформенность не кажется мне таким уж преимуществом.
>>175379>>175484
#469 #175379
>>175349
Простой апгрейд, кроссплатформенность, именно, что платформы, то есть и мобилы, и пека, и сосноли на мой взгляд, OpenGL проще осваивается, чем DX, да и код выглядит проще. Но под DX больше всяких материалов, учебников там, статей, в сдк кучи примеров.
#470 #175484
>>175349

>нубу


Нубу в рендер лезть противопоказанно.
Юзай Анрыло или еще какое двигло, там тебе будет графон за пару строчек.
>>175513
#471 #175513
>>175484
Бля, а если анрыл не сможет в многопользовательность и большой мир? А он сможет, кстати? Ну то есть если это не получится у меня, я хотя бы буду представлять, какие костыли куда поставить. Да и вообще велосипеды - наше все. Я отдаю себе отчет в том что я долбаеб, но все же я всегда мечтал написать игру, а с использованием готового движка это уже как-то не то. Хотя хуй знает. Глядишь закончу институт и там мои амбиции пообрежуться
>>175536>>175670
#472 #175536
>>175513

> Бля, а если анрыл не сможет в многопользовательность и большой мир?


А ты сам-то сможешь?
#473 #175670
>>175513

Какое дело граф-движку до многопользователей и большого мира? Линейка и eve на анреал.
#474 #177544
Пора подготавливать перекот
>>177546>>177549
#475 #177546
>>177544
Приходи через пару месяцев.
>>177549>>177552
#476 #177549
>>177544
>>177546
Недавно наткнулся на один полезный ресурс.
Можно создать что-то вроде каталога линков и разбросать их по категориям.
Да и редактировать удобно.
Выглядеть будет, примерно, вот так: https://papaly.com/alinnert/dMw6/Web-Development
Что думаете по этому поводу?
>>177552>>177627
#478 #177553
>>177552
Какой же ты дебил.
Назхуя?
Ещё 20 постов было.
>>177556
# OP #479 #177556
>>177553
Удваиваю. Ну ладно, перекат так перекат.
>>177560
# OP #480 #177560
>>177556
Эх, хотел еще линков добавить, а тут такая хуйня. Ну ладно, в тред накидаю.
#481 #177627
>>177549
Хипсторство какое-то. Просто длинный список отгоняет нюфаков по-лучше.

Хотя если не лень чому бы нет..
#482 #178431
Какие из книг в оп-посте про 3D сейчас актуально читать?
>>178451
# OP #483 #178451
>>178431
Вроде все актуальные должны быть. Сам пока только Game Engine Architecture и Superbible читал, очень годные. На остальные времени не хватает, к сожалению.
>>178476
#484 #178476
>>178451
А, збс.
Я собрался начать читать связку OpenGL Red Book + еще что-нибудь. Про архитектуру движков тогда и почитаю
#485 #182491
Анончик, а LWJGL 3 вообще торт? Когда-то смотрел туториалы чувака Oskar Veerhoek, баловался мелкими проектами. Кто-нибудь вообще использует?
>>190356
#486 #182586
Аноны, а что скажете за cogl3d.org? Есть тут эксперты?
>>182600
#487 #182600
>>182586

>эксперты


>/gd/


Кармаки вас слушают.
>>183254
1667 Кб, Webm
#488 #182916
Сделал бампмаппинг.
К успеху пришёл.
>>182925>>182933>>182964>>183146
#489 #182925
>>182916
Крут. Теперь добавь еще 3 кубика и получи 10 фпс.
>>183236
#490 #182933
>>182916
А теперь сделай energy conservation и linear colorspace.
#491 #182964
>>182916,
У тебя там фпс плюсуется.
>>183236
#492 #183146
>>182916
Обосрался с фпс.
>>183236
#493 #183236
>>183146
>>182964
>>182925
Да, обосрался.
Не обнулял счётчик кадров в конце блока.
#494 #183254
>>182600
Просто интересно, кто-нибудь тут вращал кубик в Cogl? И как оно? Действительно так легко, как обещают?
30 Кб, 600x600
#495 #183543
Имеются две точки на плоскости (А и В), центр отрезка, который они образуют является центром новой системы координат. Как определить в ней координаты третьей точки С?
>>183545
#496 #183545
>>183543
upd. если бы был бы дан угол поворота относительно центра было бы можно высчитать по формулам:
[code]
\tx = x0 cos(a) - y0 sin(a);
\ty = y0 cos(a) + x0 sin(a);
[/code]
но как высчитать этот угол я тоже не знаю, да и должны быть более прямые способы
>>183552>>183554>>183555
84 Кб, 600x600
#497 #183552
>>183545
Вот твой угол.
>>183612
84 Кб, 600x600
#498 #183554
>>183545
Вот твой угол.
84 Кб, 600x600
#499 #183555
>>183545
Вот твой угол.
#500 #183612
>>183552
Для нахождения тангенса придёться использовать достаточно тяжелый sqrt

>да и должны быть более прямые способы

>>183683>>183704
#501 #183683
>>183612
Ты игры хочешь делать, или в оптимизатора играться? Это самый очевидный способ и он хорошо работает. У тебя же не сто мини-карт (или для чего тебе такой фетиш) будет, а всего одна. Не еби гусей, бери что дают, иначе твои поиски грааля на каждом шагу доведут тебя до того, что игоря не будет, а будут вечные поиски. Перфекционизм оставь при себе, будешь надрачивать на него когда займешься оптимизацией УЖЕ ГОТОВОЙ игры.
#502 #183704
>>183612
sqrt по производительности равен делению. Если использовать тот трюк из движка первокваки, то он перестаёт быть медленным.
>>183728
#503 #183728
>>183704
Разве? Какой трюк?
>>183839
#505 #189932
bmp
#506 #190356
>>182491
Юзаю, торт
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 30 октября 2015 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /gd/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски