Tiles wie bei Need For Speed

Übersicht

BlitzBasic

Blitz3D

	JPD Betreff: Tiles wie bei Need For Speed	So, Jul 23, 2006 13:16 Antworten mit Zitat
Hallo zusammen, ich hab das vor 2 Jahren schonmal gefragt. Bin in der Zwischenzeit auch mal etwas weitergekommen, aber noch nicht zu dem Ergebnis, was ich gesucht habe. Ich frage mich schon eine ganze Zeit, wie man Rennstrecken ala NFS in Blitz3D reinbekommt. Das 3D-Modell ist dabei kein Problem, auch nicht die Modelle. Das Problem ist dieses mit den Texturen. Nun, für die jenigen, die es nicht wissen: Need For Speed verwendet ja eine Art von Tiles. Wenn man sichs genauer anschaut, sitzt da ja immer Quadrat an Quadrat. Mein Problem nun: Mehrere Surfaces im DIM-Feld hat fehlgeschlagen (bei 100 Texturen kracht mein PC zusammen) Mehrere Meshes zusammen, bei 100 Texturen = 100 Meshes (zu komopliziert) Die Möglichkeit, mit der UV-Map, also dass 16 Texturen in einer Map sind. Gut und Recht, aber die Ränder sehen schrottig aus. Nun bin ich mit meinem Latein am Ende und wollte wissen, ob von euch jemand weiß, wie man sowas umsetzen könnte. habe auch schon sowas probiert: (allerdings Schwachsinn im Nachhinein) Code: [AUSKLAPPEN] [EINKLAPPEN] dim texturen(100) textur(1) = LoadTexture("tex01.tga") mfg Jan Ich bin mir nicht ganz im klaren wie sich das ganze mit Mesh, Surface und Textur verhält. Vielleicht kann mir hier jemand ein paar Tipps geben.

JPD

Betreff: Tiles wie bei Need For Speed

So, Jul 23, 2006 13:16
Antworten mit Zitat

Hallo zusammen,

ich hab das vor 2 Jahren schonmal gefragt. Bin in der Zwischenzeit auch mal etwas weitergekommen, aber noch nicht zu dem Ergebnis, was ich gesucht habe.

Ich frage mich schon eine ganze Zeit, wie man Rennstrecken ala NFS in Blitz3D reinbekommt. Das 3D-Modell ist dabei kein Problem, auch nicht die Modelle. Das Problem ist dieses mit den Texturen.

Nun, für die jenigen, die es nicht wissen: Need For Speed verwendet ja eine Art von Tiles. Wenn man sichs genauer anschaut, sitzt da ja immer Quadrat an Quadrat.

Mein Problem nun:

Mehrere Surfaces im DIM-Feld hat fehlgeschlagen (bei 100 Texturen kracht mein PC zusammen)

Mehrere Meshes zusammen, bei 100 Texturen = 100 Meshes (zu komopliziert)

Die Möglichkeit, mit der UV-Map, also dass 16 Texturen in einer Map sind. Gut und Recht, aber die Ränder sehen schrottig aus.

Nun bin ich mit meinem Latein am Ende und wollte wissen, ob von euch jemand weiß, wie man sowas umsetzen könnte. habe auch schon sowas probiert: (allerdings Schwachsinn im Nachhinein)

Code: [AUSKLAPPEN]

dim texturen(100)
textur(1) = LoadTexture("tex01.tga")

mfg Jan

Ich bin mir nicht ganz im klaren wie sich das ganze mit Mesh, Surface und Textur verhält. Vielleicht kann mir hier jemand ein paar Tipps geben.

	hectic Sieger des IS Talentwettbewerb 2006	Di, Aug 08, 2006 16:51 Antworten mit Zitat
