Įvairūs pamąstymai (2002-2003)

Atgal į "pamąstymų" puslapį

2003 12 29

Dar šiek tiek magistrinio tema (pradžią žr. žemiau). Taigi, šiek tiek "kūrybiško tweakinimo" SH aproksimacijai; šiek tiek optimizacijos pixel shader'iams, ir gana daug "kūrybiško" požiūrio į šešėlius ("plono stulpo šešėlio nėra? gerai - stulpas plonas, šešėlis nesvarbus! globalus apšvietimas už dyką!" :)). Rezultatas - atrodo kiek geriau, klaidų mažiau (arba jas vėlgi - kūrybiškai paslepiam).

Kad palygint greitį ir vaizdą, šiaip sau padariau ir standartinius shadow-depth-map šešėlius (floating point cubemap'as vienam šviesos šaltiniui). Per daug su jais nežaidžiau (taigi nepadariau nei closer-percentage filtravimo, nei nieko - dėl to ir juose "laipteliai" visokie matosi).

Taigi, lyginam: viršuje standartiniai cubemap'ai, apačioje šitas mano gaidulis (kaip nors gudriai jį galima pavadint...):

Turiu dar keletą idėjų, kaip dar ką nors "kūrybiškai" padaryt... Reikės pabandyt :)

2003 12 28

Kartais pagalvoju - visai gerai, kad dar užtaikiau į laikmečio, kol nebuvo 3D spartintuvų, galą. Turėt šiokį tokį supratimą, kaip ir kas "tenais" vyksta, yra visai neblogai. Dar geriau - suprasti, kodėl būtent taip kažkas vyksta. Netgi labai paprastus dalykus geriau yra suprasti - kad nenutiktų, pvz., z-buferis ("na... panaikina nematomus daiktus!") arba bi-linear filtravimas ("šitas gi... sulieja tekstūras!").

Čia aišku panašų į nostalgiją oldskool laikams... Bet kai iš tikro žinai, kad, pvz., paprasčiausiai tekstūrą ant daugiakampio rankomis uždėt yra ne taip jau paprasta (tais laikais ir masteliais netgi "labai daug skaičiavimų" tam reikėjo), tai ir 3D spartintuvams didesnė "pagarba" atsiranda, o ir šiaip geriau.

Manau, kad tikras (in-depth) supratimas, kaip, kas ir kodėl yra daroma, reikalingas praktiškai visur. Kadangi be programavimo nieko daugiau neišmanau (o ir programavimo - neitin), tai pavyzdžiai bus iš to. Tarkim, dabar turi .NET, programuoji su C#, keletu kodo eilučių gali užkrovinėt milžiniškus XML dokumentus arba kvietinėt web servisus - tikrai atrodo, kad esi smarkiai atsiribojęs nuo žemo lygio detalių. Bet - kažkada ateina toks momentas, kai kas nors pradeda veikti lėtai, naudoti daug atminties ir t.t. Tada reikia kažkaip suprasti ne tik tai, kad diiidelio XML parsinimas su DOM vien tam, kad vieną elementą pažiūrėt, yra "nelabai naudingas"; ir ne tik tai, kokių parametrų perdavimas RPC kiek atsieina.

Netgi .NET programuotojam, tarkim, reikia žinoti, kas yra "locality of reference", kaip veikia CPU kešas, kodėl kartais geriau padaryti 10x daugiau operacijų tam, kad sutaupyti pusę atminties kreipinių (detaliau: čia ir čia). Aišku, tai low-level detalės, kad ir koks high-level .NETas bebūtų :(

Tas pats ir su grafika - praėjus "aš nupaišiau piramidę! o dabar nupaišysiu tekstūruotą piramidę!!!" periodui, kažkada reikia suprasti, kur ir kas "tenais" vyksta. Negali tiesiog daryt glVertex ir tikėtis, kad "OpenGL pasirūpins!" [kažkodėl dažnas dar pamini, kad "OpenGL state machine" čia yra gerai - prie ko čia "state machine", aš po šiai dienai nesuprantu]. Čia nevarau ant OpenGL - visur tas pats. Turi žinoti, kas iš tikro vyksta, ir kaip kažką padaryt tokiu būdu, kuris būtų patogiausias aparatūrai.

...atrodo, čia jau kažkur pradedu kartotis - taigi matyt užteks :)

