Kõik korterite remondi ja kaunistamise kohta

Kuidas me World of Warshipsi teeme: ekspordi automatiseerimine ja sisu kontrollimine. BigWorld Engine – Mängumootorid – Failid mänguarendajatele – Mänguarendus Sisueelarved ja part vannitoas

Kas teil on probleeme konkreetse video leidmisega? Siis aitab see leht leida video, mida nii väga vajate. Töötleme teie taotlusi hõlpsalt ja anname teile kõik tulemused. Olenemata sellest, mis teid huvitab ja mida otsite, leiame teile vajaliku video hõlpsalt, olenemata sellest, mis suunas see oleks.


Kui tunned huvi päevakajaliste uudiste vastu, siis oleme valmis pakkuma Sulle hetkel kõige asjakohasemaid uudisteateid igas suunas. Jalgpallivõistluste tulemused, poliitilised sündmused või maailm, globaalsed probleemid. Kui kasutate meie imelist otsingut, olete alati kõigi sündmustega kursis. Meie pakutavate videote teadlikkus ja nende kvaliteet ei sõltu meist endist, vaid nendest, kes need Internetti üles laadisid. Pakume teile ainult seda, mida otsite ja vajate. Igal juhul saate meie otsingut kasutades teada kõiki maailma uudiseid.


Maailma majandus on aga ka üsna huvitav teema, mis teeb paljudele muret. Päris palju sõltub erinevate riikide majanduslikust seisust. Näiteks import ja eksport, mis tahes toit või seadmed. Sama elatustase sõltub otseselt riigi olukorrast, samuti palkadest jms. Kuidas saab selline teave kasulik olla? See ei aita teil mitte ainult tagajärgedega kohaneda, vaid võib teid ka hoiatada ühte või teise riiki reisimise eest. Kui olete paadunud reisija, kasutage kindlasti meie otsingut.


Tänapäeval on väga raske mõista poliitilisi intriige ja olukorra mõistmiseks tuleb leida ja võrrelda palju erinevat teavet. Seetõttu leiame teie jaoks hõlpsasti riigiduuma saadikute erinevaid kõnesid ja nende avaldusi kõigi viimaste aastate kohta. Saate hõlpsasti aru poliitikast ja olukorrast poliitilisel areenil. Sulle saavad selgeks erinevate riikide poliitikad ja saad end saabuvateks muutusteks hõlpsalt ette valmistada või meie tegelikkusega kohaneda.


Siit leiate aga mitte ainult erinevaid uudiseid üle kogu maailma. Samuti leiate hõlpsalt filmi, mida on õhtul õllepudeli või popkorniga mõnus vaadata. Meie otsinguandmebaasis on kilesid igale maitsele ja värvile, leiate hõlpsalt enda jaoks huvitava pildi. Leiame teie jaoks hõlpsasti isegi vanimad ja raskesti leitavad teosed, aga ka tuntud klassikud nagu Star Wars: The Empire Strikes Back.


Kui soovite lihtsalt veidi lõõgastuda ja otsite naljakaid videoid, siis saame ka siin teie janu kustutada. Leiame teile miljon erinevat meelelahutuslikku videot üle kogu planeedi. Lühikesed naljad rõõmustavad teid kergesti ja lõbustavad teid terveks päevaks. Mugava otsingusüsteemi abil leiate täpselt selle, mis teid naerma ajab.


Nagu juba aru saite, töötame väsimatult selle nimel, et saaksite alati täpselt seda, mida vajate. Oleme selle imelise otsingu loonud spetsiaalselt Sinu jaoks, et saaksid video kujul vajaliku info üles leida ja seda mugavast pleierist vaadata.

Selles väljaandes jätkame küsimuste esitamist mänguarendajatele. Seekord annab intervjuu ettevõtte projekti "" tehniline direktor Mihhail Živets Wargaming.net.

NVIDIA MAAILM: Millist graafikamootorit teie projektis kasutatakse? Millised on minimaalsed ja soovitatavad süsteeminõuded? Kas need on tingitud teatud funktsioonidest või keskendusite 3D-kaartide teatud levimuse tasemele? Kas kasutate uusimate põlvkondade graafikakaartide juurdepääsetavuse funktsioone või järgite standardeid?

Projekt World of Tanks kasutab BigWorldi graafikamootorit oma modifikatsioonidega, mis tuli teha projekti spetsiifikast tulenevalt. Mootori eripäraks on keskendumine avatud maailmadele, millel on dünaamiliselt laaditud kaardi osad, nagu seda tehakse näiteks World of Warcraftis. Püüame kasutada tehnoloogiaid, mis võimaldavad luua monitori ekraanile pilti, mis on lähedane meie kunstnike visanditele ja kohandada neid süsteeminõuetega.

NVIDIA MAAILM: Kas NVIDIA ja ATI videokaardid erinevad programmeerimise poolest oluliselt? Kas on võimalik kirjutada lihtsalt läbi DirectX-i või OpenGL-i ja hankida mõlema müüja jaoks tõhus kood või peate iga tarnija jaoks funktsioonidest oma versioonid tegema? Millist lähenemist kasutasite?

M.J.: Erinevate tootjate videokaartidel on oma eripärad. See võib olla spetsiaalsete tekstuurivormingute tugi või tekstuuridele juurdepääs tipuvarjurist. Samal ajal on DirectX-i või OpenGL-i API-de pakutavate ühiste funktsioonide kasutamisel erinevused kahe tootja GPU-de vahel minimaalsed ning ATI ja NVIDIA videokaartide erinevuse tõttu on lisafunktsioone rohkem. kui mis tahes piirangud. Mis puutub mootoripoolsesse "erikohtlemisse", siis BigWorld ei anna ühelegi müüjale otsustavat eelist.

