Keresés

Részletes keresés

HLJ Creative Commons License 2015.05.17 0 0 49605

HA jól értem akkor a felső része a feszítőkábel és az alsó meg a munkakábel. A híd alja és a feszítő kábel között 15 centi különbség van.

Előzmény: Bzmot332 (49604)
Bzmot332 Creative Commons License 2015.05.17 0 0 49604

Ha nagyon szőrszál hasogató lennék, azt mondanám, hogy nem túl előnyös, ha a feszítőkábel hozzáér a hídhoz, mert az ugyanúgy feszültség alatt van, mint a munkakábel (a pontos elnevezéseket elfelejtettem, de remélem érthető).

Előzmény: HLJ (49603)
HLJ Creative Commons License 2015.05.16 0 0 49603

Pár ilyen jellegű képet megnéztem és erre a következtetésre jutottam. Ha jól tudom valamilyen rögzítő kapcsok még vannak a hídnál, de azt nem teszem bele.

 

 

Szerintem ez így elfogadható. Vélemény?

Előzmény: Bzmot332 (49602)
Bzmot332 Creative Commons License 2015.05.15 0 0 49602

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.

Előzmény: HLJ (49601)
HLJ Creative Commons License 2015.05.14 0 0 49601

Van-e arra szabály, hogy a vasúti híd alsó része a felső vezeték felső részétől hány centire van?

tibitrain Creative Commons License 2015.05.13 0 0 49600

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. 

Előzmény: Bzmot332 (49599)
Bzmot332 Creative Commons License 2015.05.13 0 0 49599

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.

Előzmény: tibitrain (49598)
tibitrain Creative Commons License 2015.05.13 0 0 49598

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.

Előzmény: ManagedCode0x01 (49597)
ManagedCode0x01 Creative Commons License 2015.05.12 0 0 49597

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.

Előzmény: tibitrain (49595)
Gothpaladinus Creative Commons License 2015.05.12 0 0 49596

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.

Előzmény: tibitrain (49590)
tibitrain Creative Commons License 2015.05.12 0 0 49595

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...

Előzmény: ManagedCode0x01 (49593)
tibitrain Creative Commons License 2015.05.12 0 0 49594

Köszi. Ezt ki is próbálom. Kipontosvesszőzöm a transparent sorokat a b3d fájlokból és megpróbálom.

Előzmény: ManagedCode0x01 (49593)
ManagedCode0x01 Creative Commons License 2015.05.12 0 0 49593

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.

Előzmény: tibitrain (49585)
HLJ Creative Commons License 2015.05.12 0 0 49592

É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.

Előzmény: Bzmot332 (49589)
HLJ Creative Commons License 2015.05.12 0 0 49591

Alfa csatornás png, de az se mindig jól jön ki én Ftrainben igyekszem az összes képemet png-be menteni.

Előzmény: tibitrain (49590)
tibitrain Creative Commons License 2015.05.12 0 0 49590

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.

Bzmot332 Creative Commons License 2015.05.12 0 0 49589

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.

Előzmény: HLJ (49588)
HLJ Creative Commons License 2015.05.12 0 0 49588

Amit én mondtam, hogy darabolja fel az állomást az mennyibe segíthet még be?

Igen openBVE teljesítményén is igencsak javítani kellene meg még sok máson.....

Előzmény: Bzmot332 (49587)
Bzmot332 Creative Commons License 2015.05.12 0 0 49587

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.

Előzmény: tibitrain (49585)
HLJ Creative Commons License 2015.05.11 0 0 49586

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.

Előzmény: tibitrain (49585)
tibitrain Creative Commons License 2015.05.11 0 0 49585

 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.

HLJ Creative Commons License 2015.05.06 0 0 49584

Managecodeékat hadd kérdezzem kíváncsiságtól vezérelve dolgoztok-e valamin mostanában valamit akár openBVE-vel vagy más segédprogrammal?

phontanka Creative Commons License 2015.05.04 0 0 49583

Igen, tökéletesen élethű.

Előzmény: HLJ (49582)
HLJ Creative Commons License 2015.05.04 0 0 49582

Akkor bocsánat, nem figyeltem meg jól milyen a valósában tehát szimuláció élethű ezen a téren.

Előzmény: vasutasadam (49581)
vasutasadam Creative Commons License 2015.05.04 0 0 49581

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.

Előzmény: HLJ (49580)
HLJ Creative Commons License 2015.05.03 0 0 49580

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?

maztro Creative Commons License 2015.05.01 0 0 49579

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.)

Előzmény: tibitrain (49578)
tibitrain Creative Commons License 2015.04.30 0 1 49578

Én is egy képet...

HLJ Creative Commons License 2015.04.29 0 1 49577

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:

 

 

 

Szerintem egészen jól mutat!

tibitrain Creative Commons License 2015.04.29 0 0 49576

Oké bocsi. Nekem csak simán négyes metró volt eddig és lesz is. Annyira nem néztem utánna, mert nem kimondottan ez a része érdekelt/érdekel.

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!