37061
Digital Combat Series: World
A DCS World megszületésével a DCS sorozat egyetlen közös magra építve, egy felületről lesz elérhető. Az eddig egyenként telepíthető DCS részek helyett egyetlen közös felületről lesz elérhető, így sokkal könnyebben lehet váltani az egyes kiegészítők között, egyszerűbb és könnyebb lesz a frissítés is. A DCS World folyamatos frissítésekkel, a grafikus rendszer, az AI egységek, AI logika, effektek, stb. együtt fejlődik. Minden ami a szimuláción kívüli repülhető gép, térkép vagy más fizetős tartalom. A jelenlegi DCS World még béta verziós, nem végleges. Az első kiadás ingyen tartalmazza a Flaming Cliffs 2-ből származó repülhető Szuhoj Szu-25T Frogfoot típust.(THX by Sanyo)
*-------*
Nem jogtiszta játék letöltésében, telepítésében és használatában nem tudunk és nem is akarunk segíteni.
Az ilyen jellegű hozzászólások válaszolatlanul lesznek, vagy minden további értesítés nélkül törlésre kerülnek.
HUNAF nyílt facebook csoport KATT IDE!
DCS OFFICIAL fórum KATT IDE!
A DCS HuNAF weoldala KATT IDE!
Szimulátor történelem KATT IDE!
-
Solt #21399 Én is rácuppantam, de még 30-ért is sok lenne... ki lehet ezt hozni olcsóbban, csak meg kell fűznünk egy szakit! :)) -
#21398
Ááááá de fasza! Csak az a 60+ ropi...
Valaki estleg tudna ilyesmit gyártani? -
Solt #21397 Nézzétek milyen fasza asztalhoz rögzíthető Hotas tartót találtam: LINK
Az ára horror sajnos, szóval házi barkácsban kéne megoldani valahogy!
-
#21396
Lehet csak én nem vettem észre eddig, volt ilyen.. nem tudom, de ez nagyon állat :)
![]()
-
MBW126 #21395 A prémium vs. nem prémium tüza kérdéséhez: ha a motort 95-ös benzinre tervezték, semmilyen észlelhető előny nem származik a magasabb kompressziótűrésű tüza használatából. Az ilyen-olyan tisztító adalékoknak sem célszerű bedőlni, egy szétszereléses tisztítást az ilyen csodavackok nem helyettesítenek. Emellett, amit mégis leoldanak, az ugye átmegy a motoron, amit azért nem szilárt, kikühedt diribdarabkák tovább darálására terveztek.
A jármű viselkedését, fogyasztását sokkal inkább meghatározza a guminyomás megfelelősége, a gumi anyagának keménysége, a szélirány és erősség, az útburkolaton lévő csapadék jellege és mennyisége, valamint az út minősége. -
MBW126 #21394 Úgy tudom, a belső - külső égés kategóriáját az választja el egymástól, egy térfogatban történik-e az égésfolyamat és a munkavégzés. Egy dugattyús motor egyértelműen belső égésű, egy gőzgép, gőzturbina egyértelműen külső égésű. A tolóerőt szolgáltató gázturbináknál a tolóerőt ismereteim szerint az égéstér fala veszi fel, ebből a szempontból belső égésű.
Vannak viszont olyan tengelyteljesítményt szolgáltató gázturbinák, ahol a gázgenerátor rész - aminek igazán nem is kell gázturbinának lennie, a harmincas években ugye kísérleteztek dugattyús motor füstgázának felhasználásával is - és a munkaturbina, vagyis az a turbina rész, ami a füstgáz belső energiájából forgó mozgást állít elő, az nincs mechanikai kapcsolatban egymással. Az ilyen gázturbina végülis tekinthető külső égésűnek. (Valójában ugye nem kell a harmicas évekig menni példáért, elég csak a garázsig, mert minden turbófeltőltő lényegében ilyen gázturbina, csak a munkát nem légcsavar, hanem egy kompresszor hajtására fordítjuk..)
A benzinmotorok égését kifejteném: a normál üzemi állapotnak megfelelő szikragyújtásos égésnél a gyertya villamos ívétől kiindulva nagyjából egy gömbcikk alakú hullámfront mentén zajlik az égésfolyamat, aminek hatására a hengerben a nyomás folyamatosan növekszik - ez az egyik gond a wankel motorokkal, ott az égéstér alakja legjobb pillanataiban sincs köszönő viszonyban a gömbbel -, miközben a dugattyú a felső holtponton átjutva már lefelé mozog, a nyomásnövekedéstől hajtva. A kopogásos égésnél ezzel szemben öngyulladás történik, a hengerben lévő benzin-levegő keverék még a felső holtpont felé haladó dugattyú felett gyullad meg, a forgattyús mechanizmus meghatározta haladási iránnyal ellentétes, dinamikus ütést mérve a dugattyúra, azon keresztül az egész forgattyús mechanizmusra. A begyulladás általában több ponton történik, a nyomásnövekedés nagyon meredek. Mivel a dugattyú még felfelé mozog, az elégett, magas hőmérsékletű füstgázt tovább sűríti, emiatt kap az égéstér s így a hűtés szempontjából halmozottan hátrányos helyzetű dugattyútető nagyobb hőterhelést, mint a tervezett égés során.
Hatványozottan rossz a helyzet nagy hengerszám esetén. A hengerszámot a munkaütemek számával elosztva megkapjuk, hány hengerben zajlik épp azonos munkafolyamat. A szóban forgó motor ugye 12 hengeres, vagyis egyidejűleg 3 hengerben van gyújtást követő expanzió, ami forgás irányú hajlító nyomatékot jelent a motor számára, ekkor következik be az ellentétes hajlító nyomatékot előidéző kopogásos égés. Minél hosszabb egy forgattyús tengely - alias főtengely - annál érzékenyebb az ilyen hatásokra.
Nem tudom, a Messer motor valójában mennyi ideig bírta ki röhögés nélkül a kopogásos égést, de figyelembe véve, hogy normál üzemállapotban is néhány tíz üzemórára tervezett élettartamú, katonai célú eszközről van szó, arra tippelnék, nem sokáig.
A diesel motornál sincs robbanás, ott is szabályos égés zajlik. Az ottó motornál az üzemanyag-levegő keveréket sűrítjük össze, majd a megfelelő időpontban villamos ívvel begyújtjuk, a diesel motornál ezzel szemben a levegőt sűrítjük össze, majd a megfelelő időpontban a sűrítés miatt a tüzelőanyag gyulladási hőmérséklete fölé hevült levegőbe nagy nyomással beporlasztjuk a tüzelőanyagot. A tüzelőanyag ugyanolyan szépen, lassan, fokozatos nyomásnövekedést előidézve ég el, mint a szabályos égésű ottó motornál. Ebből nagyjából látható, miért nehezebb jó kibocsátású dieselt faragni, mint ottót: bár az égésfolyamat egyik esetben sem lesz sohasem tökéletes - mert a kémia egy mocskos ribanc - de az ottó esetében több ideje van a tüzának a levegővel keveredni, elpárologni, ideálisabb elegyet képezni. A dieselnél ezzel szemben mire a tüza észrereveszi, hogy itt akár még egy kiadós oxidálásra is lehetőség nyílt, mert van eléggé meleg és oxigén, addigra már vége a bulinak, és a kidobóember szerepét betöltő dugattyú már tessékeli is kifelé. -
#21393
Aham, az lehet, már régen volt. Csak megmaradt bennem hogy volt ilyen teszt.
De akkor meg adódik a kérdés hogy ha a benzinkúton nem tudsz 100 oktános benzint venni akkor hol?
Utoljára szerkesztette: PhantomAss, 2016.11.09. 08:15:48 -
#21392
-
Colos1357 #21391 Az nem szükséges, hogy a kompresszióviszony megváltozzon, az már bőven elég, ha a gyújtás előtt nagyobb a sűrítés. Ez pedig teljesül akkor, amikor az előgyújtás a holtponthoz közelebb kerül. Persze, ha megváltozna a kompresszióviszony, akkor még jobb lenne. A mai napig kísérletezgetnek változó kompresszióviszonyú motorokkal, de tudtommal egyelőre több a hátránya, mint az előnye 
Nem hoz annyit, hogy megérje vesződni vele.
PhantomAss, én láttam azt a tesztet. De ott tudtommal kiderült, hogy nem a motorokkal volt a gond, hanem a benzinnel. Azért, mert rá vagyon írva, hogy prémium, meg más a színe, még nem jelenti azt, hogy az is... -
gantus68 #21390 En is visszamentem stable-re, megvarom mig kijavitjak, addig repkedek :)
-
#21389
Ha itt most megnyomom az F1-et, akkor egy almenü helyett egyszerűen bezáródik ez a rádió menü.
A normál DCS-ben még működik.
![]()
-
#21388
nem lehet a gyalogosoknak azt mondani a rádión, hogy "szálljatok be vazze"..
Szóval ez az "embark to transport" nem működik.
-
#21387
Mit qrtak el? -
#21386
Húúúú, de nagyon felbaszott idegileg ez a szar. Ha lenne valami kicsit is normális alternatívája a DCS_nek, MOST basznám ki az egész hóbelevancot az ablakon.
MIÉRT kell elbaszni, ami működik? MIÉRT???
-
#21385
Az árnyék kezelése, generálása, hogy az egyik miért jobb vagy a másik miért rosszabb, ez már programozás területe, amihez nem értek. Shadow Mappingnak hívják egyébként, ezt lehet előre is generálni és valós időben is generálni, de alapszabály itt is, hogy minél kevesebb elem lép interakcióba egymással, annál gyorsabban megvan a végeredmény. Gondold végig, hogy a számítógép az nyilván nem "lát" semmit, ő csak a térbe helyezett pontokkal, adatokkal tud dolgozni. Van egy nagy adag koordináta halmaz, ami a 3d modelled. Ehhez képest megadod a fényforrás helyét és irányát (napfénynél perspektívával nem számolnak, az ortografikus vetület miatt csak iránya és fényerő van, térbeli kiindulási pontja nincs, egy elemlámpa viszont pontként jelenik meg a térben, ott fontos a perspektíva is, ami megint nem teszi egyszerűbbé a számolást). És akkor shadow map generálásnál elkezdi a gép kiszámolni a koordinátákból, hogy egy harmadik elemre vetítve (talaj pl) mely pontok határolják az árnyékot (pontosabban a saját és a cél objektum UV mapján melyik területek lesznek sötétek, a fényszóródást, fényerőt is számolva meg megkapja, hogy mennyire lesz világos az árnyék). Ez most nagyon leegyszerűsített eljárás, és tuti, hogy egy programozó szakszerűbben le tudja írni, de biztos látod, ha több elemet kell bevonni a számolásba (szomszédos épület), amik ráadásul változhatnak is (nap mozgását követi az árnyék), akkor az jelentősen több számolási igény. Ha statikus fényforrás lenne, változatlan nap állással, az lenne a legegyszerűbb, akkor elég lenne előre generált shadow mapot húzni az egészre, vagy eleve ráfesteni az épületekre és a talajra (sok fps-ben például ez a helyzet, egyszerűen az idő függvényében nem változik a nap helyzete, ezért nem is kell számolni a környezeten megjelenő fények nagy részét. Kap egy illumination map-ot, ami az ilyen statikus fénylő felületeket kezeli, azt' el van intézve).
Armánál is hasonló lehet a probléma, dinamikus fények vannak, nap is napszaknak megfelelően mozog, de így is állandóan teljesítmény problémák vannak vele, a grafikai effektek, háttérben futó fizikai szimulációk, AI szimuláció, egyéb szarok elviszik a processzor és a videokártya nagy részét. Valszeg az elemlámpa árnyék annyira alul van a listán, hogy egyenlőre nem foglalkoztak vele (shadow mapnak elég nagy a videokártya memória igénye). Arma amúgy is elég gáz, ok, a gépem már kicsit lassú hozzá, de csak offline tudok játszani, ott stabil 40-50 fps. Felmegyek online, és 15 fölé nem megy :/ Akkor a netkód tesz be az egésznek? Vagy a pálya van telerakva minden szarral? Ki tudja?
A PBR anyagoknál lehetőség van arra, hogy több layerben használj textúrákat. Páldául van egy alap anyag, és ahogy közeledsz, az engine sorra növeli a részletek sűrűségét, akár még új layereket is pakol rá, ugyanazon az elven, ahogy LOD-ot számol a 3d objektumokra. Legalábbis az Unreal 4 tudja ezt. Az Arma nem hiszem. A procedural anyagok viszont iszonyatosan számolás igényesek, és ilyen megoldások mellett amit az unreal tud, nincs is rá szükség.
És ugye van még egy faktor, amire játékkészítőnek figyelnie kell, a kompatibilitás. MI az a minimum spec. amin el kell, hogy fusson a játék? A sok kompromisszum nyilván a low end gépek miatt kell.
Utoljára szerkesztette: VO101Tom, 2016.11.08. 17:18:26 -
#21384
Jó lenne több ilyen ötletelést olvasni, megbeszélni,hogy mi hogyan működik a játékmotoroknál konyhanyelven , nem mondom, hogy megváltanánk a világot vele, de legalább egy kicsit átlátná az ember .
Visszatérve az alapszituhoz, miért egyszerűbb és könnyebb azt megvalósítani, hogy a nap okozta vetett árnyékot mindegy egyes objektumra külön kiszámolja és ignorálja azokat amelyek belelógnak egymás árnyékba? Ahelyett, hogy egy menetben a napból húzva egyenes vonal mentén az összes akadály kontúrját rávetítené a talajra ahogy a valóságban is?
ARMA-ban is csak a nap tud árnyékot vetni, de a zseblámpa nem ,viszont egy zárt térben is nappali világosság van, ez azért nonszensz 2016 végén sztem.
Az anyagoknál nem lenne egyszerűbb a shader alapú vagy procedurális megközelítés a nagy felbontású textúrák helyett ? például a gumi üveg , króm és réz anyagok elég jól behatárolt tulajdonságokkal rendelkeznek. A felbontás vagy ha nagyon rájuk közelítünk akkor a textúrával ellentétben nem romlana a minőség ,csak egyszer kell megcsinálni és behívni a megfelelő helyeken, míg textúra alapon minden gumi,króm,réz objektumra külön meg kell festeni és betölteni. Arról nem is beszélve, hogy az elkészítése mennyivel rövidebb ideig tart. -
#21383
Értem mire gondolsz, de én is úgy vagyok vele, hogy bár a játékmenet a legfontosabb, de ha már itt a technológia, miért ne nézzen ki jól? :)
De a probléma mindig is a valós idejű számolásokkal van. Amikor játékhoz készít valaki grafikai engine-t, akkor mindig egyszerűsítésre van kényszerítve és minden mikroszekundum nyereség -interpolálva az összes használt textúrára és anyagra- hatalmas gyorsulást jelent. A .dds fájl formátumot például kifejezetten arra fejlesztették, hogy tömörítetlen formában tárolja a textúrákat úgy, hogy a videokártya a leggyorsabban be tudja olvasni. Elképzelhetetlen, hogy például jpg-n tároljanak bármit, hogy aztán a kicsomagolással menet közben kelljen foglalkozni. Pedig milyen jól hangzana, hogy egyetlen 4K-s textúra ne 12 MB-ot foglaljon videokártya memóriából, hanem csak 90KB-ot. Igen, csak amikor azt a fájlt ki kell csomagolni, akkor jönnének a hatalmas akadások, fps droppok. A néhány éve megjelent PBR anyagok elég látványos változást hoztak sebességben, rengeteg számolási igényt vettek le a videokártya válláról azzal, hogy egy-egy anyag összes, a valós életben mérhető fizikai vagy fény jellemzőit egy meghatározott szabvány szerinti map-okon tárolják (innen is a neve - Phisical Based Rendering).* Teljesen eltűntek a procedural anyagok, amiket meghatározott algoritmus alapján, de valós időben számolna ki a program. Helyette jöttek az engine-ben összeállított anyagok (shaderek), amik szintén lehetnek bonyolult, sok lépcsőből álló összetett anyagok is, a sebesség viszont sokkal gyorsabb lett (3DS Max vagy Maya-nál használható VRay renderelő már évek óta hasonló rendszert használ, de azt álló képekhez, vagy nem valós idejű mozgókép renderhez fejlesztették, és bár iszonyatosan szép, pontos és élethű - esélytelen bármit is valós időben megjeleníteni vele). Ma már azt mondhatjuk, hogy az Unreal, Unity, Cryengine közel fotoreal végeredményt tud valós időben. És ez hatalmas fejlődés. A speciális, custom video engine-t használó játékok, mint az Arma, Clod, DCS meg futnak utánuk, ahogy éppen tudnak. A DCS EDGE például egyértelműen elindult ebbe az irányba, talán egyszer a Clod is el fog ;) .
A sok pozitívum mellett viszont iszonyatosan megnőtt a foglalt terület igénye is. Most már nem csak egy rajzolt textúra lapot kell tárolni, hanem mindjárt hatot (alsó hangon). Úgyhogy már itt is trükközni kell, bevett eljárás, hogy fognak pár fekete fehér map-ot, ahol az anyag jellemzőit egyetlen fekete-fehér skálán elfoglalt értékkel jelölik (például AO map, roughness map, metallic map), és ezeket egyetlen RGB kép különböző csatornáira teszik rá. Vörös csatorna lesz az AO érték, Zöld a felület érdesség, a Kék a fényvisszaverés mértéke például). Hopp mindjárt három map elfoglalja el egyetlen map helyét (RGB-nél ha csak egyetlen fekete fehér képet tárolsz, akkor az összes csatornán ugyanaz az érték lenne tárolva). Bár a PBR mint szabvány elég gyorsan elterjedt, az ilyen trükközések még mindig a játék programozók hatáskörébe tartoznak. A shaderek megoldásai, bonyolultsága esetleg befolyásolhatják, hogy miket érdemes összevonni, és miket kell külön hagyni.
*A PBR anyagokkal már meg lehet csinálni azt, hogy normal mapokkal együtt (amit az anyag tulajdonságokhoz csapnak, de az alapvetően 3D geometriát módosító/szimuláló map) anyag-csomagokat netes boltokban áruljanak, amit egyszerűen a szerkesztőbe húzva pontosan ugyanezt az eredményt kapd. És ezek digitálisan beszkennelt anyagok, nem jó kezű festők rajzolgatják az anyagokat, hanem erre való kamerákkal, lencsékkel szkennelik őket. Quixel megascans például. A mapok tile-osak, ami azt jelenti, hogy -elvileg- nem látsz vágást ha a csempék egymás mellett ismétlődnek, de azért vigyázni kell, mert a minta ismétlődés ettől függetlenül látványos lehet, ha túl kis, túl sűrű mapot használsz. Néhány éve ez elképzelhetetlen lett volna (és ezért néz ki manapság már mindegyik ugyanúgy. Ezek után most mivel tudsz villantani grafika terén? Csak a részletességgel és a belepakolt content-el).
Szóval nem egyszerű. Kívülről csak a végeredményt látni, és sokszor nem tudni, hogy a fejlesztők miért kényszerültek egyszerűsíteni egyik vagy másik anyagon/effekten. Azt soha nem feltételezném, hogy ők nem látják vagy nem értenének hozzá. Csak lehet hogy teljesen más a prioritásuk.
Afranc, ez megint kisregény lett... Na, megyek vissza dolgozni, GDP-t kell termelni :) -
#21382
Én annyit szeretnék elmondani, hogy a tököm tele van a kurva EDével.
Volt egy szögegyszerű kveszt, amit gyakorlásra csináltam magamnak. nem nagy vasziszdasz... de a peccselés után nem működik.
Hát menjenek a picsába. Uff.. -
#21381
Volt pár éve a Totalcaron egy teszt ahol a hazai benzinkutak prémium üzemanyagait hasonlították össze, többféle autóval. Megmérték fékpadon hogy mennyivel erősebb lett az autó, fogyasztás jobb-e, stb.
Az eredmény lesújtó volt, gyakorlatilag szinte mindenben rosszabb eredmények jöttek ki mint a gyárilag előírt üzemanyaggal.
(azt mondjuk nem tudom hogy a prémium 100 oktános benzint jelent-e, de valszeg).
Sajnos nem találom a cikket, lehet hogy nem is TC volt, majd utánanézek.
Utoljára szerkesztette: PhantomAss, 2016.11.08. 13:34:50 -
#21380
Kb én is így gondolom, de mivel a keveréket nem tudod jobban besűríteni, mert a fizikai méretek a hengerben nem változnak , nem lesz hosszabb a hajtókar, hogy magasabbra menjen és mivel ha az elektronika a kopogást meg akarja előzni ezért a jobb benzint a holtpont előtt jóval be fogja gyújtani, mielőtt öngyulladás lenne ezáltal elveszti a hasonló sűrítést is a 95höz képest.
Tehát nem nyer vele az ember semmit max a jobb égéshő miatt nem kokszosodik és megtisztítja a motort. -
Colos1357 #21379 Köszi, ezt így ebben a formában nem tudtam.
Repvez: Minél jobban be van sűrítve a keverék a gyújtás pillanatában (minél nagyobb a nyomása), annál jobb lesz a motor teljesítménye. A 100-as azért jobb, mint a 95-ös, mert jobban be lehet sűríteni. De ha nincs jobban besűrítve, akkor kb. ugyanott vagy, mint a 95-össel, mert csak a magasabb égéshője miatt lenne nagyobb a teljesítmény, de ez olyan kicsi különbség, hogy szinte nincs is.
A modern autókban van kopogásérzékelő, ami addig változtatja az előgyújtást, ahol éppen hogy nem kopog. (Ez a legideálisabb állapot) Ha ilyen autóba tankolod a 100-ast, akkor be tudja állítani a motort a computer, és két lehetőség közül lehet választani. Ezt nem tudom, hogy milyen autóknál van, és mi alapján választ, egyáltalán lehet-e, én csak az elméleti részét tudom, elméletileg pedig lehetséges.
1. lehetőség: a teljesítmény nyereséged megmarad, így ugyanannyit fogyaszt, de jobban megy.
2. visszavesz az adagolási mennyiségből annyit, hogy a teljesítmény megmaradjon. Így a kocsi ugyanúgy fog menni, de kevesebbet fog fogyasztani.
Fogalmam sincs, hogy a fentiek közül mit valósítanak meg. Logikusnak tartanám, hogy ha pl. sport módban van, akkor teljesítményre megy, takarékosban pedig fogyasztásra.
De az autógyártók nem túlságosan bőbeszédűek, ha a motorvezérlő elektronika programjáról van szó... -
#21378
Egyébként visszatérve az oktánszámokhoz, hétköznapi értelemben van értelme a 95 ös helyett a 100as benzint használni autóba, mármint ami 95ösre terveztek? Ha jól értem amit leirtatok akkor ha nincs átálitva a motor 100as üzemre akkor nem tudom kihasználni a nagyobb teljesitményt. Vagy már a mai fed komputerek autómatikusan állitják ezt?
Mert azt is mondják, hogy kevesebbet eszik a kocsi tőle, de az mitől ,mikor a keverék arány nem változik , adott fordulathoz adott mennyiségű levegő benzin megy függetlenül az oktántol.
Tehát miben nyujt többet egy hagyományos auban a jobb benzin. mert árban jóval drágább, de az elönyei nem biztos hogy annyival jobb. -
Kurfürst #21377 Jaja, valahogy így. A 109K-ban kétféle motor volt, a korai 1800 LE-s 605DM 1,75ata-s max. szívótérnyomással (100% MW nélkül: 1,35) MW befecskendezéssel, majd gyorsan váltotta a DB/DC jelű motor, növelt teljesítménnyel.
A DB és DC lényegében ugyanaz a motor, csak más beállításokkal, a B jelűt (ez van a DCS-ben) a 87 oktános B-4 üzemanyaghoz állították, ezzel tudott 1850 LE-t 1,8ata szívótérnyomáson. A normál teljesítmény 1430 LE 1,45ata szívótérnyomáson, 2600/min fordulat mellett, efölött kapcsol be az MW befecskendezés és azzal 1,8atáig lehet menni (illetve, pl. bejáratás alatt vagy MW nélküli üzemnél - az MW tankot a K-4en lehetett pótüzemanyag tartálynak is használni - max. 1,5 atáig bírja.). Elviekben lehetett volna csak magasabb, 100 oktános (150 es teljesítményszámú) C-3as üzemanyaggal is elmenni 1,8-ig MW nélkül is, de ezt úgy tudom később elvetették, nem is annyira a hengerfej, inkább a gyújtógyertyák túlhevülése miatt.
Nagyjából ez volt a limit, amit a motor 87 oktános üzemannyaggal a maga 8,5:1-es kompresszióviszonya mellett még kopogás nélkül elviselt, efölött a DC jelű beállítást és C-3 üzemanyagot kellett alkalmazni. Átállították a gyújtást, kompresszor vezérlést, kicserélték a gyertyákat és végül a szívótérnyomást 1,98ata-ra állították, ezzel 2000 LE-t lehetett elérni földközelben.
-
#21376
Igen utólag én is rájöttem, hogy nem volt pontos a leírás, de azért rá lehetett jönni , hogy mire is gondoltam.
Valóban nem az AO-ra gondoltam, hanem amit Tom is linkelt. Az AO az hozzáad egy kis látványt ,de az alap probléma hiányát nem oldja meg.
Sajnos ahogy nézem megfordulni látszik a folyamat ami a régi játékoknál jelen volt. Ott és akkor a grafikai hiányosságokat próbálták a játékmenettel és olyan technikai vívmányokkal megoldani amit csak ki tudtak préselni a hardwerből. Most meg szinte csak a grafikán van a hangsúly, bár a fenti probléma mutatja, hogy ez sem teljesen igaz.Csak most a játékmenet miatt ráér nézelődni az ember és nem feledkezik bele a játékba, hogy ilyen "kis" dolgok ne érdekeljék, meg már tisztába van vele az ember , hogy megoldhatóak a dolgok jobban is akkor miért nem teszik meg.
Amikor még csak gyerekcipőbe járt a 3d VGA ugyan ilyen szinten meg volt oldva az árnyékolás a fizika, az ami most megkülönbözteti az a részletesebb modell és a magas textúrafelbontás. pedig a mai VGA-k simán tudnák kezelni jobban az anyagjellemzőket kisebb textúrákkal vagy azok mellőzése nélkül is.
Nagyon jó volt ez az írás Tom, jó lenne több ilyen hétköznapi nyelven íródott dolgot olvasni a témákban, hogy megértse az ember a működésüket. -
#21375
Nekem a fekete színek nagyon hiányoznak a DCS-ből, ha az árnyékok sötétebbek lennének az már sokat dobna az összképen. -
#21374
Az AO effekt nagyon jót tesz a képnek, mert segít érzékelni a 3d modell kialakítását, de a valóságban ilyen sötétedés nincs (kivéve persze a spéci eseteket, amikor tényleg kosznak van felhasználva).
Az árnyék nem tud szóródni, a fény tud szóródni. Van a direkt és a diffúz fény. Az 1. pontot amit írsz, a vetett árnyékot a direkt fény okozza, pl a nap, vagy éjjel a lámpák. Ez így is van, ahogy mondod, ha a fény útját valami blokkolja, elnyeli vagy visszaveri, akkor mögötte már sötétben marad a tér (éjjel, vagy világűrben készített fotókon remekül látni).
A 2. pontban amit írsz, az a fényszóródás, a diffúz fény. Legjellemzőbb és kültéren a legjelentősebb az atmoszférán szétszóródó (eredetileg direkt fényként indult) fotonok bevilágítják a föld légkörét, ez nagyon erős diffúz fényt ad. Ettől nem lesz korom sötét az árnyékában, ezért látunk az épületekben akkor is, ha csak néhány ablak néz a szabadba. Röviden ennyi a különbség.
Hosszabban ez azért lesz jóval bonyolultabb dolog (ha már a játék és valóság különbségeiről van szó), mert visszaverődni nem csak levegő részecskéken tudnak, hanem minden testen (nyilván, hisz ezért látjuk őket), viszont ennek több paramétere is van. Első a visszaverődés mértéke. Ez az anyag felülettől nagyban függ, hogy mennyi energiát veszít. Pl a Szén keveset ver vissza, a fémek nagyon sokat (pontosabban a fémek 100%-ban visszavernek minden fényt, csak a kosz, kopás, felület érdesség viszi ezt az értéket lejjebb). Egy hosszú sötét folyosóra rányitott fényes helység egy ideig az ajtó körül megvilágítja a folyosót is, de az ide-oda pattogó fény hamar elnyelődik (talán ezt hívtad te mélységi árnyéknak?). Játékokban a reflection map vagy metallic map kezeli ezt. A második a felület (visszaverődés) színe. Egyes felületek bizonyos hullámhosszú fényt elnyelnek, másokat visszavernek. Piros labdát leteszel egy fehér fal mellé, a labdát érő fény nagy része elnyelődik, csak a vörös hullámhosszúak pattannak vissza, ezért halvány vörös elszíneződést kap a fal is (eleve a labda színét is azért látod vörösnek, mert csak a vörös fotonok verődnek vissza). Az anyagok színét a diffuse map vagy az albedo map tartalmazza. Játékok itt szoktak csalni, a visszavert fényt nem mindig színezik meg. Természetesen a tárgy színét normálisan mutatja a képen, de a mellette lévő anyagokra a kiindulási (pl fehér vagy sárgás) fény verődik "tovább". Spórolás van :) . A harmadik a visszaverődés iránya, ami a felület érdességétől függ. A nagyon durva felület sokfelé szórja a fényt, annak lesz pl. aluminium hatása, a sima felület (üveg, tükör) meg egy irányba veri vissza, ott a beeső fény akár változatlanul is tovább pattanhat (ekkor lesz belőle tükör). Ezt a roughness map alakítja ki, ez pl nagyon élethű eredményt ad, ha műanyagon kis koszt, matt foltokat akarsz megjeleníteni).
Ez a négy fő paraméter (fényforrás energiája, visszaverődés mértéke, színe, felület érdessége) alapvetően le tud írni bármilyen manapság használt anyagot*. Persze vannak még finomítások, a fresnel visszaverődés, amikor egy felületet nagyon lapos szögben nézve sokkal több fény verődik vissza, mint amikor magas beesési szöggel éri a fény (biztos volt már olyan veled is, hogy naplementénél, laposan szembe sütött a nap, és még az úttestről is visszaverte a fényt. Ez a fresnel hatás). Vagy a vékony anyagoknál a fény átszűrődése. Papírlap mögött lévő fények, viaszból készült tárgyak, vagy akár az emberi test vékonyabb részei - fülcimpa, újjak, satöbbik - mögötti fény is átszűrődik.
Vagy van egy komplett különálló téma, az áttetsző anyagok fénytörés renderelése, amihez már közeghatárokon megtörő fény torzulása, prizma és lencse hatások számolása kell. Játékokban csak a kromatikus aberráció effektet láttam (lencsehatású képnél a széleken a vörös és kék színek kissé szétcsúsznak), de pl BoS-nál a több cm vastag páncélüveg fénytörését már nem tudták megoldani (fénytörés miatt megemelte pár centiméterrel a nézőpontot, így a valóságban a pilóta tök jól ellátott a motor fölött (célzókészülék elhelyezésénél is beleszámolták ezt), viszont a játékban fénytörés nélkül a Revi közepe alig pár mm-el nézett a motorburkolat fölé - sok sikert célozni úgy :) )
*Itt egy nagyon fasza kis összefoglaló, hogyan működik ez PBR anyagoknál (lap alján van pár példa is, hogy mennyire fasza felületeket lehet ezekkel a mappokkal kialakítani): http://www.marmoset.co/toolbag/learn/pbr-practice
Na, jó hosszú lett, nem akartam ennyit írni, csak egyik téma vezet a másikhoz. :)
Utoljára szerkesztette: VO101Tom, 2016.11.08. 08:21:42 -
Colos1357 #21373 Lehet, hogy keverem.
Én úgy tudom, hogy renderelési szempontból kétféle árnyék van:
1. vetett, ami pl. egy fának, háznak az árnyéka. Egy sima sötét folt, ami csak az objektum geometriájától függ.
2. szórt árnyékok, ezek felelősek pl. a házak nappal ellentétes oldalának sötétségéért, az objektumok kölcsönhatásából eredő "árny-játékokért" - pl. ami a renderképeden is látható több helyen -, illetve az egyes objektumokon belül a mélységi árnyékokért. Úgy tudtam, hogy ezekért felel az AO.
Én amúgy ennek fejletlenségét annak tudtam be, hogy a map még csak alpha, és több ponton is észrevenni, hogy nagyon nincsen kész. -
#21372
Amiről Repvez írt, az látszik a feltöltött videódon is, csak nem fogalmazott jól. Az épületeknek van vetett árnyéka, csak ezek nincsenek interakcióban mással, csak a talajjal. A videódból szedtem ki ezt a kockát, látod azt az épületet lent? A mellette lévő magas épület árnyéka nem vetül rá, csak a talajra. Ezek az egyszerűsítések számolást spórolnak. Viszont ha megnézel egy képet, akkor zavaró lehet akkor is ha azonnal nem veszed észre. Az viszont igaz, hogy repvez linkelt képén ez alig látszik, nekem ott az egész képen használt matt anyagok sokkal zavaróbbak.
SPOILER! Kattints ide a szöveg elolvasásához!![]()
Az ambient occlusiont viszont kevered valamivel, az nem számol fényforrásokkal, nincs vetett árnyéka sem. A modellekre rakott sötétebb területeket csak a modell geometriából számolja. Összetartó felületeknél egyre sötétebb ahogy a felületek egyre közelebb kerülnek egymáshoz. Ez homorú szögeknél nem számol semmit és beállítástól függően már lehet, hogy tompa szögeknél sem. Vray renderelőben pl "Vray dirt"-nek is nevezik, mert végeredményben olyan hatást kelt, mint a résekbe ragadt kosz.
SPOILER! Kattints ide a szöveg elolvasásához!![]()
Az AO a játékokban használt PBR anyagok egyik alapvető map-ja, amit rengeteg helyen használnak. Repvez linkelt képén is és a te videódon is látni a házak tetején pl, a felüljáró korlátjánál stb. És azt is látni, hogy az épületekre rakott AO-nak sem a talajjal sem a közeli épületekkel nincs kapcsolata, mert amikor az AO mapot generálták, akkor valszeg egy-egy épület volt a szerkesztőben (lehetőség lenne ezt is valós időben generálni, hogy minden modell hasson a környezőkre is, az SSAO opció például ezt teszi (Clod-ban van ilyen), de az előre generált mapok betöltése jelentősen csökkenti a számolás igényt.
Utoljára szerkesztette: VO101Tom, 2016.11.07. 23:38:59 -
Colos1357 #21371 Jah, az teljesen más, az az ambient occlusion.
Egy videokártya zabáló, számításigényes folyamat, mert a szórt árnyékokat a VGA számolja ki rendereléskor, attól függően, hogy hol vannak a fényforrások, milyen az egyes objektumok geometriája és a felületek tükröződése, valamint figyelembe veszi azt is, hogy az objektumok milyen kölcsönhatásban vannak egymással.
Egy árnyéknál a fényforrás helyzete csak az árnyék helyzetét határozza meg, míg AO -nál - pl, egy épület oldalán - az árnyék sötétségét is.
Az tény, hogy ennél azért lehetne jobb. -
#21370
Pedig van az árnyékokkal is gond, ha megnézed jobban akkor az épületek árnyékos oldala is szinte olyan világos mint a napsütött és csak önárnyékok vannak vetett nincs, vagyis egy toronyház árnyéka nem jelenik meg egy mögötte lévő kisebb épületen. vagy a gép nem kerül az épület árnyékába mikor elrepül mellette
ÉS a felhőkarcolók is kb ugy néznek ki mint a tejes kartondobozok. -
Colos1357 #21369 Szerintem az árnyékokkal semmi gond, de szerintem csak beállítás kérdése. HD -ben éri csak megnézni. A szeméttube sokat rontott rajta...
Ja, és a kedvencem, amikor naplementekor repülsz. Akkor még árnyékot vet a nap is, de már számolja az éjszakai fények árnyékait is. Ilyenkor ott, ahol nappal vagy éjszaka 55...60 FPS van, leesik 5...10...15 FPS -re :D
Utoljára szerkesztette: Colos1357, 2016.11.07. 21:00:00 -
#21368
Itt szerintem a fények és csillogások azok, amiken elsősorban lenne mit csiszolni (a mai game enginek a reflection -vagy metallic- és roughness mapokat már elég jó sebességgel tudják kezelni). Nekem az árnyékok sem elég kortrasztosak, a napsütés is túl jellegtelen irányú és erejű, de ami nagyon hiányzik, az a talajon, gépeken játszó csillogások, elszíneződések. A fekete lehetne feketébb, a napfény meg lehetne erősebb és színezhetné jobban a dolgokat. Valahogy így:
SPOILER! Kattints ide a szöveg elolvasásához!![]()
![]()
itt meg a kortraszt, árnyékok ereje más, nem is kicsit.
![]()
A fókuszálás is segíthetne, bár azt játékokban nem használják, mert nehéz kideríteni, hogy a játékos épp mire akar fókuszálni, így marad minden tűéles (vannak próbálkozások, mint az Arma post process effects, de az is csak a cső előtt lévő dolgokra tud fókuszálni, ha a képernyőn máshova nézel, akkor az már nem stimmel). A légköri effektusok is teljesen ki szoktak maradni, jobb esetben kap a horizont egy kékes gradienst, de a légmozgás miatti torzulásokat elmosódásokat sem szokták beleprogramozni (tegyük hozzá pontos fénytörést (refraction) renderelni az egyik leginkább számolás igényes dolog).
SPOILER! Kattints ide a szöveg elolvasásához!![]()
Utoljára szerkesztette: VO101Tom, 2016.11.07. 19:46:16 -
#21367
Köszi, ez a doksi még nem volt meg. 
-
sakkay #21366 De rohadtul megbántam, hogy nem vettem meg most a messzát..most meg a youtubon bámulom a videókat -
Ludowik #21365 ![]()
Meg egy ilyet a csúnya árkád másik játékban ezek mind műxenek és a kezelőszervek is gomra rakva.
Utoljára szerkesztette: Ludowik, 2016.11.07. 19:08:37 -
Ludowik #21364 Bf 109 K-4
Manual Control
Mixer is not controllable
Pitch is controllable
has automatic pitch
Radiator (water) is controllable
Radiator (oil) is not controllable
Oil and water uses combined radiator control
Supercharger is not controllable
Turbocharger is not controllable
Compressor settings 1
Optimal Altitude
6900 m
100% Enginepower 1250 hp
WEP Enginepower 1775 hp -
#21363
A virtual tunder birds tett ki a FB oldalára pár képet:
![]()
ÉS végig néztem még pár másik képet is a 2.0ából, de ahhoz képest, hogy a gépek részletesek a táj és az épületek változatosak akkor is valami hiányzik a képekről amitől realisztikus hatást kelltene bennem és nem egy rajzfilmszerű matt temperával szinezett animációt látnék.
Nem tudom egyenlöre megfogni , hogy mi az amivel ezt javitani lehetne. -
#21362
Majd megnézem, bár a messzerrel sztem könnyű leszállni így is.
Kiváncsi leszek mennyivel másabb manuállal.
-
Colos1357 #21361 Akkor próbáld ki, hogy amikor final -on vagy leveszed manualra, és folyamatosan feltolod 12:00 -ra, figyelve arra, hogy a max. fordulatszámot ne érd el. Jobban lassul a gép, és ha hirtelen gázt kell neki adni, akkor ezt finomabban tudod megtenni, mert nem kezdi el b@sztatni a PP-t. Én is le tudok szállni autón, de manualban szerintem biztonságosabb. -
#21360
Úgy látom hogy ez nincs lemodellezve a DCS-ben, a messzernél sosem használom a manual pp-t leszálláskor és sosem szokott gond lenni.
