Програмне забезпечення перетворення та підготовки графічних зображень до візуалізації засобами Software Render та Mental Ray

- Апаратну візуалізацію систем часток

- Більш старі версії Mental Ray не підтримують послойну візуалізацію

- Жодна з версій не підтримую файли з блочним порядком текстури

Стандартний модуль візуалізації має ще й інші недоліки якщо порівнювати його Mental Ray.

- Відсутність можливості освітлення за допомогою карти фотонів.

- Відсутність можливості імітації глобального освітлення

- Mental Ray містить більш фотореалістичні матеріали

Незважаючи на ряд недоліків як у стандартного візуалізатора Мауа так і у Mental Ray кількість користувачів цих рендерів значна [12].

Проблема візуалізації тримірного зображення стала однією з ключових проблем комп'ютерної анімації. Зменшення часу візуалізації є ключовим пунктом та метою дипломного проекту

В цьому розділі було розглянуто наступні питання

1. Досліджено історію виникнення тримірної графіки

2. Сфери використання тримірної графіки

3. Огляд існуючих рішень для роботі з три мірною графікою

4. Процес візуалізації три мірного зображення, де було розглянуті основні візуалізатори та порівняння Maya Software Render та Mental Ray

РОЗДІЛ 2. ПЕРЕТВОРЕННЯ ТА ПІДГОТОВКА ГРАФІЧНИХ ЗОБРАЖЕНЬ ДО ВІЗУАЛІЗАЦІЇ ЗАСОБАМИ SOFTWARE RENDER ТА MENTAL RAY

2.1 Визначення процесу візуалізації три мірного зображення

тримірний візуалізація графічний програмний

Рендеринг або візуалізація (англ. renderіng - "отрисовка") у комп'ютерній графіці - це процес одержання зображення по моделі, за допомогою комп'ютерної програми. Тут модель - це опис тривимірних об'єктів на строго певній мові або у вигляді структури даних. Такий опис може містити геометричні дані, положення крапки спостерігача, інформацію про висвітлення. Зображення - це цифрове растрове зображення. Простіше говорячи, рендеринг - створення плоского зображення (картинки) по розробленої 3D сцені. Синонімом у є Візуалізація.

Це один з найбільш важливих розділів у комп'ютерній графіці, і на практиці він тісним образом пов'язаний з іншими. Звичайно, програмні пакети тривимірного моделювання й анімації містять у собі також і функцію рендеринга. Існують окремі програмні продукти, що виконують рендеринг. Залежно від мети, розрізняють пре-рендеринг, як досить повільний процес візуалізації, що застосовується в основному при створенні відео, і рендеринг у реальному режимі, використовується у комп'ютерних іграх. Останній часто використовує 3 D-Прискорювачі [1]

Результат процесу візуалізації можна чітко побачити якщо зрівнювати зображення тримірної сцени до рендерінгу та після. На малюнку що розташований нижче (Рис 2.1) показана звичайна тримірна сцена так як її сприймає око людини. А на малюнку 2.2 продемонстрована таж сама сцена але після візуалізації.



Рис. 2.1. Екран звичайної тримірної сцени

Результат процесу візуалізації

Рис. 2.2. Результат візуалізації тримірної сцени

Математичне обґрунтування. Реалізація механізму рендерінга завжди ґрунтується на фізичній моделі. Вироблені обчислення ставляться до тієї або іншої фізичної або абстрактної моделі. Основні ідеї прості для розуміння, але складні для застосування. Як правило, кінцеве рішення або алгоритм більше складні й містять у собі комбінацію різних технік.

Основне рівняння. Ключем до теоретичного обґрунтування моделей візуалізації служить рівняння рендерінга. Воно є найбільш повним формальним описом частини рендерінга, що не ставиться до сприйняття кінцевого зображення. Всі моделі являють собою якесь наближене рішення цього рівняння.

 (2.1.)

Неформальне тлумачення таке: Кількість світлового випромінювання (Lo) вихідного з визначеної точки в певному напрямку є власне випромінювання й відбите випромінювання. Відбите випромінювання є сума в усіх напрямках прихожого випромінювання (Lі) помноженого на коефіцієнт відбиття з даного кута. Поєднуючи в одному рівнянні прихоже світло з вихідним в одній крапці, це рівняння становить опис усього світлового потоку в заданої системі.

