Thor i Tane

[korvtiger]

Jag tror nog snarare att de två spakar vi har hittat är till fram respektive bakdamp. Jag tror inte man har flera öppningsgrader på spakarna till skopan. Den ska ju bara vara antingen öppen eller stängd. Draget vill man ju å andra sidan kunna reglera i någon mån.

Intressant, har aldrig hört talas om eller ens sett detta utfört på något lok. Vad jag hittat verkar det aldrig ha använts i Sverige, verkar vara något utländskt påhitt. Antagligen så har det provats på något lok eftersom det står om det i Ånglokläran, men det verkar inte ha varit någon höjdare.

[korvtiger]

Hamnade av en ren händelse inne på Wikipedias sida om ULJ, (https://sv.wikipedia.org/wiki/Upsala...Lok_och_vagnar), där hittade jag följande om BLJ 5 Thor: "Pannan är inte överhettad och maskinen har därför planslider. Ingen fallrost och stybbtratt byggdes in. Elbelysning installerades först 1937."

Det rätar ut en del frågetecken. De två handtagen vi har diskuterat måste därmed vara till främre och bakre damp.

[tanigardi]

Skönt, då kan man sluta leta efter en spak som inte finns

[tanigardi]

En liten uppdatering av lokbyggets fortskridande.

För närvarande pågår arbetet med ”attachment points” och animering av av eldsadsluckorna och ångbromsen.

Animeringen av vattenpelaren i vattenståndsglasen var ”a piece off cake” med hjälp av Korvtigers demoanimation.

Kämpade länge med eldstadluckorna, men fick slutligen det att fungera. Troligen skulle det gå att få till animationen betydligt enklare och ”elegantare”, men tänkte att jag skulle försöka att få till den själv. Har importerat det hela som ett ”scenery objekt” i Tane, och där fungerar animationen korrekt. Vad som återstår är att få till urtagen som finns i luckarmarna för styrningen av luckorna. Kanske det är lite överkurs med det skulle ju se trevligt ut.

thor_fireplates.jpg

En fundering, jag har animerat luckorna från öppet läge till stängt, Skall det kanske vara tvärs om?
En fråga till: skall det animeras öppen-stängd-öppen eller bara öppen-stängd?

Har studerat B- lokets hytt och ”body” och har lite undringar om vissa ”attachment points”.

1 I bodymeshet finns både a.cabfront och a.dubback som har samma position. Vad har a.dubback för funktion?

2 I body-meshet är a.light1, a.light3, a.light5 är positionerade med negativ z. Varför och vad är deras funktion?

3 Läste någonstans att a.cabfront skall finnas i både ”body’n” och interiören. Är det nödvändigt eller räcker det att origo i hytten matchar a.cabfront i body’n?

4 Hittade inga ”attachment points” för belysningen i hytten. Är jag ett blindstyre eller hur skall det göras på något annat sätt?

5 Hastighetsmätaren. Se bild.

thor_deuta.jpg

Den är ju graderad från 120 km/tim framåt till 120 km/tim bakåt (med en röd markering vid 50 km/tim). Det verkar ju väldigt mycket, loket kan väl knappast komma upp i dom hastigheterna och STH vid Blj var ju endast 35 km/tim. Så vilken maxhastighet vid framåtgång skulle vara realistisk att utgå ifrån när man ställer in vinkeln för visaren? Förmodar att 50 km/tim skulle vara lämpligt för läget för backgång.

Det var förfärligt mycket frågor och jag är rädd att det kommer många fler.

Åke

[korvtiger]

Ursprungligen postat av tanigardi

En fundering, jag har animerat luckorna från öppet läge till stängt, Skall det kanske vara tvärs om?
En fråga till: skall det animeras öppen-stängd-öppen eller bara öppen-stängd?

Tvärs om! De animeras från stängda till öppna och bara åt ena hållet. I regel, animera/modellera alltid allting i standard-läget/stängt läge till omlagt läge. Det är sällan man animerar en hel cykel stängd-öppen-stängd, då animationen oftast är samma åt båda hållen.

Ursprungligen postat av tanigardi

Har studerat B- lokets hytt och ”body” och har lite undringar om vissa ”attachment points”.

1 I bodymeshet finns både a.cabfront och a.dubback som har samma position. Vad har a.dubback för funktion?

Jasså, du hittade den! a.dubback är egentligen a.cabback som jag har ändrat namnet på direkt i meshens im-fil. Jag höll på och försökte få det att fungera att styra strålkastarljuset från hytten och kunna byta om man ville ha främre eller bakre lyktorna tända, men SP1 satte käppar i hjulen för mig. Gjorde på detta sättet för att slippa att be Lan att exportera om meshen varje gång jag ville lägga till/ta bort den attachmenten. Eftersom det är namnet cabback som Trainz letar efter så räcker det med att byta detta namnet, vilket bara är att göra i .im-filen om man öppnar den med en texteditor.

Cabback är den attachmenten för interiören som används när man byter håll på loket. Detta för att kunna ha lok med hytter i var ände.

Ursprungligen postat av tanigardi

2 I body-meshet är a.light1, a.light3, a.light5 är positionerade med negativ z. Varför och vad är deras funktion?

De är punkterna där coronorna till lyktorna/lanternorna ska monteras. Om jag inte missminner mig så pekar -Z åt det hållet strålkastarskenet riktas, alltså framåt. Dessa borde vara beskrivna i Trainz dokumentation någonstans.

Ursprungligen postat av tanigardi

3 Läste någonstans att a.cabfront skall finnas i både ”body’n” och interiören. Är det nödvändigt eller räcker det att origo i hytten matchar a.cabfront i body’n?

Låter onödigt. I exteriöra meshen så talar a.cabfront om var den interiöra meshen skall ha sitt origo. Men varför skulle man ha en i en interiöra meshen?
Om det inte finns någon sådan i B-lokets interiör-mesher så borde det inte behövas. Lan kanske kan svara bättre?

Ursprungligen postat av tanigardi

4 Hittade inga ”attachment points” för belysningen i hytten. Är jag ett blindstyre eller hur skall det göras på något annat sätt?

Med belysningen i hytten menar du manometrarna och vattenstådsglasen som är upplysta? De är inte belysta på riktigt, utan är fejkat med självlysande texturer som jag fixade med Blender. Inte så svårt att göra och riktigt bra resultat! Kan beskriva det närmare om du är intresserad.

Ursprungligen postat av tanigardi

5 Hastighetsmätaren. Se bild.

Bifogad fil 74875

Den är ju graderad från 120 km/tim framåt till 120 km/tim bakåt (med en röd markering vid 50 km/tim). Det verkar ju väldigt mycket, loket kan väl knappast komma upp i dom hastigheterna och STH vid Blj var ju endast 35 km/tim. Så vilken maxhastighet vid framåtgång skulle vara realistisk att utgå ifrån när man ställer in vinkeln för visaren? Förmodar att 50 km/tim skulle vara lämpligt för läget för backgång.

Hade vi kommit fram till om hastighetsmätaren var original från BLJ-tiden, eller nyinsatt på ULJ? Mätaren skall egentligen alltid ha maxgraderingar i båda riktningarna.
Eftersom graderingen är på backgångssidan så gissar jag att den är ditsatt på grund av att tenderlok är begränsade i den hastighet de får backa med då tendern lätt spårar ur annars. Plockade fram min SäO från 1941 och där står det att tåg med backgående tenderlok med boggietender och minst halva förråd inte får framföras snabbare än 60 km/h. Backgående tenderlok med 2- eller 3-axlig tender eller med boggietender med mindre än halva förråd gäller bara 45 km/h. Lite märkligt fortfarande då MROs SäO (den som museibanorna idag rättar sig efter) säger att max hastighet i backgång med tenderlok är enbart 40 km/h, vilket torde vara det som ULJ har att gå efter.

Mätarna som tillverkades av Deuta eller Penta var av standardtyp som alltid hade 120 km/h som max. Man ville väl inte göra flera olika versioner antar jag. Mätaren kan säkert varit tagen från något annat, större/snabbare lok också.
Vad menar du med "ställer in vinkeln för visaren"? Du behöver bara modellera visaren så den pekar på 0:an och har sitt origo i punkten den snurrar runt med Z-axeln som rotationsaxel. Sedan sköter configen resten, inga animationer här inte! Sedan så sätter man angles i configen till att vara -pi till pi radianer (== -180 grader till 180 grader) och limits i configen till att vara -38.8 till 38.8 m/s (== -140 till 140 km/h), eftersom 140 km/h borde vara ett halvt varv på mätaren. Du kommer ju aldrig att komma upp i så höga hastigheter, men gör det enkelt när du mäter ut vinklar och hastigheter/tryck på alla mätare!

Du är välkommen att låna texturen till hastighetsmätaren ifrån B eller Sb-loken om du vill ha en mer högupplöst textur!

Ursprungligen postat av tanigardi

Det var förfärligt mycket frågor och jag är rädd att det kommer många fler.

Åke

Många mer frågor vill vi ha!

[lan]

Ursprungligen postat av korvtiger

Låter onödigt. I exteriöra meshen så talar a.cabfront om var den interiöra meshen skall ha sitt origo. Men varför skulle man ha en i en interiöra meshen?
Om det inte finns någon sådan i B-lokets interiör-mesher så borde det inte behövas. Lan kanske kan svara bättre?

Anledning till att det ligger en a.cabfront i hytten är att när jag importerar detaljer från själva loket till hytten så tar jag alltid med a.cabfront också.
Då är det bara att flytta hela paketet tills a.cabfront ligger i origo. Sen kan man ta bort a,cabfront vilket jag väl råkat glömma.

[tanigardi]

Skönt att fått veta i vilket läge animationen skall starta, har försökt söka info om detta men inte lyckats få klart för mig hur det skulle göras.

När det gäller light attachments är jag fortfarande osäker. I B-loket finns ju även light0, light2 och ligh4 som är placerade i centrum av lyktorna i fronten. Har dom samband med light1, light3 och light5? Är vädigtl dåligt påläst i dokumentationen angående detta.

Tack för klargörandet av a.dubback, då vet jag att det inte är något jag behöver bekymra mig om

Mitt svammel om vinklarna till hastighetsmätaren avsåg precis vad du skrev, alltså vilka vinklar som skulle anges i configen. Sen det där med pi radianer förstod jag inte riktigt, det var 48 år sedan jag läste geometri och mycket har fallit i glömskans skugga
Skulle vara mycket tacksam för att få tillgång till den högupplösta texturen sill hastighetsmätaren.

Det där med självlysande texturer lät intressant, skulle vara mycket intresserad av att vet hur det går till att göra. Skulle detta var lämpligt till taklampan i hytten också?

Till Lan:

a.cabfront i hytten finns inte kvar i B-lokets mesh, vad jag syftade på var att jag sett en tutorial av Slugmaster (tror jag att det var) där han hävdade att a.cabfront skulle finnas både i hytt-meshet och i body-meshet, tyckte själv att det verkade onödigt men tänkte det var bäst att få det bekräftat.

Tack för all hjälp!

Åke

[korvtiger]

Bara som extra förtydligande så ska omkastaren animeras från full back till full framåt. Lämpligen animerar du över 75+75+1 frames, för 75 % bakåt och 75 % framåt plus 0-läget.

Har ju aldrig byggt något lok själv, bara varit inblandad med samtliga fingrar när Lan byggt och uppdaterat sina lok. Men jag tror det är så att jämna nummer på a.light är för ljus framåt och udda nummer är för bakåt. Så Sb-loket borde ha 0,1,2,3,4, där de jämna är för framåt två buffertlyktor och en toppstrålkastare och de udda är för två bakåt, två buffertlyktor. B-loken borde enbart ha 0, 2, 4 och deras tendrar 3 och 5. Lan får gärna rätta mig här om jag fått något om bakfoten.

Trainz, liksom matematiker och datorer föredrar att räkna med radianer istället för grader. Inte så svårt egentligen, 180 grader == pi radianer. Så ett halvt varv är pi radianer, alltså ca 3.1415.
Högupplösta texturer levereras till din PM-inbox straxt!

Ja, det där med "inte så svårt" är väl relativt som så mycket annat... För mig var det inte så svårt, men det kräver en del kunnande om rendering och bakning av texturer. Men såhär har fungerar det i alla fall:
Vi har den vanliga meshen av hela hytten. Den fick jag av Lan i fbx-format. Därefter plockade jag ut alla delar som skulle vara upplysta, i detta fall manometrar och vattenståndsgasens metallskydd. Sedan plockade jag bort så mycket polygoner som möjligt som inte att vara upplysta. Därefter flyttade jag ut alla polygoner en millimeter så att de upplysta mesherna skulle vara framför grundmeshen när den visades. Därefter skapade jag ett nytt UV-mappslager och mappade om dessa upplysta objekt så de hamnar på en endaste ny och tom texture.

Sedan kan man ju antingen "måla" ljuset för hand, om man föredrar det. Jag gjorde det dock lite enklare för mig (eller svårare om man inte vet hur man gör...) Eftersom jag har två UV-mappslager, dels det gamla som är kopplat till deras ursprungliga "dag"-texturer och dels den nya mappningen som är till den nya, mindre "natt"-texturen kan jag välja vilken jag vill använda. Så jag sätter upp ett material i Blenders inbyggda path-tracing renderingsmotor Cycles där jag tar "dag"-texturen in i materialet. Därefter så sätter jag upp en scen med nästan helt svart bakgrund och lampor med orange/gult ljus. När jag sedan renderar så kommer det se ganska verkligt ut med mörka mesher, men upplyst i närheten av lamporna. Därefter bakar jag dessa till "natt"-texturen och använder den nya UV-mappningen till detta. Då kommer exakt samma ljus att ritas av Cycles direkt till den nya, tomma texturen. Denna kan man sedan använda som en helt vanlig textur i Trainz. Det enda lilla kruxet är att man drar upp Emit i materialet i Blender innan man exporterar. Då kommer detta material att bli självlysande.
Sedan ska bara ljusmeshen styras av ett script, så meshen visas när man slår på ljuset. Om du flippar ljuset på och av så kommer du kunna se gränsen mellan dag-meshen och natt-meshen.

Inte så svårt va? Kanske inte något man ska ge sig på i första taget, men jag blev riktigt nöjd med resultatet!

Det fungerar till alla sorters statiska ljuspunkter, så lampan i taket, visst! Men det skulle antagligen kräva en väldigt stor natt-mesh. Och spakar och annat rörligt kan inte vara upplyst.
Om du vill ha det på Thor också, så kan jag fixa det om du skickar mig meshen till interiören, eller så slänger jag ihop en mer noggrann, steg för steg instruktion med bilder på hur man gör.

[tanigardi]

Nu är alla animationer på plats förutom omkastaren och fyren. Fyren utförs vad jag förstått enl. Auran's metod. Omkastarens animation har jag däremot lite funderingar kring. Själva omkastarskruven animeras ju med 75+1+75 frames från full back, dessutom så roterar ju själva skruven åtskilliga varv från ändlägena. Så min fundering gäller ju hur själva omkastarmuttern skall animeras, det blir ju en "linjär" animering men bör ju innebära att den skall animeras med ett mycket större antal frames än omkastarskruven om visarens läge skall stämma med aktuell fyllning.

snip_20170803132310.jpg

Lite fler funderingar.

Har animerat höger främre dörr med sitt handtag, med avsevärt fler frames än dess fönster. Detta för att handtaget skall kunna fällas ned och upp utan att det ser ut som handtaget går rakt genom hyttväggen. Måste fönstret vara animerat med samma antal frames som dörren?

I configen till B-lokets hytt's mesh-table så står bara "att-parent" när det förekommer ett mesh som vars parent är ett annat mesh, varför ? (hoppas svammlet var begripligt )

Mvh!

Åke

[lan]

Hej Åke,
Korvtiger kan säkert reda ut detta också, men jag kan bidra med lite grann:

Antalet frames på skruven och omkastarmekanismen behöver inte vara samma men det viktiga är att samordna rörelserna. När vi animerade gick vi från full back till full fram, sen skriptade Korvtiger detta.

Dörren är en animerad mesh och fönstret en annan, där fönstret är fäst vid en rörlig attachpunkt som följer dörrens animation - alltså fäst i en a.r.nnnn/a.mmmm där a.r.nnnn är länkad till b.r.nnnn.

Men som sagt - Kortigers förklaringspotential är skyhögt överlägsen min

[korvtiger]

Själva fyren (glöden) med ljuseffekter som finns beskriven för äldre versioner av Trainz har jag för mig vi kom fram till att den inte fungerade i TANE. Tror vi skippade effekter med fyren över huvud taget på Lans lok. Det skulle i alla fall gå att använda Emit på materialet så det blir självlysande, vilket jag tror vi glömde.

Ursprungligen postat av tanigardi

Omkastarens animation har jag däremot lite funderingar kring. Själva omkastarskruven animeras ju med 75+1+75 frames från full back, dessutom så roterar ju själva skruven åtskilliga varv från ändlägena. Så min fundering gäller ju hur själva omkastarmuttern skall animeras, det blir ju en "linjär" animering men bör ju innebära att den skall animeras med ett mycket större antal frames än omkastarskruven om visarens läge skall stämma med aktuell fyllning.

Nej, varför? Hur skulle det göras? Hela omkastaren, veven och muttern med visaren är en mesh, en control som animeras med en animation över 75+1+75 frames. Själva muttern går som du säger linjärt från längst bak till längst fram. Veven går ungefär 6 hela varv från full fyllning bakåt till full fyllning framåt på ett lok av Sbs storlek har vi räknat ut. Kanske något mindre på Thor.
Mitt tips är att "keya" varje hela tiotal samt de båda ändlägena, så frame 0 (=-75%), sedan var tionde frame, så frame 5 (=-70%), frame 15 (=-60%), frame 25 (=-50%), ...., frame 75 (= 0%), frame 85 (= +10%), frame 95 (= +20%), ... , frame 145 (= + 70%), frame 150 (= +75%).
Sedan kanske muttern och visarens animation inte blir helt linjär eftersom omkastarskalan inte alltid är helt linjär, beroende på att det är mycket cirkelformade rörelser i slidstyrningen, så skalan är väl egentligen ett utsnitt av någon form av sinusfunktion. Därav att vi valde att keya som vi gjorde för att varje hela tiotal skulle matcha perfekt bakkant på visaren mot kanten på trappsteget. Om du slår på free camera och går fram till omkastaren i hytten på något av Lans lok kan du se procenttalen och trappstegen tydligt, samt var visaren pekar. Som sagt är det bakkanten på visaren som är där den markerar. Vid 0% ska bakkanten på visaren vara i bakkant på "fenan" som markera 0% på skalan.

Sedan är det ju låsspaken som blir en separat spak, men den behöver ju inte animeras för hand så den bara roterar runt en axel.
Har två halvbra bilder på omkastarskalan sedd uppifrån där man ser markeringarna med 10-tals procent, som jag tog i Grängesberg om du vill ha. (Lan, för övrigt så hade vi helt rätt i att 10% inte skrivs ut, utan att första "trappsteget" ska vara +/- 20%, så vår modell är helt korrekt!)

Ursprungligen postat av tanigardi

Har animerat höger främre dörr med sitt handtag, med avsevärt fler frames än dess fönster. Detta för att handtaget skall kunna fällas ned och upp utan att det ser ut som handtaget går rakt genom hyttväggen. Måste fönstret vara animerat med samma antal frames som dörren?

Nej, detta fungerar alldeles utmärkt! Det är ju två helt olika controls, bara att den ena råkar vara parentad till den andra.
Sedan som jag beskrivit i dokumentationen till STL ångloksscript så går det att animera över olika antal frames för interiörens mesher och de mesher på den exteriöra modellen som deras "öppenhetsgrad" speglas på, då den mäts i procent och inte i frames ifall du inte skulle behöva lika mycket frames till exteriöra animationen av dörren.

Ursprungligen postat av tanigardi

I configen till B-lokets hytt's mesh-table så står bara "att-parent" när det förekommer ett mesh som vars parent är ett annat mesh, varför ? (hoppas svammlet var begripligt )

Att-parent (kort för attachment parent) talar om vilken mesh i mesh-tablen som attachment pointen (emptyn) finns på som refereras till i att-taggen, om det var vad du menade. Så för fönstret i dörren ska att-parent vara dörrens mesh-namn i mesh-tablen och attachmenten(emptyn) ska vara i dörrens mesh, länkad till latticen så den rör sig korrekt och namngiven som Lan beskriver, a.r.door_lattice/a.window, där a.r.door_lattice är namnet på den dummy/lattice (b.r.door_lattice) som attachmenten är parentad till. Hoppas det var begripligt.

[tanigardi]

Stort tack för klargörande info. Skall försöka mig på omkastaranimeringen, och se hur det går och om jag fattat det hela rätt. Det bästa är ju att kasta sig in och försöka, rätt vad det är så brukar det gå upp en talgdank hur det hela skall utföras.

Vad gäller mesh table'n så var min undring varför man inte behöver ange att-parent "default" på meshen som är parent till interiören.

Skulle gärna vilja ha bilderna på omkastarskalan, glömde själv att fotografera den vid mitt besök i hytten på Thor förra sommaren.

Mvh!

Åke

[korvtiger]

Du har PM!

Aha! Det är för att default-meshen är den som används om inte någon annan mesh anges med att-parent. Så alla mesher som har attachments på default-meshen behöver man inte använda att-default på. Och default-meshen för interiören monteras automatiskt av Trainz på a.cabfront i lokets default-mesh.

[tanigardi]

Har nu i princip loket färdigmodellerat och har ägnat mycket tid åt att få till config-filerna och scripten. Har varit lite som att leta nålar i en höstack, en felstavning, en felvänd klammer etc. Nu äntligen så har jag fått in både boggierna, interiören och bodyn felfria i CM, men problemet som jag inte lyckats lösa är att trots att loket visas som felfritt så syns det inte i previewen eller i Trainz (dock kan man hitta loket i listan i trainz men det syns ej när man försöker sätta ut det på spåret.

[tanigardi]

Borde väl tillägga hur jag gått tillväga. Interiören syns in i förhandsvisningen och i scriptet har jag inte lagt till något förutom förutom "include", "class" och "isclass". Boggierna syns i förhandsvisningen, drivboggien ser ju lite märklig ut med alla stänger utspridda lite hur som helst, som scenery object ser boggien normalt ut.
Bodyn, där har jag plankat från b-lokets config allt som verkar vara tillämpligt. I "steam" har jag tagit alla värden till de saker som gäller för thor, från b-loket för att ha något att utgå ifrån. "Mass" har jag höftat till 70 procent av tjänstevikten minus vikten av vattnet i pannan. (Har inte hittat några uppgifter på tenderns vikt).

I engineconfigen där har jag lagt in allt som gäller för tryckluftsbromsen från b-loket med för hoppningen att man på detta sätt skulle kunna simulera handbromsningen av tågen via tangentbordet enbart.
"motor" där har jag taget värdena som ett mellanting mellan Donj's mallet och donj lok nr 5. "steam" där är värdena framtagna med hjälp av ett kalkylark skapat av "Billegulla.
I scriptet har jag lagt till förutom det obligatoriska, steam id'n på: sand, pysare on, steam brake och turbo generator.