2003 12 28

Ne į temą - mažas žaislas "Kas Yra Kas Lietuvoje". Štai ką naudingo galima nuveikti, kol vyksta online chat'as su bosu :)

2003 12 25

Geras knygas reikia pradėt skaityt nuo mažens - ShaderX^2 pakliuvo į Martos rankas :)

Ok, tai nėra kokia nors super-fundamentali knyga (t.y. jos turbūt neverta pirkt, jei "noriu 3D išmokt!"). Bet yra tikrai neblogų dalykų. O jei dar ir už dyką gauni - tai negi neimsi?

Dabar reik žiūrėt, ar aš patsai papulsiu į ShaderX^3, ar ne... Jei labai labai greitai ką nors gero sugalvosiu, tai, žiū, dar gal ir du kartus papulsiu :)

2003 12 05

Pastaruoju metu galvojau apie šešėlius, lokalų apšvietimą, sferines harmonikas ir kitokį briedą, žodžiu, apie savo magistro darbą. Sugalvojau tokį dalyką: tarkim, turim statinę sceną, ir norim dinaminių šviesos šaltinių. Taip pat norim šešėlių, pageidautina "minkštų", ir nenorim naudot įprastų metodų kaip kad shadow volumes arba shadow maps.

Darom taip: daugelyje scenos paviršiaus taškų (viršūnėse, tarkim) apskaičiuojam iš-ten-matomo-atstumo funkciją. T.y. funkcija (pusėje) sferos paviršiaus, kur f-jos reikšmė - kiek iš tos vietos "matosi" ta kryptimi. Dabar, renderinant kiekvieną tašką, reikia pažiūrėt, koks atstumas iš taško šviesos šaltinio kryptimi -- jei mažesnis nei atstumas iki pačio šviesos šaltinio, vadinasi, taškas yra šešėlyje.

Problema: reikia kažkaip saugoti tas matomo-atstumo funkcijas daugelyje taškų. Kad taškų daug, tai nėra labai didelė bėda (dešimt ar šimtas tūkstančių, koks skirtumas :)). Bėda - kaip jas saugoti, ir dar taip, kad galėtum labai greitai rasti f-jos reikšmę norima kryptimi. Kolkas aš f-jas aproksimuoju sferinėmis harmonikomis (SH), 5-tos eilės -- taigi f-jai saugoti reikia 25 skaičiukų. Tačiau 5-tos eilės SH, sakyčiau, nelabai gerai aproksimuoja tas funkcijas :(

Kolkas rezultatas atrodo maždaug taip (~27 tūkstančiai viršūnių, 25 komponentų SH f-ja kiekvienai viršūnei, trys spalvoti dinaminiai šviesos šaltiniai, naudoja pixel shader 2.0, veikia ~60FPS ant Radeon9800Pro, taigi lėtai):

Šešėliai vietomis atrodo gana gerai, bet vietomis ir labai blogai :(

Taip pat, SH aproksimavimo klaidos iš arti (šešėlis ant sienos, šešėlis ant stulpo prie lempos, šešėlis ant grindų po lempa):

Dabar galvoju, ką čia galima būtų padaryt. Viktoras Jucikas man sako, kad reikia naudot waveletus, mol, gal bus geriau. Bičeliai iš Stenfordo irgi naudojo waveletus šiek tiek susijusia tema (All-Frequency Shadows Using Non-linear Wavelet Lighting Approximation), ir sako, kad tai geriau už SH... Tai ką, dabar man dar ir waveletus išmokt reikia? :)

Pabaigai: šiek tiek fun: jei tiesiog sumuoji SH koeficientus į spalvos kanalus be jokios aiškios priežasties, gaunasi gana gražios pastelės:

O va kaip viskas atrodo in wireframe (t.y. reikia daug viršūnių, kur laikyt matomo-atstumo f-jas):

Aj, dar bandžiau pasikonsultuot su žmonėmis iš gd-algorithms konferencijos visu šituo klausimu. Na, išvadų jokių nebuvo :), ir pati diskusija dar į konferencijos archyvus, rodos, nesuplaukė -- bet jinai turėtų būti už keleto dienų čia (tema "Occlusion maps for local lights via SH?").

