Глава 45. RenderMonkey.

Создание шейдеров трудоёмкая и очень трудная задача. Поэтому очень удобно создавать их в специальных программах. Также в этих программах очень удобно настраивать шейдер, а уже потом экспортировать его код. Самой известной программой в этой области является RenderMonkey.

Бесплатно скачать самую свежую версию RenderMonkey можно здесь: http://developer.amd.com/gpu/rendermonkey/Pages/default.aspx

Хорошие уроки по использованию RenderMonkey можно посмотреть здесь: http://www.dtf.ru/articles/print.php?id=38592

Интерфейс RenderMonkey интуитивен и совместим со стандартом MS Visual Studio. Рабочее пространство разделено на три основные зоны: браузера эффектов, служебных сообщений и визуализации. Согласно терминологии, которой придерживаются разработчики из ATI, совокупность элементов древовидной структуры, отображаемой в окне браузера, называется эффектом. В комплект поставки входят 35 готовых эффектов для OpenGL, позволяющих визуализовать поверхности мыльных пузырей, воды, древесины, металла, меха, огня и др. Двойной щелчок левой клавишей мыши по любому из элементов дерева приводит к вызову соответствующих инструментов его редактирования. Синтаксические конструкции исходного кода шейдеров выделяются разными цветами. Всякое изменение любого элемента приводит к мгновенному перерисовыванию содержимого окна визуализации. Для сохранения результатов используется стандартный формат XML, позволяющий разработчикам легко организовывать импорт настроек эффекта в свои приложения. Впечатления от RenderMonkey напоминают нечто среднее между опытом работы материалов в 3ds max или Maya и опытом программирования в современной оконной среде IDE.

Несмотря на оригинальность общей идеи и множество неоспоримых частных достоинств, RenderMonkey, прежде всего, является оружием конкурентной борьбы в руках ATI. Поэтому нет ничего удивительного в том, что наиболее эффективно и устойчиво она работает с чипами серии Radeon, и вряд ли в будущем нам стоит надеяться на исправление этого перекоса.

В заключение хотелось бы дать совет всем программистам, желающим

Глава 46. Оптимизация программы.

Вот вы доделываете свой проект и понимаете, что быстродействие программы оставляет желать лучшего. Рассмотрим, как можно повысить быстродействие программы.

1. Самое простое - подождать годика два, пока компьютеры не станут достаточно быстрыми :)

2. Оптимизировать за счет качества:

• использовать текстуры меньшего размера;

• использовать низкополигональные модели;

• ограничивать зону видимости (свойство DepthOfView у камеры);

• отключить тени;

• в системах частиц брать меньше частиц;

• уменьшить разрешение экрана в полноэкранном режиме или размер GLSceneViewer’а в оконном режиме;

• На качество должно влиять сглаживание GLSceneViewer.Buffer.AntiAliasing, но я никаких изменений не заметил;

• отключить дополнительные эффекты;

• и т.д.

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

3. Если есть большое количество одинаковых объектов, то делать их Proxy объектами.

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

5. Использовать различные алгоритмы отсечения невидимых граней: BSP, Frustum Culling, Octree;

6. Использовать LOD, т.е. если объект удаляется на значительное расстояние, менять его на более простой. А когда объекты совсем далеко, заменять их спрайтами;

7. Самые трудоемкие и часто используемые места программы делать в виде ассемблерных вставок,

а так же писать на чистом OpenGL;

8. Если нужно в программе вычислять какие-то алгебраические выражения, то попробуйте их сначала упростить;

9. Начиная с Delphi 7, существует директива inlane. Из-за неё в процессе компиляции сам компилятор при вызове процедуры не вставляет ссылку на неё (процедуру), а сразу вставляет тело. Но учтите, что такой подход существенно повышает объём исполняемого файла.

9. Выносите из циклов куски кода, не зависящие от итерационной переменной (это же относится к

Cadencer’у и другим таймерам).

10. Скорость арифметических операций над числами зависит от их типа. Например, операции над числами типа Extended выполняются дольше, чем над числами типа Real, типа Real дольше, чем типа Single. И, конечно же, вещественные числа считаются в несколько раз дольше, чем целые.

11. GLMaterialLibrary хранит изображения и в ОЗУ даже после того, когда они уже есть в видео памяти. От этого можно избавиться с помощью правильного задания TGLPicFileImage. Например: GLSphere1.Material.Texture.ImageClassName := TGLPicFileImage.ClassName; а после этого грузить картинку из файла. PicFile Image не держит ничего в памяти дольше чем нужно. По требованию загружает картинку из файла, отправляет в видеопамять и очищает использованную при загрузке оперативную память.

11. Классический прием – «разматывание циклов». Например, есть цикл:

for i:=1 to 100 do

begin

^b:=b+2;

end;

Попробуем его немного «размотать»:

for i:=1 to 20 do

begin

^b:=b+2;

b:=b+2;

b:=b+2;

b:=b+2;

b:=b+2;

end;

При этом результат получается тот же, но в пять раз меньше операций перехода в цикле. Надеюсь,

вы не осудите за такой пример, нормальный программист написал бы просто: b:=b+200.

К этому же приему можно отнести «раскрытие процедур», т.е. отказаться от процедур и писать все сплошным текстом, при этом не тратится время на их вызов.

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