Ångloksprojekt

[korvtiger]

Tack för glada tillrop!

-----

Nu blir det en liten parentes till Sa-bygget.

På förfrågan så tänkte jag försöka förklara normalmapping lite närmare.
Detta är som jag varit inne tidigare ett lite abstrakt och svårgreppat koncept då det involverar en del matematik. För er som verkligen vill veta mer om matematiken bakom och hur man implementerar det i en egen grafikmotor rekommenderar jag denna tutorial: https://learnopengl.com/Advanced-Lig...Normal-Mapping.
Jag tänker försöka förklara det mer ur en modellerares perspektiv. För jag lovar att man inte behöver veta särskilt mycket avancerad geometri för att kunna använda normalmapping!

Men vi börjar från början: vad ska man ha en normalmap till?
Jo en normalmap används för att lägga till detaljer på ytan på de trianglar som ett objekts mesh består av. Så utan att lägga till flera vertiser och trianglar som kostar prestanda kan man lägga till massor av små detaljer och ojämnheter på triangeln - så som nithuvuden och repor - mycket, mycket billigare prestandamässigt än om de modellerats ut för hand. (tänk er bara jobbet att modellera ut alla repor i en plåt med polygoner...) Kolla bara in post #66 i denna tråd för att se vad man kan göra med en normalmap (eller en bumpmap).

Det låter ju bra, men vad sjutton är då en normal?
En normal är en vektor (tänk er en pil) som perkar ortogonalt (vinkelrät) mot en yta. Exempelvis: normalen till golvet i ett hus är en pil som pekar rakt upp. Om du står på golvet kan man säga att du är en normal till govlet. Normalen till en vägg pekar rakt ut från väggen, osv...
normalvektor.jpg
Som 3D-modellerare är begreppet normal redan bekant då det är det hållet som en triangel/polygon pekar åt. En polygon har ju två potentiella normaler, en som pekar rakt upp från ytan åt ena hållet och en som pekar rakt åt motsatt riktning. Så vi måste välja vilket håll polygonen skall peka åt genom att se till att dess normal pekar åt rätt håll.
När vi nu börjar pyssla med normalmapping kommer inte bara varje triangel få en normal, utan varje pixel kommer att ha en normal som kommer att varieras med hjälp av en textur, normalmappen. Man utgår då från triangelns normal och låter normalmappen förändra denna normal i varje pixel för att kunna skapa små ojämnheter i ytan.

Vi börjar med att jämföra de två teknikerna bumpmapping och normalmapping med hjälp av ett av SJs gamla monogram som de använde på de teakklädda personvagnarna:
explanation.jpg

Först och främst ser vi ser att bumpmapping och normalmapping ger i princip samma resultat, visuellt.
Till vänster en yta utan någon extra detaljering. Varje pixels normal på denna yta pekar rakt upp, alltså i samma riktning som hela ytans normal. Vi får en platt yta.
I mitten ser vi bumpmapping. Här använder vi en svartvit textur för att definiera höjd. Ju ljusare, ju högre är pixeln upphöjd. Längst ned ser vi hur pixlarna ger olika höjd och ifrån dessa kan grafikmotorn sedan räkna ut ytans lutning. Notera att en bumpmap inte definierar hur högt upphöjd en viss nyans innebär. Detta är helt upp till grafikmotorn att tolka.
Till höger ser vi normalmapping där normalmappen är genererad från bumpmappen. Här ser vi att en normalmap i regel är en väldigt blåtonad textur. Om vi jämför med bumpmappen ser vi att det helvita mitt på monogrammet och den grå bakgrunden har samma färg i normalmappen, en ljus blålila ton. Detta är ytor som är plana och pekar rakt upp. Vi ser att kanterna på monogrammet har olika färg beroende på vilket håll de pekar åt. Till exempel får kanter som pekar åt höger en rosa ton och kanter som pekar uppåt har mer grönaktig ton. I bilden nedtill ser vi hur de olika färgerna tolkas som vektorer som ändrar riktningen på de ursprungliga normalerna. Dessa nya normaler talar om hur den pixeln på ytan lutar. Som en parentes kan vi kan också notera att vi förlorar informationen om en ytas höjd i normalmappen jämfört med bumpmappen.


Så vi har nu sett att en normalmap är någon sorts vektorer (tänk pilar) som pekar ut den riktning som pixelns normal har och att dessa vektorer är inkodade i en blåtonad textur. Men hur fungerar detta?
Jo, för att kunna beskriva en riktning i tre dimensioner behöver man just tre koordinater. Dessa tre koordinater pekar ut en punkt i 3D-rymden. Från koordinatsystemets origo drar men sedan en vektor som pekar på punkten, och vips så pekar den vektorn (som är mycket bra att tänka på som en pil) ut en riktning i 3D-rymden. Notera att det finns oändligt många punkter som skapar vektorer som pekar ut samma riktning. Till exempel genom att fördubbla längden på vektorn, pekar den fortfarande åt exakt samma håll som tidigare, även om det är en annan punkt/vektor. Man brukar därför tala om normaliserade vektorer. En normaliserad vektor är en vektor som har längden 1. Detta gör att varje tänkbar riktning i en 3D-rymd kan beskrivs av exakt en normaliserad vektor. Om man tar alla tänkbara normaliserade vektorer ritar de upp ytan på ett klot med radien 1 runt origo. Om man accepterar detta kan man också förstå att våra tre koordinater i 3D-rymden är allt vi behöver för att beskriva alla möjliga riktningar vi kan tänkas vilja beskriva.

Följande bild förklarar det koordinatsystem som normalmappen utgör:
normalmap_axis.jpg

Så en normalmap är en färgtextur med tre färgkanaler, alltså lika många som koordinater vi behöver för att beskriva en riktning. I bilden ser vi en polygon med normalmappen på. Ytan skapar ett koordinatsystem X, Y, Z som är kopplat till motsvarande RGB-färgkanaler i texturen, så X <-> R, Y <-> G och Z <-> B. X och Y beskriver riktningar i ytan medan Z är normalen till ytan och pekar rakt upp ur ytan. Genom att koda in en koordinat i detta koordinatsystem som en färg kan vi beskriva en vektor som alltså pekar ut riktningen vi vill att normalen skall peka åt i en specifik pixel.

Hur kodar vi då in normalen som en färg?
RGB kodar som bekant färger i 256 nyanser per kanal, så 0-255 för röd, 0-255 för grön och 0-255 för blå färgkanal.
Eftersom vi vill kunna visa riktningar både i X, Y respektive Z's riktningar samt i motsatta riktningar så måste vi mappa om dessa så att halva färgskalan pekar åt motsatt håll. Då blir det så att färgnyansen 255 är så långt åt axelns riktning man kan komma och 0 är så långt man kommer i motsatt riktning. Mitt mellan dessa, värdet 128 är "0-värdet", alltså varken i axelns riktning eller motsatt dess riktning. Notera att värden under 128 på Z axeln (blå färgkanal) alltså ger en väldigt märklig normal som pekar inåt i ytan. Undvik alltså detta!
Med detta förstår vi också varför de flesta ytor på en normalmap är ljust blålila. En oförändrad normal som pekar rakt upp ut ytan (i ytans egen normals riktning) har alltså RGB värdet 128,128,255, vilket innebär ingen utsträckning åt X eller Y, men rakt åt Z. Normalen pekar alltså rakt i Z-axelns riktning och detta är just en ljust blålila färg.

Nu har vi allt vi behöver för att kunna beskriva våra normaler som en färg. Här nedan visas ett exempel med en vektor/normal i vitt som kodas som RGB = 180,90,200. För att hitta vektorn/normalen behöver vi bara följa pilar i X,Y och Z-axlarnas riktning med rätt längd. Notera att X/röd och Z/blå pekar i X- respektive Z-axlarnas riktning eftersom deras färgvärde är över 128, medan den gröna pekar i motsatt riktning eftersom värdet är mindre än 128.
normalmap_vektor.jpg


Förhoppningsvis gav denna post en lite bättre förståelse för normalmapping. Men jag betvivlar att det gjorde er mycket klokare på hur man ritar normalmaps. Men var så lugna! Ingen, inte ens textureringsproffs, målar större delar av normalmaps för hand. Man skapar dem antingen genom att rita bumpmaps för hand (vilket är hur jag gör) och låter ett program som AwesomeBump räkna om det till en normalmap, eller så genererar man dem från en högdetaljerad variant av meshen där alla nitar och detaljer faktiskt är modellerade. Det sistnämnda är dock inget alternativ om man vill ha repor och ojämnheter på varenda vägg i en ånglokshytt som ni kanske förstår. Då får man istället ladda ned PBR texturer från nätet som innehåller färdiggenererade normalmaps och använda dem i sin egen normalmap-textur.

Även om detta är lite off-topic så får ni gärna ställa frågor om normalmapping om ni har sådana. Har ni mycket frågor eller grejer att diskutera så går det givetvis bra att öppna en egen tråd också.

Hoppas detta kan vara till nytta för någon byggare där ute.

[Hawk]

Hej
Blev detta fantastiska lok släppt för nerladdning ?

[lan]

Nej, men det kanske kommer nån gång ????

Korvtigers experimenterande med Sa 1277 med ny textureringsteknik 'a l'a PBR ( Physically Based Rendering) var mycket lovande ( som man kan se på bilderna i denna tråd).
Det ligger säkert i en av Korvtigers många malpåsar på nån av hans datorer och om det blir färdigt vet nog inte ens Korvtiger - men det är en utmärkt illustration på vad en skicklig och mycket kompetent byggare kan uträtta ! Vi gamla f.d. kan bara hoppas !

[korvtiger]

Som Lan säger så har detta projekt tagit en långpaus. Visst är jag lite sugen att någon gång i framtiden bygga klart den, men just för tillfället saknar jag dator som kan köra Trainz och som är tillräckligt kraftfull för att köra Blender. Men om några år kanske?

[Hawk]

Ursprungligen postat av korvtiger

Som Lan säger så har detta projekt tagit en långpaus. Visst är jag lite sugen att någon gång i framtiden bygga klart den, men just för tillfället saknar jag dator som kan köra Trainz och som är tillräckligt kraftfull för att köra Blender. Men om några år kanske?

Tack för svar, så får man vänta...

[korvtiger]

Jag har så smått tagit upp detta projekt igen. Jag har mest spenderat tiden med att försöka hitta ett bra workflow för texturering, men är inte helt nöjd. Problemet är att ett ånglok är så stor och komplext att det blir lite för tungt för det workflow jag har kikat på. Under tiden så började jag experimentera med att exportera med hjälp av FBX till TRS2019 som jag skaffade för ett par månader sedan. Detta var helt nytt för mig och det finns fortfarande lite konstigheter som händer längs vägen, men på det stora hela fungerar det bra. Jag har lyckats exportera hela loket inklusive boggier. Och när man väl är inne i simulatorn är ju steget inte långt till att man vill se skapelsen rulla, bara för att bli besviken på att hjulen står helt still.. Dags för animering alltså!

Jag ber om ursäkt på förhand för en lång utläggning om Blender-tekniska saker med mycket ånglokstekniska facktermer. För er som inte är insatta så får ni väl kolla på bilderna istället!

SJ Sa har ju en slidstyrning av system Walschaert (uttalas "wallskart") även benämnd Heusingers eller Heusinger von Waldeggs slidstyrning. Jag har experimenterat med att animera Walschaerts slidstyrning tidigare i Blender och kollat på hur andra på internationella Trainz-forumet har gjort det. Dock så har jag varit besviken då de flesta valt att förenkla (eller fuska om man så vill...) och approximera vissa delar av rörelsen. Jag har inte kunnat hitta någon som lyckats animera rörelsen på ett tillfredsställande sätt i Blender, så jag började experimentera med det själv.

Man kan dela upp Walschaerts slidstyrning i två delar: dels de delar som drivs direkt ifrån drivhjulet som är direkt kopplade till drivhjulets rotation; och dels själva slidstyrningen som är beroende av den första delen och av fyllningsgraden som styrs av föraren.
Den första delen som bara är beroende på drivhjulen är ganska trivial att rigga och animera. Dels är det kolvrörelsen med kolvstången och dels är det kulissens rörelse. Båda dessa kan riggas på lite olika sätt, men alla borde ge samma resultat, inga konstigheter.
Den andra delen däremot, själva slidstyrningen är mer komplex, särskilt på lok med Walschaerts slidstyrning.

Det första som jag tänkt på som många andra väljer att förenkla är hur rörelsen från tärningen i kulissen och rörelsen från tvärstycket vävs samman. Vad man gör är att man begränsar rörelsen av kopplingen mellan försprångsstången och tärningsstången till att bara vara horisontell, vilket förenklar hur man riggar tärningsstången. Detta resulterar dock i att slidstången börjar att röra sig upp och ned på samma sätt som den punkt man fixerat horisontellt borde ha gjort. Eftersom avståndet mellan slidstången och tärningsstångens infästning i försprångsstången är ganska kort, så märker man bara av denna rörelse om man studerar slidstyrningen mer noga (Se vänstra bilden i animationen nedan). Dessutom kan man dölja det ytterligare genom att låsa slidstångens rörelse i horisontell led, så att slidstångens infästning i försprångsstången egentligen bryts, vilket märks ännu mindre (Se mittenbilden i animationen nedan). Men ni som känner mig förstår att jag inte skulle nöja mig med sådana approximationer.
Egentligen så är ju försprångsstången fast sammanbunden med slidstången och kan därför inte röra sig i vertikalled (i fästpunkten med slidstången), utan bara horisontellt, samt rotera kring fästpunkten i slidstången. Slidstångens position och den vinkeln som försprångsstången intar ska drivas ifrån tvärstyckets rörelse, samt ifrån kulissen.


Från vänster:
1. Försprångsstången och tärningsstångens koppling är låst i horisontalled längs grön axel (notera hur slidstången rör sig upp och ned något)
2. Samma som den första, men med slidstångens rörelse låst i horisontalled i blå axel (notera hur kopplingen mellan försprångsstång och slidstången inte hänger ihop)
3. Korrekt beteende enligt min lösning (notera att försprångsstången och tärningsstångens koppling rör sig upp och ned på ett korrekt sätt)

Detta visar sig vara ganska svårt att få till i Blender, vilket ledde mig till att generalisera problemet och fråga om hjälp på ett Blenderforum. Jag illustrerar problemet med följande bilder:
rigging_question4.jpg
rigging_question3.jpg

