Pa ti rece da znas osnovne stvari vezane za 3D...

U svakom slucaju, ako si vec odlucio da sam sve radis, to je dobro, tako se najbolje uci. Z order se radi ili pored Z buffera koji ti ne mozes da koristis za softverski renderer, a back face culling se radi tako sto pogledas na koju stranu ti je orijentisan trougao u screen spaceu: ako gleda na pozadi, onda ga odbacis, a u suprotnom ga iscrtas. Jednostavna matematika.

Znam ja za tu vrstu HSR-a, tj ako je ugao izmedju vektora normale trougla i vektora camere (from-to) manji od 90 onda je on vidljiv, i da se on lako trazi preko skalarnod i vekorskog proizvoda, itd...
Sve je to lako, medjutiim kako da odredim smer normale, znam za koriscenje pravila desne zavojnice-ruke, sta ce se desiti na sledecem primeru (u dodatku dole).

Probaj da u screen space-u uradis sledece:

Ukoliko je ovo vece od nule, trougao je vidljiv.

U svakom slucaju bi bilo bolje eliminisati poligon pre projekcije.
Time se izbegava suvisni racun...

A kako mislis da odredis da li je poligon forward facing ili back facing pre projekcije?

Transformacija normale je jeftinija od transformacije tri vertex-a

I da i ne:

Transformacija normale jeste jeftinija, ali cilj je da uklonis faceove, a ne vertexe. Normale se nazalost vezuju za vertexe. Pogledaj primer gde imas vertex na silueti objekta - ti njega moras da transformises jer je deo neko forward facing trougla, ali takodje i back facing trougla. U slucaju da radis sa normalama, morao bi da transformises 3 normale, i da onda za svaki face izracunas i 'face normal' i da na osnovu njega izracunas na koju stranu gledas. Ovo je isti djavo kao da transformises sve vertexe.

Postoji i varijanta da osim vertex normala koje koristis za osvetljenje sacuvas i face normal, i da onda nju transformises, i na osnovu nje odredis da li treba da iscrtas face. Nazalost, cak ni to te ne cuva od toga da moras da transformises vise vertexa nego sto ti treba (jer to sto neki face gleda na pozadi ne znaci da ne treba transformisati barem neki njegov vertex).

Takodje, sa face normal varijantom je problem to sto za sve forward facing faceove ti moras da transformises i po jednu normalu vise po faceu da bi video na koju stranu gleda. A faceova ima vise nego vertexa ...

Kako god da okrenes zeznuto :)

Marko, cak i da resis ovo, problem je i to sto ne mozes da se oslonis samo na bilo koju od ovih metoda uklanjanja nevidljivih trouglova: sta se desava kada objekat ima forward facing trougao koji se nalazi iza nekog drugog forward facing trougla? Drugim recima, sta cemo ako objekat nije konveksan? Zamisli objekat koji se sastoji od dve sfere:



U svakom slucaju, pisanje softverskog renderera je otprilike kao pisanje asemblera - da, naucices nesto, ali ces vise vremena potrositi na resavanje poznatih problema nego na resavanje novih i verovatno zanimljivijih problema (osvetljenje, senke, itd.).

---

U svakom slucaju, dopada mi se da je ponovo krenula neka diskusija na 3D programiranju, a da nije o holodeku. :)

Zapravo ono sto Tosa prica je normala face-a. U software renderingu nema pravila, sam vezujes normale sa cim hoces. ;) Naime proveris da li je normala face-a vidljiva (klasican dot produkt normala pravac u koji gleda kamera). Sve pozitivno je sigurno vidljivo, onda za negativne vrednosti odredis neku vrednost npr. -30 stepeni i sve ispod te vrednosti je nevidljivo. Sve izmedju -30 i 0 mozes da tretiras kao vidljivo i renderujes ili da za te poligone dodas jos jedan screen space test pre renderinga.

Ova tehnika nije idealna jer u nekim slucajevima poligoni (kada su dovoljno veliki i kada se nalaze u uglovima ekrana) postaju nevidljivi, ali bi bili vidljivi kada se koristi samo screen space test.

Uglavnom u proslosti u igrama sa software rendering-om ovaj problem se nije vidjao zato se ovakav backface culling koristio samo za animirane karaktere. Za velike poligone koji bi pravili ovaj problem koriscena je BSP tehnika.

One koje zanima software rendering najbolje je da pogledaju ove knjige:

Michael Abrash's Graphics Programming Black Book
http://public.planetmirror.com/pub/gpbb/

Tricks of the 3D Game Programming Gurus-Advanced 3D Graphics and Rasterization
ISBN: 0672318350

Branimir

Secam se te knjige :)

Jeste, ali za face normal vazi i sve ono sto sam napisao gore - moras da transformises vertexe (SSE - protrcis jedanput kroz ceo VB i sve transformises, ovo je verovatno brze nego da gledas face po face i da onda transformises njegove vertexe sa kesiranjem). E sad se postavlja pitanje da li je efikasnije za svaki face transformisati i normalu pre renderinga, ili raditi nesto na osnovu vertex normala (dakle bez face norm)? Pogotovu sto ti vertex norm ne gine zbog osvetljenja...

Takodje, kao sto sam kazes, ne mozes da dozvolis da ti trouglovi tek tako nestaju ako zadju u nezgodan ugao - morao bi da radis u screen spaceu.

Marko, kad vec pricamo oko ovoga, sta si namerio da uradis sa rendererom? Teksture, osvetljenje, samo solid color?

Da u sadasnje vreme to je totalno neprihvatljivo. :) Mada kada sam ja radio software rendering to je bila normalna praksa (386, 486, Pentium 1). Jer tada je bilo dovoljno impresivno da renderujes 3D i niko nije cepidlacio ako par poligona nestane... ;)

