не могу понять как рисовать в 3D скажем в координатной сетке например определенной от (0,100) по x,y,z .

т.е. у меня есть массив точек с координатами мне надо его отрисовать как point cloud скажем.
можно его просканировать и определить дипазон значений по x,y,z будет (min_x;max_x)x(min_y;max_y)x(min_z;max_z).
и потом в этот координтаный куб надо вывести точки, если я пытаюсь вывести просто так, то получается чушь.

еще неплохо было бы понять как делать приближение\отдаление и как крутить для более удобного просмотра.
возможно у кого то есть готовый проект с этими возможностями т.к. они более менее базовые.

Почему Вы так думаете?

Вообще -- всё задаётся заданием афинных преобразованием координат. man glFrustum glOrtho glScale glTranslate glRotate, ну и вообще теорию линейных афинных преобразований хорошо бы знать.

В OpenGL есть две матрицы, в соответствии с которыми преобразуются координаты вертексов: GL_MODELVIEW и GL_PROJECTION. Они совершэнно одинаково (но последовательно) действуют на координаты, и единственная разница, что первая (GL_MODELVIEW) действует до освещения, а вторая -- после, и её значения не влияют на рассчёт света. Текущая матрица для редактирования выбирается glMatrixMode.

Соответственно, во вторую матрицу имеет смысл запихивать преобразования камеры -- в частности, все задания порта отображэния через glFrustum/glOrtho, а во вторую -- преобразования модэлей (движэние/вращение/и т.д.). Какую из матриц "крутить" для более удобного просмотра, и для приближэния/удаления объекта -- это ужэ дело вкуса.

По поводу крутить/отдалять: получение значений насколько -- вешаетесь на события от мышки (как -- зависит от оконной системы), перемещения с нажатой кнопкой записывает в изменение угла вращения по соответствующей координате. Не забываем брать остаток от деления на 360 -- а то при большых числах могу вылезти неприятные ошыбки округления. Колёсико -- как изменение масштаба. Ещё жэлательно для клавиатуры управление продублировать.
 В процэдуре отрисовки берёте значения углов и изменение масштабов, и вставляете glRotate/glScale.

Это всё действительно для OpenGL 2, но в третьей версии всё это сохранено только ради совместимости и скоро поддерживаться не будет, в связи с чем это использовать не рекомендуется.
В OpenGL 3+ эти операции полностью переложены на плечи программиста - всё делается вручную в шейдерах.

Вот пример для OpenGL3.3 с вращающимся кубом и хороший мануал по матрицам преобразований.

Нет никакой третьей версии. Крайний OpenGL -- OpenGL 1.2, да и то лучшэ ориентироваться на 1.1. Всякие 2 и 3 сделаны исключительно для безсмысленного прожыгания времени, потому ни для чего кроме безсмысленного прожыгания времени не пригодны.
В общем, оно или сдохнет совсем или вся муть из 2 и 3 будет переделана кем-то вменяемым. Скорее, к сожалению, сдохнет, хотя я всё ещё надеюсь на что-то.

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

Более того, версия 3.3 уже вошла в стандарт и поддерживается повсеместно. Что не удивительно, кстати.


Или Вы изучали исходники и имеете претензии к коряво написанному коду?

Ну, холивар.



Третья и четвёртая окончательно перестали быть удобным языком трёхмерной графики. И вообще перестали быть языком трёхмерной графики в общем-то. Довольно  смешно правда, что при этом возможности делать на них что-то кроме графики так и не появилась -- но это неважно.



Как и у 1.1 и 1.2. Точнее, он простой и адэкватный -- в тех местах, где не менялся с 1.1.



И что? Ну, то есть, по-моему у меня не поддержывается -- но я как-то непонимаю, что с того, что какая-то гадость скомпилирована под все известные платформы?



Мне хватило спецыфикацый.

tzirechnoy, скажем так, как только смогу на 1.* использовать все прелести изменяемых вершинных буферов, геометрических шейдеров и прочей новомодной "гадости" прямо "из коробки", сразу же начну писать на нем) Обещаю)

Куча полезных примеров по OpenGL


Это сообщение отредактировал(а) XLAT - 22.2.2012, 23:47

http://bash.org.ru/quote/11258



У Вас вершынный буфер для glVertexPointer получился неизменяемым? Да Вы талант.



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

Но ё-моё, то жэ самое, написанное на Си на клиенте -- на порядок удобнее и мощнее -- хотя казалось бы, от ручной писанины в Си деградировать некуда. И это по-вашэму -- нормальный API??? В начале XXI века? Да так просто не бывает! Нельзя быть настолько олигофреном, чтобы придумать GLSL. Но совместными усилиями комитету удалось немыслимое.

PS Да, API VBO, как ни удивительно, тожэ демонстрирует олигофрению авторов в степени не меньшэ дебильности. Казалось бы, логичная задача, простейшэе, без изящества и дажэ с заметными проблемами скорости, но в общем что-то дающее решэние. Но вот обязательно надо отчебучить что-нибудь такое, чтобы дурь свою продемонстрировать. На ровном месте.

Он позволяет изменять данные прямо в видеопамяти?

Добавлено через 2 минуты и 44 секунды


Вообще-то нет.