2003 11 03

Ką gi - rodos, kad laimėjau ATi/Beyond3D "šeiderių" konkursą. Netikėta, bet visai malonu :) Šiek tiek žemiau mėtęsi paveikslėliai ir yra iš jo, t.y. demkės-šeiderkės Shaderey - galit ją parsisiųsti ir žiūrėt, jei tik ji veiks.

2003 10 09

Kartais, kai paskaitau kokius nors žaidimų review'us, arba kokias nors diskusijas vieno ar kito žaidimo/"variklio" klausimu, vis aptinku maždaug tokį: "naudojamas Super Turbo variklis, palaikantis Tuos ir Anuos efektus ar fyčerus". Ir tai pristatoma kaip variklio "pliusas". Juokinga!

Iš principo, bet koks "variklis" tave gali tik riboti. Grafikos pavyzdys: imam plain DX9 - ir turim visas priemones, kokiomis tik galime pasiekti spartintuvą. Turim visų įmanomų technologijų palaikymą, apskritai viską. Reiškia, galim realizuoti bet kokius efektus ar "fyčerus". Dabar, jei pradedam ant to lipdyti "variklį", tai automatiškai kažką abstrahuojam. Varikliai tam ir yra, kad tave atitolintų nuo žemo lygio detalių, kažkiek abstrahuotų no to, kas iš tikro vyksta, ir šiaip palengvintų darbą. Tačiau neišvengiamai abstrakcijos procese kažkas prarandama - kažko padaryt nebeišeina (variklis neleidžia!), arba kažką padaryt tampa net sunkiau (reikia apeiti variklio apribojimus!). Taigi, galimybių požiūriu, grafinis variklis gali tik riboti.

Čia panašu į Joel'io Law of Leaky Abstractions...

Aišku, varikliai paslepia žemo lygio detales, šiaip daug ką palengvina - tai gerai. Bet kai kitą kartą man rodysit variklį, geriau išvardykit jo apribojimus, o ne "ką jis palaiko" :)

2003 08 30

Paskutiniai - kas gi vis dėlto tai yra, galima pamatyti paveikslėlių viršuje :) Dabar - lauksim, ir žiūrėsim, kas gi bus!

2003 08 28

Dar keletas - atrodo gana baisiai! Ypač wireframe'u...

Tai va, atrodo baisiai, o vyksta ten daug (na, nelabai daug) funky dalykų:

• gerai užsislėpęs "atmospheric light scattering" (dėl jo dangus yra dangaus spalvos, ir kiti daiktai nublanksta, tipo),
• "image space edge detection" (juodos linijos, pagal gylio skirtumus ir normalių skirtumus),
• taip pat kažkas keisto su spalvom - aš konvertuoju iš RGB į HSV, tuo pačiu kvantuoju HSV komponentes, tada kažkaip (gana bjauriai) išdarkau S ir V komponentes, tada atgal į RGB. Šitą vietą dar reikia taisyt, idant atrodytų ne per daug klaikiai :)

2003 08 17

Šiaip paveikslėlis iš to, ką šiuo metu bandau daryti - kad ir kas tai bebūtų :)

Nieko įspūdingo - kokis tai terrain'as (apie pusė milijono trikampių), kelios tekstūros ant jo, kažkiek pseudo medžių (jie turi taip atrodyti :)), ir paprasti projektuoti šešėliai, nuo medžių einantys ant terrain'o. Aišku, šešėliai dinaminiai - šviesos šaltinio kryptį galima keist kaip nori...

Sunkiausia čia padaryt, kad šešėliai per daug blogai neatrodytų - aš naudoju vieną 1024x1024 tekstūrą visiem šešėliam - supaišau į ją visus medžius, tada projektuoju ant žemės. Į tekstūrą paišoma maždaug tiek, kiek mato žiūrovas (ant viso terrain'o uždėta tekstūra būtų ryškiai per mažos rezoliucijos), taigi jam judant plotas, kuriam "skiriamas" šešėlis, pastoviai keičiasi. Va čia ir išlenda - po truputį keičiantis tam plotui, šešėlių pikseliai baisingai pradeda matytis (nors aš ir naudoju pseudo-anti-alias šešėliams, t.y. paskaitau iš tekstūros keturis kartus su kiek kitomis koordinatėmis). Na, bet galų gale viskas dabar gerai - reikia tą "šešėliuojamą" plotą kvantuot tokiu žingsniu, kuris lygus vienam shadow map'o tekseliui. Va :)

