Розробка підсистеми візуалізації моделей і їх модифікації

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати


РЕФЕРАТ

Звіт з НДРС: __ с., __ Рис., __ Джерел

Об'єктом даного НДРС є процес моделювання, який має на увазі під собою певну групу дій або подій. Метою дослідження є побудови систем візуалізації моделей розкрою і їх модифікації.

При виконанні даної роботи необхідно: проаналізувати способи і методи створення універсального сховища даних, на прикладі побудови динамічно формується інформаційного файлу або ж іншими словами - метафайл. Дослідити основні графічні можливостей мови високого рівня С #, а також розглянути можливість побудови криволінійних поверхонь, грунтуючись на графічній бібліотеці GDI +.

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

Сховище, ГРАФІКА, СПЛАЙН, метафайл, ШАБЛОН, OPENGL

ЗМІСТ

Введення

1. Способи та методи створення сховищ даних

2. Вибір бібліотеки візуалізації

2.1. Бібліотека Direct 3 D

2.2. Бібліотека OpenGL

2.3. Бібліотека GDI +

3. Огляд мов високого рівня

3.1. Мова високого рівня С + +

3.2. Мова високого рівня С #

4. Побудови криволінійних поверхонь

4.1. Сплайн Безьє

4.2. Кубічні сплайни

Висновки

Список використаних джерел

ВСТУП

Мета НДРС - дослідження побудови систем візуалізації моделей і їх модифікації. У зв'язку з поставленою метою необхідно виконати наступні головні завдання.

  1. Дослідити методи побудови креслень викрійок.

  2. Вивчити існуючі системи візуалізації.

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

Одним з найбільш популярних напрямків розробки програмного забезпечення на сьогоднішній день є розробка систем підтримки прийняття рішень. Як відомо, структурно будь-яка СППР складається з бази даних, бази моделей та засобів візуалізації. База даних містить початкову інформацію про розв'язуваної задачі і результати виконання проміжних кроків пошуку рішень. База шаблонів містить правила і обмеження, за якими вхідна інформація перетворюється на вихідну. Засоби візуалізації дозволяють користувачеві в інтерактивному режимі задавати початкову інформацію про розв'язуваної задачі, контролювати процес виконання реалізованих методів і алгоритмів, а також оцінювати отримані рішення. СППР на сьогоднішній день застосовуються практично у всіх областях знань. У даній роботі проводяться дослідження можливості побудови СППР для вирішення задачі інтерактивного конструювання моделей одягу, коли користувач за обраним шаблоном проектує модель, додаючи до шаблону вибрані деталі і перетворюючи її в відповідно до заданих розмірів.

1. СПОСОБИ І МЕТОДИ СТВОРЕННЯ СХОВИЩ ДАНИХ

Працюючи з графікою, рано чи пізно постане завдання у передачі інформації від однієї програми до іншої. Для того щоб наша програма могла швидко і з найменшими труднощами зберегти дані, необхідно скористатися стандартом Windows - WMF. WMF - абревіатура від "Windows Metafile Format" (метафайл Windows). Використовується для обміну графічною інформацією між додатками, а також для компактного зберігання інформації малювання. Підтримує вектору і растрову графіку. У метафайлу записані команди інтерфейсу графічних пристроїв (GDI-команди), кожна з яких описує одну графічну функцію. Для того, щоб відобразити метафайл, програма передає ці команди спеціальної функції, яка відтворює зображення. Метафайли забезпечують незалежні від пристрою засоби зберігання та вибірки графічної інформації. На відміну від растрових файлів, що зберігають графічну інформацію безпосередньо, а у вигляді пікселів, метафайли ідеально підходять для таких зображень, як карти, діаграми, архітектурні креслення та інші малюнки, що складаються з перекриваються фрагментів. Так, наприклад, в САПР, метафайли можуть застосовуватися для запам'ятовування даних. Вони також корисні при передачі зображень в їх власних форматах в системний буфер, для використання їх іншими додатками. Якщо зображення може бути намальовано з допомогою команд GDI, воно може бути передано іншій програмі як метафайл. При цьому мається на увазі, що програма знає, як інтерпретувати команди метафайлу. Усі найбільш популярні додатки використовують WMF-файли для зберігання графічної інформації. Виходячи з вище описаного, можна сказати, що для реалізації універсального сховища даних, необхідно застосувати метафайл-структуру, яка формується динамічно в процесі створення і подальшої модернізації моделей одягу. Процес формування можна розбити на два етапи: формування в процесі створення шаблону, і доповнення або коригування надалі. Перший має на увазі під собою створення певної інформації для малювання, після того як буде створено шаблон моделі по зазначених розмірах. Другий етап, це коригування вже існуючої інформації в метафайл, тобто коли необхідна візуальна модернізація, або ж доповнення нової як наслідок приєднання нових, деяких окремо заданих деталей.

2 ВИБІР БІБЛІОТЕКИ ВІЗУАЛІЗАЦІЇ

