Glorg v2

[GeirGrusom]

Jeg har begynt helt fra nytt på Glorg, denne gangen legges kildekoden på nett under Google Code med Mercurial. For de som ikke vet hva Glorg er, så er det et grafikk og spill API for .NET som jeg har brukt i mange av prosjektene mine.

Etterhvert har jeg nå innsett at Glorg ikke kan nå særlig lenger uten en massiv overhaling, så derfor har jeg bestemt meg for å begynne på nytt, og nå skal den være cross-platform fra bunnen av.

Dette har jeg lykkes noe i, men jeg mangler erfaring fra X og da spesielt glX, så hvis noen har noe å tilføye der, hadde det vært fint

 

Kilder er tilgjengelig fra http://code.google.com/p/glorg2/

Ingen binærfiler klare enda.

 

Foreløpig er det X delen som ser ut til å skape mest hodebry, ettersom utifra tutorialen på OpenGL.org så virker det vanvittig mye mer komplisert enn det er under wgl. Hvorfor vet jeg ikke, fordi jeg er ikke godt kjent med X, og etter en del googling, ser det ut til at svært få er det.

 

Fremover ser jeg for meg at Glorg v2 ihvertfall skal nå original Glorg på muligheter, men ta igjen på å være bedre designet og oppbygget, samt utnytte generics og delegates bedre.

 

Glorg v2 vil også krever minimum OpenGL v 3.2 og dermed må man ha DirectX 10 hw for at det skal fungere. Jeg skal også forsøke å legge inn mer og bedre arbeid i lyd-biten av Glorg som var temmelig mangelfull i den forrige. Scenegraphen skal også kunne serialiseres fra bunnen av, som jeg ikke helt tenkte på i forrige versjon.

 

Det jeg foreløpig har skrevet som til dels fungerer er:

- wglContext

- Vector datatyper (2, 3 og 4)

- Matrix datatype

- Quaternion datatype

- Linker som brukes for å laste .Dll-er og .so-filer og hente ut funksjoner fra dem

Jeg har enda ikke noe grafisk å vise, og jeg mistenker at det tar litt tid før det dukker opp. Viktig å ha et godt fundament.

 

Hvis noen er interessert i å bidra, er det bare å sende PM.

 

Kommentarer taes i tråden Kommentartråd for Glorg v2

Endret 6. april 2010 av GeirGrusom

[GeirGrusom]

Har lagt til flere ting nå, men ikke jobbet noe mer med glX. Jeg har derimot implementert Vertex Buffer Objects, Shader Objects, og 16-bit flyttalsdatatype (Half) og tilhørende vektorklasser.

 

Vertex Buffer Objects bruker delegates (og closures) for å gi vertex peker og lignende, fremfor slik det var i gamle Glorg, hvor den gikk igjennom et array for å finne passende funksjon. Fordelen nå er at passende funksjon er funnet ut på forhånd, med passende parameter, som skal etter boka være mye raskere.

 

Vertex Buffer Objects består av BufferObject<T> (abstrakt) VertexBuffer<T> og IndexBuffer<T>.

 

Shader Objects fungerer mer eller mindre helt likt slik det gjorde i Glorg.

 

Alt i alt er jeg fornøyd med slik glorg er bygget opp nå. Det mangler derimot svært mye enda, mest viktig kanskje teksturer og framebuffers.

[GeirGrusom]

Da har jeg gjort en del oppdateringer, samt fått til noe visuelt Dog foreløpig fungerer dette kun under Windows så lenge jeg ikke får til glX.

 

Demoen som ligger med bruker Vertex Buffer Objects for å vise et 512x512 terreng med normaler. På min maskin får jeg rundt 1500 fps.

 