NVIDIA MAAILM: Mis on NVIDIA ja ATI kaartide mängude kiiruse erinevuste põhjused? Kas see on mängumootori algoritmide omadus või sõltub see rohkem mängustseenidest? See tähendab, et näiteks ühes mängus on rohkem high-poly stseene ja teises on suur overdraw indikaator või palju poolläbipaistvaid tekstuure koos keeruka antialiasinguga ja seetõttu saavad suurema täitmissagedusega videokaardid paremini hakkama? ("Kas teie programmile meeldis mis tahes arhitektuur?").

M.J.: Erinevused taanduvad peamiselt riistvaralistes omadustes (erinevused mälusiinide laiuses, rasterdamise ühikute arv, varjutusühikud jne), aga ka draiverite teostuses. Mida tasakaalustatum on protsessori ja GPU koormus ning mida paremini on stseen organiseeritud, seda vähem peaksid videokaardi funktsioonid üldist jõudlust mõjutama. See hõlmab hoolikat suhtumist tekstuuride arvu ja eraldusvõimesse, osakeste ja läbipaistvate objektide väikest ülevõtmist, LOD-de kasutamist, objektide partiidesse rühmitamist ja nii edasi - kõik see langeb võrdselt nii mootoriarendajate kui ka mängudisainerite õlgadele.

NVIDIA MAAILM: Videokaartide testimisel kasutatakse reeglina ligikaudu samu mängukomplekte. Kui kohane on selline üldistus, kui kuvatakse testitulemused selliste erinevate žanrite jaoks nagu 3D-laskjad, kolmanda isiku RPG-d ja strateegiamängud. Kas populaarsed võrdlusnäitajad näitavad teie mängu jõudlust?

M.J.: Ma ei jagaks taotlusi žanri järgi. Kõik on eranditult nende kasutatavate algoritmide arendajate kätes. Igal juhul püüavad arendajad laadida kasutaja süsteemi võimalikult tasakaalustatult ja saavutada samal ajal toote maksimaalse atraktiivsuse.

Vaadates FPS-i numbreid sellistes mängudes nagu Crysis või uusim Need for Speed, võite umbkaudu ette kujutada mitmete teiste kaasaegsete mängude jõudlust, nii et siin võime täie kindlusega öelda, et need testid on üsna paljastavad. Selle taseme mänge saab kasutada videokaartide etalonidena, kuna kõrge kvaliteediga seadete korral laadivad need graafika alamsüsteemi maksimaalselt.

NVIDIA MAAILM: Mis on CPU koormuse suurenemise põhjus eraldusvõime suurenemisega? Kas on tõsi, et mudelite detailsuse suurendamine nende "nurksuse" minimeerimiseks nõuab rohkem protsessori võimsust animeerimiseks, nähtamatute primitiivide lõikamiseks, varjude mahtude ehitamiseks jne? Kas teie mängus oli selline efekt?

M.J.: Eraldusvõime suurendamine ei tohiks protsessori koormust otseselt mõjutada, välja arvatud juhul, kui mootor näeb loomulikult ette mudelite polügonaalsuse automaatset suurendamist, täiendavat tessellatsiooni ja rohkem mudelianimatsiooni kaadreid. Kui eraldusvõime suurenedes CPU koormus põhjuseta suureneb, peitub probleem kas mängukoodis või videokaardi draiveris.

NVIDIA MAAILM: Kas protsessori koormus võib suureneda, kui anisotroopne filtreerimine on lubatud? Sama kehtib ka Full Scene Antialiasing'i kohta. Kui selleks on vaja kogu stseeni joonistada kahekordse eraldusvõimega, siis teoreetiliselt võib ka kolmnurkade arv suureneda.

M.J.: Vastus mõlemale küsimusele on eitav. Kui anisotroopne filtreerimine on lubatud, suureneb tekstureerimisüksuste koormus. Kui FSAA on lubatud, teeb pikslite konveier rohkem tööd. Mis puutub kõrgemasse eraldusvõimesse, siis pikslite arvu kahekordistamine suurendab toimingute arvu pikslivarjutajas, rasteriseerijates ja TMU-des.

NVIDIA MAAILM: Arvutuste ülekandmine GPU varjutajatesse on kestnud väga pikka aega, algul oli see T&L, kärpimine. Kas GPU mudelite animatsioon läheb nüüd arvesse? Mis kõigepealt jääb 3D-mootori jaoks protsessori arvutuste jaoks alles? (Mille peale T&L-i GPU-le arvestasite?).

M.J.: Meie projektis kasutatav mootor ei teosta GPU-ga mingeid arvutusi. Teoreetiliselt, kui me peaksime näiteks paljude objektide füüsikat reaalajas arvutama, võiksime võtta sama PhysX , mis teeb suurepäraseid arvutusi NVIDIA GPU-l, kuid projekti spetsiifika tõttu on meil piisavalt protsessori võimalusi.