OpenGL і Direct 3 D - дві основні на сьогоднішній день апаратно-прискорює бібліотеки для створення комп'ютерної тривимірної графіки, а також бібліотека GDI + (доповнена GDI), призначена для роботи в рамках Microsoft. NET Framework, також заснована на OpenGL і Direct 3 D, і являє собою набір класів. Ці класи інкапсулюють поведінку об'єктів та інструментів, призначених для малювання. Розглянемо детальніше кожну з них.

2.1 Direct 3 D

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

У DirectX 9.0 функціональність DirectDraw і Direct3D об'єднана в єдиний API, названий DirectX Graphics. Direct3D - частина цього компоненту і буде в центрі нашої уваги. Microsoft Direct3D надає програмісту вибір з двох варіантів: використовувати конвеєр стандартних функцій (fixed-function pipeline) або програмований конвеєр (programmable pipeline). Перший покладається на існуючі алгоритми, стандартизовані в Direct3D. Стандартні функції (fixed functions) надаються через фіксований набір перелічуваних значень за аналогією з OpenGL. Це має на увазі, що конвеєри стандартних функцій і в Direct3D, і в OpenGL використовують внутрішні оператори switch. Деякі з блоків case, відповідних перераховуваній значенням в операторі switch, можуть виконуватися з апаратним прискоренням в залежності від функціональності (можливостей) графічної плати, з якою має справу виконуюча середовище (runtime). При використанні конвеєра стандартних функцій в Direct3D програміст спочатку перевіряє через виконуючу середу, чи підтримує дана графічна плата конкретну функціональність.

Оскільки деякі графічні плати підтримують не всі функції, доступні через Direct3D, передбачений механізм перевірки можливостей апаратного забезпечення. Якщо дана функція не підтримується апаратно, перевірка закінчується невдачею, що дозволяє програмістові перемкнутися на інший алгоритм з апаратним прискоренням. Головне - пам'ятати, що Direct3D-конвеєр стандартних функцій надає доступ до апаратної функціональності. Хоча в Direct3D є режим чисто програмної емуляції (software-only emulation mode), також званий еталонним пристроєм (reference device), він призначений лише для налагодження і тестування.

Інший, більш цікавий підхід до проблеми паралельної еволюції апаратного та програмного забезпечення - застосування програмованого конвеєра. У цьому випадку замість вибору зумовленого перечислимого значення і запиту до Direct3D на виконання відповідного алгоритму програміст визначає власний алгоритм. Виконуюча середу Direct3D динамічно компілює цей алгоритм для нижчого апаратного забезпечення, взаємодіючи з JIT-компілятором, який є частиною драйвера пристрою. За створення JIT-компіляторів для конкретних графічних пристроїв відповідають постачальники обладнання. Таким чином, Direct3D виступає в ролі графічної віртуальної машини (graphics virtual machine), яка фактично віртуалізує графічний процесор (GPU) на основі призначеного для користувача набору команд для графічних операцій.

Хоча обидва програмних рівня Direct3D (керований і некерований) надаються через групи об'єктів, не слід вважати їх інфраструктурою програмування прикладного рівня. Основна роль архітектури Direct3D - забезпечити доступ до базової функціональності рішенням вищого рівня, наприклад API ігрових движків. Щоб спростити реалізацію таких рішень, бібліотека розширень Direct3D (Direct3D extension library) явним чином надає додаткову функціональність. Для кращого розуміння архітектури Direct3D ви повинні розібратися не тільки в абстрагіруемой функціональності, але і в тому, як ця функціональність структурована і як до неї звертатися. У декількох наступних розділах ми дамо огляд основних елементів архітектури Direct3D і обговоримо, яким чином організований доступ до них з некерованого COM API і керованого рівня абстракції. NET. Як це нерідко буває в архітектурах комп'ютерного апаратного забезпечення, в архітектурах апаратного прискорення тривимірної графіки застосовуються два способи оптимізації: конвейеризация (pipelining) і паралелізації (parallelizing). Алгоритми, доступні через Direct3D, логічно організовані в конвеєр.

Конвеєр Direct3D слід розглядати як набір алгоритмів, що виконують операції над тривимірними геометричними величинами (3D geometric quantities), якими в разі Direct3D є зумовлені вершини (vertices) і примітиви (primitives). Основне призначення конвеєра - перетворення геометричних даних у зображення, що формується на екрані. Етап тесселяції в Direct3D - розбиття на трикутники фіксованого набору визначених примітивів більш високого порядку, в тому числі трикутних (triangle patches), прямокутних (rectangle patches) і полігональних ділянок поверхонь (N patches) (хоча трикутні ділянки поверхні залишаються найбільш поширеною формою). В даний час етап тесселяції не можна програмувати, тому Direct3D не надає ніяких механізмів для генерації геометричних даних на основі програмованих процедур. А така можливість дозволила б різко зменшити обсяги даних, що пересилаються по шині. Апаратна підтримка програмування етапу тесселяції, мабуть, з'явиться в найближчому майбутньому [4].

