Celkem slozity protokol pro B-rep reprezentaci sceny (databaze sceny).
Scena je slozena z rovinnych plosek, zakladnimi prvky (tzv. entitami) jsou:
vrcholy, hrany, steny a telesa.
Pro moznost reprezentace nekterych slozitejsich struktur (napr. pro
hierarchicke triangulace) byla jako dalsi entita pridano tzv. rozdeleni
(Division).
Protokol nedefinuje dimenzi prostoru, ve kterem se scena nachazi. Takze jej lze bez problemu pouzivat v 2D, 3D nebo i vicedimenzionalnich prostorech.
Vertex (vrchol) - v geometrickem nebo i grafovem slova smyslu. Zakladni atribut: poloha v prostoru.
Edge (hrana) - (usporadana) dvojice vrcholu. Geometricky se muze prestavit jako orientovana usecka mezi dvema vrcholy.
Face (stena) - N-uhelnik (polygon) skladajici se z jedne uzavrene posloupnosti na sebe navazujicich hran. Derave steny je zatim treba vyrabet s pomoci tzv. fiktivnich hran. Pozdeji mozna pridam do databaze dalsi entitu: Loop.
Solid (teleso) - mnozina sten, ktere jsou na sebe fyzicky napojene (v prirode by tvorily povrch pevneho telesa). Obecnejsi pojeti neni tak prisne - mohla by to byt libovolna relevantni mnozina sten.
Division (rozdeleni) - jeden uzel v DAG grafu multi-triangulace. Udaje o predkovi (mnozina sten pokryvajici jistou oblast = domenu) a naslednikovi (jina mnozina sten pokryvajici shodnou domenu). Naslednik je typicky hrubsi reprezentaci stejne domeny, predek a naslednik nebyvaji v relaci "je zjemnenim".
Jednotlive entity lze chapat jako oddelene databazove tabulky (viz relacni databaze). kazdy prvek databaze (konkretni vrchol, hrana, stena, ..) ma svoje identifikacni cislo (id), ktere se exkluzivne pouziva pri odkazovani na dany objekt.
Kazda entita ma v databazi sceny prirazeny jiste atributy. Nektere atributy jsou zakladni (povinne, bez nich by to nemelo smysl: napr. dvojice vrcholu u hrany), libovolnou mnozinu atributu lze konfigurovat dodatecne.
Typ atributu: boolean, integer, long, double, coord_2D, coordh_2D, apod. (kompletni seznam viz konstanty Brep.ATTR_*).
Atribut se oznacuje identifikatorem (kratky mnemotechnicky retezec), pro rychlejsi masovy pristup je vhodnejsi tzv. handle - cele cislo jednoznacne identifikujici dany atribut v ramci jedne Brep databaze.
Typicka sada atributu pro reprezentaci obycejne 3D sceny:
Entity | Attribute name | Type | Memo |
---|---|---|---|
VERTEX | Coord | ATTR_COORDH_3D | [x,y,z,w]: world coordinates |
EDGE | Data | int[2] | [V1,V2]: vertex handles |
EDGE | Real | ATTR_BOOLEAN | Is this edge real or virtual? |
FACE | Data | int[] | [E1,E2, ... En]: edge handles |
FACE | Color | ATTR_RGB | Base color for flat shading |
SOLID | Data | int[] | [F1,F2, ... Fk]: face handles |
Aby bylo mozne definovat ruzne sady "stejnych" atributu v jedne databazi, jsou zavedeny tzv. kontexty. Priklad: 3D scenu chceme zobrazovat v nekolika oknech na obrazovce, kazde okno ma svoji sadu souradnic a tedy potrebuje i vlastni atribut "Coord-int".
Algoritmy, ktere s databazi pracuji, vzdy dostavaji jako vstupni parametr i kontext, ze ktereho maji data brat. V kazdem z kompatibilnich kontextu se musi pouzivat stejne retezcove identifikatory atributu!
Kazdy atribut je oznacen, zda se ma sdilet mezi vsemi kontexty, nebo zda ma byt pro kazdy kontext vytvorena jeho unikatni kopie.
Priklad: 3D scena ma svetove souradnice (Coord typu ATTR_COORDH_3D, sdileny), pro 2 zobrazovaci soustavy jsou potreba 2 kontexty s odlisnymi atributy Coord-int. Pro jednoduchost jsou uvedeny pouze atributy vrcholu:
Pro snadnejsi prochazeni dat v Brep databazi je k dispozici sada iteratoru. Iteratory mohou napr. prochazet sekvencne vsechny vrcholy dane sceny (vertexIterator()), vsechny vrcholy v dane stene (vertexInFaceIterator()), apod.
Protokol FaceRender implementuje pomocnou nizsi vrstvu pro vykreslovani viditelnych casti teles (resp. jejich sten). Pro ruzne pristupy vypoctu viditelnosti jsou definovany dva typy globalniho vyplnovani (podle dane bit-masky fillInside() a mimo danou bit-masku fillOutside()) + jednodussi elementarni vyplneni dane vodorovne radky fillHLine().
"Pattern" pro klasicky plosny algoritmus na viditelnost:
Copyright (c) 2002-2006 Josef Pelikán, last change: $Date: 2013-11-22 23:47:16 +0100 (Fri, 22 Nov 2013) $