Jeg har lagt til en Game klasse som fungerer nogenlunde slik Game klassen i XNA gjør, med unntak av at denne ikke bruker fixed step. Jeg har ikke laget noe scenegraph enda, ettersom såpass mye fortsatt mangler. Men Game klassen gjør det relativt enkelt å lage et program, ettersom den lager en render tråd og eventuelt en simuleringstråd for deg. Det er laget slik nå at rendertråden venter til simuleringstråden gir klarsignal før den rendrer, ettersom at dersom det er lav frame-rate for simuleringstråden er det lite poeng i at rendertråden skal fortsette. FPS blir regnet ut i rendertråden og vil derfor ta med seg hvor lang tid simuleringstråden bruker også, ettersom den må vente på den.

 

 

Selve programmet kan lastes ned her:

Glorg v2 Donwload

[GeirGrusom]

Jeg har lagt til en rekke nye ting, blant annet teoretisk Linux støtte. Det funker ikke i VirtualBox, men jeg fikk en VirtualBox feilmelding, så det kan være der problemet ligger. OpenGL funksjonene for øvrig funker fint (glGetVersion, glXGetProcAddressARB) men kall til ARB funksjoner gir

OpenGL Warning: vboxCall failed with VBox status code -39

 

Jeg har bygget opp et scenegraphsystem, der alle objekter blir organisert i et tre. I tillegg til treet, er det lagt til en lineær liste som skal føre til raskere oppslag av enheter. Jeg er usikker på hvordan det blir mer søk, ettersom et navn ikke trenger være unikt for ethvert objekt. Jeg tror jeg nesten må kunne gi et objekt en unik ID, og en hash av navnet som brukes ved triggers og lignende. En unik ID må kunne gis dersom objekter skal lese opp igjen fra en strøm, og det er referanser til objektet i andre objekter. Da skal ikke objektet serialiseres dobbelt opp (dette hindrer NodeReference klassen)

Eksempler på slike ting, kan være kamera-mål, hvor et mål er en del av et annet objekt. For eksempel:

 

Scene
 PerspectiveCamera->Target = "CameraTarget"
 Player
   CameraTarget("CameraTarget")

 

Dersom denne serialiseres uten referansene, så vil CameraTarget blir feilaktig serialisert to ganger. Én gang i PerspectiveCamera, og én gang som er sub-objekt til Player.

[GeirGrusom]

Har jobbet en del med X delen, men jeg er ikke kommet i mål enda. Grunnen til at den kræsjet i den gamle versojnen, var at glXGetVisualFromFBConfig ikke returnerte noe visual. Jeg vet rett og slett ikke hva jeg gjør feil, ettersom jeg så langt har gjort mer eller mindre akkurat det som står i tutorialene.

 

Utover det har jeg fikset serialiseringen nå, så i teorien skal scener la seg serialisere og deserialisere. Merk dog at det er én ting som ikke lar seg serialisere: funksjonspekere. Det er ikke umulig å ordne, men det er ikke noe jeg gidder å bruke tid på. Nå må en legge inn en NodeReference<T> i objektet. Denne vil la seg serialisere, og vil bli oppdatert automatisk når objektet blir serialisert (utvikleren skal ikke trenge å tenke på NodeReference<T> annet enn som en referanse til et objekt, serialisering er fullstendig automatisk)

 

Jeg har såvidt begynt på en Material klasse og en Light klasse, men dette er ikke høyt prioritert enda. Jeg hadde gjerne sett at jeg ble ferdig med X, men det ser litt mørkt ut...

 

Utover det, har jeg nå lagt inn RK4 for simuleringer, men det mangler for radial kraft.

[GeirGrusom]

D har jeg laget et resource system, der en velger resourcemanager.Import<Model>("minfil.model.obj") så skal den laste en ressurs, gi den en hash utifra navnet, og returnere den til funksjonen. Den teller for hver gang en ressurs blir bedt om, og når en ressurs blir satt ut av bruk (ved Dispose()) så dersom ingen bruker den, vil ressursen bli frigjort.

Det mangler veldig mye, og jeg har ikke testet så godt enda, men alt i alt er jeg fornøyd med hvordan dette går fremover. Jeg har nå fungerende kameraklasse, lys, teksturer, modell og for å importere slike ting. Scenegraphen lar seg serialisere uten videre. Det begynner å nærme seg slik at en faktisk kan bruke Glorg til å lage spill med. Det som mangler enda er:

- Lyd mangler fullstendig

- Flere filformater for objekter

- Flere filformater for teksturer, samt 1D, 3D og cubemaps

- Animasjoner

- Framebuffers

- Innebygget scripting støtte

[GeirGrusom]

Jeg har fikset en del synkroniseringsproblemer som førte til at noen programmer kunne gi en accesviolation. Grunnen var litt simpel, fordi ressurser forsøkte å frigjøre seg før scenen var frigjort. Problemet med dette, er at ressursene da fortsatt er i bruk, og kan ikke frigjøres. Rettelsen var rett og slett å få render-tråden til å frigjøre hele nodetreet også, ettersom det ikke er noe krav om at simuleringstråden må gjøre dette.

På en annen notis har jeg såvidt begynt på framebuffers og utvidet teksturklassene litt. Jeg er enda langt ifra ferdig med dette dog. Jeg jobber også med å få til en unproject funksjon, men jeg er usikker på om Matrix.Invert() funksjonen min er riktig. Det er også en liten bug der som får programmet til å kræsje dersom du prøver å bruke Unproject funksjonen før Rendering devicen er laget, og det er ingen deterministisk måte å vite når denne vil dukke opp på, ettersom det foregår i en egen tråd.

Jeg har også lagt til HitTest funksjon på nodene, som standard returnerer denne false. For å utvide denne, kan man bruke en av BoundingBox, BoundingSphere etc. for å sjekke mot linjenen som kommer inn. Det er også en funksjon for å hente alle objektene som treffer en linje, også en funksjon for å kun hente det nærmeste objektet.

[GeirGrusom]

Ville bare gjøre en kjapp oppdatering.

Jeg har fikset Quaternion nå. Det var ikke noe galt med selve klassen, men med hvordan jeg brukte den Jeg har nå lagt til to statiske metoder: FromEulerAngle og FromAxisAngle. Det er anbefalt å bruke sistnevnte, da denne er enklest i bruk.

 

Dersom du for eksempel skal rotere et objekt med musa, kan dette fåes til simpelt:

 

Vector2 dir = new Vector2(e.x - oldx, e.y - oldy); // Finn ut hvor mye musa har flyttet seg
float mag = dir.Length; // Dette blir vinkelen vi skal rotere med
dir /= mag; // Normaliser vektoren
node.Orientation = Quaternion.FromAxisAngle(mag / 128, new Vector3(dir.y, dir.x, 0)) * node.Orientation;
oldx = e.x; oldy = e.y;

[GeirGrusom]

Har nå fikset en litt alvorlig feil i Glorg: Kameraet funket ikke skikkelig. Feilen var at roteringen til et kamera, roterte scenen, ikke selve kameraet. Dette er fikset nå.

I tillegg har jeg lagt til at man kan sette Target på noder, som gjør at noder automatisk "ser på" andre noder.

Det er da også følgelig lagt til funksjoner for å lage LookAt matrise, og for å gjøre en matrise om til en Quaternion.

I tillegg har jeg lagt til Vector3.Cross, og Abs funksjoner for vektorer.

Jeg har også fikset slik at dersom en utfører Dispose() på en ressurs som ikke er behandlet av en resourcemanager, så ville ikke objektet bli disposet (en måtte kalle DoDispose()) dette er nå fikset.

 

Nå MÅ jeg se på feilen med lasting av .obj filer. jeg vet hva feilen er, og hvordan jeg skal fikse det, men det er så mye jobb at jeg blir litt apatisk. Problemet er at 3dsmax og lignende verktøyer bruker tre forskjellige arrays for posisjoner, normaler og teksturkoordinater. Dette blir lagret i .obj formatet med en indeks som peker til flere forskjellige vertexer. Dette må fikses ved at hver eneste unike "indeks" må legges i et nytt array, og en må danne vertex for hver unike index. Slit med andre ord.