Етап трансформацій і освітлення (transform and lighting, T & L) забезпечує перетворення позицій вершин і трансляцію системи координат моделі у світову систему координат і систему координат камери. Обчислення освітленості для кожної вершини виконуються для визначення відбитої і розсіяної колірних компонент (specular and diffuse color components). Потім позиції вершин модифікуються в ході трансформації проекції (projection transformation), щоб отримати перспективну проекцію (perspective projection), ортогональну (orthographic projection) або іншого типу. Хоча конвеєр стандартних функцій як і раніше надає ці алгоритми T & L через той же API, що й раніше, в більшості графічних плат вони можуть бути реалізовані на рівні мікрокоду графічного процесора. Так, в процесорі Radeon 9700 весь модуль T & L можна і потрібно реалізувати в програмованому конвеєрі як вершинні шейдери (vertex shaders).

Для більшої швидкодії на етапі растеризації будь-які вершини невидимих ​​камері об'єктів вирізаються (clip). А щоб уникнути растеризації трикутників, відвернути від камери, може виконуватися операція відсікання невидимих ​​поверхонь (back-face culling). Більше того, для вибору і настройки реальних алгоритмів, які будуть задіяні на етапі растеризації, використовується оцінка атрибутів (attribute evaluation). Нарешті, після всіх цих оптимізацій починається власне растеризація, в ході якої здійснюється рендеринг пікселів.

На етапі обробки пікселів ви можете використовувати для визначення значення кольору (color value) пікселя або мультитекстурирование на основі стандартних функцій (fixed-function multi-texturing), або програмовані піксельні шейдери (pixel shaders). Мультитекстурирование на основі стандартних функцій реалізується за рахунок багатопрохідного накладення текстур, причому на кожному проході над значеннями кольору і прозорості (color and alpha values) піксела можна виконувати фіксований набір операцій. Піксельні шейдери дають набагато більшу гнучкість, дозволяючи оперувати значеннями кольору і прозорості на власній мові асемблера (custom assembly language). Алгоритми, реалізовані на етапі обробки пікселів, включають накладення рельєфу (bump mapping), затінення (shadowing), накладення карти середовища (environment mapping) і т. д.

При обробці буфера кадру (frame buffer processing) використовується набір регіонів пам'яті, відомих як поверхня рендеринга (render surface), буфер глибини (depth buffer) і буфер шаблонів (stencil buffer). На цьому етапі виконується серія обчислень для визначення таких параметрів, як глибина, прозорість (alpha) і шаблон (stencil). Буфер глибини - це ще один метод оптимізації рендеринга, застосовуваний для видалення прихованих ліній і поверхонь. Перевірка глибини дозволяє з'ясувати, які пікселі приховані і не потребують рендеринге. При цьому використовується або z-буфер, або w-буфер (у кожного з них свої плюси і мінуси). Обробка буфера кадру дає можливість створювати ряд ефектів, у тому числі прозорість (transparency), туман (fog) і тіні (shadows).

У конвеєрі Direct3D, - його поведінку можна змінювати через стан графіки (graphics state). Це стан використовується для налаштування багатьох алгоритмів трансформації, освітлення, растеризації, обробки пікселів і буфера кадру, що надаються Direct3D для візуалізації кадру. Воно включає стану рендеринга (render state), трансформації (transformation state), семплера (sampler state) і накладення текстур (texture stage state) [5].

2.2 OpenGL

Зараз тривимірні зображення можна побачити скрізь, починаючи від комп'ютерних ігор і закінчуючи системами моделювання в реальному часі. Раніше, коли тривимірна графіка існувала тільки на суперкомп'ютерах, не існувало єдиного стандарту в галузі графіки. Всі програми писалися з "нуля" або з використанням накопиченого досвіду, але в кожній програмі реалізовувалися свої методи для відображення графічної інформації. З приходом потужних процесорів і графічних прискорювачів тривимірна графіка стала реальністю для персональних комп'ютерів. Але в той же час виробники програмного забезпечення зіткнулися з серйозною проблемою - це відсутність будь-яких стандартів, які дозволяли писати програми, незалежні від обладнання та операційної системи. Одним з перших таких стандартів, що стоїть і донині є OpenGL.

OpenGL - це графічний стандарт в області комп'ютерної графіки. На даний момент він є одним із самих популярних графічних стандартів у всьому світі. Ще в 1982 р. в Стенфордському університеті була розроблена концепція графічної машини, на основі якої фірма Silicon Graphics в своєї робочої станції Silicon IRIS реалізувала конвеєр рендеринга. Таким чином була розроблена графічна бібліотека IRIS GL. На основі бібліотеки IRIS GL, в 1992 році був розроблений і затверджений графічний стандарт OpenGL. Розробники OpenGL - це найбільші фірми розробники як устаткування так і програмного забезпечення: Silicon Graphics, Inc., Microsoft, IBM Corporation, Sun Microsystems, Inc., Digital Equipment Corporation (DEC), Evans & Sutherland, Hewlett-Packard Corporation, Intel Corporation та Intergraph Corporation.

OpenGL перекладається як Відкрита Графічна Бібліотека (Open Graphics Library), це означає, що OpenGL - це відкритий і мобільний стандарт. Програми, написані за допомогою OpenGL можна переносити практично на будь-які платформи, отримуючи при цьому однаковий результат, будь це графічна станція або суперкомп'ютер. OpenGL звільняє програміста від написання програм для конкретного обладнання. Якщо пристрій підтримує якусь функцію, то ця функція виконується апаратно, якщо немає, то бібліотека виконує її програмно.

Що ж представляє з себе OpenGL? З точки зору програміста OpenGL - це програмний інтерфейс для графічних пристроїв, таких як графічні прискорювачі. Він включає в себе близько 150 різних команд, за допомогою яких програміст може визначати різні об'єкти і виробляти рендеринг. Кажучи більш звичною мовою, ви визначаєте об'єкти, задаєте їх місце розташування у тривимірному просторі, визначаєте інші параметри (поворот, масштаб, ...), задаєте властивості об'єктів (колір, текстура, матеріал, ...), положення спостерігача, а бібліотека OpenGL подбає про те щоб відобразити все це на екрані. Тому можна сказати, що бібліотека OpenGL є лише відтворює (Rendering), і займається тільки відображенням 3Д об'єктів, вона не працює з пристроями введення (клавіатури, миші). Також вона не підтримує менеджер вікон.

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

У деяких бібліотеках OpenGL (наприклад під X Windows) є можливість зображувати результат не тільки на локальній машині, але також і по мережі. Додаток, який виробляє команди OpenGL називається клієнтом, а програма, яка отримує ці команди і відображає результат - сервером. Таким чином можна будувати дуже потужні відтворюють комплекси на основі декількох робочих станцій або серверів, сполучених мережею [6]. Що надає бібліотека в розпорядження програміста? Основні можливості:

1) геометричні та растрові примітиви. На основі геометричних і растрових примітивів будуються всі об'єкти. З геометричних примітивів бібліотека надає: точки, лінії, полігони. З растрових: бітовий масив (bitmap) та образ (image)

2) використання В-сплайнів. B-сплайни використовуються для малювання кривих по опорним точкам.

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

4) робота з кольором. OpenGL надає програмісту можливість роботи з кольором у режимі RGBA (червоний-зелений-синій-альфа) або, використовуючи індексний режим, де колір вибирається з палітри.

5) видалення невидимих ​​ліній і поверхонь. Z-буферизація.

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

6) накладення текстури. Дозволяє надавати об'єктам реалістичність. На об'єкт, наприклад куля, накладається текстура (просто якесь зображення), в результаті чого наш об'єкт тепер виглядає не просто як куля, а як різнобарвний м'ячик.

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

8) освітлення. Дозволяє задавати джерела світла, їх розташування, інтенсивність, і т.д.

9) атмосферні ефекти. Наприклад туман, дим. Все це також дозволяє надати об'єктам або сцені реалістичність, а також "відчути" глибину сцени.

10) прозорість об'єктів.

2.3 Бібліотека GDI +

GDI + - це набір програмних засобів, які використовуються в. NET.

GDI + дозволяють творцям додатків виводити дані на екран або на принтер без необхідності забезпечувати роботу з певними типами пристроїв відображення. Для відображення інформації програмістові досить викликати потрібні методи класів GDI +. При цьому автоматично враховуються типи певних пристроїв і виконуються виклики відповідних драйверів. Інтерфейс GDI + є розвитком GDI (Graphic User Interace), використаного в ранніх версіях Windows. Таким чином, модифікація GDI для. NET називається GDI +.

При створенні ОС Microsoft Windows компанія Microsoft позбавила програмістів від необхідності враховувати апаратні особливості відеоадаптерів, переклавши цю задачу на драйвери відеоадаптерів. Ці драйвери створюються розробниками відеоадаптерів і найкращим чином реалізують можливості апаратури.

Що ж стосується додатків, то для них у складі ОС Microsoft Windows був передбачений набір системних функцій, що реалізують інтерфейс графічних пристроїв (Graphics Device Interface, GDI).

Інтерфейс графічних пристроїв GDI, як це можна припустити з назви, призначений для взаємодії додатків Microsoft Windows з графічними пристроями, такими як відеоадаптер, принтер або плоттер.

Коли програми звертаються до GDI для виконання операції виведення графічного зображення, вони працюють не з реальними (фізичними) пристроями виведення, а з логічними пристроями. Програми Microsoft Windows не визначають тип відеоадаптера (EGA, VGA, SVGA і т.п.), а працюють з логічним відеоадаптером, що мають феноменальні характеристики: здатність відображати практично будь-який колір, має величезний дозвіл і т. д.

