Pelimoottoreista keskustelua (Unreal Engine, Unity, Source, jne)

mystikkogames sanoi:
Unityn kieli C# muistutti liikaa javaa.
Napsauta laajentaaksesi...
Lähes Java-vihaajana voin todeta, että kielenä C# on suosikkejani vaikka ulkoisesti muistuttaakin Javaa. Riippuu toki siitä, mistä et pidä Javassa, olisiko mielipiteesi C#:sta sama kuin Javasta.

mystikkogames sanoi:
Ja Unityn IDE miljoonine nappuloineen muistutti liikaa Blender 3D:n super paskaa GUI.
Napsauta laajentaaksesi...
En ole varma, tarkoitatko Unityn editoria vai ohjelmointi-IDE:ä, mutta ainakin jälkimmäiseen voi luonnollisesti käyttää mitä tahtoo ja esim. Visual Studio ja Visual Studio Code ovat käsittääkseni aika suosittuja vaihtoehtoja. Itse asiassa en oikeastaan keksi, miten tuo kuvaus voisi tarkoittaa itse Unityn editoria, koska siinä ei ole ihan hirveästi nappuloita, joten oletan, että tarkoitat ohjelmointi-IDE:ä.
 
mystikkogames sanoi:
Tulipas ensi kertaa katsottua video unishitistä. Unityn kieli C# muistutti liikaa javaa. Ja Unityn IDE miljoonine nappuloineen muistutti liikaa Blender 3D:n super paskaa GUI. Kaikki aika menee niiden pikkunapiskoiden painelemiseen, että saa ladattua uv-kartan jollekin asteroidille. Mikä tietysti näyttää aivan paskalta lopullisessa tuotteessa. Ja sitä saa säätää 1000h releasen jälkeen... Blender 3D:ssäkin on pelitila missä pisnes-koodia saa kirjoitettua pythonilla. Teoriassa se toimii. Mutta käytännössä saan nopeammin valmista kun otan assemblyn ja setpixel-metodin käyttöön. Tarvitsen pimeää huonetta unityn jälkeen enkä edes kirjoittanut riviäkään koodia :p.
Napsauta laajentaaksesi...

Juuh. Kyllä se käyttöliittymä-design aiheutti ihottumaa itsellekkin. Yritän vaan elää kyseisen ongelman kanssa ja oikeilla plugineilla saa sitäkin parannettua. :)
 
Katselin ihan 2minuuttia täältä -> Unity - Space Shooter tutorial
IDE muistutti liikaa blenderiä joten pysyn erossa.

Katsoin aluksi että joku koodaa Quaken tyhjästä. Loppujen lopuksi valtavasti paskanjauhantaa ja helloworld C:llä. Epäilen että kaverilla on suomalaiset sukujuuret huonon signal/noise ration takia :p
 
Nyt on GameGuru kokeiltu, ja aika äkkiähän siinä tuli seinä vastaan niinkuin joku aiemmin jo sanoikin.
Harmi vain, koska muuten kyllä olisi ollut ihan hyvä ohjelma.
 
En myöskään erityisesti pidä Unityn käyttöliittymästä, ja alkuhahmotus on jotenkin todella vaivalloista, vaikka tutoriaalejakin seuraisi. Space Shooter tutoriaalin aikanaan tein, jotain tankkitutoriaaliakin hetken, mutta jotenkin en silti kokenut pääseväni oikein yhtään sisälle - tuntui että liian paljon asioita pitäisi tarkemmin tietää, eikä kädestä ohjaavien videotutoriaalien seuraaminen sellaisenaan oikein napannut.

Humblebundlesta ostin Game Maker Studio 2 -creator lisenssin (vuodeksi), kun oli tarjouksessa ~15 euroa. 2D-peliohjelmointi onkin minua kiehtonut reilusti enemmän, ja se tuntuu paljon helpommin lähestyttävältä spriteineen, joita simppeleitä pikku-ukkoja voi piirrellä itsekin. Unityn 2D-puolikin tuntui sen verran päälleliimatulta, että helpompaa kokeilla toista ohjelmaa. GMS2 nyt tuli ensimmäiseä vastaan, vaikka ilmeisesti myös Godot olisi ihan pätevä.

GMS2 olen nyt tehnyt Heartbeastin videoita seuraamalla, ja nyt tuntuu löytyneen ainakin tutoriaalit, joita jaksan seurata. Vaikka lähtötasoa odotetaan aikalailla 0, niin yleensä videoista pystyy skippaamaan helposti osat, joiden toteuttamisen koen osaavani jo itse. Sitten kun huomaan menneeni sivupolulle - eli olen tehnyt eri tavalla ja uusi tarjottu idea ei sovikaan toteutukseeni, refaktoroin koodia lähemmäs tarjottua.

