[Direct3D/C#] Gamedesign problemen

[Mischa_NL]

Na erg veel proberen, zoeken, toepassen, verbeteren etc, heb ik eindelijk een erg simpel direct3d programma.
Wat het doet op dit moment? Het initialized DirectX, en kan meshes toevoegen uit .X bestanden.
Verder ben ik nog niet!

Een aantal problemen waar ik nu tegenaan loop zijn moeilijk te vinden op google aangezien het vooral design-problemen zijn.

Probleem 1:
Objecten (meshes) die ik uit .X bestanden laad, nemen de positie van zichzelf zoals ze gedesigned zijn in 3dsmax over. Dit wil ik niet. Als ik in 3dsmax dit object op +10x zet en hem vervolgens inlaat in directX en draw, begint het opbject ook op +10x. Dit is niet wenselijk. Dat object moet gewoon op 0.0.0 gedrawd worden mits ik een transform.world doe.
Ik weet ook niet of dit nu een issue is die ik in 3dsmax op moet lossen, of bij het exporteren naar .X, of dat dit gewoon iets is wat je in DirectX kunt fixen.

Probleem 2:
Collision Detection. Ik kan op internet niks zinnigs vinden, over dit onderwerp, met duidelijke uitleg. Ik wil testen of 2 meshes elkaar raken. Echter hoe dit moet is me niet duidelijk. Ik kan een boundingbox genereren, en weet dus alle 'uitersten' van de mesh. Hoe kan ik dit het best aanpakken? ik lees dingen over raytracing? maar hoe wat en waar? Wei kan me helpen!?

Probleem 3:
Meshes lijken gekarteld te worden op bepaalde afstanden... Wat is de oplossing hiervoor.
Hieronder een voobeeld:


Er zullen me nog wel een aantal dingen te binnen schieten, maar 'first things first'.
Alvast heel erg bedankt.

[NMe]

Probleem 1: waarom maak je je model niet gewoon gecentreerd rond 0,0,0?
Probleem 2: [google=direct3d collision detection], eerste hit lijkt me al aardig duidelijk?

[Verwijderd]

Probleem 3:

DxDevice.SamplerState[0].MinFilter = TextureFilter.Anisotropic;
DxDevice.SamplerState[0].MagFilter = TextureFilter.Anisotropic;

[Mischa_NL]

-NMe- schreef op maandag 12 maart 2007 @ 14:20:
Probleem 1: waarom maak je je model niet gewoon gecentreerd rond 0,0,0?
Probleem 2: [google=direct3d collision detection], eerste hit lijkt me al aardig duidelijk?

Dat was inderdaad een oplossing die ik gevonden heb, in 3dsmax 0,0,0 als middelpunt van mijn model gebruiken. Maar het lijkt zo 'onhandig'. die link ga ik even doorlezen.

Verwijderd schreef op maandag 12 maart 2007 @ 14:26:
Probleem 3:

DxDevice.SamplerState[0].MinFilter = TextureFilter.Anisotropic;
DxDevice.SamplerState[0].MagFilter = TextureFilter.Anisotropic;

Dit krijg ik niet werkende. Het blijft 'gekartelt' als een model vanuit een hoek wordt bekeken. Ligt dit misschien aan de belichting? of het feit dat de models tegen elkaar aanzitten?

[ Voor 30% gewijzigd door Mischa_NL op 12-03-2007 14:39 ]

[Verwijderd]

wanneer 2 vlakken precies door elkaar heen lopen kan het idd kloppen dat directx niet weet welk vlak hij zichtbaar moet renderen. dit kan kartelig overkomen. maar aangezien jij aangeeft dat het enkel bij bepaalde hoeken is, vermoed ik eerder dat misschien z-buffering niet goed staat. dan lijkt het ook in bepaalde hoeken kartelig.

ik zit nu op me werk en ben ff kwijt hoe je ook alweer zbuffering goed aanzette. maar dat kan iemand anders hier vast wel vertellen.. of anders ff zoeken op google.

[.oisyn]

Mischa_NL schreef op maandag 12 maart 2007 @ 14:17:
Probleem 2:
Collision Detection. Ik kan op internet niks zinnigs vinden, over dit onderwerp, met duidelijke uitleg.

Je kunt niets zinnigs vinden, of je kunt niets zinnigs vinden met duidelijke uitleg? Want dat eerste is onzin, en het tweede is denk ik puur persoonlijk maar niet zo heel erg gek - het is niet zo'n heel erg triviaal onderwerp.

Om te kijken of twee kubussen elkaar snijden is echter vrij simpel met de separating axes test:
- voor elk vlak van box A, kijk of alle vertices van box B aan de buitenkant liggen
- voor elk vlak van box B, kijk of alle vertices van box A aan de buitenkant liggen
- voor elke combinatie van edges van A en B, bereken een vector die loodrecht op beide edges liggen (cross product), projecteer de boxes op die vector en kijk of ze overlappen.

Over dat kartel-probleem, ligt de nearplane wellicht te dicht bij de camera? Want hoe dichterbij, hoe (exponentieel!) meer resolutie je verliest achterin.

[ Voor 7% gewijzigd door .oisyn op 12-03-2007 15:06 ]

[Mischa_NL]

.oisyn schreef op maandag 12 maart 2007 @ 15:04:
[...]

Je kunt niets zinnigs vinden, of je kunt niets zinnigs vinden met duidelijke uitleg? Want dat eerste is onzin, en het tweede is denk ik puur persoonlijk maar niet zo heel erg gek - het is niet zo'n heel erg triviaal onderwerp.

Om te kijken of twee kubussen elkaar snijden is echter vrij simpel met de separating axes test:
- voor elk vlak van box A, kijk of alle vertices van box B aan de buitenkant liggen
- voor elk vlak van box B, kijk of alle vertices van box A aan de buitenkant liggen
- voor elke combinatie van edges van A en B, bereken een vector die loodrecht op beide edges liggen (cross product), projecteer de boxes op die vector en kijk of ze overlappen.

Over dat kartel-probleem, ligt de nearplane wellicht te dicht bij de camera? Want hoe dichterbij, hoe (exponentieel!) meer resolutie je verliest achterin.

Het is inderdaad het geval dat ik niks kan vinden wat mij duidelijk uitlegt, wat precies het slimste is kwa techniek, en hoe deze toe te passen. Ik ga verder googlen over Collision detection.

Over die nearplane... dit is mijn code. en als ik die van 0.3f naar 30f verander worden de kartels inderdaad kleiner. maar weg zijn ze niet.

Dit is mijn zeer uitgebreide camera functie .

C#:

device.Transform.View = Matrix.LookAtLH(new Vector3(100, 200, 52), new Vector3(100, 0, 78), new Vector3(0, 0, 1));
device.Transform.Projection = Matrix.PerspectiveFovLH((float)Math.PI / 4, (float)this.Width / (float)this.Height, 0.3f, 500f);

Voor zover ik weet zijn de nearplane en farplane het gebied dat getekend moet worden?
stel dat ik daar 50 en 100 van maak tekent hij alles van 50 tot 100.
nu staat mijn camera op 200 afstand, en begint hij te tekenen op 0.3f.
Moet ik de nearplane dichterbij de blokken laten beginnen? Zo ja, waarom krijg ik dan minder kartels? Ik snap het idee daarachter niet echt...

[.oisyn]

Om te bepalen welke pixels voor andere pixels liggen, gebruikt de hardware een z-buffer - voor elke pixel op het scherm bestaat er een corresponderende z-waarde in de z-buffer. Als je een nieuwe pixel tekent, dan kijkt hij of de z van de nieuwe pixel kleiner is dan de z in de z-buffer, en zo ja dan tekent hij de pixel en update hij de z-buffer.

De precisie van de waarden in de z-buffer is natuurlijk ook maar eindig, en met je near- en farplane verdeel je eigenlijk de z-waarden van de pixels over de beschikbare precisie van de waarden in de z-buffer. z=0 is meestal de nearplane, en z=1 is je farplane. Verder worden niet echt de z waarden gebruikt, maar 1/z waarden omdat die na de projectie lineair te interpoleren zijn. Als jij dus een near en far van resp. 1 en 100 hebt, dan schaalt het dus van 1/1=1 naar 1/100=0.01. Tussen de near en de far zit hier maar een verschil van 0.99. Echter, bij een hele kleine near, dus stel 0.01, dan is de waarde in je z-buffer 1/0.01=100. En van 100 naar 0.01 is een verschil van 99.99, een ruime factor 100 meer dan bij near=1.

Een near van 0.3 is ook heel erg dichtbij hoor. Het hangt natuurlijk een beetje af van hoe de rest van de wereld geschaald is, maar wij gebruiken momenteel een near van 16 en een far van 20.000. Je kunt verder ook het formaat van je z-buffer nog aanpassen. Ik weet niet hoe je dat nu initialiseert, maar dat zou best eens 16 bits kunnen zijn. Door dat op 24 te zetten, of een floating point formaat, heb je al een stuk meer precisie.

[Mischa_NL]

.oisyn schreef op maandag 12 maart 2007 @ 15:43:
Om te bepalen welke pixels voor andere pixels liggen, gebruikt de hardware een z-buffer - voor elke pixel op het scherm bestaat er een corresponderende z-waarde in de z-buffer. Als je een nieuwe pixel tekent, dan kijkt hij of de z van de nieuwe pixel kleiner is dan de z in de z-buffer, en zo ja dan tekent hij de pixel en update hij de z-buffer.

De precisie van de waarden in de z-buffer is natuurlijk ook maar eindig, en met je near- en farplane verdeel je eigenlijk de z-waarden van de pixels over de beschikbare precisie van de waarden in de z-buffer. z=0 is meestal de nearplane, en z=1 is je farplane. Verder worden niet echt de z waarden gebruikt, maar 1/z waarden omdat die na de projectie lineair te interpoleren zijn. Als jij dus een near en far van resp. 1 en 100 hebt, dan schaalt het dus van 1/1=1 naar 1/100=0.01. Tussen de near en de far zit hier maar een verschil van 0.99. Echter, bij een hele kleine near, dus stel 0.01, dan is de waarde in je z-buffer 1/0.01=100. En van 100 naar 0.01 is een verschil van 99.99, een ruime factor 100 meer dan bij near=1.

Een near van 0.3 is ook heel erg dichtbij hoor. Het hangt natuurlijk een beetje af van hoe de rest van de wereld geschaald is, maar wij gebruiken momenteel een near van 16 en een far van 20.000. Je kunt verder ook het formaat van je z-buffer nog aanpassen. Ik weet niet hoe je dat nu initialiseert, maar dat zou best eens 16 bits kunnen zijn. Door dat op 24 te zetten, of een floating point formaat, heb je al een stuk meer precisie.

Wauw, wat een uitleg.
Ik heb hem nu op 24 gezet en het is inderdaad al veel minder.
Daarnaast inderdaad, het schalen van je wereld... Wat is ideaal? Is het zo als je grote models hebdat dat je meer precisie hebt? een blok wat je op mijn scherm ziet is 10.1f op dit moment.

Ook typisch, als ik mijn camera, langzaam of snel, over de X move, heb ik geen kartels. Is dat 'gezichtsbedrog' of niet?

[ Voor 3% gewijzigd door Mischa_NL op 12-03-2007 16:49 ]

[Verwijderd]

Dat klinkt niet logisch. Maar voor de test, zet je nearplane eens zo ver mogelijk, en je far plane zo dichtbij mogelijk, zo dat ze ongeveer (met een kleine marge) de het model inklemmen? Je zou sowieso zolang je gekke dingen doet niet snel last mogen hebben van z-fighting. Ik ben er enerzijds niet echt van overtuigd dat dat het probleem daadwerkelijk is (maar ik durf anderzijds ook eigenlijk niet te twijfelen aan .oisyn's kennis en inzicht).

[Mischa_NL]

Zeer basic collision detection zit er inmiddels in. Boundingboxes die bewogen zijn worden getjekt op alle anders boxes. Dit moet ik nog verbeteren zodat hij alleen checkt op boxes on screen of zelfs alleen diegene binnen bereik.

Karteltjes zijn er nog steeds een beetje, zoals ik al zei, gedeeltelijk opgelost door depthbuffer op 24 te zetten.

Probleem 1, staat nog steeds... Is er in 3dsmax een manier om je model simpel te centreren rondom 0,0,0?

[.oisyn]

right-click op de move button en dan met de hand 0, 0, 0 invoeren?

Verwijderd schreef op maandag 12 maart 2007 @ 21:17:
Ik ben er enerzijds niet echt van overtuigd dat dat het probleem daadwerkelijk is (maar ik durf anderzijds ook eigenlijk niet te twijfelen aan .oisyn's kennis en inzicht).

Ik heb ook nooit beweerd dat dat het probleem moet zijn, dus het kan net zo goed iets anders zijn . Ik moet zeggen dat ik momenteel ook twijfel als ik nog eens goed naar de screenshot kijk. We hebben het toch over die box in het midden, met kartels aan de linker en rechterkant?



Dit lijkt idd niet door z-fighting oid. Hoe zit de mesh eigenlijk in elkaar? Is dat ook gewoon een kubus?

[Mischa_NL]

Het is een mesh met vraagtekens erop (de vraagtekens zijn dus ook echt 3d en geen textures!
Het gaat hierom:




Voor de rest kan ik niet echt een 'simpel' reken voorbeeld vinden om physics te maken om te springen...
Ik weet ongeveer hoe het werkt, maar zou iemand mij een simpel rekenvoorbeeld kunnen geven?
Met als waarden iets van: 40kg met een hoek van 45°. Ik weet niet of dit onder script request valt? zo ja: pseudocode mag ook...

[ Voor 3% gewijzigd door Mischa_NL op 13-03-2007 11:53 ]

[Verwijderd]

3D game design, collision detection, physics... nou vraag je nogal wat dingen.

Dit zijn onderwerpen die alles behalve simpel zijn, het kost veel mensen jaren om dit soort materie te leren (zelfs met een goede achtergrond) en dan nog blijft het ingewikkeld. Het is niet voor niets dat spellen jaren duren met relatief grote teams om voor elkaar te krijgen.

Als je echt interesse hebt in het onderwerp kun je erover denken om er een opleiding in te gaan volgen, ik geloof dat er een Nederland meerdere zijn. Ik zou wel een opleiding specifiek gericht op game design kiezen want met bijvoorbeeld een informatica opleiding krijg je relatief weinig wiskunde en weinig te doen met 3D game design (soms zelfs helemaal niets) waardoor je nog niet echt verder komt (maar het geeft wel een goede basis natuurlijk).

Ook zijn er heel veel boeken te krijgen over deze onderwerpen.

Daarnaast zijn bijvoorbeeld de Quake engines volledig open source, zelfs met een betrekkelijke basis kennis is het mogelijk met zulke engines een leuk spel te maken. Zelf een dergelijke engine bouwen is in je eentje haast niet te doen.

[.oisyn]

Verwijderd schreef op dinsdag 13 maart 2007 @ 12:02:
Het is niet voor niets dat spellen jaren duren met relatief grote teams om voor elkaar te krijgen.

De reden daarvoor is omdat het veel werk is, niet omdat het ingewikkeld is

Als je echt interesse hebt in het onderwerp kun je erover denken om er een opleiding in te gaan volgen, ik geloof dat er een Nederland meerdere zijn. Ik zou wel een opleiding specifiek gericht op game design kiezen want met bijvoorbeeld een informatica opleiding krijg je relatief weinig wiskunde en weinig te doen met 3D game design (soms zelfs helemaal niets) waardoor je nog niet echt verder komt (maar het geeft wel een goede basis natuurlijk).

"Gamedesign" betekent overigens het design van je game. Dus storyline, artwork, etc., en heeft niets te maken met het "design" van je programmacode. Als je een gamedesign opleiding doet dan leer je ook dat eerste, niet dat laatste. That said, ik heb het idee dat de TS hier meer is geïnteresseerd in het programmeer-aspect van de game, en als dat geval is ga dan alsjeblieft een gewone informatica opleiding doen, met keuzemogelijkheden voor computer graphics en wiskunde. Heb je veel meer aan dan die bestaande gamedesign opleidingen waar je totaal niet wordt opgeleid als goede programmeur (meer een manusje van alles, zoals -NMe- ook al zei eerder in deze draad).

Daarnaast zijn bijvoorbeeld de Quake engines volledig open source, zelfs met een betrekkelijke basis kennis is het mogelijk met zulke engines een leuk spel te maken. Zelf een dergelijke engine bouwen is in je eentje haast niet te doen.

De vraag is: wil je een spel maken, of wil je een engine maken? Als je ooit de gameindustrie in wil als programmeur kan ik je aanraden dat laatste te doen/proberen.

[Mischa_NL]

Ik wil niet eens specifiek een engine maken. Wat ik wel leuk vind is een beetje aanklooien met direct3d, ik vind dat het me nog aardig lukt ook. Zeer basic collision detection zit er al in... Boundingbox en vergelijken maar, nou is dat nog niet zo uitgebreid maar ik hoef ook geen crysis2 te schrijven met weet ik wat voor ingewikkelde technieken.
Waar ik nu mee bezig ben is (de basis van) Direct3D onder de knie krijgen, wennen aan coordinate system, en je code die je uit tutorialtjes pakt, doorgronden en daarna, uitbreiden. Ik snap nu de werking van Direct3D en hoe het ongeveer in elkaar steekt. Nu probeer wat zeer basic(!!) 'physics' toe te voegen.

Een voorbeeld omzetten naar c# is totaal geen probleem Ik snap alleen niet helemaal hoe ik uitreken hoe ik een traject bereken van krachten. Iemand links? voorbeelden? Ik google zelf ook door, maar heb vannacht al een uur zonder een voor mij 'begrijpbaar' voorbeeld te vinden, helaas.

[.oisyn]

Mischa_NL schreef op dinsdag 13 maart 2007 @ 11:53:
Het is een mesh met vraagtekens erop (de vraagtekens zijn dus ook echt 3d en geen textures!
Het gaat hierom:

[afbeelding]

Aha. Dit lijkt idd wel op z-buffer artifacts. Zie je die kartels ook nog enorm knipperen als je de camera beweegt ("z-fighting")?

Voor de rest kan ik niet echt een 'simpel' reken voorbeeld vinden om physics te maken om te springen...
Ik weet ongeveer hoe het werkt, maar zou iemand mij een simpel rekenvoorbeeld kunnen geven?
Met als waarden iets van: 40kg met een hoek van 45°. Ik weet niet of dit onder script request valt? zo ja: pseudocode mag ook...

Je denkt te moeilijk . Je moet het zien in termen van snelheid en acceleratie. Het is handig om de snelheid van een object op te slaan in een vector, in units per seconde. Elk frame kijk je hoeveel tijd (in seconden) er zat tussen de vorige en de huidige frame, dit is je frametime. Voor al je objecten tel je bij de snelheid frametime*zwaartekracht op. Daarna tel je bij de positie frametime*snelheid op. Zwaartekracht is hier gewoon een vector recht naar onderen met een bepaalde lengte, afhankelijk van hoe sterk je zwaartekracht is. Als je wilt springen, geef je je object gewoon een opwaartse snelheid. Na verloop van tijd komt ie automatisch weer naar beneden.

[Mischa_NL]

.oisyn schreef op dinsdag 13 maart 2007 @ 12:31:
[...]

Aha. Dit lijkt idd wel op z-buffer artifacts. Zie je die kartels ook nog enorm knipperen als je de camera beweegt ("z-fighting")?

Nee het lijkt zelfs minder te zijn als de camera beweegt...
Ik zal even wat code 'pasten'.

code:

//voor het aanmaken device, geen idee of dit met de ZBuffer te maken heeft
presentParams.AutoDepthStencilFormat = DepthFormat.D24X8;
presentParams.EnableAutoDepthStencil = true;          


//op moment van init van device settings zoals alphablending etc
device.RenderState.ZBufferEnable    = true;

//drawen van objecten
public void Draw_Object()
{
      device.Transform.World = Matrix.Translation(x,z,y);

      for (int i = 0; i < meshMaterials.Length; i++)
      {
            device.Material = meshMaterials[i];
            device.SetTexture(0, meshTextures[i]);
            meshh.DrawSubset(i);
      }
}

//eentje vergeten: voor beginscene
device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.Blue, 1.0F, 0);

[...]

Je denkt te moeilijk . Je moet het zien in termen van snelheid en acceleratie. Het is handig om de snelheid van een object op te slaan in een vector, in units per seconde. Elk frame kijk je hoeveel tijd (in seconden) er zat tussen de vorige en de huidige frame, dit is je frametime. Voor al je objecten tel je bij de snelheid frametime*zwaartekracht op. Daarna tel je bij de positie frametime*snelheid op. Zwaartekracht is hier gewoon een vector recht naar onderen met een bepaalde lengte, afhankelijk van hoe sterk je zwaartekracht is. Als je wilt springen, geef je je object gewoon een opwaartse snelheid. Na verloop van tijd komt ie automatisch weer naar beneden.

makes sense!!! ik denk dat ik het op die manier wel voor elkaar krijg ja...

[ Voor 5% gewijzigd door Mischa_NL op 13-03-2007 12:49 ]

[Verwijderd]

.oisyn schreef op dinsdag 13 maart 2007 @ 12:31:
Je denkt te moeilijk . Je moet het zien in termen van snelheid en acceleratie. Het is handig om de snelheid van een object op te slaan in een vector, in units per seconde. Elk frame kijk je hoeveel tijd (in seconden) er zat tussen de vorige en de huidige frame, dit is je frametime. Voor al je objecten tel je bij de snelheid frametime*zwaartekracht op. Daarna tel je bij de positie frametime*snelheid op. Zwaartekracht is hier gewoon een vector recht naar onderen met een bepaalde lengte, afhankelijk van hoe sterk je zwaartekracht is. Als je wilt springen, geef je je object gewoon een opwaartse snelheid. Na verloop van tijd komt ie automatisch weer naar beneden.

Nog een kleine aanvulling om misschien je inzicht wat te vergroten: dit receptje is niets anders dan numerieke integratie. Net als bij een gewone integraal (zoals op de middelbare) die je analytisch oplost neem je de integrand, evauleer je die functie, vermenigvuldig je hem met een kleine tijdstap (of wat je integratievariabele ook mag zijn) en hoop je dat op. Hoe hoger je aantal fps, hoe kleiner de tijdstap en hoe nauwkeuriger je benadering van de echte integraal.

[Mischa_NL]

Ik heb nu frustum culling geimplenteerd, en dat werkt perfect. Daarnaast de code flínk herschreven.

Nu ben ik benieuwd wat voor system er gebruikt wordt om een wereld te schalen.
Wordt er een soort metrisch systeem gebruikte of eigen eenheden?
Wat voor grootte kwa eenheden is dan gebruikelijk?

[Mischa_NL]

kick.

Help me .oisyn!!!

[DroogKloot]

Welke eenheden je aan je wereld- en object-representatie verbindt maakt in het geheel niet uit zolang het systeem consistent is, dwz. als je er voor zorgt dat een afstand van '10' die op de ene plek met 10 kilometer correspondeert dat op de andere ook doet (en niet met bv. 10 centimeter). Kortom, het is natte-vinger werk.

[.oisyn]

Klopt. Neem gewoon iets wat je handig vindt werken. Centimeters is een veelgebruikte maat. Zorg wel dat je hier van tevoren een goede keuze voor maakt waar je je goed bij voelt - het kan een ramp zijn om dat later aan te moeten passen (zeker als je gebruik maakt van een physics library - dat opnieuw moeten tweaken is een hel kan ik je vermelden)

[Mischa_NL]

.oisyn schreef op dinsdag 13 maart 2007 @ 12:31:
[...]

Aha. Dit lijkt idd wel op z-buffer artifacts. Zie je die kartels ook nog enorm knipperen als je de camera beweegt ("z-fighting")?


[...]

Je denkt te moeilijk . Je moet het zien in termen van snelheid en acceleratie. Het is handig om de snelheid van een object op te slaan in een vector, in units per seconde. Elk frame kijk je hoeveel tijd (in seconden) er zat tussen de vorige en de huidige frame, dit is je frametime. Voor al je objecten tel je bij de snelheid frametime*zwaartekracht op. Daarna tel je bij de positie frametime*snelheid op. Zwaartekracht is hier gewoon een vector recht naar onderen met een bepaalde lengte, afhankelijk van hoe sterk je zwaartekracht is. Als je wilt springen, geef je je object gewoon een opwaartse snelheid. Na verloop van tijd komt ie automatisch weer naar beneden.

KICK.

Ik ben nog steeds bezig met basic physics. Ik zit echter met een probleem. Hoe sla ik mijn velocity op?
Doe ik dit als een vectorpunt positie en een vectorpunt waar hij in 1 seconde naartoe beweegt? Of doe ik dit als een Vectorpunt positie en 2 polar-coordinate hoeken? of nog anders?
Ik kom er niet uit. Ingelezen en snap de materie, maar niet hoe ik dit moet opslaan.

[.oisyn]

een cartesische vector, dus een x- en een y-waarde. Dat is zeg maar de delta waarmee hij elke seconde beweegt. Dan doe je dus elke frame:

C#:

position.x += velocity.x * frameTime;
position.y += velocity.y * frameTime;

Handiger is natuurlijk gewoon een Vector struct met overloaded operators zodat je gewoon position += velocity * frameTime kunt doen

[Mischa_NL]

hehe! geweldig!! het werkt!!

Ik heb een physics class geschreven waarvan in iedere physicalobject instance een instance van aangemaakt. Deze manier: objects[object->physics]

Alleen het volgende probleem waar ik weer niet uitkom . Op het moment dat ik nu een collision maak zet ik mijn velocity op 0. Is dit kwa 'real-life' situatie ook? lijkt me niet? Hoe werkt dit in het echt?

Stel ik val van 10 meter, en kom op de grond... waarom val ik op deze grond en stop ik?

Als het zo doorgaat kan ik komende week wel een exetje plaatsen. Niet dat het dan iets nuttigs zal doen... maargoed... het is iets .

[ Voor 13% gewijzigd door Mischa_NL op 24-03-2007 01:02 ]

[Verwijderd]

http://www.gamasutra.com/...20118/vandenhuevel_01.htm

Een hele duidelijke tutorial over 2D/3D collision detection en bounce met cirkels en bollen.

[Thralas]

Mischa_NL schreef op zaterdag 24 maart 2007 @ 01:00:
Alleen het volgende probleem waar ik weer niet uitkom . Op het moment dat ik nu een collision maak zet ik mijn velocity op 0. Is dit kwa 'real-life' situatie ook? lijkt me niet? Hoe werkt dit in het echt?

Momentum (Impuls) is waar je naar op zoek bent.

[roy-t]

Waarom gebruik je eigenlijk de C# + Direct X Microsoft XNA Game Studio Express, volledige gratis en vol met tutorials over collision detection e.d. ook is het een handig programma om C# en Direct X samen te laten werken, en is het gratis (en bevat een optie om je game ook te compilen voor de Xbox360 ipv voor de pc)

Linkje: http://msdn2.microsoft.com/en-us/xna/aa937795.aspx

linke2 (extra tuts) http://learnxna.com/default.aspx

[Mischa_NL]

ja geen idee. ik wil zo veel mogelijk 'zelf' maken...
je kunt ook wel een engine van het net plukken of een game modden en zeggen dat je een game gemaakt hebt.
c++ en unmanaged ging me iets te ver dus ben ik zo begonnen.

even snel gezocht en het ziet er wel leuk uit, maar ga nu niet overschakelen. misschien bij mijn volgende project oid.

iig. ik zal die link eens bekijken.

[ Voor 112% gewijzigd door Mischa_NL op 24-03-2007 14:37 ]

[Mischa_NL]

Kwa collision response verzuip ik helaas in de informatie...
Heeft dit te maken met elastic en non-elastic collisions?

Verwijderd schreef op zaterdag 24 maart 2007 @ 02:25:
http://www.gamasutra.com/...20118/vandenhuevel_01.htm

Een hele duidelijke tutorial over 2D/3D collision detection en bounce met cirkels en bollen.

hier kan ik het gewoon mee .

[ Voor 56% gewijzigd door Mischa_NL op 26-03-2007 17:23 ]

[Verwijderd]

Probleem 1: Middelpunt bepalen van het model. Daarna alle punten transformeren naar nieuw middelpunt 0,0,0

[Mischa_NL]

Hier wordt ik dus pisnijdig van he.
Dat ik het niet snap of er neit uitkom.

ik heb verscheidene krachten:
zwaartekracht + misschien een extra kracht van een playerinput (laten we het een stuwkracht noemen: bv een motor die extra kracht naar beneden levert).
nu komt het tot een botsing.

wat nu?

ik kom er echt niet uit.
ik wil NIET de acceleration bepalen maar de IMPULS nodig om die acceleration te geven.

en aub geen sites ik google al 4 dagen en kom er niet uit. wie kan me helpen.

zwaartekracht en andere krachten werken gewoon, ik weet gewoon niet wat ik moet doen als ik bots.

ff uitgebreid:

krachten: 1000N Y, 100N X, -100NY
acceleratie/versnelling = krachten resultant(100N,1000-100N,0) / massa
snelheid+richting = oude snelheid + acceleratie*frametime
positie = posititievector + snelheidvector.

nu bots ik, wat doe ik nu met deze waarden? hoe bereken ik de nieuwe krachten?

acceleratie

[ Voor 30% gewijzigd door Mischa_NL op 28-03-2007 20:18 ]

[Mischa_NL]

kick

[Mischa_NL]

kick

[compufreak88]

Je zult een of andere waarde moeten definieren die bepaalt hoeveel van de energie weer teruggegeven wordt. Als je die hebt, dan vermenigvuldig je de krachten met die waarde, maar dan in tegenovergestelde richting oid (of iets met hoek van inval is hoek van terugkaatsing).

[Verwijderd]

het ligt er een beetje aan wat je wilt doen als hij botst... wil je dat hij afketst? of dat hij afremt? de ander wegstoot? etc.

als je wilt dat hij afketst is het het makkelijkste om bijvoorbeeld een bounding sphere om je mesh heen te leggen en dan de hoek berekenen van het raakvlak. vervolgens hem t.o.v. dat raakvlak afketsen. (hiervoor hoef je natuurlijk niet een sphere object te maken... die bounding sphere is ff voor je eigen gedachtengang. )

stel het raakvlak is 'vlak', dus alsof hij op de grond valt. en hij komt binnen met een hoek van (1/4 Pi,0,0) dan kets je hem af naar (3/4 Pi,0,0)

daar moet je dus even een mooie functie voor gaan ontwerpen (even de oude goniometrie en meetkunde boeken uit de kast halen)

[Verwijderd]

Voordeel daarvan is dat de radius van de bounding sphere door DirectX bij het inladen van de mesh automatisch berekend kan worden. Als je zelf aan het spelen bent ermee kan dat erg handig zijn.

[Mischa_NL]

Zo zo. tis weer een tijdje geleden.
ik zit nu lekker maar heb nog wat probleempjes.

Ik heb nu een nieuwe velocity berekend die ik op het moment van de collision erin beuk. echter lijkt me dit niet 'de' manier?
Hoe kan ik deze velocity omzetten naar een impuls die direct (deltatijd) het object laat afketsen oid?

C#:

        public void UpdateWorld()
        {
            for (int i=0;i<Objects.GetLength(0);i++) {      
                Objects[i].StorePosition( this);            
                Objects[i].UpdatePosition(this);
                Objects[i].collisiondetection.SaveCollisions(this,i);
            }
            
            for (int i=0;i<Objects.GetLength(0);i++) {
                foreach(Collision collision in Objects[i].collisiondetection.Collision) {
                
                    Objects[i].position = Objects[i].oldposition + Maths.AddVector(Objects[i].mmesh.bsphere.center, Objects[i].mmesh.bsphere.radius) - Maths.AddVector(collision.obj.mmesh.bsphere.center, collision.obj.mmesh.bsphere.radius);
                    Objects[i].velocity = Maths.DevideVector(Maths.MultiplyVector(collision.obj.oldvelocity,collision.obj.mass),Objects[i].mass);

                        
                }
                
                
                Objects[i].oldposition = Objects[i].position;
                Objects[i].collisiondetection.Collision.Clear();
                Objects[i].UpdateForces();
            }

        
        }

dat is mijn code nu maar wat in de foreach staat klopt natuurlijk niet... ik moet daar een force adden bij elke collision, maar ik weet niet hoe ik van V F kan maken. wie weet het wel ?

[.oisyn]

Ik snap niet helemaal wat je bedoelt, maar het is niet handig om een kracht te berekenen die door de molen wordt gegooid zodat je uiteindelijk weer een velocity krijgt. Je kunt beter gewoon direct de velocity instellen bij een botsing .

Overigens kun je geen kracht van snelheid uitrekenen - een constante snelheid is namelijk het resultaat van geen kracht. Krachten hebben te maken met acceleratie.

[Mischa_NL]

.oisyn schreef op zaterdag 07 april 2007 @ 00:46:
Ik snap niet helemaal wat je bedoelt, maar het is niet handig om een kracht te berekenen die door de molen wordt gegooid zodat je uiteindelijk weer een velocity krijgt. Je kunt beter gewoon direct de velocity instellen bij een botsing .

Overigens kun je geen kracht van snelheid uitrekenen - een constante snelheid is namelijk het resultaat van geen kracht. Krachten hebben te maken met acceleratie.

Aha dan is mijn code op deze manier in orde.
Nog wat tweaken en doen en dan moet dit in orde komen. Ookal krijg ik af en toe nog steeds dat objecten intersecten en dat mijn code het niet fixxed. Is als er veel objecten tegelijk colliden. dit komt dan omdat oldposition geen vrije plek meer is. maarja daar verzin ik wel iets op.
Dan even friction toevoegen en bounciness. Dit is niet zo gigantisch ingewikkeld denk ik.

Daarna moet ik angular velocity implenteren, iets wat wel iets lastiger is, aangezien ik gebruik maar van AABB's. wat is hier de oplossing voor? ik kan een object wel draaien, maar de AABB draait niet mee, en dus zal een object alleen op het scherm draaien en in het systeem (boundingbox) niet...
Ik heb er al even over zitten piekeren, misschien een OOB?

Ben vanavond ook ff aan pielen geweest met heightmaps, maar daar moet ik wat langer de tijd voor nemen dan een uurtje . Lijkt simpel maar is het, zoals bijna alles op gameprogramming gebied, niet...

Volgorde wordt zo een beetje dit:
Basic physics afmaken: friction, bounciness en angular velocity.
Basic terrain renderer: heightmaps, multitexturing, LOD, in zones opdelen, collision van objects, skydome.
Lightning en Shadow class. Ik wil graag dynamic softshadows maar of dit performancewijs haalbaar is weet ik niet, er is gelukkig genoeg begrijpbare code over te vinden.
Daarnaast wat special effects. (wolken, fog, dynamische zon, heel misschien iets van destuctable terrain maar geen idee of dat haalbaar is, ik betwijfel het )
heel wat dus, ik ben de komende maanden nog wel onder de pannen. Ik hoop dat terrain renderer wel wat vlotter gaat maar ik denk het wel, physics is gewoon lastig en veel 'overnemen' en 'zoeken'.
Agja. Ik loop te ver vooruit:
angular velocity, collision point op een aabb?

[farlane]

Mischa_NL schreef op vrijdag 06 april 2007 @ 22:56:
ik moet daar een force adden bij elke collision, maar ik weet niet hoe ik van V F kan maken. wie weet het wel ?

Bij een constante massa geldt:

code:

F = m . a = m . dv/dt

Dus zoals .oisyn al zei, een kracht zorgt voor een versnelling niet voor een snelheid.

Ik weet niet wat je precies bedoelt met aabb maar als je over botsende objecten hebt praat je als snel over impuls, impulsmoment en stoot.

Hier begint natuurkunde pas echt leuk te worden

[ Voor 20% gewijzigd door farlane op 07-04-2007 13:38 ]

[.oisyn]

farlane schreef op zaterdag 07 april 2007 @ 13:34:
Ik weet niet wat je precies bedoelt met aabb

axis aligned bounding box

[Mischa_NL]

en een OOB is een object oriented bounding box, om het maar even aan te vullen

[Mischa_NL]

Nieuw Probleem!
Ik wil van een vertex en indexbuffer een mesh maken, maar DirectX.Mesh vraagt om int's als nr of faces en nr of vertices.
echter als ik meer dan 64000 van die dingen heb, krijg ik logischerwijs een error...
het zal toch wel mogelijk zijn grote meshes te maken??

edit. wat raar? +/-64000 is niet een int maar een ushort? wtf. waarom kan ik geen grotere meshes maken?

[ Voor 16% gewijzigd door Mischa_NL op 09-04-2007 21:42 ]

[.oisyn]

Wat voor videokaart heb je? De oudere modellen ondersteunen alleen 16 bits indices.

[Mischa_NL]

.oisyn schreef op dinsdag 10 april 2007 @ 11:05:
Wat voor videokaart heb je? De oudere modellen ondersteunen alleen 16 bits indices.

geforce 4 matig kudtding. zou dat een probleem kunnen zijn ?

[.oisyn]

Wellicht . Ken de specs niet uit m'n hoofd ofzo . Heb je de DirectX Caps Viewer? Zit in de DX SDK

[Mischa_NL]

verdorie. wat is het toch ook een partij klotezooi he

caps.MaxVertexIndex geeft 65535 terug. Verdorie haha. is dit softwarematig op te lossen? Of zit er niks anders op dan kleinere meshes te gebruiken?

[Verwijderd]

je mesh gewoon in meerdere delen/meshes opsplitsen.

[ Voor 7% gewijzigd door Verwijderd op 10-04-2007 18:27 ]

[.oisyn]

Je kan ze natuurlijk ook gewoon in een preprocessing stap opdelen in stukjes. Sowieso gebruikt een beetje game niet die DirectX Mesh classes maar hebben gewoon hun eigen formaat.

[Mischa_NL]

Verwijderd schreef op dinsdag 10 april 2007 @ 18:26:
je mesh gewoon in meerdere delen/meshes opsplitsen.

okidokie. wel zuur dat directx daar geen oplossing voor bied.

[Mischa_NL]

Update met screen!
Ben nu bezig met heightmap import te verbeteren. heightmaps worden nu op moment van import opgesplitst in zones van grootte naar voorkeur.
Screen:

[Mischa_NL]

Ben ik weer!

Mijn terrein bestaat op dit moment nog uit vaste 'zones' van een bepaalde grootte.
Je kunt instellen hoe groot een zone moet zijn.

Het kloterige hieraan is echter, wat is je ideale grootte. het is zééér duidelijk dat bij kleine terrains (weinig vertices) de frustum culling enorm veel doet en de framerate zeer netjes houd.
wordt een terrein echter groter (en zoom je uit) dan moet je echter zoveel calls sturen naar drawprimitives dat het daardaar merkbaar trager wordt!
Ook zonder de culling is er een duidelijk performanceverschil. hoe groter het aantal prims wat je naar je drawprims stuurt hoe effectiever lijkt het. Dit zal onder andere komen doordat er meer indices gedrawt moeten worden natuurlijk. is dat het enige? is er meer?

Verder ga ik proberen 'Geometry Clipping' te implenteren. zal echter wel redelijk lastig worden.

[Woy]

Voor games wordt er volgens mij meestal voor gekozen om terein ( of andere objecten ) die op een grotere afstand zijn minder gedetaileerd te tekenen. Je kan dus voor het terein wat veraf ligt de primitive count een stuk terug brengen. Aangezien het verder weg is zal dit niet extreem op vallen.

[Mischa_NL]

Dat snap ik vandaar dat ik de term geometry clipmapping aanhaal.

Maar dat is een softwarematig probleem. wat ik bedoel is dat het lijkt dat er een verhouding is tussen preciezere culling wat zorgt voor hogere framerates niet altijd effectief werkt. hoe kleiner de zones hoe preciezer de culling. echter ook hoe kleiner de zones hoe meer calls naar drawprimitives.
het lijkt erop dat je het beste 256 * 256 zones in de buffers te stoppen en te laten tekenen dan bv zones van 32*32.

verder ben ik benieuwd hoe ik gedetailleerdere heightmaps kan maken. dat gaat denk ik alleen door de heightmaps groter te maken?
bv: heightmap van 1024 x 1024 de punten ipv op afstand 1 op afstand 0.1 zetten?
op deze manier krijg je wel enorme heightmaps lijkt me???
1024x1024 op 1 per meter 1024 km
echter wil je een precisie van 10 centimeten dan moet je al (1024*10)*(1024*10) hebben lijkt me?

[ Voor 29% gewijzigd door Mischa_NL op 21-04-2007 13:20 ]

[Woy]

Ik zou mijn heightmaps denk niet een vaste resolutie laten hebben. Je kan je resolutie op punten waar een groter verschil in hoogtes is dan een hogere resolutie laten hebben als een stuk waar je een vlak landschap hebt.

[Mischa_NL]

rwb schreef op zaterdag 21 april 2007 @ 13:53:
Ik zou mijn heightmaps denk niet een vaste resolutie laten hebben. Je kan je resolutie op punten waar een groter verschil in hoogtes is dan een hogere resolutie laten hebben als een stuk waar je een vlak landschap hebt.

Dat is niet echt wenselijk denk ik. het maken van LOD levels doe je normaal on the fly lijkt me. niet in een RAW/bmp heightmap. die geeft gewoon per pixel data. en dan lijkt me dat je dat doet op het hoogste LOD level (meeste detail).

Nu zit ik echter met een matig probleem haha. Kan ik met mijn matige Geforce 4 - 440mx SE wel gebruik maken van vertex/pixel shaders? ik begin onderhand te denken van niet?
Kan iemand me uit de brand helpen? Voglens mij is het een DX7 kaart?

Anders moet ik gaan upgraden en daar heb ik eigenlijk geen trek in haha.

[Verwijderd]

GetDeviceCaps

[Verwijderd]

En voor je terrein, een klassieker voor inspiratie: http://www.llnl.gov/graphics/ROAM/roam.pdf

[Mischa_NL]

Verwijderd schreef op zaterdag 21 april 2007 @ 22:11:
GetDeviceCaps

geeft shaderversion 0 en build -1 aan dus dat zegt denk ik genoeg .

Kwa roam, weleens doorgekeken ja! GeoClipmapping spreekt me meer aan doordat je alles via vertexshaders doet, je belast je cpu minimaal.

[Sponge]

Maar wel elke frame op de GPU, ipv dat je alles genereert en om de zoveel tijd de index/vertexbuffers update. Als je stilstaat hoeft er niets geudpate te worden als je de CPU versie hebt.

Voor mijn western maak ik overigens geen gebruik van LOD. Al mijn quad tree patches zijn grondig geoptimaliseerd, en daar laat ik het bij...

[.oisyn]

Mischa_NL schreef op vrijdag 20 april 2007 @ 23:47:
Ben ik weer!

Mijn terrein bestaat op dit moment nog uit vaste 'zones' van een bepaalde grootte.
Je kunt instellen hoe groot een zone moet zijn.

Het kloterige hieraan is echter, wat is je ideale grootte. het is zééér duidelijk dat bij kleine terrains (weinig vertices) de frustum culling enorm veel doet en de framerate zeer netjes houd.
wordt een terrein echter groter (en zoom je uit) dan moet je echter zoveel calls sturen naar drawprimitives dat het daardaar merkbaar trager wordt!
Ook zonder de culling is er een duidelijk performanceverschil. hoe groter het aantal prims wat je naar je drawprims stuurt hoe effectiever lijkt het. Dit zal onder andere komen doordat er meer indices gedrawt moeten worden natuurlijk. is dat het enige? is er meer?

Drawprim calls en statechanges zijn duur, daarom is het devies op de PC om zoveel mogelijk te batchen (de consoles hebben hier zo goed als geen last van, daarom kon de Xbox nog zo lang met de PC meekomen terwijl hij vrijwel identieke maar verouderde hardware bevatte). DirectX 10 brengt hier verandering in, maar daar heb je nu natuurlijk niets aan

Maak grote 'zones', zoals je die noemt (de veelgebruikte term daarvoor meer 'patch' ), van zeg 64k verts. Genereer een quadtree met een bepaalde diepte (even uitvogelen wat de beste cpu/gpu traidoff is) om je visibility mee te testen. Gebruik die visibility info om dynamische indexbuffers te maken - van alle subpatches die zichtbaar zijn kopieer je de indices in de indexbuffer. Daarna kun je in een keer het zichtbare deel van een patch tekenen door die dynamische indexbuffer te gebruiken.

[Mischa_NL]

Ben een beetje aant klooien met gui, en ik zit met een gedachtekronkel waar ik niet uitkom...
Is het mogelijk om rechtstreeks op screen/pixel coordinates te tekenen? ik bedoel: ik wil niet dat mijn gui een 3d object is, en gewoon altijd gerendert wordt. Of moet ik die dingen op z=0 tekenen om pixel-coords te hebben? maar dit gaat dan weer fout met mijn view frustum lijkt me?
Wat is de manier om dit te doen?

[Woy]

Ik weet het niet zeker, maar je kan toch bij je vertex format aangeven dat ze al getransformed zijn? Daar kan je dan toch een soort van bilboard objecten van maken?

Zitten er trouwens niet wat voorbeeldjes over de GUI in de DX sdk?

[Mischa_NL]

rwb schreef op zondag 29 april 2007 @ 16:35:
Ik weet het niet zeker, maar je kan toch bij je vertex format aangeven dat ze al getransformed zijn? Daar kan je dan toch een soort van bilboard objecten van maken?

Zitten er trouwens niet wat voorbeeldjes over de GUI in de DX sdk?

zitten erin, maar die maken gebruik van een wrapper waardoor de render code niet echt duidelijk is...

edit:
VertexFormat.Transformed werkt perfect. nu uitzoeken hoe ik moet gaan schalen. alles lijkt zo makkelijk maar is zo ingewikkeld.

ik heb het nu zo dat je windows aanmaakt zonder parent (dan is de parent het 'bureaublad' van directx) en met een parent. Op het moment dat je een child aanmaakt voegt hij bij de parent in een list de child toe. op het moment dat je een transform op een object doet gaat hij recursief alle childs ook mee moven. ik denk dat dit wel een goed systeem is.
Maar wat ook wel goed zou kunnen werken, is de coordinaten van een child relatief te laten zijn aan de parent. op deze manier hoef je de childs niet te transformen op het moment dat je de parent transformed.
Wat zou beter zijn? ik denk zelf het 2e, omdat het veel sneller zal zijn. echter heb je dan wel een probleem als je niet alles mee wil laten schalen op het moment van bv een resize.
Ik weet het niet, help me uit de brand .

[ Voor 51% gewijzigd door Mischa_NL op 30-04-2007 00:07 ]

[Mischa_NL]

keiharde kick .
Nieuwe kaart aangeschaft (7900 GT) die voldoet aan wat ik nodig heb. Jammer dat ik geen pci-e slots heb, dus tis een agp geworden. Pc wordt echt te oud...

Maargoed, screentje van huidige uiterlijk:


Ik wil graag mijn heightmap upscalen. Eindelijk de goede term gevonden!
Welk algoritme zou ik hiervoor kunnen gebruik? iets als bicubic filtering of iets?

[roy-t]

Ziet er al netjes uit, vooral ook omdat uit je posts blijkt dat er een geavanceerde ondergrond is. Ik lees je topic half mee voor ideeen over physics en performance enzo (zit zelf lekker met XNA icm C#, vind ik al low lvl genoeg ) en nu geef ik je even een gratis kickje.

[ Voor 12% gewijzigd door roy-t op 06-05-2007 18:33 ]

[Sponge]

Mischa_NL schreef op zaterdag 05 mei 2007 @ 18:43:
keiharde kick .
Nieuwe kaart aangeschaft (7900 GT) die voldoet aan wat ik nodig heb. Jammer dat ik geen pci-e slots heb, dus tis een agp geworden. Pc wordt echt te oud...

Maargoed, screentje van huidige uiterlijk:
[afbeelding]

Ik wil graag mijn heightmap upscalen. Eindelijk de goede term gevonden!
Welk algoritme zou ik hiervoor kunnen gebruik? iets als bicubic filtering of iets?

Wat bedoel je met upscalen? Verhogen? Verhoog je gewoon de hoogte waardes? Of, normaliseer je deze bijvoorbeeld eerst om ze daarna te vermenigvuldigen met de gewenste (max) hoogte.

Als het minder 'bobbelig' moet worden kan je er met een box filter overheen gaan van bijv 3x3 en alles middelen. Alleen bij de randjes moet je dan ff goed opletten

[.oisyn]

Mischa_NL schreef op zaterdag 05 mei 2007 @ 18:43:
Ik wil graag mijn heightmap upscalen. Eindelijk de goede term gevonden!
Welk algoritme zou ik hiervoor kunnen gebruik? iets als bicubic filtering of iets?

Ik gebruik daar zelf altijd een bicubic filter in de vorm van catmull-rom splines voor. Deze splines hebben (itt bijvoorbeeld beziers, hermites en nurbs) de erg handige eigenschap dat hij begint bij het 2e control point en eindigt bij het 3e, met dezelfde tangent vectors als de vorige en volgende splines. In other words, als je 5 control points hebt, C₁ t/m C₅, dan is de eerste spline { C₁, C₂, C₃, C₄ }, waarbij de spline door C₂ en C₃ gaat. De volgende is { C₂, C₃, C₄, C₅ }, waarbij hij door C₃ en C₄ gaat, en deze splines sluiten naadloos op elkaar aan.

Door steeds 4 opeenvolgende height samples in je heightmap als control points te nemen kun je er zo curves tussen definieren. Als je dit doet in de horizontale richting dan heb je in de verticale richting in essentie een array van splines. Als je van 4 (in verticale richting) opeenvolgende splines gaat samplen op een bepaald x-coordinaat, dan kun je daaruit vervolgens weer een verticale curve maken zodat je verder kunt interpoleren voor het y-coordinaat.

[Mischa_NL]

.oisyn schreef op maandag 07 mei 2007 @ 11:54:
[...]


Ik gebruik daar zelf altijd een bicubic filter in de vorm van catmull-rom splines voor. Deze splines hebben (itt bijvoorbeeld beziers, hermites en nurbs) de erg handige eigenschap dat hij begint bij het 2e control point en eindigt bij het 3e, met dezelfde tangent vectors als de vorige en volgende splines. In other words, als je 5 control points hebt, C₁ t/m C₅, dan is de eerste spline { C₁, C₂, C₃, C₄ }, waarbij de spline door C₂ en C₃ gaat. De volgende is { C₂, C₃, C₄, C₅ }, waarbij hij door C₃ en C₄ gaat, en deze splines sluiten naadloos op elkaar aan.

Door steeds 4 opeenvolgende height samples in je heightmap als control points te nemen kun je er zo curves tussen definieren. Als je dit doet in de horizontale richting dan heb je in de verticale richting in essentie een array van splines. Als je van 4 (in verticale richting) opeenvolgende splines gaat samplen op een bepaald x-coordinaat, dan kun je daaruit vervolgens weer een verticale curve maken zodat je verder kunt interpoleren voor het y-coordinaat.

Ik heb eens gezocht en dan dat bicubic filtering inderdaad een mooie oplossing is!
Nog een aantal dingetjes waar ik op het moment tegenaan loop:

Op het moment dat ik meer drawindexed primitives calls maak gaat de framerate gígantisch achteruit. Dit zijn dan batches van 256*256 verts.
Als ik ipv 1 patch 4 patches van die size draw dan gaat de fps van 180 naar 40... Dit zou toch niet moeten lijkt me? dat zijn 'slechts' 15.7 miljoen vertices per seconde! dat zou mijn kaart toch makkelijk aan moeten kunnen lijkt me. ook gebruik ik een redelijk kleine texture die ik niet per patch herhaal maar over alle patches heentrek (64*64 px). Ik bereken wel mijn schaduwen realtime op de gpu. de vertice normals worden vooraf opgeslagen en met het vertexbuffer meegestuurd. deze doet dan vervolgens een simpele dotproduct en normalize. lijkt me niet dat dit zó zwaar is.

Wie weet er waardoor dit komt?

Daarnaast ben ik aan het kijken geweest voor LOD algoritmes maar die gaan me eigenlijk mijn pet een beetje te boven, en daar meot ik gewoon weken instoppen om er een te implenteren. Daarom heb ik zelf wat dingetjes bedacht die enigsinds lijken op geoclipmapping, Maar nog niet genoeg over nagedacht om te implenteren.

Nu ben ik bezig met texturing van het terrain. en aangezien je verzuipt in de info over texturing heb ik zelf een 'ideetje'. Ik ben benieuwd wat jullie ervan vinden, en wat volgens jullie de pro's en con's zijn.

1. Door middel van de heightmap maak ik aan de hand van de hoogte een basis texture, bestaande uit kleuren + blend tussen die kleuren. Deze trek je over heel de mesh heen.
2. Over deze hele texture gooi ik een gedetailleerde noise map, of Detail texture (nog niet helemaal uit). Deze tile je over de mesh heen voor een wat onregelmatiger terrain.
3. Bovenop deze texture ga ik kijken naar de afstand. bv:
<=25 meter: zeer gedetailleerde texture
>25 - <=100 meter: minder maar nog steeds details
>100 - <=500 meter: weinig detail
>500 meter : zeer weinig detail, wellicht geen extra texture.

Of ik deze dan over elkaar gooi of per level 1 texture pak weet ik nog niet, ik denk het laatste.
Op deze manier krijg je dichtbij een zeer gedetailleerde omgeving en veraf een veel minder maar nog steeds acceptabel (door de afstand) level of detail. Om geen 'randen' te krijgen blend ik de levels uit 3 over in elkaar over een bepaalde afstand. bv: blenden van 20 tot 30 meter voor niveau 1 en van 90 tot 110 op niveau 2. enz.
De camera distance van het terrain is heel makkelijk op de gpu te bepalen dmv de distanc functie: distance(cam.pos * world matrix, renderpos * world matrix) .

Wat denken jullie van dit idee? En wat zijn volgens jullie de voor- en nadelen?

edit: Even snel gephotoshopped hoe ik het ongeveer in gedachte heb!

Lagen heb ik over elkaar gegooid:
Eerst de heightmap
Daarna de colormap (globale kleuren)
Vervolgens de noise map
Dan de eerste cirkel met gedetailleerde texture
En tot slot de 2e cirkel.

[ Voor 5% gewijzigd door Mischa_NL op 09-05-2007 16:22 ]

[Mischa_NL]

Heightmap + base texture + detail texture 100* x en 100* y getiled!



Ziet er al leuk uit, maar niet bepaald realistisch. Ik ga toepassen dat de detailtexture gebonden is aan de grondsoort en wat meer subtiele verschilletjes kwa dirt, gras, steen. verder op stijle wanden ook geen gras bv...

op- aanmerkingen?

[.oisyn]

Ja, bicubic filtering geeft per definitie mooi golvende heuveltjes. Wellicht wil je interpoleren tussen lineair geinterpoleerd + noise en bicubic geinterpoleerd, afhankelijk van je terrain type.

[riemerg]

mooi project, zeer informatieve thread. Eerste keer dat ik over de catmull-rom interpolatie hoor, en het lijkt iets te zijn dat ik meteen kan gebruiken.
Ik houd zelf een site met tutorials voor XNA/C# op www.riemers.net, met 2 reeksen over terrain, missch dat je er nog iets nuttigs op vindt.

Iig, ALS je eventueel bereid bent je code publiek te maken, zou ik ze zeer graag aanbieden op mijn site voor lezers met grotere honger. Dit is de eerste maal dat ik dit overweeg, maar het lijkt me dat jouw project perfect aansluit als mijn laatste reeks tutorials. Laat me maar weten indien je dit zou interesseren, mijn email is (riemer punt grootjans at gmail punt com).

[Mischa_NL]

riemerg schreef op dinsdag 15 mei 2007 @ 22:21:
mooi project, zeer informatieve thread. Eerste keer dat ik over de catmull-rom interpolatie hoor, en het lijkt iets te zijn dat ik meteen kan gebruiken.
Ik houd zelf een site met tutorials voor XNA/C# op www.riemers.net, met 2 reeksen over terrain, missch dat je er nog iets nuttigs op vindt.

Iig, ALS je eventueel bereid bent je code publiek te maken, zou ik ze zeer graag aanbieden op mijn site voor lezers met grotere honger. Dit is de eerste maal dat ik dit overweeg, maar het lijkt me dat jouw project perfect aansluit als mijn laatste reeks tutorials. Laat me maar weten indien je dit zou interesseren, mijn email is (riemer punt grootjans at gmail punt com).

Jij BÉNT riemer?
Je bent mijn held gek. ik volg je tuts!
Ik denk dat ik weinig kan bieden wat niet in je tuts staat aangezien ik het meeste daarvan afleid.
Maar ik zou zeeeker graag met je in contact komen gewoon omdat jou tuts. echt zo informatief zijn!
Echt de beste tut site over c# en mdx is riemers! ik kan je mijn source wel sturen, maar heel veel heb je er denk ik nog niet aan, ben wel een beetje aant denken aan wat dingen om te implementeren maar dat zijn slechts ideeen. Lijkt me wel tof om contact met je te houden!

[Sponge]

Je kan ook proberen "Texture splatting" toe te passen, waardoor het terrein een stuk interessanter wordt denk ik .

[.oisyn]

riemer: over je tuts, ik zie dat je met "culling" alleen backface culling bedoelt. Maar culling is veel generiekere term waarbij je elementen in je scene niet tekent. Visibility determination op een quadtree is ook een vorm van culling.

(Ik klikte natuurlijk op de culling tut omdat ik geinteresseerd was in wat jij had te melden over verschillende culling systemen aangezien dat mijn specialiteit is, maar tot mijn grote verbazing ging het slechts over het triviale backface culling )

[ Voor 3% gewijzigd door .oisyn op 16-05-2007 13:31 ]

[roy-t]

Ruis in je terrein zou het nog wat realistischer maken, ook een betere gras texture zou helpen, en zodadelijk plant je natuurlijk allemaal bomen en dergelijken, schaduw van bomen (en schaduw van wolken!) maakt het terein in 1 klap een stuk mooier!

Gaaf hoever je al bent btw (ik loop waaay achter, ik ben pas bij de fase: grid )

[Creepy]

Mischa_NL schreef op dinsdag 15 mei 2007 @ 23:51:
[...]
Lijkt me wel tof om contact met je te houden!

offtopic:
Even over dat contact: het zou jammer zijn als de discussie hier zich verplaatst naar een e-mail discussie tussen jou en riemer.

[Mischa_NL]

.oisyn schreef op woensdag 16 mei 2007 @ 13:30:
riemer: over je tuts, ik zie dat je met "culling" alleen backface culling bedoelt. Maar culling is veel generiekere term waarbij je elementen in je scene niet tekent. Visibility determination op een quadtree is ook een vorm van culling.

(Ik klikte natuurlijk op de culling tut omdat ik geinteresseerd was in wat jij had te melden over verschillende culling systemen aangezien dat mijn specialiteit is, maar tot mijn grote verbazing ging het slechts over het triviale backface culling )

Zie het commentaar op de volgende quote. Kort uitgelegd werkt mijn frustum culling zo:
je hebt 6 planes die de frustum bounds voorstellen (near, far, top, bottom, left, right) als een object bij alle 6 een true oplevert (>near, >far, <top, > bottom, <right, > left) zit hij erin. Op die manier kun je ook je intersections testen + waar de intersect is (waar is eigenlijk onbelangrijk).

therat10430 schreef op woensdag 16 mei 2007 @ 14:02:
Ruis in je terrein zou het nog wat realistischer maken, ook een betere gras texture zou helpen, en zodadelijk plant je natuurlijk allemaal bomen en dergelijken, schaduw van bomen (en schaduw van wolken!) maakt het terein in 1 klap een stuk mooier!

Gaaf hoever je al bent btw (ik loop waaay achter, ik ben pas bij de fase: grid )

Aah, maar wat ik nu heb is niet zó heel veel meer. Ik heb op het moment een grid + een in photoshop gemaakte base texture + een detailtexture. Daarnaast wat basis physics, eigen mesh class waar je aan de render method shaders kunt hangen met input waarden. Daarnaast heb ik ook frustum culling, maar dit werkt helaas niet optimaal hij cullt namelijk alleen volledige objecten. wat ideaal zou zijn is als hij een grid test en als deze een intersection detecteert in 4en zou spliten om vervolgens de grids die nog steeds intersecten weer door 4 deelt enzovoort.
Ik ben nu zelf met texturing aan het kijken hoe ik dit mooi krijg. Ruis in de vorm van noise zie ik vanaf aangezien dit niet echt realistisch is. ik wil echter wel dmv een noise alphamap wel een 2e detailtexture over de 1ste detailtexture heentrekken zodat je niet overal gras = gras hebt maar er niet overal even veel gras groeit maar ook plekken zijn maar steen is ipv grass, of klei... iets in die trent.
Daarnaast denk ik dat ik dmv een alphamap ook mijn detail textures laat faden om zo in de verte minder detail te tonen.

Creepy schreef op woensdag 16 mei 2007 @ 14:18:
[...]

offtopic:
Even over dat contact: het zou jammer zijn als de discussie hier zich verplaatst naar een e-mail discussie tussen jou en riemer.

Dat is ook niet de bedoeling!

[roy-t]

Achja ik ben vooral aan het spelen met Direct3d (via C#/xna dan) ene keer een hud de andere keer een grid met een goede camera, de volgende keer weer een spritebatch en allemaal in apparte projecten enzo.

(ik heb nu één redelijke engine waar ik wat mee zou kunnen doen, moet alleen nog even uitvogelen of ik textures over een grid kan trekken, misschien dat ik daar is mee verder ga, probleem is alleen ik heb geen doel )


Ik weet trouwens niet of je wel eens naar de Unreal Editor die bij Unreal 2 en UT2003/2004 zit hebt gekeken, ze gebruiken daar voor terrainrendering een soort van lagen van textures op de volgende manier

Eerst maak je een collectie van textures die je wilt gebruiken op je terrein, bijvoorbeeld, gras, zand, steen, klei.

Gras is bijvoorbeeld de top texture, daaronder zit zand dan steen etc.

Gras heeft een alphamap, waardoor op sommige plekken gras half doorzichtig is, en op veel plekken zelfs helemaal. Hierdoor kun je de texture eronder zien soms half er doorheen, soms volledig en scherp, en soms kijk je ook weer door de texture heen want deze heeft ook een eigen alphamap en zo kijk je weer naar de volgende texture.

Dit was een heel handige manier om 'redelijk makkelijk' (zoals ik het zie) een terrein te krijgen met mooie afwisselende textures.

De manier waarop je dit kon maken was trouwens lekker simpel in de editor, je voegde textures toe aan het terein en daarna selecteerde je de texture waarmee je wilde werken en met een soort van gum voegde je alpha toe of haalde je dit weg. (van 0 tot 100% opaque)

Misschien dat je dit principe in meer of mindere mate kunt toepassen (je kan natuurlijk de overlappende textures en bijbehorende alphamaps ook gewoon maken in PS, en dan later zien hoe deze eruit zien, want ik denk dat de editor hiervoor maken de lastigste stap is.

Succes ik ben benieuwd of en hoe je dit lukt!

[.oisyn]

Mischa_NL schreef op woensdag 16 mei 2007 @ 17:08:
[...]
Zie het commentaar op de volgende quote. Kort uitgelegd werkt mijn frustum culling zo:
je hebt 6 planes die de frustum bounds voorstellen (near, far, top, bottom, left, right) als een object bij alle 6 een true oplevert (>near, >far, <top, > bottom, <right, > left) zit hij erin. Op die manier kun je ook je intersections testen + waar de intersect is (waar is eigenlijk onbelangrijk).

Begrijp ik het nu goed dat je mij probeert uit te leggen hoe frustum culling werkt?

Bovendien klopt het niet. Je test nu of een object volledig binnen het frustum valt. Als hij er slechts gedeeltelijk binnen valt geeft jouw algoritme false, terwijl zo'n object dan wel alsnog zichtbaar is. Je moet het andersom doen - als een object zich volledig vóór een van de planes bevindt, dan is hij niet zichtbaar. De voorkant van een plane definieer ik als de buitenkant van het frustum (dus het frustum is eigenlijk de intersectie van alle achterste half-spaces van de 6 vlakken).

Echter heb je dan nog wel wat false positives

code:

.        F
      +------+
     L\      /R
       \  N /
   ooo  +--+
     ooo  
       ooo 
         ooo
           ooo

Het object, aangegeven door de o'tjes, snijdt zowel het vlak L (left plane) als N (near plane). Het bevindt zich dus niet geheel voor een van vlakken, en wordt daardoor bepaald als zichtbaar.

Dit kun je voor lief nemen, maar voor dure objecten wat rendering betreft zou je bijvoorbeeld extra planes op de hoeken kunnen plaatsen, of je stapt over op een SAT (Seperating Axis Test) - dan test je ook de planes van het object zelf (voor zover dat een polytoop is), en de crossproducts van elke paar van edges tussen het object en edges van je frustum. Deze test is 100% correct. Als je objecten bovendien altijd een AABB (axis aligned bounding box) hebben, kun je deze test enorm optimaliseren, en heb je met ong. 12 planetests een 100% correcte test.

Ik gebruik overigens geen frustums meer in onze engines, maar beam trees. Aangezien we de wereld hebben opgedeeld in cells (convex closed mesh), die onderling verbonden zijn door portals (convex polygons), en we bovendien occluders (convex polyhedrons) in de cells hebben staan, bouw ik een BSP tree om te kijken welke regionen er zichtbaar zijn, waar vervolgens de objecten (spheres of OBBs), lights (sphere, cone, cylinder) en terrain (AABB trees) tegen testen. Dit doe ik ook voor de lichten in de scene trouwens, om te bepalen welke objecten ze belichten en welke schaduwen getekend moeten worden.

[ Voor 19% gewijzigd door .oisyn op 16-05-2007 17:45 ]

[Mischa_NL]

.oisyn schreef op woensdag 16 mei 2007 @ 17:37:
[...]

Begrijp ik het nu goed dat je mij probeert uit te leggen hoe frustum culling werkt?

Bovendien klopt het niet. Je test nu of een object volledig binnen het frustum valt. Als hij er slechts gedeeltelijk binnen valt geeft jouw algoritme false, terwijl zo'n object dan wel alsnog zichtbaar is. Je moet het andersom doen - als een object zich volledig vóór een van de planes bevindt, dan is hij niet zichtbaar. De voorkant van een plane definieer ik als de buitenkant van het frustum (dus het frustum is eigenlijk de intersectie van alle achterste half-spaces van de 6 vlakken).

Echter heb je dan nog wel wat false positives

code:

.        F
      +------+
     L\      /R
       \  N /
   ooo  +--+
     ooo  
       ooo 
         ooo
           ooo

Het object, aangegeven door de o'tjes, snijdt zowel het vlak L (left plane) als N (near plane). Het bevindt zich dus niet geheel voor een van vlakken, en wordt daardoor bepaald als zichtbaar.

Dit kun je voor lief nemen, maar voor dure objecten wat rendering betreft zou je bijvoorbeeld extra planes op de hoeken kunnen plaatsen, of je stapt over op een SATtest - dan test je ook de planes van het object zelf (voor zover dat een polytoop is), en de crossproducts van elke paar van edges tussen het object en edges van je frustum. Deze test is 100% correct. Als je objecten bovendien altijd een AABB (axis aligned bounding box) hebben, kun je deze test enorm optimaliseren, en heb je met ong. 12 planetests een 100% correcte test.

Ik gebruik overigens geen frustums meer in onze engines, maar beam trees. Aangezien we de wereld hebben opgedeeld in cells, die onderling verbonden zijn door portals, en we bovendien occluders in de cells hebben staan, bouw ik een BSP tree om te kijken welke regionen er zichtbaar zijn, waar vervolgens de objecten (spheres of OBBs), lights (sphere, cone, cylinder) en terrain (AABB trees) tegen testen. Dit doe ik ook voor de lichten in de scene trouwens, om te bepalen welke objecten ze belichten en welke schaduwen getekend moeten worden.

Ik zal voor occlusion ook te kijken naar mogelijkheden, aangezien je een shadow map kunt maken op de gpu zou je natuurlijk ook een shadow map kunnen maken met je camerapoint als lightpoint. de schaduwplekken clip je vervolgens. Vraag me alleen af hoe dit kwa performance is. En of het uberhaubt werkt. Overigens test ik idd hetzelfde als jij zegt bij mijn frustum culling. ik kan ook een intersect afvangen. de uitleg was eigenlijk als algemeen bedoeld en niet specfiek voor iemand.

[roy-t]

Hey BSP's is dat niet ook hoe het in de Unreal Engine gedaan wordt? (ja sorry ik haal al mijn kennis uit de unreal engine, ik speel er al mee vanaf 1 en kan niet wachten op 3! (en een computer die 3 trekt )

[.oisyn]

Mischa_NL schreef op woensdag 16 mei 2007 @ 17:44:
[...]

Ik zal voor occlusion ook te kijken naar mogelijkheden, aangezien je een shadow map kunt maken op de gpu zou je natuurlijk ook een shadow map kunnen maken met je camerapoint als lightpoint. de schaduwplekken clip je vervolgens.

Klopt, maar dat is wel erg basic. Je tekent nog altijd veel teveel. De schaduw van iets wat belicht wordt door een bepaalde lichtbron hoeft natuurlijk nog niet zichtbaar te zijn op je scherm - dat hoef je niet naar je shadowbuffer te renderen. In eerste instantie test je natuurlijk of het licht wel 'zichtbaar' is (light volume intersect met view frustum), maar ook belangrijk is om het te belichten object te testen tegen het gebied waarvan je mogelijkerwijs de schaduw zou kunnen zien. Dit gebied is natuurlijk het viewfrustum zelf, maar ook alle punten in de ruimte waarvan de schaduw tov de lichtbron op het frustum valt. Oftewel, voor point en spotlights de convex hull van je frustum en de lichtbron, voor directional lights je viewfrustum geextrude in tegengestelde richting van de lichtstralen.

Samenvattend, een object moet naar de shadowbuffer van een light getekend worden als
- light-volume intersect met viewfrustum
- object intersect met light volume
- object intersect met shadow volume

Die laatste twee zou je kunnen combineren door de boolean intersection te maken van de light- en de shadowvolume, maar dat is computationeel lastig wegens de ronde vormen van de light volumes. Twee tests is dus handiger (hoewel ook hier weer wat false positives door geïntroduceerd worden).

[.oisyn]

therat10430 schreef op woensdag 16 mei 2007 @ 17:46:
Hey BSP's is dat niet ook hoe het in de Unreal Engine gedaan wordt? (ja sorry ik haal al mijn kennis uit de unreal engine, ik speel er al mee vanaf 1 en kan niet wachten op 3! (en een computer die 3 trekt )

BSP staat voor Binary Space Partitioning en is al in de jaren 50 uitgevonden . Het werd in Doom al gebruikt voor terrain modeling, visibility determination en collision detection (maar dan als 2d variant). De Unreal en Quake games gebruiken het ook, hoewel voor visibility determination in Quake een PVS werd uitgerekend aan de hand van de bsp data. Doom3 ging over op cells en portals, wat imho het beste werkt voor indoor en sommige outdoor omgevingen. Als je er occluders aan toevoegt (het systeem waar ik mee bezig ben voor onze upcoming games) is het ook wel geschikt voor outdoor.

UE3 bestaat toch al? Gears of War op de Xbox 360 maakt er geloof ik gebruik van.

[ Voor 4% gewijzigd door .oisyn op 16-05-2007 18:04 ]

[Mischa_NL]

.oisyn schreef op woensdag 16 mei 2007 @ 17:56:
[...]


Klopt, maar dat is wel erg basic. Je tekent nog altijd veel teveel. De schaduw van iets wat belicht wordt door een bepaalde lichtbron hoeft natuurlijk nog niet zichtbaar te zijn op je scherm - dat hoef je niet naar je shadowbuffer te renderen. In eerste instantie test je natuurlijk of het licht wel 'zichtbaar' is (light volume intersect met view frustum), maar ook belangrijk is om het te belichten object te testen tegen het gebied waarvan je mogelijkerwijs de schaduw zou kunnen zien. Dit gebied is natuurlijk het viewfrustum zelf, maar ook alle punten in de ruimte waarvan de schaduw tov de lichtbron op het frustum valt. Oftewel, voor point en spotlights de convex hull van je frustum en de lichtbron, voor directional lights je viewfrustum geextrude in tegengestelde richting van de lichtstralen.

Samenvattend, een object moet naar de shadowbuffer van een light getekend worden als
- light-volume intersect met viewfrustum
- object intersect met light volume
- object intersect met shadow volume

Die laatste twee zou je kunnen combineren door de boolean intersection te maken van de light- en de shadowvolume, maar dat is computationeel lastig wegens de ronde vormen van de light volumes. Twee tests is dus handiger (hoewel ook hier weer wat false positives door geïntroduceerd worden).

de schaduw vanuit het camerapunt als lichtpunt is toch per definitie onzichtbaar? (reflecties daargelaten)

[.oisyn]

Hoezo onzichtbaar? En wat bedoel je met camerapunt als lichtpunt (dat je de shadowmap rendert met de transformatie van de lichtbron wil nog niet zeggen dat daar ook echt je camera zit - wellicht zie je dat zo maar dat zorgt alleen maar voor verwarring )? Waar het om gaat is dat je de shadowmap projecteert op de omgeving - specifiek op die objecten die het licht raakt. Het zou weleens zo kunnen zijn dat de projectie van een object op de shadowmap zelf uiteindelijk nergens op geprojecteerd wordt, omdat er simpelweg niets zichtbaar is waar die projectie op zou kunnen vallen. In zo'n geval is het dus onzinnig om dat object naar de shadowmap te renderen - het draagt toch niet bij aan het resultaat (dit zijn dus schaduwen die buiten het beeld vallen)

[ Voor 84% gewijzigd door .oisyn op 16-05-2007 19:28 ]

[riemerg]

Mischa_NL schreef op dinsdag 15 mei 2007 @ 23:51:
[...]
Lijkt me wel tof om contact met je te houden!

Je hebt mn mail, maar ik heb natuurlijk geen tijd om alle vragen langs mails te beantwoorden. Hiervoor heb ik het forum, maar als het over iets algemeens gaat ben je altijd vrij om een mailtje te sturen

Creepy schreef op woensdag 16 mei 2007 @ 14:18:
[...]

offtopic:
Even over dat contact: het zou jammer zijn als de discussie hier zich verplaatst naar een e-mail discussie tussen jou en riemer.

Idd niet de bedoeling, en momenteel ook helemaal geen tijd voor

.oisyn schreef op woensdag 16 mei 2007 @ 13:30:
riemer: over je tuts, ik zie dat je met "culling" alleen backface culling bedoelt. Maar culling is veel generiekere term waarbij je elementen in je scene niet tekent. Visibility determination op een quadtree is ook een vorm van culling.

(Ik klikte natuurlijk op de culling tut omdat ik geinteresseerd was in wat jij had te melden over verschillende culling systemen aangezien dat mijn specialiteit is, maar tot mijn grote verbazing ging het slechts over het triviale backface culling )

Leuk dat je even keek! Voor de tuts op mijn site werk ik met reeksen in volgorde, en het culling chapter dat je bekeek was dan ook een van de eerste chapters van reeks 1 Voor het terrain van reeks 4 heb ik basis quadtree geimplementeerd, maar ik heb de laatste tijd echt te weinig tijd om die reeks af te maken.
Vooraleer ik me op mijn site waag aan een iets gedetailleerder cullling mechanisme, wil ik eerst een volledige 2D game maken, omdat ik denk dat daar globaal gezien meer mensen mee geholpen zijn.
Begrijp me niet verkeerd; culling mechanismes boeien me enorm en ik respecteer je kennis hierover. Culling is een domein waarover ik informatie kan blijven vergaren, en ik zou het dan ook apprecieren als je me een article/boek hierover op jouw niveau kan aanraden. Of uiteraard, het zou super zijn als je even de moeite zou willen doen om een mechanisme uit de doeken te doen in een articel op mn site?
Gezien je inzet op dit forum vermoed ik dat het algemeen geweten is, maar kan ik je even vragen hoe je aan al deze kennis hierover komt?

[roy-t]

.oisyn schreef op woensdag 16 mei 2007 @ 18:03:
[...]
UE3 bestaat toch al? Gears of War op de Xbox 360 maakt er geloof ik gebruik van.

Offtopic: tsja maar die is nog niet op de pc uit dus heb niet met de editor kunnen spelen, ik vind het super om met XNA te spelen, maar leveldesign is toch echt mijn passie, wachten op UT2k8 dus

Ontopic: Ben beniewd of Mischa wat vond van mijn terrein ideetje?

[Mischa_NL]

therat10430 schreef op woensdag 16 mei 2007 @ 17:16:
Achja ik ben vooral aan het spelen met Direct3d (via C#/xna dan) ene keer een hud de andere keer een grid met een goede camera, de volgende keer weer een spritebatch en allemaal in apparte projecten enzo.

(ik heb nu één redelijke engine waar ik wat mee zou kunnen doen, moet alleen nog even uitvogelen of ik textures over een grid kan trekken, misschien dat ik daar is mee verder ga, probleem is alleen ik heb geen doel )


Ik weet trouwens niet of je wel eens naar de Unreal Editor die bij Unreal 2 en UT2003/2004 zit hebt gekeken, ze gebruiken daar voor terrainrendering een soort van lagen van textures op de volgende manier

Eerst maak je een collectie van textures die je wilt gebruiken op je terrein, bijvoorbeeld, gras, zand, steen, klei.

Gras is bijvoorbeeld de top texture, daaronder zit zand dan steen etc.

Gras heeft een alphamap, waardoor op sommige plekken gras half doorzichtig is, en op veel plekken zelfs helemaal. Hierdoor kun je de texture eronder zien soms half er doorheen, soms volledig en scherp, en soms kijk je ook weer door de texture heen want deze heeft ook een eigen alphamap en zo kijk je weer naar de volgende texture.

Dit was een heel handige manier om 'redelijk makkelijk' (zoals ik het zie) een terrein te krijgen met mooie afwisselende textures.

De manier waarop je dit kon maken was trouwens lekker simpel in de editor, je voegde textures toe aan het terein en daarna selecteerde je de texture waarmee je wilde werken en met een soort van gum voegde je alpha toe of haalde je dit weg. (van 0 tot 100% opaque)

Misschien dat je dit principe in meer of mindere mate kunt toepassen (je kan natuurlijk de overlappende textures en bijbehorende alphamaps ook gewoon maken in PS, en dan later zien hoe deze eruit zien, want ik denk dat de editor hiervoor maken de lastigste stap is.

Succes ik ben benieuwd of en hoe je dit lukt!

Voor zover ik zag op wat reviews van de sandbox editor werkt far cry zo ook. De term hiervoor is texture splatting. Wat ik alleen niet weet is hoe ik dit in een editor zou moeten doen. ik denk dat ik de textures + waar welke texture moet komen het best 'hard' kan opslaan en in kan laden. lijkt me een voordeel tegenover real time berekenen: Het kan preciezer omdat je meer controle hebt bij het level editten + tis sneller. bij een editor zou je dan alsnog een algoritme kunnen verzinnen wat je land automatisch textured maar dat je het toch nog zou kunnen aanpassen.
Ik weet het niet...

[Mischa_NL]

Ik heb ervoor gezorgd dat uit een xml file mijn terrain textures gehaald worden.
1 base texture die geplaatst wordt zonder alpha map.
Vervolgens staan daarin de splat textures met alpha map.
Helaas ondersteund hlsl geen Texture array's... Waarom dit niet is weet ik niet, ik vind het knap irritant.
Wat zou een mooie oplossing hiervoor zijn?
De makkelijkste oplossing is gewoon 20 textures declareren en deze aan de hand van het aantal textures vullen.
Wat ik ook zou kunnen doen, maar wel ingewikkelder, is het gedeeltelijk 'genereren' van een effect file. ik genereer dan on the fly hoeveel splat textures er zijn en rag dat in mijn effect file alvorens hem in te laden.
Maar toch, dit gaat moeilijk worden op het moment dat ik een splat wil toevoegen voor bv ontploffingen.
Wat is de slimste oplossing?

Hier vast een screen van het zwaaar verbeterde terrain:

[roy-t]

Dat ziet er inderdaad een stuk beter uit, die mooie ronde heuveltjes doen me echt denken aan UT2k4 (wat wel een compliment is lijkt me )

[Mischa_NL]

Introducing phong shading!

Topview met instelling als glad object.

En hier een screen met een wat beter getweakte roughness. Doch kan het nog altijd beter, ik heb het er net inzitten.


Nu bumpmapping en normalmapping implementeren, en vervolgens toch een LOD algoritme in de kraag vatten.

Framrates liggen nu rond de 120. om de een of andere reden heb ik wel een soort 'schok' als ik niet fullscreen draai. Kan echter liggen aan de PresentationInterval = immediate. Blijkbaar moet je dit eigenlijk niet gebruiken als je niet full screen draait. Maar dat moet ik wel doen omdat ik anders de performance slecht kan checken.

[Verwijderd]

Ik volg dit topic al een tijdje, in combinatie met de tutorials van riemer, maar dit ziet er wel heel gelikt uit. We zijn voor ons Minor traject (software engineering) op school momenteel zelf bezig met ontwikkelen van een game, maar we gebruiken hier Irrlicht voor, ik denk dat we toch maar eens beter moeten gaan kijken naar puur Directx of een combinatie van deze twee

[Mischa_NL]

Verwijderd schreef op vrijdag 18 mei 2007 @ 18:06:
Ik volg dit topic al een tijdje, in combinatie met de tutorials van riemer, maar dit ziet er wel heel gelikt uit. We zijn voor ons Minor traject (software engineering) op school momenteel zelf bezig met ontwikkelen van een game, maar we gebruiken hier Irrlicht voor, ik denk dat we toch maar eens beter moeten gaan kijken naar puur Directx of een combinatie van deze twee

Eens even gekeken naar Irrlicht, en de dingen die daarin zitten heb ik gewoon nog lang niet. Special effects, skydome, bump/normal én parralex mapping, char. animation, multiple lights, advanced shadowing*...

*daar bedoel ik mee: shadow mapping zodat alle objecten shadows casten. Nu heb ik alleen selfshadowing dmv een simpele shaderfunctie.

Tegen de tijd dat ik een skydome, bump/normal/parralex mapping, multiple lights & advanced shadowing heb zijn we weer 2 maanden verder denk ik...

Verder heb ik geen tools om bv heightmaps te maken of alpha maps te tekenen op zicht. nu doe ik dat 100% in photoshop, en de resultaten zouden vandaar ook veel beter kúnnen zijn.

Leuk dat mensen dit topic volgen. Ik heb voordat ik het opende ook gezocht op GoT maar een echt Direct3D topic met wat ingewikkeldere vragen was niet bepaald te vinden. Zo heb je een hoop info centraal staan die je zéker tegenkomt op het moment dat je een huisgebrouwen game wilt schrijven.

Ik zat ook al te denken om er eens een tutorialtje aan te wagen, maar het probleem is dat ik niet weet of mijn oplossingen ook altijd de goede zijn. Ik vind overal flarden en implementeer die, of het de beste manier is: geen flauw idee.

[ Voor 18% gewijzigd door Mischa_NL op 18-05-2007 18:36 ]

[Verwijderd]

Kan heel goed kloppen, maar wij gebruiken een .NET port van Irrlicht, deze implementeerd nog (lang) niet alle functies van de native Irrlicht, daarom volg ik ernaast de verschillende tutorials en stappen die jij volgt om toch een betere 'grasp' te krijgen op wat er nu gebeurt:)

[roy-t]

Phong shading?

Dat tweede screenie ziet er echt heel vet uit, 120FPS is opzich netjes (op wat voor hardware, en draait het beter als je het voor de gein eens compiled?)

Verder zou ik nu niet nog veel meer effecten loslaten op je terrein, het ziet er al ontzettend gelikt uit, en anders houd je niet genoeg cpu/gpu-tijd over voor andere effecten en high-res models.

[Mischa_NL]

therat10430 schreef op zaterdag 19 mei 2007 @ 14:46:
Phong shading?

Dat tweede screenie ziet er echt heel vet uit, 120FPS is opzich netjes (op wat voor hardware, en draait het beter als je het voor de gein eens compiled?)

Verder zou ik nu niet nog veel meer effecten loslaten op je terrein, het ziet er al ontzettend gelikt uit, en anders houd je niet genoeg cpu/gpu-tijd over voor andere effecten en high-res models.

phong shading houd rekening met het camerapunt ten opzichte van de lichtbron(nen).
Ik ga een level of detail algoritme implementeren om te zorgen voor betere performance. Ik zit te denken aan geometric clipmapping aangezien dat gewoon wat mij betreft een erg vet LOD algoritme is.
Echter is dat allemaal ingewikkelde materie, maar zeker een must als je een beetje grotere terrains wilt. En ja het ziet er redelijk gelikt uit, dat vind ik zelf ook wel. Echter moet ik nu gewoon optimizen, en zorgen dat de rest van de models ook nog genoeg gpu power hebben, want nu is mijn shader gewoon te gpu intensief...

Ik vind het nu wel wat weg hebben van de halo 1 en 2 terrains. Die hebben ook dat nét niet realistische haha. Of dat nu matig is voor Bungie of oké voor mij daar oordeel ik niet over .

Verder is dat gecompiled. dat houd in: als release zonder foutopsporing gecompiled. het blijft een JIT programma (.net hè) maar voor zover ik lees moet dat niet zoveel uitmaken.
Verder heb ik nu een 1700mhz, 768mb ram en een nvidia 7600gt erin zitten. Zijn redelijk hoge specs om dit maar rond de 120fps (@ 800x600 windowed) te draaien. Vandaar dat er gewoon een LOD algoritme moet komen om de vertices flink te verminderen. Daarnaast moet ik mijn landscape ook als een trianglestrip ipv een trianglelist renderen. Maar als ik dat nu gelijk doe weet ik niet of ik in de knoop kom met mijn LOD vandaar dat ik dat nu nog niet heb!

[ Voor 19% gewijzigd door Mischa_NL op 20-05-2007 03:01 ]

[roy-t]

Mischa_NL schreef op zondag 20 mei 2007 @ 02:52:
[...]

Daarnaast moet ik mijn landscape ook als een trianglestrip ipv een trianglelist renderen. Maar als ik dat nu gelijk doe weet ik niet of ik in de knoop kom met mijn LOD vandaar dat ik dat nu nog niet heb!

Ik zou het eerst ombouwen naar een trianglestrip omdat dit meteen heel veel vertices scheelt, en waarschijnlijk heb je voor een LOD algoritme op de ts een redelijk andere aanpak nodig als voor de tl.

Ben benieuwd hoeveel fps je hebt met een trianglelist ik gok toch al zon 200fps

(neem trouwens aan dat die 1700mhz een core2tje is?)

[ Voor 4% gewijzigd door roy-t op 20-05-2007 17:12 ]