Biztos van valami (nyilván minimum kell akkora távolság valamennyi ráhagyással, hogy ne üssön át a fesz a vezetékről). De szerintem célravezetőbb, ha keresel a neten valami képet (google), és az alapján saccolsz.
Nem. Már megcsináltam vertex-szel a tetőt. Egy textúra és 16 meshbuilder szakasz. Ugyanazok a vertex pontok, csak mindegyik egy kicsit elforgatva. A fekete részek égbolt színűek lesznek, nem átlátszóak. Az illúzió így remélem ugyanaz lesz. Ha nem akar a program transparentezni, akkor majd forgatni fog meg kezeli a sok vertex pontot.
Szerintem első közelítésben érdemes lenne azokat a nagy textúrákat átméretezni (1024*1024-re pl.). Nem számít, ha egy kicsit torzulnak. Ugye itt azt kell szem előtt tartani, hogy mennyire fontos az adott textúra. Ha olyan helyen van, ami a vonatból alig látható, csak ha mászkálsz, szerintem érdemes lebutítani (inkább nézzen i rosszabbul közelről, mint hogy a vezetés rovására menjen).
Nem kell egyébként minden transparentes résztől megszabadulni, csak ahol nagyon sok van. Szerintem az állomáson az a pár ilyen cylinder bőven megmaradhat, csak ahol nagyon sok van és meg lehet máshogy is oldani, ott kéne valamit trükközni.
Persze. Lehet alagutat vertex pontokkal is megépíteni. Csak az közel sem lesz olyan szép szabályos mint a cylinder parancs által épített. Könnyebb is az utóbbi módszer, mert a gép számolja ki.
"A csavart falrészben sem értem a problémás részt"
Nos ezt úgy képzeld el, hogy cylinder paranccsal csináltam egy textúrázott hengert. Ennek a hengernek a palástjára kellene egy lyukat "fúrni" hogy belássunk. Vagy fordítva, hogy kilássunk. Ez mindegy. Erre és nem tudok már módszert, minthogy a textúra azon pontjára, ahová a lyukat tervezzük, teszünk egy transparent foltot. Ezt a program eltünteti, és már belátunk is. Én erre nem látok más módszert. Ráadásul ha a lyuk nem lyuk, hanem egy szabálytalan alakú forma, akkor ezt vertex pontokkal körbetextúrázni szinte lehetetlen.
Az első esetben pedig, a bikás park metróállomás teteje szintén ugyanaz. A kupola rész kis háromszög ablakain ki kellene látnunk. Vagyis valahogy átlátszóvá kéne tenni ezt a részt. Persze meg lehetne oldani, hogy vertex pontokkal a rácsszerkezetet megépítjük. Nyilván ez lenne a szebb és jobb. De ez bonyolult és hosszadalmas. Tudom erre azt mondanád, hogy egy jó pályába ennyit áldozni kéne. Hát nem tudom... ennyi szabadidőm nincs. Így csak lassan, évekig fog készülni.
A tény az, hogy a transparent sorok kiiktatásával óriásit javult a gép gyorsasága. Máshoz nem nyúltam.
Azokból a képekből, amelyeket előzőleg közöltél megmondom őszintén nem látom a problémás részt. De nagyon sok esetben ki lehet kerülni a transparent részt normál geometriával. A csavart falrészben sem értem a problémás részt amelyet csak transparentekkel lehetne megvalósítani. Általában poligonmodellezésnél nem abból kéne kiindulni, hogy mi az egyszerű burkolati geometria, ami körülveszi a testet, és mi az, aminek nem kellene látszódnia, és transparenttel megoldjuk.
A kép formátuma ezt nem hinném, hogy befolyásolná, ugyanolyan pixeleket fog betölteni egy más tömörítésű alfa csatornás fájlból, mint mondjuk png-ből, a betöltési időt és módot fogja csupán befolyásolni, a futásit nem.
Végső soron megpróbálkozhatsz az MSTS/OpenRails által használt TarGA Tool 2-féle ACE formátummal is, valszeg jobban kezelné abban az alfa csatornát az OpenBVE, mint a PNG-st. De a kettő hatvány arányt én is csak javasolni tudom nem feledni: én pl. amikor a Paint.NET-hez készült OptiPNG 0.7-es pluginnal tömörítek PNG-t, határozottan gyorsabban optimalizálja a 2 hatvány arányú képeket, mint amik nem a kettő arányainak megfelelők, tehát nem is csak a BVE miatt javasolt annak megfelelni. De a 3840*1300-as képaránytól már első ránézésre is kirázott a hideg kb... mert ha legalább egy 16:9/16:10 arányban lenne, ha a 4:3/3:2/2:1/1:1 nem lehetséges, de ez így... ettől nem csoda, ha a szimulátor is kis híján behal. Na meg alapból 2048*2048-nál nagyobb felbontással nem próbálkoznék, ha szimulátorról van szó, de pl. OFF FB-re is már csak legfeljebb 2048*1536-ra lekicsinyítve töltök fel képet, ott is csak összezsugorítja csak a képeket a portál, ha pl. nyers (4016*3016) felbontásban töltöm fel, és csak még többet romlik úgy a képek minősége, mint ha alapból legfeljebb 2048*1536-ban rakom fel őket.
Sajnos igaz amit leírtatok. Transparent nélkül szépen megy, nem szaggat. Lassan tölt de ugyan, de utánna jó minden. A bikás park teteje több darabból álló belülről textúrázott cylinder. Úgy van forgatva a textúra hogy a rácsos transparentes rész van fent, az alsó rész teljesen transparentes. Így alul nem látható semmi. Fogalmam sincs hogy hogyan kéne átalakítani. Talán vertexekkel kéne csak a felső félkört megcsinálni, és transparent helyett kamu égboltot csinálni. Vagyis égkékre színezni a transparent részt. Így talán olyan lenne mintha kilátnánk, de mégse. De még mindig ott van a gellért. A csavart falmintát vertexekkel felvinni nem tudom menni fog-e. Mert ott is belső textúrás cylinder van, a fal átvágások transtarentesek. Gyakorlatilag így oda az eddigi munkám...
Mivel írtad, hogy sok a transparent rész, ezért jegyezném meg, ami nagyon tipikus az openBve-ben, viszont nem túlzottan javasolt. A szép megjelenítés érdekében a poligonokat rendezni kell, minden pillanatban a kamera távolságának megfelelően, ez az alpha sorting. Ez a hivatalos dokumentációban benne is foglaltatik az "Information and Tips" szekciónál. Tehát a gépnek minden képkocka kirajzolása előtt rendezni kell az áttetsző poligonokat a kamera pozíciójától függően. Ez sok poligon esetén már egyre lassabb lesz, ráadásul a teljesítmény egy rendezés esetén egyre több számnál egyre gyorsabban romlik.
A translate parancsnak pedig nem szabad lassúnak lennie, azt a program egyszer, a betöltésnél dolgozza fel, utána már egy olyan geometriával dolgozik, amire alkalmazva lettek a translate és rotate parancsok.
Ami az openBve betöltésénél lassulást okozhat, az a hosszú modellfájlok használata, vagy pontosabban fogalmazva bármilyen kollekcióból egy hosszú használata, például sok meshbuilder, sok material vagy sok pont. A program a forráskód tanulsága szerint minden újonnan definiált tömbelemnél, például új vertexnél vagy meshbuildernél, átméretezi az azt tartó tömböt, ezt viszont úgy teszi, hogy az addigi elemeket átmásolja egy új, tágasabb helyre. Így sok elem esetén ez egyre lassabb lesz. A route fájl betöltésnél úgy tűnik, ez már ki lett küszöbölve, a modellfájlok meg nem kell, hogy hosszúak legyenek, tehát a tervezés végső soron logikusnak is nevezhető, más kérdés, hogy az azóta felbukkanó nyelvi verziók már lehetővé teszik illetve elvárják a listák használatát, amelyek a tömbökkel ellentétben a dinamikus hozzáadásra lettek megvalósítva, azt pedig meglehetősen gyorsan végrehajtják. A route fájl betöltésénél egy saját lista-implementáció féleség található, azért is gyorsabb annak a feldolgozása.
Én abból az elgondolásból indulok ki, hogy nagyobb összetettebb objektumuknál van jelentősége, hogy egybe kell neki betölteni az egészet vagy csak külön darabokban. Nem próbáltam még ki ilyen volumenű objektummal, nem volt -rá szükségem-, de szerintem javítana valamit a teljesítményen, lásd BVEmetró munkásságát ők is darabokba építették az állomásokat, hogy ebből a megfontolásból vagy más miatt azt nem tudom.
A kettő hatványa miért fontos? A régi bve ben kellett a transparent szin miatt de itt miért kell? Esetleg más képformátum nem lenne jobb. Ez most bmp. Bàr én mindig ezzel dolgozok, a tansparent miatt.
Fogalmam sincs, mennyire akasztja meg az openBVE-t, ha egybe van az állomás, de nem hinném, hogy sokat számítana. A 4-es metró állomásai úgy sem olyan hosszúak (talán 100 méter körül van egy), bár az is igaz, hogy Tibi jócskán hozzáépített még az állomásokhoz.
Mint ahogy FB-n is írtam, a gond a sok Translate-tel lesz (szerintem). Anno a hivatalos oldalon volt fent ilyen kis szösszenet az építéssel kapcsolatban, ott írta Michelle, hogy a különféle transzformációk terhelik legjobban a gépeket, különösen ha az adott részen van transparent-es rész is (lehet az animációkra értette, de szerintem itt is ez lesz a gond).
Amúgy most olvasom végig, mit írtál a textúrákról is :D Ezek szerint nagy eséllyel lehet, az a gond. 14,8MB elég sok egy modellnek, pláne az openBVE-ben (OMSI-ban használtam 12MB-s képet legnagyobbként, de ott egy 300 méteres panelhez, és hát az OMSI erősebb program, mint az openBVE). Ha ezt 14x vesszük, megvan a gond. Szerintem első közelítésben csökkentsd le a méretüket (nem volna rossz 2 hatvány méretet használni (512, 1024...stb)), az jó eséllyel megoldja a dolgot. Ha nem egészen, még mindig ott marad a translate.
Ez lesz a gond szerintem amit leírtál. Próbáld meg, hogy kép méretén veszel lejebb, mert ezzel tapétázni lehet hátha segít valamit. Befolyásol a textúra méret és befolyásol ebben az esetben a vertex illetve translate, roatation szám is. Talán próbálhatod úgy is mint BVEmetróék, hogy külön szedték az állomásokat nem egybe tölti be hanem külön kiseb nagyobb darabokban, hátha ez is segít.
Van egy kis gubanc. Annyira nem is kicsi. Object wiewerbe nagyon lassan tölti be bikás állomást, a pályába pedig el se jutok oda. Állomásra ugrással nagy sokára sikerül, de oldalra borult szerelvénnyel.
Nem tudom hogy ez a textúrák méretei miatt van-e. A kupola nagy méretű képből van, és összesen 14 darab. 3980*1300 a mérete, és 14.8 mb/darab. A kupola egyébként 14db belülről textúrázott cylinder. A többi textúra nem nagy csak ezek.
Esetleg a sok áthelyezés (translate) miatt. Mert ez utóbbiból van sok. A b3d-ben is sok eltolás van, és az animated fájlban is sok a tologatás.
A kupola sok transparent részt is tartalmaz. Talán ez a baj.
Nincs valakinek ötlete hogy mi húzza le ennyire?
Elsődlegesen megpróbálom a textúrák méretét lecsökkenteni. Talán ez a nagy neki.
Amint az első tengely áthalad a tengelyszámlálón, vörösre vált a jelző. Ha kinézel az első kocsi ablakán, mire Te érsz a jelzőhöz, már vörös lesz. Szóval hülyeség, amit írtál.
openBVE-be zavaró mikor a mozdony elhalad a jelező mellett és vörösre vált holott vannak még mögötte kocsik valóságban ez úgy működik mikor a teljes szerelvény elhaladt akkor vált vörösre a jelző. Ezen lehet változtatni valamit, hogy kicsit élethűbb legyen?
Nem veled szurkálódok, csak kicsit a levegőbe: kár, hogy nem a valóságot adja vissza ez az állomás a képen sem, hanem a DBR (mostmár biztos tudni fogod kikről beszélek :D) fémjelzette vágyálmot, miszerint a felszínre kibuggyanó felépítmények hála a megállóba természetes fény szűrődik le. (A valóság ezzel szemben az, hogy a felépítmény gyakorlatilag kilóg a metrómegállóból, egy kis fény rászűrődik a mozgolépcsőre, ami amúgy is takarja az alatta lévő területet, a metróállomás nagy része meg félhomály. Geniális.)
Anno Ferenc7 még készített pár modellt amit remekül lehet pályákhoz használni, viszont az ő objektumai nem lettek oly módon openBVE-re kompatibilisek, hogy nincsen meg minden oldal az épületnek. Én megcsináltam mindegyik oldalát és textúrákkal láttam el. Ez lett a végeredmény:
