Использую С#+OpenTK.
С помощью OpenGL нужно нарисовать наперед не известное множество относительно сложных объектов и они отличаются), которые можно перемещать по форме. Объекты состоят из линий, закрашенных областей (причем с полу прозрачностью), текста, при их прорисовки используются циклы. В общем пока их не много - меня скорость работы графики устраивает, но если их больше чем штук 30, то при перемещении объекта(ов) (при этом рисую его как полупрозрачный прямоугольник) заметны тормоза. Я так понимаю что это из-за загрузки процессора (грузится наполовину где-то). Можно как нибудь ускорить процесс прорисовки? На ум приходит только одно: все объекты, которые не нужно перемещать сохранить как один фоновый рисунок, а поверх него уже прорисовывать перемещаемые. Или есть другие варианты? Гугл особо не помог, пушо в какую сторону гуглить - я не знаю. 

ЗЫ Что примерно рисую можно посмотреть здесь

Гуглить "списки отображения opengl" ("opengl display list"). В уроках NeHe - урок 12, в OpenGL "Red Book" - глава 7.

kemiisto, 
Спасибо, буду разбираться.
У меня возник другой вопрос, немного не по теме, но спрошу.
Я хотел бы в своем приложении использовать несколько слоев для прорисовки (к примеру фоновый, статические элементы, динамические элементы). Для этих целей можно использовать списки отображения, или есть более подходящие решения?

Проблемка возникла.
Вот моя функция создания списков отображения:

То что она долго выполняется при запуске программы - стерпеть еще можно. Но вот вызов 3го списка - это уже не допустимо:
            GL.CallList(_genList+2);
Вызываю все списки при перемещении мыши. Использование первых 2х - дают большой прирост производительности, но вот третий приводит к сильной загрузке процессора и неимоверным тормозам. Количество объектов - 50, но даже один дает большие тормоза. BuildLists() вызывается всего лишь 1 раз. Что я делаю не так?

Это сообщение отредактировал(а) Anyone - 21.5.2009, 15:59

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

Это сообщение отредактировал(а) Anyone - 24.5.2009, 22:13

Freetype http://www.freetype.org
GLTT http://gltt.sourceforge.net

а чем сейчас текст рисуется?

          _printer.Begin();
            _printer.Print("Block", _font, Color.Black,
                _rectTitle, TextPrinterOptions.Default, TextAlignment.Center);
            _printer.Print(Left.ToString() + ";" + Top.ToString(), _font, Color.Black,
                _rectFooter, TextPrinterOptions.Default, TextAlignment.Center);
          _printer.End();

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

Предлагаю вывод всего текста врапить в один Begin/End (или группировать в несколько по используемым стилям). Проблема стопудово в том, что ты для каждого блока отдельный цикл делаешь. Это ведет к переключению render states, а это напрямую влияет на производительность.

Если бы это было возможным, я бы так и сделал.


Это не проблема, а всего лишь не значительная потеря производительности.
Сам проверял и это я обсудил на форуме офф сайта враппера.

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

Есть ли какие-нибудь способы создания текстурных шрифтов без привязки к платформе?
Ну или накрайняк загрузить текстуры в списки отображения?

Я только начал изучение OpenGL, так что не судите меня строго   

Anyone, м.б. имеет смысл попробовать CEGUI# для GUI? там вроде как реализованы текстурные шрифты. 

Мне нужна максимальная производительность, так как мне придется перерисовывать окно при перемещении мыши, чем тупее либа - тем лучше, потому не хочу еще что-либо дополнительно ставить

Anyone, ну тогда засучивай рукава -- тебя ждет много интересного при реализации всего этого самостоятельно   



перечитал 2 раза, ничего не понял

arilou, видимо имелось ввиду, что чем меньше в библиотеке "обвеса" и наворотов, тем шустрее все будет в конечном счете работать.

Nofate, разработчики middleware врядли согласятся   

Попробывал все тоже самое реализовать с Tao.Framework и Tao.FreeType. Скачал враппер для работы с шрифтами 
отсюда FTclass.cs и меня, в принципе, все устраивает, кроме одного - не могу загрузить шрифт, используется стандартный я так понял, потому что даже если задать не правильное имя - шрифт такой же. При этом некоторые буквы вообще выглядят странно.
Вот как я использую:
ftFont = new FTFont(@"D:\WINDOWS\Fonts\TAHOMA.TTF", out Success);
ftFont.ftRenderToTexture(10, 300);

Есть идеи?