Evo i demo koji sam radio 1995. 100% x86 assembler, radi pod 95, 98, ME, za 2K i XP treba dosbox emulator. :)
http://www.scene.org/file.php?...95/demo/money.zip&fileinfo

BTW, primetices da ni subpixeling ni subtexeling "nisu" bili u modi. :D

Branimir

Kao prvo drago mi je da ste se zainteresovali za 'moje' pitanje, a kao drugo zelim da vrsim i iscrtavanje TEXTURE na poligon, kako da to na sto jednostavniji nacin uradim to. Zagazio sam u vode C++, koristim Dev-C++ beta 5 i dosta toga sam postigao, a za cim sam u VB mastao, ali i VB je dugo vremena za mene bio 'osnova', naime lako ali sporo iscrtavanje i...

Vidim da je bilo ovde ljudi koji su vec radili SW rasterajzing..

Mozete li me uputiti na neki Source za SW triangle texture rasterizing?
Samo mi je potrebno da bilinearno iscrtam teksturisani trougao, dakle samo da se razvuce tekstura preko njega, bez ikakvog svetla - nista Phong, Gouraud..

Koristim pbuffer za mesanje tekstura u OpenGL-u i sad se pojavio zahtev da to radi i na nekim server masinama za generisanje tekstura terena. Naravno, nema tamo ni pomena od pbuffer-a..

Ako nekoga zanima, razvijam 3D engine za:
http://www.lencods.com/CODS.aspx
http://www.mapcube.com/

Pretpostavljam da ovo radis za neki preview, jer sa samo bilinearnim i bez svetla ne mozes da dobijes nista sto ce pristojno da izgleda.

Pogledaj neki rendering library na sourceforge-u, to bi ti verovatno bilo najlakse resenje.

Radi se o delu koji kreira teksture. Slicno kao "Merge Layers" u PhotoShopu. Scena moze da ima i 10-15 Layer-a i oni se spajaju u 2D Alpha Blenderu, i onda se samo konacna tekstura salje za rendering. Zapravo, dodaju se jos i dinamicke teksture, oblaci i sl. sa multiteksturiranjem ali seovde priprema bazna tekstura.
Za to inace koristim PBuffer i Orto projekciju, vec postoji i SW rasterizator, ali samo za pravougaono mapiranje (axis aligned). Sad se pojavila potreba za mapiranjem proizvoljnih trouglova.

Nije meni problem da to uradim, ali trazi vremena, uvek ga je manjak, pa ako vec ima neko gotovo resenje.. Ranije (pre HW 3D) je bilo puno tih SW rasterizatora, pa se nadam da neko mozda ima ili zna gde ima gotov Source ili primer..

OpenGL ima software implementaciju (spor, ali je precizan rendering) u slucaju da te "server masine" nemaju podrsku za 3d akceleraciju. Takodje sve sto renderujes u pbuffer mozes da renderujes i u frame buffer. Jedini problem na koji mozes da naidjes je da frame buffer rezolucija ne moze biti dovoljno velika da izrenderujes celu teksturu odjednom, ali je moguce tu teksturu podeliti i onda renderovati deo po deo.

Ako to nije dovoljno pogledaj:
http://www.mesa3d.org/

Branimir

Hvala jos jednom, ali kako svi mi ne volimo samo 'praznu' diskusiju hajde da bacimo malo matematike i nekih jednacina, znaci kako da mapiram texturu (u trouglu ili cetvorouglu) u 2D sistemu, za pocetak.

Da li znas da nacrtas popunjen trougao bez teksture (bez API poziva)?

Branimir

Ne bi se uhvatio ozbiljnog posla da nemam nelu osnovu. Imam neko svoje resenje ali je brzina problem, ali ne bi smetalo neko uprosceno.

Teksture mesam u posebnom Threadu, tako da ne dolazi u obzir koriscenje Frame buffer-a za to, pbuffer je mnogo bolje resenje.
Ne isplati se koristiti SW OpenGL, trajalo bi nedeljama - neki nasi fajlovi sa mapama imaju i po 30-40 GB tekstura i mesa.

Takodje vec postoji odredjeno SW resenje, samo ga treba obogatiti sa uopstenim trouglovima. Dakle, radi se zapravo o 2D rasterizaciji, bilinearno, nista svetlo i ostalo.

Da, svestan sam da Mesa3D ima SW implementaciju, takodje i razni Open Source engini kao Irrlicht, ali kopati po kodu koji je cesto vrlo uopsten nije uvek efikasno.

Ipak, hvala na interesovanju.

Evo pronasao sam jedan link koji pokriva i iscrtavanje i optimizaciju:
http://www.exaflop.org/docs/fatmap/ind.html

Takodje kada na Google-u napises "texture mapping" pri vrhu dobijas sledece linkove:
http://www.geocities.com/SiliconValley/2151/tmap.html
http://www.gamers.org/dEngine/quake/papers/checker_texmap.html

Kada napises "bilinear filtering":
http://www.flipcode.com/tutorials/tut_bilinear.shtml
http://www.gamedev.net/reference/articles/article669.asp

Branimir

Hvala Branimire, onaj prvi link mi je nov i zanimljiv.

Imam dosta informacija, ali ce iznaci pak trebati vise vremena, pa me sad menadzeri teraju u drugom smeru, ovo ce malo sacekati na red..

Da, to je izuzetno dobar tekst. Pojavio se jos dok sam bio u srednjoj pre 7 godina kada sam se bavio time. Pomogao mi je za maturski.