Dar - iš antro shot'o matyt, kad terrain'as neturi jokio LOD'o (tik cull'inami gabalai, kurie į vaizdą nepatenka). Aš padariau paprastą GeoMipMapping'ą, bet praktiškai kolkas jo neprireikė - kolkas dažniau visvien stabdo ne trikampių kiekis, o pikselių kiekis...

2003 07 08

Čia iš darbo, projekto "CvFX" (ne, nVidia anei 3dfx čia neprieko :)) - toks entertainment projektas, kur stovi prieš kameras, o iš tavęs rodo "fokusus". Čia vienas iš paprastų - half-toning (ATI, GDC2003) ir edge detection, abu realizuoti viename pixel shaderyje 2.0 (galima ir senesniame, bet nebuvo reikalo). Veikia >100FPS ant paprastojo Radeon9500.

Čia aš ir klaviatūra, kaip tik alt-printscreen paspaudimo momentu :)

2003 06 17

BRDF "spiria į rimtą subinę"! Dešinėje - atlasas (satin) ir aksomas/atlasas (velvet/satin); su identišku mesh'u ir dviem tokiais pačiais kryptiniais šviesos šaltiniais. Renderint tokius realiuoju laiku pigiau grybo - du mažučiai cubemap'ai (vieną reikia du kartus dėt, kitą vieną) ir nieko daugiau. Ir atrodo pusėtinai, ne kaip plastmasinis Phong - mano akim žiūrint, atlasas į tikrą atlasą panašus; o aksomo po ranka neturėjau, kad palyginti :)

Čia, jei ką, pagal McCool et al. "Homomorphic Factorizations of BRDFs for High-Performance Rendering", SigGraph 2001 (PDF). Ir, taip, čia mano bakalauro dalis - ryt ginsiuos.

2003 05 21

Neseniai: "lietuviškos informacijos apie 3d varikliuko programinima"... Lietuviškos! Na jau...

Kad nėra - faktas. Kodėl nėra - geras klausimas :) Matyt, nėra, nes niekam nereikia, arba niekas nemoka/tingi parašyt. Arba (turbūt tai teisingiausia) ir tas, ir tas.

Dalykas, kuris "spiria į rimtą subinę" DirectX9 - tai "effect framework" (ID3DXEffect ir t.t.). Naudoji - ir vargo nematai, ir praktiškai turi viską (kas tiesiogiai liečia renderinimą), ko reikia. Pvz., po LTGameJam2003 kai kas iš dalyvių manęs klausinėjo "o kaip ten paišymas vyksta? turbūt labai sudėtingai?". O iš tikro ten nieko nėra, ir pats paišymo kodas turbūt kokius 5-10% viso kodo apimties sudaro, ir ten taip nuoseklu ir aišku viskas...

Turbūt (tik turbūt) ID3DXEffect netinka "labai rimtiems" dalykams (na, normaliems žaidimams), bet pradžiai - super.

2003 04 20

Kuo toliau, tuo labiau manyje stiprėja įsitikinimas, kad visi "games programmer wannabe" per daug dėmesio skiria grafikai. Aš pats, beje, irgi :) Čia ypač taip pagalvojau paskaitęs Vytauto Šaltenio straipsnelį - ten viskas teisybė, bet pradedama nuo grafikos.

Grafika - oras; jai visai suprast reikia tik truputėlio smegenų ir netingėt straipsnių skaityt (SigGraph, GDC, t.t.), kad neatsiliktum nuo gyvenimo. 3D plokščių veikimo principai paprasti iki bukumo, 90% visų "prijomų" ir algoritmų žinomi jau dešimtmečius, nekurios grafinės API irgi paprastesnės nei DuKartDu. Vienu žodžiu, grafikai "daug karmos turėti" nereikia.