А вообще приведите примеры того, что у Вас вызывает столько гнева и как, по Вашему, выглядело бы лучше.
Это будет куда убедительнее криков типа "там все кретины и не лечатся а я такой умный тут в белом пальто стою красивый"

Вы просили изменяемый буфер? Вот Вам изменяемый буфер. А видеопамятью пусть дрова занимаются. 

Кроме прочего, это одна из моих претэнзий к хроносам: OpenGL перестало быть API трёхмерной графики, взамен оно стало набором для битстаффинга некоторого класса современных векторых процэссоров.

То есть вот люди взяли, и понерфили освещение. Было -- вполне рабочее. С пачкой довольно весёлых спец.эффектов. Стало -- вот вам язык из 60-х годов, пишыте сами. 

Было вполне рабочее API для создания объектов сложной структуры и изменения их маленькими кусочками. Тожэ понерфили -- вот вам взамен memcpy(), играйтесь, детки. 
И это -- не последние куски API, которые разработчики радостно выкинули.
Вообще, меня это поражает -- способность гробить код и навыки программистов, наработанные десятилетиями. 

И ради чего? Можэт быть, новые подходы резко упрощают программирование? Делают программы надёжнее? Да фигвам. Точнее, ровно наоборот. И единственный заметный бонус -- спец.эффекты в игрушках (заметный, впрочем, только упёртым цэнителям этих игрушэк).

Кроме прочего, дурацкие цэли с очевидностью отразились и на общем интеллекте создателей. Вот, возьмём хотя бы VBO: ну, есть некоторая логика в задаче -- маленький спид-апчик одного часто встречающегося пути отображэния. Ну, допустим, приняли мы это решэние в виде VBO и управления серверным копированием (у меня оно тожэ вызывает некоторое недоумение своей ограниченностью, собственно, в таком виде как есть -- оно и через DisplayLists нормально могло быть организованно), ну ладно, придумали и придумали. 
Но нафига трогать glVertexPointer? Дебилы криворукие, в glVertexPointer последний аргумент -- указатель! На локальную область памяти. Не число, не тэг -- а в чистом виде указатель. Уроды. Имён функцый им не хватило.

Ну, и сам GLSL. По цэлостности языка он откровенно не дотягивает дажэ до Си. То есть это какой-то привет из 60-х. При том что, казалось бы, в начале XXI века каждый первый программист знает о возможностях автоматической трансформацыи AST для глобальной оптимизацыи, о возможностях pure functions для map-reduce, об алгебраических типах данных -- в общем, обо всех тех мелочах, которые дают возможность строить гибкие, быстрые и распределённые системы. Нет, выбран синтаксис, который как спецыально создан для осложнения суперкомпиляцыи, и система типов данных, которая вообще ничего не можэт, дажэ с отображэнием на жэлезо проблемы есть.

В общем, повторюсь, из API двух- и трёх-мерной графики люди сделали какие-то кривые ручки для колупания в потрохах современных векторных процэссоров. Ручки такого уровня, которые, кстати, подошли бы писателям драйверов, а не прикладным программистам. Это всё абсолютно ужасно, и ни для чего, кроме клепания безсмысленных игрушэк не пригодно.
Потому никакого OpenGL 2 или 3 -- нет.

tzirechnoy, а обратную совместимость и возможность инициализации контекста определенной версии никто и не заметил? Всё поддерживается, хотя и не рекомендуется к использованию.



glНарисаватьКвадратек( икс, игрек, зет );
glПаказатьКартинку();
...
Это вот это нарабатывалось десятилетиями?
----------

А работать с видеокартой напрямую - заведомо быстрее и гибче. БОльшая часть времени обработки кадра, в случае с glVertexPointer, например, тратится на копирование этих самых вертексов в видеопамять. VBO - лучшее, что можно было придумать в данном случае. Очень хорошая оптимизация.

Да - игрушки - для них это важнее всего. Но это, на сегодняшний день, основная часть рынка софта, использующего 3D в реальном времени.
----------

Я в теории компиляторов не силен, да и исходников не видел - не знаю, использует ли данные техники компилятор OpenGL. Но не нравится GLSL - используйте Cg. В чем проблема? Ой. Я забыл. Вам же нужно кучу замечательных типов данных, которых там, почему-то, тоже нет...

----------

И еще - в основе слова после 'ц' всегда пишется 'и' (кроме пяти всем известных исключений).

---
Cg а не Gc, извините - две буквы местами перепутал, а смысл исказился чуть менее, чем полностью.

Это сообщение отредактировал(а) Fynivx - 1.3.2012, 02:19

согласен с tzirechnoy, фигня получилась с шардингами всякими
пошли самым тупым и примитивным путём - путём прямой силы
хотя в самых первых книжках по ЯзПр было такое правило - самый быстрый способ что-то просчитать это когда считать ничего не надо

самое главное - алгоритмы, как не оптимизируй пузырьковую сортировку всегда будет ...

ввели возможность ввода алгоритмов в GPU, ну и хорошо, лишняя мощность никогда не помешает, но вот применение ей нашли через шардинг мягко говоря неадекватное, кроме того с большими проблемами при прикладном программировании (уже 3-й день бьюсь с установкой OpenCL - нету дровушек)