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

[wip] Цикл уроков по OpenGL 3.3 (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 544 Следующая »
#30
19:52, 26 сен. 2010

KpeHDeJIb
> vector3_normal(tangent, tangent);
>
> vector3_cross(normal, v21, v31);
> vector3_normal(normal, normal);
>
> vector3_cross(binormal, normal, tangent);
> vector3_normal(binormal, binormal);
>
> vector3_copy(pv0->normal, normal);
> vector3_copy(pv0->tangent, tangent);
> vector3_copy(pv0->binormal, binormal);
FFFUUUU

я за математику классами. можно и без перегруженных операторов, но хотя бы v1.cross(v2);

для меня больше всего были бы интересны именно аспекты перехода с FFP и предыдущих версий, и то, как сейчас максимально православно принято организовывать пайплайн. то есть, например, простейшая камера, простейшее освещение, но полностью на шейдерах, но свежей версии API. также по-моему главное - лёгкость кода, а не гибкость. то есть приложение в целом может быть организовано как у NeHe, никакой орхетектуры(извините, в смысле "монолит"), никаких врапперов, фреймворков и прочего. голый хардкод OGL, разве что математику перегрузить.

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


#31
20:31, 26 сен. 2010

  Ну тогда сразу и DevIL надо показать в действии, чтобы не этот долбаный TGA грузить, а нормальные форматы изображений. Тем более, что принцип действия там ведь такой же, как и в OGL.

#32
21:46, 26 сен. 2010

Zefick
> Ну тогда сразу и DevIL надо показать в действии, чтобы не этот долбаный TGA
> грузить, а нормальные форматы изображений. Тем более, что принцип действия там
> ведь такой же, как и в OGL.

Считаю это лишнее, DecIL пока не нужен, TGA хватит за глаза, код загрузки там на 80
строк кода и при этом формат держит альфу, что бывает полезно. В итоге для рабочего
проекта все равно нужна тулза преобразования во внутренний формат программы, в тот
же DXT например, и тулза должна работать на стадии препроцесса, но никак не в рантайме,
а для подобных уроков хватит и загрузки TGA.

Suslik
> FFFUUUU
> я за математику классами. можно и без перегруженных операторов, но хотя бы
> v1.cross(v2);
По этому поводу согласен, именно так и решил поступить. С другой стороны минимум
сущностей, более гибкий код, с вынесением платформозависимого кода в отдельные
участки, чтобы потом можно было легко переделать.

#33
22:36, 26 сен. 2010

А что, если сделать в формате .pdf? Мне кажется - это довольно красиво. А формулы на сайте выглядят хреново.

#34
22:44, 26 сен. 2010

Suslik
> для меня больше всего были бы интересны именно аспекты перехода с FFP и
> предыдущих версий, и то, как сейчас максимально православно принято
> организовывать пайплайн. то есть, например, простейшая камера, простейшее
> освещение, но полностью на шейдерах, но свежей версии API. также по-моему
> главное - лёгкость кода, а не гибкость. то есть приложение в целом может быть
> организовано как у NeHe, никакой орхетектуры(извините, в смысле "монолит"),
> никаких врапперов, фреймворков и прочего. голый хардкод OGL, разве что
> математику перегрузить.
>
> возможно, есть ещё смысл сделать ООП обёртки над совсем уж стандартными
> буферами, FBO, шейдерами и подобным. но лишь для того, чтобы структурировать
> код, а не плодить сущности в попытках сделать горе-инкапсуляцию. но главное -
> чтобы код был гораздо прозрачнее, уж обернуть его в свою горе-орхетектуру
> каждый, наверное, сможет сам.
+1

#35
23:04, 26 сен. 2010

Zefick
> Ну тогда сразу и DevIL надо показать в действии, чтобы не этот долбаный TGA
> грузить, а нормальные форматы изображений. Тем более, что принцип действия там
> ведь такой же, как и в OGL.
я сам использую devil, но не думаю, что использовать его в семле - хорошая идея. по-моему, информацию для текстур можно грузить абсолютно любую, например, генерить шашечки процедурно, потому что, как я понимаю, целевой читатель и сам прекрасно понимает, как грузить данные для текстур.

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

#36
23:26, 26 сен. 2010

Suslik
> надеюсь, у тебя есть опыт написания кроссплатформенных приложений, потому что в
> противном случае может получиться большая каша из макросов
Тут два варианта, либо через "if defined", либо подключение разных *.cpp для разных платформ.
И тот и другой вариант имеют как плюсы так и минусы. Но вобщем-то я пока не нацелен на
кроссплатформу, пока онли Win, если будут желающие помочь в поортировании, или будет
время позволять - будем портировать.

#37
0:44, 27 сен. 2010

Suslik
+1
Zefick
-1
KpeHDeJIb
+1
Pixar
+1

#38
1:04, 27 сен. 2010

Ну и вот на злобу дня, создал под все это дело проект в Google Code, адрес http://code.google.com/p/gl33lessons/
Есть еще группа для обсуждений всего проекта, на всякий случай, адрес http://groups.google.com/group/gl33lessons

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

Опять же пока добавил только Makefile'ы для MSYS + MinGW, проект для студии пока на стадии
подготовки, чтобы внедриться в текущее дерево проекта.

Просьба по возможности следить за кодом и комментировать его, либо в самом проекте, либо в
специальной группе, тут комментировать не надо, здесь я буду выкладывать только архивы с
уроками, включая исходные коды и "учебную" часть :)

