Лекция 1. Введение. Расчёт матриц камеры и проекции 

Там следующая лекция про Direct X. Значит про OpenGL нету? Нужно дальше искать?

@@voronow3 вообще это даже странно, учитывая что OpenGL - стандарт (ранняя версия даже в российских ГОСТах есть), а DirectX - проприетарная поделка Microsoft, не говоря что под мобилки Андроид ещё долго будет актуален OpenGL ES. С другой стороны DirectX 11 и Modern OpenGL по своему принципу мало чем отличаются. То есть теория примерно одинаковая. Лично я кстати вообще не одобряю изучение компьютерной графики совместно с библиотеками. Для понимания лучше написать собственный PBR визуализатор на CPU (неэффективный, тормознутый, но выдающий норм картинку с самопальным растеризатором, это даёт гораздо больше реального понимания как это работает). OpenGL дофига всего берёт на себя (имея при этом свои особенности, скажем OpenGL любит mipmap'ы и без них работает хреново (а почему так, можно легко понять хорошо разбираясь в теории). Лекции можно посмотреть, но изучать рациональнее OpenGL и затем Vulkan (намного сложнее (!) с нуля не надо точно). Однако зная OpenGL и Vulkan можно портнуть графику почти на любое устройство в мире, разве что Apple традиционно плюёт на стандарты.

@@andrewvsk2368 Спасибо за ценную информацию. Я давно присматриваюсь к OpenGL ES в рамках проекта настольных приложений под Qt и на встраиваемой электронике. Про термин PBR ничего не знаю. Можете, акромя гугления порекомендовать материалы для просвящения?

Спасибо.

В 70-80 годы было очень много работ по растеризации чего угодно: кривые Безье, кривые и поверхности второго порядка, всякие NURBS, массивы вокселей и пр. То есть, мотивация "минимальное количество точек, через которое можно провести плоскость" - это не мотивация. И как это "незачем больше точек хранить"? Ещё как есть зачем. Мы же не 1 треугольник на сцене рисуем? Рисуем поверхности, а их нужно составлять из множества треугольников. И тут уже совсем не очевидно, что сетка треугольников, к примеру, в памяти займёт меньше места, чем какой-нибудь набор поверхностей 2-го порядка. Опять же к примеру, для двумерного случая нам нужно всего 4 точки для представления кубической кривой Безье. Да, это в два раза больше, чем для представления отрезка. Ну и что? Зато объект получился гладкий. Сколько вам надо отрезков что б петлю изобразить? Причём, аффинное преобразование кривой Безье не сложнее отрезка - нужно контрольные точки преобразовать. Но это мы коснулись лишь вопроса объёма памяти. Факторов сильно больше: текстурирование, нахождение пересечений, сглаживание и пр. Любопытно, что в первых версиях OpenGL даже был API для работы с NURBS. Поэтому я бы не считал вопрос "а почему треугольники" столь однозначным.

качество игры и качество кода это разные вещи

В ближайшие дни мы добавим все лекции курса.

Я продублирую комментарий, который уже оставлял раньше на эту тему. В 70-80 годы было очень много работ по растеризации чего угодно: кривые Безье, кривые и поверхности второго порядка, всякие NURBS, массивы вокселей и пр. То есть, мотивация «только 3 точки задают гарантированно плоскость» - это не мотивация. Мы же не плоскости рисуем? Рисуем поверхности, а их нужно составлять из множества треугольников. Или вообще не треугольников. Давайте подумаем про память. Совсем не очевидно, что сетка треугольников в памяти займёт меньше места, чем какой-нибудь набор поверхностей 2-го порядка. Опять же, к примеру, для двумерного случая нам нужно всего 4 точки для представления кубической кривой Безье. Да, это в два раза больше, чем для представления отрезка. Ну и что? Зато объект получился гладкий. Сколько вам надо отрезков что б петлю изобразить? Причём, аффинное преобразование кривой Безье не сложнее отрезка - нужно контрольные точки преобразовать. Опять же вы говорите про нормаль. Нормаль «однозначно определяется» к бесконечному кол-ву классов поверхностей. Но это мы коснулись лишь вопроса объёма памяти. Факторов сильно больше: текстурирование, нахождение пересечений, сглаживание и пр. Любопытно, что в первых версиях OpenGL даже был API для работы с NURBS. Поэтому я бы не считал вопрос «а почему треугольники» столь однозначным.

Можно поискать на сайте курса compscicenter.ru/courses/3d-graphics/nsk/2017-autumn/

Да, я на доске минус потерял где-то по дороге :) У вас правильно получилось вывести. В своё оправдание скажу, что преподаватели всё-таки не роботы и тоже иногда ошибаются ;) Причём это для студентов, с некоторой точки зрения, полезно: им приходится тщательнее прорабатывать материал и уже не выйдет просто так зазубрить и забыть после экзамена. Придётся реально разбираться в текстах. Но, в целом, конечно, лучше б лекторы всё правильно и без ошибок давали. Занятный случай на эту тему был у меня, когда сам в универе учился. Припёрлись мы как-то на досрочный экзамен по матанализу. И лектор там выдал: «У меня в лекциях в некоторых местах допущены ошибки. Ваша задача - найти их, объяснить, что там не так и исправить доказательство». Каждому досталось по две таких теоремы, сидели закуривали собственные же конспекты несколько часов %) Один человек из, по-моему, пяти пошёл сдавать обычный экзамен. Такие дела =) А вам уважуха за внимательность.

@@DrollerTroller там он ещё одну ошибку допустил когда складывал вектора

Зашел узнать почему используется f(z) = (a*z + b)/(z) и именно эта часть лекции вырезана, ну что ж за провал то. Может кто знает где можно эту информацию почерпнуть?

Можно не отвечать, такой вопрос уже был)

Сергей Зинченко спасибо ,посмотрю

@@Ruslan_Ishmuratov есть ещё документ лекций по линейной алгебре

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fNk_zzaMoSs.html - включи русские субтитры.

Да, но там много своей специфики.

Нет.

Нет! Треугольник потому, что только 3 точки гарантированно задают плоскость, соответственно однозначно просто рассчитать нормаль...

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

В теории, тут можно действовать по-разному. Можно честно "отсечь" часть треугольника рамкой экрана (прямоугольником) после проецирования, разбить на треугольники получившееся и растеризовать. Можно уже в процессе растеризации сбрасывать с конвейера пиксели за границей экрана. Но в этих способах есть одна проблема - перспективное деление для вершин, оказавшихся за ближней плоскостью отсечения. Там, потенциально, мы можем и на ноль поделить. Поэтому, обычно, отсечение делается в 3D ещё до перспективного деления. Этот функционал полностью реализован на видеокарте и какие-то рычаги управления для него мне неизвестны. Разве что, в DX12 есть честный консервативный растеризатор. Но я эту тему особо не бурил.

Спс

Есть альтернативное мнение, что надо писать на D. По крайней мере в Remedy (Control, Max Payne, Alan Wake) согласны.

@@DrollerTroller всех агитирую за D!

@@DrollerTroller прекрасный язычище