Nur eines mal kurz zwischendurch (sitze zZ bei der Arbeit). Wenn man beispielsweise 16 Teiltexturen in einer geladenen Textur per UV auslesen möchte, muß folgendes beachtet werden: Beispiel: Geladene Textur mit 512x512 Pixel ~ 128x128 Pixel einer Teiltextur. Um die kantenübergänge der Teiltexturen schön aussehen zu lassen, muß eine Teiltextur auf 127x127 bzw. 126x126 gezeichnet werden. Das liegt daran, daß an jedem Ende einer Textur schon in das nächste Pixel 'hinein geslidet' wird. Im Idealfall sieht dann eine Teiltextur wie folgt aus: 126x126 die durch Wiederholungsmuster auf 128x128 gebracht und in die Geladene Textur eingezeichnet wird. Beim Auslesen wird dann jedoch nur der Teilabschnitt von 126x126 per UV ausgelesen, auch wenn 128x128 in der Quelle vorhanden sind. Zu beachten ist auch, daß die UV-Koordinaten um 0,5 Pixel verschoben sind. Ist schwer zu erklären, aber wenn man es einmal gemacht hat leicht zu verstehen.

hectic

Sieger des IS Talentwettbewerb 2006

Di, Aug 08, 2006 16:51
Antworten mit Zitat

Nur eines mal kurz zwischendurch (sitze zZ bei der Arbeit).

Wenn man beispielsweise 16 Teiltexturen in einer geladenen Textur per UV auslesen möchte, muß folgendes beachtet werden: Beispiel:

Geladene Textur mit 512x512 Pixel ~ 128x128 Pixel einer Teiltextur.

Um die kantenübergänge der Teiltexturen schön aussehen zu lassen, muß eine Teiltextur auf 127x127 bzw. 126x126 gezeichnet werden. Das liegt daran, daß an jedem Ende einer Textur schon in das nächste Pixel 'hinein geslidet' wird.

Im Idealfall sieht dann eine Teiltextur wie folgt aus:

126x126 die durch Wiederholungsmuster auf 128x128 gebracht und in die Geladene Textur eingezeichnet wird. Beim Auslesen wird dann jedoch nur der Teilabschnitt von 126x126 per UV ausgelesen, auch wenn 128x128 in der Quelle vorhanden sind. Zu beachten ist auch, daß die UV-Koordinaten um 0,5 Pixel verschoben sind.

Ist schwer zu erklären, aber wenn man es einmal gemacht hat leicht zu verstehen.

	JPD	Mi, Aug 09, 2006 0:54 Antworten mit Zitat
Aja, dachte auch schon an so eine Lösung. 126x126 Pixel würden für meine Zwecke ja ausreichen. also wenn ich einen Punkt an UV 0.5 x 0.5 setzen möchte, also die Mitte, dann muss ich vorher noch die Verschiebung mit den 0,5 Pixel beachten. Währe mein Bild 512 Pixel breit würde das auf 0,5 Pixel umgerechnet +0,0009765625 ergeben ... macht das Sinn? Nunja, ich werde es mal probieren ... woher kommen diese 0,5 Pixel? MfG JPD

JPD

Mi, Aug 09, 2006 0:54
Antworten mit Zitat

Aja, dachte auch schon an so eine Lösung.

126x126 Pixel würden für meine Zwecke ja ausreichen.

also wenn ich einen Punkt an UV 0.5 x 0.5 setzen möchte, also die Mitte, dann muss ich vorher noch die Verschiebung mit den 0,5 Pixel beachten. Währe mein Bild 512 Pixel breit würde das auf 0,5 Pixel umgerechnet +0,0009765625 ergeben ... macht das Sinn?

Nunja, ich werde es mal probieren ... woher kommen diese 0,5 Pixel?

MfG JPD

	Jan_ Ehemaliger Admin	Mi, Aug 09, 2006 7:46 Antworten mit Zitat
ich bin der Festen überzeugung, NFS benutzt keine Tiles. Das die Leute es aus Straßen im 3D Modeller zusammensetzten möge was anderes sein, aber ich glaube nciht, das die Tiles benutzen
between angels and insects

Jan_

Ehemaliger Admin

Mi, Aug 09, 2006 7:46
Antworten mit Zitat

ich bin der Festen überzeugung, NFS benutzt keine Tiles.
Das die Leute es aus Straßen im 3D Modeller zusammensetzten möge was anderes sein, aber ich glaube nciht, das die Tiles benutzen