Виконуючи запит програми, GDI звертається до драйвера пристрою виведення, що працює, у свою чергу, безпосередньо з фізичним пристроєм виводу. У процесі виконання запиту GDI (або драйвер) враховує обмежені можливості відеоадаптера та його апаратні особливості, роблячи необхідні наближення.

Наприклад, програма може вказати для кольору лінії будь-якої із приблизно 16 млн. квітів, проте не всяке пристрій володіє таким колірним дозволом (обмеження на кількість одночасно відображаються присутні, наприклад, у кишенькових комп'ютерах). У залежності від типу фізичного пристрою, використовуваного для висновку, GDI може вибрати для відображення колір, найбільш відповідний запитаному кольором, і допустимий для пристрою.

Наприклад, якщо пристрій виведення монохромне, замість різних кольорів можуть використовуватися градації сірого кольору. Тому додаток може запитати для виведення будь-який колір, але для малювання буде використаний тільки такий, який може використовувати дану фізичну пристрій [4].

Така ситуація, коли додаток запитує в ОС Microsoft Windows одне, а отримує інше, виникає не тільки при роботі з кольором. Додаток може запросити для виведення шрифт, описавши його характеристики. Інтерфейс GDI підбере для виведення найбільш підходящий (з його точки зору) шрифт, відповідний опису, і надасть його додатком.

Програми Microsoft Windows здатні працювати в незмінному вигляді на будь-якому обладнанні, аби був відповідний драйвер. Чим краще використовувана апаратура, чим більшими можливостями вона володіє, тим ближче будуть параметри отриманого шрифту і кольору відповідати запитаним.

Тому навіть якщо зараз в нашому розпорядженні є тільки відеоадаптер з обмеженою кількістю відображуваних кольорів, при розробці додатків Microsoft Windows Ви можете не обмежувати себе дюжиною квітів. Ваше застосування повинне бути зроблено так, щоб воно могло використовувати будь-який колір. З часом, коли у Вас з'явиться сучасний відеоадаптер, вікно Вашого застосування засвітиться всіма барвами веселки, причому для цього не доведеться вносити ніяких змін в сам додаток.

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

Контекст відображення можна порівняти з аркушем паперу, на якому додаток малює те або інше графічне зображення, а також пише текст. Інструменти для малювання - це пір'я, кисті (а також шрифти і навіть цілі графічні зображення), за допомогою яких створюється зображення.

Крім контексту відображення та інструментів для малювання, додаткам доступні десятки функцій програмного інтерфейсу GDI, призначені для роботи з контекстом відображення та інструментами. Що ж стосується додатків Microsoft. NET Framework, то вони реалізують можливості інтерфейсу GDI + за допомогою набору відповідних класів та інтерфейсів.

У термінах ОС Microsoft Windows контекст відображення (display context) представляє собою структуру даних, що описує пристрій відображення. У цій структурі зберігаються різні характеристики пристрою і набір інструментів для малювання, обраний за замовчуванням. Додаток може вибирати в контекст відображення різні інструменти (наприклад, пір'я різної товщини і кольору, з різними «наконечниками»). Тому якщо Вам треба намалювати лінію червоного або зеленого кольору, перед виконанням операції слід вибрати в контекст відображення відповідне перо.

Зауважимо, що функції малювання GDI, що входять у програмний інтерфейс Win32 API, не мають параметрів, що вказують колір або товщину лінії. Такі параметри зберігаються в контексті відображення.

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

Можна створити контекст відображення для метафайлу. Метафайл - це звичайний файл або файл в пам'яті, в якому зберігаються послідовності команд інтерфейсу GDI. Додаток може виконувати графічний висновок в метафайл як у звичайний пристрій виводу, а потім «програвати» метафайл на реальному пристрої виводу.

Контекст пристрою в термінах ОС Microsoft Windows виступає в ролі єднальної ланки між додатком і драйвера пристрою (мал. 1) і являє собою структуру даних розміром приблизно 800 байт. Ця структура даних містить інформацію про те, як потрібно виконувати операції виведення на даному пристрої (колір і товщину лінії, тип системи координат і т. д.).

Малюнок 2.1 - Висновок даних через контекст пристрою

Якщо програма отримує або створює контекст для пристрою відображення, такий контекст називається контекстом відображення (display context). Тому коли, наприклад, додаток отримує контекст для відображення в одному зі своїх вікон, такий контекст називається контекстом відображення. Якщо ж йому потрібно виконувати операцію виводу для пристрою (для принтера або для екрану дисплея), додаток повинен отримати або створити контекст пристрою (device context).

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

Концепція графічного інтерфейсу GDI + дещо відрізняється від концепції «класичного» графічного інтерфейсу GDI, з яких звикли мати справу розробники додатків Microsoft Windows.

Перш за все, це стосується класу Graphics, що реалізує в собі як властивості контексту відображення, так і інструменти, призначені для малювання в цьому контексті [4].

Для того, щоб програма могло що-небудь намалювати у вікні, вона повинна, перш за все, отримати або створити для цього вікна об'єкт класу Graphics. Далі, користуючись властивостями і методами цього об'єкта, додаток може малювати у вікні різні фігури або текстові рядки.

3. ПЕРЕГЛЯД МОВ ВИСОКОГО РІВНЯ

На сьогоднішній день існують безліч мов програмування, але найбільш популярні з них це - С + +, і С #. Розглянемо їх більш детально.

3.1 Мова високого рівня С + +

Страуструп почав працювати над «Сі з класами» в 1979 році. Ідея створення нової мови належить Страуструп. Він виявив, що мова моделювання Симула (Simula) має такі можливості, які були б дуже корисними для розробки великого програмного забезпечення, але працює дуже повільно.

У той же час мова BCPL досить швидкий, але дуже близький до мов низького рівня і не підходить для розробки великого програмного забезпечення. Страуструп почав працювати в «Bell Labs» над завданнями теорії черг (у додатку до моделювання телефонних дзвінків). Спроби застосування існуючих у той час мов моделювання виявилися неефективними. Згадуючи досвід своєї дисертації, Страуструп вирішив доповнити мова Сі (наступник BCPL) можливостями, наявними в мові Симула. Мова Сі, будучи базовою мовою системи UNIX, на якій працювали комп'ютери «Bell» є швидким, багатофункціональним і стерпним. Страуструп додав до нього можливість роботи з класами та об'єктами. У результаті, практичні завдання моделювання виявилися доступними для вирішення як з точки зору часу розробки (завдяки використанню Симула-подібних класів) так і з точки зору часу обчислень (завдяки швидкодією Сі). На початку в Сі були додані класи (з інкапсуляцією), похідні класи, сувора перевірка типів, inline-функції і аргументи за умовчанням. Розробляючи Сі з класами (пізніше С + +), Страуструп також написав програму Cfront, транслятор, що переробляє вихідний код Сі з класами у вихідний код простого Сі. Нова мова, несподівано для автора, придбав велику популярність серед колег і незабаром Страуструп вже не міг особисто підтримувати його, відповідаючи на тисячі питань.

У 1983 р. відбулося перейменування мови з Сі з класами в С + + з міркувань маркетингу. Крім того, в нього були додані нові можливості, такі як віртуальні функції, перевантаження функцій і операторів, посилання, константи, користувальницький контроль над управлінням вільною пам'яттю, поліпшена перевірка типів і новий стиль коментарів (//). Його перший комерційний випуск відбувся в жовтні 1985 р.. У 1985 р. вийшло перше видання «Мови програмування С + +», що забезпечує перший опис цієї мови, що було надзвичайно важливо через відсутність офіційного стандарту. У 1989 р. відбувся вихід С + + версії 2.0. Його нові можливості включали множинне спадкування, абстрактні класи, статичні функції-члени, функції-константи і захищені члени. У 1990 р. вийшло «Коментувати довідкове керівництво по C + +», покладене згодом в основу стандарту. Останні оновлення включали шаблони, виключення, простору імен, нові способи приведення типів і булевський тип. Стандартна бібліотека С + + також розвивалася разом з ним. Першим додаванням до стандартної бібліотеці С + + стали потоки введення / виводу, що забезпечують кошти для заміни традиційних функцій Сі printf і scanf. Пізніше самим значним розвитком стандартної бібліотеки стало включення до неї Стандартної бібліотеки шаблонів.

Після багатьох років роботи спільний комітет ANSI-ISO стандартизував С + + у 1998 р. (ISO / IEC 14882:1998). Протягом декількох років після офіційного виходу стандарту комітет обробляв повідомлення про помилки і в результаті випустив виправлену версію стандарту С + + у 2003 році.

C + + - компільований суворо типізований мова програмування загального призначення. Підтримує різні парадигми програмування: процедурну, узагальнену, функціональну; найбільшу увагу приділено підтримці об'єктно-орієнтованого програмування. У 1990-х роках мова стала одним з найбільш широко вживаних мов програмування загального призначення. При створенні С + + прагнули зберегти сумісність з мовою С. Більшість програм на С справно працюватимуть і з компілятором С + +. С + + має синтаксис, заснований на синтаксисі С [4]. Нововведеннями С + + в порівнянні з Сі є:

- Підтримка об'єктно-орієнтованого програмування через класи;

- Підтримка узагальненого програмування через шаблони;

- Доповнення до стандартної бібліотеці;

- Додаткові типи даних;

- Виключення;

- Простору імен;

- Вбудовані функції;

- Перевантаження операторів;

- Перевантаження імен функцій;

- Посилання і оператори управління вільно розподіленою пам'яттю.

3.2. Мова високого рівня С #

C # - мова програмування, що поєднує об'єктно-орієнтовані та аспектно-орієнтовані концепції. Розроблений в 1998-2001 роках групою інженерів під керівництвом Андерсa Хейлсбергa в компанії Microsoft як основна мова розробки додатків для платформи Microsoft. NET. Компілятор з C # входить в стандартну установку самої. NET, тому програми на ньому можна створювати і компілювати навіть без інструментальних засобів на кшталт Visual Studio.

C # відноситься до сім'ї мов з C-подібним синтаксисом, з них його синтаксис найбільш близький до С + + і Java. Мова має строгу статичну типізацію, підтримує поліморфізм, перевантаження операторів, вказівники на функції-члени класів, атрибути, події, властивості, винятки, коментарі у форматі XML. Перейнявши багато що від своїх попередників - мов С + +, Delphi, Модула і Smalltalk - С #, спираючись на практику їх використання, виключає деякі моделі, що зарекомендували себе як проблематичні при розробці програмних систем: так, C # не підтримує множинне наслідування класів (на відміну від C + +) або виведення типів (реалізовано в. NET Framework 3.0). C # розроблявся як мова програмування прикладного рівня для CLR і, як такий, залежить, перш за все, від можливостей самої CLR. Це стосується, перш за все, системи типів C #, яка відображає FCL. Присутність або відсутність тих або інших виразних особливостей мови диктується тим, чи може конкретна мовна особливість бути трансльована у відповідні конструкції CLR.

Так, з розвитком CLR від версії 1.1 до 2.0 значно збагатився і сам C #; подібної взаємодії слід чекати і надалі. (Проте ця закономірність буде порушена з виходом C # 3.0, що є розширеннями мови, що не спираються на розширення платформи. NET.) CLR надає C #, як і всім іншим. NET-орієнтованим мовам, багато можливостей, яких позбавлені «класичні» мови програмування. Наприклад, збірка сміття не реалізована в самому C #, а проводиться CLR для програм, написаних на C # точно так само, як це робиться для програм на VB.NET, J # та ін [4].

4 ПОБУДОВИ КРИВОЛІНІЙНИХ ПОВЕРХОНЬ

Існують два методи побудови криволінійних поверхонь: перший це - сплайн Безьє, другий - канонічні сплайни. Розглянемо більш детально способи побудови кожного з них.

4.1 Сплайн Безьє

Криві е Безьє були розроблені в 60-х роках XX століття незалежно один від одного П'єром Без'є (B ézier) з автомобілебудівної компанії «Рено» та Полем де Кастельє (de Casteljau) з компанії «Сітроен», де застосовувалися для проектування кузовів автомобілів . Вперше криві були представлені широкій публіці в 1962 році французьким інженером П'єром Без'є, який, розробивши їх незалежно від де Кастельє, використовував їх для комп'ютерного проектування автомобільних кузовів. Криві були названі ім'ям Безьє, а ім'ям де Кастельє названий розроблений ним рекурсивний спосіб визначення кривих (алгоритм де Кастельє). Згодом це відкриття стало одним з найважливіших інструментів систем автоматизованого проектування і програм комп'ютерної графіки [1].

Крива Безьє - параметрична крива, що задається виразом

де - Функція компонент векторів опорних вершин, а - Базисні функції кривої Безьє, звані також поліномами Бернштейна.

де n - ступінь полінома, i - порядковий номер опорної вершини.

Сплайни Безьє бувають:

1) лінійні криві - при n = 1 крива є відрізком прямої лінії, опорні точки P0 і P1 визначають його початок і кінець. Крива задається рівнянням:

2) квадратні криві Безьє (n = 2) задається третьою опорними точками: P0, P1 і P2.