GMS2 on kyllä aika... jännä. Jotenkin miellyttävä käyttää, että onhan tuo sovellus aika selkeä: konseptit, objektit, huoneet ja eventit suhteellisen helppo ymmärtää. Mutta kyllä tämäkin vähän aivoja vääntää, kun päivätyökseen koodaa. Toistuvalle koodille ei voi tehdä paikallisesti pientä apufunktiota, koska mitään keywordia funktioiden tekemiseen ei ole. Funktioden sijaan voi tehdä "skriptejä", jotka ovat globaaleja ja maagisesti saavat kutsuvan objektin kontekstin. Jokainen funktio siis menee omaan tiedostoonsa, jota pahentaa se, etten ainakaan keksinyt miten funktioille saisi optionaalisia parametrejä. Enumeja loin yhden objektin createssa, mutta niiden scope olikin sitten yllätykseksi globaali. Ei suoraa koodieditori-integraatiota muuhun, vaan oma koodieditori, joka ei kuitenkaan tarjoa automaattista block-hidea (vaan joudut erikseen nimeämään piilotettavia regioneja), eikä mitään "hae ja korvaa" -mahdollisuutta tai refaktorointityökalua. Ehkä tuohon editoriin sitten saa lisäosia, tai pitäisi avata erikseen projekti muussa editorissa (esim. VS Code) ja ainoastaan luoda eventtien runko GMS2 sisällä.
 
aLaverto sanoi:
Mikäs olisi hyödyllinen kieli jolla saisi hyvän pelimoottorin, onko jotain hyvää fps pelimoottoria
Napsauta laajentaaksesi...
Pelimoottorit käyttää sekä scriptattavia että ohjelmoitavia lisäosia joita voi tehdä useilla kielillä. Googlaile vaikka unityn ja unrealin quickstart guideja.
 
Onko mahdollista tehdä peli yksinkertaisesti vain ostamalla pelihahmo yms. Unreal kaupasta? :lol:
 
dragon age sanoi:
Onko mahdollista tehdä peli yksinkertaisesti vain ostamalla pelihahmo yms. Unreal kaupasta? :lol:
Napsauta laajentaaksesi...
Minkälaista peliä oot tekemässä? riippuu ihan siitä :cool:. Unreal tarjoaa valmiin pohjan 1st ja 3rd person projekteihin ja sitten on valmist pohja Twin Stick shootteriin ja muutamaan muuhun. Käytännössä on mahdollista siis, toki jotain omaa varmaan on pakko laittaa, muuten koko hommassa ei ole mitään järkeä :love:
 
dragon age sanoi:
Onko mahdollista tehdä peli yksinkertaisesti vain ostamalla pelihahmo yms. Unreal kaupasta? :lol:
Napsauta laajentaaksesi...
näitä kutsutaan "Asset Flipper" peleiksi, ja niitä on steam pullollaan.
Mahdollista toki mutta hintaa saattaa kasautua aika paljon jos alat ostamaan kaiken

kyllähän internet in pullollaan ilmaistakin tavaraa, esim Kenney · Assets
mutta älä missään nimessä pistä lainattua tavaraa julkiseen jakoon, et puhumalla selviä kun tulee kirjettä asianajajilta.
(Tarkista aina että assettien mukana tulevat lisenssiehdot)
 
Siellä kaupassa onkin ilmaista tavaraa myös, ja jokaisen kohdalla on yhteensopiva versionumero mainittu.
Täytyi sitten päivittää Unreal uudempaan versioon, jonka jälkeen tein uuden projektin -> pelihahmo siihen.
Muuten on jo hyvä alku, mutta "compiling shaders" kestää todella kauan jostain syystä.
Johtuisikohan tuo sitten uudemmasta versiosta.
Tietenkään ei ole hyvä tehdä peliä valmiilla pelihahmoilla tai maisemilla, mutta kun tekee vain omaksi huviksi niin sillä ei ole merkitystä.
 
Onnistuin saamaan pelihahmon ampumaan tulta, mutta jokin siinä on vielä hieman pielessä, koska tuli pysyy paikallaan hahmon kohdalla eikä lähde eteenpäin:lol:
Jotain erroreita kyllä oli matkalla, jos vaikka kokeilisi uudestaan.
 
Löysin ihan mielenkiintosen GDC paneelin proc-gen animaatioista:


ja pikkusella virittelyllä sain tehtyä tommosen kolmen keyframin juoksuanimaation UE4:ssa
cQKhwEv.gif
 