[GeirGrusom]

Da har jeg ordnet støtte for obj. Merk dog at dette er laget for output fra 3d studio max, og er ikke testet for noen andre programmer. Problemet jeg støtte på var som sagt at den ga fra seg tre arrays: posisjoner, normaler og teksturkoordinater. Det er fikset slik nå at den genererer vertexer utifra hvordan de blir brukt i index bufferet. Det vil bli dobbeltlagrin av posisjoner, men det er forventet av OpenGL allikevel.

 

Nå mangler bare en material editor, så skal Glorg være i slik stand at det faktisk kan brukes. Jeg tenker da kikke så lett på å legge inn en svææært simpel fysikkmotor for rigid body. Jeg vil begynne med å implementere kun støtte for spherical collisions, siden dette er det enkleste og mest brukbare å implementere. Dette blir gjort simpelt ved at Scene for en egenskap som heter Physics eller noe slikt, hvor en setter inn en instans av en fysikkmotor implementasjon. Deretter skal alle objektene implementere et interace, som gjør at Glorg automatisk finner at objektene som blir satt inn er et fysikkobjekt, og fysikkmotoren får vite om den.

 

Deretter vurderer jeg enten å legge inn støtte for OpenCL, eller begynne med OpenAL. Jeg tenker å legge inn OpenCL fordi det er minst jobb for meg, og jeg vil bli langt fortere ferdig med et fungerende OpenCL API enn et fungerende lyd og musikk API.

 

Jeg har også lest en artikkel om 2D grafikk i OpenGL, og ble litt interessert. Jeg har lyst til å få inn et 2D API fordi det blir enklere å lage HUD etc. dersom det er mulig å tegne enkle vektorfigurer.

http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html

Denne artikkelen bruker stencil bufferet for dette, som av en eller annen grunn førte til at en ikke trengte å tesselere modellen. Et problem gjenstår, og det er tekstrendering. Planen er å muligens blande inn System.Drawing her, og rendre tekst til et bitmap. Det må isåfall bli små bilder, ettersom dette ikke er en veldig rask måte å rendre tekst på av flere grunner. Jeg er ikke så veldig interessert i å bruke glut, men det kan være at jeg ender opp med det.

[GeirGrusom]

Nå byttet jeg litt rundt på ResourceManager klassen. Jeg erstattet T LoadResource<T>(string) med følgende:

bool Load<T>(string, string, out T)
bool Load<T>(string, out T)

 

En kan nå skrive

if(!manager.Load("somemodel", out model))
 Console.WriteLine("Cannot load 'somemodel'");

Glorg vil nå først forsøke å laste med ModelMeshImporter, deretter Obj, og til sist 3ds. En kan bestemme mer ved å sette inn parameter nummer to som handleren til de forskjellige importerne.

Idéen senere er at den skal importere til et format, og cache i et mer foretrukket format slik at det tar kortere tid å laste neste gang. Grunnen er at .obj tar forholdsvis lang tid å laste, så den skal istedet bli cachet til en binærfil.

Endret 5. mai 2010 av GeirGrusom

[GeirGrusom]

Skal bare nevne at jeg har lagt inn støtte for .3ds filer nå også. Den genererer dog normaler selv, ettersom denne informasjonen ikke ligger med i .3ds filer, annet enn smoothing groups.

.3ds blir sist prioritert nettopp på grunn av dette. Importeren er ikke istand til å generere normalene slik som det var designet i filen, og derfor er .obj foretrykket ettersom denne gjør det mer eller mindre korrekt.

[GeirGrusom]

Nå har jeg nesten lagt inn støtte for materialer. Det funker relativt simpelt, og jeg skal forklare her:

En lager en .xml fil, med følgende struktur:

<Material>
 <VertexShader src="default.vs" />
 <GeometryShader src="pointsprite.gs" />
 <FragmentShader>
   // fragment shader code
 </FragmentShader>
 <Uniforms>
   <Uniform type="float" name="intensity" value="1.0" />
   <Uniform type="float4" name="position" />
   <Uniform type="float3" name="direction" value="{0, 1, 0}" />
   <Uniform type="texture2d" name="diffuse" value="default" />
 </Uniforms>
</Material>

Merk at value for teksturer er et filnavn.

[GeirGrusom]

Jeg gjorde nå en litt viktig endring. Tidligere så itererte rendering tråden igjennom scenen på samme måte som simulatoren. Nå derimot lagres alle objekter som settes inn i scenen i en egen lineær liste. Dette fører til at den unødvendige (for renderingtråden) trådstrukturen fører til raskere gjennomgang og mindre overhead, samt at det ikke lenger skal skje at insetting eller fjerning av objekter gir exception. Det skal heller ikke skje at renderingtråden kan vente relativt lenge på å få tilgang til objekter.

[GeirGrusom]

Min tester forteller meg at det er noe galt med interpoleringen som gjør at aksellerasjonen øker hele tiden, noe jeg skal se nærmere på. Foruten det, skal materials fungere nå, men teksturer forblir svarte av uante grunner. Det kan bli til at jeg legger inn støtte for pixel buffer object på teksturer, men foreløpig brukes en egen klasse for dette som ikke arver fra BufferObject.

[GeirGrusom]

Jeg har ryddet opp i OpenGL kallene, nå gjøres det ikke noe annet enn OpenGL 1.0, 1.1, 1.2, 1.4, 1.5, 2.0, 2.1 3.0, 3.1 og 3.2. Alle deprecated funksjoner fra OpenGL er fjernet, og kun de som ligger i gl3.h er lagt inn.

Det betyr også at hele fixed function saken er borte, og dermed fungerer ikke lys lenger. Dette er noe som vil bli løst senere med deferred shading eller noe i den duren.

Jeg funderer på om jeg skal bruke stencil shadows eller shadow maps. Med shadow maps bruker man mer minne, men en har mye større mulighet til å få et bedre resultat (som soft shadows) kanskje en blanding er optimalt, men først og fremst tror jeg at jeg må få til deferred shading uten skygger, så jeg kan frigi versjon 1 og faktisk prøve å få tak i utviklere.

 

edit: jeg tror jeg vet hvorfor teksturene ble svarte nå ^^ TEXTURE0 i OpenGL 3 er "ingen tekstur" siden tellinga starter på 1.

Endret 19. mai 2010 av GeirGrusom

[GeirGrusom]

Da har jeg fikset problem som ATI kort hadde, og jeg har ordnet slik at også kameraer vil oppføre seg som vanlige objekter (altså transformering)

Fysikk er nå lagt inn i en egen tråd, og dermed er også fysikkmulighetene som lå i Node flyttet til DynamicNode. Alle fysikkobjekter må implementere IPhysicsObject for å fungere.

 

Prøver å legge inn slik at ressurser blir lastet i en separat tråd, men det går ikke å lage to OpenGL 3.2 contexts av en eller annen grunn...

[GeirGrusom]

ATI Problemet: det viser seg at jeg må bruke glVertexBuffer, som er laget for at en skal slippe å kalle glAttribPointer så mange ganger, og etter OpenGL 3.0 er det ikke lenger lov å rendre noe uten at et Vertex buffer er aktivt (annet enn null) av en eller annen latterlig grunn. Dette er ikke AMD sin feil, dette er OpenGL spesifikt, og nVidia er bare mye rundere på det. Ulempen som jeg ble forklart på OpenGL.org er at glVertexBuffer vil faktisk kunne minke ytelsen av en eller annen grunn. Men dette er selvsagt driverspesifikt.

 

Jeg ser fordelen med glVertexBuffer, men at det er påkrevd synes jeg er litt tåpelig.

 

Jeg holder nå på å skrive GeoMipMap klasse, men foreløpig er det bare et vanlig terreng som bruke quadtree for å kunne rendre raskere. Dette kan testes i "Glorg testtråd"-en.

 

GlorgIDE:

Jeg har startet på en map/spill editor for glorg. Planene er at du kan bruke den til to ting: lage brett, eller hele spill. Foreløpig kan du bare seg deg rundt, og sette ut dynamicmesh, vanlig mesh, terreng etc.

[GeirGrusom]

Glorg 2 v.0.8 Beta

 

Jeg slipper nå første testversjonen. Dette for å kanskje skape et lite testmiljø. I denne posten skal jeg gå igjennom hvordan Glorg funksjoner, og jeg skal vise ting som er implementert, og ting som enda mangler.

 

Dersom en har vært borti XNA, kan glorg virke litt likt på noen områder, men idéen er at Glorg skal gjøre litt mer av jobben enn XNA gjør.

 

Grunnleggende

Glorg er multi-threaded, den bruker per nå 3 forskjellige tråder, disse er:

- Logikk (spill-logikk som AI etc.)

- Fysikk (foreløpig bare RK4 interpolering av aksellerasjon og hastighet)

- Rendering

 

Disse deler ikke objektområde. De har hver sin egen liste over objekter de jobber med. For å kommunisere med disse trådene bruke PhysicsInvoke, GraphicsInvoke og LogicInvoke som gir en funksjonspeker som tråden utfører ved første anledning.

 

Selve scenen er et tre hierarki. Dersom objekter ikke er IPhysicsObject (eller arver fra DynamicNode) så vil posisjon og rotasjon bli påvirket av foreldrenoden.

 

Merk at grafikk ikke lastes med en gang et objekt settes inn i scenen, den lastes ved første anledning. Det kan derfor hende at Logic tråden kan utføres på et objekt hvor grafikken enda ikke er lastet.

 

Game klassen

Dette er relativt likt som i XNA. Programmet må (bør) være en klasse som arver fra Glorg2.Game. Denne klassen utfører ting som tråding og synkronisering. Det er her scenen initialiseres. Dette gjøres ved å override Init funksjonen.

InitializeGraphics overrides dersom Game klassen har grafikkobjekter som må lastes. Dette er vanligvis ikke tilfelle, men det kommer an på utvikleren.

[Game].Scene er et felt som behandler selve scenen. Denne kan brukes til å lete etter objekter (med Linq eller hva du enn måtte ønske) og behandle grunnobjektet (ParentNode)

 

Scene.Node klassen

Node er et objekt i scenen. Alle objekter har en posisjon og en rotasjon, uansett om objektet er synlig eller ikke. Merk at noder er ikke synlig som standard, kun noder som arver IRenderable blir behandlet av rendering tråden, på samme måte er det kun objekter som arver fra IPhysicsObject som behandles av fysikktråden.

Mer at posisjon er en Vector4, og ar rotasjon er en Quaternion. En kan leke litt med objektene i GlorgIDE som ligger i kildekoden. Merk at alle vinkler som synes i GlorgIDE og andre componente editorer regner i grader ikke i radianer, Glorg internt bruker Radianer. Dette skal være påpekt i context hjelp.

 

Camera klassene

Det finnes foreløpig kun én kamera klasse: Scene.PerspectiveCamera. Denne tar FieldOfView som er vinkel i radianer (det er en tilsvarende for Grader som brukes av component editorer som GlorgIDE)

 

Generelt om noder

Noder skal være unike, det skal ikke finnes referanser til noder i scenen som ikke går igjennom NodeReference klassen. Derfor MÅ kameraet (Scene.Camera) være en node i scenen, og ikke bare en ny instans. Ellers vil ikke scenen kunne deserialiseres skikkelig.

 

Ressurser

Ressurser lastes med Scene.Resources.Load funksjonen. Denne tar to eller tre parameter: Ressursnavn (filnavn uten extension relativ til .exe fila), handler (valgfri, denne spesifiserer hvilken importer som skal brukes, dette antydes fra sammenheng og er derfor ikke nødvendig) og returverdi.

