Нещодавно мені було надано це посилання на сайт підручника від того, кому я передав оригінальну книжку OGL Redbook. Третій заголовок вниз чітко говорить про забуття glBegin () & glEnd () як типовий метод візуалізації. Я дізнався за методом Redbook, але бачу певну користь у VBO. Чи справді це шлях? Якщо так, чи є спосіб легко перетворити код візуалізації та наступні шейдери в VBO та наступні типи даних?
Відповіді:
З сучасними VGL-модулями OpenGL - це шлях, фіксований функціональний матеріал (включаючи glBegin / glEnd та речі між ними) був застарілий з 3.0 та видалений з 3.1.
З основним профілем OpenGL, OpenGL ES 2.0+ та WebGL ви навіть не маєте доступу до старих матеріалів.
Деякі люди думають, що спочатку вивчити старі речі краще, тому що це трохи простіше, але ті речі, які ви дізнаєтесь, здебільшого марні, а потім речі, які вам доведеться вивчати.
Це не лише VBO, вам потрібно використовувати шейдери для всього і робити матричні перетворення самостійно (або використовувати GLM).
Єдиною причиною використання старих матеріалів було б, якщо ви хочете націлити на OpenGL до 2.0. яка була випущена в 2003 році. Є кілька дійсно чітких вбудованих чипсетів нетбуків, які є 1,5, але навіть 1,5 повинні підтримувати VBO, а не шейдери. Або OpenGL ES 1.x, який базується на конвеєрі фіксованих функцій (наприклад, він використовується на старих iPhone). Або OpenGL SC (для критично важливих систем).
Наступні загальновживані функції всі застарілі:
У навчальних посібниках opengl-tutorial.org є те, що, на мою думку, є найкращим способом вивчити OpenGL. Вони покладаються на деякі спадкові речі, але насправді вони не навчають вас. Наприклад, ваш не повинен нічого робити без шейдера, але він працює. І вам потрібно обробляти матричні операції (обертати, перекладати тощо) самостійно, але за замовчуванням ви отримаєте базовий плоский 2D-огляд.
Окрім уникнення застарілих матеріалів, існує маса функцій, які роблять кодування OpenGL набагато приємнішим, але з багатьма з них вам доведеться вирішити, чи все в порядку, вимагаючи новіших версій 3.x + OpenGL та сумісного обладнання.
Більше інформації в публікації, яку я зробив тут .
Якщо вам потрібно підтримати старі OpenGL з якихось причин, ви можете використовувати VBO, коли це можливо, а коли його немає, надайте резервну копію, яка використовує glBegin / glEnd та циклічні передачі для всіх вершинних даних.
З іншого боку, немає реального "простого" способу відновити старий код візуалізації. Ви можете, можливо, реалізувати власну версію функцій, які додають вершини до масиву / вектору, який потім скидає їх у VBO та малює, коли ви підробляєте виклик glEnd. але це було б дуже неефективно, оскільки він би робив це кожен кадр (якщо ви не встановите чек, щоб зробити це лише один раз, але це не працює для анімованих об'єктів), і, ймовірно, буде більше роботи, яка просто переходить на VBO. Я думаю, якби у вас було багато коду, цей підхід може спрацювати.
З VBO, як правило, ви маєте дві основні переваги.
Перевага 1 стосується повністю статичних даних і випливає з того, що ви зможете зберігати ваші вершинні дані в пам'яті, що є найбільш оптимальним для GPU.
Перевага 2 стосується динамічних даних і виникає через те, що можна в будь-який момент часу вказати ваші вершинні дані до того, як використовувати їх для візуалізації, що може краще прокласти конвеєр.
Третя перевага полягає в пакетному пакетному виклику, але він також поділяється на вершинні масиви старої школи, тому я не називаю це спеціально для VBO. Надсилання даних в GPU (або використання даних, що вже є на GPU) багато в чому схожа з дисковим введенням-виведенням і мережевим трафіком - якщо у вас є кілька великих партій, це ефективніше, ніж багато невеликих пакетів.
Хороша (не на 100% точна, але достатня, щоб допомогти вам зрозуміти) аналогія для цього - якщо ви водій автобуса, який повинен привозити 50 людей з одного міста в інше. Ви можете завантажувати їх по одному і робити 50 окремих поїздок - це glBegin / glEnd. Крім того, ви можете посадити всі 50 з них на автобус і просто здійснити одну поїздку - це партія з вершинними масивами або VBO (у випадку VBO 50 людей уже будуть в автобусі;)).
Однак це досягає ціни, і тут ціна полягає в тому, що ви втрачаєте можливість просто вказувати дані вершин як і коли цього вимагаєте. Що ж, гаразд, ви можете це зробити (з деякою додатковою роботою), але ви не отримаєте повну продуктивність свого коду. Натомість вам потрібно подумати більше про свої вершинні дані, як вони використовуються, як (і якщо) їх потрібно оновлювати, чи можна будь-яку анімацію робити в шейдері (таким чином, щоб дані залишалися статичними - VBO дійсно потребують шейдери для чимало випадків анімації, щоб добре працювати) або чи потрібно дотримуватись вершинних даних кожного кадру, ефективні стратегії оновлення, якщо останній тощо. Якщо ви цього не зробите і просто застосуєте наївне перетворення, у вас є дуже високий ризик багато роботи лише для того, щоб кінцевий результат насправді працював повільніше!
Це може здатися великою роботою, коли ви вперше зіткнулися з цим, але це не так, насправді. Потрапивши в такий спосіб мислення, ви дійсно виявите, що це неймовірно просто і майже виходить природно. Але ви можете викрутити свої перші кілька спроб, і вам не слід відштовхуватись, якщо так - викручування - це можливість дізнатися, що ви зробили не так.
Кілька заключних думок.
Наявність даних вашої моделі у форматі, який легко завантажується у VBO, може допомогти вам зробити цей весь процес набагато простішим. Це означає, що вам слід уникати більш складних або екзотичних форматів, принаймні спочатку (і поки вам не зручніший процес); зберігайте речі максимально простими та елементарними під час навчання, і буде менше речей, щоб піти не так, і менше місць, щоб шукати помилки, якщо (або коли!) справи йдуть не так.
Люди іноді відкладаються, якщо вони бачать реалізацію VBO, використовуючи більше пам'яті, ніж оптимізовану / стиснуту реалізацію glBegin / glEnd (вони навіть можуть називати це "відходом"). Не будь таким. За винятком крайніх випадків, використання пам'яті справді не що важливо. Тут явний компроміс - ви приймаєте потенційно більшу витрату пам'яті в обмін на значно більшу продуктивність. Також допомагає розвинути мислення, що пам'ять - це дешевий і багатий ресурс, який можна використовувати; продуктивність - ні.
І нарешті старий каштан - якщо він уже досить швидкий, то ваша робота виконана. Якщо ви потрапляєте в цільовий кадр, якщо у вас є запас місця для перехідних умов, то це досить добре, і ви можете перейти до наступного кроку. Ви можете витрачати багато часу та енергії, вичавлюючи додаткові 10% із чогось, що насправді цього не потребує (там, зробили це, все-таки потрапляєте у пастку), тому завжди враховуйте, що найбільш оптимально використовувати власний час - адже час програміста навіть менш дешевий і менш багатий, ніж продуктивність!