Se pare ca s-a schimbat ip-ul de pe serverul unde l-am uploadat, sper sa rezolv azi sau maine
Deliverance a scris:
Uite ca am si eu unele intrebari, n-am reusit sa-l downloadez(inca) dar:
-> Ai spus BSP + portaluri pentru partitionare spatiala. Ce ai folosit exact: portal based culling sau PVS?
Amandoua, PVS se foloseste pe server pentru o verificare foarte rapida dar nu foarte precisa ptr a vedea ce trebuie trimit fiecarui client, ce e potential vizibil pentru el doar aia i se trimite.
EVS ( exact visibility set ) folosesc pe client pentru rendarea doar a ce se vede ( pana la nivel de pixel ). Pentru asta folosesc doar portalele generate folosind BSP la compilarea hartii, dar arborele BSP propriuzis e folosit doar la collision detection.
-> Arborele BSP este construit sau incarcat dintr-un format cum ar fi cel folosit de quake? (.bsp) Daca da, ce complexitate de constructie aveti, folositi euristici pentru echilibrarea arborelui?
E construit dintr-un algoritm probabil ca cel din quake, l-am citit dintr-un articol care se referea la quake.Dar a suferit multe modificari de atunci...
Complexitatea e greu de spus pe moment, dar voi incerca sa calculez.Arborele trebuie creat de mai multe ori ptr eliminarea geometriei care nu se vede si ptr plasarea portalelor unde trebuie.
Pentru creare folosesc doar principiul minimului de taieturi, rezulta un arbore nu foarte echilibrat dar cu putine taieturi in geometrie (doar acolo unde sunt portaluri). Se poate umbla la functia respectiva ptr a da un arbore mai echilibrat dar cum nu este deloc adanc e mai bine asa.
-> Daca ai folosit portal based culling ai generat automat portalele sau manual?
E un fel de combinatie, ele se genereaza automat, dar trebuie limitat modul si locurile in care se genereaza, spunandu-i unde sa NU fie generate. Vorbeam cu tipul care trebuia sa ne faca hartile,el lucrand cu editoare din astea, si el imi spunea ce ar avea nevoie si cum i-ar fi mai comod. Pana la urma depinde de cel care lucreaza cu editorul cum prefera, o sa pun o optiune sa alegi intre generare semi automata si plasare manuala.
-> Collision detection + sliding este? Daca da, poti sa-mi pui putin despre optimizari/algoritmul folosit pentru coliziuni?
Este collision , este sliding.
Insa daca intri intre 2 poligoane nu mai faci slide
. Nu e bug nici scapare, am scos pur si simplu asta pe moment fiindca nu functiona cum trebuie.
Pentru collision folosesc BSP-ul ptr geometria statica si un model de coliziune (format din boxuri) ptr modelele dinamice sau alea importate din max.
Algoritmul e cam asa: mai intai se verifica coliziunea cu geometria statica (aici intervine BSPul ). Dupa ce termin cu asta trec la modelele dinamice ( aici folosesc iar PVS, fiecare model avand un set cu sectoarele in care se afla, se face o verificare rapida daca obiectele sunt in acelasi sector , daca asta cade se face iar o verificare rapida cu bounding boxul ), daca testele astea cad atunci se trece la verificarea exacta a coliziunii box vs box sau ray vs box. (box vs box e la fel cu ray vs box dar se adauga un offset). Boxurile pot fi orientate.
-> Ma intereseaza in mod deosebit algoritmul de line of sight. Cum beneficiaza de pe urma bsp-ului, ce complexitate are?
Aici folosesc doar portalele, fara arbore. Pornesc de la frustumul initial si tai primul portal vizibil din sectorul curent cu frustumul, apoi creez alt frustum cu ce mai ramane din portal si trec prin portal in sectorul urmator reluand operatia ( in acelasi timp adaug intr-o lista toate sectoarele vizibile si fetzele vizibile din acele sectoare ). Dupa ce termin cu geometria statica iau obiectele dinamice la rand si verific sectorul/sectoarele in care se afla cu cele vizibile, daca sunt in sectoarele respective le verific si fata de frustumul cu care s-a ajuns in sectorul respectiv ptr a fi sigur ca sunt sau nu vizibile.
Folosesc o gramada de teste box vs frustum si projected scissor vs projected scissor test ptr optimizari.
La rendare desenez fiecare sector vizibil pe rand si pun un scissor in jurul portalului(bucatii de portal ramase) care a dus in acel sector, asa ca desenez doar ce e vizibil pana la nivel de pixel.
Cand o sa iei jocul sa ii dai din consola sa iti afiseze wireframe si scissorurile ptr portaluri si lumini ptr a vedea exact ce se intampla.
Cum adica soft shadows? Din cate am inteles faci un texture lookup pentru aproximarea functiei de iluminare, un model dinamic ar trimite soft shadows ?
Nu sunt soft shadows dinamice, umbrele sunt precalculate si puse intr-o textura ( sa zicem cube map, merge si cu map 2d daca toate directiile sunt la fel ), textura asta o inmultesti cu rezultatul functiei de iluminare. Sunt cateva locuri unde e folosit in hartile din demo, am pus de exemplu un ventilator in plafon (care nu lasa umbre dinamice), iar lumina care bate din spatele lui proiecteaza o textura cu imaginea ventilatorului si prin triggere o fac sa se invarta la fel cu ventilatorul, e un efect foarte cool
O metoda mai buna ptr fake soft shadows care e folosita si in filmele de unreal engine 3 si zic ei ca sunt soft shadows (vrajeala
) e sa folosesti 2 cubemapuri cu umbrele, unul normal si altul bluruit si sa interpolezi intre ele.
Pentru soft shadows dinamice folosesc shadow buffere in loc de stencil (desi nu se compara nici pe departe cu cele rezultate din iluminarea globala), dar in demoul asta nu sunt folosite (in viitor o sa inlocuiesc total stencilul cu shadow buffere).