f.eks.

public Node MyNode : IRenderable
{
 [NonSerialized()]
 StdMaterial material;
 [NonSerialized()]
 Model mdl;
 public void InitializeGraphics()
 {
   if(!Owner.Resources.Load("default_mat", out material))
     Glorg2.Debugging.Debug.WriteLine("Error:Failed to load material 'default_mat'");
   if(!Owner.Resources.Load("my_model", out mdl))
     Glorg2.Debugging.Debug.WriteLine("Error:Failed to load model 'my_model'");
 }

 public override void DoDispose()
 {
   if(material != null)
     material.Dispose();
   if(mdl != null)
     mdl.Dispose();
 }
 (...)
}

 

I motsetning til vanlig .NET kan objekter i Glorg føre til minnelekasjer e.l. Det er derfor viktig å frigjøre objekter i DoDispose. Merk at objekter ikke blir frigjort før de ikke lenger er i bruk. Grunnen til at dette skjer, er at objektene det er snakk om er OpenGL objekter som må frigjøres, ellers sitter de og tar plass på skjermkortet ditt uten å være i bruk. Objekter kaller Dispose i destructoren deres, som fører til at du kan få feil i OpenGL kall dersom grafikkobjekter faller til destructor før Glorg har frigjort dem.

 

Tegning av grafikk

Merk at det ikke er noen Draw funksjon på Model klassen. Dette kan komme inn senere, men akkurat nå må dette gjøres manuelt.

OpenGLDevice har noen funksjoner som er viktig å vite litt om:

- SetActiveMaterial()

- SetVertexBuffer()

- SetIndexBuffer()

- Draw()

Dette er funksjonene som kreves for å tegne (SetIndexBuffer er valgfritt derimot)

Model klassen består av ett Vertex buffer, men mange indexbuffer og materials. For å rendre, må du sette VertexBufferet en gang, deretter iterere igjennom alle elemente i Parts, kalle SetIndexBuffer på elementets IndexBuffer, og kalle Draw med Triangles som parameter.

 

VertexBuffer og IndexBuffer

Glorg har en VertexBuffer klasse. Denne må konstrueres med en VertexBufferDescriptor som beskriver vertex formatet. Alle vertex format har en public static readonly egenskap som er en VertexBufferDescriptor. Du kan definere egne, men som oftest er dette unødvendig.

Bruk Allocate for å allokere antall elementer du ønsker. Det er ikke anbefalt å bruke Add funksjonen, ettersom dette fører til kopiering og flytting av elementer. Hvis du kan regne ut hvor mange punkter modellen må ha, regn ut det på forhånd og bruk Allocate.

Du kan sette hver enkelt vertex/index med indexeren til VertexBuffer/IndexBuffer:

 

vb[0] = new VertexPositionNormalTexCoord() {Normal = Vector3.Up};
ib[0] = 10;

 

Vær obs på at Glorg er fortsatt under konstruksjon, og det er ting som kan bli endret, fjernet og lagt til. Men hovedprinsippene vil ikke endre seg.

 

Kildekoden kan hentes fra:

Google Code

Mercurial:https://glorg2.googlecode.com/hg/

 

Det er anbefalt å laste ned kildekoden med Mercurial og legge til Glorg som et prosjekt i din Solution, ettersom det gjør at det er veldig enkelt å laste ned oppdatert kode når jeg gjør endringer.

 

For de som kun er litt interesserte, så er binærfilene her:GlorgIDE w Glorg.zip

 

Lykke til! Dersom du møter på merkelige feil eller har kommentarer, så er det bare å poste i kommentartråden eller sende meg en PM.

[GeirGrusom]

Jeg har laget GLorg IDE som sagt, men tenkte det kanskje kunne være mer interessant å kunne innlemme denne som en kontroll i Visual Studio istedet. Da får en VS som en programmeringsplattform som må være å anse som svært nyttig.