I problemet så vill jag styra punkterna A och E och få Blender att räkna ut positionerna för B, D samt för C, där C enbart får röra sig horisontellt (längs med X-axeln i illustrationen). Låter som ett enkelt problem va? Tydligen inte. Jag diskuterade och bollade idéer med expertisen utan att få något bra sätt att lösa det på. Så jag började fundera på om man kunde formulera det hela som ett Constraint Satisfaction Problem (CSP: https://en.wikipedia.org/wiki/Constr...action_problem), alltså ett ekvationssystem med massor av matematiska villkor som måste vara uppfyllda, i detta fallet:
length(A, B) = en konstant
length(B, C) = en konstant
length(C, D) = en konstant
length(D, E) = en konstant
length(B, D) = en konstant
samt där x och y för A och B är kända (eftersom jag själv har positionerat dem) samt att y för C är känd.

Med dessa ekvationer plus några begränsningar för att hjälpa till med det hela (B_x < A_x t.ex.) borde det gå att lösa systemet och ställa upp en ekvation för C_x, enbart beroende på A och Bs positioner. Denna ekvation skulle jag sedan kunna använda mig av i Blender för att positionera en Empty för punkten C och driva den ifrån positionerna för A och B. Sedan skulle det vara trivialt att sätta upp en eller två armaturer med inverse kinematics (IK) för att få till rörelsen A->B->D->E (Alternativt en för A->B->C och en annan för E->D->C).

Jag började att försöka lösa detta ekvationssystem. Efter två sömnlösa veckor och fem fullklottrade papper så insåg jag att det faktiskt går att lösa ekvationssystemet, men att det skulle bli ett så komplicerat uttryck för C_x att jag inte kände att det var rätt väg att fortsätta.

[korvtiger]

(Fortsättning från förra inlägget p.g.a. att jag nådde gränsen för max antal tecken.. )

----

Det andra som folk brukar förenkla (antagligen på grund av bristande kunskap om slidstyrningar ) är att låta tärningens position i kulissen vara fix och driva tärningsstångens rörelse därifrån. Men detta är inte helt sant. För om man väl börjar kika noga på ånglok i rörelse (eller som jag, detaljgranskat och lekt så mycket med att rigga slidstyrningen att man insett att så måste vara fallet) så inser man att tärningen faktiskt rör sig något upp och ned i kulissen under ett drivhjulsvarv. Detta beror på att tärningsstången hänger ihop med omkastningsveven genom lyftlänken. Omkastningsvevens position är fix, den bestäms med hjälp av omkastningsveven inne i hytten och låses fast med en hake. Det gör att hela tärningsstångens rörelse blir begränsad av att den är upphängd i lyftlänken. För att allt ska fungera måste därför tärningen röra sig något i kulissen för att kompensera denna låsning.

Detta började jag att hitta en lösningsväg på genom att jag insåg att man borde kunna driva tärningsstångens rörelse från kulissens teoretiska mittpunkt, istället från tärningens position i kulissen. Så istället för att armaturens första ben utgår ifrån en punkt på kulissen som de flesta verkar göra, så börjar första benet i den teoretiska mittpunkten till kulissbågen och går sedan till tärningen och därefter vidare till tärningsstången. Detta var en bra start, men sedan fastnade jag med samma problem som ovan, att jag på något sätt måste begränsa tärningsstångens rörelse på mitten av ett ben, likt hur försprångsstången B-D begränsas av punkten C som ligger mitt på benet.


Efter att ha övergett idén om att lösa det generella problemet med ekvationssystem började jag istället utforska Blenders verktyg för IK och insåg att det faktiskt fanns verktyg för att låsa ett bens rotation i förhållande till dess förälder, samt att man kan ha flera IK-kedjor i samma armature. Detta tillsammans med en idé om att man kan approximera punkten C:s horisontellt låsta rörelse som en cirkel med tillräckligt stor radie fick alla bitar att falla på plats.

Min lösning på det generella problemet ovan blir alltså:
* Skapa en armature med ben A->B->C->D->E
* Lägg till en IK constraint på D->E med en Empty som target
* Lägg till en IK Lock på benet C->D så att B->C->D alltid hänger ihop som om det vore ett ben (Hittas under Bone properties>Inverse Kinematics när man är i Pose mode)
* Extrudera ett nytt ben ifrån punkten C och dra det nedåt en bra bit
* Skapa en Empty vid spetsen på det nya benet och lägg till en IK på benet och peka på Emptyn

Voila! Nu kommer punkten C att vara begränsad av att den alltid måste vara på samma distans från Emptyn som ligger långt ned. Den kommer alltså att bara kunna röra sig i en cirkel runt den punkten. Naturligtvis kommer C att åka nedåt om den flyttar sig långt ifrån sin ursprungspunkt, men ju längre man gör hjälpbenet, ju mindre kommer felet att bli. Tycker man om trigonometri kan man roa sig med att räkna ut hur stort felet blir för en viss längd på benet. Detta är fortfarande en approximation, men för detta ändamål fungerar det riktigt bra då punkten C inte rör sig så långt från sin utgångspunkt. Dessutom är det inte särskilt svårt att sätta upp denna rigg heller.

Dessa idéer möjliggör faktiskt att rigga hela Walscharts slidstyrning.
Jag använder en armature som utgår ifrån kulissens teoretiska mittpunkt (mittpunkten är parent:ad så att den roterar runt kulissens rotationspunkt som ju drivs av excenternstången från drivhjulet) med först ett ben till tärningen. Sedan är tärningsstången uppdelad i två ben, först fram till lyftlänken och sedan vidare till försprångsstången. Det andra benet har en IK Lock för att sitta ihop med det första så att de bildar ett ben. Förprångsstången är uppdelad på samma sätt med ett ben ned till slidstången och ett från slidstången ned till försprångslänken med IK Lock. Sedan ett sista ben för själva försprångslänken till tvärstycket med en IK constraint med en Empty som target vilken i sin tur får rörelsen från tvärstycket. Därefter använder jag tricket med ett långt hjälpben som låser slidstångens rörelse horisontellt som jag beskrev ovan, vilken ju också har en IK constraint till en Empty. Till sist har vi lyftlänken som är ett ben som utgår ifrån de båda benen som utgör tärningstången. Denna har en IK med en Empty som target. Denna Empty är ju fästpunkten för lyftlänken i omkastningsveven och denna kan man sedan parenta till omkastningsaxelns rotation och här kommer nu det smått fantastiska:
Med denna setup, kan man välja fyllning enbart genom att vrida omkastningsaxeln, precis som i verkligheten! Tyvärr stödjer ju inte Trainz att kunna ställa slidstyrningen i spelet, men med denna rigg kan man ju i alla fall exportera en korrekt slidrörelse för en viss fyllning.


Animation på hela härligheten, tärningen i toppen på kulissen, vilket den är vid backgång med SJ Sa (även om hjulen snurrar framåt på animationen... ). Notera drivningen till hastighetsmätaren på bakre drivhjulet!


Närbild på slidstyrningen, nu är med tärningen i botten på kulissen vilket betyder att loket driver framåt

Notera hur tärningen rör sig något upp och ned i kulissen, precis som den ska!

En bra sak till med denna lösning är att den utan vidare stödjer alla mindre variationer av Walschaerts slidstyrning, som där man kan ha lyftlänken fäst på tärningsstången mellan tärningen och försprångsstången (som på Sa) eller bakom kulissen (se bifogad blendfil), eller där slidstången kan vara fäst i försprångsstången över fästet för tärningsstången eller under som på Sa.


För er som är intresserade att titta närmare på lösningen så bifogar jag två blend-filer, en med lösningen på det generella problemet som jag visade i förra inlägget och en med hela Walschaerts slidstyrning typ så som den är uppsatt på min Sa, men efter ritning på något amerikanskt(?) lok där lyftlänken är fäst bakom kulissen. Armature:en är dock exakt likadan som på min Sa.
I den första filen kan man testa genom att i pose mode röra på benen TopBlack och BottomBlackTarget och se hur riggen sköter sitt jobb med att placera punkten C.
I Walschaerts-filen, starta hjulanimationen med mellanslag och rotera sedan på Emptyn ReverseArm för att ändra fyllningsgraden och gå mellan framåt och back.


Sådär, det var all information jag ville häva ur mig denna gång. Hoppas att någon fann det intressant!

[tanigardi]

Otroligt intressant lösning. Har just börjat försöka sätt mig in hur du riggat, tar nog lite tid, är inte så snabb i vändningarna precis. Upptäckte också när jag kollade min egen animation av Sexans slidstyrning att kolvstången vobblar något, förmodligen har jag väl inte fått kolvstångens "ghost" i rätt position. Har också kämpat med samma problem du tar upp men inte lyckats få till det helt korrekt. I och för sig syn ju inte "fusket" i Trainz men man vill ju att det skall vara korrekt. Vad jag kan se av min lösning som bygger på "Ushi's variant från Aurans forum, så är väl problemet att tärningen inte rör sig i kulissen och att lyftlänken rör sig något i tärningsstången. Ett stort problem med Sexans slidstyrning var bristen på ritningar, hittade bara en mycket lågupplöst schematisk ritning där man knappt kunde urskilja detaljerna. Fick lov att sätta ut den med hjälp av foton och "trial and error", med hjälp av en oherrans massa cirklar.
Hoppas att jag kan komma med frågor lite längre fram när jag testat din metod.

[korvtiger]

Kul att det är av intresse! Det är bara att fråga på om något är oklart!
Om du inte lyckas dissekera mina filer själv så skulle jag kunna bidra med någon steg-för-steg-instruktion med bilder på hur man gör, men sådant tar ju lite tid att göra.

Det finns nog bättre sätt att rigga kolvrörelsen utan att använda en ghost, jag bara tog den första som jag lyckades få att fungera i mitt exempel.
När jag skapar ghosten brukar jag göra såhär:
Jag markerar mittpunkten på armaturen (alltså kopplingen mellan kolvstången och vevstaken, den punkt som ska vara mitt mellan vevstakslagret och ghosten), flyttar dit 3D-cursorn med Shift-S>Cursor to Selected.
Därefter väljer jag 3D-cursorn som Transform Pivot Point (https://docs.blender.org/manual/en/2...int/index.html) så att man roterar saker med 3D-cursorn som pivot istället för mitten på objekten eller vad man nu har inställt.
Därefter kopierar jag (eller skapar och placerar) Emptyn som markerar vevstakslagret i hjulet för att skapa ghosten och roterar det 180-grader runt X-axeln (runt 3D-cursorn). Och vips så hamnar den på rätt plats!
Sedan måste man ju strula lite med constrainten, eftersom ghosten flyger iväg så fort man lägger på Copy Location constrinaten. Jag brukar bara markera ghosten, flytta dit 3D-cursorn med Shift-S som ovan, lägga på constrainten och sedan flytta tillbaka ghosten till 3D-cursorn med Shift-S>Selection to Cursor.

[tanigardi]

Har testat din lösning på animationen, fungerar super. Det mest frapperande är ju enkelheten i lösningen. Enda nackdelen är ju att man fastnar i att sitta och ändra på tärningenens position i kulissen hela tiden och förlorar värdefull modellerings tid

Har också följt din tråd på Auran's forum, verkar ju intressant med Paul Hobbs förslag med "stretching" ihop med IK-lock. Har inte hunnit pröva än, men vad jag kan förstå är det inte så enkelt att få till som det verkar. IK-lock är också en funktion som jag tidigare inte haft koll på, har ju sett det men inte förstått hur det skulle implementeras. IK-lock verkar vara något som kan förbättra min animation av sexans eldstadsluckor, som det är nu är den inte särskilt elegant, men den fungerar.
På Auran's forum diskuterades ju också om att exportera Armaturerna direkt utan att använda sig av empties som objekten är parenterade till. Har prövat själv, funkat ibland och ibland inte. Kan ju kanske vara ett problem som sitter framför tangentbordet

[korvtiger]

Du får hojta till om du behöver hjälp med eldstadsluckorna! Har fått mersmak på IK-rigging problem efter det här nämligen!

----


Idag blir det bara en kort uppdatering. Jag har äntligen fixat till ett vettigt workflow för texturering. Det är inte helt perfekt, men det fungerar ganska bra och är smidigt. Bara under dagen igår texturerade jag om hela loket (exklusive hjulen) helt från grunden! Det kommer antagligen en lång utläggning om hur jag gjort och vilka verktyg jag använt för de som är intresserade lite längre fram.

Tills dess får ni njuta av den första bilden av loket inne i simulatorn!
Ingame_1.jpg

Det saknas fortfarande en hel del rör och slangar och glas-texturen är högst provisorisk. Men den är inne och den rullar och hela animationen av hjulen fungerar!

[tanigardi]

Ser ju väldigt lovande ut, är speciellt imponerad av textureringen av slidstyrningen, du har verkligen fått fram effekten av oljig, lätt rostig metall

Ser verkligen fram emot en beskriving av ditt texturerings-workflow.

Vad gäller mina eldstadsluckor så har jag animerat om dem med hjälp av IK-lock och IK-stretch a la Paul Hobbs, gick som en dans. Har även försökt att animera slidstången med hjälp av samma metod, men där gick jag bet

[Vänersborgs_Stinsen]

Helvete va fint detta blir!!

[Bengan]

Ursprungligen postat av Vänersborgs_Stinsen

Helvete va fint detta blir!!

👍👍👍 Instämmer. Man skulle nästan kunna ta det som ett foto.

[Jockes]

Riktigt, riktigt läckert korvtiger!!