NVIDIA MAAILM: Viimastel aastatel on videokiirendid muutunud "intelligentseks", nad ise kasutavad nähtamatute primitiivide äralõikamise meetodeid, näiteks: hierarhiline z-puhver. Kui tõhusad need on? Kas nüüd on võimalik kõik kolmnurgad lihtsalt videokiirendisse pista, et see kõik ise joonistaks? Esimeste 3D-mängude (seeria Quake ja Unreal) päevil kasutati renderdatud kolmnurkade, BSP-puude jms vähendamiseks keerukaid meetodeid. Kui asjakohane see praegu on?

M.J.: Muidugi ei tohiks loota sellele, et videokiirendi määrab iseseisvalt, millised objektid on renderdamist väärt ja millised mitte nähtavad. Peame rakendama ebavajaliku varajase katkestamise tehnikat, kuna üleliigse teabe edastamine GPU-le toob kaasa jõudluse languse. Seega on probleem endiselt aktuaalne, kuigi palju vähemal määral. Eriti juhtudel, kui peate joonistama suur number erinevaid objekte. Fakt on see, et tänapäevased kaardid ei tegele mitte ainult ebavajaliku äralõikamisega, vaid need on koormatud ka keerukamate valgustustüüpide arvutustega jne. Seega, kui on võimalus ja vahendid videokaardi abistamiseks, tuleks seda teha.

Näiteks BigWorldi mootoris kasutatakse nähtamatute objektide lõikamiseks enne joonistamisetappi Umbra teeki. Stseen on BSP-puu, mis võimaldab kiiresti ja tõhusalt ära visata stseenifragmendid, mis ilmselt ei kuulu ulatusse.

NVIDIA MAAILM: Omal ajal oli umbes P4 kriisi ajal selline olukord, et süsteemi kitsaskohaks oli protsessor, mis ei suutnud videokiirendit “laadida” ning mängudes FPS-i tõstmiseks ennekõike tippu. -end CPU mudel oli nõutav. Kas protsessori ja graafikaprotsessori vahel on praegu sarnane suhe või on protsessorid ületanud teatud kriitilise jõudluse taseme ja kas võite võtta odava protsessori ja võimsa videokaardi? See viitab mängudele, mille rõhk on graafikal, stiilis nagu Quake ja Doom.

M.J.: Nõrk protsessor koos võimsa videokaardiga on süsteemi kitsaskoht, kuna paljud toimingud, nii madala taseme (juhtkäskude voo moodustamine juhi poolt) kui ka kõrgetasemelised (rakendusloogika - mängutsükkel, osakeste värskendus, tegelane animatsioon, füüsika, heli jne) sõltuvad otseselt protsessori jõudlusest. Olulist rolli mängib ka protsessori vahemälu suurus, mis on odavatel mudelitel üsna väike.

Videokaardi tõhusaimaks tööks on vaja ka süsteemiressursse, kiiret süsteemisiini ja piisavas koguses hea kiirusega RAM-i. Sageli ei suuda video alamsüsteem näidata, milleks ta võimeline on lihtsalt seetõttu, et protsessoril pole aega vajalikke andmeid sinna üle kanda. Seega, kui rääkida ressursside säästmisest, piisab keskmise protsessori ostmisest, emaplaat veidi üle keskmise, kuid ärge koonerdage graafikakaardi ja RAM-iga.

NVIDIA MAAILM: DirectX versioonist versioonini on muutumas üha enam graafikamootoriks. Kas vastab tõele, et tänapäeval koosneb 3D programm praktiliselt Direct3D API kõnedest ja enamus arvutusi tehakse selles? Kuidas hindate Uusim versioon DirectX? Kas sellest on saanud peaaegu täieõiguslik mootor ja mitu versiooni selleks veel vaja on?

M.J.: Direct3D-d ei saa pidada eraldiseisvaks graafikamootoriks ja on ebatõenäoline, et Microsoft astub lähitulevikus oma mängumootori loomise sammu. See on ebapraktiline mitmel põhjusel, sealhulgas paljude erinevate mänguprojektide mootorinõuete erinevuste tõttu. Näiteks autosimulaatoril, reaalajas strateegiamängul ja 3D laskuril on iseloomulikud omadused, mis ei võimalda sama mootorit kõigil kolmel juhul võrdselt tõhusalt kasutada.

Direct3D kümnes versioon tõi ressurssidega töötamisel kasutusele uued abstraktsioonitasemed ja lisavõimalused varjutajate arendamiseks, näiteks said kättesaadavaks sellised nipid nagu Stream Output. Samas on D3D jäänud samaks, mis ta oli – madala tasemega API, mille abil saab arendaja konkreetse ülesande jaoks mängumootori kujundada.

NVIDIA MAAILM: Üldiselt on viimasel ajal toimunud mängude ja 3D-mootorite "globaliseerumine". Seal on mõned kõige populaarsemad platvormid, millel tehakse palju mänge. Kas see on objektiivne protsess? Kas arendajal on praegu mõtet kirjutada oma mootor, kui saate litsentsida valmis täisfunktsionaalsele mootorile. Näiteks ilmus hiljuti järgmine Unreal Engine'i versioon, mida on alla laaditud juba kümneid tuhandeid kordi. Kui kaua on aega hetkeni, mil kõik mängud hakkavad kasutama ühte või kahte 3D-mootorit?

M.J.: Kasutame BigWorldi ja oleme sellega siiani rahul. Mis puutub "globaliseerumisse", siis on ebatõenäoline, et juhtub ime ning CryTek, Epic ja hulk teisi otsustavad üksteisele tüki mängumootorite turust kinkida. Ärge unustage, et reeglina on sama mootoriga loodud mängud väga sarnased ja see pole alati hea. Tõenäoliselt kasvab mootorite arv ainult üha kitsama spetsialiseerumisega. Igal juhul on alati ainulaadsed mootorid.

