JLI Spieleprogrammierung

Chewie · Verfasst am: 19.02.2004, 16:40 Titel:

bei DrawPrimitive() geb ich ja genau an wieviele tris von wo im VB, drum denke ich auch, dass nur die übermittelt, transformiert und gerendert werden. bist du dir da sicher, dass immer der ganze vb transformiert wird?

Kampfhund:
aber darüber reden wir ja die ganze zeit! nur wie stückelst du jetzt eine seite eines tiles mit z.B. 20 verts an einen hochaufgelösten rand mit sagen wir 60 verts?...

Christian Rousselle · Verfasst am: 19.02.2004, 17:09 Titel:

Sicher bin ich mir nicht, ich habe aber auch noch nichts konkretes gefunden. Im Prinzip macht es natürlich keinen Sinn, denn gesamten VB zu transformieren, wenn man nur einen Teil braucht, aber ob das DX, der Treiber oder sonst was auch weiss ist die Frage. Wenn man Software Vertex Processing verwendet, dann wird immer der komplette Buffer transformiert...ich hoffe dass es bei HWVP nicht der Fall ist. Schlecht wäre auch, wenn es von der Grafikkarte/Treiber abhängt.

Selbst dann, bist du aber mit deinem 1025x1025 VB bei ca. 32 MB Daten - und hast auch noch 32-Bit Indices - hilft nicht viel weiter...

Christian

Chewie · Verfasst am: 19.02.2004, 17:25 Titel:

also ich hoffe mal, dass es nicht so ist.

ok, ob man jetzt den speicherbedarf bei einem outdoor level in kauf nehmen will, oder doch lieber die performance mit ständigem verändern der vertexdaten drückt, ist wohl geschmackssache.
aber wahrscheinlich ist so ein speicherbedarf schon reell, wie sollte man es sonst z.B. in einer indoor engine machen, wo ich einfach alle vertizen brauche?

edit:
eine idee zu den rändern hätt ich noch. man könnte sich für jedes tile mehrere 'rahmen' merken, die die verbindung vom rand zum tile enthalten. also sozusagen adapterrahmen, die von der maximalen auflösung auf eine beliebige umsetzen.
ist halt wieder die frage, ob sich das speichermäßig auszahlt.

Christian Rousselle · Verfasst am: 19.02.2004, 17:31 Titel:

Hmm, warum sollten die Indoor level größer sein? Ich denke, dass es eher umgekehrt ist. Die Q3-Level haben alle eher wenig Dreiecke. DOOM III, HL2 usw. werden mehr haben, aber das ist ja auch alles nicht mehr klassich Indoor, oder?

Kampfhund · Verfasst am: 19.02.2004, 17:40 Titel:

@Fallen:
Hast recht...ich hatte nicht alle seiten durchgelesen.

@Chewie:
Das könnte man doch berechnen...denke ich.

Optimierung allgemein:
Auf www.vterrain.org gibts sicher auch interessante Papers dazu.

Chewie · Verfasst am: 19.02.2004, 17:40 Titel:

ich denke einfach, wenn aktuelle spiele vorraussetzungen von 128mb haben, wird da schon ein großer teil für vertexdaten draufgehen...

hast du vielleicht ein paar gute links für outdoor/lod engines?

Christian Rousselle · Verfasst am: 19.02.2004, 17:46 Titel:

Den Link den Kampfhund gepostet hat, enthält alle interessanten Paper, die ich kenne. Wie immer, wenn es interessant wird, gibt es so gut wie keine Implementierung oder Tutorials im Netz, die funktionieren und mehr können, als dass, was ich habe (nicht das ich sagen will, dass es besonders toll ist, aber das meiste, was ich so finde ist Spielerei..64x64 Heightmap, eine Textur fürs Terrain usw.) Auf Gamedev gibt es noch einen interessanten Artikel (Geomorphing with the Vertex Shader), auf den hat sich FallenAngel auch schon bezogen.

Christian

Kampfhund · Verfasst am: 19.02.2004, 17:51 Titel:

ich weiß nicht ob es schon gesagt wurde:
könntes du nicht für den LOD level noch die "Flachheit" des terrains in betracht ziehen (falls es nicht schon drinn ist, im wireframe mode sah es jedenfalls nicht danach aus).

LeeDiGer · Verfasst am: 06.09.2004, 08:57 Titel:

Christian,
Ich hab mal das Beispielterrain aus dem 2. Buch angeschaut und hab gesehen, dass man die Einzelnen Tiles raussehen konnte. Die Texturen wurden nicht richtig platziert. Somit entstanden Nahtstellen. Und es war gar nicht möglich 1025x1025 Maps einzufügen (was sinnvoller als 1024x1024 wäre). Es würden Lücken entstehen, weil der Algorithmus von dir aus dem Buch es verbieten würde, Texturen mit ungerader Größe zu laden. Habs mittlerweile korrekt umgebaut und mit GeoMipmapping erweitert. Und noch viel wichtiger: Skalierung bei Bedarf.

Das neue Testterrain von dir sieht nicht schlecht aus. Aber das Terrain könntest du auch mal um einiges größer Skalieren. Nur wenn du ein Terrain einfügst, das die Höhen und Tiefen schnell wechselst, würd ichs dann so lassen.
Wie sieht das aus mit erstellen von Löchern (z.B. durch Bomben) zu laufzeit? Welche Algorithmen git es, um solche löcher zu berechnen?
_________________
Kein Rückzug! Kein Aufgeben!

Fallen · Verfasst am: 06.09.2004, 09:27 Titel:

Deformation der Landschaft:

1. Heightmap ändern/durch nen Falloff Algorithmus oder ner simplen Distance Berechnung alle Oberflächenpunkte innerhalb der Distanz verschieben (nach unten)

2. Boolsche Rechenoperationen die zum Beispiel Terrain - (Minus/Subtraktion) Kugel durchführen dabei wird vom terrain die Menge der Kugel abgezogen und zurück bleibt das terrain mit nem reingebrannten Loch in der Schnittmengenform der Kugel.

Beiepiele dafür habe ich im Web leider kaum welche gefunden Sad

Wegen der Texturgrösse, was macht das fürn unterschied wenn du nun die Textur um ein pixel breiter und ein pixel höher machst ?
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

LeeDiGer · Verfasst am: 07.09.2004, 08:47 Titel:

Ich meine damit, dass man die Heightmap in der Auflösung um einige Faktoren verringern kann und als Ausgleich entsprechend Skalieren und damit immer noch genug Details hat. schon allein, wenn man die Breite und Länge der Heightmap halbiert, wird die Map etwa 4mal so schnell gerendert.
_________________
Kein Rückzug! Kein Aufgeben!

LeeDiGer · Verfasst am: 09.09.2004, 01:10 Titel:

Gibts auch ein Tutorial für Octrees? Ist meiner Meinung nach eines der schwierigsten Kapitel für die Erstellung von Terrains.
_________________
Kein Rückzug! Kein Aufgeben!

Sören · Verfasst am: 09.09.2004, 20:51 Titel:

Octrees werden heutzutage für Terrainrendering nicht mehr oft benutzt, weil der Rechenaufwand in Relation zum Quadtree zu groß ist, sodass es meistens schneller ist am Quadtree zu cullen und halt die eine oder andere Primitive bruteforce zu rendern.

LeeDiGer · Verfasst am: 09.09.2004, 22:29 Titel:

Das man ein Terrain nur 2 dimensional betrachten braucht, hab ich mir auch überlegt. Wie man nen Quadtree anlegt, w+rd ich so noch hinkriegen. Nur gibt es folgendes wo ich noch ein paar antworten bräuchte:
Wird für eine Map nur 1 Vertexbuffer und Indexbuffer angelegt und die entsprechnde Triangleliste an die Childs weitergegeben? Wie funktioniert der Algorithmus, um Cracks zu beseitigen? Der reine ROAMalgorithmus ist mir klar.
_________________
Kein Rückzug! Kein Aufgeben!