Source 2 moottorin julkaisua tässä odotellaan. Jossain vaiheessa huhuissa oli, että saisi ilmaiseen käyttöön kuten Goldsource (half-life1) moottorin aikoinaan. Tiedä sitten sitä. Dotassahan se jo on, mutta käsittääkseni kehittäjät eivät vielä ole saaneet.
 
Palanca sanoi:
Mikä olisi aloittelijalle järkevin tapa toteuttaa yksinkertainen 2d peli?
Napsauta laajentaaksesi...
Valkkaa jonkun tutorialin youtubesta tai ostat kirjan ja seuraat sitä. (esim ISBN 978-1-4842-1793-1)

Pelimoottorilla ei loppuunsa ole merkitystä, työkalujen käytön joutuu opettelemaan ennemmin tai myöhemmin.
 
Lisään vielä, että jos ei ennen pelejä ole tehnyt, kannattaa idea pitää todella simppelinä. Yksi hyvä tapa onkin kloonata jokin olemassa oleva peli (ensimmäisenä mieleen tulee Pong), koska tuolloin löytää helpommin netistä apua ongelmatilanteissa.
 
Kiitos! Idea on todella simppeli, pärjäisi ihan point and click tyylilläkin.
 
Gamesalad pelimoottorista tuli sähköpostia:
We are writing to inform you that we were recently able to confirm that there was unauthorized access to a GameSalad database containing user profile information.

Sitten kehoitetaan vaihtamaan salasana yms.
 
Mikähän pelimoottori olisi hyvä yksinkertaiselle 2d-pelille Androidille pääasiassa? Unity on ihan vähän tuttu, muut ei ollenkaan. Unityn lisäksi katsoin libgdx:ää ja Godotia. Unitylle varmasti apua löytyy eniten.
 
kaakau<"'\\/> sanoi:
Mikähän pelimoottori olisi hyvä yksinkertaiselle 2d-pelille Androidille pääasiassa? Unity on ihan vähän tuttu, muut ei ollenkaan. Unityn lisäksi katsoin libgdx:ää ja Godotia. Unitylle varmasti apua löytyy eniten.
Napsauta laajentaaksesi...
Taidankin tehdä 3d-pelin, mutta hyvin yksinkertaisen ja kokeilen Godotilla tehdä, jos saan nyt mitään aikaiseksi. Voin yrittää kirjoittaa kokemuksia siitä, vaikka en tiedä onko se minkään arvoinen, kun ei käytännössä ole mitään mihin verrata. Aika paljon Unityn kaltaiselta vaikuttaa.
 
Olen itse aloittamassa tekemään peliä ja mietin tuota unityn käyttöä. Ilmaista versiotahan saa käyttää jos peli ei tuota yli 100k vuodessa. Mitä sitten käy jos peli olisikin menestys ja tuottaisi yli 100k vuodessa? pitääkö sitten päivittää pro malliin vai mitähän sitten tapahtuu?
 
Raksu22 sanoi:
Olen itse aloittamassa tekemään peliä ja mietin tuota unityn käyttöä. Ilmaista versiotahan saa käyttää jos peli ei tuota yli 100k vuodessa. Mitä sitten käy jos peli olisikin menestys ja tuottaisi yli 100k vuodessa? pitääkö sitten päivittää pro malliin vai mitähän sitten tapahtuu?
Napsauta laajentaaksesi...
vaihat vaan seuraavaan pykälään. se hintatarkistus on edeltävältä 12kk ajalta
1618217905606.png


Huom. sisältää myynnin lisäksi myös rahoituksen eli jos saat rikkaalta enolta USD 101000 kehityskuluihin niin pitää nostaa plussaan
 
TheMeII sanoi:
vaihat vaan seuraavaan pykälään. se hintatarkistus on edeltävältä 12kk ajalta
1618217905606.png


Huom. sisältää myynnin lisäksi myös rahoituksen eli jos saat rikkaalta enolta USD 101000 kehityskuluihin niin pitää nostaa plussaan
Napsauta laajentaaksesi...
Okei! täytyy sitten vaihella, kunhan saan koko pelin ensin tehtyä :D
 
Aloittelin tammikuussa sukellusta peliohjelmointiin, jolloin Unity ja Unreal taistelivat hetken keskenään, kunnes päädyin Unityyn helppouden takia. Unityn kanssa ei ihan heti (lue: koskaan) joku tule kaivelemaan sun kukkaroa... Miten täällä muuten on näin vähän keskustelua aiheesta? Samalla sivulla viestejä kolmelta eri vuodelta. :lol:
 
Unityn isoin etu aloittelijalle on minusta helppouden lisäksi se, että sille on storessa iso kasa ilmaisia assetteja. Pääsee paljon paremmin alkuun. Unrealin asset storen ilmaisvalikoima on melkoisen säälittävä. Lisäksi näppituntumalta oppaat on parempia.
 