NVIDIA MAAILM: Kas on tõsi, et uusimad videokaardid on toore võimsuse poolest muutunud väga võimsaks ja, erinedes varasematest mudelitest efektide poolest, võivad paljastada oma potentsiaali ennekõike suurte monitoridega (alates 1920x1200) süsteemides anti- aliasing ja täielik anisotroopne filtreerimisrežiim? Kas inimesel, kellel on nt 1280x1024 monitor, kes ei ole filtreerimise ja AA fänn, on mõtet osta uus videokaart, näiteks GTX285 ja Radeon uuel protsessil?

M.J.: Olen nõus, nii on. Kuid sellegipoolest ärge unustage korralikke monitore, millel on piisav värvikvaliteet, kõrge eraldusvõime, kontrastsus. Saate mängust palju rohkem naudingut. Kuid isegi kui otsustate oma lemmikmonitori mitte vahetada, tasub kaart välja vahetada, sest see suurendab kindlasti teie süsteemi jõudlust, kuna osa vanu arvutusalgoritme uutel kaartidel on juba riistvaras realiseeritud.

NVIDIA MAAILM: Varem olid mänguarendajad uusimate graafikakaartide funktsioonide ja efektide kasutamisel konservatiivsed, kuna keskendusid hetkel kõige tavalisematele kaartidele. See tähendab, et näiteks tingimuslik DirectX n tuleb välja ja mänge kirjutatakse endiselt DirectX n-2 all. Kas olukord on viimasel ajal muutunud? Kas hiljuti välja antud videokiirendite uusi efektivõimalusi on mängus lihtne kasutada?

M.J.: Kui Windows 7 oleks välja tulnud paar aastat varem või Microsoft oleks loobunud mõttest siduda DirectX 10 Windows Vistaga, oleksid mänguarendajad juba ammu üle läinud API kümnendale versioonile. Nüüd on meil aga see, mis meil on: kõik hitid Viimastel aastatel kasutada DX9 ja DX10 tugi on sageli turundustrikk.

NVIDIA MAAILM: Kui intensiivselt kasutavad mängud tavaliselt uusimate, väljalaskehetke videokiirendite võimsust? Näiteks, kas praegu kasutatakse GT200 arhitektuuri kõiki võimalusi? Kas see on tüüpiline olukord, kui väljalaske hetkel täidab uus GPU lihtsalt olemasolevaid mänge veidi paremini, kuid aja jooksul, kui mänge optimeeritakse uue arhitektuuri jaoks ja rakendatakse uusi funktsioone, tundub selle väärtus kasvavat? Kui palju teie mäng uusi funktsioone kasutab?

M.J.: Uue arhitektuuri ja selle ühtse varjundi mudeli puhul on võitnud peaaegu kõik. GPU tipu ja pikslite torujuhtmete töökoormus ühtlustus seal, kus ühes või teises suunas esines suuri moonutusi. Mis puutub uutesse funktsioonidesse, siis mida suurem on teatud funktsiooni toega videokaartide protsent, seda meelsamini kasutavad mänguarendajad neid oma projektides. Meie kasutatav BigWorld põhineb DirectX 9 ja SM 3.0 võimalustel.

NVIDIA MAAILM: Nüüd on võrgumängud muutunud väga populaarseks. Kas see on jätnud oma jälje videokiirendite tööstusele? Kuna selliste mängude mootorid on keskendunud põhifunktsioonide komplektile, mis suurel hulgal kasutajatel on, ja FPS-i piirab endiselt internetiühendus, tundub mõttetu osta võrgumängude jaoks tipptasemel videokiirendit. Kas see on mängugraafika arengu pidur? "Täis 2D" brauserimängud, mis ei vaja kiirendit, on populaarsemaks muutunud.

M.J.: Kui vaadata World of Warcrafti tellijate arvu ja võrrelda seda näiteks Aioni või Age of Conaniga, on vastus ilmne: võrgumängude puhul mänguviis, mängumaailma areng, põnev PvP komponent ja graafika jaoks on esmajoones olulised muud hetked, mis pole otseselt seotud. See ei pidurda graafika arengut, sest mängijad ei ela MMORPG-des üksi. Uued laskurid, sõidusimulaatorid ja RPG-d tõstavad paratamatult mängude 3D-graafika kvaliteedi latti. MMO-mängud liiguvad aeglaselt, kuid kindlalt samas suunas, eesmärgiga meelitada ligi suuremat mängupublikut. Muide, seesama Blizzard töötab nüüd kuulduste kohaselt uue MMOG-i kallal ja on ebatõenäoline, et nad oma uues projektis 8 aastat vana mootorit kasutavad.

NVIDIA MAAILM: Mil määral vajavad SLI ja Crossfire tehnoloogiad mänguarendaja tuge? Mis on nende tehnoloogiate erineva efektiivsuse põhjuseks erinevate mängude puhul? Kas mängumootori funktsioonidega või mängustseenidega? Kui palju kasu saab teie mäng SLI ja Crossfire'i kasutamisest?

M.J.: Mootori optimeerimine kahe videokaardi jaoks on väga keeruline protsess. On vaja hoolikalt korraldada kompaktne andmeedastus GPU-le ja tasakaalustada mootorit GPU ja CPU vahelise koormuse osas. Kui rakendus toetub ühe kaardiga töötades juba protsessorile või andmeedastusse üle siini, peate unustama SLI või Crossfire'i. See on tegelikult see, mis eristab teatud mänge paaritud kiirenditega töötamisel. Meie mäng suurendab SLI-s jõudlust umbes 10%, kuid nüüd optimeerime mitmeid mooduleid, et sellistes režiimides jõudlust parandada.

