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:
Hú, te jó ég, mióta nem írtam itt Indán egy karaktert sem... De gondolom a túlnyomó többségetek már úgyis tudja, hogy a FB-s OpenBVE Hungarian Centrum csoportban továbbra is aktívan folytatom BVE-s tevékenységeimet.
Mint látjuk, a mi drága jó Tibink nemrégiben nagyon szépen rákapott a Budapest DBR projekt témára, és ahogyan alkot, az bizony nagyon magas színvonalt képez, Bvemetro-magasságokba helyezve a mércét, szóval állítom, hogy érdemes lesz rá várni! :)
Én az itteni szünet megkezdése óta nem sokat változtattam az általam megkezdett pályán, habár tegnapelőtt éjjel jó pár órát rászántam, hogy a való életben működő automatikához a szimulátor korlátaihoz képest a lehető legközelebb hozzam az MI általi vezetést. Így tehát ahogy a valóságban is, az ajtók a játékos beavatkozása nélkül nyílnak/záródnak, a vonat az állomásról meginduláskor először csak ~35 km/h-ig gyorsít, majd csak egy kis idő után gyorsít ismét rá a menetrend betartásához szükséges sebességre, az állomásra érkezés előtt pedig le is lassít ~35 km/h-ra, és csak a peron mellé éréskor kezd el ismét fékezni megállásig.
A megoldást videóra is vettem a frissített pálya kiadásakor, ha valakit érdekel, itt megnézheti, hogyan is néz ki a gyakorlatban, amit itt leírtam: https://www.youtube.com/watch?v=ey1UUVzsBGs
Hát ez így nem biztos hogy jó, mert hogy a mod-nak két paraméter kell ( Mod[a,b] )
Az mod osztója hiányzik a képletből, a kétobjektumos váltakozáshoz meg szerintem amúgyis kell a 2-vel való osztás, így különbözteti meg a páros és páratlan kimenetelt.
Ha a VALAMI-t elhagyjuk a szorzással együtt ( [time,2] ), akkor 1 mp-ként villog.
Ha a VALAMI=2 (azaz [time*2,2] ), akkor 0,5 mp-ként villog. Ha a VALAMI=4 (azaz [time*4,2] ), akkor 0,25 mp-ként villog, és így tovább. A VALAMI minél nagyobb értéke a villogás sűrűségét növeli.
A TÁVOLSÁG helyére beírod, hány méternél kell közelebb érni, hogy elkezdjen villogni, a VALAMI helyére pedig írsz egy kicsi számot (1-2 körül), ezzel szabályozva, milyen gyorsan villog. A többit értelemszerűen írd át.
A feltétel lehet sántít, pályán nem néztem meg, de elvileg jónak kéne lennie.
