Комментарии 30
Ну вообще Фрустум — Frustum, а никак не FrustRoom, откуда вы это взяли. Frustum — это усеченная пирамида. en.wikipedia.org/wiki/Frustum
Вообще хорошо все, однако статический конвейер в OpenGL безумно устарел. Ваш проект будет проще переписать, чем портировать на OpenGL ES 2.0
Во первых, статический конвеер не устарел. Для простых приложений, тем более для начинающих — самое то.
Во вторых, OpenGL ES это для встраиваемых систем. Для PC всё же OpenGL 4.x.
Во вторых, OpenGL ES это для встраиваемых систем. Для PC всё же OpenGL 4.x.
Статический конвеер устарел. Начинающим лучше сразу привыкать к связке VBO+ shaders, иначе потом будет тяжело переучиваться. Для простых объектов, конечно, лучше использовать glBegin/glEnd .glBegin/glEnd для low-poly объектов часто оказываются быстрее, чем буфера вершин.
Конечно устарел, современные видеокарты уже не поддерживают даже инструкции статического пайплайна. Там на каждое изменение стейта прослойка в API генерирует заново шейдеры.
Статья интересная и точно будет полезна начинающим для понимания 3D.
Но нельзя ли перед тем, как опубликовать, перечитать все внимательно? В статье куча ошибок. И я не говорю про орфографию. Когда на натыкаешься на такое
понимаешь, в чем дело только после пятого прочтения.
Это не претензия лично к автору, пол хабра этим страдает.
Но нельзя ли перед тем, как опубликовать, перечитать все внимательно? В статье куча ошибок. И я не говорю про орфографию. Когда на натыкаешься на такое
кликаем по правой кнопкой мыши по панели инструментов
понимаешь, в чем дело только после пятого прочтения.
Это не претензия лично к автору, пол хабра этим страдает.
Для новичков надо бы сначала теорию прочитать, например «Математические основы машинной графики», Роджерс Д., Адамс Дж. Книга старая, но математические основы описаны на порядок лучше чем в этой статье, куча примеров, сначала с 2д, потом все на 3д переводят.
Я не мог тут объяснять математические основы, иначе статья была бы очень большой.
На хабре уже имеется, кстати, отличная (и понятная) статья на тему проективной геометрии:
habrahabr.ru/post/126269/
habrahabr.ru/post/126269/
Сарказм?
Почему сарказм? Нет, я сам долго путался и понять не мог, потратил пару часов на вышеуказанную книгу и сразу всё понял, как заново мир открыл, сейчас без каких либо проблем делаю свой движок потихоньку, ради интереса. Просто достаточно было бы подобную книгу указать в статье, можно было бы и не писать.
Спасибо, исправил. Но когда пишешь такую статью, офигиваешь, устаёшь, и проверка ошибок затруднительна.
Udacity недавно на тему 3D выложило курс
www.udacity.com/course/cs291
www.udacity.com/course/cs291
Во время учебы в универе писал такой на C++, если не ошибаюсь, в качестве курсовой. Вот, если кому интересно: bitbucket.org/aiglikov/rubiks-cube (управление — левая/правая/средняя кнопка мыши).
Ну и для полноты картины мой старенький кубик на JS+Canvas без всяких библиотек:
habrahabr.ru/post/100576/
habrahabr.ru/post/100576/
Кубик Рубика состоит из 26 кубиков нерубика(простых кубиков)
Кода было бы гораздо меньше при использовании VBO.
www.arcsynthesis.org/gltut/ — лучше сразу начать читать вот это. Там про современный быстрый и куда более мощный pipeline. Фактически нет никакого смысла учить то, что уже сейчас устарело и никаких вообще знаний про то, как работают видеокарты не дает.
Плохой урок, который учит работе с древним фиксированным конвейером (который на современном железе эмулируется). Имхо уроки по depricated функционалу вообще не должны появляться.
сорри, я не специально, но что-то, когда искал материалы про opengl, в них не было написано, что это древность.
Сорри.
Сорри.
Давайте я вам помогу, и расскажу как избегать такой проблемы на примере вашей ситуации.
Вы захотели писать 3д приложения, но в этом как говорится ни в зуб ногой. Всегда есть 2 варианта, использовать голый API, или использовать библиотеки. Исходим из следующего:
1. Мы хотим заниматься этим профессионально этой областью — наш выбор сначала API, и изучаем именно API, и только потом переходим на библиотеки. К этому времени у нас будет трезвый взгляд и понимание, какая именно библиотека лучше всего нам подходит. Для изучения API мы обязательно должны руководствоваться официальными спеками на апи. Для OpenGL это www.opengl.org/documentation/specs/ Но так же мы можем использовать примеры из интернетов, но обязательно по каждой API функции читать документацию в спеках. В интернете полно устаревших примеров.
2. Мы хотим разово (но качественно) решить наши проблемы. Гуглим библиотеки. Среди библиотек выбираем только те, которые поддерживаются (в интернете полно устаревших библиотек). Ваш этот OpenTK последний раз релизился более двух лет назад: www.opentk.com/project/opentk а найтли билды: sourceforge.net/projects/opentk/files/opentk/nightly/ которые вываливались каждые 2-3 дня, уже не обновляются год. Допустим мы навыбирали актуальных поддерживаемых библиотек. Идем на специализированный форум:
www.opengl.org/discussion_boards/forum.php
www.gamedev.net/page/index.html
gamedev.ru/
И смотрим что народ говорит по этим библиотекам там. Если библиотека практически не упоминается, значит у неё пользователей мало, а это значит слабый фидбек о багах, и слабый саппорт, и скорее всего эта библиотека загнется. Исключение — очень молодые библиотеки.
Ну и в конце концов можно спросить у людей на форуме какую библиотеку мне выбрать, А, B или C.
p.s. Хотя для меня честно говоря странновато, что OpenTK 2010 года релиза использует фиксированный конвеер, и насколько я понимаю, эти методы не помечены как depricated (Obsolete)?
Вы захотели писать 3д приложения, но в этом как говорится ни в зуб ногой. Всегда есть 2 варианта, использовать голый API, или использовать библиотеки. Исходим из следующего:
1. Мы хотим заниматься этим профессионально этой областью — наш выбор сначала API, и изучаем именно API, и только потом переходим на библиотеки. К этому времени у нас будет трезвый взгляд и понимание, какая именно библиотека лучше всего нам подходит. Для изучения API мы обязательно должны руководствоваться официальными спеками на апи. Для OpenGL это www.opengl.org/documentation/specs/ Но так же мы можем использовать примеры из интернетов, но обязательно по каждой API функции читать документацию в спеках. В интернете полно устаревших примеров.
2. Мы хотим разово (но качественно) решить наши проблемы. Гуглим библиотеки. Среди библиотек выбираем только те, которые поддерживаются (в интернете полно устаревших библиотек). Ваш этот OpenTK последний раз релизился более двух лет назад: www.opentk.com/project/opentk а найтли билды: sourceforge.net/projects/opentk/files/opentk/nightly/ которые вываливались каждые 2-3 дня, уже не обновляются год. Допустим мы навыбирали актуальных поддерживаемых библиотек. Идем на специализированный форум:
www.opengl.org/discussion_boards/forum.php
www.gamedev.net/page/index.html
gamedev.ru/
И смотрим что народ говорит по этим библиотекам там. Если библиотека практически не упоминается, значит у неё пользователей мало, а это значит слабый фидбек о багах, и слабый саппорт, и скорее всего эта библиотека загнется. Исключение — очень молодые библиотеки.
Ну и в конце концов можно спросить у людей на форуме какую библиотеку мне выбрать, А, B или C.
p.s. Хотя для меня честно говоря странновато, что OpenTK 2010 года релиза использует фиксированный конвеер, и насколько я понимаю, эти методы не помечены как depricated (Obsolete)?
не помечены.
Насчет OpenTK, конечно грустно, что уже два года нет обновлений. Даже ветка прошлогодняя с говорящим названием есть.
И это при том, что его используют продукты, которые довольно активно разрабатываются. Те же MonoGame, Xamarin.iOS, Xamarin.Android и т.д.
Хоть на форуме и пишут, что он stable и production ready, но отсутствие активности настораживает. Хотя альтернатив у него я не видел. Может кто подскажет?
И это при том, что его используют продукты, которые довольно активно разрабатываются. Те же MonoGame, Xamarin.iOS, Xamarin.Android и т.д.
Хоть на форуме и пишут, что он stable и production ready, но отсутствие активности настораживает. Хотя альтернатив у него я не видел. Может кто подскажет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем эмулятор Кубика Рубика