OpenGL alapozó sorozatunk mérföldkőhöz érkezett. Ugyanis minden tudásunk meg van ahhoz, hogy egy összetett 3Ds modellt jelenítsünk meg virtuális világunkban. Ha visszagondolunk, akkor eddig csupán csak kockákat, gömböket és egyéb egyszerű objektumokat ábrázoltunk. Valljuk be őszintén, nem volt túlságosan izgalmas vagy látványos a végeredmény. De most ezzel szakítunk és kész 3D modelleket fogunk betölteni és megjeleníteni.
[ProHardver] Régóta ismert probléma, hogy az eddig kiválóan működő multisampling élsimítás már nem felel meg a kor követelményeinek. Bár kétségtelen, hogy kifejezetten jó a képminőséghez mért erőforrásigénye, a manapság alkalmazott renderelő motorok olyan eljárásokkal dolgoznak, ahova már a fejlesztői kontroll szükséges a technika megfelelő alkalmazásához, ezt azonban sokan inkább kihagyják, aminek többnyire az az eredménye, hogy a játék nem tartalmaz majd élsimító algoritmust. Ilyenkor az AMD és az NVIDIA a driverben keres valamilyen utat az MSAA aktiválására, ez azonban messze nem egyszerű feladat, mivel a renderkódot nem tudják befolyásolni, így a kényszerítés sokszor csak részlegesen, vagy rosszabb esetében egyáltalán nem ad értékelhető eredményt.
Az AMD a fenti problémák miatt dolgozta ki az MLAA-t, vagyis a morfologikus élsimítást. A közhiedelemmel ellentétben az algoritmus alapjait nem az AMD fektette le, ők csak továbbgondolták azokat, és előálltak egy DirectCompute felületre alapozó megvalósítással. Az MLAA előnye régóta ismert. A technika minden felülettel kompatibilis, vagyis nem csak a poligonok éleit szűri, hanem képes a textúrák, az átlátszó felületek, illetve a shaderek recés torzulásait is javítani. Mivel a teljes megvalósítás post-process effekt formájában működik, a végleges képkockán fut le, ami azt eredményezi, hogy minden renderelőn ugyanúgy fog működni. Kétségtelen, hogy az MLAA nem az élsimító technológiák Szent Grálja, de az MSAA egyre több hibát generál, a mai deferred render motorokkal, és ennek kivédésére csak a supersampling megvalósítás jelentett megoldást, de az olyan túlzott erőforrásigényt követel, hogy lényegi haszna csak a csúcskategóriás termékeken van.
Dead Space AA nélkül és MLAA-val
A morfologikus szűrés gyakorlatilag csak a számítási teljesítményre érzékeny, de az algoritmus elképesztően jól párhuzamosítható, vagyis az 1-2 TFLOPS-os kapacitással rendelkező GPU-k már megbirkóznak vele. A technológia lényegében olyan szomszédos pixeleket keres, ahol nagy az eltérés a színinformációkban. A kiválasztott képpontokat csoportosítja, majd egy előre definiált alakzatot rendel hozzájuk. A lényegi munka itt kezdődik meg. A környező pixelek adatai alapján az algoritmus korrigálja a vizsgált alakzathoz tartozó pixelek színét, annak megfelelően, hogy a szomszédos képpontok mennyire eltérőek. Az algoritmus nagymértékben skálázható, hiszen a számításba vett pixelek száma tetszőlegesen állítható be, ugyanakkor problémák is előfordulnak. A vízszintes és függőleges állapothoz közeli vonalakra egyetlen minta sem alkalmazható tökéletesen, ami azt eredményezi, hogy ezek az élek nem lesznek kifogástalanul szűrve. Itt jön az a pont, ahol mindenképpen szükséges az MSAA vagy az SSAA alkalmazása. Szerencsére az MLAA post-process szűrő, így tökéletesen kompatibilis minden más képminőség-javító technológiával.
MLAA működése
Az NVIDIA egyelőre az MSAA és az SSAA alkalmazhatóságáért küzd, de nem kérdéses, hogy szükséges egy újszerű megvalósítás bevezetése. Az MLAA, ahogy fentebb kiderült egy értékelhető opció, de nem biztos, hogy a GeForce-ra történő implementálás hatékony lenne. Mivel az algoritmus csak a nyers számítási teljesítményre érzékeny a Radeonok komoly előnyben vannak itt, hiszen a legerősebb fermis GPU 1,58 TFLOPS-os teljesítményre képes, szemben a Cayman 2,7 TFLOPS-os tempójával. Ebből rögtön lehet látni, hogy ugyanaz a kód – a jól párhuzamosítható jellegből adódóan – a hasonló árú GeForce termékeken nem lenne túl gyors, vagyis az MLAA alkalmazása nem célszerű, és lényegében ezért nem lett eddig bevezetve. Van azonban más megoldás is, mint például a Subpixel Reconstruction Anti-Aliasing.
Practical Morphological Anti-Aliasing (UZ MLAA)
A subpixel alapú élsimítás alapjai szintén nem mondhatók újnak, mivel az Apple is ezt alkalmazza a termékein. Természetesen az NVIDIA csak az alapokat használta fel, így az eredmény eltérő is lehet, sőt annak kell lennie, hiszen a cél a 3D-s játékokon való alkalmazás. A monitoron megjelenő pixelre úgy gondolunk, hogy az a legkisebb megjeleníthető elem. Alapvetően ez igaz is, meg nem is. A szemünk valóban a pixelt látja a legkisebbnek, de valójában egy képpont három úgynevezett subpixelből áll (RGB). Ezek a vörös (Red), a zöld (Green) és a kék (Blue) árnyalatok, és lényegében a végső pixel színe is innen származik. Amennyiben az árnyalatok közül csak egyet is megváltoztatunk, úgy a képpont végső színe is módosul. Az SRAA gyakorlatilag itt próbál eredményt elérni.
Az NVIDIA algoritmusa az előzetes adatok szerint kifejezetten a deferred render motorokhoz alkalmazkodik, és alapvetően mélységpufferre építkezik. Pontos leírás még nem látott napvilágot, de a mintavételezést itt lehet végrehajtani, majd a kinyert adatokat felhasználva egy nagyfelbontású mélységpuffert kell létrehozni. A minőség itt skálázható lesz, mivel pixelenként több mintát is ki lehet nyerni. Természetesen a több adat nagyobb teljesítményveszteséggel jár, de az eredmény is jobb lesz. A deferred rendering fázisainál az összemosás a szokott módon megy végbe, de a képminőség összességében jobb lesz, mivel a mélységpuffer a szükségesnél több információt tartalmaz, vagyis ezeket fel lehet használni a subpixelek színinformációinak korrigálására, azaz az élsimításra. Ezt szintén el lehet játszani a normal buffer esetében, ami még tovább javítja az eredményt. Utóbbi esetben valószínűleg az alkalmazásprofilokkal testre is lehet szabni a megvalósítást. Az eljárás a teljesítményigény tekintetében teljesen kötött, mivel pixelenként ugyanaz a számítás fut le. Az előzetes adatok szerint 720p-s felbontásban a készülő algoritmus 1,8 ms-os időigénnyel rendelkezett, ami jónak mondható, bár a minőségről nem nyilatkoztak a fejlesztők. Lényegében az eredmény a minták számával befolyásolható, vagyis az SRAA az igények szerint skálázható.
A Subpixel Reconstruction Anti-Aliasing algoritmusról február végén beszél bővebben az NVIDIA. Természetesen az elméleti alapok lefektetése mellett gyakorlati implementációra is szükség van, vagyis meg kell várni, míg elkészül a driveres implementálás, mely bármely GPGPU platformon alkalmazható. Hogy ez mikorra lehetséges, arról nincs információ.
A pixelek geometriája eltérő paneleken
Érdemes megjegyezni, hogy a subpixel alapú megvalósítások általános hátrányokkal is küzdenek. Elsősorban fontos tényező a monitor képpontjainak geometriája. Ebből a szempontból nagyon sok eltérő megvalósítás létezik. Valószínűleg az LCD panelek élveznek prioritást, ám ezen belül is léteznek RGB és BGR kialakítású panelek, ahol az egyes pixelekhez tartozó subpixelek ugyan megegyeznek, de a lineáris sorrendjük más. Gyakorlatilag számítani kell arra, hogy az eredmény monitoronként változó lesz, mivel a subpixelek geometriai elhelyezkedését és sorrendjét a driver képtelen ellenőrizni, vagyis az adott algoritmus, csak egy bizonyos előre kiválasztott paneltípuson lesz tökéletes. Érdemes lesz tehát több paneltípusra is elkészíteni az SRAA-t, majd egy adatbázis alapján alkalmazni a legjobb eredményt nyújtó megoldást.
[Origo] Kedden este kiadta a Microsoft másfél éve kapható legújabb operációs rendszeréhez az első szervizcsomagot, vagyis a Service Pack 1-et. Az utóbbi tíz év során ez az első olyan javításgyűjtemény, amelyben tulajdonképpen semmilyen komoly problémát nem kellett orvosolni a Windowsban, és a felhasználók sem igazán hiányoltak belőle semmilyen funkciót.
Az első szervizcsomagban csupán az eddig kiadott kisebb javításokat gyűjtötték össze, hogy a rendszert újonnan használatba vevőknek az első indításkor ne kelljen annyi patchet letölteniük számítógépükre. Ez korántsem volt mindig így: az előző két Windows, a Vista és az XP esetében a javítócsomagokat egyfajta digitális messiásként várták a felhasználók, mivel az alapverziók annyi problémával küzdöttek, hogy egy teljes nagygenerálra volt szükség a normális működéshez.
A Vista szervizcsomagja garanciális javításként működött
A 2007 elején megjelent Windows Vista a Microsoft története legnagyobb baklövésének számít: megjelenésekor sokan szenvedtek használatával, mivel például a gyártók egyáltalán nem, vagy csak fél-egy éves késéssel adták ki termékeik új, vistás illesztőprogramjait. Ezek hiányában hiába csatlakoztattak nyomtatót, vagy multimédiás ketyeréket a PC-hez, azt nem lehetett működésre bírni.
Emellett a Vistára váltók azt tapasztalhatták, hogy rendszerük nem működik elég gyorsan, a stabilitása is hagyott maga után kívánnivalót. A komoly problémák orvoslását a Microsoft nem kapkodta el, nem kevesebb, mint egy évet kellett várnia a felhasználóknak a rendszer nagyjavítására, és az eszközök használatához szükséges illesztőprogramok is nagyjából ekkorra készültek el elegendő számban.
Mire kijavították a Vistát, már jött a Windows 7
A vistás Service Pack telepítése szteroidként hatott az operációs rendszerre, gyorsabbá vált például a fájlok másolása, a ki- és belépés vagy a hibernálás, és sokkal stabilabb lett a teljes rendszer. Azt, hogy a Windows Vista nem váltotta be a hozzá fűzött reményeket, a Microsoft is beismerte, Bill Gates a Gizmodo kütyüblognak adott interjújában elég hangsúlyosan utalt arra, hogy nem tartja túl jó szoftvernek a Vistát, az elnök-vezérigazgatói székben őt váltó Steve Ballmer pedig "befejezetlen munka"-ként hivatkozott a szoftverre.
Másfél évvel a Vista javítócsomagjának premierje után meg is érkezett a Windows 7, amely már a felhasználók és a szaksajtó részéről is kedvező fogadtatásban részesült. Aki kicsit türelmesebb volt, korábban vásárolt XP-jével akár át is vészelhette a Vistával beköszöntött vészkorszakot.
Férgek ellen kellett pajzs az XP-nek
A Windows Vista balul sikerült bevezetése miatt az eredeti terveknél jóvál tovább biztosít támogatást a Microsoft a nagyjából tíz évvel elelőtt megjelent Windows XP-hez. Mivel világszerte még rengetegen használják a szoftvert, 2014-ig jelennek meg hozzá biztonsági javítások, ami a különböző kártevők, online támadások megakadályozása miatt kulcsfontosságú. A Windows XP esetében az első, 2003-ban kiadott javítócsomag tette használhatóvá például az akkor még újdonságnak számító USB 2.0-s eszközöket, amelyek a korábbinál gyorsabb másolási sebességet biztosítottak. Csupán egy évet kellett várni az SP2-re, ami olyannyira átszabta a Windows XP-t, mintha remixelték volna a szoftvert: teljesen új tűzfal, biztonsági funkciók és a levelezést és böngészést érintő funkciók váltak elérhetővé a rendszerben. Ezt követően figyelmeztető üzenetek jelentek meg akkor is, ha a gépre nem volt víruskereső szoftver telepítve. Ez az azóta megjelent összes Windowsban így van, bár saját víruskereső alkalmazás kibocsátására csak négy évvel később szánta rá magát a Microsoft.
A biztonsági újításokra azért volt szükség, mert a kétezres évek közepén hihetetlen mennyiségben keringtek a neten az e-mailben és hálózati kapcsolatokon keresztül terjedő kártevők, amelyek nem csak a vállalatoknak, hanem az otthoni felhasználók mindennapi életét is megkeserítették.
Már jövőre megérkezhet a Windows 8
A Windows 7-ből már több mint 300 millió darab licencet értékesített a társaság, amelynek fejlesztői a pletykák szerint már tavaly óta dolgoznak a második javítócsomag elkészítésén. Bár ennek várható megjelenési idejéről nincs információ, a technológia gyors fejlődése miatt minden bizonnyal az új szoftver funkcióit is bővíteni kellhet utólag. Például már kaphatóak az elterjedt USB 2.0-nál gyorsabb USB 3.0-s eszközök, de a Windows 7 alapból még nem támogatja ezeket, az SP1 telepítése után sem - manuálisan kell illesztőprogramokat telepíteni használatukhoz.
Steve Ballmer a Windows 8-ról beszél a 2011-es CES-en
A szaksajtóban keringő pletykák szerint elképzelhető, hogy az USB 3.0 alapszintű támogatása csak a Windows 8-ban lesz elérhető. Erről a rendszerről még nem sokat tudni, Steve Ballmer januári bemutatója szerint már nem csak a hagyományosan személyi számítógépekbe szánt lapkákat tartalmazó eszközökön, hanem például mobil eszközökön, például táblagépeken és okostelefonokon is fut majd. Ez a szoftver az elemzők várakozásai szerint jövőre jelenik meg, ami jelentős késést jelent, hiszen a rivális Apple és Google már kínál táblagépekre optimalizált szoftvereket.
Mi is az az Alisaing? Eredendően egy mintavételezési hibáról beszélhetünk. Van a mi kis analóg világunk a maga majdnem végtelen (szemünk számára végtelen, mert nem látunk molekuláris szinten) részletességével, és ezt szeretnénk minél jobban megközelíteni a monitoron (valósághű). Mivel a számítógép digitális, van egy részecskeméret (pl. egy pixel a monitoron) ami alá nem tud menni, azok a részletek, amik a való világban kisebbek ennél a részecskeméretnél nem - vagy csak nagyon nehezen - jeleníthetőek meg. Ezt a problémát hívják aliasingnak. A gyakorlatban két megjelenési formája van:
1. töredezett élek (ezzel gondolom mindenki találkozott)
2. megjelenő majd eltűnő részletek
Felmerül a kérdés, hogy miért nem lehet ezt gondos tervezéssel (nem tervezek túl kis objektumokat) elkerülni. Sajnos nem lehet, mert egy hatalmas objektum is összemehet apróra, ha távol kerül a kamerától.
Hogyan lehet védekezni ellene? - Anti Aliasing
Valamilyen módon finomítani kell a felbontást, persze ez további számolással és memória valamit memória sávszélesség zabálásával jár. Persze semmi sincs ingyen még a virtuális világban sem. Akkor hogyan? Túlmintavételezéssel! Növeljük kétszeresére a felbontást mindkét irányba, ezzel megnő a kép részletessége viszont drasztikusan nő a feldolgozás összetettsége is. Így egyetlen pixelt már 4 pixel fog reprezentálni a megnövelt képünkön. Ezen a duplázott képen számoljuk ki a rendereléseket, majd visszaméretezzük a képet úgy, hogy 2×2esével kiátlagoljuk (összeadjuk, majd elosztjuk négyel) a pixeleket. Ezt a kétszeres növelést (kétszeres túlmintavételezés) hívják Nyquistmintavételezési törvénynek.
A túlmintavételezést megcsinálhatjuk többféleképpen is. A legegyszerűbb a duplázás x és y irányba OGSS (Ordered Gird Super Sampling), de használható elforgatással kapott mintavételezés RGSS (Rotated Gird Super Sampling) amikor a 4 (vagy több) szubpixel az eredeti kép elfogatásával jön létre.
OGSS mechanizmusa
Szintén használható valamilyen fajta multi sampling, ahol nem a kép duplázásával nyerünk újabb mintavételi részleteket hanem valamilyen más transzformációval. A multisampling általában gyengébb képet ad mint a supersampling de jóval gyorsabb.
Akkor most lássuk a hatást gyakorlatban
Egy egyszerű mintavételezési példa. Rajzoljunk pár fekete sávot fehér háttérrel és ezeket nézzük meg 110, 133 és 200 százalékos nagyításban.
100% - 110% - 133% - 200%
Látható, hogy csak 200%-nál maradt töredezés mentes a sáv felülete, mert itt jött ki kétszer annyi (egész számszor) mintavevő hely.
A terepi felmérési munkák szükségességének elbírálása, az alkalmazandó eszközök és eljárások megválasztása az alapadatok és az általános bejárás során szerzett tapasztalatok birtokában mindig a tervező mérnök feladata és felelőssége. A kiválasztott mérőeszköz nemcsak a felvételezés pontosságát, hanem a méréstechnikát, az eredmények feldolgozását és a teljesítményt is egyszerre rögzíti. Ezért nem mindig a legpontosabb mérőeszköz (mérőállomás) a leghatékonyabb a feladat szempontjából.
Az erdővel borított területen problémát jelent még az irányértékek tájékozása, ezért nem meglepő, hogy a busszola teodolit alkalmazása erdőtömbön belüli (belső) felmérések esetében még mindig megengedett. A tájoló teodolitok ugyanis olyan szögmérő műszerek, amelyek az Am mágneses vagy az Af földrajzi azimut mérését teszik lehetővé, elkerülhetővé téve ezzel az irányértékek tájékozását, ill. azt, hogy tájékozó irányokra legyen szűkség. Ebből következik, hogy alkalmazásuk elsősorban fedett terepen (erdőben), esetleg földalatti méréseknél (bányák, metró) indokolt. A mágneses és a földrajzi északi irányok mindenhol a rendelkezésünkre állnak. A tájoló teodolitok között megkülönböztetjük az Am mágneses azimut közvetlen mérésére alkalmas busszola teodolitokat és az Af földrajzi azimut közvetlen mérésére szolgáló giro-, vagy pörgettyűs teodolitokat.
Wild T0 busszola-teodolit
Az erdőmérnöki gyakorlat hagyományos földi terepi mérőműszere a busszola teodolit, a giroteodolitok erdőmérnöki gyakorlatban való alkalmazására Magyarországon is voltak, de méretei és a hosszadalmas mérési eljárás miatt az erdészeti alkalmazásban nem tudott elterjedni. Az elterjedést nem indokolta a giroteodolitok busszola teodolitoknál jóval nagyobb pontossága sem, az erdőmérnöki gyakorlat ezt nem igényelte (Bácsatyai, 2002). A busszola teodolitok szerepét fokozatosan átvették a mérőállomások az erdőgazdálkodás gyakorlatában is. Ezekkel az eszközökkel ugyanis jóval pontosabban lehetséges a terepi felvételezés elvégzése és a hibák kiszűrése is jóval egyszerűbb, mint a busszola teodolitok esetében. Hátrányok, hogy jóval bonyolultabb és kényesebb mérőeszközök, mélyebb geodézia jártasságot igényelnek és szükséges az irányértékek tájékozása, energiaellátásuk még mindig nem teljesen megnyugtató. Mérőállomással csak szakszerű személyzet képes hatékony munkavégzésre.
A hagyományos "mérőcsomag"
A legújabb fejlesztések az elektrotechnikában már lehetővé tették olyan szenzorok megalkotását, amelyek a geodéziai mérések szempontjából is kielégítő pontossággal határozzák meg a mágneses azimut szögértéket. A lézeres távméréssel összekapcsolva pedig megszületett a "tájoló teodolitok" legújabb generációja.
Az erdőmérnök új mérőeszköze: TruPulse 360B
A TruPulse lézeres távolságmérőt a Laser Technology gyártja és fejleszti. A cég központja az Egyesült Államokban, Colorado állam Centennial városában található. A bemutatásra kerülő modell (TruPulse 360B) alapját a TruPulse 200 képezte, amely először 2006-ban került piacra. Ez a modell vízszintes és ferde távolságot, két pont közötti távolságot (hiányzó háromszögoldal), dőlésszöget, és három méréssel magasságot tudott mérni. Az eszköz jó alapot képezett a további fejlesztésekhez. A későbbi verzió már Bluetooth vezeték nélküli adatátvitelre is képes lett (TruPulse 200B). A Laser Technology nem sokkal ezután szabadalmaztatott egy digitális iránytű technológiát (TrueVector), amely parányi mérete mellet már megbízhatóan volt képes mérni a mágneses északhoz képesti irányszöget (Am). Így már nem volt akadálya annak, hogy megszülessen minden idők legkisebb „busszola-teodolitja”, a TruPulse 360B! A jelenleg elérhető modellek:
TruPulse 200
TruPulse 200B
TruPulse 360
TruPulse 360B
A TruPulse 360 egy olyan maroknyi mérőeszköz, amely gyorsan és közvetlenül szolgáltatja a szükséges távolságokat és szögadatokat a koordinátageometria számításokhoz. Mindezt úgy teszi, hogy nincs feltétlenül szüksége műszerállványra mivel akár szabadkézből is történhet a mérés.
A műszer ferdeségét a beépített szenzorok automatikusan kompenzálják. A mérőeszköz rendkívül kompakt és robusztus kialakítású. Kifejezetten terepi mérésre és térinformatikai adatgyűjtésre készült. A mérés az irányzás elvégzése után egyetlen gomb megnyomásával végrehajtható. Az eredmények jól látható kijelzőn közvetlenül leolvashatóak vagy PDA-ra küldhetőek.
A legfontosabb műszaki paraméterek
Közvetlenül mérhető adatok:
Távolság: vertikális (VD), horizontális (HD) és ferde távolság (SD)
Magassági szög (INC) fok és százalék dimenzióban
Magasság meghatározás (fa, épület, oszlop, stb.) három mérésből
Mágneses északkal bezárt szög (Azimut, AZ) fok dimenzióban
Hiányzó háromszögoldal meghatározása (ML) két mérésből
Legközelebbi, Legtávolabbi, Folyamatos és Szűrő mód: többféle mérési mód, amelyek lehetőséget nyújtanak egyes célpontok kiválasztására vagy kihagyására, és a lehető legpontosabb mérést biztosítják, bármilyenek is legyenek a terepviszonyok.
A TruPulse 360 mérési lehetőségei
Műszaki jellemzők:
Méretek: 12 cm × 5 cm × 9 cm
Súly: 220 gr
Mértékegységek: Láb, jard, méter, fok és lejtszázalék
Távolság mérés tartománya: 1000 m reflektáló felület nélkül és 2000 m reflektáló felület alkalmazása esetén
Magassági szög tartománya: ±90°
Azimut szög tartománya: 0° - 359,9°
Mérési pontosság:
Távolság mérés: 0 és 100 m között tipikusan ±10 cm, felette ±30 cm a hiba, jó minőségű cél esetén
Magassági szög: ±0,25°
Azimut szög: ±1,00°
Tápellátás:
A TruPulse mérőeszközök egyik legnagyobb előnye, hogy két ceruzaelem szükséges csupán a tápellátás biztosításához. Ez valódi mérési körülmények között 40000 mérést tesz lehetővé folyamatos bekapcsolás mellett bluetooth nélkül, bluetooth esetén 30000 méréssel számolhatunk.
MobileMapper 6 és Trupulse 360
Amellett, hogy önálló eszközként is sokra hivatott, kiegészítőként is jól alkalmazható GNSS mérésekhez. Csatlakoztatható soros porton (RS232) keresztül vagy bluetooth-szal a különféle kézi adatgyűjtő rendszerekhez, okos telefonokhoz, PDA-khoz, netbook-okhoz, stb. A TruPulse 360B mérőeszköz minden joggal követelhet helyet magának a kisebb pontosságigényű feladatok körében, mivel rendkívül gyors és hatékony mérést tesz lehetővé. Kezelése végtelenül egyszerű, amely kielégítő pontossággal társul a geodézia számítások szempontjából is. Jóval több, mint a hagyományos busszola-teodolit (lézeres távmérő) így minden olyan területen ahol a hagyományos mérőeszköz alkalmazhatónk minősült a TruPulse 360B is megállja a helyét.
A TruPulse mérőrendszer
Eddig csak magával a TruPulse eszközzel foglalkoztunk, pedig hatékony alkalmazásához szükséges még pár kiegészítő tartozék beszerzése is. Az egyik legfontosabb az adatgyűjtő eszköz, amely lehet PDA, okostelefon, NetBook vagy akar egy tablet is. A lényeg az, hogy tartalmazzon Bluetooth modult vagy támogassa az RS232 protokollt.
Komplett mérőrendszer
Ezután szükség lesz még egy állványra, amin elhelyezzük magát a műszert és az adatgyűjtőt, ez lehet egy- vagy háromláb kialakítású. Célszerű még alkalmazni egy GPS vevőt is, ha lehetséges. Így a mért poláris pontok egyből abszolút koordinátákat vehetnek fel, de ennek hiányában helyi rendszerben is dolgozhatunk, aminek a kezdőpontját mi magunk határozzuk meg.
Reflektáló felület és TruPulse tartókonzol (kiegészítők)
Ahhoz, hogy a gyakorlatban sikeresen alkalmazhassuk a TruPulse 360B mérőeszközt, fontos, hogy az eszköz megfelelően kalibrálva legyen. Ez azt jelenti, hogy a mérési helyen észak felé fordulva kalibráljuk a kompasz modult, lásd a lenti videón:
Sikeres kalibráció után az eszköz máris kész a mérésre. De ne legyünk ilyen gyorsak, ugyanis itt van még a deklináció kérdése is. Hogy mi is az a deklináció? A mágneses elhajlás vagy más néven mágneses deklináció a mágneses és a földrajzi Északi-sark közötti szögbeli eltérés fokokban kifejezve.
A deklináció értelmezése
A TruPulse belső iránytűje figyelembe tudja venni a helyi mágneses elhajlást, ha megadjuk az értékét. A beállított szögértékkel korrigálja a mért azimut szöget. A várható deklináció mértékét deklinációs térképekről vehetjük le, mint amilyen ezek is itt:
Az igazság az, hogy célszerű, ha a deklinációt nullának állítjuk a TruPulse eszközön belül és csak a mérés befejeztével a mérési adatok benti feldolgozása során számolunk vele. Ennek több oka is van. Először is célszer a deklinációt pontosan meghatározni és nem modellből levenni az értékét, másrészt a TruPulse eszköznél is értelmezhető a busszola-teodolitok 0 osztáshibája.
TruPulse 360, reflektáló felület mint cél (ismert magasságon)
Ez régen azt jelentette, hogy a mágneslemezre erősített vízszintes kör 0 osztása nem a mágneses északi irányba, hanem egy attól csekély mértékben eltérő irányba áll be. A deklináció és a 0 osztáshiba együttesen terheli a TruPulse mérési eredményeit, ezért tájékozási állandónak is nevezhetjük.
A mérés végrehajtása
A terepen a mérés mindig egy ismert pontról indul. Az álláspont koordinátáját meghatározhatjuk GPS vevővel, vagy helyi rendszerben dolgozunk.
A TruPulse 360B lézertávmérővel az álláspontról mérünk a pont objektumokra (részletpontok). Mivel az álláspont koordinátáit meghatároztuk a GPS vevő segítségével a pont objektumok létrehozhatók a távmérő által szolgáltatott vízszintes távolság (HD) és az Azimut (AZ) ismeretében. A poláris mérés két paramétere (HD, AZ) Bluetooth kapcsolaton keresztül jut el az adatgyűjtőre, amelyen a feldolgozó szoftver fut. A felmért részletpontok később álláspontként szolgálhatnak, így haladva előre az egyik pontról a másikra, egészen addig amíg minden szükséges pontot be nem mértünk. Ha minden állásponton visszamérünk az előző álláspontra is, akkor a mért Am (azimut) szögértékek ellenőrzésére lehetőségünk nyílik.
A bemutatott mérési módszer támogatására készítettem egy célszoftver aminek a Pocket Surveyor v1.0 nevet adtam. A program automatikusan fogadja a TruPulse eszköz által küldött NMEA szerű mondatokat és megjeleníti a mérési eredményeket. A program képernyőképe itt látható:
Pocket Surveyor v1.0
A program elkészítésére azért volt szükség, mivel abban az időben amikor először kerültem kézközelbe a TruPulse 360B-vel még a piacon nem volt elérhető olyan program amely mint busszola-teodolitként gondolt volna rá és nem csupán egy okos lézeres távmérőként. Ezért a hatékony és gyors részletpontmérést egyik piaci szoftver sem támogatta akkor még.
TruPulse-os részletmérés
Erdei út mérése TruPulse 360-nal
Nagy előnye ennek a hagyományos mérőállomással való méréssel szemben, hogy a sűrű növényzet ellenére csak kevés helyen van szükség irtásra, mivel minimális „zöld falon” kell a jelnek áthatolnia. Ezért erdőben ideális a használata.
Tovább is van, mondjam még?!
Ha valakinek nem lenne elegendő az a pontosság amit a TruPulse 360 belső kompasza tud, nos annak sem kell lemondania erről a maroknyi csodáról. Ugyanis itt van a MapStar Compass Module II.
A kompasz modul vízhatlan alumínium házban foglal helyet. Működési ideje 15 óra, amit 2 db ceruzaelem (AA) mellet képes hozni. A modul az azimut szög számításánál automatikusan kompenzálja a külső hőmérsékletből és a műszer ferdeségéből eredő hibákat. A legfontosabb adatok a modulról:
Méretek: 31 x 5 x 3 cm
Tömeg: 570 g
Pontosság: +/- 0,3 fok
Ismételhetőség: +/- 0,1 fok
Felbontás: 0,1 fok
Kommunikáció: RS232
Adatformátum: NMEA 0183
Ár: $ 1,500.00
Láthatjuk, hogy TruPulse 360 kompaszához képest ez a modul jóval pontosabb és megbízhatóbb szögmérést tesz lehetővé, igaz ennek meg is kell fizetni az árát. Minden esetre kompakt mérete és alacsony energiaigénye kiváló terepi eszközzé teszi és jól párosítható a TruPulse 200 távmérővel (nincs belső kompasz).
Mindenképpen érdemes még megemlíteni az Criterion RD 1000 Relaszkópot ami tulajdonképpen a Bitterlich-féle tükrös relaszkóp modernizált változata. Segítségével meghatározható a faegyedek átmérője, a mért átmérő magassága, valamint támogatja a mintakörös felvételezést is. További információk itt.
Felhasználási területek
Nyiladékok és határok felmérése.
Belső úthálózat, közelítőnyomok felmérése.
Patakok, magaslesek, szórók, tűzrakhelyek, táborhelyek, stb. felmérése.
Famagasság meghatározás, törzstérképezés.
Műtárgyak, vezetékoszlopok, egyéb objektumok bemérése.
Elérhetetlen vonal ill. távolság meghatározás pl. két fa közötti
Terep felvételezése, terepmodell pontosításhoz vagy tervezéshez.
Semlegesvonal nyomozás.
Forgalmazók
A TruPulse lézer távmérő viszonylag könnyen beszerezhető hazánkban is. Az első hivatalos viszonteladó a Navicom-Plusz Bt. volt, ma már viszont a DigiTerra Kft. forgalmazza az eszközt. A külföldiek közül a csehországi Field-Map mindenképpen megér egy misét.
Ha valaki alapvető programozási ismeretekkel (pl. C vagy Delphi) rendelkezik és szeretné kihasználni a legújabb Microsoft Silverlight 4 technológiát, akkor most egyebet sem kell tennie, mint letöltenie a devPortal.hu gondozásában született "Silverlight 4.0 - A technológia és ami mögötte van" című magyar nyelvű informatikai szakkönyvet.
Megint a Factory-ból kell kiindulni ám ezúttal prototípusokat lehet gyártani. A cél, hogy előre inicializált típusokat lehessen menet közben készíteni úgy, hogy annak részletkérdéseivel már ne kelljen foglalkozni. A típusokat klónozással kell előállítani, szükség esetén mély másolással. (Amikor a referencia tagokat újra kell kreálni, hogy két objektum ne használja őket közösen). Sokszor előfordul az, hogy bizonyos osztályt prototípusként használunk fel. Ilyenkor általában az "új" típust származtatjuk a régiből és semmit sem változtatunk rajta, csak a konstruktorban inicializáljuk:
class MyObject { int size;
public MyObject(int size) { this.size = size; } }
class MyOtherObject : MyObject { public MyOtherObject() : base(22) { } }
Ezzel tulajdonképpen semmit sem csináltunk, nem fejlesztettük tovább az objektumot, csak létrehoztunk egy prototípus osztályt. Ez főleg akkor válik nehézkessé, amikor ebből kellene 30-40 féle. Többek között az ilyen esetekre jó a Prototípus használata.
Alkalmazhatóság
Akkor használjuk a Prototype mintát, ha rendszernek függetlennek kell lennie a termék létrehozási, összeállítási és megjelenítési módjától; és
ha a példányosítandó osztályok futásidőben határozódnak meg, például dinamikus betöltés esetén, vagy
el szeretnénk kerülni a termékek osztályhierarchiájával párhuzamos osztályhierarchiájú gyárak építését, vagy
amikor az osztályok példányainak csak néhány különböző állapotkombinációja lehet. Kényelmesebb a megfelelő számú prototípust elhelyezni és klónozni, mint példányosítani a megfelelő állapottal.
Struktúra
Résztvevők
Protype: deklarál egy interface-t önmaga klónozásához.
ConcretePrototype: implementál egy műveletet önmaga klónozásához.
Client: új objektumot hoz létre, megkérve a prototípust önmaga klónozására.
Együttműködési információk
A kliens megkéri a a prototípust, hogy klónozza önmagát.
Következmények
A Prototype minta hasonló következményekkel jár mit az Abstract Factory és Builder: elrejti a termék osztályokat a kliens elől, csökkentve a ezzel azon nevek számát, amiket a kliens ismer. Emellett, ezek a minták lehetővé teszik, hogy a kliens módosítás nélkül dolgozzon az alkalmazás-specifikus osztályokkal.
A Prototype minta további előnyei:
Termékek hozzáadása és eltávolítása futásidőben. Új konkrét termékosztály beépítése a rendszerbe, egyszerűen a prototípuspéldány bejegyeztetése a klienssel. Ez valamelyest hatékonyabb, mint a többi létrehozási minta, mert a kliens futásidőben építhet be és távolíthat el prototípusokat.
Új objektumok meghatározása változó értékek mellett. A nagymértékben dinamikus rendszerek lehetővé teszik a új viselkedés definiálását az objektum összetételén keresztül – például az objektum változóinak értéket adva – és nem új osztályokat meghatározva. Ténylegesen a meglévő osztályok példányosításával, és ezek a prototípus kliens-objektumaiként bejegyeztetve adjuk meg. A kliens az új viselkedésmódot a felelősség prototípusra való átruházásával adhatja meg. Ez a tervezési mód lehetőséget ad új „osztályok” létrehozására programozás nélkül. Valójában a prototípus klónozása hasonló egy osztály példányosításához. A Prototype minta nagymértékben csökkenti a rendszer számára szükséges osztályok számát.
Új objektum megadása változó struktúra mellett. Sok alkalmazás részekből és alrészekből építi fel az objektumokat. Kényelmi szempontok miatt, az ilyen alkalmazások lehetővé teszik az összetett, felhasználó által definiált struktúrák példányosítását.
Kevesebb alosztály. A Prototype minta lehetőséget ad a prototípus klónozására, ahelyett, hogy egy gyártó metódust kérne meg új objektum létrehozására. Ezért nincs szükség Creator osztály hierarchiára.
Alkalmazás dinamikus beállítása osztályokkal. Egyes futásidejű környezetek lehetővé teszik az osztályok dinamikus betöltését alkalmazásokba.
A Prototype minta legfőbb felelőssége, hogy mindegyik Prototype alosztálynak implementálnia kell a Clone műveletet, ami bonyolult lehet. Például nehéz, ha az adott osztály már létezik. Clone implementálása akkor is nehéz lehet, ha olyan objektumokat tartalmaznak, amelyek nem támogatják a másolást vagy körkörös hivatkozást tartalmaznak.
Implementációs rész
A Prototype implementációjánál tartsuk szem előtt a következőket:
Prototype menedzser használata. Amikor egy rendszerben a prototípusok száma nem rögzített (tehát dinamikusan létrehozhatóak és megsemmisíthetőek), nyilván kell tartani a rendelkezésre álló prototípusokat. A kliensek maguk nem kezelik a prototípusokat, csak mentik és kiolvassák a nyilvántartóból. Egy kliens elkéri a prototípust a nyilvántartóból, mielőtt klónozná azt. Ezt nyilvántartót hívjuk Prototype menedzsernek. A prototype menedzser egy asszociatív tároló, ami egy adott kulcshoz tartozó prototípust ad vissza. Vannak műveletei a kulcshoz tartozó prototípus bejegyzésére és a bejegyzés érvénytelenítésére. A kliensek megváltoztathatják a nyilvántartót és tallózhatják azt futásidőben. Ez lehetővé teszi a klienseknek, hogy a rendszer leltárát kódírás nélkül felvegyék.
A Clone művelet implementálása. A Prototype minta legnehezebb része a Clone művelet helyes implementálása. Ez kiváltképp bonyolult amikor az objektumstruktúra körkörös hivatkozásokat tartalmaz. Ha a rendszerben lévő objektumok rendelkeznek Save és Load műveletekkel, akkor ezek használhatóak a Clone alapértelmezett implementálásához, egyszerűen csak menteni kell az objektumot majd azonnal visszatölteni. A Save művelet menti az objektumot egy puffermemóriába, a Load egy másolatot hoz létre, rekonstruálva a objektumot a pufferből.
Klónok inicializálása. Amíg néhány kliens tökéletesen elégedett a klónnal, ahogy van, mások az általuk választott értékkel akarják inicializálni néhány vagy az összes belső állapotát. Általában ezeket az értékeket nem lehet átadni a Clone műveletben, mert számuk prototípus-osztályonként változik. Néhány prototípusnak szüksége lehet több inicializáló paraméterre; másoknak egyre sincs szükségük. A Clone műveletben történő paraméterátadás eleve kizárná egy egységes klónozó interfész használatát. Lehetséges, hogy a prototípus osztályok már definiálnak műveleteket az állapot kulcsrészeinek (újra) beállítására. Ha ez van, akkor a kliensek ezeket a műveleteket használhatják azonnal klónozás után. Ha nincs, akkor lehet nekünk kell az Initialize műveletet bevezetni, amely argumentumként kapja meg az inicializáló paramétereket és ennek megfelelően állítja be a klón belső állapotát.
Minta kód
// Prototype pattern using System; using System.Collections.Generic;
namespace Prototype { /// /// MainApp startup class for Real-World /// Prototype Design Pattern. /// class MainApp { /// /// Entry point into console application. /// static void Main() { ColorManager colormanager = new ColorManager();
// Initialize with standard colors colormanager["red"] = new Color(255, 0, 0); colormanager["green"] = new Color(0, 255, 0); colormanager["blue"] = new Color(0, 0, 255);
// User adds personalized colors colormanager["angry"] = new Color(255, 54, 0); colormanager["peace"] = new Color(128, 211, 128); colormanager["flame"] = new Color(211, 34, 20);
// User clones selected colors Color color1 = colormanager["red"].Clone() as Color; Color color2 = colormanager["peace"].Clone() as Color; Color color3 = colormanager["flame"].Clone() as Color;
// Wait for user Console.ReadKey(); } }
/// /// The 'Prototype' abstract class /// abstract class ColorPrototype { public abstract ColorPrototype Clone(); }
/// /// The 'ConcretePrototype' class /// class Color : ColorPrototype { private int _red; private int _green; private int _blue;
// Constructor public Color(int red, int green, int blue) { this._red = red; this._green = green; this._blue = blue; }
// Create a shallow copy public override ColorPrototype Clone() { Console.WriteLine( "Cloning color RGB: {0,3},{1,3},{2,3}", _red, _green, _blue);
return this.MemberwiseClone() as ColorPrototype; } }
/// /// Prototype manager /// class ColorManager { private Dictionary _colors = new Dictionary();
// Indexer public ColorPrototype this[string key] { get { return _colors[key]; } set { _colors.Add(key, value); } } } }
Ismert felhasználás
Eszköztáraknál
Alapvető plug-in mechanizmusoknál
EJB/COM Szervereknél
Kapcsolódó minták
A Prototype és az Abstract Factory bizonyos tekintetben konkurens minták. Azonban használhatóak együtt is. Az Abstract Factory tárolhat egy olyan prototípus halmazt, amelyet klónozni akarunk, és a termék objektumokat adjuk vissza.
Már régóta szerettem volna foglalkozni a shaderekkel. Sajnos a bevezetők írása nem az én műfajom, így most is egy nagyszerű írást hívok segítségül TheProGamer tollából. Remélem segíteni fog mindenkinek ráhangolódni a témára. Amint lesz egy kis időm a példaprogram is érkezni fog...
Bevezetés
Mik is azok a shaderek, hogy működnek és miért jelentenek fejlődést? Ezen kérdésekre próbálok ezzel a cikkel választ adni. Kezdjük is rögtön azzal hogy mik is ezek? Hogy ezt megértsük először nézzük meg hogy néz ki a Direct3D Pipeline.
Mint a képen is látható a shaderek két részre oszthatók: Pixel Shader és Vertex Shader. Ez a két shader típus két ezelőtt teljesen merev automata folyamatot vált le. A Vertex Shader-ek a T&L leváltására készültek, a Pixel Shader-ek pedig a textúra mintavételezés és a képernyőre kerülő képpontok színének előállításának merev önműködő folyamatát hivatottak rugalmasabbá tenni.
De mik is ezek a shaderek konkrétan?
Kis, önálló nyelven a programozó által írt mini programocskákról van szó, amik alapvetően arra hivatottak, hogy a idáig automata folyamatokat elvégezzék. Kérdezhetitek hogy ez akkor miért jó, hisz ugyanazt csinálja és még ezt is kódolni kell. Mert nem csak helyettesíteni lehet vele ezeket az a folyamatokat, hanem tovább fejleszteni, bonyolultabbá és összetettebbé tenni, ezáltal sokkal élethűbb képet előállítani. Mert ugye ha valamilyen új, rugalmasabb eszközt adunk a programozók kezébe egy régi helyett, akkor ők nem arra fogják ezt használni hogy csak a régit helyettesítsék vele. :) Ez idáig gondolom érthető.
De akkor most ezek konkrétan hogyan is működnek?
Kezdjük az egyszerűbbel, a Vertex Shader-rel. A Vertex Shader minden egyes vertexre lefut, nem számít hogy hol van, milyen messze, milyen irányban. Legelőször is meg kell adnunk hogy a vertexek mely adataira van szükségünk (pl.: Helyzet, Normál Vektor, Tangens Vektor, Bitangens Vektor, Vertex Szín, Textúrakoordináta stb.). Ezeken az adatokon tudunk műveleteket végezni. Viszont ha nekiállunk Vertex Shader-t használni egy modellen, akkor a T&L egység már nem fogja a beállított mátrixokat „végrehajtani”, mivel maga a T&L egység ilyenkor le is áll. Tehát nekünk kell kézbe venni a dolgokat és a mátrixokat a vertexeken végrehajtani. Ezt szerencsére meg lehet oldani Vertex Shader-el, viszont felmerül a kérdés, hogy hogyan tudjuk a Vertex Shader-ben a mátrixokat használni mikor azokat nem tudjuk a vertex adatoknál lekérni. Szerencsére erre is van megoldás, a program, ami a Vertex Shader-t használja képes arra hogy speciális függvényekkel változókat adjon át a shader-nek, így simán át lehet már passzolni a mátrixokat is a szorzásokhoz. Tehát egy alap Vertex Shader annyit csinál hogy az átadott három mártixal (Világ, Nézeti és Projekciós) megszorozza a vertex pozícióját. De ez még csak a kezdet, innen már csak a képzeletünk (és a maximális utasítás szám) szab határt annak, hogy mit csinálunk a vertexek adataival. Ha kész vagyunk a vertex adatok számolásával akkor már csak ki kell választani hogy mit akarunk tovább küldeni.
Ezzel nagyjából végig is értünk a Vertex Shader-eken. Most következzen az érdekesebb és kissé bonyolultabb rész, a Pixel Shader. A Pixel Shader minden egyes pixelre lefut és végrehajtja a megadott műveleteket (mint ahogy azt a Vertex Shader is tette a vertexekre). És akkor itt most oszlassunk el egy tévhitet, ugyanis sokan hiszik azt, hogy a Pixel Shader a textúra képpontjain halad végig. Pedig nem így van. Eleve a textúra képpontjait nem pixelnek hanem texelnek hívjuk (pixel = picture element ; texel = texture element ). Tehát a Pixel Shader a képernyőre kerülő képpontokon fut végig, azoknak a színét számolja ki a textúrából vett minta és a megadott számítások alapján.
Itt már kevesebb adattal dolgozunk, csak az adott képponthoz tartozó textúrakoordinátát és ha van akkor vertex színt kapjuk meg. Ezek alapján tudunk a texturából mintát venni és azt tovább küldeni a képernyőre. És itt jön egy újabb kérdés: Akkor hogyan tudunk megvilágítást számolni Pixel Shader-ben, hiszen ahhoz kell az adott pont Normál Vektora.
Az egész egy kis trükkel megoldható. A trükk lényege az, hogy a Vertex Shader-ben fogjuk a Normál Vektort és textúrakoordinátának „álcázva” tovább küldjük feldolgozásra. Így már tudjuk használni a Pixel Shader-ben is a Normálokat. De ennek a módszernek van még egy igen kellemes előnye, mégpedig az, hogy raszterezéskor a videokártya lineáris interpolálással minden egyes ponthoz amit a Pixel Shader később kezelésbe vesz kiszámolja az adott textúra koordinátát a környező 3 vertex textúrakoordinátájából. Magyarul a háromszög felületén végigátlagolja a textúra koordinátákat annak függvényében hogy az adott pont milyen messze van az adott vertexektől. És mivel mi a Normál Vektort is textúra koordinátaként küldtük tovább az is szépen végigátlagolódik, lényegében minden egyes ponthoz kiszámolódik az adott Normál Vektor. Innen bár semmi akadálya annak hogy hogy megvilágítást számoljunk.
Ezzel körülbelül minden a cikkben felvetett kérdésre sikerült (remélem kielégítő) választ adni, remélem hasznát veszitek. Folytatások tervben, ha van rá igény akkor meg is írom őket.
[ItCafe] A mai naptól Magyarországon is minden felhasználó számára elérhető az Office Web Apps, amelynek összes funkciójához eddig a hazai Live ID birtokosoknak csak egy része fért hozzá – közölte ma a szoftvercég hazai leányvállalata. A böngészőből használható csomag segítségével Word-, Excel-, PowerPoint- és OneNote-dokumentumokat lehet létrehozni, szerkeszteni és megosztani a SkyDrive-on, a Microsoft ingyenes, 25 GB kapacitású internetes tárhelyén. Az Office Web Apps közel 150 országban használható a mai naptól.
Az internetes Office tartalmazza a felhasználók által leggyakrabban igénybe vett funkciókat, kezelőfelülete pedig a széles körben ismert asztali Office programcsomagéra épül. Az online program mindenki számára ingyenes, használatának nem feltétele az Office 2010 vagy valamely régebbi Office programcsomag jogtiszta változatának telepítése.
A legújabb Office Web Apps arra is képes, hogy egy blogba vagy weboldalba ágyazzon be egy Excel-táblázatot vagy PowerPoint-prezentációt. Ha ilyenkor a webes alkalmazásban frissítjük a táblázatot, akkor az a blogon vagy weboldalon is frissül, a prezentáció pedig kis méretben és teljes képernyőn is megtekinthető. A netes bemutatókhoz szabadon használható az Office.com képtára, amely több mint kétszázezer jogdíjmentes, szabadon felhasználható fotót és illusztrációt tartalmaz.
Az új alkalmazás egyik előnye, hogy eredeti formátumukban őrzi meg az Office-dokumentumokat, a konvertálásnál nem veszik el semmilyen formázási parancs. Mostantól a dokumentumok közvetlenül a Microsoft ingyenes internetes tárhelyéről, a mindenki számára 25 GB kapacitást nyújtó SkyDrive-ról is megnyithatók, és nemcsak a Hotmail-, hanem a Gmail- vagy a Yahoo Mail fiókkal rendelkezők is szerkeszthetik ezeket.
Nagy Levente, a Microsoft Office üzletágának vezetője elmondta: „Az Office Web Apps kiválóan kiegészíti a hagyományos, számítógépen futtatott Office programokat. Különösen akkor lehet hasznos, ha a felhasználók dokumentumaikat távolról szeretnék elérni, és olyan idegen gépről szerkeszteni, amelyen nincsenek telepítve a már megszokott irodai programok.”
További információ az online Office-ról a Microsoft magyar nyelvű weboldalán olvasható.
[Index] Márciustól a világ hatvan országában ismerhetik meg az informatikai biztonsággal foglalkozó szakértők az új támadási módszert, amellyel simán ellophatók a windowsos jelszavak.
A számítógépes bűnözők elleni harc világszerte oktatott tananyagába is bekerült annak az új biztonsági résnek a leírása, amelyet nemrégiben fedezett fel a NetAcademia Oktatóközpont etikus hekkere, Barta Csaba.
Egy rootkitről van szó, amely teljesen észrevétlenül fut a Windows operációs rendszeren, és a segítségével úgy lehet átírni a jelszavakat (akár a rendszergazdáét is), hogy annak semmilyen nyoma nem lesz. A szakmában korábban csak elméleti lehetőségként tekintettek erre a biztonsági résre, Barta Csaba azonban valós példával igazolta annak létezését. A kártékony kód a Windows 7 és a Windows Server 2008 legfrissebb, naprakész verziói alatt is fut, és eredetileg a vírusirtó programok sem fedezték fel. A kártékony kódot természetesen elküldték a vírusirtó cégekhez, tehát most már felderíthető.
A magyar felfedezést is tartalmazó, 7-es verziószámú Ethical Hacking tananyag – mely alapján többek közt az Amerikai Egyesült Államok Védelmi Minisztériumának informatikai biztonságért felelős szakembereit is képzik – idén március közepétől lesz elérhető az EC-Council képviselettel rendelkező országokban, így Magyarországon is.
Interjú Barta Csabával, a NetAcademia oktatójával és a Deloitte forensic-szakemberével a floridai Miamiban megrendezett XIV. Hacker Halted konferencián tartott előadása alkalmából, ahol a saját fejlesztésű rootkitjét mutatta be a szakma nemzetközi képviselői számára.
OpenGL alapozó sorozatunk mérföldkőhöz érkezett. Ugyanis minden tudásunk meg van ahhoz, hogy egy összetett 3Ds modellt jelenítsünk meg virtuális világunkban. Ha visszagondolunk, akkor eddig csupán csak kockákat, gömböket és egyéb egyszerű objektumokat ábrázoltunk. Valljuk be őszintén, nem volt túlságosan izgalmas vagy látványos a végeredmény. De most ezzel szakítunk és kész 3D modelleket fogunk betölteni és megjeleníteni.
Bejegyzések
