Stěrače na 2D cabu
- Tvůrce vlákna Howky
- Datum začátku
Josef Vogeltanz
Pomocník strojvedoucího
Sledoval jsem, ale nepřišel jsem na to, jak by měl vypadat sterac.ace samotný. Zda prostě textura smetáku s vyalfovaným okolím a zaměřeným otočným bodem. Samotný zápis funkce v .cvf jsem pochopil. Asi nezbude nic jiného, než jít na to "experimentálně". Premiéra viditelné kapoty ála Icík se konala u ošklivky z řady 110, tak si ji na test stěračů zase půjčím. Potenciál jinak vidím v případě OR u 3D kabin. Ale o tom můžu akorát kecat, protože 3D kumštem nevládnu.
Pikku
Pomocník strojvedoucího
Tam to funguje bez problému, a tyhle animace dokonce dokážu. (Kdo má velké hektory a prasátka tak ví, jak to vypadá.)
Josef Vogeltanz
Pomocník strojvedoucího
Vyzkoušeno s devíti obrázky animace (stejně jako u původní ukázky) a funguje pod OR MG bez problémů:
Animoval jsem samotné ramínko smetáku, pro lepší efekt by to možná chtělo celé okno vč. kapek na skle a stopy setření. Na druhou stranu, tohle by měl výt efekt vázán spíše na počasí a ne na spínač stěračů na pultu. V případě nasazení u česko-slovenských kabin by ale docházelo ke kolizi s LVZ, které má nyní většinou klávesu stěračů obsazenu. Pro LVZ by se musela najít jiná.
Animoval jsem samotné ramínko smetáku, pro lepší efekt by to možná chtělo celé okno vč. kapek na skle a stopy setření. Na druhou stranu, tohle by měl výt efekt vázán spíše na počasí a ne na spínač stěračů na pultu. V případě nasazení u česko-slovenských kabin by ale docházelo ke kolizi s LVZ, které má nyní většinou klávesu stěračů obsazenu. Pro LVZ by se musela najít jiná.
Raději ne, když by měly kapky stékat po okně při jízdě (např. 100 km/h) směrem dolů, jako je tomu např. u řady X5X. Navíc, kdo se sveze občas "na stěrače" ví, že to ani kapky na sklech nejsou. Takže co jsem byl na TS naposledy někdy ve 2018, tak být tvůrcem, toho jinak skvělého nápadu/efektu, při jízdě dopadající kapky deště bych poněkud roztříštil do slité rozostřené vrstvy, přes kterou je vidět rozmazaně, ale ne kapky. Takováto animace by pak nemusela být možná ani toliko složitá pro programátora/ladiče v OR.
Igor Hnízdo
BAN
S tím tříštením/netříštěním kapek na skle to není tak jednoznačné. Je-li sklo ošetřeno nějakou hydrofobní-nesmáčivou vrstvou (stačí i vosk), tak kapky naopak drží na skle (vlivem povrchového napětí) vcelku a stejně tak samostatně stékají. Kdo vyjede s autem z myčky a použil vosk, přesně tento efekt následně zažije. Dokud se vrstva vosku ze skla nesmyje.
Pro zajímavost poznatek z praxe - kdysi jsem v autě experimentoval s "protimlžnými" přípravky na vnitřní plochu skel. Ty působí přesně opačně - zesilují smáčivost plochy skla, takže vlhkost se nesráží ve formě drobných kapek (způsobujících rozptyl světla a tím "zamlžení"), ale kapky se slévají do jedné vrstvy. Neosvědčilo se to, poněvadž vzniklá vrstva vody na skle, byť jednolitá, rozhodně není rovná a průhled sklem tak zkresluje, navíc se na zkreslení podílí i rozdílné indexy lomu světla ve skle a ve vodě - je to asi jako když koukáte "přes rozvlněné akvárko", nebo když "máte hodně blbý brejle". A co je horší, vysušit takto vzniklou, relativně silnou vrstvu vody ofukováním skla následně trvá několikanásobně déle, než osušit běžné zamlžení. Což bezpečnosti rovněž nepřidává.
A s animací to rovněž není jednoduché - v případě 2Dcabu by stačilo stávající alfavrstvu, určující průhlednost, použít pro oblast, kde se textury kapek budou generovat. Následně by ale jako "maska" musela být použita další textura, jejíž alfavrstva by určovala oblast, kterou stěrač pokrývá. A ani to by nestačilo - pokud je stěrač zapsán jako "Dial" (otočná rafička), musel by program na základě analýzy pohybu textury určovat plochu, kterou "stěrač" přejíždí, následně počítat, kudy se právě pohyboval, jakým směrem a dle toho určovat plochu, kde bylo právě setřeno a kde se tedy textury "kapek" budou objevovat "od nuly". A ani tím problém nekončí - stírátko v žádném případě kapky "neodmazává" jako guma tužku, ale setřenou masu vody "hrne" před sebou. Takže již vykreslené textury kapek by bylo třeba následně posouvat "před" stírátkem, navíc by se musely deformovat a slévat do jedné vrstvy. Vrstva na okraji stírané plochy se následně začíná roztékat jednak dle gravitačního působení a jednak vlivu větru. Čímž se dostáváme k dalšímu problému a sice, jak správně určit, kam se kapky na skle mají pohybovat? U 2D kabiny by bylo nutné zadat úhly skla ve dvou rovinách, aby byl program informován o poloze okna vůči podélné ose modelu, potažmo směru jízdy. Teprve poté, jednak s počítáním vlivu gravitace a jednak vlivu větru (vítr, navíc měnící se, už je nějakou dobu v ORTS implementován), by byl schopen rozhodnout, kterým směrem se následně mají textury vody po obraze pohybovat. Celkově vzato, byla by to hodně kostrbatá a těžkopádná implementace. Jak tu padla zmínka i TS (RW), tak ani tam není animace vody na skle a jejího stírání zcela realistická, navíc hra neumí animaci dopadajících, rozpleskávajících se a tajících sněhových vloček. Asi nejlépe je animace vody a stírání (včetně shrnování stírátkem a následného roztékání/stékání shrnuté masy vody) vyřešena v ETS2/ATS. Jenže tam je toto pochopitelně od počátku implementováno už v jádru grafického enginu.
A co se kolize ovládání stěračů/VZ týče, tak ano, nejrozumnější bude použít cab object "Cab_Radio", stejně to neumí nic jiného, než přepínání dvou snímků textury, takže jde max. nastínit svit kontrolek vysílačky, ale co se samotné funkce vysílačky týče (přehrávání zvuků), to ORTS neumí.
Ale mnohem lepší je mít nainstalované skripty TCS (verzi 1.01) od @Icik, pak po zapsání odkazu na patřičný VZ do *.eng (a úpravě textury opakovače - popsáno v návodu) už není potřeba uměle zapínat/vypínat přenos kódu maskovací texturou. Navíc v situacích, kdy není obsluha TB vyžadována, není potřebná ani ve hře - není už tedy potřeba mačkat TB stále, i při přenosu zelené. Jen je třeba mít v Options stále zapnutý "Alerter in Cab", bez něj skripty nefungují. Mám otestovanou KBS a LS-IV diesel, fungují perfektně. A pro stroje s Mirelem je nejlepší používat Jindrovo vývojovou odnož "ARR+Mirel", poněvadž tam je VZ-1 v0.4 implemetován přímo ve zdrojovém kódu hry a je programován přesně dle podkladů výrobce, takže realisticky umí vše, co reálný zabezpečovač. Jen s tvorbou jeho grafiky pro 2D cab je to složitější a dodatečná implementace do starších kabin je ořech kameňák.
Pro zajímavost poznatek z praxe - kdysi jsem v autě experimentoval s "protimlžnými" přípravky na vnitřní plochu skel. Ty působí přesně opačně - zesilují smáčivost plochy skla, takže vlhkost se nesráží ve formě drobných kapek (způsobujících rozptyl světla a tím "zamlžení"), ale kapky se slévají do jedné vrstvy. Neosvědčilo se to, poněvadž vzniklá vrstva vody na skle, byť jednolitá, rozhodně není rovná a průhled sklem tak zkresluje, navíc se na zkreslení podílí i rozdílné indexy lomu světla ve skle a ve vodě - je to asi jako když koukáte "přes rozvlněné akvárko", nebo když "máte hodně blbý brejle". A co je horší, vysušit takto vzniklou, relativně silnou vrstvu vody ofukováním skla následně trvá několikanásobně déle, než osušit běžné zamlžení. Což bezpečnosti rovněž nepřidává.
A s animací to rovněž není jednoduché - v případě 2Dcabu by stačilo stávající alfavrstvu, určující průhlednost, použít pro oblast, kde se textury kapek budou generovat. Následně by ale jako "maska" musela být použita další textura, jejíž alfavrstva by určovala oblast, kterou stěrač pokrývá. A ani to by nestačilo - pokud je stěrač zapsán jako "Dial" (otočná rafička), musel by program na základě analýzy pohybu textury určovat plochu, kterou "stěrač" přejíždí, následně počítat, kudy se právě pohyboval, jakým směrem a dle toho určovat plochu, kde bylo právě setřeno a kde se tedy textury "kapek" budou objevovat "od nuly". A ani tím problém nekončí - stírátko v žádném případě kapky "neodmazává" jako guma tužku, ale setřenou masu vody "hrne" před sebou. Takže již vykreslené textury kapek by bylo třeba následně posouvat "před" stírátkem, navíc by se musely deformovat a slévat do jedné vrstvy. Vrstva na okraji stírané plochy se následně začíná roztékat jednak dle gravitačního působení a jednak vlivu větru. Čímž se dostáváme k dalšímu problému a sice, jak správně určit, kam se kapky na skle mají pohybovat? U 2D kabiny by bylo nutné zadat úhly skla ve dvou rovinách, aby byl program informován o poloze okna vůči podélné ose modelu, potažmo směru jízdy. Teprve poté, jednak s počítáním vlivu gravitace a jednak vlivu větru (vítr, navíc měnící se, už je nějakou dobu v ORTS implementován), by byl schopen rozhodnout, kterým směrem se následně mají textury vody po obraze pohybovat. Celkově vzato, byla by to hodně kostrbatá a těžkopádná implementace. Jak tu padla zmínka i TS (RW), tak ani tam není animace vody na skle a jejího stírání zcela realistická, navíc hra neumí animaci dopadajících, rozpleskávajících se a tajících sněhových vloček. Asi nejlépe je animace vody a stírání (včetně shrnování stírátkem a následného roztékání/stékání shrnuté masy vody) vyřešena v ETS2/ATS. Jenže tam je toto pochopitelně od počátku implementováno už v jádru grafického enginu.
A co se kolize ovládání stěračů/VZ týče, tak ano, nejrozumnější bude použít cab object "Cab_Radio", stejně to neumí nic jiného, než přepínání dvou snímků textury, takže jde max. nastínit svit kontrolek vysílačky, ale co se samotné funkce vysílačky týče (přehrávání zvuků), to ORTS neumí.
Ale mnohem lepší je mít nainstalované skripty TCS (verzi 1.01) od @Icik, pak po zapsání odkazu na patřičný VZ do *.eng (a úpravě textury opakovače - popsáno v návodu) už není potřeba uměle zapínat/vypínat přenos kódu maskovací texturou. Navíc v situacích, kdy není obsluha TB vyžadována, není potřebná ani ve hře - není už tedy potřeba mačkat TB stále, i při přenosu zelené. Jen je třeba mít v Options stále zapnutý "Alerter in Cab", bez něj skripty nefungují. Mám otestovanou KBS a LS-IV diesel, fungují perfektně. A pro stroje s Mirelem je nejlepší používat Jindrovo vývojovou odnož "ARR+Mirel", poněvadž tam je VZ-1 v0.4 implemetován přímo ve zdrojovém kódu hry a je programován přesně dle podkladů výrobce, takže realisticky umí vše, co reálný zabezpečovač. Jen s tvorbou jeho grafiky pro 2D cab je to složitější a dodatečná implementace do starších kabin je ořech kameňák.
Josef Vogeltanz
Pomocník strojvedoucího
Tady jde spíše o "zabavení" klávesové zkratky pro účel zapínání vlakových zabezpečovačů. Rádiový provoz lze ještě simulovat jako zvukovou kulisu, samozřejmě nezávisle na dění. Tak těžká škoda by to nebyla. Navíc se animace stěračů až tak rychle rozšiřovat nebudou. Použití CAB_RADIO TWO_STATE je u stávajících kabin jako šafránu. Lze najít u "vintage" kabiny 100/121/140, kde maskuje ručky manometrů, u kabiny pro řadu 242, kde maskuje LVZ (první vlaštovka) a u kabiny 363.5, kde maskuje bargrafy na displeji. Takže ve dvou případech funkce evidentně použitá jako "volná" klávesová zkratka a v jednom případě použitá tak, jak by bylo možné v případě uvolnění klávesy V pro stěrače (autora kabiny už tehdy zřejmě štvalo kmitání košťat zvenčí při zapnutí LVZ).
Netuším ale jak bylo myšleno použití ALT+R v uvedených případech. V readme kabin zmínka jak a proč používat není.
Netuším ale jak bylo myšleno použití ALT+R v uvedených případech. V readme kabin zmínka jak a proč používat není.
Icik
Pomocník strojvedoucího
Já myslím, že Pikku a jemu podobní dokáží stěrače pomocí 3Dmodelu animovat daleko lépe a hlavně plynuleji/přirozeněji.
Opravdu by měl stačit jen FreightAnim bez kastle jen se stěrači a přizpůsobit ho modelu z venku i ve 2D kabině pomocí souřadnic v engu. Vždyť to OR umí. Klávesa V klidně ať si zůstane (použije se také pro zvukový trigger stěračů - na to nezapomínejte) a pro ostatní ať se používá například zmiňovaná Alt+R nebo nějaký generic.
Opravdu by měl stačit jen FreightAnim bez kastle jen se stěrači a přizpůsobit ho modelu z venku i ve 2D kabině pomocí souřadnic v engu. Vždyť to OR umí. Klávesa V klidně ať si zůstane (použije se také pro zvukový trigger stěračů - na to nezapomínejte) a pro ostatní ať se používá například zmiňovaná Alt+R nebo nějaký generic.
