Haluan pystyä tuottamaan suuren joukon pieniä itsenäisesti liikkuvia esineitä reaaliajassa. Ne voivat liikkua parvella, mutta heidän suhteelliset asemansa eivät ole johdonmukaiset – heidän asemansa voi muuttua mielivaltaisesti parvessa ja parvet voivat hajota ja uudistua milloin tahansa.
Mikä lähestymistapa rajoittavan volyymihierarkian rakentamiseen sopisi parhaiten tähän tilanteeseen? tapa ylläpitää optimaalista huonompaa, mutta riittävän hyvää hierarkiaa, joka vaatii vain jokaisen kehyksen osittaisen päivittämisen? Vai onko olemassa tapa rakentaa hierarkia alusta alkaen jokaiselle kehykselle, joka on riittävän nopea sujuvalle animaatiolle?
Kohteiden lukumäärä on liian suuri renderöimättä ilman hierarkiaa, mutta samasta syystä uskon hierarkian rakentamisen vievän aikaa.
John Calsbeekin kommentin jälkeen, jos keskittyminen volyymihierarkioiden rajoittamiseen on harhaanjohtavaa, ja tähän tilanteeseen on parempi lähestymistapa avaruusosioihin vastaamaan vastaavasti. Etsin jotain, joka pystyy käsittelemään kuvaamani, mukaan lukien kaikki mitä en ole ajatellut.
Kommentit
- Rajoitatko tarkoituksella kysymys rajoittavista äänenvoimakkuushierarkioista vai oletko avoin muille alueelliselle osioinnille?
- @JohnCalsbeek I ’ muokattu selventämään – kiitos, kun osoitit tahaton rajoitus.
- Harkitse ” -parven ” käsittelemistä yhtenä yksikkönä, kun parvet sulautuvat; Yhdistä ne yhdeksi parveksi, kun yksinäinen vaeltaa kauas, siitä tulee ” parvi ”. Tämä toimii parhaiten, jos parvet ovat yleensä yhtenäisiä ja yksinäiset yleensä harvinaisia. ” -parvella voi pelata paljon siististi, sillä se on yksi yksikkö ”, kuten sallimalla jäsenten vaihtaa parvia vain, kun he ovat kosketuksissa toistensa kanssa, luettelo jatkuu ja jatkuu.
Vastaa
Harkitse erityisesti spatiaalisen hajautuksen käyttöä. jos kohteesi ovat samankokoisia.
Jaa periaatteessa maailmasi yhtenäisen kokoisiksi ruudukkosoluiksi (2D ja 3D ovat molemmat kelvollisia mahdollisuuksia pystysuuntaisen liikkeen määrästä riippuen). Jokainen päivitys, määritä objekti jokaiselle lokerolle, jonka se limittää – jos solut ovat kohtuullisen kokoisia objektien suhteen, useimpien kohteiden tulisi päätyä yhteen lokeroon.
Jokainen lokero lisätään hash-taulukkoon, avaimen ollessa roskakorin koordinaatit. (Voit myös ajatella sitä hash-taulukoksi, jossa on useita arvoja samalle avaimelle ja joka lisää objektin kerran jokaiselle solulle, jonka se on päällekkäinen.)
Tässä järjestelmässä ei ole uudelleenrakennettavaa hierarkiaa, mikä tekee siitä sopivan hyvin dynaamisille kohtauksille. Voit silti testata solun mitat rungolla tai tukkeilla karkealla tasolla ja hylätä useita esineitä kerralla. Lisäksi on helpompaa hallita tätä rakennetta vähitellen – voit pitää hash-taulukon saman kehyksestä toiseen ja siirtää objekteja roskista toiseen vain, kun ne ylittävät solun rajan.
Vastaus
Voit yrittää yksinkertaisesti tehdä rajoittavista äänenvoimakkuuksista hieman suurempia kuin on välttämätöntä, jotta objektit eivät ylitä rajojaan joka liikkeellä, mutta sitten taas, joudut rakentamaan rakenteen uudelleen nyt ja sitten.
Tai on olemassa Rajaintervallihierarkia , joka yrittää puuttua juuri tähän skenaario.
Tai Ingo Waldin, Solomon Boulosin ja Peter Shirleyn artikkeli Deformoituvien kohtausten säteen jäljitys käyttämällä dynaamisia rajoittavia volyymihierarkioita saattaa olla kiinnostavaa.
Vastaus
Haluaisin lisätä tähän käytännön näkökulman.
Anna minulle esipuhe, että en käytä rajoitettuja tietoja täällä:
- En tiedä kuinka m kaikki kohteet, joita olet tekemisissä.
- En tiedä mihin kiihtyvyysrakennettasi tarkalleen käytetään. Frustumin teurastus? Säteen jäljitys? Törmäystunnistus BVH: n kohteiden välillä?
Jatkossa oletan, että puhut frustumin muutamien tuhansien esineiden teurastamisesta.
Objektien määrä on liian suuri hahmonnettavaksi ilman hierarkiaa, mutta samasta syystä uskon hierarkian rakentamisen vievän aikaa.
Väitän, että jos sinun täytyy käydä jokaisessa objektissa jokaisessa kehyksessä BVH: n laskemiseksi, niiden tappaminen suoraan ja ilman BVH: ta on todella nopeaa. Tämä riippuu tietysti teidän frustumin teurastuksesta. Kaikkien objektien rajaavat tilavuudet tulisi tallentaa vierekkäin muistiin. Tämä johtaa tehokkaampaan suorittimen välimuistin käyttöön ja mahdollistaa optimoinnin edelleen SIMD-ohjeiden avulla. DICE: lla on koko esitys tästä aiheesta: Battlefieldin tuhoaminen: tietoihin perustuva suunnittelu käytännössä
Esityksessä mainitaan myös nopeampi teurastaminen vielä enemmän yksinkertaisen ruudukon avulla.
Koska oletan, että useimmilla 3D / simulaatio- / pelikoodipohjoilla on jo jonkinlainen BVH-luokka ja en tiedä kuinka kriittistä on saada paras teurastusteho, haluaisin esittää joitain argumentteja BVH: n noudattamiseksi:
Rakentaminen riippuu käytetystä menetelmästä BVH voi olla nopea ja yksinkertainen.
Nykyinen binäärisen BVH-sovellukseni (kussakin solmussa voi olla vain nolla tai kaksi lasta ja kukin lehtisolmu tallentaa vain yhden kohteen), joka on suunniteltu nopeaan rakentaminen vie noin 0,18 ms 1137 objektille i7-5960X @ 3,89 GHz: n yhdellä langalla. Olen varma, että se voi olla nopeampi. Rakentaminen tapahtuu jakamatta muistia prosessissa (tämä kaksinkertaisti rakentamisen suorituskyvyn).
Vaikka SAH saattaa tuottaa parhaan BVH: n, se kestää kauan. SAH on hyvä asioille, jotka voit laskea ennakolta, kuten törmäysverkot. Ajon aikana voit laittaa törmäysverkot BVH: hen, joka soveltuu paremmin reaaliaikaiseen rakentamiseen.
Nopea ja yksinkertainen BVH-rakentamismenetelmä (I ”m käyttäen tällä hetkellä” on lajitella kaikki akselin objektit (esimerkiksi ylätason AABB: n pisin akseli) ja jakaa kokoelma keskelle.
Voit nopeuttaa asioita entisestään laskemalla solmun AABB: t. Puun rakentamisen jälkeen yhdistämällä vanhemman solmun kaksi alisolmun AABB: tä. Näin vältetään iterointi kaikkien objektien läpi (toinen kaksinkertainen nopeus). Tämä on kuitenkin mahdollista vain, jos jakokriteerisi ei perustu vanhemman AABB: hen. / p>