NVIDIA MAAILM: Pikka aega on palju räägitud arvutituru kriisist ja mängude järkjärgulisest üleminekust konsoolidele. Kuid seda pole veel juhtunud. Kas seda on tulevikus oodata? Kas vastab tõele, et standardse riistvara tõttu on digibokside graafika programmeerimine palju lihtsam? Või tasandab digibokside igavene mahajäämus "raua" taseme osas ühtlust?

M.J.: Mängukonsoolidel on arendaja jaoks mitmeid eeliseid (üks platvorm, üks funktsioonide komplekt ja sellest tulenevalt sama jõudlus kõigile mängijatele), kuid arvutimängude ja eriti võrgumängude turg kasvab pidevalt, nii et te ei tohiks oodata üldist üleminekut konsoolidele.kulud. Ärge unustage, et võimsama riistvaraga mängukonsoolide väljaandmist hoiavad tagasi konsoolitootjad ise, püüdes praeguste mängude müügi kaudu hüvitada eelmise põlvkonna konsoolide väljalaskmise kulusid. Seetõttu läheb enne Playstation 4 või Xbox 720 väljaandmist palju aega ja ilmub palju projekte, mis on keskendunud praeguse põlvkonna konsoolidele. Mõnel juhul, näiteks Nintendo Wii puhul, on täiustatud riistvara suurepäraste tulemuste saavutamiseks täiesti ebavajalik.

NVIDIA MAAILM: Kas on tõsi, et mängudes kasutatakse nüüd peaaegu üldiselt kombinatsiooni projektsioonimeetodist, et luua mudelitest varjud, ja varjude mahtude meetodit dünaamiliselt või staatiliselt arvutatud varjude mahtudega liikuvatel objektidel, mudelitel ja relvadel ning mudelite liikuvatest osadest enda peal. ?

M.J.: Varjumahtude asemel kasutatakse sageli sama projektsioonitehnikat koos modifikatsioonidega (kaskaadvarjukaardid, eraldi varjukaart isevarjutamiseks jne). Varjude mahud annavad terava varjuserva, kuid kannatavad kõrge täitekiiruse, täiendavate CPU arvutuste ja varjude pehmete servade keeruka rakendamise tõttu.

NVIDIA MAAILM: Kas olemasolevatel varjutusmeetoditel on tulevikku kogu stseeni dünaamilise valgustuse loomisel? See tähendab, et videokiirendite võimsuse järkjärgulise suurendamisega saab neid kasutada kogu valgustuse dünaamika arvutamiseks? Või on vaja uusi meetodeid?

M.J.: Projektiivsed varjud on tänapäevastes mängudes kaugele jõudnud ja mõningaid nende modifikatsioone kasutatakse veel pikka aega koos lisaefektidega, nagu SSAO. Muidugi, kui GPU-l on vaba kiirte jälgimine, pole projektiivsetel ega mahulistel varjudel mingit võimalust.

NVIDIA MAAILM: Kuidas hindate Precomputed Radiance Transfer tehnoloogiat mängudes rakenduse osas? Kas kavatsete seda tulevikus kasutada?

M.J.: PRT nõuab pikki arvutusi, ei ühildu animeeritud mudelitega ega anna põhimõtteliselt suuri visuaalseid eeliseid võrreldes sama Ambient Occlusioniga. Võtke näiteks Halo 3, mis kasutab PRT-d, kuid ei paista valguse kvaliteedi poolest silma võrreldes Gears of Wari või Crysisega.

NVIDIA MAAILM: DirectX 11 ja Fermi arhitektuur, kas tasub oodata DirectX 11 kiirendeid ja mänge või on tegemist API mööduva versiooniga? Kas kiirendi juunior DirectX 11 mudel, mis on halvem absoluutvõimsuselt, täitumiskiiruselt, võib olla parem kui vana, kuid võimsam DirectX 10 toega mudel? Kas Fermi arhitektuuri väljatulekuga võib oodata mingit kvalitatiivset hüpet mängugraafikas või on see ulatuslik kasv, rohkem kolmnurki, suurem kiirus kõrgete eraldusvõimetega jne? Kui Fermi oleks teie mängu väljatöötamise ajal saadaval, siis kui erinev oleks mäng graafika poolest?

M.J.: DirectX-i üheteistkümnes versioon pakub rohkem võimalusi GPU-l arvutamiseks, samas kui DX10-ga võrreldes ei too see 3D-graafikasse olulisi täiustusi. Mis puutub Fermi, siis minu arvates on kõige huvitavam funktsioon 3D-mudelite jaoks täielikult juhitud tessellatsioon.

Mihhail Živets, projekti World of Tanks tehniline direktor, Wargaming.net

Pärast World of Warshipsi esilinastust gamescomis ja IgroMiris on mängu ametlik lansseerimine aina lähemale ja lähemale. Suletud alfatestimine on nüüd täies hoos ja meie, Wargamingu Peterburi divisjoni Lesta Studio arendajad, peame veel lahendama terve hunniku probleeme. Samas suudeti paljud takistused siiski seljataha jätta. Allpool on lugu sellest, kuidas kohandasime oma mootori eksportijat laevade vajadustega ja ehitasime üles sisu kontrollimise protsessi.