between angels and insects

	Dreamora	Mi, Aug 09, 2006 8:12 Antworten mit Zitat
Wär auch ziemlich hirnrissig, wenn man schon nen 3D Modeller benutzt, nicht? Dazu kann man schliesslich die UV von Strassenteilen einfach so machen, dass sich die Textur schön wiederholt (rasch den UV Mapper anschmeissen und planar UV mappen, da es ja nur ne strasse is). Danach verbiegt man dann die Strasse in die gewünschte "Formung" (Kurve, hochkurve oder was auch immer) und die Textur bleibt immer noch korrekt, solange man die Strasse nicht breiter / schmaller macht (das ist verboten)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 09, 2006 8:12
Antworten mit Zitat

Wär auch ziemlich hirnrissig, wenn man schon nen 3D Modeller benutzt, nicht? Smile

Dazu kann man schliesslich die UV von Strassenteilen einfach so machen, dass sich die Textur schön wiederholt (rasch den UV Mapper anschmeissen und planar UV mappen, da es ja nur ne strasse is). Danach verbiegt man dann die Strasse in die gewünschte "Formung" (Kurve, hochkurve oder was auch immer) und die Textur bleibt immer noch korrekt, solange man die Strasse nicht breiter / schmaller macht (das ist verboten)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	hectic Sieger des IS Talentwettbewerb 2006	Mi, Aug 09, 2006 12:27 Antworten mit Zitat
@JPD, Wenn man eine Textur mit den Angaben der größe läd, so spart man sich die Angabe 'komischer' zahlen wie +0,0009765625. Beispiel: Eine Textur von 512x512 läd man dann mit LoadTexture("textur.png",1,512,512). setzt man dann die UV Koordinaten, dann entspricht es direkt den Pixelbreiten. Also UV 0.5,0.5 bedeutet das erste Pixel oben/links, UV 511.5,511.5 das Pixel unten/rechts.

hectic

Sieger des IS Talentwettbewerb 2006

Mi, Aug 09, 2006 12:27
Antworten mit Zitat

@JPD, Wenn man eine Textur mit den Angaben der größe läd, so spart man sich die Angabe 'komischer' zahlen wie +0,0009765625. Beispiel: Eine Textur von 512x512 läd man dann mit LoadTexture("textur.png",1,512,512). setzt man dann die UV Koordinaten, dann entspricht es direkt den Pixelbreiten. Also UV 0.5,0.5 bedeutet das erste Pixel oben/links, UV 511.5,511.5 das Pixel unten/rechts.

	JPD	Mi, Aug 09, 2006 12:41 Antworten mit Zitat
@hectic ... gute Idee, so wirds schon leichter eine Art Tilemap umzusetzen. @Dreamora ... ich weiß nicht ob du die Zeiten von NFS 3 und NFS 4 kennst, bei denen ein sogenannter T3ED-Trackeditor herausgekommen ist. Dieser war so aufgebaut, dass die ganze Strecke aus Quadraten aufgebaut war. Diese konnten jeweils mit den einzelnen Tiles belegt werden. Anders komme ich ja gar nicht auf die Idee mit den Tiles. Also danke erstmal ... melde mich wieder wenns was Neues gibt JPD

JPD

Mi, Aug 09, 2006 12:41
Antworten mit Zitat

@hectic ... gute Idee, so wirds schon leichter eine Art Tilemap umzusetzen.

@Dreamora ... ich weiß nicht ob du die Zeiten von NFS 3 und NFS 4 kennst, bei denen ein sogenannter T3ED-Trackeditor herausgekommen ist. Dieser war so aufgebaut, dass die ganze Strecke aus Quadraten aufgebaut war. Diese konnten jeweils mit den einzelnen Tiles belegt werden. Anders komme ich ja gar nicht auf die Idee mit den Tiles.

Also danke erstmal ... melde mich wieder wenns was Neues gibt Very Happy

JPD

	Dreamora	Mi, Aug 09, 2006 12:55 Antworten mit Zitat