Методи рендерінга. Ray castіng (метод "кидання" променя) використовується в realtіme- рендерінгу (наприклад, у комп'ютерних іграх), де швидкість створення картинок важливіше їх якості. Суть методу в наступному: з точки спостереження у напрямку пікселя, колір якого визначається, випромінюється уявлюваний промінь. Якщо промінь перетинає який-небудь примітив, то цей примітив "офарблює" відповідний піксель у свій колір. Існують варіації методу, коли випромінюються додаткові промені від примітива в "крапку спостереження" або від джерела світла убік примітива (для обчислення освітленості й тіней). Для обчислення освітленості примітива можуть використовуватися й дані, отримані методом radіosіty.

Radiosity (або метод випромінювання) часто називають Global Іllumіnatіon (глобальне освітлення), хоча radіosіty усього лише один з алгоритмів обчислення цієї самої "глобальної освітленості", що використовується, як правило, у сполученні з іншими алгоритмами. Методом radіosіty намагаються моделювати шлях відбитого від поверхні світла, що у реальності відбивається не в одному напрямку ("кут відбиття дорівнює куту падіння"), а розсіюється (dіffusіon) у просторову півсферу, "висвітлюючи" цілу область навколо крапки падіння, при цьому колір розсіяного світла змінюється відповідно до кольору поверхні в крапці падіння променя. Складність і точність методу radіosіty варіюється в дуже широких межах. В візуалізації реального часу й при візуалізації сцен з навколишнім середовищем глобальну освітленість імітують за допомогою нехитрого трюку, злегка висвітлюючи всю сцену уявним джерелом світла, називаним ambіance (навколишнє середовище). А от у сполученні з методом трасування променів (ray tracіng) radіosіty дозволяє одержати дуже реалістичні зображення, особливо при візуалізації інтер'єрів, щоправда, ціною збільшення в багато разів часу рендерінгу. Втім, багато хто 3D-Програми дозволяють вручну дати вказівки візуалізатору, які об'єкти будуть брати участь у глобальної освітленості, а які ні, при цьому можна одержати дуже гарний (у змісті реалістичності) результат набагато швидше. Різних способів імітувати глобальну освітленість придумано досить багато, деякі дають досить непоганий результат, але різке збільшення продуктивності процесорів (за рахунок многоядерності, приріст виходить не 5-10-20 %, а кілька разів) при досить помірному їхньому подорожчанні робить використання манівців для високо реалістичної візуалізації недоцільним - порівняно чесні способи рішення рівняння рендерінга (абсолютно чесних способів не існує) дають більше точний результат при тих часових витратах, що й в нечесних способах. Математичним апаратом розрахунку глобальної освітленості методом radіosіty є метод кінцевих елементів. Якщо говорити популярно, то при рішенні рівняння рендерінга методом radіosіty у розрахунок приймаються тільки ті промені, які будучи випущені джерелом світла й дифузне відбившись деяку кількість разів (або жодного разу) від поверхонь у сцені, попадають в око спостерігача (об'єктив віртуальної камери). Тому вірніше говорити, що метод radіosіty дає не загальне, а часткове рішення рівняння рендерінга, цей метод не прораховує, наприклад, дзеркальні відбиття, переломлення променів, тверді (hard) тіні, його ціль - винятково дифузійні відбиття.

Короткий опис алгоритму radіosіty. Алгоритм оперує не променями, а світловою енергією, циркулюючої у тримірній сцені. У загальному випадку тримірна сцена складається з нескінченної безлічі крапок, які обмінюються світловою енергією. Простежити всі ці взаємодії не представляється можливим, тому нескінченна безліч крапок заміняють на кінцеве число ділянок (patches) поверхонь, що утворять тримірну сцену. Способів розбивки на ділянки досить багато, але універсального, придатного на всі випадки життя, поки не винайшли. Алгоритм radіosіty многопрохідний, на кожному проході для кожної ділянки обчислюється світлова енергія, що прийшла до нього від інших ділянок. Частина цієї енергії поглинається ділянкою, інше відбивається назад у сцену й ураховується при наступному проході.

Ray tracing (трасування променів) - самий трудомісткий у плані обчислень алгоритм реалістичного рендерінга, але без нього просто неможливо: геометрично точне видалення невидимих поверхонь, відбиття, переломлення, дисперсія, тверді тіні, об'ємні ефекти - от тільки деякі (втім, найважливіші ) його цілі. А в парі з radіosіty метод цей метод становить більшу частину всього реалістичного рендерінга. Обчислювальна трудомісткість методу ray tracіng зв'язана насамперед з тим, що він, по суті справи, є спробою вирішити рівняння рендерінгу з як можна меншою погрішністю. Зате нагородою за цю спробу є дуже високий рівень реалізму візуалізованих сцен (в основному завдяки обліку таких оптичних явищ, які не попадають в поле зору інших алгоритмів рендерінга). Простежити всі промені в сцені не представляється можливим через їхнє нескінченне число, тому трасуються не всі промені, а тільки ті, які беруть участь в "формуванні" пікселя візуалізованого зображення. І самими природними кандидатами на трасування є промені, що попадають в око спостерігачеві (об'єктив віртуальної камери). Метод трасування променів як би вивернуть навиворіт: простежуються не промені, випущені джерелом світла, а уявлювані промені, випущені оком спостерігача (об'єктивом камери). Саме через цей базовий метод трасування не враховується дифузні відбиття, при яких напрямок відбитого від поверхні променя непередбачено, а враховує тільки дзеркально відбиті й переломлені промені (а в останніх версіях багатьох рендерів ще й дисперсно переломлені (dіspersіon). Трасування променів, що виходять від джерела світла, теж використовується - для уточнення результатів трасування променів від ока спостерігача. Через це виникла плутанина в термінології: що вважати прямим, а що інверсним трасуванням. У більшості візуалізаторів, ray tracіng має на увазі саме промені, що виходять від ока спостерігача.

2.2 Типові проблеми візуалізації тримірного зображення

Процес візуалізації за частую буває найбільш проблематичним на всьому етапі моделювання три мірної сцени, адже на тільки на цьому етапі ми можемо відчути весь реалізм сцени. Основна проблема, з якою зіткаются спеціалісти з візуалізації та 3D дизайнери - це дуже великий час візуалізації. Типовий приклад. При зйомках фільму «Володар перснів» візуалізація одного кадру з персонажем Голлум займала від 45 хвилин. В одній секунді фільму 25-33 кадри. Порахували що візуалізація усіх кадрів фільму зайняла би 450 років. Але є кілька прийомів обходу цієї проблеми. Один з них це використання фалів внутрішніх форматів рендерів та кешинг текстури.

2.3 Вимоги до створення програмного забезпечення

2.3.1 Функціональні вимоги

Програмне забезпечення перетворення та підготовки графічних зображень до візуалізації засобами Software Render та Mental Ray повинно зменшувати час візуалізації і при цьому не погіршувати якість зображення при візуалізації. Програма має надавати можливість конвертації як у внутрішній формат Maya Software Render *.bot так Mental Ray *.map.

Функціональні вимоги до програми відображені на малюнку 2.3 «Модель функціональних вимог»



Рис. 2.3. Модель функціональних вимог

Опис діаграми вимог

Активні суб'єкти:

1. Спеціаліст з візуалізації. Особа, що безпосередньо працює з системою, саме вона задає параметри та запускає процес конвертації зображень та візуалізації три мірної сцени.

2. Менеджер проекту. Особа, що не працює з програмою безпосередньо, але зацікавлена в результатах її роботи, а саме в отриманні зображення очікуваної якості за більш короткий час.

Варіанти використання

Зменшення часу візуалізації - варіант використання, що ініціюється активних суб'єктом «менеджер проекту» виконується активним суб'єктом «спеціаліст з візуалізації». Передбачає сукупність дій направлених на зменшення часу візуалізації.

Отримання зображення очікувальної якості - варіант використання, що ініціюється активних суб'єктом «менеджер проекту». Включає в себе варіант використання мінімізація втрат даних при конвертуванні форматів

Можність задавати параметри візуалізації без необхідності замінувати код - варіант використання, що виконується активним «Спеціаліст з візуалізації» і являє собою сукупність дій направлених на отримання ПО в якому при конвертуванні непотрібно бачити або видозмінювати код.

Перетворення файлів стандартних графічних форматів до формату *.bot *.map - варіант використання, що виконується активним суб'єктом «Спеціаліст з візуалізації». Передбачає сукупність дій направлених на перетворення стандартних графічних зображень у зображення внутрішніх форматів Maya та Mental Ray [3].

Діаграма послідовності дій при роботі з програмних забезпеченням перетворення та підготовки графічних зображень до візуалізації засобами software render та mental ray

Рис. 2.4. Діаграма послідовності дій при роботі з програмних забезпеченням

2.3.2 Не функціональні вимоги

Не функціональні вимоги це вимоги які не були відображені в моделі варіантів використання, такі як надійність, зручність використання, продуктивність, супроводжуваність та інше. Для програмного забезпечення перетворення та підготовки графічних зображень до візуалізації засобами Software Render та Mental Ray необхідно виконати наступні вимоги не функціональні вимоги:

- Інтерфейс програмного забезпечення повинен бути сумісним з Windows XP або Mac OS

- Програмне забезпечення повинно виключати можливість коректування та внесення нових параметрів під час візуалізації

- Програмне забезпечення повинно працювати на усіх платформах Мауа нижче 8.5

- Програмне забезпечення може бути використане тільки на жорсткому диску з файловою системою FAT32

2.4 Чинники підвищення ефективності роботи візуалізатора завдяки використанню зображень формату *.bot та *.map

Коли проходить процес візуалізації , скрипти, сцени, текстури та інше завантажуються до RAM. Якщо весь вільний RAM вже використовується, може виникнути перенавантаження оперативної пам'яті та подальші проблеми з нею. Для того щоб зменшити завантаження пам'яті можна сконвертувати текстуру у BOT чи MAP формат зображення.

BOT (Block Order Texture) файли з блочним порядком текстури, знижують запити к оперативній пам'яті при роботі з великими картами текстури, так як згідно зі структурою об'єкту текстура б'ється на фрагменти, котрі візуалізатор може легко помістити в кеш. Завдяки використанню BOT файлів візуалізатор може обійтися завантаженням лише тих фрагментів що необхідні для візуалізації. Відповідно замість 40 мегабайт завантажується усього кілька сотень кілобайтів. На жаль ці файли не розпізнаються зовнішніми програмами, тому конвертувати треба лише ті файли котрі в наступному не доведеться редагувати. Звичайна текстура завантажується до RAM повністю. А текстура формату BOT лише на 250 Кбайт (проте може бути і вище). Це дає змогу ефективно розвантажити пам'ять. Проте використовувати текстури внутрішнього формату BOT можна лише ті котрі більше 250 Кбайт та які розміщуються в сцені на віддаленій відстані від камери. Якщо зображення не є BOT файлом, Мауа створює тимчасовий BOT файл в тому зображенні що візуалізується. Це може дуже заповільнити час візуалізації та збільшити необхідну частину дискового простору під час процесу рендерінга (візуалізації). Проте якщо с конвертувати усі файли текстур до формату BOT це зможе зменшити час візуалізації. Проте слід пам'ятати, що конвертувати у BOT формат можна не усі текстури сцени, а лише ті що відповідають вимогам.

- Зображення не повинно бути менше за 250 Кбайт

- Текстура яка використовується у сцені не повинна бути на передньому плані камери, бо інакше не має жодного сенсу у такій конвертації.

- Зображення повинно мати один з основних форматів, але не IFF чи BMP.

Map чи Memory-Mapped Textures це зображення внутрішнього формату візалізатора Mental Ray, і ніяка інша програма нездатна працювати з таким форматом.

Mental Ray підтримує текстури відображення пам'яті на UNIX чи NT платформах. Відображення або інакше кажуть розкладка пам'яті означає що текстура не завантажується до пам'яті а доступ до неї надається коли цього хоче шейдер. Немає ніякої команди чи функції для цього. Якщо текстура є такою що може бути с конвертованою в Map то Mental Ray це робить автоматично. Тільки зображення Map формату можуть бути розкладені. Зображення формату Mental Ray може мати розширення *.map так і інші формати, але якщо вони такі що піддаються розкладці Mental Ray розпізнає їх. Зображення може мати розширення jpg проте бути файлом Map. Звісно таке зображення неможливо подивитися у графічних редакторах і звісно таке зображення може отримати тільки після конвертації. Примітимо, що відображення-розкладка пам'яті основана на концепті того що дані зображення на диску не потребують декодування або видозмінення форматів, проте це доступно в тому ж форматі, що Mental Ray використовує у себе під час візуалізації.

Нормально коли Mental Ray намагається автоматично с конвертувати зображення стандартних форматів. Наприклад, файл кольорового зображення у конструкті скалярної текстури, Mental Ray тихо конвертує кольорові пік селі у скалярні як у текстури та читає їх. Більшість типів даних конвертуються у більшість форматів. Проте це не спрацює для текстур відображення пам'яті map, тому що це буде призводити до помилки. Це також стосується і байтового порядку [14].

Для створення текстури розкладки-відображення пам'яті необхідно вирішити кілька питань.

1. Текстура повинна бути конвертована у формат map. Це може бути виконано кількома кроками.

- Є спеціальні плагіни для Adobe Photoshop, проте використовувати їх можуть далеко не усі. Плагінів усього один і коштує він дорого. А сконвертованій файл не завжди є правильним.

- До пакету Мауа входить утиліта imf_copy. Вона конвертує значно краще ніж пагін до Adobe Photoshop і є безкоштовною, але з нею можна працювати лише через командну строку. Для того щоб конвертувати кілька файлів треба писати BAT файл, що через велику кількість зайвих параметрів може бути по складності як повноцінний скрипт. Недоліки та буде розглянуто окремо.

2. Необхідно замінити усі старі текстури у три мірній сцені на нові формату map. Використовуючи стандартні засоби, це крок виконання може дуже затягнуться якщо кількість текстур дуже велика. Проте слід пам'ятати що візуалізатор Mental Ray розпізнає map файли навіть і без розширення map. Краще завжди давати файлам розкладки пам'яті розширення map бо Mental Ray то їх розпізнає, а дизайнер чи спеціаліст з візуалізації плутається. Для того, щоб зі звичайного файлу зробити файл розкладки пам'яті треба виконати такі дії. Графічне зображення розбивається на окремі частини (квадрати) які мають 4px*4px розмір.

Кожен з цих квадратиків заміняється квадратиком розміром 1px*1px. Тобто чотири квадрати 4px*4px , які стояли разом створять новий квадрат розміром 4px*4px і так до того як залишиться один квадрат 1px*1px. На малюнку можно побачити приблизну структуру map файлу.

Рис 2.5. Графічна структура файлу формату map

Текстура не повинна лежати на диску з файловою системою NTFS якщо дії мережений рендерінг. Але цього правила також слід дотримуватися я для звичайної візуалізації. Якщо діє мережений рендерінг, відповідальність текстури правилам повинна бути чіткою, бо інакше це може дуже заповільнити процес візуалізації. Розкладка-відображення пам'яті дуже ефективно діє на дуже великі текстури в десятки мегабайт. У такому разі текстура не буде завантажуватися у пам'ять уся, а лише по запиту шейдера.

При мереженому рендерінгу файл map повинен використовуватися лише комп'ютерами з одноконю файловою системою та з однаковою бітністю (16,32,64) [14].

Існують програми для роботи з bot і map. У пакеті Мауа є така програма іmgconfіg. Але використовувати цю програму недоцільно тому що вона працює тільки через командний рядок, тобто всі файли всі параметри треба прописувати вручну й працює тільки з фалами bot. Це ще припустимо на сценах з невеликих кількістю текстур і використанням стандартного визуализатора. Але найчастіше стандартний визуализатор не використовують і кількість текстур буває досить велике. У таких ситуаціях на великих студіях пишуть свої специфічні програми. Дане програмне забезпечення є рішенням для дизайнерів без доступу до продукту великих студій і працюючих одних.

У пакеті Мауа вже є також іmf_copy яка працює з визуализатором Mental Ray. Використовувати її також важко як і іmgconfіg тому що вона теж працює через командний рядок.

2.5 Схема роботи програмного забезпечення

На схемі нижче представлена схема роботи програмного забезпечення підготовки та перетворення графічних зображень до візуалізації.

Опис схеми роботи ПЗ. Починається робота с програмним забезпеченням з його запуску. Після запуску програмного забезпечення виводиться інтерфейс де можна ввести параметри конвертації у bot чи map формат. Після того як параметри будуть введені система аналізує їх і приймає рішення про то для якого візуалізатора ці параметри введені.

Нагадую, що текстури формат bot використовується тільки рендером Maya SoftRender а формат map тільки для Mental Ray. Після того як система визначилась з візуалізатором проходить процесс конвертації у внутрішні формати візуалізаторів.



Рис 2.6. Схема роботи програмного забезпечення

Файл BOT отримується шляхом ділення текстури зображення на блоки рівних за розміром. Хоча допускається і ділення на різнорозмірні ділянки. Файл MAP отримується наступним шляхом. Графічне зображення розбивається на окремі частини (квадрати) які мають 4px*4px розмір. Кожен з цих квадратиків заміняється квадратиком розміром 1px*1px. Тобто чотири квадрати 4px*4px , які стояли разом створять новий квадрат розміром 4px*4px і так до того як залишиться один квадрат 1px*1px. На малюнку можна побачити приблизну структуру map файлу. Таким чином, необхідність створення програмного забезпечення яке б змогло контролювати та зменшувати час візуалізації дуже важких сцен, дуже велика. Наявність такої програми у дизайнерів та спеціалістів з візуалізації збільшила б якість їх роботи та зменшила б час потрачений на цю роботу.

В цьому розділі було отримано наступні результати:

1. Визначено основні етапи візуалізації та опис її типових проблем.

2. Визначено вимоги до створюваного програмного забезпечення.

РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ПЕРЕТВОРЕННЯ ТА ПІДГОТОВКИ ГРАФІЧНИХ ЗОБРАЖЕНЬ ДО ВІЗУАЛІЗАЦІЇ

3.1 Вибір операційного середовища та засобів розробки програмного забезпечення

Можна сміло сказати, що жодна сфера людської діяльності не розвивається настільки динамічно, як індустрія комп'ютерної графіки. Ця як і раніше порівняно молода галузь уже зуміла проникнути у всілякі області. Серед них моделювання, анімація й візуалізація. Вони не стоять на місці, і розвиток кожної зі шлях удосконалювання й прогресу. У результаті сьогодні ми спостерігаємо такі реалістичні й правдоподібні зображення, яких не бачили ніколи колись. І ніколи наукові експерименти не відрізнялися такою складністю. І ніколи не було таких інтерактивних ігор з ефектом занурення, як зараз. Ніколи, тобто до сьогодні. Якщо в індустрії комп'ютерної графіки в чомусь і можна бути впевненим, то лише в тім, що зміни не просто невідворотні, вони тривають, і їхня інтенсивність усе збільшується. Стійкий ріст минулих років мерхне в порівнянні з нинішньою швидкістю появи й втілення в життя нових і ідей. Рушійна сила цього прогресу - ненаситне бажання людини одержувати більш складні зображення й випробовувати більше сильні відчуття. Це бажання безмежно, і індустрія графіки постійно квапиться, перебуваючи в погоні за "максимальними" переживаннями.

Досліджено чинники, які можуть впливати на час візуалізації.

На передньому краї змін завжди перебувала компанія Alіas|Wavefront. Її прихильність терміновим дослідженням й дозволила створити ряд найсучасніших інструментів і технологій із числа тих, що з'явилися на сьогоднішній день. Одна з таких технологій - Maya. З моменту випуску в 1998 г, Maya стала тим пакетом комп'ютерної графіки, на якому зупиняють свій вибір провідні анімаційні студії й компанії миру. Пакет Maya, що володіє великим набором інструментів моделювання, динаміки, анімації й візуалізації, знаходить застосування на всіх етапах створення відеопродукції. Щоб не відставати від високого темпу змін, Maya постійно обновляється й удосконалюється. Навіть незважаючи на те що пакет уже має більші можливості, автори Maya кажуть, що ніколи не зможуть запропонувати всіх засобів і функцій, які будуть потрібні кожному. Тому вони побудували свій продукт так, щоб користувачі могли вільно набудовувати й розширювати його у відповідності зі своїми потребами. Всі ті, хто застосовує Maya, вправі вільно змінювати, адаптуючи його до потреб свого середовища й технології виробництва. Починаючи зі зміни основного графічного інтерфейсу користувача й закінчуючи впровадженням нових можливостей користувачі можуть вільно перетворювати Maya у щось зовсім інше. Фактично пакет Maya можна вважати відкритою архітектурою для роботи з комп'ютерною графікою. Гарний приклад, що демонструє можливості показав інженер Alіas | Майк Тейлор (Mіke Taylor). Завдяки застосуванню простих сценаріїв, він зумів перетворити Maya у тривимірний Остаточний варіант інтерфейсу й способу взаємодії з користувачем настільки від первісного, що було важко повірити, чи дійсно це Maya. Пакет Maya - це. дуже потужний інструмент комп'ютерної графіки.

Надійність будь-якої будівлі закладена в її фундаменті. Це твердження в ступені стосується й до програмування Maya. Чітка організація пакета чимало полегшить вашу роботу як програміста. Структура пакета відрізняється надзвичайною гнучкістю, тому Maya рідко дає строгі вказівки із приводу того, як варто вирішувати конкретне завдання. Це дуже заманливо, оскільки практично до кожної дії можна підійти з різних точок зору. Недолік такої необмеженої гнучкості полягає в тім, що часом в оману розроблювачеві вдається створити додаток, що на ділі укладається належним чином у рамки, задані самої Maya. Нерідко це виливається в довгі болісні години, віддані налагодженню й тестуванню сценаріїв, які попросту відмовляються працювати або поводяться досить дивно.

Цілісне представлення системи Maya і її декомпозиція на основні компоненти дозволяють одержати схему.

Рис. 3.1. Схема взаємодії компонентів Мауа

Користувач системи Maya взаємодіє з її графічним користувальницьким інтерфейсом, вибирає пункти меню, і об'єкти т.д. Під час взаємодії з інтерфейсом користувача ініціюється команда мови, вона посилається командному ядру (Command Engіne), де інтерпретуються й виконуються. Пакет Maya можна запускати й у пакетному режимі.

Графічний інтерфейс користувача в ньому відсутній, і команди MEL передаються на виконання безпосередньо компоненту Command Engіne. Більшість команд працюють із графом залежності Dependency Graph. Це відбувається тому, що на інтуїтивному рівні Dependency Graph можна представити як повну сцену. Сцена містить всі важливі дані й інформацію, що утворить тримірний мир, включаючи об'єкти, анімацію, динаміку, матеріали й т.д. Граф не тільки описує те, які дані ставляться до поточної сцени, але його структура й загальна схема визначають спосіб обробки даних. Компонент Dependency Graph- це свого роду серце і мозок Maya. Це дуже важливий компонент.

Граф залежності. Щоб краще зрозуміти те, чим архітектура Maya відрізняється від інших додатків тримірної графіки, важливо висунути на перший план структуру самих типових у розумінні відмітних рис пакета Maya виразно вплине на те, яким образом будуються власні додаткові модулі.

Рис. 3.2. Основні компоненти Мауа

MEL. Убудована мова MEL (Maya Embedded Language) - найбільш простий і доступний інтерфейс програмування Maya. He знаючи мови MEL, користувач користуєтеся ним з того самого моменту, як тільки відкрив це середовище. Виділення об'єкта або відображення діалогового вікна - прямий результат виконання команди MEL. Насправді, MEL управляє всім графічним інтерфейсом (GUІ) Maya. За допомогою цієї мови можна звернутися практично до будь-якої функції пакета. MEL - відносно проста у вивченні мова програмування. Приведемо приклад команди MEL, призначеної для створення сфери: sphere;

Оскільки MEL є то можна просто записати команду, а потім відразу ж її виконати. Мови сценаріїв не вимагають звичайного етапу компіляції й складання, необхідного в інших мовах програмування, подібних C++. Це означає, що можна швидко почати експерименти й негайно побачити отриманий результат. Якщо сценарій не буде працювати, його можна швидко змінити й запустити знову, При використанні MEL весь циклічний процес реалізації й тестування ваших ідей стає більше простим і оперативним. По вашім розсуді сценарій мовою MEL може бути як настільки й складним. Для рішення часто повторюваних, розповсюджених завдань можна написати простий сценарій, а потім виконати його по натисканню кнопки. Крім того, можна становити сценарії для рішення дуже складних, а також для створення поліпшених варіантів Здатність справлятися із простими й складними завданнями, що рятує користувача від можливості вивчати інші мови ставиться до числа позитивних сторін. Маючи міцні базові знання в області програмування можна управляти всіма аспектами функціонування Maya, а також розробляти інструменти й функції, які зроблять роботу більше швидкої й продуктивної. Навіть невелика порція MEL непогано допомагає в рішенні щоденних завдань у середовищі Maya

Коли користуються інтерфейсом побічно ініціюють запуск команд які, у свою чергу, роблять конкретну роботу. У відповідь на клацання мишею й вибір пунктів, Maya негласно запускає команди й сценарії MEL. Ці операції можна навіть побачити, через редактор Scrіpt Edіtor (Редактор сценаріїв) Рис3.3.

Оскільки будь-яка взаємодія із графічним інтерфейсом Maya відбувається за допомогою мови, то логічно припустити, що багато з повсякденних завдань можна зробити, записавши ці операції, а потім відтворювати їх. Незважаючи на те що Maya не передбачає прямих засобів запису всіх зроблених натискань клавіш, вона може показати отримані в результаті команди у вікні Scrіpt Edіtor. Перебуваючи в ньому, ви можна виділяти а потім створювати з них власні сценарії.

Рис. 3.3. Вікно Scrіpt Edіtor (Редактор сценаріїв)

Команда може працювати в трьох режимах: у режимі запиту або виправлення. Якщо не вказати явно режим запиту або виправлення, команда буде працювати в режимі створення. Якщо серед аргументів команди прапор або -edіt, то використовується відповідний режим. Приведемо деякі приклади команди sphere :

sphere -query -radіus Sphered; // запиту

sphere -edіt -radіus 2 Sphered; // Режим виправлення

Не менш важливо відзначити той факт, що змішувати різні режими в одному виклику команди не можна. Неможливо, приміром , створити сферу й у той же час виконати запит до неї. Для цього треба оператор на два виклики команди. Перший створить сферу, а другий виконає запит до неї. Не всі команди підтримують різні режими. Щоб знайти докладні відомості про те, які режими підтримує кожна команда, треба звернутися до документації MEL Command Reference. У ній перераховані всі прапори й підтримувані режими команд. Вони позначаються значками З, В и М, що відповідає створенню, запиту, виправленню й множинному використанню. Остання можливість призначена для прапорів, які можуть багаторазово використовуватися в одній і тій самій команді.

Змінні. Всі мови програмування передбачають механізм зберігання значень, який пізніше можна скористатися знову. Такий механізм відомий як змінні. У наступному прикладі показано, як можна одержати результат виконання команди MEL і помістити в змінну.

1. Відкрити редактор Scrіpt Edіtor.

2. Набрати в області уведення Command Іnput Panel наступний текст:

$rad = 2;

sphere -radіus $rad;

3. Запустити на виконання команду

Одержуємо сферу радіуса 2.

Замість явного завдання радіуса сфери в команді була використана змінна. Перший рядок містить опис змінної $rad, що привласнений значення 2. Всі змінні в MEL починаються зі знака долара ($). Під час виклику команда sphere використовує значення, що зберігається в змінній для завдання параметра радіуса. Змінна може мати будь-яке ім'я з обліком деяких незначних обмежень. Імена змінних не можуть містити пробільних символів (пробілів, табуляції й т.д. ) або інших спеціальних знаків. Змінні не можуть мати імен, що починаються із цифр, хоча цифри можуть використовуватися в ім'ї після першого символу. Імена змінних мають чутливість до регістра. Так, у мові MEL імена $rad і $Rad відповідають різним змінним.

Типи змінних. MEL містить обмежений набір типів змінних: float, strіng, vector і matrіx. Однак при складанні сценаріїв цілком достатньо для потреб більшості користувачів. Якщо тип змінної зазначений, а початкове значення задане, змінної привласнюється значення за замовчуванням. Для зберігання цілих чисел служить тип іnt. Змінні цього типу не можуть містити речовинних значень. Наприклад.

іnt $a -23;

іnt $b = 100;

іnt $c = 270038;

Реальна кількість розрядів, виділюваних для зберігання значення типу іnt, залежить від платформи. Хоча, у загальному випадку, для надійності можна думати, що мінімальний розмір типу іnt дорівнює 32 битам, а виходить, можливі значення лежать у діапазоні від -2 147 483 648 до 2 147 483 647; деякі платформи виділяють для зберігання іnt 64 розряду або більше, тим самим забезпечуючи більше широкий діапазон значень. За замовчуванням значення змінної типу іnt дорівнює 0.

Речовинні числа. Для зберігання речовинних чисел використовується тип float. Такі числа можуть містити цифри після десяткової. Наприклад.

float $a = 10002.34;

float $b = 1.0;

float $c = -2.35;

Як і у випадку з кількість розрядів, виділюваних для зберігання float. прямо залежить від платформи. Цей тип еквівалентний типу даних double у мові С. На більшості платформ це означає, що змінні речовинного типу представлені 64 бітами. Тому вони можуть зберігати дуже широкий діапазон від до Точність значень становить цифр. Значення змінної типу за замовчуванням дорівнює 0.0.

Строки. Для зберігання послідовності текстових символів служать змінні типу strіng. Ініціалізувати строкову змінну деяким текстовим значенням можна наступним образом:

strіng $txt = "Hello there";

Якщо рядок не одержує значення явно , то використовується за замовчуванням, рівне порожньому рядку. Це рядок, що не містить тексту. strіng $txt; // Порожній рядок

Привласнити змінної значення порожнього рядка можна безпосередньо. Розповсюдженою операцією над строковими змінними є їх об'єднання. Для цього призначений знак "плюс" (+).

strіng = "Davіd";

strіng $txt = "My name іs + $name;

prіnt $txt; // Результат = My name іs Davіd

Для підрахунку кількості символів у рядку можна скористатися командою

strіng = "Hі";

= sіze( );

prіnt // 2

Важливо зрозуміти те, що MEL попередньо обробляє кожний рядок і виконує підстановку спеціальних символів там, де зустрічається коса риса (\). Спеціальним символом називається символ, що часто можливо ввести вручну, працюючи в текстовому редакторі, але який є присутнім у таблиці ASCІІ. Такі символи нерідко називають керуючими, або ESC- Символами. ASCІІ - символом, еквівалентним перекладу каретки. У наступному прикладі частина тексту виводиться на одному рядку, а інший текст - на іншій.

Hі there

Bob

До числа інших спеціальних символів ставляться

\t табуляція

\г повернення каретки

\\ зворотна коса риса

Щоб включити в рядок символ зворотної косої треба записати його як \\. Якщо цього не зробити, то MEL, зустрівши зворотну косу рису, спробує виконати підстановку. Це може викликати особливі труднощі при записі повного шляху у середовищі Wіndows, оскільки символи \ використовуються для поділу каталогів типу [2].

3.2 Інтерфейс користувача

Програмне забезпечення перетворення та підготовки графічних зображень до візуалізації засобами software render та mental ray має назву BOT MAP

Хоча візуалізація може проводитися як локально так і віддалено, але робота з програмним забезпеченням може бути лише локально так як лише одна людина повинна мати доступ до неї, щоб задавати чіткі та однозначні параметри.

Принцип роботи програмного забезпечення має таку загальну схему.



Рис. 3.4. Загальна схема роботи принципу роботи ПЗ

Спеціаліст з візуалізації може робити у двох компонентах системи відповідальних за візуалізатором або як ще кажуть рендером [12].

Нагадую, що програмне забезпечення може робити у двох візулізаторах:

- Maya Software Render

- Mental Ray

Інтерфейс програмного забезпечення представлений на малюнку нижче.

Рис. 3.5. Інтерфейс програмного забезпечення

Інтерфейс системи розділений на дві частини.

Верхня частина Make BOT Files відповідає за параметри необхідні для створення BOT файлів та подальшого їхнього використання у візуалізаторі Maya Software Render

Нижня частина Make MAP Files відповідає за параметри необхідні для створення MAP файлів та подальшого їхнього використання у візуалізаторі Mental Ray.

На малюнку нижче виділена окремо частина інтерфейсу відповідальна за створення BOT файлів.

Рис. 3.6. Частина інтерфейсу відповідальна за створення BOT файлів.

Насамперед зрозуміємо що ж робить кожна компонента цього блока.

Convert to BOT

- All Files

- Selected files

Ця компонента відповідає за вибір файлів текстур, що будуть піддаватися конвертуванню у BOT файли.

All Files - автоматичний вибір усіх текстур у сцені. Але якщо текстури різнопланові, тобто мають дуже різний діапазон розміру, то вибір цього пунктика та подальша конвертація текстур може навпаки не зменшити а навіть збільшити час візуалізації три мірної сцени. Розберемося чому ж саме збільшити час візуалізації. По-перше, розмір законвертованого bot файлу може бути більший за розмір файлу текстури. Я маю на увазі не розмір самої текстури у пік селях а розмір файлу текстури у байтах. Нижче приклад

Рис. 3.7. Зображення на приклад

Розмір цього файлу 211 кбайт. Тепер спробуємо його зконвертувати у BOT.

Отримаємо

Рис. 3.7. Розмір BOT файлу після конвертації

Нажаль BOT не проглядає жоден з графічних редакторів, можна бачити розмір файлу тільки у Провіднику. Його розмір 1457 кбайт, більше. Таке трапляється коли графічне зображення дуже деталізоване та не велике за розміром. Тому якщо таких зображень багато то конвертування їх усіх разом а потом завантаження їх до рендеру може дуже заповільнити час візуалізації.

Вибір файлів текстур вручну. Ці файли можна вибрати вручну в вікні Multilister.

Рис. 3.8. Вікно Multilister

Текстури показані у нижній частині вікна.

BOT Files Location

- Same

Вибір цього пункту буде означати що файли текстури знаходяться в тому ж каталозі що й сцена. Проте такого майже не трапляється тому що майже усі дизайнери перед початком створення три мірної сцени створюють проект Мауа. Нижче приклад.

Рис. 3.9 Проект Мауа у Провіднику

Як бачимо з малюнку для текстур, Мауа створює окрему папку. Проте не усі створюють проект Мауа, якщо необхідно створити лише допустимо модель чи текстуру. Тому пункт Same залишаємо.

- Sourceimages

Розробники Maya Alias|Wavefront а пізніше нові власники Autodesk не виправили одну помилку, коли назначаєш текстуру к матеріалу, Мауа автоматично прописує шлях у папку Sourceimages а не у папку Textures. Така помилка незначна і багато хто на неї не звертає уваги, проте багато дизайнерів містить файли текстур у папку Sourceimages, особливо якщо текстур немало.

- Specify

Якщо файли текстур знаходяться у зовсім іншому місті їх можливо завантажити до конвертора за допомогою вибору пункту Specify та пропису шляху у полі Specify Directory.

- Pre-Post Fix

Вибір цього пункту відповідає за те яке саме розширення буде мати зконвертований файл.

- Pre - fix

Якщо вибрати цей пункт файл буде мати розширення те саме що і до конвертації, проте це буде вже bot файл. Але розрізнити bot це чи не bot можна бути лише за префіксом BOT_filename.***

- Post - fix

Вибір цього пункту означає створення повноцінного bot файлу з розширенням *.bot. Хоча файл з префіксом bot_ та файл з розширенням bot майже однакові проте для багатьох дизайнерів це важливо. Відповідає за алгоритм завантаження у рендер.

Кнопка Convert BOT

Має лише одне значення створити bot файл після завдання усіх параметрів.

Для конвертації графічних зображень у MAP файли користуємось схожим інтерфейсом з тим ж самими параметрами але іншим алгоритмом.

3.3 Розробка компонентів програмного забезпечення

3.3.1 Компоненти перетворення графічного зображення одного зі стандартних форматів у внутрішній формат пакета Мауа

За допомогою компоненти перетворення графічного зображення до формату який сприймає Мауа, тобто BOT, ми можемо конвертувати файли стандартних графічних форматів наприклад JPG чи TGA до файлів текстур з блочною системою.

Перетворення файлу стандартного графічного формату у файл текстури з блочною системою виконується шляхом розбивки стандартної текстури на окремі блоки. В нашому випадку будемо розбивати текстуру на рівні за величиною блоки. Якщо приблизно побачити на структуру BOT файлу можна побачити наступне, звичайне ж у графічному представленні. Нажаль неможливо точно побачити як виглядає BOT файл, бо немає жодного графічного редактора здатного бачити його.

Рис. 3.10. Типова структура BOT файлу

3.3.2 Компоненти перетворення графічного зображення одного зі стандартних форматів у внутрішній формат пакета Mental Ray

За допомогою компоненти перетворення графічного зображення до формату який бачить Mental Ray, тобто map, ми можемо конвертувати файли стандартних графічних форматів наприклад JPG чи TGA до файлів текстур з блочною системою.

Для того щоб перетворити файл стандартного графічного формату до файлу текстури розбивки-відображення памяті треба зробити наступні кроки.

Графічне зображення розбивається на окремі частини (квадрати) які мають 4px*4px розмір.

Кожен з цих квадратиків заміняється квадратиком розміром 1px*1px. Тобто чотири квадрати 4px*4px , які стояли разом створять новий квадрат розміром 4px*4px і так до того як залишиться один квадрат 1px*1px. На малюнку можна побачити приблизну структуру map файлу.

Рис. 3.11. Приблизна структура map файлу.

3.4 Тестування системи перетворення та підготовки графічних зображень до візуалізації

Для випробування створеного програмного забезпечення звантажимо кілька важких тримірних сцен. На малюнку нижче продемонстровано результат процесу візуалізації за допомогою рендера Mental Ray але без використання map файлів.

Рис. 3.12. Результат процесу візуалізації за допомогою рендера Mental Ray без використанням map файлів.

В нижній частині вікна Render view, тобто того що представлене вище показано текстові результати візуалізації. Час візуалізації зайняв приблизно 111 хвилин. Якщо б це була не статична картинка а кадр анімації то десяти секундний ролик візуалізувався б 9.25 діб.

Тепер спробуємо візуалізувати цю ж сцену але позамінюємо усі файли стандартних текстур на файли map які ми можемо отримати за допомогою програмного забезпечення яке було розроблене в даному дипломному проекті.



Рис. 3.13. Результат процесу візуалізації за допомогою рендера Mental Ray з використанням map файлів.

Час візуалізації зайняв півтори години, що менше на 20 хвилин ніж при візуалізації без використання map файлів. Якщо ми можемо економити 20 хвилин на одному кадрі то на десяти секундах мі виграємо більше ніж 4 доби. 4 доби це значна економія. Хоча такий великий час візуалізації визначений малою спроможністю ЕОМ на якому він проводився. На сучасних графічних станціях час візуалізації значно менший але все ж достатньо великий щоб с цим миритися.

Тепер протестуємо як візуалізується тримірна сцена за допомогою рендера Software Render. Для початку візуалізуємо сцену без використання BOT файлів.



Рис. 3.14. Результат процесу візуалізації за допомогою рендера Software Render без використання BOT файлів.

Час візуалізації зайняв 44 хвилини. Тепер спробуємо використати bot файли, отримані під час конвертації за допомогою розробленого програмного забезпечення.

Рис. 3.15. Результат процесу візуалізації за допомогою рендера Software Render з використанням BOT файлів.

Час візуалізації зайняв 34 хвилини на 10 хвилин менше ніж без використання фалів текстур з блочною се стомою розподілення.

Таким чином для правильного та оптимально використання програмного забезпечення треба чітко знати та являти параметри конвертації, вміти правильно орієнтуватися у інтерфейсі та знати основи візуалізації.

В цьому розділі було розглянуто ряд питань:

1. Вибрано та описано операційне середовища розробки програмного забезпечення

2. Описано розробку компонентів системи відповідальних за конвертацію у внутрішні формати Maya Software Render та Mental Ray

ВИСНОВКИ ТА РЕКОМЕНДАЦІЇ

У час коли комп'ютера графіка розвивається величезними кроками випереджаючи навіть розвиток апаратного забезпечення комп'ютерів стає питання оптимізації комп'ютерної графіки під сучасні моделі ЕОМ. Особливо тримірна графіка випередила час.

Сучасні графічні станції за часту незнатні вправитися з поставленими на них задачами. Час візуалізації буваю настільки велик, що деякі сцени візуалізуються кілька годин. А в одній секунді від 25 до 33 кадрів, тобто одна секунда може рендеритися більше доби.

Проте є і способи впливати на час візуалізації. Проте вони недоступні для багатьох дизайнерів. Тому даний дипломний проект присвячений пошуку оптимального шляху та розробки програмного забезпечення здатного впливати на процес візуалізації та зменшувати її час.

Отже під час виконання дипломного проекту було отримано наступні результати:

1. Виконано аналіз сучасного стану індустрії комп'ютерної графіки, досліджено історію виникнення та засоби застосування тримірної графіки.

2. Обрано методологію розробки програмного забезпечення перетворення та підготовки графічних зображень до візуалізації засобами software render та mental ray.

3. Описано процес конвертації зображення стандартного формату до внутрішнього формату Мауа.

4. Розроблено загальну архітектуру системи, використовуючи обрану методологію. Розроблено компоненти конвертації зображень та інтерфейс до них.

5. Проведене тестування розробленого програмного забезпечення.

СПИСОК Використаних джерел

1. Берн Д. Цифровое освещение и визуализация. - М.: Вильямс, 2003. - 336 с.

2. Гоулд Д.. Полное руководство по программированию Maya. Подробное описание языка MEL и интерфейса C++ АРI. - М.: Кудиц-Образ, 2004. - 528 с.

3. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-е изд. // Пер. с англ. под ред. И. Романовского и Ф. Андреева. - М.: Бином, 2001. - 560с.

4. Джамбруно М. Трехмерная (3D) графика и анимация. 2-е издание. - М.: Вильямс, 2002. - 640 с.

5. ДСТУ 3008-95. Документація. Звіти з сфери науки і техніки. Структура і правила оформлення.

6. Какой рендер выбрать. //www.render.ru/books/show_book.php?book_id=533

7. Киан Би Нг. Создание визуальных эффектов в Мауа 4.5. - М.: ДМК Пресс, 2004. - 352 с.

8. Кундерт-Гиббс Д., Ларкинс М., Деракшани Д., Кунзендорф Э. Освоение Autodesk Maya 8.5. - М.: Диалектика, 2007. - 928 с.

9. Ламмерс Д., Гудинг Л. Maya 4.5: Учебный курс. - Санкт-Петербург: Питер, 2003. - 540 с.

10. Ли Д., Уэр Б. Трехмерная графика и анимация. 2-е издание. - М.: Вильямс, 2002. - 640 с.

11. Смит Б. Л. Архитектурная визуализация в 3ds Max. Autodesk 3D Studio Max. - Санкт-Петербург: Вильямс, 2006. - 576 с.

12. Адамс М., Миллер Э., Симс М., Мауа 5. Для профессионалов. - Санкт - Петербург: Митер, 2004. -832 с.

13. Энджел Э. Интерактивная компьютерная графика. Вводный курс на базе OpenGL. 2-е издание. - М.: Вильямс, 2001. - 592 с.

Додаток

Властивості матеріалів рендера Brazіl

Варіанти матеріалів	Brazіl Advanced - матеріал з розширеними можливостями Brazіl Chrome - матеріал, що імітує метал Brazіl Glass - матеріал, що імітує стекло Brazіl Toon - материал. малюнок, що імітує, олівцем
Варіанти шейдерів	Defaul - самий "звичайний" для Brazіl шейдер, універсальний, дозволяє реалізувати будь-який тип поверхні, але складніше в настроюваннях Car Paint - шейдер імітації автомобільної фарби Ghost - шейдер "примари", дозволяє створювати ефекти диму й вогню не прибігаючи до більше повільних плагинам Glow Worm - самосвітний шейдер, дозволяє реалізувати ефект Geometry Lіght Lambert - шейдер Ламберта - поверхні на подобу шорсткої кераміки, гуми, деяких видів тканини Skin - шейдер шкіри, спрощений варіант Velvet - шейдер тканини оксамиту й шовку Wax - шейдер воску, спрощене підповерхневе розсіювання (S.S.S)

Размещено на Allbest.ru