Itse on tullut käytettyä mm. Ogre3D, JMonkeyEngine, Unity, Unreal ja nyt viimeisimpänä Godot. Kaikissa on puolensa ja liikaa ei kannata yhteen sitoutua vaan enemmin valita engine sen mukaan mitä on tekemässä. Ja engineä tärkeämpää olisi tehdä pelejä valmiiksi (asia missä itse en ole ollut hyvä) :)

Keskustelua ei varmaan ole siksi, ettei täällä riitä aiheesta kiinnostuneita ylläpitämään hyvää keskustelua ja asiasta kiinnostuneet ovat siirtyneet muihin (kuten moottorin tarjoamille) foorumeille keskustelemaan.
 
Nuo moottorit vaan on aika isotöisiä oppia kunnolla. Esimerkiksi Unity ja Unreal on kuitenkin aika erilaisia petoja jo ihan siitäkin lähtien, että toisessa kieli on C# ja toisessa C++. Aika vähän Unrealin kanssa olen mitään tehnyt (ja vain vähän enemmän Unityn), mutta editoritkin vaikuttivat aika erilaisilta.
 
Unitystä on itsellä niin pitkä aika etten muista mitä kaikkea siinä oli (ja paljonko on tullut lisää), mutta aloittelijalle Unity varmaan on se parempi valinta. Ja jos Unity tuntuu raskaalta niin tuostakin kevyempiä moottoreita löytyy. Sitä tuossa edellisessä viestissä yritin sanoa, että kannattaa kuitenkin pitää vaihtoehdot mielessä jos/kun uutta peliä lähtee tekemään koska niillä tietyt asiat voivat onnistua helpommin kuin sillä moottorilla X mihin on tottunut. :)
 
Lähdin itse liikkeelle opettelemaan Unityä ihan niiden omien tutoriaalien kautta. Niissäkin oli hieman haastetta kun käyttöliittymä muuttuu niin nopeasti että pari kuukautta vanha tutoriaalikin oli jo vähän vanhentunut. 15 vuoden .NET/C#-tausta tietysti helpotti paljon kun ei sitä tarvinnut opetella kaiken muun sivussa.

Siitä sitten tekemään omia testejä ja minipelejä (ensin 2D, sitten 2.5D, sitten 3D). Ensin ilmaisilla asseteilla ja sitten shoppaili mitä tarvitsi.

Huomasin että jos on joku kova tavoite mielessä (saada peli Steamiin, saada joku asia toimimaan ennen päivää X), niin tekeminen muuttui heti pakonomaiseksi vääntämiseksi.
Mutta kun teki asioita vain omaksi ilokseen, testaili ja katsoi mitä saa aikaiseksi niin asiat edistyivät paljon nopeammin (ja kevyemmin) :)

Yhtä avaruusaiheista peliä olen vääntänyt nyt vähän yli vuoden ja se alkaa olla ihan kiva pelattava. Ei kyllä lähelläkään mitään Steamiin julkaistavaa tasoa.
Sellainen tunti-pari päivässä ollut ihan hyvä tahti.

Nyt on pari vuotta Unityn opettelua takana ja alkaa olla perusasiat hallussa. Ja nyt vasta alkaa tajuamaan miten älyttömän laaja systeemi tuo on.

Ja ennen kuin osasin tehdä mitään, niin oli tapana selailla Asset Storea ja klikkailla ostoskoriin kaikenlaisia hienoja paketteja :D "Tästä saa hienon pelin kun yhdistää tämän ja tämän".
Nyt kun on osaamista vähän enemmän niin osaa jo katsoa niitä siten, että osaa tunnistaa ne paketit mihin ei skillit vielä riitä ja jättää ne pois.
 
zamerok sanoi:
Huomasin että jos on joku kova tavoite mielessä (saada peli Steamiin, saada joku asia toimimaan ennen päivää X), niin tekeminen muuttui heti pakonomaiseksi vääntämiseksi.
Mutta kun teki asioita vain omaksi ilokseen, testaili ja katsoi mitä saa aikaiseksi niin asiat edistyivät paljon nopeammin (ja kevyemmin) :)
Napsauta laajentaaksesi...

Tuo testailu on hyvä juttu. Huomasin Unreal Enginessä, että jos sijoitat hahmon jonnekin, niin sitä hahmoa voi venyttää. Venytinkin heti jättimäisen npc hahmon sinne kentälle.
Sitten sellaisen jutun, jota on jo käytetty joissakin peleissä, eli jos sijoitat hahmon kentälle noin vain, niin ne hahmot jäävät "ruumiiksi" lojumaan maahan ja niitä voi potkia :D
Ruumiita potkimalla voisi ehkä täyttää jonkin montun, josta sitten pääsisi taas eteenpäin ruumiiden yli kävelemällä.

