3D motor programozás

3D motor programozás
2017-03-15T18:35:41+01:00
2017-03-18T12:54:01+01:00
2022-10-19T17:55:34+02:00
  • Egy minimalista 3D engine is jól jöhet néha olyan programokhoz, amihez nem kell feltétlenül egy unity vagy unreal. Most pont egy threejs-re írt minimalista "engine" fejlesztése foglalkoztat, textúrák és bonyolult alakzatok nélkül. Beépített "model szerkesztő" -vel.
    Mutasd a teljes hozzászólást!
  • A tucathoz jo...
    Mutasd a teljes hozzászólást!
  • Nézd, ahol már grafikailag annyira igényes engine kell, ott az engine ára elhanyagolható költség a modellezés költségeihez képest. Egy indie projekt nem tud olyan grafikát összerakni, amihez akár egy unity nem lenne elég.
    Mutasd a teljes hozzászólást!
  • Egy game engine-nél is vannak választható komponensek, nem csak a kész engine és a mindent a nulláról megírunk opció létezik. Van számos library, és framework az API-k mellett, amiket a kész motorok is használnak.
    Lehet integrálni kész fizikai alrendszert, audio-t, script rendszert, hálózat kezelést, az ablakozó és input részt is sokan kész library formájában építik be, és az editorhoz is lehet használni a QT-t vagy a .NET-et is.

    Miért írunk meg mégis 1-1 komponenst (és velük alkotva egy motort), amikor minden készen van, csak le kell tölteni?
    -Az adott libraryk nem támogatnak minden szükséges platformot, vagy vannak függőségeik, amik nem kellenek.
    -Az adott komponensek tudása túl általános és egy speciális stílushoz az nem passzol. (pl. autós fizika, ami még a gumi melegedésével is kalkulál -fel kell találni a kereket-)
    -Lehetnek még performancia okai is annak, hogy például még az STL konténereket sem használja valaki realtime részben, hanem saját egyszerű, de gyors megoldást/adatszerkezetet használ.
    -Lehet, hogy kész kiforrott megoldás nincs még, vagy egyáltalán nincs semmi. Például a játékokban lévő AI még ma is elég butácska, itt még van hova fejlődni. Külön Game Editor pedig úgy tudom egyáltalán nincs is a piacon.
    -A feladat annyira egyszerű, hogy egy tapasztalt fejlesztőnek pár nap alatt implementálható és egyszerűbb ezzel dolgozni, mint egy ezer félét tudó és ezer függőséget hozó valamit átalakítani.
    -Licensz problémák is lehetnek, mivel a nyílt kódú komponensek átalakított változatát is közzé kell tenni és ez egy céges projektnél nem biztos, hogy lehetséges. (Még maga Carmack is átalakította a Doom3 forrását csak azért, hogy nyílttá tudja tenni)
    -Egy idő után ezek a komponensek elhalnak, hozzájuk a support egyenlő a 0-val, sok esetben egyes verziók is teljesen inkompatibilisek a másikkal, egyszóval hosszútávon csak kínszenvedés a velük való komoly munka. (ez igaz a legtöbb kész motorra is)
    -Gyakorlás, fejlődés, szakmai skillek gyűjtése.
    Mutasd a teljes hozzászólást!
  • Ma elnézve a palettát, azért még mindig a grafikailag igényes engine-k nagy része proprietary. Gondolok itt a Frostbite-ra, a Dooma 2016 engine-ere, a GTA V engine-jere, es meg egy csomo igenyes engine van a jatékiparban.

    Az open-source-ok kozul szinte egyedul az Unreal a komolyan vehető, én nem nagyon tudok más olyan open source engine-ről, amiben pl. normális physically based rendering lenne, miközben ma már nem lehetetlen az ehhez kellő tudást összeszedni a netről.

    Én pl. kifejezetten VR engine-t írok hobbyból Windows-ra, ami tisztán üzletileg nem lenne racionális (de mivel hobbyból csinálom, ez nem számít), de nem vagyunk olyan messze attól, hogy racionális legyen, mert:  Az Unreal is tartalmaz hatszázezer féle olyan tool-t amire nincs szükségem, támogat olyan platformokat, amikkel nem foglalkozom, olyan screen-space effekteket, amik nem jók VR-ban, és pl. a deferred shading, amivel dolgozik nem optimális VR-hoz, mert nem lehet vele MSAA-t csinálni. Az oculus pl. kapásból írt hozzá egy új renderer path-t, ami forward rendering és sokkal gyorsabb:

    Optimizing the Unreal Engine 4 Renderer for VRPersze nemigen tartják ezt szerintem karban...

    NAmost ha pl. gondolok egyet és ráspecializálom amit írok eye trackingre és foveated renderingre most, amikor még a mainstream engine-k nem foglalkoznak még ezzel annyira mélyen, máris van egy terület, amiben amit írok, az élvonalban lehet.

    Mindenesetre az engineek területén van még mit csinálni, lehet még írni olyan engine-t ami a maga területén nagyon optimális. Üzletileg nem feltétlenül racionális döntés, de az innovációt sok esetben nem a racionális döntések hajtják. Személy szerint én úgy gondolom, hogy már eleve játékfejlesztéssel foglalkozni sem racionális üzletileg, hiszen ugyanazzal a tudással más iparágakban több pénzt is lehet csinálni.
    Mutasd a teljes hozzászólást!
  • Mindenre a megfelelő eszközt kell kiválasztani, és akkor írni újat, ha nincs megfelelő. Nem feltétlenül érdemes mindig újra feltalálni a kereket. Adatok tárolására is van ahol az sqlite a megfelelő, van ahol a ms-sql vagy oracle, van ahol a mysql, van ahol a mongodb, és van ahol az egyedi, fájl alapú tárolás. De nem érdemes mindent ez utóbbi módon megoldani.
    Mutasd a teljes hozzászólást!
  • Minek az Urho, ha már volt előtte Unreal, de minek az Unreal, amikor ott a Tech, de minek a Tech, amikor ott a Wolf3D és minek a wolf3D, amikor... A Croteam is biztos csupa debil, mert Serius motort ír, ami, mint tudjuk fölösleges, mert ott az Urho3D, ami mindenre jó.

    A PHP, MySQL stb webes eszközök, amikkel fejlesztenek pl. CMS-t, de minek a fejleszteni CMS-t, amikor már van ilyen? A te gondolatmeneted szerint egy for ciklust is felesleges megírni, mert már biztos írt valaki for ciklust. Sőt tovább megyek minek írsz hozzászólást, amikor a prog.hu már teli van hozzászólásokkal? Nem egyszerűbb bevágólapozni egyet?
    Mutasd a teljes hozzászólást!
  • Annyira nem bonyolult a használata. Picit olyan ez, mint a PHP framework vs saját egyedi motor.
    Mutasd a teljes hozzászólást!
  • Fölösleges, mire megtanulom a használatát már rég kész van a saját cél render.
    Mutasd a teljes hozzászólást!
  • Unrealt nem is, de vannak kisebb, ingyenes motorok is, Pl. Uhro3d / uhrosharp amik elég jól integrálhatók.
    Mutasd a teljes hozzászólást!
  • Javaslom kezdd az elején,

    bár a könyv régi (1984), de az alapok benne.

    W. M. Newman: Interaktív számítógépes grafika / Könyv / Antikvarium.hu

    Ezután tanulj opengl-t (kezdetben a fix pipeline, de lehet egyből a shaderekbe is beleugrani).

    Rengeteg matek lesz (nem kell megijedni), különösen akkor válik fontossá, mikor pl. animálni akarsz valamit.

    Teljesen nullából kezdés helyett pl. játssz kicsit a webgl-el, shadertoyjal hogy megértsd a technikákat.

    Illetve még a létező enginek forrását is lehet tanulmányozni.
    Mutasd a teljes hozzászólást!
  • Számos vizualizációs lehetőség van, amit 3D-ben is lehet ábrázolni, miközben épp folyik valaminek a gyártása, tervezése, megfigyelése, felderítése, szimulálása, diagnosztizálása stb. Lehet ez orvosi, biztonság technikai, geodéziai, katonai, rendőrségi, gyári, és számos egyéb alkalmazás, mint "üzleti" alkalmazás és nem játék. Valahol például textúrázatlan low poly modelleket kellett csak megjeleníteni, ami mutatott valamit, máshol meg egy 3D terepet kellet ábrázolni célpontokkal stb. Ilyen egyszerűbb feladatokhoz teljesen fölösleges egy Unreal4 motort integrálni.
    Mutasd a teljes hozzászólást!
  • Mit csinál egy üzleti appban egy 3D-s opengl engine ?
    Mutasd a teljes hozzászólást!
  • Nem érted. Az eredeti thread arról szólt, hogy ahogy az üzleti apphoz sem ír az átlagpolgár saját SQL szervert, vagy .NET frameworköt, úgy a legtöbb esetben ma már egyedi játékmotort sem fejlesztenek a cégek, hanem kész játékmotort használnak, és elkülönül az a pár cég aki játékmotort fejleszt, és azok akik játékot fejlesztenek.

    Én meg üzleti apphoz fejlesztek OpenGL-el grafikus engine-t, na bumm! (nem első eset) Az SQL csak egy része az egésznek, olyan, mint az OpenGL. Lehet írni saját SQL motort, mint ahogy le lehet menni Vulkan/Metal szintre is, vagy akár saját renderelőt is lehet írni. Ugyanígy lehet írni .NET-et, meg lehet írni Lua rendszert is, de amíg megfelel az igényeknek nem feltétlenül szükséges. 

    Ami viszont szükséges az egy architektúra, ami úgy működik, ahogy az ügyfélnek/kiadónak szüksége van rá és ezt nem mindig elégíti ki egy komplett engine. Ezért írod az ügyvitelt is .NET-el, SQL-el, mint, ahogy én is a grafikus renderelőt OpenGL-el és Tao-val, mert elég nehéz lenne az üzleti appba belegyömöszölni egy Unreal engine-t, meg őszintén szólva fölösleges is lenne, mint ahogy nálad sincs értelme egy SAP-ot beletenni a számlázó programodba.

    Saját játékmotort is fejlesztek szabadidőmben. Egyrészt azért, mert ez is egy skill, ezzel is tudok pénzt keresni. Másrészt ez egy testreszabott célmotor, nem egy több millió soros giga valami, amivel a mariótól kezdve a 3D FPS-ig mindent lehet. A grafika minősége a grafikuson múlik, meg a GPU-n leginkább, mivel ma már minden technológiához hozzá lehet férni a neten számtalan tutorial és könyv formájában is, ahogy láthatod a fórumban. Ma már nem krőzus kincse kitalálni a Carmack motort, hanem a célnak megfelelően csak le kell implementálni. Éppen ezért ez ma már egy grafikus API-val mondhatni rutinfeladat nem olyan nagy világszám, mint a régi időkben. Mint, ahogy számlázó programot is nagy szám lehetett megírni C64-re mondjuk grafikus felülettel ASM-ben, míg ma ez már rutinmunka egy pályakezdőnek is a .NET-el, meg az SQL-el.
    Mutasd a teljes hozzászólást!
  • A skinek nyilván rajzoltak, de szerintem az arcok ábrázolása sem annyira rossz ma már mint a Skyrim idejében volt.
    Mutasd a teljes hozzászólást!
  • Nem tudom szerintem meg messze vagyunk az elethu dolgoktol. Vannak szep kepek, de ha kozelebbrol megvizsgalod latod hogu az rajzolt... pl tipikusan az emberek a jatekokban ilyenek.
    Mutasd a teljes hozzászólást!
  • Nem érted. Az eredeti thread arról szólt, hogy ahogy az üzleti apphoz sem ír az átlagpolgár saját SQL szervert, vagy .NET frameworköt, úgy a legtöbb esetben ma már egyedi játékmotort sem fejlesztenek a cégek, hanem kész játékmotort használnak, és elkülönül az a pár cég aki játékmotort fejleszt, és azok akik játékot fejlesztenek.

    Azt, hogy mi a .NET ne nagyon akard elmagyarázni, kb. 10 éve fejlesztek különféle szoftvereket rá (előtte meg vagy 20 évig más platformokra az ősi mainframektől a delphiig és a wxWidgetig), ahogy játékmotorból is láttam már párat (unity, urhosharp, libgdx és nagyon futólag godot), mivel ez a hobbim (xenko-t leginkább azért nem, mert egyrészt a demo appja droidon élből segfaultot dobott, másrészt a mai napig nem tudni milyen licensszel jön ki - bár jövő hónapra ígérik). Ami miatt szerintem nagyon nem érdemes ebbe beleásni magát az embernek, mert manapság már a profi motorok kb. hozzák a fotorealisztikus képet - ennél sokkal tovább szerintem már nemigen lehet jutni. Ez már nem Carmackék ideje amikor egy-egy új motorral egy-két ember megváltotta a világot.
    Mutasd a teljes hozzászólást!
  • Nálad vannak kicsit zűrök fogalmi szinten.

    Először is a .NET egy keretrendszer, amivel programozhatsz magadnak egy architektúrát például egy game engine-t. A Xenko engine pedig egy játékfejlesztői eszköz, amit .NET keretrendszer segítségével fejlesztettek. Nagyon nem egy szinten van a kettő, nem is értem, hogy lehet összekeverni. Lehetne persze Xenko-val is könyvelő programot írni, csak lehet hamarabb beletörne a bicskád, mint a .NET-nél.
    Mutasd a teljes hozzászólást!
  • Te kevered picit a dolgokat - persze ez játék motortól is függ.

    Alapvetően az OpenGL, DirectX, stb. kb. a fájlrendszer szintjének felel meg. Alapvetően ez a legalsó réteg amit a földi halandó még viszonylag egységesen el tud érni, ez kb. a dolog legalja.

    Az általános célú játékmotor, mint Pl. a Unity3D kb. az SQL szerver, vagy a .NET szintje. Biztosít egy olyan közbülső API-t, ami kb. azt tudja, hogy van egy model, van rajta egy material, van egy világítás, van egy animáció, a te kódod pedig biztosítja hogy mi legyen ezekkel. Te döntöd el, hogy FPS legyen belőle vagy RTS vagy sakkozóprogram. Lehetnek előre gyártott komponenseid, mint ahogy Pl. egy üzleti appban is lehetnek - sőt vannak is - előre gyártott komponensek, Pl. grid, chart, stb.

    Vannak végül a különféle game maker programok, és egyéb magas szintű dolgok, ahol tényleg előre kapsz mindent, és akár programozási ismeret nélkül is tudsz játékot írni. Ezek felelnek meg kb. a CMS rendszereknek, vagy az SAP-nak - bár az igazság az, hogy ez utóbbi saját programnyelvvel rendelkezik, és gyakorlatilag bármit le lehet benne fejleszteni ami ügyvitel - bár olyan rugalmas persze nyilván nem lesz, mint egy Visual Studio/NET.
    Mutasd a teljes hozzászólást!


  • Hát nem. Az összes általam ismert ilyen rendszer valamilyen kész adatbáziskezelőt használ (MS-SQL, FireBird, MySQL, illetve régebben dbf vagy access). Az egyediséghez bőven elég az eltérő táblaszerkezet is... Egyedi, fájl alapú megoldást csak Commodore 64-en láttam a régi szép időkben, illetve egy helyen valaki okoska quickbasic-ben próbált ilyet csinálni - ezzel kapcsolatban azért kerestek meg, mert a csávó aki írta elment a cégtől, viszont a rendszer különböző pontokon random vesztette az adatokat... Megnéztem, belül a rendszer maga volt a programozott káosz. Nem kötöttünk üzletet a megrendelővel...
    Mutasd a teljes hozzászólást!
  • Kicsit kevered a fogalmakat. Például a .NET, SQL Server, WPF megfeleltethető játékfejlesztésben a STL, OpenGL, QT rendszereknek. Ráadásul pont az üzleti alkalmazásokat szokták saját fejlesztéssel megoldani, viszonylag kevés fejlesztőcég használ kész engine-t pl.: SAP-ot. Pont azért teszik ezt, amiért játék engine-t is ír valaki, vagyis olyan feltételeknek kell megfelelnie a programnak, amit a sablon engine nem tud, vagy nem úgy valósítható meg, mint egy célfeladatokra orientált, vagy csak egyszerűen ágyúval verébre eset lenne.

    pawnda
    Szakmailag mi ér többet?
    1. valaki profi szinten tud egy engine-ben dobozokat összekötni , scriptet írni
    2. másvalaki megír magának egy engine-t és editort
    Egy állásinterjún mondjuk az Ubisoft-nál, NVidia-nal kit fognak felvenni szerinted?

    A másik, hogy például egy 3D Tetris-hez, vagy valami más egyszerűbb játékhoz mi a búbánatnak töltsön le egy több millió soros engine-t és kezdjen el azzal vesződni?
    Mutasd a teljes hozzászólást!
  • Ez kb. olyan ötlet, mint hogy saját fájl alapú adattárolást csinálni SQL szerver helyett a számlázóprogramodhoz, csak hogy megspórold az SQL szerver megtanulásának költségét.

    Pont azt tippelném, hogy egy csomó számlázóprogram saját formátumot használ. Pl. hogy ne lehessen olyan könnyen váltani közöttük, és a "jóleszazúgy" faktor is simán benne lehet.
    Mutasd a teljes hozzászólást!
  • szinte senki sem ír már saját enginet és nincs is értelme.

    Most épp egy üzletember beszél belőled. De ha tanulni akarsz valamiről, akkor van értelme összerakni egy sajátot. Szórakozásnak sem utolsó, és van rá esély, hogy utána másét is jobban átlátja az ember.
    Mutasd a teljes hozzászólást!
  • Ez kb. olyan ötlet, mint hogy saját fájl alapú adattárolást csinálni SQL szerver helyett a számlázóprogramodhoz, csak hogy megspórold az SQL szerver megtanulásának költségét.
    Mutasd a teljes hozzászólást!
  • Érdemes elolvasnod Asylum az feljegyzéseit.The Asylum
    Mutasd a teljes hozzászólást!
  • Nagyon más idők járnak, szinte senki sem ír már saját enginet és nincs is értelme. Az engine 30% a játékfejlesztésnek, de hogy abban te hatékonyan tudjál fejleszteni szükséged lesz egy szerkesztőre ami mondjuk a maradék 70%.

    Ha játékot akarsz fejleszteni szedd le a Unity3d-t minimális porgramozással lehet benne olyan komplex játékokat írni, hogy ha valaki nem tudja mivel csináltad csak áll és keresi az állát.
    Mutasd a teljes hozzászólást!
  • Unreal engineben akár az enginet magát is átírhatod mellesleg.

    Lehet, hogy neki nem az a célja, hogy egy 23 éves több millió soros engine-t átalakítson (sok értelme nincs), hanem írjon egy kicsi egyszerű saját motort, ami azt tudja, amire neki szüksége van és mivel ő fejlesztette nem kell hónapokig sem tanulnia a használatát.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Sok értelme nincs neki, de nem is rég volt egy hasonló topic valahol prog-on, ahol valaki írta, hogy valaki csinált youtube-n egy videósorozatot arról, hogy a 0-ról épít egy enginet.

    Viszont 99%, hogy te nem enginet akarsz írni, így inkább jobban járnál ha unity/unreal engine használata után néznél utána.
    Unreal engineben akár az enginet magát is átírhatod mellesleg.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd