53049
Hivatalos forum Oktató videók Kép feltöltése JoeDestroy_cucc Oktató vid_HU L_Viper cucc BMS manual_HU 80's Mod HT kisokos BMS Wiki Falcon4exe
-
#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. -
#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. -
#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. -
#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. -
#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. -
#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 -
#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. -
#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. -
#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. -
#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 -
#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.
-
#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 -
#51793
Az éjszakai kabinvilágításnál ütne nagyon a RT. Meg az FPS az egy számjegyet, az fix. -
#51792
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.
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.
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 -
#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á. -
#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. -
#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.
-
#51787
Már volt erről szó, asszem pont I-Hawk írta, hogy az új grafikai engine PBR anyagokat fog használni. -
#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. -
#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. -
#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? -
#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).
-
#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? -
#51781
Phisical Based Rendering rövidítése. Modern anyagtípus, kb. minden korszerű játék ezt használja már. -
#51780
Mi az a PBR? -
#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
Utoljára szerkesztette: VO101Tom, 2020.04.17. 03:05:31 -
#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. -
#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. -
#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). -
#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...
![]()
-
#51774
A skinezésnél sem festettem külön semmit. Ami a gépre került, azt láttam a kabinból is. -
#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. -
#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 . -
#51771
Értem.
Az utolsó mondat az durva. -
#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). -
#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. -
#51768
Melyik részt hogy értem? -
#51767
Lehet ezzel újat mondok, de a jelenlegi Falconos megoldás sokkal moddolás barátibb, mint pl a CloD.
Ezzel most sokkoltál. -
#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