Ja yhden pelin tein näin: jos raahaat tikapuita ja portaita kentälle, teet uuden kentän korkeammalle, niin voit kiivetä ja hypätä läpi siitä uudesta kentästä uudelle tasolle, jossa on taas uusia portaita, ja täytyy vain löytää reitti, josta pääset ylöspäin taas uudelle kentälle.
Yritin tehdä mahdollisimman vaikeasti kiivettävän reitin, ja kyllä se aika hyvin onnistuikin :)

Lisäys: Nyt vasta huomasin kuinka musiikkia lisätään peliin. Mp3 vain pitää muuttaa wav muotoon. Starter content->audio->import->omakappale wav->tuplaklikkaus ja save->raahaa biisi peliin :D
 
Viimeksi muokattu:
Huomenna eventtiä unreal5:en kehitystyökaluihin ja työskentelytapoihien liittyen. Jännä nähdä miltä unreal5:en työkalut ja työtavat näyttävät.

Join us at 10am EDT on May 26 as Chance Ivey, Senior Technical Designer at Epic Games and Galen Davis, Producer/Evangelist for Quixel at Epic Games provide a first look at new game development tools and workflows that will be available with Unreal Engine 5 before exploring a new sample project.
Napsauta laajentaaksesi...

 
BSP:t poistettu UE5:ssä, todella huono uutinen ainakin omalla kohdalla.

EDIT: Löytyi ne sittenkin Place Actors Panelsin alta :thumbsup:
 
Viimeksi muokattu:
Kuinkahan paljon tuo Unreal Engine 5 kehitysympäristö mahdollisine lisäkilkkeineen vie tilaa levyltä? Sinänsä nimittäin kiinnostaisi kyllä jossain kohtaa perehtyä, että mille tuo vaikuttaa.
 
Don Stupido sanoi:
Kuinkahan paljon tuo Unreal Engine 5 kehitysympäristö mahdollisine lisäkilkkeineen vie tilaa levyltä? Sinänsä nimittäin kiinnostaisi kyllä jossain kohtaa perehtyä, että mille tuo vaikuttaa.
Napsauta laajentaaksesi...
Riippuu millä mausteilla ottaa, pelkkä engine joku 35Gb, lähdekoodien kanssa saattaa mennä yli 100Gb
 
Mitäköhän RT tekniikoita nykymoottoreissa käytetään?
Tuolla on esim hieman yleisesti avattu RTtä:
 
Griffin sanoi:
Mitäköhän RT tekniikoita nykymoottoreissa käytetään?
Napsauta laajentaaksesi...

Lyhyest:

Niitä "kaikkia".

Pitemmästi:

Videolla näyttää käyvän läpi perustavanlaatuista matematiikkaa ja konsepteja jotka on sittemmin vuonna 1986 mankeloitu sen nimiseksi integraaliksi kuin Rendering Equation, johon kaikki modernit renderöinti implementaatiot jotenkin nojaa, kuten myös algoritmit joita käytetään nykyaikaisissa Path-tracing ja Ray-tracing implementaatioissa. Referenssi path-tracer esim Unreal Enginessä varmasti mukailee hyvin pitkälle Monte Carlo menetelmää (varmasti kaikilla lisämausteilla). Huikeita yksinkertaistuksia on keksitty ja edelleen keksitään että RT olisi peleissä käytettävissä sujuvasti.
 
PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼ sanoi:
Lyhyest:

Niitä "kaikkia".

Pitemmästi:

Videolla näyttää käyvän läpi perustavanlaatuista matematiikkaa ja konsepteja jotka on sittemmin vuonna 1986 mankeloitu sen nimiseksi integraaliksi kuin Rendering Equation, johon kaikki modernit renderöinti implementaatiot jotenkin nojaa, kuten myös algoritmit joita käytetään nykyaikaisissa Path-tracing ja Ray-tracing implementaatioissa. Referenssi path-tracer esim Unreal Enginessä varmasti mukailee hyvin pitkälle Monte Carlo menetelmää (varmasti kaikilla lisämausteilla). Huikeita yksinkertaistuksia on keksitty ja edelleen keksitään että RT olisi peleissä käytettävissä sujuvasti.
Napsauta laajentaaksesi...
Niin.. Mietin, että onko nuo kaikki yksinkertaistukset, joita esim tuolla videolla mainittiin nyt jo käytössä?
 