JPD hat Folgendes geschrieben: @Dreamora ... ich weiß nicht ob du die Zeiten von NFS 3 und NFS 4 kennst, bei denen ein sogenannter T3ED-Trackeditor herausgekommen ist. Dieser war so aufgebaut, dass die ganze Strecke aus Quadraten aufgebaut war. Diese konnten jeweils mit den einzelnen Tiles belegt werden. Anders komme ich ja gar nicht auf die Idee mit den Tiles. Ach so. Ne den Editor kenne ich net, die Spiele hingegen schon. Dachte nur weil du in 3D auch mit quadratischen bzw. rechteckicken blöcken arbeiten musst wenn die strasse nicht einfach nur eben ist, sich das ganze also auch auf etwas ähnliches reduziert wie dein Problem. Weil auf "total Tile" runter ist bei richtigem 3D so eine Sache ... da wirste noch an ganz andere Probleme stossen, die bei Pseudo 3D und Fakes wie sie damals normal waren garnie entstehen konnten.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 09, 2006 12:55
Antworten mit Zitat

JPD hat Folgendes geschrieben:

@Dreamora ... ich weiß nicht ob du die Zeiten von NFS 3 und NFS 4 kennst, bei denen ein sogenannter T3ED-Trackeditor herausgekommen ist. Dieser war so aufgebaut, dass die ganze Strecke aus Quadraten aufgebaut war. Diese konnten jeweils mit den einzelnen Tiles belegt werden. Anders komme ich ja gar nicht auf die Idee mit den Tiles.

Ach so.
Ne den Editor kenne ich net, die Spiele hingegen schon.
Dachte nur weil du in 3D auch mit quadratischen bzw. rechteckicken blöcken arbeiten musst wenn die strasse nicht einfach nur eben ist, sich das ganze also auch auf etwas ähnliches reduziert wie dein Problem.
Weil auf "total Tile" runter ist bei richtigem 3D so eine Sache ... da wirste noch an ganz andere Probleme stossen, die bei Pseudo 3D und Fakes wie sie damals normal waren garnie entstehen konnten.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	JPD	Mi, Aug 09, 2006 13:01 Antworten mit Zitat
Hm, du meinst sowas wie Raycaster oder die "3D"-Landschaft von Siedler ... oder wohl das Softwarerendering ... nunja, das Hauptproblem auf das ich bei meinen Tiles gestoßen bin ist einfach die Verwaltung der ganzen Texturen. Ich meine jetzt nicht, alles irgendwie in eine Datei oder so speichern, sondern wie ich das ganze Sinnvoll in den Grafikkartenspeicher bring, ohne dass sich bei ner Landschaft von 5000 Triangles nur noch 10 fps hab ... aber mit dem Ansatz der UV-Map bin ich schonmal ein Stück weiter gekommen ... oder kennt jemand 3DGameStudio von damals "Sybex" ... dort konnte man auch Riesige 3D-Welten bauen mit hunderten von Texturen und das ganze lief flüssig. Hm ... so viel zum Thema Texturenverwaltung ... k.a. wie das Professionel gemacht wird ...

JPD

Mi, Aug 09, 2006 13:01
Antworten mit Zitat

Hm, du meinst sowas wie Raycaster oder die "3D"-Landschaft von Siedler ... oder wohl das Softwarerendering ...

nunja, das Hauptproblem auf das ich bei meinen Tiles gestoßen bin ist einfach die Verwaltung der ganzen Texturen. Ich meine jetzt nicht, alles irgendwie in eine Datei oder so speichern, sondern wie ich das ganze Sinnvoll in den Grafikkartenspeicher bring, ohne dass sich bei ner Landschaft von 5000 Triangles nur noch 10 fps hab ... aber mit dem Ansatz der UV-Map bin ich schonmal ein Stück weiter gekommen ...