Kas kita yra visa likusi dalis - pirmiausia pats žaidimas, po to šalutiniai efektai (Bus fizikos modeliavimas - koks, kodėl ir kaip tai veiks? Kaip su žaidimu tinkle? Kaip ir kodėl pats žaidimas bus padarytas?). Na, į šiuos klausimus aš irgi ieškau atsakymo - jei kas nors žinot, praneškit :) Aš galiu manyt, kad žinau, kaip daroma grafika, bet kaip sužinot, kaip daromi žaidimai (arba: kaip turėtų būti daromi žaidimai)?

Va, pribūriau, kaip "grafika yra gaidys", tai dabar reikia vėl apie 3D... Peter-Pike Sloan išmislai (minėjau kažkur čia jau) labai ir labai įdomu, reiktų kada nors pabandyt ką nors ta tema sukept. "Kada nors", aišku, vėl tas hipotetinis momentas - "kai bus laiko"...

Aš įsivaizduoju, kad galima būtų įprastus lightmap'us pabandyt pakeist šitais stebuklais - tikriausiai reikėtų pagrindinę geometriją suskaidyt į daugiau trikampių (bet trikampiai šiais laikais nemokami) ir kiekvienoje viršūnėje laikyti sferinių harmonikų koeficientus (arba CPCA skaičiukus). Tada iš esmės gautume kažką tarpinio tarp lightmap'ų ir per-vertex dinaminio apšvietimo. Hm, galbūt tai nelabai tiktų itin mažoms patalpoms arba arti esantiems šviesos šaltiniams; bet turėtų tikt kokiai nors katedrai, pro kurios langus/vitražus šviečia besikeičianti šviesa :) Arba, dar geriau - išorės scenoms.

Dar kita idėja - išplėsti tai, ką nVidia darė GeForceFX demoškei "Ogre". Iš jų GDC2003 prezentacijos "Ogres and Fairies: Secrets of the NVIDIA Demo Team" (berods čia) galima suprast, kai kiekvienai ogro modelio viršūnei jie buvo paskaičiavę "occlusion term" - na, jos apšviestumą. Dar tikriausiai per anksti apšviestumą (1 skaičius) pakeist sferinėm harmonikom (tarkim, 25 skaičiai), bet ta diena turbūt artėja.

Dar viena mane persekiojanti idėja: turiu įtarimą (įtariu bites), kad "Bžykt" vaizdą galima išgauti kitu, galbūt geresniu, būdu. Net nepamenu, kas sugalvojo, kaip padaryt tuos "spalvotus brūkšnius" - berods, tai buvau aš :) Blogiausias dalykas su jais - kad supaišius viską į mažą tekstūrą, tą tekstūrą reikia atsitempti atgal iš video plokštės, ir pagal jos pikselių spalvas paišyt tuos brūkšnius. Ta dalis "atsitempti atgal" ir stabdo labiausiai...

Galvoju, kad tikriausiai išeitų supaišius viską į tokią pat mažą tekstūrą, vaizdą išgaut kaip nors gudriai panaudojant pixel shader'ius. Pvz., paskaitom tą tekstūrą keliose vietose, jei spalvos skiriasi - tai, e... kažkaip išgaunam "perėjimą tarp brūkšnių". Panaši idėja, tik žymiai paprastesnė, kaip tik neseniai buvo vienoje iš ATI GDC2003 prezentacijų - berods Realtime 3D Scene Post-Processing. Ech - ir šitą daiktą reikia imt ir pabandyt kada nors... Kas nors žino planetą, kur paroje yra 64 valandos?

2003 04 08

Visu smarkumu ruošiuosiu būsimajam GameJam#2 - visai sunku; įtariu, kad šiek tiek "per daug" užsibrėžiau (net lygių redaktorių beveik baigiu padaryt - siaubas!). Nežinia, kas iš viso to gausis, bet kolkas aš savim visai patenkintas, va tik kad spėčiau padaryt viską...

2003 02 27

Vienas įspūdingiausių praeitų metų (2002) SigGraph straipsnių buvo "Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments" - straipsnį, slaidus ir video galima rasti čia.

