Eine Frage des Terrains
Übersicht
BlitzBasic Blitz3D
|
Kernle 32DLLBetreff: Eine Frage des Terrains |
 Mo, Dez 17, 2007 14:59Antworten mit Zitat 
|
|---|---|---|
|
Hiho,
in diesem Thread geht es hauptsählich um die Frage ob ich für mein Spiel ein Terrain benutzen sollte, und wenn ja, welches sollte ich für die geschilderten Situationen nutzen ? (Blitz3D Terrain, oder selbstgemachtes). Nundenn, in meinem Spiel, das ich schon etwas länger programmiere (etwa 3 mal wieder neu angefangen), bin ich nun an der Wahl des Spielfelds angelangt. Vereinfacht gesagt geht es um Spielfiguren die sich über ein Spielfeld bewegen. Das Spielfeld ist in mehrere Felder unterteilt, von denen jedes einen "Typ" haben kann, z.b. Meer, Lava, etc. Die erste Frage muss man nicht aus der Teschnischen, sondern aus der Spielerischen Sicht sehen. Macht es Sinn, für eine solche Art von Spiel ein Terrain zu nehmen, oder reicht hier eine Flache Fläche ? Technisch gesehen bereitet mir jede mir erdenkliche Art des Spielfelds Kopfschmerzen. Benutze ich das B3D-Terrain... a) ...muss ich Abstriche in der Vielfalt des Terrains machen (Ränder) b) ...muss das Terrain aus einer Textur bestehen, was unmöglich ist (Ein Spielfeld besteht aus 16x16 Felder, und die Textur für ein Feld ist Variablen 64 oder 128. Somit währe diese eine Textur dann 1024 oder 2048 Pixeln... das schafft keine Grafikkarte, vor allem keine ältere) Benutze ich ein eigenes Terrain (1 Mesh)... a) ...muss ich auf B3Ds LOD verzichten b) ...muss das Terrain aus einer Textur bestehen... Benutze ich ein eigenes Terrain (jedes Feld ein Mesh)... a) ...muss ich auf B3Ds LOD verzichten b) ...habe ich einen enormen Geschwindigkeitsverlust (CPU + Speicher) Benutze ich ein einfaches Plattes Spielfeld (2 Triangles)... a) ...muss das Terrain aus einer Textur bestehen... Irgentwie sitze ich mit meinem Gedankengang fest... Hat einer eine Idee ? Hier noch ein paar Bilder zum veranschaulichen meiner bisherigen Tests... Selbstgebautes Terrain (1 Mesh) [Screen 1] [Screen 2] Jedes Feld ein Mesh [Screen 1] Grüßle: Kernle |
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
DreamoraBetreff: Re: Eine Frage des Terrains |
Mo, Dez 17, 2007 15:06 Antworten mit Zitat
|
|
|---|---|---|
|
Kernle 32DLL hat Folgendes geschrieben: Benutze ich das B3D-Terrain... a) ...muss ich Abstriche in der Vielfalt des Terrains machen (Ränder) b) ...muss das Terrain aus einer Textur bestehen, was unmöglich ist (Ein Spielfeld besteht aus 16x16 Felder, und die Textur für ein Feld ist Variablen 64 oder 128. Somit währe diese eine Textur dann 1024 oder 2048 Pixeln... das schafft keine Grafikkarte, vor allem keine ältere) a) Das musst du immer, die Welt ist immer irgendwo fertig solange du nicht das "Matrix" System von DBP kopierst (dafür hats nen source im codearchiv). Simpel gesprochen ist so eine Matrix nix anders als ein 64x64 Grid das dynamisch aktualisiert wird. b) Mindestens 2 fehler hier: b.1) 1024 und 2048 sind kein Problem, nicht Mal auf Radeon 9000 und Geforce 4. Speziell fehlt mir da in deiner Aufzählung die Detail Texture b.2) Gibt es dafür hinaus die Möglichkeit mit Multitexturing und Alphamask mit den BlitzTerrains etwas ähnliches zu machen wie mit den Mesh Terrains. Kernle 32DLL hat Folgendes geschrieben: Benutze ich ein eigenes Terrain (1 Mesh)... a) ...muss ich auf B3Ds LOD verzichten b) ...muss das Terrain aus einer Textur bestehen... Wohl wahr Kernle 32DLL hat Folgendes geschrieben: Benutze ich ein eigenes Terrain (jedes Feld ein Mesh)... a) ...muss ich auf B3Ds LOD verzichten b) ...habe ich einen enormen Geschwindigkeitsverlust (CPU + Speicher) Mieser Ansatz. Der sinnvollste Ansatz ist der "Chunk" Ansatz, den auch T.ED und andere Editoren nutzen. Dabei hat man mehrere Meshes a 32x32 oder 64x64 Quads. Dies bringt mehrere Vorteile mit: a) Man kann Geomipmapping nutzen (precalculated LoD) b) Senkt es die Grafikkarten belastung und man kann sogar die Texturen der einzelnen Chunks "baken" und sie einzeln texturieren. Senkt die belastung für die GPU immens speziell auf bandbreitenschwächeren Karten Kernle 32DLL hat Folgendes geschrieben: Benutze ich ein einfaches Plattes Spielfeld (2 Triangles)... a) ...muss das Terrain aus einer Textur bestehen... Der Ansatz taugt bestens wenn man niemals auch nur im Ansatz nahe ran kommt oder man es aus prinzip nur von +- gerade oben sieht. Eine weitere mächtige Variante fehlt komischerweise total, nämlich mehrere Blitz3D terrains so chunken. Via Hideentity kannst du ihr "soll ich lod updaten oder net" steuern |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
- Zuletzt bearbeitet von Dreamora am Mo, Dez 17, 2007 15:12, insgesamt einmal bearbeitet
|
Foppele |
Mo, Dez 17, 2007 15:06 Antworten mit Zitat
|
|---|---|---|
| Warum kannst du nicht die "jedes Feld ein Mesh" Methode benutzen und die ausserhalb des Sichtfeldes ausblenden bzw. durch eine Low Detail Version ersetzen? | ||
|
hecticSieger des IS Talentwettbewerb 2006 |
Mo, Dez 17, 2007 16:55 Antworten mit Zitat
|
|---|---|---|
| Hi Foppele, ich habe erst kürzlich einen Meshterrain -Code irgendwo gepostet. Dieser erstellt (wie Dreamora schon oben erwähnte) ganz automatisch Meshblöcke von je (kann man selbst angeben) gleicher Kantenlänge (z.B. 32x32 Quads). Da man also alles selbst macht, hat man auch volle Kontrolle über die Vertices, was bedeutet dass man mit wenigen Codezeilenerweiterung solche Würfel als Singlesurface innerhalb eines Blocks erstellen könnte. Jeder dieser Blöcke kann dann z.B. per EntityAutoFade nach einer bestimmten Entfernung automatisch ausgeblendet werden. Vielleicht kannst du ja was damit anfangen. | ||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
|
|
Kernle 32DLLBetreff: Re: Eine Frage des Terrains |
Di, Dez 18, 2007 0:56 Antworten mit Zitat
|
|---|---|---|
|
Dreamora hat Folgendes geschrieben: [...]b.2) Gibt es dafür hinaus die Möglichkeit mit Multitexturing und Alphamask mit den BlitzTerrains etwas ähnliches zu machen wie mit den Mesh Terrains.[...]
interessant, werde ich mal nach schauen Dreamora hat Folgendes geschrieben: [...]Der sinnvollste Ansatz ist der "Chunk" Ansatz, den auch T.ED und andere Editoren nutzen. Dabei hat man mehrere Meshes a 32x32 oder 64x64 Quads.
Dies bringt mehrere Vorteile mit: a) Man kann Geomipmapping nutzen (precalculated LoD) b) Senkt es die Grafikkarten belastung und man kann sogar die Texturen der einzelnen Chunks "baken" und sie einzeln texturieren. Senkt die belastung für die GPU immens speziell auf bandbreitenschwächeren Karten Ich denke eigentlich das dass genau mein Ansatz ist. Jedes "feld" (64x64 btw) ist ein Typefeld was neben Informationen auch das Mesh hält... wenn das nicht das ist was du meinst 8was ich irgentwie vermute ^^) werde ich nochmal die Forensuche anschmeißen 
Generell meine ich mal (ich glaube sogar von dir) gelesen zu haben das zuviele Surfaces schlecht sind (was mit vielen einzelnen Meshes wohl unweigerlich die Folge ist oder ?). Wenn ich mich recht entsinne ging es um das problem, das jemand eine .x Datei mit zuviel Daten in B3D laden wollte, was nicht ging... Aynway, ich denke viel Surfaces = weniger Rechenleistung ? Oder habe ich das falsch interpretiert ?  Sorry, in der echten 3D-Rechen Thematik hinter B3D kenne ich mich nicht so gut aus (ok, der Begriff Matrix ist mir auch schon außerhalb des gleichnamigen Films begenet nämlich bei dem gescheiterten versuch mich in C++ einzuarbeiten...)
@hectic: Danach werd ich deffinitiv auch mal schauen |
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
Dreamora |
Di, Dez 18, 2007 1:19 Antworten mit Zitat
|
|
|---|---|---|
|
Viele Surfaces -> Bandbreitenschwache Grafikkarte kolabiert und du hast 0 FPS
Aber das Problem damals war das der User 0 plan hatte mit Meshes. Wenn du ein B3D Mesh hast das mehrere MB hat dann kann ich garantieren das es NICHT geht. Das liegt daran, dass eine einzelne Entity (egal wieviele surfaces) nur 65536 vertices und triangles haben kann. willst du mehr musst du childs machen oder etwas wie einen quad / oct tree mit meshes |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Di, Dez 18, 2007 1:22 Antworten mit Zitat
|
|---|---|---|
|
Ja, zu viele Surfaces ist nicht gut, da jedes Surface eine Extrabehandlung benötigt, was auch Zeit kostet. Zu große Surfaces wiederrum ergeben, dass wenn auch nur ein Triangle im Sichtbereich der Kamera liegt, das ganze Mesh gerendert/berechnet wird. Bei Meshterrains ist also das beste Gleichgewicht zwischen 32x32 und 64x64 Quads. Da andere Zahlen (ausser 32^2 und 64^2) zu anderen Problemen führen, so wird halt das eine oder das andere gewählt.
Bei meinem letzten Post meinte ich natürlich @Kernle 32DLL nicht @Foppele, muss ich wohl durcheinander gekommen sein. |
||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
|
|
Kernle 32DLL |
Di, Dez 18, 2007 15:39 Antworten mit Zitat
|
|---|---|---|
|
hmm, ich verweise nochmal auf [dieses] Bild. Das ist ein 100x100 Spielfeld oder so... weis ich nicht mehr so genau. Jedes "Feld" besteht aus einem eigenen Mesh mit Surface, etc.
Die Frage ist nun, wenn ich bei solchen Riesigen Spielfeldern (die zwar nicht im Spiel vorkommen werden, aber einfach aus Verständnissgründen) für jedes Feld ein Mesh+Surface nehme, ist das dann eine gute Lösung ? Oder gibt es da bessere Wege ? Ich habe mir schon gedacht evt. alle Feldtexturen in eine zu packen. Das Spielfeld besteht dann aus einem Mesh, dessen Vertices die "große" Textur benutzen (vereinfacht gesagt meine ich damit das ich jedem Dreieck des Spielfelds sage wo in der Großen Textur mit allen Feldtexturen die zu verwendenen Texturpunkte sind... Siehe SpriteCandy Imagepacker ^^) Grüßle: Kernle PS: Ist eine Feldgröße von 64x64 und eine Feldtexturgröße von 128x128 Speicher- und Rechenleistungsmäßig vertretbar ? (ausgegangen von einer guten Umsetzung) |
||
- Zuletzt bearbeitet von Kernle 32DLL am Di, Dez 18, 2007 17:21, insgesamt einmal bearbeitet
Dreamora |
Di, Dez 18, 2007 15:54 Antworten mit Zitat
|
|
|---|---|---|
|
In eine packen geht bei Terrains dieser Art nicht.
Grund ist das die Texturrepetition via UV Tricks geht und wenn du mehr als eine Textur drauf hast, kannst du keine UV tricks haben. du wärst also wieder am gleichen punkt wie wenn du eine Grosse textur hast ... |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
|
Kernle 32DLL |
Di, Dez 18, 2007 17:30 Antworten mit Zitat
|
|---|---|---|
hm,wiso ? Wenn ich eine Textur wie diese habe:
Dann weis ich das Feldtyp Nr1 die Punkte... 0.0,0.0 // 0.5,0.0 0.0,0.5 // 0.5,0.5 ...hat. Und diese kann ich den Vertices ja doch eigentlich zuweisen oder ? Ich rede hierbei üprigens nicht vom B3D Terrain ^^ Die Idee gefällt mir eigentlich... Zumal ich damit theoretisch nur ein Mesh und eine Surface habe. Oder ich mache einfach ein Mesh mit jedem Feld als eine Surface. oder ich bleibe dabei jedes Feld = ein Mesh+Surface. Ich bräuchte einfach mal einen Ratschlag von euch was ich letzendlich machen soll ^^ Programmiert bekomme ich das bestimmt, aber ich weis schlicht nicht welche die beste Lösung ist. Das einzig Wichtige ist, dass das Terrain möglichst wenig Leistung frist, da ich die für die Spielfiguren brauche (viele Partikeleffekte, etc.). Grüßle: Kernle PS: Danke das ihr euch so für mein problem einsetzt und versucht mir die Problematik näher zu bringen ^^ |
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
|
aMulSieger des Minimalist Compo 01/13 |
Di, Dez 18, 2007 18:01 Antworten mit Zitat
|
|---|---|---|
|
Ich würde auf keinem Fall jeden Feld ein eigenes Surface verpassen, bei 100x100 Feldern hast du dann 10,000 Surfaces und ich bezweifele, dass ältere Grafikkarten da noch mitspielen.
Eine Alternative wurde übrigens noch gar nicht genannt: Du könntest alle Felder mit gleicher Textur in ein Surface packen. Dann könntest du das maximale aus deinen Texturen rausholen und hättest nicht übertrieben viele Surfaces. (Evtl. könntest du auch wie du in deinem letzen Posts zeigst mehrere Texturen in eine packen und so gruppieren -> weniger Surfaces) Der einzige Nachteil an dieser Methode ist, dass so eigentlich immer das ganze Spielfeld gerendert wird(sobald einmal Gras sichtbar -> alles Gras gerendert) Um diesen Effekt zu verhinder könnte man das Spielfeld auch noch mal in mehrer Teile unterteilen und nur in diesen die Felder gleicher Textur in ein Surface packen. Was jetzt die optimale Lösung ist? Gute Frage, das kommt ganz darauf an, wie detailliert deine Texturen sein sollen, wie viele Texturen es geben soll und natürlich auch, ob jedes Feld nur aus zwei Polys bestehen oder gar eine eigenen Geometrie haben soll. Gemäß dem Fall, dass die Texturen nicht hyper-detailliert sein sollen und die Felder aus nur je zwei Polys bestehen, wurde ich die empfehlen, das Spielfeld in mehrere Meshes (+ Surfaces) mit je 32*32 bis 64*64 Feldern aufzuteilen und die Texturen alle in eine Megatextur zu packen(in 2048^2 passt ganz schön was rein). Wenn du die Texturen größer als 128*128 habe willst würde ich dir dann doch eher raten Felder gleicher Textur ins gleiche Surface zu stecken und bei einem großen Spielfeld dieses wie beschrieben auch noch einmal aufzuteilen. EDIT: Mir fällt gerade auf, dass die Frage mit dem mehrere Texturen in eine packen und per UV-Koordinaten zuteilen noch gar nicht geklärt zu sein scheint. Ich weiß ehrlich gesagt nicht wirklich was Dreamora in seinem letzen Post sagen wollte, aber solange man jedem Feld seine eigenen vier Vertices gibt, kann man ihm auch einen eigenen Texturabschnitt zuweisen. |
||
|
Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben!
advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans! Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! | RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 | Stereoskopie in Blitz3D | Teleport-Animation Screensaver |
||
|
|
Kernle 32DLL |
Di, Dez 18, 2007 19:37 Antworten mit Zitat
|
|---|---|---|
|
gut, ich denke ich werde mal beides ausprobieren.
Die "Ein Mesh / Eine Surface" Methode und die "Mesh+Surface pro Feldtyp" Methode evt. probiere ich auch ne andere Art von Gruppierung.. mal schauen 
Danke für die Tipps
Jetzt geht es mir ums spielerrische... Da ich ja nun ein Terrain nehme, muss ich mir überlegen wie ich die Einheiten darauf platziere... Einfach im Mittelpunkt der 4 Punkte eines Feldes sieht vermutlich recht seltsam aus... (Vor allem bei Quadratischen Würfel Figuren). Irgentwelche Vorschläge ?
Grüßle: Kernle |
||
|
Mein PC: "Bluelight" - Xtreme Gamer PC [Video]
Meine Projekte: Cube-Wars 2010 [Worklog] Anerkennungen: 1. Platz BCC #7 , 1. Platz BCC #22 , 3. Platz BAC #89 Ich war dabei: NRW Treff III, IV ; Frankfurter BB Treffen 2009 |
||
|
|
hecticSieger des IS Talentwettbewerb 2006 |
Di, Dez 18, 2007 19:50 Antworten mit Zitat
|
|---|---|---|
|
Wenn man ein Bild auf einer Textur hat, dann kann man die UV-Koordinaten über 1 hinaus laufen lassen. Dadurch kann man Traingles einsparen, da pro Quad eben mehrfach das selbe Bild nebeneinander zu sehen ist. Das ist ein Trick, aber bei solchen Spielfelder wie oben beschrieben nicht möglich.
Alternative: Man erstellt pro Spielfeldeinheit ein Quad und setzt pro Quad eigene UV-Koordinaten. Dabei werden dann mehrere Bilder in eine Textur kopiert. Sowas habe ich erst kürzlich gemacht. http://www.hectic.de/data/tileterrain.rar Bevor Fragen auftauchen. Das Tileterrain kann: - ''beliebig'' groß sein, da eine automatische Sektoraufteilung angegeben werden kann (Sinnvoll z.B. 32x32 Quads/Block) - mit dem Mausrad gezoomt werden. - Pro Block ein EntityAutoFade eingestellt werden, was Recourcen einspart. Vielleicht ist es das was du suchst... edit1: Was noch nicht drin ist, aber für ein Spiel rein muss, ist das abspeichern der einzelnen Handles pro Block, da sonst diese nicht mehr per Laufzeit gelöscht werden können. |
||
| Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D | ||
Übersicht
BlitzBasic Blitz3D
Powered by phpBB © 2001 - 2006, phpBB Group