3) кубічні криві Безьє (n = 3) описується наступним рівнянням:

Чотири опорні точки P0, P1, P2 і P3, задані в 2-х або 3-мірному просторі визначають форму кривої [2].

Малюнок 4.1 - Кубічна крива Безьє (n = 3)

Лінія, бере початок з точки P0 прямуючи до P1 і закінчується в точці P3 підходячи до неї з боку P2. Тобто крива не проходить через точки P1 і P2, вони використовуються для позначення її напрямки. Довжина відрізка між P0 і P1 визначає, як скоро крива поверне до P3.

У матричній формі кубічна крива Без'є записується таким чином:

де називається базисної матрицею Без'є:

Побудова кривих.

1) Лінійні криві. Параметр t у функції, яка описує лінійний випадок кривої Безьє, визначає, де саме на відстані від P0 до P1 знаходиться B (t). Наприклад, при t = 0,25 значення функції B (t) відповідає чверті відстані між точками P0 і P1. Параметр t змінюється від 0 до 1, а B (t) описує відрізок прямої між точками P0 і P1.

Малюнок 4.2 - Лінійні криві

2) Квадратні криві. Для побудови квадратних кривих Безьє потрібно виділення двох проміжних точок Q0 і Q1 з умови, щоб параметр t змінювався від 0 до 1:

Точка Q0 змінюється від P0 до P1 і описує лінійну криву Безьє.

Точка Q1 змінюється від P1 до P2 і також описує лінійну криву Безьє.

Точка B0 змінюється від Q0 до Q1 і описує квадратну криву Безьє.

Малюнок 4.3 - Квадратні криві

3) Криві вищих ступенів. Для побудови кривих вищих порядків відповідно потрібно і більше проміжних точок. Для кубічної кривої це проміжні точки Q0, Q1 і Q2, що описують лінійні криві, а також точки R0 і R1, які описують квадратні криві:

Малюнок 4.4 - Криві вищих ступенів

Для кривих четвертого ступеня це будуть точки Q0, Q1, Q2 і Q3, що описують лінійні криві, R0, R1 і R2, які описують квадратні криві, а також точки S0 і S1, описують кубічні криві Безьє:

Малюнок 4.5 - Криві четвертого ступеня

Завдяки простоті завдання та можливості зручно маніпулювати формою, криві Безьє знайшли широке застосування в комп'ютерній графіці для моделювання гладких ліній. Оскільки крива повністю визначається своєї опуклою оболонкою з опорних точок, останні можуть бути відображені і використовуватися для наочного управління формою лінії. Крім того, аффінниє перетворення кривої (перенесення, масштабування, обертання) також легко можуть бути здійснені шляхом застосування трансформацій до опорних точок. Наявність опуклої оболонки значно полегшує завдання про точки перетину кривих Безьє: якщо не перетинаються опуклі оболонки, то не перетинаються і самі криві.