ЗЫ. Писал в саппорт ОпенТК по поводу скорости работы текста. Добавили кеширование с помощью списков отображения при использовании TextPrinter, работает заметно быстрее, гдето так же, как и в Tao.Framework + Tao.FreeType, но последняя связка мне больше нравится, потому что текст хорошо масштабируется и работает все таки быстрее (особенно при загрузке формы и изменении ее размеров).

ЗЫ2. Мой вопрос по поводу FTFont.Write() отпал, потому запостил в этой теме.

Разобрался с предыдущим вопросом.
Ждите следующие   

Это сообщение отредактировал(а) Anyone - 1.6.2009, 18:55

Anyone, позвольте полюбопытствовать вы ушли все-таки от использования OpenTK или используете TAO и OpenTK совместно? И как процесс? продвигается?

Это сообщение отредактировал(а) fomich0ff - 19.6.2009, 08:14

Я использую сейчас ТАО - как по мне - быстрее работает, кроме того команды выглядят как по стандарту, легко переносить из других языков программирования.

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

Anyone, не могли бы Вы ткнуть носом что я делаю не так?
Сейчас я пытаюсь вывести хоть какой-нибудь текст с помощью Tao + FTclass. Скачал пример отсюда, но почему-то у меня весь текст выводится в виде пустых квадратиков (и английский и русский). Я пробовал делать как Вы указывали чуть выше, но результат такой же - квадратики. Вы с такой проблемой не сталкивались? Может надо включить какой-то режим?

ЗЫ. Кстати все пути к шрифтам я изменил на соответствующие для моей машины.

Это сообщение отредактировал(а) fomich0ff - 1.7.2009, 12:43

Таких проблем у меня не было.
Нужно код смотреть.

Ну вобщем-то в коде примера я изменил только пути к шрифтам и все. Единственное на что я могу грешить - на библиотеку freetype6.dll. Она требовалась для запуска примера. Я ее нашел в либах TeX'a. Может версия не та. Может еще что...

Я сделал так.
Библиотеку скачал тут
Кинул в папки проекта Debug, Release файлы со шрифтами и такие dll-ки: freetype6.dll, Tao.FreeType.dll, zlib1.dll.
После этого все стало нормально работать.

Добавлено через 2 минуты и 18 секунд
zlib1.dll можно посмотреть тут: \Program Files\TaoFramework\lib

Спасибо. Завтра попробую.

Долго отсутствовал, потому что не было инета. Значит пишу отчет: на моем компе вывод текста не работает. На других компах все работает нормально. Грешу на то что у меня встроенная видюха и, возможно, кривые дрова. На остальных копмах все карточки внешние. Вобщем засада.

Не работает только текст, или графика вообще?
У меня тоже слабенькая видяха в ноуте, многие расширения не держит.

Графика работает. Медленно, но работает. А вот с текстом чудеса - вместо букв выводит прямоугольники. На других компах буквы видны.

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

Это сообщение отредактировал(а) Anyone - 22.7.2009, 14:11

Ага, спасибо. Попробую.
За этот месяц я чего только не перепробовал. Пока отрисовку текста отложил в сторону. 
У меня возник такой вопрос:
Предположим на экране рисуются несколько тысяч примтивов (треугольники, квадраты, звездочки и т.п.). Все имеют одинаковый видимы размер (например 20х20 пикселей). Как сделать так чтобы при масштабировании (glScaled) всей сцены все эти примитивы не изменяли видимых размеров (т.е. на экране они оставались так же 20х20 пикселей). Пример может быть таким: предположим есть карта какой-нибудь страны. На этой карте звездочками помечены крупные города. Так вот надо, чтобы карта страны масштабировалась, а звездочки - нет (т.е. всегда оставались одного и того же размера).
Надеюсь я понятно объяснил суть проблемы.

Очень просто. Если вся сцена масштабируется в n раз, то те примитивы, которые не должны масштабироваться, нужно промасштабировать в 1/n раз

Значит я правильно думал =) Я так понимаю, что с текстом точно так же? Т.е. чтобы он оставался всегда одного и того же размера нужно масштабировать его в 1/n раз? Я надеялся, что есть какие-то скрытые возможности у OpenGL.
Тогда такой вопрос: есть ли быстрый способ проверить попадает ли рисуемый объект (точка, треугольник, полигон и т.д.) в видимую область или нет? т.е. стоит его рисовать или можно перейти к следующему объекту? Потому что если у меня на схеме 40000 элементов, а отрисовать надо только 1000, то зачем тратить время на остальные 39000.
А! Вот при изучении списков у меня возник такой вопрос (уж не знаю сможете ли Вы на него ответить): я так понял, что каждый конкретный список компилируется в набор команд, понимаемых видеокартой (возможно он при этом еще и оптимизируется). А где все эти откомпилированные списки хранятся? И есть ли какое-нибудь ограничение на количество списков?