Griffin sanoi:
Niin.. Mietin, että onko nuo kaikki yksinkertaistukset, joita esim tuolla videolla mainittiin nyt jo käytössä?
Napsauta laajentaaksesi...
Juu on varmasti. Nuita yksinkertaistuksia on opetettu vuosikymmeniä jo yliopistotason peligrafiikkakursseilla ja homma on koko ajan edennyt. NVidialla taitaa olla maailman parhaat tyypit töissä jotka nuita kehittää edelleen.

Nykyaikaiset RT pelit ei olisi mahdollisia jos kaikki viimeisimmät huijaukset ja yksinkertaistukset ei olisi jo käytössä.

Edit: monet kikat on myös naamioitu Vulkan ja DXR Api kutsuihin.
 
Jos laskentateho ei olisi ongelma niin ehä se olis ku mallintaa pari perus kvarkkia ja muutama vuorovaikutusvoima tehdä muutama (10^80) oliota ja kirjoitella lähtötilanne. Mutta käytännössä kaikki vaan koittaa miten saadaan huijattua mahollisimman vähällä laskennalla mahdollisimman aidon näköistä /tuntuista. Hyvä koodari tekee koodin joka toimii, erinomainen koodari optimoi sen.
 
PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼ sanoi:
Juu on varmasti. Nuita yksinkertaistuksia on opetettu vuosikymmeniä jo yliopistotason peligrafiikkakursseilla ja homma on koko ajan edennyt. NVidialla taitaa olla maailman parhaat tyypit töissä jotka nuita kehittää edelleen.

Nykyaikaiset RT pelit ei olisi mahdollisia jos kaikki viimeisimmät huijaukset ja yksinkertaistukset ei olisi jo käytössä.

Edit: monet kikat on myös naamioitu Vulkan ja DXR Api kutsuihin.
Napsauta laajentaaksesi...
Onkos noita listattu, mitä missäkin käytetään? Käytetäänkö kaikissa samoja?
JA mitä artifakteja huijauksista seuraa. Niitähän tahtoo seurata, enemmän tai vähemmän..
 
TheMeII sanoi:
Jos laskentateho ei olisi ongelma niin ehä se olis ku mallintaa pari perus kvarkkia ja muutama vuorovaikutusvoima tehdä muutama (10^80) oliota ja kirjoitella lähtötilanne. Mutta käytännössä kaikki vaan koittaa miten saadaan huijattua mahollisimman vähällä laskennalla mahdollisimman aidon näköistä /tuntuista. Hyvä koodari tekee koodin joka toimii, erinomainen koodari optimoi sen.
Napsauta laajentaaksesi...
Ei fotorealismiin sentään noin paljoa vaadita. Lasketaanhan sellaisia kuvia nytkin, aikaa vaan menee rutkasti enemmän kuin peleissä on varaa.
 
Makis sanoi:
Ei fotorealismiin sentään noin paljoa vaadita. Lasketaanhan sellaisia kuvia nytkin, aikaa vaan menee rutkasti enemmän kuin peleissä on varaa.
Napsauta laajentaaksesi...
Teen valaistussimulointeja työkseni lähinnä VRay:n valoanalyysityökaluilla ja vaikka laskenta-ajat on luokkaa tunteja per kuva, niin sekin vaatii jo ihan älyttömästi yksinkertaistuksia ja optimointia ja (kymmenien) vuosien kokemuksen ymmärtää missä kohdissa voi oikoa ja missä ei. Jotenkin uskomattoman oloista kuinka hyvin esim Unreal huijaa grafiikan näyttämään aidolta. Mutta se tosissaan vain näyttää siltä, ja on kaikissa vähääkään erikoisemmissa tapauksissa aika kaukana todellisuudesta.
 
Tuommoista taas:
www.humblebundle.com

Holiday Encore: Unity Tools

We’ve teamed up with Unity for a bundle of versatile game development tools, featuring more than two dozen utilities, systems, and other assets. Pay what you want and support Girls Make Games Scholarship!
www.humblebundle.com www.humblebundle.com

www.humblebundle.com

Holiday Encore: Unity Art

We’ve teamed up with Unity for a bundle of versatile art assets & creative utilities, featuring characters, environments, music, SFX, and more. Pay what you want and support Girls Make Games Scholarship Fund.
www.humblebundle.com www.humblebundle.com

Olleet aikaisemmin myös, mutta tästä aloittelijalle paketti pelien tekemiseen.
 
finWeazel sanoi:
Oletetaan kaksi samankokoista mutta eri resoluutiolla olevaa näyttöä. Valitsen numerot helpoksi. Molemmille näytöille piirretään 5cm*5cm kokoinen neliö. Toisella näytöllä neliön resoluutio on 100x100 pikseliä ja toisella näytöllä 200x200 pikseliä. 200x200 pikseliä neliö tarvii 4x enempi pikseleitä ja käyttää siten tekstuurista eri mipmap tasoa. Jos tuo alkuperäinen tekstuuri oli vaikka 8k kokoinen niin kumpikaan piirretyistä neliöistä ei käytä alkuperäistä tekstuuria vaan sopivan kokoista mipmap tasoa.
Napsauta laajentaaksesi...