PS. Т.е. смысл какой, как только будет готов очередной урок - исходники на него пакуются в архив
и более не подлежат изменению, также под них создается отдельный тег в дереве проекта,
с линейной структурой. Конечно нарушать структуру проекта в тегах неправославно, но я пока
не вижу других способов выделять уроки в отдельные самостоятельные единицы внутри проекта.
Так что если есть какие-либо предложения - you are welcome, буду решать как лучше поступить.

#39
2:15, 27 сен. 2010

Еще раз раз про ООП, зачем это надо для небольшого урока...? Чем Nehe подкупает именно простотой. Не надо всяких классов, абстракций и тому подобного. Главное - "конфетка" в виде opengl, а обертку пусть каждый делает свою.
Совсем не понятно, зачем подобного рода конструкции в контексте базового урока по OGL...?

OPENGL_CALL(glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT));

#40
8:34, 27 сен. 2010

Пусть ООП будет там, где оно короче, проще и понятнее.

#41
8:42, 27 сен. 2010

> Совсем не понятно, зачем подобного рода конструкции в контексте базового урока по OGL...?
> OPENGL_CALL(glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT));
Думаю в статье по уроку это будет описано. Вобще говоря это обработка ошибок, к которой нужно привыкать с самого начала.

#42
8:57, 27 сен. 2010

подписываюсь на статьи :)
Но решительно против фреймворка и ООП
Впрочем если под фреймворком подразумевается только создание окна и обработка устройств, то другое дело. А если как у humus'а, то фтопку однозначно!

#43
9:22, 27 сен. 2010

Necrys
> Думаю в статье по уроку это будет описано. Вобще говоря это обработка ошибок, к
> которой нужно привыкать с самого начала.
Да все понятно, только главное понять в контексте чего мы ведем диалог...., правильно, -  "Уроки по OPenGL 3.x и выше для новичков и тех кто сам пугается перехода"
А ведь это всего навсего очистка буфера, а когда надо будет рассказать про VBO, VAO, FBO...и иже с ними, и получится "аля Борисков, humos, G-trunkи, Glus и т.д", за этими многослойными ООПами и классами собственно OpenGL будет не виден.
И в очередной раз все превратится в "посмотрите как я круто умею "обвязывать" функции OpenGL, мой стиль программирования самый самый...".

P.S. ИМХО цель обучить людей не ООПу или стилистике программирования, а использованию OpenGL.

#44
9:34, 27 сен. 2010

RigoN
> И в очередной раз все превратится в "посмотрите как я круто умею "обвязывать"
> функции OpenGL, мой стиль программирования самый самый...".
>
> P.S. ИМХО цель обучить людей не ООПу или стилистике программирования, а
> использованию OpenGL.

Ну, если начнет к этому скатываться - остановите меня кто-нибудь :) А пока еще не
дошли до этих вещей, поэтому рано рассуждать. Например чем удобна обвязка над
теми же шейдерами - обработка ошибок, на которую все кладут болт.

RigoN
> Совсем не понятно, зачем подобного рода конструкции в контексте базового урока по OGL...?
> OPENGL_CALL(glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT));

Очедвино это будет описано в уроке, как правильно заметил Necrys, это обработка ошибок
OpenGL, полу-автоматическая, чтобы не забывать про нее никогда и чтобы в случае чего
сразу же увидеть где был затык. Вобщем-то это простой макрос:

// безопасный вызов функции OpenGL
#define OPENGL_CALL(expression) \
        { \
                expression; \
                if ((g_OpenGLError = glGetError()) != GL_NO_ERROR) \
                        LOG_ERROR("OpenGL expression \"" #expression "\" error %d\n", (int)g_OpenGLError); \
        }

Страницы: 1 2 3 4 544 Следующая »
ПрограммированиеФорумГрафика

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