Mootori standardvarustus

Iga mootor sisaldab tööriistakomplekti 3D-mudelite eksportimiseks 3D-redaktoritest oma andmevormingusse. Meie BigWorld, mille põhjal World of Tanks valmib, pole erand. See toetab eksporti 3D Maxist ja Mayast. Peaaegu iga mänguprojekt nõuab standardsete eksportijate kohandamist projekti spetsiifikaga. Meie projektis on laevamudelid spetsiifilised.

Maya kohandatud eksportija esimene versioon "koolitas" selle lihtsalt ära tundma laevastseeni keerukamat struktuuri. Olemasolevale C++ koodile lisati Pythoni juhtkood, samuti pistikprogramm Maya jaoks koos kasutajaliidesega wxWidgetis. See nägi välja umbes selline:


Kohandatud eksportija kasutajaliides

Saadud tööriistal oli palju puudusi.

Eksporti sai teha ainult kasutaja osalusel, kes pidi eksportijale "ütlema", mida stseen sisaldab. Selle tööriista kasutamine erinevate protsesside automatiseerimisel, näiteks sisu automaatsel kontrollimisel levitamise ehitusjärgus, ei tulnud kõne allagi.

Eksportija nõudis, et kasutaja teaks kaugeltki ilmselgetest parameetritest, töötas aeglaselt, praktiliselt ei toetanud stseeni kontrollimist ja nõudis ka tohutul hulgal ressursse.

Arhitektuur oli tulevikus funktsionaalsuse laiendamise peamine probleem. Eksport oli tegelikult tuumaoperatsioon (spagetifunktsioonide komplekt), mis tõlkis andmed ühest struktuurist (laaditud Maya stseen) teise struktuuri (BigWorld) otse füüsilistesse failidesse. Kui serialisaatorid ja äriloogika on rakendatud “monoliitses vormis” ja andmemudel lihtsalt puudub, siis ei ole võimalik lisada andmetöötlust (eel- ja järeltöötlust), aga ka taaskasutamist (koodi taaskasutamine) serialiseerijaid ja andmemudelit. muud tööriistad, mis rakendavad oma äriloogikat. Keerulisemaid sisutootmisprotsesse oli võimatu üles ehitada.

Aja jooksul muutus olemasolevale koodile uute funktsioonide lisamine peaaegu võimatuks. Otsustati eksportija nullist ümber kirjutada, pannes sellesse uue arhitektuuri.

karm igapäevaelu

Meie projekti tase on tõstnud nõudeid sisu kvaliteedile, keerukusele ja mahule. Meie stuudio on viimase paari aastaga kõvasti kasvanud. Nüüd on meil võimalus eraldada piisavalt ressursse sisutootmisega seotud ülesannete täitmiseks. Meie juurde tulid professionaalid, kellel on suurepärane C++/C# arhitektuuriarenduse ja tehnoloogiate taust. Samal ajal oli see eksportija arendajatele esimene Pythoni ja Maya API-de kasutamise kogemus. See tõi kaasa täiendavaid riske, millega tuli arvestada.

Eksportija ümberkujundamist hindasime kahe-kolme inimkuu pärast. Mänguarenduses ei saa ilma optimismita hakkama.

Oleme lisanud järgmised riskid:

Vorminõuete puudumine;
Pythoni teadmiste tase;
Maya API keerukus;
algoritmide ümbertegemine primitiivide töötlemiseks.

Palju tegelikku aega kulus nõuete kogumisele mitteametlikest allikatest, nagu juhiks saanud arendajad, vanad taimerid, torsioonväljad ja olemasoleva eksportija kood. Need teadmiste killud on Confluence'is vormistatud ja kirja pandud nõuete, spetsifikatsioonide ja UML-diagrammidena.

Esimesed prototüübid näitasid vajadust kasutada nimeruumide ja Pythoni moodulite kontseptsiooni (__init__.py). Samuti on välja töötatud mehhanism, mis võimaldab "läbipaistvalt" kasutada C ++ teekide (.pyd) funktsioone.

Maya API keerukusest ja keerukusest võiks kirjutada eraldi raamatus. Iga funktsionaalsus eeldas prototüüpide loomist, konsultatsioone 3D-kunstnikega ja mootori (renderdamise) arendajatega.

Tavalisel eksportijal oli oma rakendus suurel hulgal algoritme, näiteks hulknurkade trianguleerimine, pesastatud sõlmede teisendusmaatriksite arvutamine jne. Loobusime neist Maya API kasutamise kasuks, mis parandas oluliselt eksportija jõudlust.

On viimane aeg lisada Murphy seadustesse reegel, et iga teie väljamõeldud projekt viiakse kindlasti ellu mitte rohkem kui "x3" kavandatud ajast, kui te sellest ei loobu.

Tulemus oli meie tehtud pingutust väärt. Lõpuks leidis isegi meie peamine mudelite eksportimise eest vastutav kunstnik pärast paarikuulist tegutsemist, et meie eksportija on peaaegu täiuslik.

Vaatame kapoti alla

Meie stuudio kasutab aktiivselt Pythonis skripte. Üritasime kogu eksportija selle peale rakendada. Loomulikult ei sobi Python suurte binaarandmete töötlemiseks - näiteks tipukonteinerid (tipupuhver), tipuindeksi konteinerid (indeksipuhver) jne. Selliste konteinerite andmemudel ja jadaandmed realiseeriti C ++-s raamatukoguna (. pyd), mis sobivad loomulikult Pythoni andmemudeliga. Kogu äriloogika rakendati Pythonis.