Pirmas žingsnis link gero apšvietimo realiuoju laiku; rašydamas "geras" turiu omenyje ne "mes turim per-pixel specular'us ir stencil šešėlius" (primena DoomIII, ane?), bet kad mes turim šviesos transporto vaizdavimą - iš ten turim ir "minkštus" šešėlius, ir šviesos atspindžius, t.t. Praktiškai tą patį, ką gauname ir skaičiuodami radiosity. Tik kad mūsų šviesos gali judėti ir visaip kitaip duotis. Kaip lightmap'ai, tik dinaminiam apšvietimui. Gerai!

Žiūrint į straipsnį, pirma jis kala per smegenis (bent jau man taip buvo), bet kai geriau įsiskaitai (arba ilgiau pažiūri ne į straipsnį, o į slaidus), tai paaiškėja, kad visa idėja stebėtinai paprasta. Du kart du beveik :)

2003 02 27

O, kokia pauzė buvo :)

Krapštau po truputį GameJam#2 "variklį" ir jaučiu, kad vėl darau klaidą - pradedu daryt viską "nuo apačios"... T.y.: padarau resursų krovimą, renderinimą, ir t.t. O tada ant to gauto "variklio" bandysiu lipdyt "žaidimo variklį".

Va čia ir įtariu bites - galbūt iš tikro pradėt daryt nuo pačio žaidimo, ir palaipsniui sudėt į "variklį" tai, ko reikia ir tokiu būdu, kad būtų patogu?

Dar bėda - kaip pats žemiausias sluoksnis ("grynasis variklis" - pats sugalvojau :)) daromas maždaug įsivaizduoju... Įdomu, kaip reikėtų daryt aukštesnį - "žaidimo variklį"? T.y. kaip valdomi žaidimo veikėjai, kaip bendrauja tarpusavyje, t.t. Kas pasakys man?

2003 01 11

Žiūrinėjau DirectX9 - visai gerai. Jis šiek tiek per anksti išleistas, nes užsilikę nemažai klaidų (apie jas galima paskaityt DX konferencijoje), dokumentacijoje yra klaidų ir kai kas nedokumentuota. Bet šiaip gerai - beveik kaip DX8, ir nemažai gerų dalykų pridėta.

2002 12 26

"Physically based modeling" kursas (čia) yra labai gerai. Super slaidai, ir super anotacijos. Visiem, kas domisi fizika/partiklais, būtina!

2002 12 08

Darbe kažkaip atėjo mintis, ar tikrai greitai veikia mūsų 3d engine su visu jo OOP ir krūva abstraction layer'ių. Ir ką - realiame žaidimo pavyzdyje niekas iš pačio variklio į "daugiausia laiko užimu" topus neįeina! Daugiausia užima pats paišymas - logiška...

O dar sako, kad OOP stabdo (ar stabdo bent jau ten, kur greičio reikia)... Pas mus to OOP net per daug (abstrakcijos ant abstrakcijų... galima turbūt būtų apatinius sluoksnius iš viso išmest, ir niekas nepastebėtų), o įtakos greičiui - jokios :)

2002 11 21

Nugirdau mintį, jog "C++ šiek tiek populiari yra tik todėl, jog Microsoft ją stengiasi prastumti. Jei taip nebūtų, tai Delphi viską valdytų." Įdomi mintis, nieko nepasakysi :)

C++ mane vis labiau stebina. Tikrai kad su ja taip yra: pradžioj manai, kad jos nemoki, po kokių metų manai, jog moki, o po 2-3 metų suvoki, kad nė velnio tu C++ nemoki...

Greitas pavyzdys iš Spirit-Phoenix: visi žino std::for_each - jis kiekvienam konteinerio elementui vykdo kažkokią funkciją (t.y. paduotą funktoriaus objektą). Dabar pavyzdys: atspausdinkim visus nelygnius STL konteinerio skaičius su for_each:

for_each( c.begin(), c.end(),
    if_( arg1 % 2 == 1 ) [
        cout << arg1 << ' '
    ]
);

Stebėkit, kas pasidaro vidurinėse eilutėse - iš tos "C++ primenančios" išraiškos sukonstruojamas funktoriaus objektas, kuris turi operator(), kuris savo ruožtu spausdina lyginius argumentus! Nereikia rašyt jokios naujos klasės su "kažkokiu ten" operatoriumi, etc. C++ naudojamas kaip funkcinio programavimo kalba!

