Snake5's Blog

Kāda spēļu veidotāja blogs…

Daily Archives: 20 aprīļa, 2010

Ir variants…

Tātad, apskatījos dažādus ne tik vecos Gunplay screenshot’us, un CoD4 screenshot’us un sapratu, ka vajag “bagātākas” tekstūras — tad ar decal’iem īpaši aizrauties nevajadzēs. Tagad pētīšu HL2 līmeņus (dabūju BSP viewer’i), skatīšos, kā tur panāca to piepildījuma efektu bez nenormāla decal’u skaita.

EDIT: Paskatījos, kā tur viss veidots.. apskatījos daudzas tekstūras arī.. izskatās, ka viņiem ir vairākas versijas vienai tekstūrai – līdzīgi kā citi profesionāli līmeņu veidotāji, viņi paņēma čupu ar tekstūrām, čupu ar bojājumu/netīrumu tekstūrām un uzblendoja otrās uz pirmajām dažādos veidos.

Man vajag to un šito..

Ietestējot trulāko apgaismojuma implementāciju, kādu vien varēju uzveidot, nonācu pie secinājumiem:

– Vajag samazināt manas prasības
– Vajag ierobežot dzini

Tur pat zirgam ir skaidrs, ka ar alphablendotiem (no CG valodas tulkojas kā – caurspīdīgiem) objektiem joki mazi. Pat ja 2 slāņus es uzzīmētu bez problēmām (1. slāņa gaismai piereizinātu 1-dest_alpha (saglabājās no pēdējā zīmētā caurspīdīgā objekta), kas ir, citiem vārdiem sakot, SrcBlend=InvDestAlpha), ar 3 slāņiem to izdarīt nesanāks. Tāpēc es vēlreiz aci uzmetu prasībām..

Un izrādās, ka…

1. alphablend’otus daudzstūrus tik daudz man tomēr nevajag:

Ar AlphaFactor=127 nemaz nav tik viegli pamanīt tās nelielās problēmas, tomēr …

2. daudzos gadījumos var “smago alphablendu” (kuram vajag uzrenderēt gaismas) aizstāt ar alphablendotām tekstūrām bez gaismas, un ar zemu alpha vērtību pāri visai tekstūrai (<~0.5), vai dažos gadījumos vēl receptei var piemest additive blending’u (src_alpha;one), piemēram – gaismām:

Kā mēs te redzam, ir problēmas, bet tās ir viegli atrisināmas – gaismu spraitiem lietojam additive blending’u, logiem pirmā slāņa alphablends ir bezmaksas, bet gaismas spraitu lejā var apstrādāt tā, lai tam būtu asas malas un alphablendings netaisītu nekādas problēmas…

Tas mūs noved pie nākošās problēmas – pikseļainas, “apgrauztas” malas. Kura nemaz nav īsti problēma, jo videokartes saprot mul_sat un mad_sat instrukcijas. alpha = saturate( alpha * 255 – alpha_factor );. Viss vienā instrukcijā. (mul_sat būs tad, ja apmierinās alpha_factor =0, bet tas visticamāk tā nebūs :P).

Nākamā problēma – sienu detalizācija. Tā kā pienākusi tāda situācija, ka apgaismotus alphablendotus decal’us lietot tik daudz nevar, tad pagaidām redzu šādus variantus:

– Ne-alphablendoti decal’i; (sienu bojājumi, uzraksti)
– Alphablendoti decali – pavisam neapgaismoti, ar mazām alpha vērtībām (+varbūt additive blending); (dūmi, gaismas stari)
– decal’us neapgaismot ar dinamiskajām gaismām; (tumšie sienu bojājumi, visi tumšie uzraksti un viss pārējais, kas tumšs)
– vairākas tekstūras vienam blokam, kuras kaut kā tiek jauktas kopā; (sarežģīts un nepārdomāts variants, visticamāk dabas “telpām” der, kur gan jau tāpat var iespiest cita veida decal’us)
– decal’iem tiem izrēķināta krāsa no centra punkta; (der tumšām telpām, gaismas stariem – krāsas pieregulēšanai)
-= vajag izdomāt veidu, kā lietot ļoti daudz decal’us, kuri saplūst ar sienu (tātad – alphablendoti, apgaismoti)
Pagaidām atbilde varētu būt deferred rendering … man nepatīk tā atbilde. Atmiņu aprij nenormālos daudzumos (1024 x 768 x 32 biti x 3 rendertarget’i => 72 MB*). Tekstūrām maz vietas paliek videokartēs ar 256 MB atmiņu. Nemaz nerunājot par 1280 x 1024 x 32 x 3, kas ir vienāds ar 120 MB…

Jādomā būs kaut kas cits.

* – diffuse tekstūra (3 x 8 biti), lightmapes tekstūru koordinātas (2 x 16 biti), normālmape + specularmape ((3 vai 4) x 8 biti). Max. 2 x 8 biti (2 kanāli) paliek brīvi, bet tas pat īsti nemaina nepieciešamību pēc šādu formātu tekstūrām.