oder kennt jemand 3DGameStudio von damals "Sybex" ... dort konnte man auch Riesige 3D-Welten bauen mit hunderten von Texturen und das ganze lief flüssig. Hm ... so viel zum Thema Texturenverwaltung ... k.a. wie das Professionel gemacht wird ...

	Dreamora	Mi, Aug 09, 2006 13:08 Antworten mit Zitat
Sinnvoll in den Grafikspeicher bringen ist garnicht so das Problem. Dazu sind 2 Dinge aber elementar wichtig: 1. Anzahl der verschiedenen Texturen reduzieren (-> kombinieren auf einer), um die Surfaceanzahl reduzieren zu können. Hat allerdings den Hacken das man die maximalauflösung einzelner Texturen reduzieren muss. (um dein Beispiel mit Editor zu nehmen: Da wars glaub 64x64 oder so, was auf heutigen systemen zum heulen aussieht) ) 2. Meshes zusammenfügen per AddMesh um die Anzahl Surfaces weiter zu reduzieren. Dazu solltest du einfach alles was in einem gewissen bereich ist zusammenfügen. (erst beim export aus dem Editor, wie langsam es im Editor drin ist, interessiert ja eigentlich niemanden, du solltest dann einfach eine einigermassen gescheite Grafikkarte haben. Also etwas was mindestens auf 600 endet, egal ob von NVidia oder ATI ) Da gibt es zu bedenken, dass du nicht mehr als 32768 Polygone zusammenpacken solltest ausser du setzt GeForce 5 voraus, da es davor karten gibt (GF4 MX zb) die sonst einfach das zeitliche segnen und garnix rendern oder MAVen. Damit sollte es dir eigentlich problemlos möglich sein sehr sehr viel reinzubekommen. Und durch die lokal ("würfelbereich" oder so) zusammengefügten Meshes wird das Rendering durch das Verhalten von Blitz3D noch weiter beschleunigt
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 09, 2006 13:08
Antworten mit Zitat

Sinnvoll in den Grafikspeicher bringen ist garnicht so das Problem. Dazu sind 2 Dinge aber elementar wichtig:

1. Anzahl der verschiedenen Texturen reduzieren (-> kombinieren auf einer), um die Surfaceanzahl reduzieren zu können. Hat allerdings den Hacken das man die maximalauflösung einzelner Texturen reduzieren muss. (um dein Beispiel mit Editor zu nehmen: Da wars glaub 64x64 oder so, was auf heutigen systemen zum heulen aussieht) )

2. Meshes zusammenfügen per AddMesh um die Anzahl Surfaces weiter zu reduzieren. Dazu solltest du einfach alles was in einem gewissen bereich ist zusammenfügen. (erst beim export aus dem Editor, wie langsam es im Editor drin ist, interessiert ja eigentlich niemanden, du solltest dann einfach eine einigermassen gescheite Grafikkarte haben. Also etwas was mindestens auf 600 endet, egal ob von NVidia oder ATI Smile

)

Da gibt es zu bedenken, dass du nicht mehr als 32768 Polygone zusammenpacken solltest ausser du setzt GeForce 5 voraus, da es davor karten gibt (GF4 MX zb) die sonst einfach das zeitliche segnen und garnix rendern oder MAVen.

Damit sollte es dir eigentlich problemlos möglich sein sehr sehr viel reinzubekommen. Und durch die lokal ("würfelbereich" oder so) zusammengefügten Meshes wird das Rendering durch das Verhalten von Blitz3D noch weiter beschleunigt Smile

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	JPD	Mi, Aug 09, 2006 13:17 Antworten mit Zitat
Ok ... soweit hab ich das nun wohl kapiert. Kann man das irgendwo nachlesen wie Blitz3D arbeitet? Das Beispiel mit dem hochaufgelösten Raum der sich hinter einer unscheinbaren Wand verbirgt und ein Spiel in die Knie zwingt kennt vielleicht jeder ... man dreht sich und sieht eigentlich nur die Wand ... aber hinter der Wand sind tausende Polygone. Nunja, wie siehts bei Blitz3D mit der Logik aus ... entscheidet Blitz3D selbst was gerendert werden muss und was überhaupt sichtbar ist? BTW: Es ist nicht LoadTexture, sondern LoadBrush mit U_scale und V_scale ..