Tässä on se väärä käsitys, että mip mapista on vain yksi taso muistissa. Tai edes vain joitakin tasoja.
Tekstuurit on muistissa kokonaan ja jos niille halutaan mip mapit, sitten tekstuurit vie 1.3333x tilan.

Tekstuurien muistihallintaa hoitaa engine ja siellä on myös tekstuurinpakkausta, niin muistissa ei ole yhtä tasoa.. Todennäköisesti modernissa enginessä ei ole edes mip mappeja, vaan jonkunnäköinen anisotrooppinen filtteröinti, mutta ei taas mennä sivuraiteille.

Yksinkertaisilla numeroilla, käytettäessä mipmappeja, muistissa on 8k neliöstä:
8192 x 8192 (alkuperäinen)
2048 x 2048 (ensimmäinen taso)
512 x 512 (toinen taso)
128 x 128 (kolmas taso)
32 x 32 (neljäs taso)
8 x 8 (viides taso)
2 x 2 (alin taso)

Sitten jos piidetään 100x100 neliö, niin napsitaan todennäköisesti 128x128 tasosta ja 200x200 alueella voidaan napsia samankokoinen neliö 512 x 512 tasosta. Tätä tarkoitetaan siinä linkkaamassasi wikipedia-artikkelissa mip map seteillä.
Ei ole mitään väliä näille tasoille, vaikka näytön resoluutio olisi 8K. Ne toimivat samoin.

--

Mistä näkee , että peli ei ole täysi 8K-tekstuureja, jotka ei mahdu muistiin? Siitä, että pelikoko on luokkaa 100GB ja pelissä on enemmän kuin kymmenen aluetta, ääniefektejä ja animaatioita. Ei tuosta tilabudjetista vaan tule niin paljon dataa, että ei mahtuisi näytönohjaimen muistiin pelialueita optimoimalla.
Muistissa tosiaan vain sen hetken vaatima data, mutta skenekohtaisesti oletat paljon enemmän dataa, kuin oikeasti on missään pelissä.
 
Viimeksi muokattu:
@hsalonen

DirectX:n sampler feedback tarjoaa mekanismin jolla ei tarvi edes koko mipmapin taso olla muistissa. Sen avulla saadaan haettua juuri ne alipalaset per mipmap taso, joita peli yritti käyttää. Ilman sampler feedbackiakin striimaus onnistuu, mutta devaajan tarvii nähdä enemmän vaivaa kehittääkseen heuristiikan tekstuurien esilataukseen.

Over time, there has been steady increase in display resolutions whereupon games are expected to be drawn at higher and higher resolutions. An expectation of high-resolution output brings about a need for high resolution textures, and with those, a high memory cost. In many situations it is not desirable or feasible to keep the most-detailed mips of all of a scene’s textures in memory all at the same time.
Napsauta laajentaaksesi...
Sampler feedback is one feature with two distinct usage scenarios: streaming and texture-space shading.
Napsauta laajentaaksesi...

Sampler Feedback

Engineering specs for DirectX features.
microsoft.github.io

toinen lähde ja esimerkki ominaisuuden käytöstä: https://www.intel.com/content/dam/d...back-texture-space-shading-direct-storage.pdf

Rage tais olla eka peli mikä käytti virtuaali/megatextuureita. Siinä pelissä ladattiin juurikin vain oikea mipmap taso hieman etukäteen mitä engine käyttää. "rajoittamattoman kokoiset tekstuurit", koska muistissa oli vain se mitä tarvitaan + cache.

UE5 on vienyt tämän pidemmälle. Rajaton geometria ja rajattomat teksuurit. Muistiin ladataan juuri se mitä tarvitaan. Alkuperäinen geometria ja alkuperäiset 8k tekstuurit muistissa vain, jos on nenä kiinni objektissa

lähde ue5. UE5:en tapauksessa kannattaa katsoa koko esitys, jos haluaa ymmärtää. Linkki aikaleimalla yhteen relevanttiin striimaukseen liittyvään kohtaan

Toki on pelejä, jotka tekevät tyhmästi ja lataavat kaiken muistiin eivätkä striimaa mitään. Tämä on menneisyys mikä onneksi ei tule toistumaan, kun UE5 ja muut modernimmat enginet vievät markkinan. Se auttaa paljon, että molemmat konsolivalmistajat siirtyivät ssd-levyihin ja striimausta erityisen hyvin ssd:lta tukeviin rajapintoihin.
 