Найбільше значення мають кубічні криві Безьє [1]. Криві вищих ступенів при обробці вимагають більшого об'єму обчислень і для практичних цілей використовуються рідше. Для побудови складних за формою ліній окремі криві Безьє можуть бути послідовно з'єднані один з одним у сплайн Безьє. Для того щоб забезпечити гладкість лінії в місці з'єднання двох кривих, суміжні опорні точки обох кривих повинні лежати на одній лінії [4]. Існує три програмного методу побудови:

  1. public void DrawBezier (Pen, Point, Point, Point, Point);

  2. public void DrawBezier (Pen, PointF, PointF, PointF, PointF);

  3. public void DrawBezier (Pen, float, float, float, float, float, float, float, float);

Малюнок 4.6 - Програмна реалізація

4.2 Кубічні сплайни

На відміну від тільки що описаних кривих ліній Безьє, лінії кубічного сплайна (cardinal spline) проходить через всі задані точки [3]. Побудова здійснюється по кроках наведеним нижче: запишемо для зручності Si (x) у вигляді:

тоді

.

Для виконання умови безперервності

Звідси отримуємо формули для обчислення коефіцієнтів сплайну:

Малюнок 4.1 - Приклад кубічного сплайна

Якщо врахувати, що c0 = cn = 0, то обчислення с можна провести за допомогою методу прогонки для трехдіагональной матриці. Існує два програмного методу побудови кубічних сплайнів: метод DrawCurve і DrawClosedCurve [3]. Перший з цих методів малює незамкнену криву лінію (відкритий сплайн), а другий - замкнуту (закритий сплайн).

  1. public void DrawCurve (Pen, Point []);

  2. public void DrawCurve (Pen, PointF []);

Малюнок 4.2 - Приклад закритого сплайна

ВИСНОВКИ

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

1) Що стосується вибору бібліотеки візуалізації, то можна зупинитися на GDI +, оскільки дві інші призначені для виконання куди біліше складних завдань, наприклад, написання комп'ютерних ігор, або будь-яких інших складних графічних комплексів. Ще одним аргументом GDI +, є, проста у використанні, та реалізації;

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

3) C # вирішує проблему побудови криволінійних поверхонь, використовуючи два види сплайнів: Безьє і кубічні;

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

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

  1. Лебедєв С. А., Мельников В. А. Загальний опис методів розкрою. М., 1999;

  2. Глушкова В.М. Крій та Шиття. М., 1995;

  3. Юр'єв А.А. Системи візуального моделювання. Д., 2005

  4. Шрус О.В. Калмига В.Г. Основи мов програмування. М., 2002

  5. Краінберг А. Керований DirectX, 856с., Тому 2.

  6. SiliconGraphics Help 3.1 - "OpenGL". 1250c.

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Наукова робота
97.8кб. | скачати


Схожі роботи:
Розробка підсистеми морфологічного аналізу інформаційної системи
Розробка підсистеми управління оптимального плану випуску виробів
Розробка організаційного проекту функціональної підсистеми управління бухгалтерським обліком
Розробка серії моделей жіночої блузи
Розробка динамічних моделей для транспортно виробничої системи
Розробка нових моделей шкільної форми з показом мод
Дизайнерська розробка експозиційних макетів моделей жіночого одягу
Розробка моделей гурткових занять забезпечують розвиток самостійності учнів
Розробка комплексу функціональних моделей управління якістю в системах прийняття управлінських рішень
© Усі права захищені
написати до нас