Aišku, galima klaust "kas iš to? mes galim paprastą for ciklą parašyt!". Taip. Tikrai galima ciklą parašyt. Aš pats irgi nelabai suprantu funkcinio programavimo prasmę/naudą (kolkas), bet mane vistiek labai žavi C++ kalba...

2002 11 12

Apie tinkamą duomenų konteinerį: testavau particle sistemą: 9000 dalelių, kiekviena tik juda pastoviu greičiu, kas sekundę "numiršta" bei yra sukuriama po maždaug 1500 dalelių. Į GPU pučiama per AGP (kolkas nenaudojant index buferių), fillrate neėda, viskas po AthlonXP1500+ su DDR atmintimi.

Na, jau iš anksto aišku, kad std::list dalelėms laikyt netinka - baisus iteravimas (kešo atžvilgiu), new/delete kiekvienai dalelei, ir t.t.

Resizable pool yra paprasto pool idėja, išplėsta iki tiek, kad pool'as nėra fiksuotos talpos ir į jį sudėti objektai niekada nekeičia savo vietos atmintyje. Realizavau taip: kaip sąrašą iš paprastų pool'iukų. Na, o paprastas pool'as - tai fiksuoto dydžio masyvas objektams, ir indeksų masyvas. Pagal indeksų masyvą įterpimo ir šalinimo greičiai yra O(1), iteravimas daugeliu atvejų irgi cache-friendly. Resizable pool atveju iteravimas yra šiek tiek sudėtingesnis.

Packed array gi yra iš viso paprastas daiktas - tiesiog masyvas. Šalinant ką nors iš vidurio, paskutinis elementas atkopijuojamas į ką tik pašalinto vietą. Taip niekada nebūna "skylių", o ir kešas tiesiog džiaugiasi, iteruojant per masyvą. Realizavau iš viso paprastai, std::vector pagalba (kas papildomai suteikia ir kintamą talpą).

...tai štai, kiek įtakoja konteineris. Dar primeskit, kad čia yra ir kitų neoptimalių dalių (keletas virtualių metodų kiekvienai dalelei, etc.).

2002 11 10

Visgi įdomu, kodėl ray-tracing kai kurie žmonės laiko dievu? Kiek mano galva neša, jis tinkamas atspindžiams/refrakcijai (o ir tiems ne itin). Tu negali padaryt normalaus apšvietimo su raytraceriu. Negali caustics'ų padaryt. Negali padaryt švytėjimo. Na, ir taip toliau.

Taigi, kad raytraceriai yra riboti - faktas. Kad pakankamai lėti - irgi faktas. Man įdomu, kodėl raytracerių fanatai nenaudoja kito - riboto, bet greito - metodo - paprasto trikampių piešimo? Nežino? Nebando?

Argumentas, kad "OpenGL/D3D viską stengiasi vaizduoti greitai", o "raytraceriai viska daro akuratniai" - nieko vertas. GL/D3D vaizduoja tekstūruotus trikampius, ir vaizduoja juos tiksliai (na, proto ribose :)) - daugiau jie nieko nedaro. Greitis yra tiesiog šiaip, šalutinis (bet geras) požymis. O kuo tekstūruoti trikampiai nusileidžia spindulių leidinėjimui? Manau, kad kaip ir niekuo... netgi galėčiau teigti, kad įmanoma su GL/D3D sugeneruot tokį patį vaizdą kaip ir su Pov-Ray, tik su šalutiniu efektu, jog veiks gerus keliasdešimt kartų greičiau :)

Va, tik šiandien perskaičiau Jensen "Global Illumination using Photon Maps" (gėda - taip vėlai!) - tai, IMHO, yra gerai.

O šiaip - man rodos, kad 3D hardwarui nebeliko itin daug kliūčių iki tikrai gero vaizdo - prieš kiek laiko vienintelė bėda buvo mažas tikslumas pikseliuose (8 bitai - nekas...), betgi dabar ir šios bėdos nebeliko.

...tai jei viskas gerai, tai turbūt nėra blogai, ane?