finWeazel sanoi:
@hsalonen

DirectX:n sampler feedback tarjoaa mekanismin jolla ei tarvi edes koko mipmapin taso olla muistissa. Sen avulla saadaan haettua juuri ne alipalaset per mipmap taso, joita peli yritti käyttää. Ilman sampler feedbackiakin striimaus onnistuu, mutta devaajan tarvii nähdä enemmän vaivaa kehittääkseen heuristiikan tekstuurien esilataukseen.



Sampler Feedback

Engineering specs for DirectX features.
microsoft.github.io

toinen lähde ja esimerkki ominaisuuden käytöstä: https://www.intel.com/content/dam/d...back-texture-space-shading-direct-storage.pdf

Rage tais olla eka peli mikä käytti virtuaali/megatextuureita. Siinä pelissä ladattiin juurikin vain oikea mipmap taso hieman etukäteen mitä engine käyttää. "rajoittamattoman kokoiset tekstuurit", koska muistissa oli vain se mitä tarvitaan + cache.

UE5 on vienyt tämän pidemmälle. Rajaton geometria ja rajattomat teksuurit. Muistiin ladataan juuri se mitä tarvitaan. Alkuperäinen geometria ja alkuperäiset 8k tekstuurit muistissa vain, jos on nenä kiinni objektissa

lähde ue5. UE5:en tapauksessa kannattaa katsoa koko esitys, jos haluaa ymmärtää. Linkki aikaleimalla yhteen relevanttiin striimaukseen liittyvään kohtaan

Toki on pelejä, jotka tekevät tyhmästi ja lataavat kaiken muistiin eivätkä striimaa mitään. Tämä on menneisyys mikä onneksi ei tule toistumaan, kun UE5 ja muut modernimmat enginet vievät markkinan. Se auttaa paljon, että molemmat konsolivalmistajat siirtyivät ssd-levyihin ja striimausta erityisen hyvin ssd:lta tukeviin rajapintoihin.
Napsauta laajentaaksesi...


Naniitit on se poikkeustapaus ja naniitit on enemmän LoD-työkalu, kuin pelkkä mip map. Käytännössä naniitit tekee juuri sitä, mitä luulet tapahtuvan pelkästään tekstuureilla ja tekee sitä koko skenelle.

Nyt jos kiinnostaisi enemmän, niin hakisin sen videon, jossa näytetään miten nanite-puusto on kehittynyt sen loikan mip map-puiden yli käyttää alimmillakin tasoilla ihan 3d low poly puumallia.

Puhut nyt kuitenkin beta-asteella olevasta teknologiasta, jota 99% peleistä ei käytä ja yrität saada sen kuulostamaan siltä, että tämä on tulevaisuus. Lisäksi redusoit teknologian mip map -hölmöilyysi ja unohdat täysin, että siellä näytönohjaimen muistissa on jopa miljoonia polygoneja (siitä samasta videosta) ja niiden rendaus on se haaste, jota naniitit lähtivät ratkaisemaan.

--

Rage taas on juuri se, mitä puhut ja se iso tekstuuri oli pääosin maastossa, eikä ollut mikään 8k - se oli suurempi. Rage on myös hyvä esimerkki siitä, että teknologia ei lähtenyt kantamaan - ja montako megatexturing peliä tiedät? Minä tiedän kaksi (pun intentended).

--

Tässä edelleenkin sivuutat tärkeimmän asian: jos niitä tekstuureita olisi noin paljon, skenet noin monimutkaisia, niin:
  • 16GB keskusmuistia ei riittäisi peleille (voidaan osittain ratkaista streamauksella, niinkuin konsoleissa on tehty, kun se muisti kuristaa)
  • Pelien datatiedostot veisivät teratavuja
  • Et saisi full res tekstuuria ikinä näkyviin, ellei olisi vähintään 4K-näyttö, ehkä jopa 8K-näyttö, pelit tehtäisiin "tulevaisuuden raudalle"
  • Näytönohjainten muisti ei loppuisi ikinä, kun se muistinhallinta olisi tehtävissä dynaamisesti (ja mistähän tämäkin keskustelu lähti - muistin loppumisesta)
  • Pelit veisivät radikaalisti eri määrän muistia eri resoluutioilla (siis 2x tai 4x määriä)
  • Jonkun 24GB näytönohjaimen näytönohjainmuisti olisi mahdollista saada täyteen pelissä (tästä olisi kiva esimerkkejä saada)
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
259 291
Viestejä
4 502 988
Jäsenet
74 378
Uusin jäsen
Shadowman

Hinta.fi

Back
Ylös Bottom