Это сообщение отредактировал(а) fomich0ff - 22.7.2009, 16:47

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

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

Поэтому советую по своим вопросам создавать отдельные темы - больше шансов что кто-нибудь ответит   



Естессно

в любом случае большое спасибо ;)

Anyone, я конечно понимаю что тема уже закрыта, но добавлю что отрисовывая списками ты нехило теряешь производительность, лучше отрисовывай массивами а ещё если их отрисовывать через VBO (Vertex Buffer Object). Он даст сильный прирост производительности при отрисовке сложных моделей (в плане количества полигонов)
темболее если у тебя видиокарта начиная от mx440 то всё должно поддерживаться =)

Это сообщение отредактировал(а) ShellRaiser - 23.7.2009, 15:19

ShellRaiser, 
Во-первых, от OpenGL я давно отказался в пользу WPF, потому я ничего не теряю в производительности   . 
Во-вторых, моя видяха/дрова не держат FBO и VBO.

Это сообщение отредактировал(а) Anyone - 23.7.2009, 15:26

Anyone, я просто видел что ктото советовал через списки выводить, и решил предложить пример по-лучше;)
а WPF на OpenGL основанна? или обёртка хорошая?

На DirectX. Это не обертка, это новая технология от Microsoft для создания интерфейса на основании языка xaml.

Спасибо, буду знать;)

Ну я бы сделал так:


Команды glPushMatrix и glPopMatrix очень полезны для таких вещей, которые тебе нужны.


Что значит быстрый способ? "Быстрый" - понятие относительное. Сразу могу ответить вот что. Если ты выводишь 3D-сцену, то ты задаёшь видимый объём командой glFrustum (или glOrtho, или gluPerspective). Можешь у себя в проге при выводе каждого примитива проверять, попадает ли он в видидмый объём. Правда эту же проверку осуществляет OpenGL, так что не знаю, что быстрее. Вообще, есть разные способы сокращения числа выводимых примитивов, я их не очень хорошо знаю. Мне приходилось пользоваться только отсечением по расстоянию. То есть ты считаешь расстояние от точки взгляда до выводимого примитива, и если оно больше некоторой константы, то не выводишь этот примитив.

VC15, спасибо.




У меня что-то типа векторного графического редактора. Назначение: проектирование схем трубопроводов. Там не надо 3D. Там все на плоскости. Так вот практически все графические объекты в течении своей жизни не меняются, а стало быть их удобно выводить в виде списка отображения (или дисплейного списка). Так вот я тестил производительность на 20000 полигонов. Если пробегать весь массив и тупо рисовать каждый полигон (независимо от того виден он или нет), то такой способ работает медленнее чем если выводить только те несколько сотен полигонов, которые видны. Так вот основная загвоздка заключается в том - как быстро выбрать из общего массива полигонов те, которые необходимо рисовать. Т.е. не тупым перебором, а спомощью какого-нить хитрого алгоритма. ;)
Эту проблему я пока не решил.   

fomich0ff, а какие условия выборки?

arilou, я, если честно, не очень понял, что от меня требуется =)
Вобщем у меня есть массив примитивов (допустим это произвольные полигоны). У каждого примитива есть прямоугольная область (в мировых координатах), в которую он вписан. Естественно известны всякие параметры типа цвет примитива, цвет его границы, толщина границы и т.д. Так вот я так думаю, что выбирать примитивы надо используя именно эту прямоугольную область. Вот только как это сделать не используя прямой перебор? Не знаю. Буквально минут 20 назад нашел статью про octree. Думаю попробовать. Может есть еще подобные алгоритмы?

fomich0ff, так тебе нужно определить, какие полигоны не попадают в экранную область? я бы держал список видимых объектов и обновлял его только когда меняется положение камеры.

а вообще, если полное 2Д -- зачем тогда OGL?

Ну вобщем-то это я и пытаюсь сейчас реализовать с помощью octree.


GDI/GDI+ работают медленно. Особенно когда сложная сцена с большим количеством полигонов с большим количеством вершин. Уже испытано. После долгих поисков/экспериментов остановился на OGL 

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

arilou, должен, но не канает - медленно =(