Цитата(Anyone @ 21.5.2009, 11:35  ) |
| в какую сторону гуглить - я не знаю |
Гуглить "списки отображения opengl" ("opengl display list"). В уроках NeHe - урок 12, в OpenGL "Red Book" - глава 7.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Программирование игр, графики и искусственного интеллекта > Ускорение прорисовки в OpenGL |
| Автор: Anyone 21.5.2009, 13:35 |
| Использую С#+OpenTK. С помощью OpenGL нужно нарисовать наперед не известное множество относительно сложных объектов и они отличаются), которые можно перемещать по форме. Объекты состоят из линий, закрашенных областей (причем с полу прозрачностью), текста, при их прорисовки используются циклы. В общем пока их не много - меня скорость работы графики устраивает, но если их больше чем штук 30, то при перемещении объекта(ов) (при этом рисую его как полупрозрачный прямоугольник) заметны тормоза. Я так понимаю что это из-за загрузки процессора (грузится наполовину где-то). Можно как нибудь ускорить процесс прорисовки? На ум приходит только одно: все объекты, которые не нужно перемещать сохранить как один фоновый рисунок, а поверх него уже прорисовывать перемещаемые. Или есть другие варианты? Гугл особо не помог, пушо в какую сторону гуглить - я не знаю. ЗЫ Что примерно рисую можно посмотреть http://i.piccy.info/i3/77/25/059390f298667c448a74fc597726.png |
| Автор: kemiisto 21.5.2009, 13:41 | ||
Гуглить "списки отображения opengl" ("opengl display list"). В уроках NeHe - урок 12, в OpenGL "Red Book" - глава 7. |
| Автор: Anyone 21.5.2009, 14:03 |
| kemiisto, Спасибо, буду разбираться. У меня возник другой вопрос, немного не по теме, но спрошу. Я хотел бы в своем приложении использовать несколько слоев для прорисовки (к примеру фоновый, статические элементы, динамические элементы). Для этих целей можно использовать списки отображения, или есть более подходящие решения? |
| Автор: Anyone 21.5.2009, 15:55 | ||
| Проблемка возникла. Вот моя функция создания списков отображения:
То что она долго выполняется при запуске программы - стерпеть еще можно. Но вот вызов 3го списка - это уже не допустимо: GL.CallList(_genList+2); Вызываю все списки при перемещении мыши. Использование первых 2х - дают большой прирост производительности, но вот третий приводит к сильной загрузке процессора и неимоверным тормозам. Количество объектов - 50, но даже один дает большие тормоза. BuildLists() вызывается всего лишь 1 раз. Что я делаю не так? |
| Автор: Anyone 24.5.2009, 20:28 |
| С причиною тормозов разобрался - много текста прорисовываю. Но это мне очень нужно. Какой наилучший способ быстрого вывода текста с возможностью масштабирования, желательно с заданным шрифтом? При этом для меня важна кроссплатформенность. |
| Автор: Nofate 27.5.2009, 12:10 |
| Freetype http://www.freetype.org GLTT http://gltt.sourceforge.net а чем сейчас текст рисуется? |
| Автор: Anyone 27.5.2009, 12:18 | ||
_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. На форме может быть много объектов, которые, в свою очередь, содержат в себе несколько текстовых блоков, котрые выводятся в цикле. |
| Автор: arilou 29.5.2009, 01:26 | ||
Предлагаю вывод всего текста врапить в один Begin/End (или группировать в несколько по используемым стилям). Проблема стопудово в том, что ты для каждого блока отдельный цикл делаешь. Это ведет к переключению render states, а это напрямую влияет на производительность. |
| Автор: Anyone 29.5.2009, 12:54 | ||||
Если бы это было возможным, я бы так и сделал.
Это не проблема, а всего лишь не значительная потеря производительности. Сам проверял и это я обсудил на форуме офф сайта враппера. Думаю текстурные шрифты намного бы улучшили производительность, но насколько я понял (опять же из того форума), обертка не позволяет этого сделать, по крайней мере так, как это обычно делается. Есть ли какие-нибудь способы создания текстурных шрифтов без привязки к платформе? Ну или накрайняк загрузить текстуры в списки отображения? Я только начал изучение OpenGL, так что не судите меня строго  |
| Автор: arilou 29.5.2009, 20:27 |
| Anyone, м.б. имеет смысл попробовать CEGUI# для GUI? там вроде как реализованы текстурные шрифты. |
| Автор: Anyone 29.5.2009, 22:26 | ||
Мне нужна максимальная производительность, так как мне придется перерисовывать окно при перемещении мыши, чем тупее либа - тем лучше, потому не хочу еще что-либо дополнительно ставить |
| Автор: arilou 30.5.2009, 00:58 | ||
Anyone, ну тогда засучивай рукава -- тебя ждет много интересного при реализации всего этого самостоятельно 
перечитал 2 раза, ничего не понял |
| Автор: Nofate 31.5.2009, 23:37 |
| arilou, видимо имелось ввиду, что чем меньше в библиотеке "обвеса" и наворотов, тем шустрее все будет в конечном счете работать. |
| Автор: arilou 1.6.2009, 01:44 |
Nofate, разработчики middleware врядли согласятся  |
| Автор: Anyone 1.6.2009, 02:04 |
| Попробывал все тоже самое реализовать с Tao.Framework и Tao.FreeType. Скачал враппер для работы с шрифтами http://icarus.svn.sourceforge.net/viewvc/icarus/Development/Source/ISE.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:54 |
| Разобрался с предыдущим вопросом. Ждите следующие |
| Автор: fomich0ff 19.6.2009, 08:12 |
| Anyone, позвольте полюбопытствовать вы ушли все-таки от использования OpenTK или используете TAO и OpenTK совместно? И как процесс? продвигается? |
| Автор: Anyone 19.6.2009, 10:30 |
| Я использую сейчас ТАО - как по мне - быстрее работает, кроме того команды выглядят как по стандарту, легко переносить из других языков программирования. Задачу решил частично, пушо мне некогда было сидеть над ней. Пока обошелся рисованием реверсивных объектов, если их нужно перемещать. Дальше в планах попытаться седлать скриншет статических объектов, создать такую вот текстуру, и поверх нее рисовать уже объекты, которые перемещаются, такой пример на другом форуме я нашел. |
| Автор: fomich0ff 1.7.2009, 12:41 |
| Anyone, не могли бы Вы ткнуть носом что я делаю не так? Сейчас я пытаюсь вывести хоть какой-нибудь текст с помощью Tao + FTclass. Скачал пример http://icarus.svn.sourceforge.net/viewvc/icarus/Development/Source/Samples/ISE.FreeType/1.Simple/Program.cs?revision=280, но почему-то у меня весь текст выводится в виде пустых квадратиков (и английский и русский). Я пробовал делать как Вы указывали чуть выше, но результат такой же - квадратики. Вы с такой проблемой не сталкивались? Может надо включить какой-то режим? ЗЫ. Кстати все пути к шрифтам я изменил на соответствующие для моей машины. |
| Автор: Anyone 1.7.2009, 12:46 |
| Таких проблем у меня не было. Нужно код смотреть. |
| Автор: fomich0ff 1.7.2009, 14:04 |
| Ну вобщем-то в коде примера я изменил только пути к шрифтам и все. Единственное на что я могу грешить - на библиотеку freetype6.dll. Она требовалась для запуска примера. Я ее нашел в либах TeX'a. Может версия не та. Может еще что... |
| Автор: Anyone 1.7.2009, 14:14 |
| Я сделал так. Библиотеку скачал http://icarus.svn.sourceforge.net/viewvc/icarus/Development/Source/ISE.FreeType/ Кинул в папки проекта Debug, Release файлы со шрифтами и такие dll-ки: freetype6.dll, Tao.FreeType.dll, zlib1.dll. После этого все стало нормально работать. Добавлено через 2 минуты и 18 секунд zlib1.dll можно посмотреть тут: \Program Files\TaoFramework\lib |
| Автор: fomich0ff 1.7.2009, 15:59 |
| Спасибо. Завтра попробую. |
| Автор: fomich0ff 22.7.2009, 10:12 |
| Долго отсутствовал, потому что не было инета. Значит пишу отчет: на моем компе вывод текста не работает. На других компах все работает нормально. Грешу на то что у меня встроенная видюха и, возможно, кривые дрова. На остальных копмах все карточки внешние. Вобщем засада. |
| Автор: Anyone 22.7.2009, 10:16 | ||
Не работает только текст, или графика вообще? У меня тоже слабенькая видяха в ноуте, многие расширения не держит. |
| Автор: fomich0ff 22.7.2009, 12:57 |
| Графика работает. Медленно, но работает. А вот с текстом чудеса - вместо букв выводит прямоугольники. На других компах буквы видны. |
| Автор: Anyone 22.7.2009, 14:09 | ||
Насколько я помню, у других тоже были такие проблемы. Попробуй кинуть файл шрифта в папку с ехе-файлом и проверить статус успешности инициализации библиотеки. А еще лучше обратится на форуме OpenTK - там обычно помогают решить проблемы, если есть знание английского канеш. |
| Автор: fomich0ff 22.7.2009, 16:07 |
| Ага, спасибо. Попробую. За этот месяц я чего только не перепробовал. Пока отрисовку текста отложил в сторону. У меня возник такой вопрос: Предположим на экране рисуются несколько тысяч примтивов (треугольники, квадраты, звездочки и т.п.). Все имеют одинаковый видимы размер (например 20х20 пикселей). Как сделать так чтобы при масштабировании (glScaled) всей сцены все эти примитивы не изменяли видимых размеров (т.е. на экране они оставались так же 20х20 пикселей). Пример может быть таким: предположим есть карта какой-нибудь страны. На этой карте звездочками помечены крупные города. Так вот надо, чтобы карта страны масштабировалась, а звездочки - нет (т.е. всегда оставались одного и того же размера). Надеюсь я понятно объяснил суть проблемы. |
| Автор: Anyone 22.7.2009, 16:10 | ||
Очень просто. Если вся сцена масштабируется в n раз, то те примитивы, которые не должны масштабироваться, нужно промасштабировать в 1/n раз |
| Автор: fomich0ff 22.7.2009, 16:41 | ||
Значит я правильно думал =) Я так понимаю, что с текстом точно так же? Т.е. чтобы он оставался всегда одного и того же размера нужно масштабировать его в 1/n раз? Я надеялся, что есть какие-то скрытые возможности у OpenGL. Тогда такой вопрос: есть ли быстрый способ проверить попадает ли рисуемый объект (точка, треугольник, полигон и т.д.) в видимую область или нет? т.е. стоит его рисовать или можно перейти к следующему объекту? Потому что если у меня на схеме 40000 элементов, а отрисовать надо только 1000, то зачем тратить время на остальные 39000. А! Вот при изучении списков у меня возник такой вопрос (уж не знаю сможете ли Вы на него ответить): я так понял, что каждый конкретный список компилируется в набор команд, понимаемых видеокартой (возможно он при этом еще и оптимизируется). А где все эти откомпилированные списки хранятся? И есть ли какое-нибудь ограничение на количество списков? |
| Автор: Anyone 22.7.2009, 18:10 | ||
| К сожалению, я не могу ответить на все вопросы, поскольку я лишь поверхностно изучал OpenGL и вскоре и вовсе понял что это не то, что мне нужно, и прекратил изучение данной технологии. По поводу текста в OpenGL вообще нету встроенной поддержки, потому приходится извращаться разными способами, и они не позволяют выводить быстро изменяющийся текст в больших масштабах, что мне очень нужно. Поэтому советую по своим вопросам создавать отдельные темы - больше шансов что кто-нибудь ответит
Естессно |
| Автор: fomich0ff 22.7.2009, 18:33 |
| в любом случае большое спасибо ;) |
| Автор: ShellRaiser 23.7.2009, 15:18 |
| Anyone, я конечно понимаю что тема уже закрыта, но добавлю что отрисовывая списками ты нехило теряешь производительность, лучше отрисовывай массивами а ещё если их отрисовывать через VBO (Vertex Buffer Object). Он даст сильный прирост производительности при отрисовке сложных моделей (в плане количества полигонов) темболее если у тебя видиокарта начиная от mx440 то всё должно поддерживаться =) |
| Автор: Anyone 23.7.2009, 15:25 |
| ShellRaiser, Во-первых, от OpenGL я давно отказался в пользу WPF, потому я ничего не теряю в производительности . Во-вторых, моя видяха/дрова не держат FBO и VBO. |
| Автор: ShellRaiser 23.7.2009, 15:46 |
| Anyone, я просто видел что ктото советовал через списки выводить, и решил предложить пример по-лучше;) а WPF на OpenGL основанна? или обёртка хорошая? |
| Автор: Anyone 23.7.2009, 16:46 | ||
На DirectX. Это не обертка, это новая технология от Microsoft для создания интерфейса на основании языка xaml. |
| Автор: ShellRaiser 24.7.2009, 09:52 |
| Спасибо, буду знать;) |
| Автор: VC15 6.8.2009, 16:01 | ||||||
Ну я бы сделал так:
Команды glPushMatrix и glPopMatrix очень полезны для таких вещей, которые тебе нужны.
Что значит быстрый способ? "Быстрый" - понятие относительное. Сразу могу ответить вот что. Если ты выводишь 3D-сцену, то ты задаёшь видимый объём командой glFrustum (или glOrtho, или gluPerspective). Можешь у себя в проге при выводе каждого примитива проверять, попадает ли он в видидмый объём. Правда эту же проверку осуществляет OpenGL, так что не знаю, что быстрее. Вообще, есть разные способы сокращения числа выводимых примитивов, я их не очень хорошо знаю. Мне приходилось пользоваться только отсечением по расстоянию. То есть ты считаешь расстояние от точки взгляда до выводимого примитива, и если оно больше некоторой константы, то не выводишь этот примитив. |
| Автор: fomich0ff 6.8.2009, 16:13 | ||
VC15, спасибо.
У меня что-то типа векторного графического редактора. Назначение: проектирование схем трубопроводов. Там не надо 3D. Там все на плоскости. Так вот практически все графические объекты в течении своей жизни не меняются, а стало быть их удобно выводить в виде списка отображения (или дисплейного списка). Так вот я тестил производительность на 20000 полигонов. Если пробегать весь массив и тупо рисовать каждый полигон (независимо от того виден он или нет), то такой способ работает медленнее чем если выводить только те несколько сотен полигонов, которые видны. Так вот основная загвоздка заключается в том - как быстро выбрать из общего массива полигонов те, которые необходимо рисовать. Т.е. не тупым перебором, а спомощью какого-нить хитрого алгоритма. ;) Эту проблему я пока не решил.  |
| Автор: arilou 6.8.2009, 23:33 |
| fomich0ff, а какие условия выборки? |
| Автор: fomich0ff 7.8.2009, 08:40 |
| arilou, я, если честно, не очень понял, что от меня требуется =) Вобщем у меня есть массив примитивов (допустим это произвольные полигоны). У каждого примитива есть прямоугольная область (в мировых координатах), в которую он вписан. Естественно известны всякие параметры типа цвет примитива, цвет его границы, толщина границы и т.д. Так вот я так думаю, что выбирать примитивы надо используя именно эту прямоугольную область. Вот только как это сделать не используя прямой перебор? Не знаю. Буквально минут 20 назад нашел статью про http://www.gamedev.ru/code/articles/?id=4200. Думаю попробовать. Может есть еще подобные алгоритмы? |
| Автор: arilou 7.8.2009, 11:22 |
| fomich0ff, так тебе нужно определить, какие полигоны не попадают в экранную область? я бы держал список видимых объектов и обновлял его только когда меняется положение камеры. а вообще, если полное 2Д -- зачем тогда OGL? |
| Автор: fomich0ff 7.8.2009, 11:30 | ||||
Ну вобщем-то это я и пытаюсь сейчас реализовать с помощью octree.
GDI/GDI+ работают медленно. Особенно когда сложная сцена с большим количеством полигонов с большим количеством вершин. Уже испытано. После долгих поисков/экспериментов остановился на OGL |
| Автор: arilou 7.8.2009, 15:23 | ||
так у тебя же плоский список и фактически 2D сцена? octree - это больше для 3D используют, когда глубина присутствует. например, в террейнах для оптимизации кол-ва полигонов и отсечении невидимых. т.е. в твоем случае, имхо, простой перебор по запросу вполне должен проканать. |
| Автор: fomich0ff 7.8.2009, 15:26 |
| arilou, должен, но не канает - медленно =( |