Eksportija raamistikku plaaniti kasutada mitte ainult Maya "käsitsi" eksportimiseks, vaid ka mis tahes ülesannete jaoks, kus selle funktsionaalsust saaks taaskasutada, näiteks sisu kontrollimise automatiseerimiseks. Igast arendatud tööriistakomplektist nõuame Pythoni, käsurea (käsurida) ja kasutajaliidese tööriistade jaoks liideste (API) olemasolu.

Arhitektuur

Eksportija raamistiku arhitektuur on modulaarne, kihiline. Seal on füüsiline ja loogiline kiht, samuti domeenikiht. Iga kiht sisaldab eraldi mooduleid: andmemudel, äriloogika, serialisaatorid, aga ka muundurid, mis suudavad teisendada ühe kihi andmemudeli teise kihi andmemudeliks. Füüsilised ja loogilised kihid rakendavad tegelikult ORM-i arhitektuuri analoogi.

Domeenikihi arhitektuur on loodud andmemudeli mugavaks töötlemiseks äriloogika järgi. See on täielikult isoleeritud ega sisalda eeldusi selle kohta, kuidas see füüsilisse salvestusruumi järjestatakse.


Eksportija kihiline arhitektuur

Ekspordiprotsess

Kihiline arhitektuur tutvustab ekspordiprotsessi teatud funktsioone. Tegelikult deserialiseerime kahte (või enamat) mudelit erinevatest allikatest (Maya ja BigWorld Engine). Pärast seda liidetakse need mudelid üheks uueks. Järgmisena muudetakse uus mudel BigWorld-Engine-vormingusse.


Ekspordiprotsess

Paindlikkus sisu tootmisprotsessis

Rakendatud arhitektuur muudab keerukate sisutootmisprotsesside ülesehitamise üsna lihtsaks. Näiteks meie peamine laevamudel koosneb tehnoloogiliselt kolmest eraldi Maya stseenist, millest igaüks on samaaegselt arendatud erinevate osakonna poolt:

Esimene stseen sisaldab visuaalset mudelit ja kokkupõrkemudelit.
Teine vaatus sisaldab ballistilist mudelit.
Kolmas sisaldab efektide porte.

Lisaks sellele lisab (redigeerib) mootori tööriistakomplekt (toimetajad) tuletatud mootorivormingu mudelile oma andmed (neljas stseen).

Eksportija lahendab hõlpsasti mittetriviaalse ülesande ühendada kõik neli stseeni üheks saadud laevamudeliks.

Sisu kinnitamine

Sisu kontrollimise süsteem võimaldab otsida sisuvigu nii igast kihist (allikast) eraldi kui ka tekkivast sisust. Tõendajate arv ulatub praegu mitmekümneni. Automaatne sisukontroll on sisse ehitatud jaotamise ehitusprotsessi, mis võimaldab võimalikult suurel määral elimineerida inimteguri ning garanteerida sisu terviklikkuse ja tehnilise puhtuse.


Näide laevamudeli kontrollimisest Mayas

Sisueelarved ja part vannitoas

Sisu kontrollimise protsessi oluline osa on eelarvete kontrollimine, näiteks hulknurkade eelarvete kontrollimine. Alloleval joonisel on eelkõige teave kolmnurkade arvu kohta visuaalse mudeli jaoks iga koha jaoks:


Maya kasutajaliidese pistikprogramm

Sellise kontrollimise vajaduse ilmekaks illustratsiooniks on kolleegide jutt ühe varasema projekti kohta. Kaardil oli hävimatute majadega hoonestatud krunt. Niipea, kui kaamera oma pilgu sellele alale pööras, langes FPS kohe metsikult. Pärast probleemi uurimist selgus, et ühes majas oli vann, milles ujus väike “plastikust” part. Kõik see oleks tundunud kunstnike naljaka vembuna, kui mitte see, et pardimudel sisaldas umbes miljonit hulknurka.

Praktikas on eelarvelist väärtust väga raske järgida. Paljud mudelid on objektiivselt erandid. Ka eelarve väärtuse määramine vahemikuna ei lahenda probleemi, kuna aja jooksul hakkavad mudelite hulknurgad lihtsalt vahemiku ülemise väärtuse poole kalduma. Meie puhul plaanime muuta nende mudelite isiklikke eelarveid, mis ei vasta seda tüüpi mudelite standardeelarvele.

Sisu töötlemine

Ekspordi igas etapis on vajalik töötlemine (eel-/järeltöötlus). Näiteks enne Maya kihi loogilise andmemudeli teisendamist õhutõrjerelvade domeeni andmemudeliks tuleb relva skelett kõigepealt Y-teljel 45 kraadi pöörata ja skelett eemaldada. Meie arhitektuur võimaldas meil läbipaistvalt integreerida erinevaid töötlemisi ekspordi mis tahes etapis.




Mudeli näide enne ja pärast eeltöötlust

x64 tugi

Üsna hiljuti on meie artistid massiliselt migreerunud 32-bitise Maya 2012 pealt 64-bitise Maya versiooni peale 2014. Kuna eksportija on peaaegu täielikult Pythonis kirjutatud, ei olnud meil x64 toega peaaegu mingeid probleeme. Ainult C ++ keeles realiseeritud raamatukogu (.pyd) nõudis veidi "šamanismi".

