Thor i Tane

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