Exempel på uppdrag jag har haft genom åren


Roll/titel/system: webbutvecklare

Uppdragslängd: 2011-2011

Kund/avdelning: (konfidentiellt på kundens begäran)
Tekniska miljön bestod av: XHTML, CSS3, Javascript, PHP, MySQL, jQuery, Linux

Uppdragsbeskrivning:

Utvecklade en webb 2.0 sida

Roll/titel/system: Frontendutvecklare

Uppdragslängd: 2011-2011

Kund/avdelning: Telia
Tekniska miljön bestod av: XHTML, CSS3, Javascript, XML, Dojo, Linux

Uppdragsbeskrivning:

GUI & Frontend-webbutveckling i J2EE utvecklingsmiljö: byte av grafisk
profil på webbplatsen: http://www.telia.se

Roll/titel/system: 3D Animatör

Uppdragslängd: 2008-2009

Kund/avdelning: (konfidentiellt på kundens begäran)
Tekniska miljön bestod av: Blender, Linux

Uppdragsbeskrivning:
Jag skapade avancerad 3D animation till en e-handelslösning.

Roll/titel/system: Scriptprogrammerare

Uppdragslängd: 2008-2008

Kund/avdelning: Spark vision
Tekniska miljön bestod av: 3DS Max, Maxscript, Python

Uppdragsbeskrivning:
Jag gjorde skriptprogrammering till 3D visualiseringsprojekt

Roll/titel/system: 3D Modellerare

Uppdragslängd: 2008-2008

Kund/avdelning: Irobics
Tekniska miljön bestod av: Blender, Linux

Uppdragsbeskrivning:
Jag skapade 3D modeller till en simulator

Roll/titel/system: 3D Animatör

Uppdragslängd: 2007-2007

Kund/avdelning:Filosoffilmarna
Tekniska miljön bestod av: Autodesk Maya, Linux

Uppdragsbeskrivning:
Jag skapade 3D animation till en kortfilm.

Roll/titel/system: Programmerare

Uppdragslängd: 2006-2006

Kund/avdelning:Wikiall
Tekniska miljön bestod av: Java SE (GUI, client-server, threads, TCP/IP, Sockets, SQL, XML, Netbeans, Swing, Applets), Linux, Blender

Uppdragsbeskrivning:
Jag utvecklade ett japanskt schackspel; Igo. Det var ett fleranvändar-Igospel i Java för Internet via applets. Det ingick avancerad GUI design & klientserverprogrammering. Det innehöll även avancerad programmering av trådar & synkronisering , TCPIP sockets och SQL databas & XML lagring. Jag utvecklade det i Netbeans i Linux.

Roll/titel/system: Programmerare

Uppdragslängd: 2006-2006

Kund/avdelning:Meindbender Animation
Tekniska miljön bestod av: Autodesk Maya, Linux

Uppdragsbeskrivning:
Plugin Scriptprogrammering i Maya embed language (MEL)

Roll/titel/system: 3D Animatör

Uppdragslängd: 2006-2006

Kund/avdelning:Copy & Paste Records
Tekniska miljön bestod av: Autodesk Maya, Linux

Uppdragsbeskrivning:
Gjorde 3D animation till en musikvideo.

Roll/titel/system: VR Konsult

Uppdragslängd: 2000-2002

Kund/avdelning:Vägverket
Tekniska miljön bestod av: 3D Studio Max, VRML, Javascript, HTML, Cosmoworld, Microsoft Windows

Uppdragsbeskrivning:
Jag utvecklade en interaktiv webbaserad 3D-vägsimulator till Vägverket.

Mission impossible 1: Konvertera terrängmodeller från generator till VRML


OBS: Här är en klassisk problemlösningssituation för många år sedan.

Vid det här laget måste detta vara preskriberat ifrån allt hemlighetsmakeri (speciellt eftersom de som möjligtvis skulle varit berörda inte alls använder VRML längre). Fast om någon vederbörande tycker att informationen inkräktar på något sätt, så kan ni väl kontakta mig så kastar jag inlägget i papperskorgen.

I ett uppdrag som jag jobbade med, en gång i tiden, använde vi ett verktyg som genererade stora terrängmodeller från GIS indata.

Jag hade ansvaret för att skapa en web3d-sida från landskapsmodellerna. För att det skulle bli någorlunda webb-vänligt så valde jag att använda det klassiska formatet VRML97.