Nüüd saab eksportijat hõlpsasti kasutada nii x32- kui ka x64-protsessides, kuna see määrab ise ja laadib C ++ teegi (.pyd) vajaliku koostu.

Kaardi kinnitamine

Eksportija arhitektuuri arendades ei osanud me ette ennustada, millistes muudes tööriistades ja automaatikates on võimalik seda taaskasutada. Kaardi kontrollimise automatiseerimine on näide sellest, kuidas "õige" eksportija arhitektuur leidis tee teise tööriista.

Kaardi kinnitamine koostab ja kontrollib kaardi sõltuvusgraafikut teistest sellel asuvatest objektidest. Eelkõige kasutatakse kaardil maastiku visuaalseid mudeleid (kivid, jäämäed), hooneid (majad, angaarid, jahisadamad), varustust (lennukid, paadid) jne.

Kaarditõendaja eripära on see, et see suudab eksportija raamistiku abil kontrollida mitte ainult visuaalsete mudelifailide olemasolu, vaid ka mudeleid endid. See välistas inimfaktori, kui kaardiarenduse osakond (LA) peab 3D-mudelite arendusosakonna (3D Art) "sõna võtma", et kasutatakse tehniliselt korrektseid mudeleid.

Distributsiooni ehitamine

Eksportija raamistik leidis kasutust ka levitamiseks sisupaketi ettevalmistamise protsessis. Jaotus ei tohiks sisaldada mudeleid, mis:

Ei ole enam kasutusel;
on veel väljatöötamisel;
mõeldud toote tulevaste versioonide jaoks.

Mänguobjektide põhiloendi (root game objects) järgi on vaja koostada sõltuvusgraafik, mille järgi genereeritakse täielik loetelu vajalikust sisust. Pole midagi lihtsamat kui mudeli deserialiseerimine eksportija raamistiku abil ja “välja selgitada”, milliseid muid mudeleid vaja on (sisuviited).

Tulemused

Meie eksportija arengulugu on näidanud, kuidas ta arenes lihtsast kõrgelt spetsialiseerunud tööriistast võimsaks süsteemiks, mis lahendab oma vahetuid ülesandeid, ning leidis rakendust ka muudes sisutootmisprotsessides. Selle eduka arendamise ja taaskasutuse aluseks on modulaarne arhitektuur, mis võimaldab kasutada selle üksikuid "kuubikuid" teiste süsteemide ehitamiseks.

Eksportijat ootab lähiajal ees veel üks BigWorld Engine failivormingu muutmisega seotud test. Oleme kindlad, et aluseks olev arhitektuur ei koge raskusi ja suudab töötada nii olemasoleva kui ka uue failivorminguga.

  • Žanri fookus: 3D MMO mis tahes žanrist;
  • Platvorm: PC, PS3, Xbox 360, iOS (iPad), veeb;
  • Programmeerimiskeel: C++, Python
  • Litsents: indie ja kommerts;
  • Avatud lähtekoodiga: ei ole ette nähtud või ette nähtud kõrgendatud tasu eest;
  • Mitmikmäng: klient-server;
  • Eelised: võimas, kõigi uusimate tehnoloogiate tugi, optimeeritud, iOS-i tugi, selliste funktsioonide jaoks odav;
  • Puudused: ei pakuta tasuta;
  • Mootori arendajad: Big World Tech Inc.

    BigWorld Engine on kõige arenenum 3D-mootor MMO-mängude loomiseks. See tegi selliseid mänge nagu "World of Tanks", "Pealm of the Titans" saidilt Wargaming.net ja muud mängud teistelt maailma mänguarendusettevõtetelt. Selle mootoriga on tehtud üle 15 MMO mängu. Selle on välja töötanud BigWorld Technology.

    Mootori optimeerimine võimaldab teil luua vähese nõudlusega mänge hämmastava graafikaga. Mootor võimaldab teil mänge iOS-i portida. C++ programmeerimiskeeles kirjutatud mänguloogika on realiseeritud mugavas Pythoni skriptikeeles. Seal on võimsad tööriistad ja klient-server mootor. Heli jaoks toetatakse FMOD-teeki ja kõik muud teegid on ühendatud pistikprogrammi kaudu. Töötab XML ja MySQL andmebaasidega. Tööriistakomplekt sisaldab võimsat maailmaredaktorit, mudeliredaktorit ja osakeste redaktorit.

    See on väga soodne. BigWorld: Indie Editioni koostamine maksab ainult 299 dollarit; BigWorld: Indie Source Edition – 2999 dollarit; BigWorld: Commercial Edition – kokkuleppel individuaalselt.

    See täiustatud mootor ei jää oma võimete poolest alla teistele seda tüüpi maailmamootoritele. Mootor on saadaval vene, korea, ameerika ja jaapani keeles. Dokumentatsioon on olemas, see võib brauserites töötada. Üldiselt saab tööle, kui on teadmisi ja hoolsust.

    See pole enam kolmanda osapoole litsentsimiseks saadaval, kuna Wargaming otsustas oma mootori levitamise lõpetada.

    Ametlik sait: http://www.bigworldtech.com





    BigWorldi tehnoloogia tööriistakett pakub täielikku ja täielikku MMOG-sisu loomise süsteemi, mis parandab teie mängu kvaliteeti ja ajakava. Kõik tööriistad on loodud mänguvarade koostööks tootmiseks suures meeskonnakeskkonnas, tagades tõhusa ressursside kasutamise ja sujuva sisujuhtme.

  • Sarnased postitused