1. 3D landskab

    Kategori: Ramblings | Tags: , , ,
    Skrevet af d. 2009-10-29 kl. 15:32:55, sidst opdateret d. 13. apr 2010 kl. 10:30:51

    Vores studenterprogrammør Asger, har haft leget med 3D visualisering og programmering. Her følger en artikel om hans første udskejelser i den virtuelle verden.

    En god indgang til 3D programmering er landskabet. Landskaber er som oftes statiske og programmøren behøver derfor ikke tage hensyn til bevægelige dele. På nettet kan man finde tonsvis af tutorials omkring landskabsgeneration ud fra højdekort, både ment som introduktion til 3D programmering, men også til de udviklere, der gerne vil optimere deres første implementation og tilføje flere visuelle effekter til det. Desuden er udgangspunktet for mange spiltyper, FPS-, RPG- eller strategispil, en verden hvor spilleren kan bevæge sig rundt, og landskabet kan være grundstammen for at skabe denne verden.

    Derfor faldt valget naturligt på et landskab som første applikation til at prøve kræfter med 3D programmering.

    En demo af Asger’s landskabsapplikation kan ses her:

    En 3D verden er mere end bare trekanter tegnet på en skærm. Det kan være en god idé at finde sig en 3D engine til at tage hånd om bruger input, renderingsstrukturen og som tillader programmøren at abstraherer fra hvordan billeder loades som texture og hvordan matematikken bag rotation og kollision fungerer.

    Her faldt valget på OpenEngine. En open source engine komplet med matematik biblioteker, geometri abstractioner, loading af 3D Studio Max modeller og brugerinputhåndtering. Derudover kan programmøren selv ændre eller tilføje til engine, hvis man har idéer til udvidelser.

    OpenEngine har desuden en OpenGL 2.0 extension. OpenGL er et cross platform 3D api, så dette vil tillade landskabsapllikationen at køre på både Linux, Mac os X og Wndows. Windows har desværre ikke support i øjeblikket, så det vides ikke om OpenEngine stadig kan køres fra det OS.

    Rustet med OpenEngine skulle landkabet så implementeres. Det er pt. blevet til et landskab med følgende features.

    • Level of detail – Landskabet understøtter dynamisk level of detail. Det vil sige at når kameraet flytter sig længere væk fra landskabet, bliver landskabet automatisk mindre detaljeret. Grunden til dette er at langt væk fra vil brugeren alligevel ikke kunne se de finere detaljegrader, så vi kan fjerne disse og vinde noget performance.
    • Culling – En anden måde at vinde performance på er naturligvis ved slet ikke at tegne noget. Det giver ikke meget mening for ting på skærmen, men for geometri der er udenfor skærmen eller gemt bag ved anden geometri, kan man vinde ekstra performance ved at culle disse.
      Landskabet understøtter dette ved en teknink kaldet frustum culling. Her beregnes der en boks rundt om dele af geometrien og denne boks testes så imod skærmens placering. Kan boksen ikke ses på skærmen, kan geometrien inde i boksen naturligvis heller ikke og vi undlader derfor at sende geometrien til grafikkortet.
    • Geomorphing – Problemet med level of detail er at der pludselig popper flere vertices ind i verdenen når verdenen bliver mere detaljeret, eller der pludselig forsvinder en del af verdenen når nogle detaljer fjernes. Denne poppen er meget synlig for brugeren og skal derfor fjernes. Der er flere løsninger til dette,
      blendinggeomipmapping eller geomorphing. Valget faldt på geomorphing, da denne rimelig nemt kan udvides til at tillade et dynamisk terrain og kan laves med næsten intet performance tab i en shader.
    • Normalmaps – Et problem, der ikke er håndteret ved geomorphing, er skygger. Skyggerne er som udgangspunkt beregnet pr vertex, men dette giver samme poppen i skyggerne, som vi lige har fjernet ved geometrien.
      Løsningen her er enten at morphe skyggerne sammen med geometrien eller bruge et normalmap. Begge løsninger er blevet afprøvet og den sidste er klart den flotteste. Grunden er at ved brug af et shadowmap har vi altid skyggerne i den højeste detaljegrad, så selvom små bakker i landskabet ikke længer bliver tegnet i geometrien, kan spilleren stadig ‘se’ dem, da de stadig kaster skygger på terrainet. Denne løsningen tillader også at fjerne nogle af de højeste level of details for yderligere performance, men spilleren vil stadig kunne ‘se’ dem, da skyggerne stadig kastes.
    • Shaders – Skal man lave noget som helst interessant i 3D grafik i dag skal man bruge shaders. Shaders tillader programmøren selv at specificerer hvad grafikkortet skal gøre med vertices og hvordan det skal beregne farver og skygger.
      Naturligvis er der derfor også brugt en shader på landskabet. Denne står for at lave geomorphing, smide texture på landskabet baseret på højde, så der kommer strand i bunden og sne på toppen af bjergene. Desuden beregner den skygger og hvor meget af landskabet, der skal kunne ses under vand.

    Koden bag landskabet kan ses her eller ved at hente OpenEngine, som beskrevet her og hente projektet terrain. Herfra kan projektet også kombileres og køres. Som nævnt er der ikke Windows support for OpenEngine pt, så projektet er kun blevet testet under Linux og Mac os X.

    Go’ bryllupsferie!

    Kategori: Meddelelser
    Skrevet af d. 2009-10-12 kl. 14:49:26

    Fra alle os i Hinnerup Net de bedste ønsker til Jakob og Else Marie om en fantastisk bryllupsferie samt al held og lykke fremover!

    justmarried

    Undgå advarsler om usikkert indhold

    Kategori: Gode råd | Tags: , , ,
    Skrevet af d. 2009-10-07 kl. 11:54:53, sidst opdateret d. 08. okt 2009 kl. 13:59:36

    Når man har truffet valget at dirigere sine besøgende til en SSL krypteret side, vil det oftest være i høj grad uhensigtsmæssigt, hvis browseren skulle finde på at komme med advarsler om, at siden indeholde usikre elementer.

    IE6 - Mixed content warning
    Eksempel på IE6 advarselsdialogboks

    De logiske
    Som ofte er tilfældet viser der sig i praksis at være forskel på hvordan markedets browsere håndterer sikkerhed – herunder er de selvskrevne kandidater til en checkliste for at undgå problemer er inkluderinger af eksternt indhold, som skal angives enten med en relativ eller HTTPS URI.

    Værd at bide mærke i, i forhold til ovenstående er at følge op på hvad eventuelt 3. parts værktøjer som eksempelvis Google Analytics, Omniture og lignende indsætter af referencer – de fleste af disse har HTTPS-baserede ækvivalenter.

    De bemærkelsesværdige
    Hvad der formentlig er knap så indlysende er, at i Internet Explorer også <object codebase="..."> og <embed pluginspage="..."> skal angives relativt eller eksplicit med HTTPS. På trods af at browseren ikke gennemfører en request på URI’en, bliver der lavet en kontrol af overenstemmelse med dokumentets protokol.

    Intuitivt eller ej, gør det sig også gældende for Internet Explorer, at eventuelle inkluderede URI’er der resulterer i en HTTP fejlkode, vil blive behandlet som usikre, idet det er browserens klassificering af sine egne fejlsider.

    De lumske
    Til gengæld er det formentlig kun blandt Microsofts egne udviklere indlysende, at brugen af iframe’s med enten tom eller ingen src-angivelse betragtes som en reference til HTTP og altså vil give en advarsel på en HTTPS side. Har man brug for den tomme iframe, kan eventuelt angives en reference til et tomt dokument, eller værdien “javascript:false

    Sidst, men bestemt ikke mindst: Hvis der benyttes javascript der kalder removeChild() på et element der har et baggrundsbillede kan fejlen også optræde. Omgåelsen er nem: Sæt i stedet outerHTML='' (og nej, der er ingen logisk og rimelig grund til at tingene skal virke sådan).

    De ligegyldige
    Blandt de ting der kan ignoreres uden konsekvenser, er protokolangivelser i:

    • DOCTYPES
    • XHTML namespaces
    • Links

    Forhåbentlig ovenstående kan redde uskyldige forbipasserende for timevis af fejlsøgning – kommer man alligevel dertil hvor der skal graves, er netværksovervågning et godt angrebspunkt – herfra er høstet gode erfaringer med både Ethereal og Fiddler.

    Bemærk, at CONNECT requests altid vil ske via HTTP, men alt andet skal ske på HTTPS.