Jag ska kanske nämna att själva poängen med webb är att det ska vara plattformsoberoende, så om användaren tvingas ladda ner en specifik .exe fil för varje webbsida användaren besöker så är det inte webb enligt mig.

Förutom VRML så testade jag även Cult3D och lite andra propritary-format etc men de formaten var hopplösa att använda till terrängmodeller. En av de många bristerna med propritaryformat är att de är väldigt icke-flexibla. De är oftast skapade för ett väldigt specifikt användningsområde. Cult3D funkade i princip bara för produktvisualisering. Problemet med Cult3D var att man var tvungen att gå genom 3DS Max (R3.1) och åtminstone på den tiden var det en väldigt ooptimerad pipeline för terrängmodeller.

Istället valde jag alltså det öppna och fria formatet VRML97 (med extensioner) som var lätt att anpassa.

VRML var och är ännu ett väldigt underskattat format (det har sedan 97 uppgraderats kontinuerligt och kallas inte längre för VRML… vill du veta vad det kallas nu för tiden så kan du ju alltid skicka ett e-post till mig och fråga). Det folk inte riktigt förstod var ju att VRML bara var ett format. Det var pluginen som visade upp VRML modellen som i första hand påverkade vilken prestanda grafiken hade och inte att man använde VRML i sig. Kör man in VRML i en snabb spelmotor så går det i princip lika snabbt som vilket annat format som helst. Det är alltså grafikmotorn som är det viktiga för prestandan, inte vilket format man lagrar modellen i. Visst går det att optimera själva modellen med olika metoder, men genom att VRML är så flexibelt så är det egentligen inte alls omöjligt att skapa sådana optimeringar i VRML.

Prop-formats-utvecklarna lyckades tyvärr att övertyga folk i branschen att formatet var det avgörande för prestandan och att VRML var ett dåligt format, vilket gjorde att formatet fick en felaktigt dålig stämpel (på motsvarande sätt som en del vill smutskasta fantastiska opensource-produkter som t.ex.Linux).

Jag var alltså tvungen att konvertera från modellen från terrängmodellsgeneringsverktyget till VRML.
Verktyget generade i bästa fall formatet Openflight, vilket var väldigt tursamt. Openflight hade bland annat använts till professionella flygsimulatorer.

Jag fick leta efter ett konverteringsprogram, som konverterade från OpenFlight till VRML97. Jag hittade ett sådant på Internet. Problemet var att konverteringsprogrammet inte hanterade LOD. Openflight-filerna innehöll LODs men konverteringsprogrammet klumpade ihop LODs i en röra.

Jag kontaktade tillverkaren av konverteringsprogrammet (som fanns i Ryssland) och frågade hur man fick det att fungera. Det var uppenbarligen en liten firma så jag kom i kontakt med utvecklaren själv.
Han visste inte riktigt hur man skulle lösa problemet.

Jag läste på Openflight-specifikationen och såg att LOD i Openflight var uppbyggda på ett annat sätt än i VRML. Jag kom då på att man kunde simulera Openflights LOD struktur i VRML.

Jag kontaktade tillverkaren av konverteringsprogrammet och förklarade hur han skulle anpassa det för att konerteringen av LOD skulle funka. Efter mycket övertalning så gjorde han anpassningen, och i den nya versionen, som han även skickade till mig, så fungerade konverteringen av LODs.

Så för första gången hade någon (dvs jag) konverterat riktiga professionella Openflight-modeller till funktionell VRML (något som egentligen antagligen betraktades som omöjligt.. ”eftersom Openflight ju var så mycket mer avancerat än VRML… jada jada”… ).

Nästa problem var att uppdragsgivaren ville att transparenta kartlager skulle visas på terrängen.

Problemet var dock att verktyget, som genererade modellen, inte skapade sådana lager. Jag fick således lägga in dem själv på tusental platser i koden. Eftersom jag hade brist på tid så hann jag inte skapa något riktigt parsingsprogram i något juste skriptspråk (vilket jag hade gjort idag) för att lösa detta, utan istället så använde jag en texteditor med batch-funktion, som genom en ruggigt klurig process kunde lösa problemet utan att använda några som helst vilkorssatser.

När jag hade optimerat de färdiga modellerna så var de åtminstone 8-10% av de ursprungliga Openflight modellerna i storlek utan den minsta kvalitetsförsämring.

Sedan så skapade jag ett webbgränssnitt, animation och massor av annat. Detta tog naturligtvis mycket tid, men jag utlämnar detta från klassiska problemlösningssituationer.

Mission completed!