Falcon 4.0 - BMS 4.3X
Jelentkezz be a hozzászóláshoz.
#51806
ÉS nem is végletekre gondoltam, az , hogy a DCS teleteszi a rendelkezésre álló memoriát az nem jelenti azt, hogy nem megy el kevesebb memoriával is. Nem tudjuk, ha lenne olyan VGA amin 64gb memória van akkor azt is teletenné e, de ez nem jelenti azt , hogy 8GB al ne menne.
Az átlag játékostábor még mindig a 8gbot hasznbálja. ha hozzávesszük, hogy a BMS a töredékét teszi ki a modellek részletessége akkor a 8gb ott is elégségesnek kellene hogy legyen.
A BMS-nél ha sikerülne hatékonyan megváltoztatni a GPU+CPU közti feladatokat, akkor szerintem böven maradni kellene eröforrásnak az extra dolgokra is, ami nem azt jelentené, hogy a mostani gépek nem lennének képesek megfelelö sebességgel futtatni akár 4k-n is.
A további években meg ahogy gyorsulnak ,fejlödnek a hardverek és optimalizálják mindig lenne potenciál ezek bövitésére.
Mivel nagyon nagy változásokat mint a fizika és a sérülés modell nem nagyon várhatunk a közeljövöben igy a kisebb modositások kevésbé lesznek hatással a hardverek kihasználására.
Szemben a DCS-vel ahol mindig ujabb es ujabb hardvereket megizzasztó extra dolgokat pakolnak bele.
#51805
Sajnos sosem ültem éjszaka vadászgép kabinban, de ha visszaverődik a fény mondjuk baloldalról, akkor igen halványan, de a jobboldalon is látszana az MFD fénye.
De ennek modellezése tényleg elmebeteg szint lenne, mert a FOV miatt úgysem látszik a pilóta szemszögéből.
De ennek modellezése tényleg elmebeteg szint lenne, mert a FOV miatt úgysem látszik a pilóta szemszögéből.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51804
DCS-nek elég egy 8GB-os kártya? Melyik térképen, mennyi egységgel? Nekem 8GB-os kártyám van (MSI GTX 1070), még nem láttam, hogy a VRam ne lett volta teljesen feltöltve, de a 11GB-os Ti kártyákkal sem.
Én meg azt remélem, ha a BMS a DCS-hez képest extra fps-t fog produkálni, az nem fogják azonnal elqrni olyan fölösleges dolgokra, amik nélkül eddig is megvoltunk. Legyenek szép fények, normális anyagok és dinamikus árnyékok, de nem kell egyiknél sem átesni a ló túloldalára és annyi erőforrást elpazarolni, hogy utána a szimuláció csak vergődjön az alacsony fps miatt.
Én meg azt remélem, ha a BMS a DCS-hez képest extra fps-t fog produkálni, az nem fogják azonnal elqrni olyan fölösleges dolgokra, amik nélkül eddig is megvoltunk. Legyenek szép fények, normális anyagok és dinamikus árnyékok, de nem kell egyiknél sem átesni a ló túloldalára és annyi erőforrást elpazarolni, hogy utána a szimuláció csak vergődjön az alacsony fps miatt.
www.pumaszallas.hu
#51803
Ha csak a DCS-t nézzük összehasonlitva, akkor sajnos azért azt kell hogy mondjam, hogy a BMS fejlesztök limitált lehetóségeikkel, nem hinném, hogy azt a fajta részletességet elérnék , igy ha a DCS-nek a 8gb VGA elég a több 100k modellekhez a 4k texturákhoz akkor a BMS-nek is elégnek kellene hogy legyen, söt.
ÁS itt lehet az amivel egy kicsit a dcs hez képest elönyt szerezhetne.
Tehát ha maradna kellö eröforrás tartalék akkor ahogy az elöbb emlitettük, több fényforrás több árnyék , esetleg több részecske szimuláció stb kerülhetne bele amit a DCS nem tud a véges erőforrás miatt meglépni .
A Vulkán meglátjuk mennyire fogja tehermentesiteni EDé-éket.
ÁS itt lehet az amivel egy kicsit a dcs hez képest elönyt szerezhetne.
Tehát ha maradna kellö eröforrás tartalék akkor ahogy az elöbb emlitettük, több fényforrás több árnyék , esetleg több részecske szimuláció stb kerülhetne bele amit a DCS nem tud a véges erőforrás miatt meglépni .
A Vulkán meglátjuk mennyire fogja tehermentesiteni EDé-éket.
#51802
Igen, az anyagtulajdonságok slotjai egymástól teljesen függetlenek, lehet rajtuk akár más textúra méret is, vagy egyszerű szám paraméter is.
A Dx9-10-11-12 engine-ek közt a legnagyobb különbség nem a shaderek (oké, a grafika is többet tud), ami igazán fontos, az a sebesség (ezért kukázták a Dx9-et VR alól). A BMS az új Dx-el biztos gyorsulni is fog, viszont a sokkal részletesebb térkép meg biztos több erőforrást is igényel majd, eleve a PBR anyagoknak is több erőforrás, SOKKAL több videokártya memória kell, mint a hagyományos anyagoknak.
A Dx9-10-11-12 engine-ek közt a legnagyobb különbség nem a shaderek (oké, a grafika is többet tud), ami igazán fontos, az a sebesség (ezért kukázták a Dx9-et VR alól). A BMS az új Dx-el biztos gyorsulni is fog, viszont a sokkal részletesebb térkép meg biztos több erőforrást is igényel majd, eleve a PBR anyagoknak is több erőforrás, SOKKAL több videokártya memória kell, mint a hagyományos anyagoknak.
www.pumaszallas.hu
#51801
Én is igy gondoltam, de ha jol tudom, akkor ha az egyik mappot kicserélem csak egyetlen szinre ami az engine által lesz használatos, attol még a többi mapot rátehetem pluszba. tehát attól, hogy az opaci map helyett csak egy szint használok attól még a karcokat tartalmazó map rákerülhet pluszba.
DE ha nem már akkor is , kevesebb helyre kell bonyolult texturákkal bajlódni, a munkahengerek cromfeluleténél, a rakéták uvegkupakjánál vagy a fények buráinál, mind olyan dolog, hogy nem kell plusz részlet csak az alap anyagra jellemző fő tulajdonság.
Egy másik dolog ami még hozománya lehet egy uj graf motornak, az pedig a modern erőforrások jobb kihasználása.
Mert manapság sztem, hiába tudja kezelni egy 2080ti VGA-t a dx9es motor , de nem biztos, hogy olyan hatékonyan mint ahogy lehetne.
Gondolok itt a SPU+VGA közti komunikációra is. Rengeteg olyan dolog lehet amit ma a CPU számol a GPU helyett, ami jelentős gyorsulással járhatna.
Vagy csak a CPU-k jobb mag kihasználását.
Nem hinném, hogy egy 98as alapokon nyugvó dx9re portolt program a mai rendszereken csak ennyire lenne képes, mikor ha a DCS-vel összehasonlítva töredék polygonbol , esetenként egyszerübb számításokból és kisebb texturákkal dolgozik.
Emiatt reménykedek, hogy az uj engineben lesz annyi felesleg a pluszba hozzáadandó featurokhoz, hogy még igy is jelentős sebességgel tudja majd futtatni.
DE ha nem már akkor is , kevesebb helyre kell bonyolult texturákkal bajlódni, a munkahengerek cromfeluleténél, a rakéták uvegkupakjánál vagy a fények buráinál, mind olyan dolog, hogy nem kell plusz részlet csak az alap anyagra jellemző fő tulajdonság.
Egy másik dolog ami még hozománya lehet egy uj graf motornak, az pedig a modern erőforrások jobb kihasználása.
Mert manapság sztem, hiába tudja kezelni egy 2080ti VGA-t a dx9es motor , de nem biztos, hogy olyan hatékonyan mint ahogy lehetne.
Gondolok itt a SPU+VGA közti komunikációra is. Rengeteg olyan dolog lehet amit ma a CPU számol a GPU helyett, ami jelentős gyorsulással járhatna.
Vagy csak a CPU-k jobb mag kihasználását.
Nem hinném, hogy egy 98as alapokon nyugvó dx9re portolt program a mai rendszereken csak ennyire lenne képes, mikor ha a DCS-vel összehasonlítva töredék polygonbol , esetenként egyszerübb számításokból és kisebb texturákkal dolgozik.
Emiatt reménykedek, hogy az uj engineben lesz annyi felesleg a pluszba hozzáadandó featurokhoz, hogy még igy is jelentős sebességgel tudja majd futtatni.
#51800
Oké, de HUD-nál és a FLIR-nél neked a HUD-ra kivetített kép a fontos, nem az, hogy a zölden világító HUD melyik krómozott felületről csillan vissza (még a zöld derengést is meg lehet oldani egyszerű emisszív anyaggal akár (pörgess bele ahol "fest" a fénnyel 2:30 környékén, meg hogy a végeredmény milyen), ami egy egyzserű PBR paraméter (vagy textúra), ahhoz sem kell raytracing. Raytracing akkor kell, ha a fényforrásból kiinduló fénysugarak pattogása, elnyelődése, szóródása a fontos neked, szerintem kabinbelsőben ennek semmi jelentősége.
Például egy vetítőgépet sem fogsz úgy szimulálni, hogy fogsz egy fényforrást, elé teszel egy fényáteresztő filmet, ami az így megszinezett fényt egy lencsén (lencse rendszeren) kereztül refractionnal és raytracinggal számolva fókuszálsz egy erősen fényvisszaverő felületre, amit majd látni fog a játékos. Hanem beteszel egy lámpát, ami odavilágít, ahol a képernyő látszana, és ugyanoda kiteszed a renderelt "végeredményt" is. Nemtom mennyire érthető mi a qrva nagy különbség ebben. A raytracing qrva jó néhány helyre, de a játékokban mindig egyszerűsíteni kell, mert valós időben ilyesmiket nem fogsz számolni.
Utoljára szerkesztette: VO101Tom, 2020.04.18. 00:57:56
Például egy vetítőgépet sem fogsz úgy szimulálni, hogy fogsz egy fényforrást, elé teszel egy fényáteresztő filmet, ami az így megszinezett fényt egy lencsén (lencse rendszeren) kereztül refractionnal és raytracinggal számolva fókuszálsz egy erősen fényvisszaverő felületre, amit majd látni fog a játékos. Hanem beteszel egy lámpát, ami odavilágít, ahol a képernyő látszana, és ugyanoda kiteszed a renderelt "végeredményt" is. Nemtom mennyire érthető mi a qrva nagy különbség ebben. A raytracing qrva jó néhány helyre, de a játékokban mindig egyszerűsíteni kell, mert valós időben ilyesmiket nem fogsz számolni.
Utoljára szerkesztette: VO101Tom, 2020.04.18. 00:57:56
www.pumaszallas.hu
#51799
A PBR bármelyik mapját lehetőséged van egyetlen színnel helyettesíteni (ha már itt tartunk, procedural mapokkal is, de proceduralt csak animált anyagoknál láttam eddig, ahova az egyszerű textúra a jellege miatt nem jó), ha nem akarsz az üvegen koszt, fényesebb és mattabb foltokat megjeleníteni, ami a felület microsurface-t, csillogást és végső soron az opacity-t is befolyásolja, akkor a textúra mapok helyett simán paraméterezheted egyetlen színnel is (bár szoktak ilyet csinálni elég gyakran, a végeredmény nagyon steril szokott lenni, ezért csak ott használják, ahol ez annyira nem lényeg).
A távcsőbe tett "lencse effekt" az nem ugyanaz mint a refraction, mert ott nem a lencse alakjából számolja a fénytörést a táncsövön átmenő fényből, csak simán a renderelt képre tesznek egy torzítás effektet, amit bármilyen videszerkesztő is tudott már 20 éve is. A fizikailag számolt fénytörés, szóródás ennél jóval bonyolultabb.
A távcsőbe tett "lencse effekt" az nem ugyanaz mint a refraction, mert ott nem a lencse alakjából számolja a fénytörést a táncsövön átmenő fényből, csak simán a renderelt képre tesznek egy torzítás effektet, amit bármilyen videszerkesztő is tudott már 20 éve is. A fizikailag számolt fénytörés, szóródás ennél jóval bonyolultabb.
www.pumaszallas.hu
#51798
Vagy a legjobb. a HUD. 😊
A Block 42-re felvetített FLIR kép, az aztán durva lenne.
A többi valóban statikus, arra pazarlás lenne.
A Block 42-re felvetített FLIR kép, az aztán durva lenne.
A többi valóban statikus, arra pazarlás lenne.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51797
Jogos, a képernyők igen, az dinamikus fényforrás. Én kabin fényekre gondoltam, visszajelző lámpák, kabinvilágítás, ilyesmik. Azokat lehet bakelni.
www.pumaszallas.hu
#51796
Hú, most pislogok egy nagyot. Egy TGP vagy SAR radarkép az nem fix fényforrás, mást bocsát ki.
Sötét szobában nézed a TV-t és máshogy világítja be a szobát. A kabinban is ezt tenné a MFD. Ráadásul, ha még játszol a fényerővel, vagy pl. mondjuk elmegy az áram, mert sérült a gép és kint süt a Hold.
A pilóta feje meg mozog.
Szép lenne no...
..meg olyan erőforrás igény, hogy beszarunk.
Kétszer.
Utoljára szerkesztette: molnibalage83, 2020.04.18. 00:05:43
Sötét szobában nézed a TV-t és máshogy világítja be a szobát. A kabinban is ezt tenné a MFD. Ráadásul, ha még játszol a fényerővel, vagy pl. mondjuk elmegy az áram, mert sérült a gép és kint süt a Hold.
A pilóta feje meg mozog.
Szép lenne no...
..meg olyan erőforrás igény, hogy beszarunk.
Kétszer.
Utoljára szerkesztette: molnibalage83, 2020.04.18. 00:05:43
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51795
Tudom , hogy azok a dolgok amiket felsoroltam, nem a PBR-hez tartoznak, de ahogy irtad szorosan kapcsolódnak is egymáshoz.
Az árnyékokra, meg pont ugy gondoltam ahogy irtad is, hogy a fontos részeknél legyen több fényforrásra is hatással, mig máshol pl egyáltalán ne.
Ezt ha jol tudom, lehet külön is szabályozni, hogy melyik tárgy vessen árnyékot és melyik ne még akár 2 fényforrás esetén is.
Igy lehet redukálni a számolást, de mégis megmarad a látszat. pl, az állohelyeken a leszállófény vagy a lámpák jó lenne ha tudna árnyékot vetni a gépeken, mert most csak fény van árnyék nincs.
az áttetszóségnél arra gondoltam, hogy ne texturával kellne meghatározni az átlátszando felulateket, hanerm a motorban lehetne definiálni az anyagot ami áttetszó pl kabintető, rakéták burái. tehát ha a modellt elkészited akkor csak az anyagot kell megadni hozzá, de nem kell textura rá, hogy átlátszó legyen.
A torzitásoknál se feltétlen kellene RT, a régebbi játékoknál is megoldották nélküle a nagyitók távcsövek eltérő torzult megjelenését
Az éjszakai viláfgitáshoz, nem hinném, hogy feltétlen szügséges a RT. oda is inkább az árnyékok kellenek, amik eddig nem nagyon voltak.
Ha több fényforrás van a kabinban az több irányba is vet árnyékot a kapcsolókon mutatókon, ez sztem több hatást ad vissza minthogy hogyan verüdik a fény a valóságban és ahogy tom is irta ezek fix dolgok felesleges dinamikusan számolni, viszont a mutatok azok mozognak és az árnyékok hiánya sokkal rosszabb.
Az NVG meg felesleges lenne fizikailag real time modellezni, ha a mostani is elég jó ahogy egy plusz szüró, van a rendes kép elött.
Az árnyékokra, meg pont ugy gondoltam ahogy irtad is, hogy a fontos részeknél legyen több fényforrásra is hatással, mig máshol pl egyáltalán ne.
Ezt ha jol tudom, lehet külön is szabályozni, hogy melyik tárgy vessen árnyékot és melyik ne még akár 2 fényforrás esetén is.
Igy lehet redukálni a számolást, de mégis megmarad a látszat. pl, az állohelyeken a leszállófény vagy a lámpák jó lenne ha tudna árnyékot vetni a gépeken, mert most csak fény van árnyék nincs.
az áttetszóségnél arra gondoltam, hogy ne texturával kellne meghatározni az átlátszando felulateket, hanerm a motorban lehetne definiálni az anyagot ami áttetszó pl kabintető, rakéták burái. tehát ha a modellt elkészited akkor csak az anyagot kell megadni hozzá, de nem kell textura rá, hogy átlátszó legyen.
A torzitásoknál se feltétlen kellene RT, a régebbi játékoknál is megoldották nélküle a nagyitók távcsövek eltérő torzult megjelenését
Az éjszakai viláfgitáshoz, nem hinném, hogy feltétlen szügséges a RT. oda is inkább az árnyékok kellenek, amik eddig nem nagyon voltak.
Ha több fényforrás van a kabinban az több irányba is vet árnyékot a kapcsolókon mutatókon, ez sztem több hatást ad vissza minthogy hogyan verüdik a fény a valóságban és ahogy tom is irta ezek fix dolgok felesleges dinamikusan számolni, viszont a mutatok azok mozognak és az árnyékok hiánya sokkal rosszabb.
Az NVG meg felesleges lenne fizikailag real time modellezni, ha a mostani is elég jó ahogy egy plusz szüró, van a rendes kép elött.
#51794
Lehetne kabinban is használni (fénytörésre pl), de az eléggé statikus környezet, az előre definiált, bakelt fényekkel is nagyon szép végeredmény kapható, mivel a mozgó alkatrészeken kívül a kabinbelső geometriája és a fényforrások helyei elég állandóak. Raytracingot például olyan effektekkel reklámozták, hogy lövöldözős játékban az autó mellett felrobbant egy gránát, és te az autó fényezésén láttad a robbanás tükörképét, és bár eddig is voltak helyettesítő megoldások, ilyet realtime játék eddig nem tudott. Ezt már nem tudod bakelni (előre eltárolni), mert nyilván az teljesen kiszámíthatatlan előre, hogy egy lövöldözős játékban mi fog egy autó mellett történni, és azt ki és honnan fogja látni. Egy kabinbelsőben ülő pilóta ennél jóval egyszerűbb helyzet.
Utoljára szerkesztette: VO101Tom, 2020.04.17. 21:06:28
Utoljára szerkesztette: VO101Tom, 2020.04.17. 21:06:28
www.pumaszallas.hu
#51793
Az éjszakai kabinvilágításnál ütne nagyon a RT. Meg az FPS az egy számjegyet, az fix.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51792
Igen, mindennek kell cserélni a textúráját, de az új talaj engine nyilvánvalóan teljesen új textúrákkal fog jönni, hiszen az a lényege, hogy másképp működik, mint a jelenlegi térkép engine, és teljesen értelmetlen lenne valamit nulláról megcsinálni nem PBR anyagokkal, ha már most tudják hogy úgyis azt fognak használni hozzá. A térkép nyilván a kornyezetet és az épületeket is teljesen meg fogja változtatni. Ami kérdéses, azok a járművek, repülőgépek, ezeket nem feltétlen kell kukázni és újat gyártani, és ezeknél lehet átmeneti idő, amíg a régi textúrákat folyamatosan lecserélik.Remélem, hogy tényleg igy lesz, mert az nem csak a kabinokra lenne igazán jó hatással, de a gépek és a környezetre is. Persze ahhoz az kellene, hogy mindenen kicseréljék a texturákat a megfelelöen beállitott PBR verzióra.
Meg az se lenne hátrány, ha a motor a fény árnyék dolgok kezelését is megváltoztatná. mert semmit nem ér egy trealisztikus anyag ha a fényeket nem kezeli megfelelöen. türözödö felületek fényáteresztés, soft, hard shadow. nem csak a napbol érkező fény vetne árnyékot.. stb.
Itt most egy szuszra azért felsoroltál pár tulajdonságot, amiket azért nem árt külön venni. A PBR anyagoknak semmi értelme nem lenne normális fények nélkül, hiszen az egész anyaghasználat a felületek fénnyel történő interakciójáról szól, hogy az legyen olyan élethű, amennyire lehet. Régi engine a mapokat sem tudná megfelelően értelmezni, szóval az anyagok és az anyagfelületek megjelenítése biztosan fejlődni fog, azokkal szerintem nem lesz gond (nagyon kiforrott standard megoldások vannak már ezekre, ez a PBR egyik nagy előnye programozó szemszögéből).
Az árnyékokkal viszont óvatosan kell bánni, az megint egy nagyon számolásigényes feladat, ha mondjuk egy előtted elterülő város minden egyes épületének, vagy egy erdő minden egyes fájának vetett árnyékot akarsz számolni, amik még rávetülnek a mellettük lévő objektumokra is, stb stb. Ezért szokták ezeket külön definiálni, hogy pl a kabint lehessen részletes fény-árnyékokkal megoldani, a talajra meg kiválaszthasd, hogy mit bír a géped. Ez érinti a használható fényforrások számát is, minden egyes fényforrás extra számolást igényel, az árnyék minőségére pedig a shadow map mérete van hatással, aminek vannak hátrányai, de még mindig a leggyorsabb az összes opció közül.
Áttetszőség eddig is volt játékokban, opacity mappal egész jól kontrollálható, ha az SSS-re gondolsz (subsurface scattering), az már bonyolultabb kicsit, de szerintem repszimben ennek semmi értelme, ez karakterek anyagainál néz ki nagyon jól, ahogy az elvékonyodó bőr fényáteresztését rendereli pl. Ami a fénytörést (refraction) illeti, az viszont az egyik legbonyolultabb számolás, ami nem csak a felületre eső bevilágítást, hanem minden más tárgyról érkező fényt is megtöri, ráadásul a torzítás számolásához kell a lencseként működő felület geometrikai modellje is... raytracing nélkül nem tudsz ilyet renderelni, de még raytracing alatt is necces ezt realtime-ban mutatni, pedig ez például repszimben qrva jó lenne, hogy a hajlított kabintető, vagy a qrva vastag péncélüveg torzítását kiszámolná. Ezt teljesen biztosan mondom, hogy raytracing nem lesz az új BMS-ben, 20xx sorozatú kártya alatt semmi nem is kezeli, és még ott is hosszú évekre vannak a kiforrott, ésszerűen használható hardvertől/szoftvertől. Igaz ez minden más effektre is, ami dinamikusan pattogó fényekkel számolódik, dinamikusan tükröződő felületek, dinamikus árnyékok, stb.
Utoljára szerkesztette: VO101Tom, 2020.04.17. 20:34:17
www.pumaszallas.hu
#51791
#51790
Ha a graf motorban minden adott a használatára akkor lényegében igen .Egy régi texturát ugyan ugy megjelenit mint most, de ha kicseréled a PBR verzióra kkor sokkal jobb eredményt ad.
És ezt akár külsösök is meg tudnák csinálni ahogy most is, ha meg van a megfelelö textura minta hozzá.
És ezt akár külsösök is meg tudnák csinálni ahogy most is, ha meg van a megfelelö textura minta hozzá.
#51789
Azt bármikor meg lehet csinálni később. Gondolom én. Akkor csak az "átkonvertált" textúra más kinézetet ad a játéknak. Addig meg maradna a mai egyes területeken.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51788
Remélem , hogy tényleg igy lesz, mert az nem csak a kabinokra lenne igazán jó hatással, de a gépek és a környezetre is. Persze ahhoz az kellene, hogy mindenen kicseréljék a texturákat a megfelelöen beállitott PBR verzióra.
Meg az se lenne hátrány, ha a motor a fény árnyék dolgok kezelését is megváltoztatná. mert semmit nem ér egy trealisztikus anyag ha a fényeket nem kezeli megfelelöen . türözödö felületek fényáteresztés, soft, hard shadow. nem csak a napbol érkező fény vetne árnyékot.. stb.
Meg az se lenne hátrány, ha a motor a fény árnyék dolgok kezelését is megváltoztatná. mert semmit nem ér egy trealisztikus anyag ha a fényeket nem kezeli megfelelöen . türözödö felületek fényáteresztés, soft, hard shadow. nem csak a napbol érkező fény vetne árnyékot.. stb.
#51787
Már volt erről szó, asszem pont I-Hawk írta, hogy az új grafikai engine PBR anyagokat fog használni.
www.pumaszallas.hu
#51786
Hát, akkor ha az új motorba ezt nem szánják bele és nem tudja, ha valami licenszelt cucc, akkor ez a don't hold your breath lesz a BMS számára.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51785
A legfontosabb különbség, hogy a PBR nem csak több textúrára, több paraméterre bontja fel az anyagot, de azokat sokkal inkább a valódi anyagtulajdonságok alapján modellezi, ezért sokkal élethűbb a végeredmény, ahogy a fényben az anyag felülete viselkedik. Előnye még, hogy realtime alkalmazásokban is elég gyors. Hátránya viszont, hogy rengeteg videokártya RAM kell neki.
A 3D modell nem tárol anyagot, csak azt az információt, hogy melyik poligonon melyik anyagot jelenítse meg, az un. UV map meg azt írja le, hogy az adott kiterített textúra mely része tartozik oda. Az engine-nek ezt nyilvánvalóan támogatnia kell, a PBR anyagokkal csak akkor tudsz régi játékot feljavítani, ha a grafikai engine, a shaderek át vannak írva, hogy melyik anyag melyik textúrája milyen tulajdonságot takar és azt hogyan jelenítse meg.
A 3D modell nem tárol anyagot, csak azt az információt, hogy melyik poligonon melyik anyagot jelenítse meg, az un. UV map meg azt írja le, hogy az adott kiterített textúra mely része tartozik oda. Az engine-nek ezt nyilvánvalóan támogatnia kell, a PBR anyagokkal csak akkor tudsz régi játékot feljavítani, ha a grafikai engine, a shaderek át vannak írva, hogy melyik anyag melyik textúrája milyen tulajdonságot takar és azt hogyan jelenítse meg.
www.pumaszallas.hu
#51784
Köszi. Bár ebből nem igazán értettem meg, hogy mitől más ez a textúra ahhoz képest, hogy mi volt korábban, vagy ha a 3D modell (?) tárolta az adatot. Akkor itt is az engine a lényeges mögötte. Ha nem támogatja, akkor semmit sem ér.
Mennyire széleskörű ez a támogatást? Kiadott játékokra is applikálják már ezeket, vagy lényegében csak új/újraírt engine-ek tudják ezt kezelni?
Mennyire széleskörű ez a támogatást? Kiadott játékokra is applikálják már ezeket, vagy lényegében csak új/újraírt engine-ek tudják ezt kezelni?
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51783
Az anyagtulajdonságokat a régebbiek is tárolták (specular-glossiness mapok), a nem realtime renderekkel is már nagyon régóta lehet rohadt szép képeket csinálni (építészeti látványtervek pl) de kissé más módon kellett paraméterezni, és nem volt ennyire elterjedt a sztenderd sem. A PBR anyagok viszont a fémeket és a csillogásokat sokkal szebben kezelik mint a régebbi játékok, de ez már a shaderek (grafikai engine) miatt is van, nem csak az anyagok miatt.
Az elterjedt sztenderd másik rohadt jó hozadéka, hogy ma már rengeteg előre elkészített, beszkennelt anyagot lehet vásárolni, amikről tényleg nem mondod meg, hogy fotó vagy render. Pl ezek: https://quixel.com/megascans. Az, hogy a játékban is ez így nézzen ki, csak erőforrás kérdése innentől, ezeket a quixeles szkennelt anyagokat pl az unreal4 engine csont nélkül használja (UE4-is ingyenes amíg nem keresel vele pénzt, ha van UE4 regisztrációd, akkor ahhoz a quixel is ingyenes. Akár hobbiból is lehet szórakozni vele, ha valakit ez érdekel).
Pl ez a tutorial egy óra alatt csinál nulláról egy komplett erdős utat, csak UE4 és Quixeles scannelt modellekkel. Ilyet régebben esélytelen volt, hogy ennyi idő alat összerakj (oké, ehhez kell már az Unreal4 is).
Az elterjedt sztenderd másik rohadt jó hozadéka, hogy ma már rengeteg előre elkészített, beszkennelt anyagot lehet vásárolni, amikről tényleg nem mondod meg, hogy fotó vagy render. Pl ezek: https://quixel.com/megascans. Az, hogy a játékban is ez így nézzen ki, csak erőforrás kérdése innentől, ezeket a quixeles szkennelt anyagokat pl az unreal4 engine csont nélkül használja (UE4-is ingyenes amíg nem keresel vele pénzt, ha van UE4 regisztrációd, akkor ahhoz a quixel is ingyenes. Akár hobbiból is lehet szórakozni vele, ha valakit ez érdekel).
Pl ez a tutorial egy óra alatt csinál nulláról egy komplett erdős utat, csak UE4 és Quixeles scannelt modellekkel. Ilyet régebben esélytelen volt, hogy ennyi idő alat összerakj (oké, ehhez kell már az Unreal4 is).
www.pumaszallas.hu
#51782
Jól értem, hogy a textúra lénygében tárolja az anyagtípus sajátosságait, amit a motor számításba vesz?
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51781
Phisical Based Rendering rövidítése. Modern anyagtípus, kb. minden korszerű játék ezt használja már.
www.pumaszallas.hu
#51780
Mi az a PBR?
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51779
Én akkor érzem azt, hogy a többi modell 3D-re is ráférne javítás, amikor esetleg falszállás előtt a közelben taxiznak. Repülés közben nagyon ritka, hogy bármilyen gép közel jöjjön, saját az elkülönítés miatt, ellenséges meg addigra már le van lőve (vagy ernyőn lógok, de végeredményben mindegy miért). Néha van, hogy tanker mögött sorba kell állni, na akkor pl látok sajátot is közelről. De én úgy vagyok vele, ha megcsinálják, akkor jó, ha nem, akkor sincs tragédia.
Viszont egy felújított PBR anyagos kabinbelsőért, főleg ha VR-t is tudna, azért bármennyit fizetnék is <#alien>
Utoljára szerkesztette: VO101Tom, 2020.04.17. 03:05:31
Viszont egy felújított PBR anyagos kabinbelsőért, főleg ha VR-t is tudna, azért bármennyit fizetnék is <#alien>
Utoljára szerkesztette: VO101Tom, 2020.04.17. 03:05:31
www.pumaszallas.hu
#51778
Holnap megszámolhatom, de a hadjáratokban használt gépek szerintem kb. 60%-*a már újabb modellel bír, messze nem a balta faragás kategória.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51777
Elég lenne, de sajnos a gépek töredéke rendelkezik csak ehhez hasonló modellel, kb a 80%a a gépeknek egy baltával faragott valami amire nagy jóindulattal lehet ráfogni , hogy az a tipus. És sajnos a legtöbb feljavitott model az olyan modell amit nem gyakran lát az ember kampányban amiket meg igen azoknak van alacsony poligonszámú modellje
Meg ez a kép nem mond semmit a játékban való felhasználás jóságáról, mert ez a modell is lehet akár 300k poligonszámú és lehet egy ennél részletesebb modellt is készíteni ami a mostani 30k értékeknek is megfelel.
Meg ez a kép nem mond semmit a játékban való felhasználás jóságáról, mert ez a modell is lehet akár 300k poligonszámú és lehet egy ennél részletesebb modellt is készíteni ami a mostani 30k értékeknek is megfelel.
#51776
Ez most nem így van, JanHas modelleket amikor LOD Editorral kellett 4.33 alá installálni, ott külön modell volt az a szárny, amit a kabinból látsz, a külső modelltől függetlenül kellett installálni (és ha valaki akarta, akár a külső modelltől függetlenül is feltehette).
www.pumaszallas.hu
#51775
Kb. ez az átlag részletesség, amire szüksége van a egy gépnek, amit AI irányít. Ez alapján TGP és minden más simán jó. Sőt, ahhoz még ekkora felbontású LOD sem kell...
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51774
A skinezésnél sem festettem külön semmit. Ami a gépre került, azt láttam a kabinból is.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51773
Nincs wing section tudtommal. Az a 2D kabinnál volt legfeljebb. Minden, amit a kabinból kifelé látsz az a gép 3D modellje.Tudom, mert a kabin integrálás egy részét anno én csináltam a 4.32 mod-ban. Csak a kabinnak volt 3D modellje. Semmi mást nem importáltam be.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51772
Az elméletét értem, a folyamatnak, Pont ezért irtam, mert a linkelt kabinnál láthatólag nem a kulsö modelbol indultak ki .
Igy a kettő közötti rések et valahogy el kell tüntetni.
Azt tudom, hogy a falconban külön készül a külsö 3d model és van a kabin plusz egy wing section, amit a kabinból látni.
De más szimulátornál nem hallopttam hogy lenne csak egy külön szárny modell a belsü nézethez.Ott az engine megoldja a nem látható részek eltávolitását vagyis azzal nem számol .
Igy a kettő közötti rések et valahogy el kell tüntetni.
Azt tudom, hogy a falconban külön készül a külsö 3d model és van a kabin plusz egy wing section, amit a kabinból látni.
De más szimulátornál nem hallopttam hogy lenne csak egy külön szárny modell a belsü nézethez.Ott az engine megoldja a nem látható részek eltávolitását vagyis azzal nem számol .
#51771
Értem.
Az utolsó mondat az durva.
Az utolsó mondat az durva.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51770
Én ezt arra mondom, hogy CloDhoz semmilyen segédprogram sincs, nincs olyan maxos plugin, amivel pl hookokat, kapcsolókat, animációkat el lehetne készíteni. A programozó szépen leül és tíz kicsi ujjával bepötyögi, hogy melyik objektum melyik tengelyen mennyit mozdul vagy fordul ha ez vagy az történik. Kézzel írják meg az ini fájlokat, hogy a kabin melyik szerkezete egyáltalán mire való és mit csinál, ahhoz milyen hang tartozik, stb. Persze a működési elv, az közös, és azt a program más része tartalmazza, de a paraméterezés az kézzel történik. Volt pár belsős próbálkozás, hogy importer programot gyártsanak hozzá, de sem a TFS vezetése, sem az 1C nem volt elragadtatva az ötlettől, hogy olyan program készüljön, ami programozók nélkül is engedi a moddolást, eleve a program fájlok is titkosítva vannak, ahhoz mindenképp a forráskód kell, hogy a programkód módosítható legyen, azt viszont még TFS-en belül is hat lakat alatt őrzik (nekem sincs hozzáférésem, nincs is szükségem rá). Szóval egyrészt igen, bonyolultabb és nehézkesebb, több ember munkája kell hozzá, másrészt ez valamilyen szinten szándékos is. Biztonságosabb, hogy a kódot nem használja más (tudunk róla, hogy már megpróbálták feltörni, és alternatív TF peccset elterjeszteni, de nem sikerült nekik).
www.pumaszallas.hu
#51769
Általában a külső modell készül el előbb, amikor a 3D modellt kezdik modellezni, akkor abból a fájlból indulnak el, amiben a külső modell legrészletesebb változata van. Amikor kabinbelsőbe ül a játékos, akkor a külső modellen bármilyen részletet el lehet tüntetni. Pl a kabinbelső kialakítása ilyen, az mindig jóval egyszerűbb mint a kabinbelső nézet, az teljesen különálló elemként marad a modellben, és amikor belső nézetre vált a játékos,akkor a low poly változat lekapcsolódik, a belső nézetes kabinbelső megjelenik. Ugyanezen az elvvel ki lehet cserélni olyan részeket is, amik esetleg kabinbelsőből nézve túl low poly modell lenne, pl az orr kabinból látható része ilyen, a kabintető kerete ilyen, esetleg még más, amit a 3D modellező fontosnak lát. Csak arra figyelni kell, hogy a high poly modellek is pontosan ugyanazt a textúrát használják, mint a külső modell. Egyébként ezt is importnál állítja be a programozó, hogy mely elemek tűnnek el belső nézetből. A kabinkeret és a low poly külső találkozása általában nem gond, mert a kabinbelső nézetből ritkán lehet a kabin külső falát látni, bentről meg csak a peremet látod. Ha valami nagyon nagy gáz lenne a találkozásnál, akkor meg meg kell nézni, hogy valamelyik modell hibás-e, esetleg a külső modellt azon a szakaszon kicsit több poligonból kell kialakítani a határokat.
www.pumaszallas.hu
#51768
Melyik részt hogy értem?
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51767
Lehet ezzel újat mondok, de a jelenlegi Falconos megoldás sokkal moddolás barátibb, mint pl a CloD.
Ezzel most sokkoltál.
Ezzel most sokkoltál.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51766
Ha erre a kabinra gondoltál akkor neki küldtem képeket és rajzokat, de tavaly óta nem is jelentkezett a forumba sem.
Mondjuk ha az akit találtam neten róla akkor lehet valami IRL meló közbeszólt. MOZI filmekhez CGI dolgokat készit .
A modellhez passzolást meg ugy értettem, hogy megcsinálja a high poly kabint és hogy illesztik ossze a low polz külsővel?
Oké, hogy két külön modell ,de a kabinbol kinézve, gondok lehetnek a törzs találkozásánál.
Nem a texturákra értettem.
@Molni : ezt hogy érted?
Utoljára szerkesztette: repvez, 2020.04.15. 20:58:43
Mondjuk ha az akit találtam neten róla akkor lehet valami IRL meló közbeszólt. MOZI filmekhez CGI dolgokat készit .
A modellhez passzolást meg ugy értettem, hogy megcsinálja a high poly kabint és hogy illesztik ossze a low polz külsővel?
Oké, hogy két külön modell ,de a kabinbol kinézve, gondok lehetnek a törzs találkozásánál.
Nem a texturákra értettem.
@Molni : ezt hogy érted?
Utoljára szerkesztette: repvez, 2020.04.15. 20:58:43
#51765
Nem az a lényeg, hogy minden épület 3D. A baj az, hogy ha te direkt importálást csinálsz, akkor nincs két egyforma épület...
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51764
Én azért szerettem a saját 80-s modban F-15-tel repülni. a DPRK erőkkel szemben úgy érezted magad, mint valami király. Ha meg jött a 29-es szembe, akkor kezdődött csak a tánc.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51763
Ok, félreérthető volt, ezért idéztem be az eredeti szöveget. Ha I-Hawk tényleg ezekkel a szavakkal mondta volna, hogy "három éven belül készen leszünk", az nagy gáz lenne mert az azt jelentené, hogy jelenleg is még években számolnak.Én sem ugy értettem, hogy fix 3 év mulva lesz kész, hanem 3 éven belül, ami jelenthet 3 hónapot is.
A térképnél azon is mülik, hogy texturából akarják lefedni a mesht vagy procedurális megoldással adnak neki mintát.
Már nem először olvasom tőled ezt, most is mondom, a procedural megoldások BORZALMASAN számolás igényesek, mert nagyon kevés adatból dolgozik, de azokat valós időben kell kiszámolnia, újra és újra. Ha festenél PBR anyagokkal, akkor látnád, hogy egy-egy komplex anyag hány tucat layerből áll, rengeteg automatizált és generált effektekkel, amikből nagyon sok számolással generálják le a végleges PBR anyagokat. Amiknél még így is annyira fontos a gyorsaság, hogy pl a dds fájlformátumot is azért fejlesztette ki az nvidia, hogy optimalizálja a textúra directX-be töltés idejét. Nem véletlen, hogy ma az összes nagy játék engine PBR anyagokat használ, mert a komplex anyagtulajdonságokat standard módon tároló textúrákból egyszerűen beolvasni a végeredményt a leggyorsabb megoldás.
Vannak nagyon jó térképkészítő pluginek, de repszimnél az a probléma, hogy a textúrának akkor is jól kell kinéznie, ha a talajon állsz és akkor is ha fent repülsz pl. 8km magasan. A 60x60km-es területnél ami megvolt párszáz megából, ott mekkora volt a talajra jutó felbontás? Mondjuk 1x1 méteres talaj szegmens hány pixelt kapott?Probáltam már egy két ilyen plugint és google earthből egy 60x60kmes terület megvolt pár száz megábol texturásan.
Nekem a BMS elég közösségi elvűnek tűnik, de az is igaz, hogy a hobbi projecteknél azért nehéz feladatot kapni, mert mindenki azért dolgozik benne, amit ő szeret csinálni. De ha felteszel egy fasza kis portfoliót, hogy miket csinátál eddig, és keresel olyan "megbízókat" akiknek modell kell a modjukhoz de nem tudnak modellezni, biztos vagyok benne, hogy lesz aki jelentkezik.A célpontnak számitó épóleteket kellene külön modellezni. Ezekhez lehetne felajánlani a közösség segitségét, hogy aki tud az a meghatározott paramétereken belül csináljon hidat erőmüvet stb.
Ehhez nincs hozzáfűzni valóm, nem vagyok programozó, én elhiszem ha azt mondják nekik ez a jó.DXel kapcsolatban , csak annyit, hogy ha hosszutávra gondolkodnak...
Szorri, itt elvesztettem a fonalat, kinek küldtél és mit?Az ilyen nagyon igéretesnek tünö dolgok sajnos mindig elhaltak eddig. én is küldtem neki referencia képeket hozzá , de nem is válaszolt.
Egy új grafikai engine nem azt jelenti, hogy a korábbi textúrákat azonnal ki kell dobni. Az új engine általában kibővített tulajdonságokat kap, ha valaminek egyszerű textúrája van, az addig marad azzal, amíg valaki nem cseréli (a szükséges, de hiányzó mapokat ilyenkor un. placeholder mapokkal helyettesítik, kap egy üres normal mapot, egy átlagos roughness és metallic mapot, a base colort meg betölti a régi diffuse-ról). Nem lesznek rajta az újítások, de nem is lesz bugos, vagy használhatatlan sem. clodban pl a repülőgépek és a minden más két teljesen más logikával, és normal mapos megoldásokkal dolgoznak, még csak nem is ugyanazokat a channeleket használja a különböző mapokhoz. Ez csak programozás kérdése, hogy az engine különbséget tud tenni köztük, az egyikre több erőforrást enged, a másikat inkább gyorsan de egyszerűbben számolja ki.Meg ha elkészül , biztos , hogy teljesen passzolni fog a régi modellhez? Ha az uj engine támogat több texturázási fajtát vagy PBR-t is, akkor azért lenne pár olyan rész kivül is ami jó lenne ha nem csak trükkel lenne ott hanem valós 3d-s elemként. Ha a fényeket máshogy kezeli az uj motor akkor az összes gépem ,módosítani kell a textura helyett a fényeket.
Teljesen biztos vagyok benne, hogy ez nem fog változni. Clodhoz pl még pluginunk sincs, a maxos modellből a programozók kézzel importálnak minden repülőt és járművet a játék alá. Itt a modellező élete egyszerűbb, mert neki "csak" modelleznie, textráznia kell, meg elhelyezni a szükséges tecnikai kiegészítéseket, hook-okat, viszont az importhoz kell egy programozó is, aki összefésüli a kóddal a gép fícsöreit, le is animálja az alkatrészeket (3D-ben csak a pivotokat tudjuk betenni, semmi mást nem lehet maxból átvinni). Lehet ezzel újat mondok, de a jelenlegi Falconos megoldás sokkal moddolás barátibb, mint pl a CloD.A kezelés alatt nem a másfajta kabinokat értem, hanem , hogy könnyebb és egyszerübb legyen a módosításokat beleimportálni a mostani pluginok helyett.
Egyszerübb DOF rendszert, egyszerübb linkelést a különálló elemekhez stb.De már az is nagy könnyebbség lenne ha nem 3-4 különálló programot kellene használni hozzá minden egyes modositás után végig konvertálgatni oda vissza.
Utoljára szerkesztette: VO101Tom, 2020.04.15. 20:45:15
www.pumaszallas.hu
#51762
2 hónapja szólt Dee Jay a Korea '80s MOD kapcsán, hogy annyira nagyon ne kapkodjak, ha nagy munkában gondolok, mert lehet, hogy jön a 4.35, de nem ilyen konkrétan.
Megkérdezem, hogy 5-6 hétről, vagy 5-6 hónapról beszélünk. Az utóbbira mondta, hogy realitás lehet. Ezért kezdtem el a MOD-ot. Még, ha újra is kell csinálni, legalább tudjuk mit. Meg közben lett egy DB bug is találva a F-104DJ-nél.
Megkérdezem, hogy 5-6 hétről, vagy 5-6 hónapról beszélünk. Az utóbbira mondta, hogy realitás lehet. Ezért kezdtem el a MOD-ot. Még, ha újra is kell csinálni, legalább tudjuk mit. Meg közben lett egy DB bug is találva a F-104DJ-nél.
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. Intel Core i5-4690K 3.5GHz, GTX 960 4GB, 16 GB DDR3 1600 MHz https://htka.hu/author/molnibalage/
#51761
Ja, ezzel nincs is vita, ED-nek üzletileg nagyon megéri a jelenlegi modell, ezért nem gondolom, hogy ott bármi változna a közeljövőben.
www.pumaszallas.hu
#51760
A DCS az még mindig az Ubisoft féle Lock On ból van tovább hegesztve ?
#51759
Én sem ugy értettem, hogy fix 3 év mulva lesz kész, hanem 3 éven belül, ami jelenthet 3 hónapot is.
A térképnél azon is mülik, hogy texturából akarják lefedni a mesht vagy procedurális megoldással adnak neki mintát.
De tudtommal, a DCS-nél minden épület külön 3ds objektum, ezért eszik ennyit az FS-nél meg az egész világ le van modellezve benne.
DE ha a Falcon marad a terület alapu dolgoknál akkor azt meg lehetne tartani ésszeró határok között.
Probáltam már egy két ilyen plugint és google earthből egy 60x60kmes terület megvolt pár száz megábol texturásan.
Igen ennek a technikáénak megvan a hátránya, hogy az épületek a térkép részei lesznek és mint ilyen nem rombolhatóak.
De sztem a legtübb simben amugy sem tudod ezt megtenni bármelyik épülettel.
A célpontnak számitó épóleteket kellene külön modellezni.
Ezekhez lehetne felajánlani a közösség segitségét, hogy aki tud az a meghatározott paramétereken belül csináljon hidat erőmüvet stb. Ha csak 50 különböző objektum készül is , de akkor is elöréább vannak vele. És azokat lehet több helyre is tenni. Akár a repülök is lehetnek ilyenek , hacsak a külsö model készül el már azzal is elörébb vannak a folytatáshoz.
De ehhez legalább tudni kellene a fájformárumot a max poligon számot a texturák fajtáit nagyságát.
És ez egyáltalán nem jelentené azt , hogy bármit is elárultak abbol amit nem akarnak.
DXel kapcsolatban , csak annyit, hogy ha hosszutávra gondolkodnak, akkor nem csak azért lett volna célszerü dx12öt választani mert az a legujabb verzió és mert , hogy a dx11et se használja ki teljes mértékben, hanem , hogy a késöbbiekben 2-3 év mulva amikor már megszönik a támogatás rá akkor is legyen mivel folytatni és ne kelljen egy ujabb engine csere.
Meg ha jol tudom a VR-hez a dx11 a minumum követelmény, de a dx12 -ben vannak meg azok a feltételek amik ahhoz kelelenek, hogy biztositani lehessen az alacsony késleltetést és a többszállon való futást. dx 11 esetében ebben nincs elöre lépés a dx9hez képest.
Az ilyen nagyon igéretesnek tünö dolgok sajnos mindig elhaltak eddig. én is küldtem neki referencia képeket hozzá , de nem is válaszolt.
Meg ha elkészül , biztos , hogy teljesen passzolni fog a régi modellhez?
Ha az uj engine támogat több texturázási fajtát vagy PBR-t is, akkor azért lenne pár olyan rész kivül is ami jó lenne ha nem csak trükkel lenne ott hanem valós 3d-s elemként. Ha a fényeket máshogy kezeli az uj motor akkor az összes gépem ,módosítani kell a textura helyett a fényeket.
A kezelés alatt nem a másfajta kabinokat értem, hanem , hogy könnyebb és egyszerübb legyen a módosításokat beleimportálni a mostani pluginok helyett.
Egyszerübb DOF rendszert, egyszerübb linkelést a különálló elemekhez stb.De már az is nagy könnyebbség lenne ha nem 3-4 különálló programot kellene használni hozzá minden egyes modositás után végig konvertálgatni oda vissza .
A térképnél azon is mülik, hogy texturából akarják lefedni a mesht vagy procedurális megoldással adnak neki mintát.
De tudtommal, a DCS-nél minden épület külön 3ds objektum, ezért eszik ennyit az FS-nél meg az egész világ le van modellezve benne.
DE ha a Falcon marad a terület alapu dolgoknál akkor azt meg lehetne tartani ésszeró határok között.
Probáltam már egy két ilyen plugint és google earthből egy 60x60kmes terület megvolt pár száz megábol texturásan.
Igen ennek a technikáénak megvan a hátránya, hogy az épületek a térkép részei lesznek és mint ilyen nem rombolhatóak.
De sztem a legtübb simben amugy sem tudod ezt megtenni bármelyik épülettel.
A célpontnak számitó épóleteket kellene külön modellezni.
Ezekhez lehetne felajánlani a közösség segitségét, hogy aki tud az a meghatározott paramétereken belül csináljon hidat erőmüvet stb. Ha csak 50 különböző objektum készül is , de akkor is elöréább vannak vele. És azokat lehet több helyre is tenni. Akár a repülök is lehetnek ilyenek , hacsak a külsö model készül el már azzal is elörébb vannak a folytatáshoz.
De ehhez legalább tudni kellene a fájformárumot a max poligon számot a texturák fajtáit nagyságát.
És ez egyáltalán nem jelentené azt , hogy bármit is elárultak abbol amit nem akarnak.
DXel kapcsolatban , csak annyit, hogy ha hosszutávra gondolkodnak, akkor nem csak azért lett volna célszerü dx12öt választani mert az a legujabb verzió és mert , hogy a dx11et se használja ki teljes mértékben, hanem , hogy a késöbbiekben 2-3 év mulva amikor már megszönik a támogatás rá akkor is legyen mivel folytatni és ne kelljen egy ujabb engine csere.
Meg ha jol tudom a VR-hez a dx11 a minumum követelmény, de a dx12 -ben vannak meg azok a feltételek amik ahhoz kelelenek, hogy biztositani lehessen az alacsony késleltetést és a többszállon való futást. dx 11 esetében ebben nincs elöre lépés a dx9hez képest.
Az ilyen nagyon igéretesnek tünö dolgok sajnos mindig elhaltak eddig. én is küldtem neki referencia képeket hozzá , de nem is válaszolt.
Meg ha elkészül , biztos , hogy teljesen passzolni fog a régi modellhez?
Ha az uj engine támogat több texturázási fajtát vagy PBR-t is, akkor azért lenne pár olyan rész kivül is ami jó lenne ha nem csak trükkel lenne ott hanem valós 3d-s elemként. Ha a fényeket máshogy kezeli az uj motor akkor az összes gépem ,módosítani kell a textura helyett a fényeket.
A kezelés alatt nem a másfajta kabinokat értem, hanem , hogy könnyebb és egyszerübb legyen a módosításokat beleimportálni a mostani pluginok helyett.
Egyszerübb DOF rendszert, egyszerübb linkelést a különálló elemekhez stb.De már az is nagy könnyebbség lenne ha nem 3-4 különálló programot kellene használni hozzá minden egyes modositás után végig konvertálgatni oda vissza .
#51758
De látod hogy működik. Máskülönben csak 100%os modulok jöttek volna ki, életszerű repmodellel.
#51757
Értem a poént, de ED-nél én már túl vagyok azon amikor tudtam röhögni ezeken. Elkérni a pénzt utána kiadni 10%-on valamit szerintem nagyobb sértés, mintha azt mondod neki, hogy még dolgozok rajta, várj egy kicsit. Mert akkor őt annyira értékeled, hogy "nesze paraszt itt a 10%, legyél boldog vele, azt majd kapod a többit ha úgy gondolom". Az, hogy eleve el sem kellene kérni a pénzt előre, ha nem tudja szállítani a megígért cuccot már nem is mondom.
www.pumaszallas.hu