JPD

Mi, Aug 09, 2006 13:17
Antworten mit Zitat

Ok ... soweit hab ich das nun wohl kapiert.

Kann man das irgendwo nachlesen wie Blitz3D arbeitet?

Das Beispiel mit dem hochaufgelösten Raum der sich hinter einer unscheinbaren Wand verbirgt und ein Spiel in die Knie zwingt kennt vielleicht jeder ... man dreht sich und sieht eigentlich nur die Wand ... aber hinter der Wand sind tausende Polygone. Nunja, wie siehts bei Blitz3D mit der Logik aus ... entscheidet Blitz3D selbst was gerendert werden muss und was überhaupt sichtbar ist?

BTW: Es ist nicht LoadTexture, sondern LoadBrush mit U_scale und V_scale ..

	Dreamora	Mi, Aug 09, 2006 13:21 Antworten mit Zitat
Bei Blitz wird jede Surface von der auch nur 1 Vertice im Sichtkegel ist, zwecks rendern an die Grafikkarte geschickt. Insofern nutzt dir eine verdeckende Wand nichts, wenn das dahinter auch im Sichtbereich ist, sofern du das dahinter nicht selbst hidest. Das liegt daran, dass es unendlich ineffizient wäre, das zu versuchen im Normalfall. Das zieht nur bei Leveln wie du sie aus Doom und so kennst. Diese optimieren das indem sie ein speziell darauf ausgelegtes Levelformat haben welches intern solche dinge gespeichert hat wie "was ist von wo aus sichtbar", weswegen solche Level dann auch kompiliert werden und nicht einfach nur gespeichert. Bei weitläufigerem nutzt man häufig entityfade und sinnvolle Kamerasichtweiten (nein, 10000 ist keine sinnvolle!) sowie nebel, dann kommt man auf ziemlich extreme leistungen. Zudem sollte man timed programmieren, dass heisst das man nicht alles immer in der hauptschleife stupid aufruft sondern nur wenn eine gewisse Zeitspanne vergangen ist (sehr wichtig beim rendern, denn die meiste zeit geht dort baden weil man 300 FPS rendert obwohl man nur 60 sieht auf dem Schirm. die restlichen 240 würden dem spiel extrem viel Zeit für AI, Physik etc geben und halt auch für SceneManagement so das man nicht nötige Dinge hiden könnte etc
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 09, 2006 13:21
Antworten mit Zitat

Bei Blitz wird jede Surface von der auch nur 1 Vertice im Sichtkegel ist, zwecks rendern an die Grafikkarte geschickt.
Insofern nutzt dir eine verdeckende Wand nichts, wenn das dahinter auch im Sichtbereich ist, sofern du das dahinter nicht selbst hidest.
Das liegt daran, dass es unendlich ineffizient wäre, das zu versuchen im Normalfall.
Das zieht nur bei Leveln wie du sie aus Doom und so kennst. Diese optimieren das indem sie ein speziell darauf ausgelegtes Levelformat haben welches intern solche dinge gespeichert hat wie "was ist von wo aus sichtbar", weswegen solche Level dann auch kompiliert werden und nicht einfach nur gespeichert.

Bei weitläufigerem nutzt man häufig entityfade und sinnvolle Kamerasichtweiten (nein, 10000 ist keine sinnvolle!) sowie nebel, dann kommt man auf ziemlich extreme leistungen.
Zudem sollte man timed programmieren, dass heisst das man nicht alles immer in der hauptschleife stupid aufruft sondern nur wenn eine gewisse Zeitspanne vergangen ist (sehr wichtig beim rendern, denn die meiste zeit geht dort baden weil man 300 FPS rendert obwohl man nur 60 sieht auf dem Schirm. die restlichen 240 würden dem spiel extrem viel Zeit für AI, Physik etc geben und halt auch für SceneManagement so das man nicht nötige Dinge hiden könnte etc Smile

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Tiles wie bei Need For Speed

Betreff: Tiles wie bei Need For Speed