Mal wieder Terrain...

Übersicht

BlitzBasic

Blitz3D

Gehe zu Seite Zurück 1, 2

	LaiKiam	Sa, Mai 20, 2006 12:54 Antworten mit Zitat
Da ich (noch) nicht mit Mesh Terrains arbeite, habe ich folgenden Quickhack gecodet, um die Texturen zu unterteilen: Code: [AUSKLAPPEN] [EINKLAPPEN] ; Tiler map_size=4096 tile_size=128 ; Finale Tiles sind (tile_size+tile_size) groß tile_x=(map_size/tile_size)-1 tile_y=(map_size/tile_size)-1 map_type$="bigmap" Graphics 1024,768,32 SetBuffer FrontBuffer() map_file$=map_type$+".bmp"; da_map=LoadImage(map_file$) savetile=CreateImage((tile_size2),(tile_size2)) Cls For y=1 To tile_y For x=1 To tile_x Cls sx=(x-1)tile_size sy=(y-1)tile_size DrawImageRect da_map,10,10,sx,sy,(tile_size2),(tile_size2) GrabImage savetile,10,10 ok=SaveImage (savetile,"textures/"+map_type$+"-"+x+"-"+(tile_y+1-y)+".bmp") Delay (10) Next Next While Not KeyHit(1) Wend Hoffe, das hilft dir . Da ich den Terrainbefehl benutze, habe ich die Überlappung auf 50% gelegt und nicht nur einen Pixel. Sollte aber ohne Probleme auf deine Bedürfnisse anpassbar sein.

LaiKiam

Sa, Mai 20, 2006 12:54
Antworten mit Zitat

Da ich (noch) nicht mit Mesh Terrains arbeite, habe ich folgenden Quickhack gecodet, um die Texturen zu unterteilen:

Code: [AUSKLAPPEN]

; Tiler

map_size=4096
tile_size=128 ; Finale Tiles sind (tile_size+tile_size) groß
tile_x=(map_size/tile_size)-1
tile_y=(map_size/tile_size)-1

map_type$="bigmap"

Graphics 1024,768,32

SetBuffer FrontBuffer()

map_file$=map_type$+".bmp";

da_map=LoadImage(map_file$)
savetile=CreateImage((tile_size*2),(tile_size*2))

Cls

For y=1 To tile_y
For x=1 To tile_x

Cls

sx=(x-1)*tile_size
sy=(y-1)*tile_size

DrawImageRect da_map,10,10,sx,sy,(tile_size*2),(tile_size*2)
GrabImage savetile,10,10
ok=SaveImage (savetile,"textures/"+map_type$+"-"+x+"-"+(tile_y+1-y)+".bmp")

Delay (10)

Next
Next

While Not KeyHit(1)
Wend

Hoffe, das hilft dir Smile

.
Da ich den Terrainbefehl benutze, habe ich die Überlappung auf 50% gelegt und nicht nur einen Pixel. Sollte aber ohne Probleme auf deine Bedürfnisse anpassbar sein.

	Bob	So, Mai 21, 2006 17:59 Antworten mit Zitat
Hi LaiKiam, danke für den Code aber das Teilen der Bitmap ist eigentlich nicht das Problem. Interessant wird es wen man versucht die einzelnen Bitmap's in Meshes zu "konvertieren" und dabei die Meshes nicht spiegelverkehrt (Y Achse) zu erzeugen und die korrekten UV Koordinaten der einzelnen Vertices zu setzen. Mittlerweile habe ich schon angefangen und die Meshes passen nahtlos aneinander und sind "Entspiegelt". Allerdings ist auf der Textur immer noch ein Übergang an den Nahtstellen zu sehen. Trotz Korrekter UV Koordinaten. Falls ich das alles noch korrekt hinbekomme werde ich den Code hier posten. Hier noch ein Screen. Der rote Hintergrund dieint dazu eventuell vorhandene Löcher bzw. falsche Übergänge in den Meshes's besser zu erkenen. Man erkennt leider deutlich das irgendetwas mit den Texturen noch nicht korrekt ist. Die Ursprüngliche Heightmap ist ein 256256 Bitmap das in 22 128er Bitmaps gesplittet wird. (Reicht ja zum testen)
Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

Bob

So, Mai 21, 2006 17:59
Antworten mit Zitat

Hi LaiKiam,

danke für den Code aber das Teilen der Bitmap ist eigentlich nicht das Problem.

Interessant wird es wen man versucht die einzelnen Bitmap's in Meshes zu "konvertieren" und dabei die Meshes nicht spiegelverkehrt (Y Achse) zu erzeugen und die korrekten UV Koordinaten der einzelnen Vertices zu setzen.

Mittlerweile habe ich schon angefangen und die Meshes passen nahtlos aneinander und sind "Entspiegelt".
Allerdings ist auf der Textur immer noch ein Übergang an den Nahtstellen zu sehen. Trotz Korrekter UV Koordinaten.

Falls ich das alles noch korrekt hinbekomme werde ich den Code hier posten.

Hier noch ein Screen.
Der rote Hintergrund dieint dazu eventuell vorhandene Löcher bzw. falsche Übergänge in den Meshes's besser zu erkenen.
Man erkennt leider deutlich das irgendetwas mit den Texturen noch nicht korrekt ist. Evil or Very Mad

Die Ursprüngliche Heightmap ist ein 256*256 Bitmap das in 2*2 128er Bitmaps gesplittet wird. (Reicht ja zum testen)

user posted image

Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

	LaiKiam	Mo, Mai 22, 2006 4:51 Antworten mit Zitat
Hm, ich habe da ein ganz ähnliches Problem: das erste Drittel ist auf Mapkoord 4,4 aufgenommen und im Hintergrund sieht man 2 steile Wände, welche dort aber nicht sind. Im 2ten Drittel befindet sich die Camera auf Koord 4,5 und eine Seite wird nun korrekt dargestellt und im letzten Drittel ist die Camera auf 5,5 und alles passt (bis ich wieder an den nächsten Rand komme). Die Heightmaps habe ich manuell kontrolliert aber keine Ränder gefunden. Irgendwie scheint BB da noch was zu interpolieren, kA. Ist in meinem Fall aber nicht so schlimm, da der Fehler zu 99% vom Nebel kaschiert wird. Falls du dein Problem gelöst hast, schau ich mir meins nochmal an, scheint das selbe Prob zu sein. Frage wieder an alle: Kommt man irgendwie an die einzelnen Polygone eines Terrains ran, wenn man LoadTerrain benutzt? Darf auch gerne ein GraKa Hack sein, da Schatten aus Meshes überhaupt nicht das Wahre sind. Steht ein Objekt auf einer ebenen Fläche, ist das gar kein Problem, auch nicht an einer einzelnen Schräge. Sobald aber ein Objekt einen Schatten über eine treppenartigen Struktur wirft, ist es Essig mit einfach. Der Meshschatten müsste dann mehrfach umgebrochen und die zusätzliche Verzerrung berechnet werden, sozusagen SoftwareStencil. Das ist dann ein Haufen Mathetik und noch mehr Polygone und das ist nicht Sinn einer auf 3D spezialisierten Sprache. Dann liegt ein Meshschatten über dem Terrain (wenn auch nur ganz wenig) und das sieht von der Seite nicht gut aus. 4096x4096 Lightmaps sind 50MB, kommen also nicht wirklich in Frage. Imho fehlt ein Befehl wie ProjectTexture texturehandle,blendingmode,posX,posY,posZ für Terrains, damit könnte man das ganze Schattendingsbums für immer und in einfach lösen... Jetzt aber erstmal gute Nacht gähn LaiKiam träumtvonStencilBuffern,Radiosity&PhotonMapping

LaiKiam

Mo, Mai 22, 2006 4:51
Antworten mit Zitat

Hm, ich habe da ein ganz ähnliches Problem:

das erste Drittel ist auf Mapkoord 4,4 aufgenommen und im Hintergrund sieht man 2 steile Wände, welche dort aber nicht sind. Im 2ten Drittel befindet sich die Camera auf Koord 4,5 und eine Seite wird nun korrekt dargestellt und im letzten Drittel ist die Camera auf 5,5 und alles passt (bis ich wieder an den nächsten Rand komme). Die Heightmaps habe ich manuell kontrolliert aber keine Ränder gefunden. Irgendwie scheint BB da noch was zu interpolieren, kA. Ist in meinem Fall aber nicht so schlimm, da der Fehler zu 99% vom Nebel kaschiert wird. Falls du dein Problem gelöst hast, schau ich mir meins nochmal an, scheint das selbe Prob zu sein.

Frage wieder an alle: Kommt man irgendwie an die einzelnen Polygone eines Terrains ran, wenn man LoadTerrain benutzt? Darf auch gerne ein GraKa Hack sein, da Schatten aus Meshes überhaupt nicht das Wahre sind.

Steht ein Objekt auf einer ebenen Fläche, ist das gar kein Problem, auch nicht an einer einzelnen Schräge. Sobald aber ein Objekt einen Schatten über eine treppenartigen Struktur wirft, ist es Essig mit einfach. Der Meshschatten müsste dann mehrfach umgebrochen und die zusätzliche Verzerrung berechnet werden, sozusagen SoftwareStencil. Das ist dann ein Haufen Mathetik Confused

und noch mehr Polygone und das ist nicht Sinn einer auf 3D spezialisierten Sprache. Dann liegt ein Meshschatten über dem Terrain (wenn auch nur ganz wenig) und das sieht von der Seite nicht gut aus. 4096x4096 Lightmaps sind 50MB, kommen also nicht wirklich in Frage.
Imho fehlt ein Befehl wie ProjectTexture texturehandle,blendingmode,posX,posY,posZ für Terrains, damit könnte man das ganze Schattendingsbums für immer und in einfach lösen...

Jetzt aber erstmal gute Nacht *gähn*
LaiKiam

*träumtvonStencilBuffern,Radiosity&PhotonMapping*

	Dreamora	Mo, Mai 22, 2006 8:51 Antworten mit Zitat
4kx4k Lightmaps kommen eh nicht in Frage, weil nur GF6 und Radeon X Serie die überhaupt unterstützen. Und sie wären schon ohne Mipmapps 64MB (mit mipmaps wärens rund 85MB) Und nein an die Vertices kommst du nicht ran. Es ist eine dynamische struktur.(sprich selbst wenn du ran kommst: Ohne Shader würde man davon die Finger lassen aus performance gründen) Nur wenn du Meshterrains erzeugst, hast du direkt Einfluss auf solche Dinge.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Mai 22, 2006 8:51
Antworten mit Zitat

4kx4k Lightmaps kommen eh nicht in Frage, weil nur GF6 und Radeon X Serie die überhaupt unterstützen. Und sie wären schon ohne Mipmapps 64MB (mit mipmaps wärens rund 85MB)

Und nein an die Vertices kommst du nicht ran. Es ist eine dynamische struktur.(sprich selbst wenn du ran kommst: Ohne Shader würde man davon die Finger lassen aus performance gründen) Nur wenn du Meshterrains erzeugst, hast du direkt Einfluss auf solche Dinge.

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

	Bob	Mo, Mai 22, 2006 12:52 Antworten mit Zitat
Ich werd bald wahnsinnig, um dem Problem der Fehlerhaften Darstellung von Texturen (fehler am Rand) auf die schliche zu Kommen habe ich mal ein kleinen Test veranstalltet. Scheinbar hat bb Grundsätzlich ein Problem mit Texturen oder es liegt an meiner G-Karte. Bei mir werden alle Texturen die so groß sind wie eigentlich gefordert (64,128,256,512 usw.) falsch dargestellt. Der Inhalt des Texturbuffers ist aber korrekt. (mit savebuffer und Photoshop überprüft.) Hier mal die Demo nebst Grafik "512.png" Code: [AUSKLAPPEN] [EINKLAPPEN] AppTitle "Fehlerhafte Darstellung von Texturen" Const ScreenX = 800 Const ScreenY = 600 Const Key_Space = 57 Graphics3D ScreenX,ScreenY,32,2 piv = CreatePivot() cam=CreateCamera(piv) Global Img,Tex img = LoadImage("512.png") B = ImageWidth(img) H = ImageHeight(img) txt1$="Geladen wurde eine BMP von "+B+"X"+H sprite = CreateSprite() PositionEntity sprite, 0,0,3 .nochmal Basis = Basis + 64 Durchgang = Durchgang + 1 txt2$ = "Erstellt wurde eine Texture von " + Basis +" x "+ Basis txt3$ = "Copiert wurde von ImageBuffer nach Texturebuffer von 0,0 bis "+ Basis +" x "+ Basis FreeTexture tex Tex = Createtexture(Basis,Basis) CopyRect 0,0,Basis,Basis,0,0,imagebuffer(img), TextureBuffer(tex) EntityTexture sprite,tex SetBuffer BackBuffer() While Not KeyDown( 1 ) If Keyhit(Key_Space) Then Goto Nochmal RenderWorld Text 0,0, txt1 Text 0,20, txt2 Text 0,40, txt3 Text 0,60, "Durchgang Nr. " + Durchgang Text 0,80, "Basis: " + Basis Text 0,ScreenY-20, "Fehlerhafte Darstellung immer bei 64,128,256,512,1024" Flip Wend End Man sieht bei jeweils am oberen und linken Rand bei 64,128,256 usw. eine Stück der Textur vom unteren bzw. rechten Rand. Wie kan man das beheben? 512.png
Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

Bob

Mo, Mai 22, 2006 12:52
Antworten mit Zitat

Ich werd bald wahnsinnig,

um dem Problem der Fehlerhaften Darstellung von Texturen (fehler am Rand) auf die schliche zu Kommen habe ich mal ein kleinen Test veranstalltet.
Scheinbar hat bb Grundsätzlich ein Problem mit Texturen oder es liegt an meiner G-Karte.

Bei mir werden alle Texturen die so groß sind wie eigentlich gefordert (64,128,256,512 usw.) falsch dargestellt.
Der Inhalt des Texturbuffers ist aber korrekt. (mit savebuffer und Photoshop überprüft.)

Hier mal die Demo nebst Grafik "512.png"

Code: [AUSKLAPPEN]

AppTitle "Fehlerhafte Darstellung von Texturen"

Const ScreenX = 800
Const ScreenY = 600
Const Key_Space = 57
Graphics3D ScreenX,ScreenY,32,2

piv = CreatePivot()
cam=CreateCamera(piv)
Global Img,Tex
img = LoadImage("512.png")
B = ImageWidth(img)
H = ImageHeight(img)
txt1$="Geladen wurde eine BMP von "+B+"X"+H

sprite = CreateSprite()
PositionEntity sprite, 0,0,3

.nochmal
Basis = Basis + 64
Durchgang = Durchgang + 1

txt2$ = "Erstellt wurde eine Texture von " + Basis +" x "+ Basis
txt3$ = "Copiert wurde von ImageBuffer nach Texturebuffer von 0,0 bis "+ Basis +" x "+ Basis

FreeTexture tex

Tex = Createtexture(Basis,Basis)
CopyRect 0,0,Basis,Basis,0,0,imagebuffer(img), TextureBuffer(tex)
EntityTexture sprite,tex

SetBuffer BackBuffer()
While Not KeyDown( 1 )
   If Keyhit(Key_Space) Then Goto Nochmal
RenderWorld
Text 0,0, txt1
Text 0,20, txt2
Text 0,40, txt3
Text 0,60, "Durchgang Nr. " + Durchgang
   Text 0,80, "Basis: " + Basis
   Text 0,ScreenY-20, "Fehlerhafte Darstellung immer bei 64,128,256,512,1024"

Flip
Wend
End

Man sieht bei jeweils am oberen und linken Rand bei 64,128,256 usw. eine Stück der Textur vom unteren bzw. rechten Rand.

Wie kan man das beheben?

512.png
user posted image

Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

	Bob	Mo, Mai 22, 2006 13:21 Antworten mit Zitat
Verdammte Hacke, (sorry für den Kraftausdruck) Vergesst die Post von oben. Ich hätte die Texture Clampen sollen. (CreateTexture,x,y,16+32) Sorry für die Panikmache.
Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

Bob

Mo, Mai 22, 2006 13:21
Antworten mit Zitat

Verdammte Hacke,

(sorry für den Kraftausdruck)

Vergesst die Post von oben.
Ich hätte die Texture Clampen sollen. Embarassed

(CreateTexture,x,y,16+32)

Sorry für die Panikmache.

Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

	LaiKiam	Mo, Mai 22, 2006 13:27 Antworten mit Zitat
@Bob: Hehe, das war einach, dein Tile ist 65x65 groß da du von 0,0 bis 64,64 kopierst. Setz' mal Basis-1 und dein Prob sollte gelöst sein. edit Oh, du warst etwas schneller @Dremora : 4kx4k funkt bei mir (GF5), aber klar, sind zu groß, zumal ich für das Riesenterrain einen Haufen davon haben müsste. Hm, Meshterrains, da kann ich ja gleich wieder Demos auf'm 68000 schreiben (ZOrder der Objekte, Aufbaurichtung des Terrains usw. muss ja dort selbst verwaltet werden). Wenigstens geht HiddenSurfaces bei Meshes automatisch, so das man nicht noch mit Flächennormalen hantieren muss. Frage mich, wofür die integrierten Terrainbefehle gut sind, grmbl...

LaiKiam

Mo, Mai 22, 2006 13:27
Antworten mit Zitat

@Bob: Hehe, das war einach, dein Tile ist 65x65 groß da du von 0,0 bis 64,64 kopierst. Setz' mal Basis-1 und dein Prob sollte gelöst sein.

*edit* Oh, du warst etwas schneller Smile

@Dremora : 4kx4k funkt bei mir (GF5), aber klar, sind zu groß, zumal ich für das Riesenterrain einen Haufen davon haben müsste.

Hm, Meshterrains, da kann ich ja gleich wieder Demos auf'm 68000 schreiben (ZOrder der Objekte, Aufbaurichtung des Terrains usw. muss ja dort selbst verwaltet werden). Wenigstens geht HiddenSurfaces bei Meshes automatisch, so das man nicht noch mit Flächennormalen hantieren muss. Frage mich, wofür die integrierten Terrainbefehle gut sind, grmbl...

	Dreamora	Mo, Mai 22, 2006 13:49 Antworten mit Zitat
Da würd ich nicht drauf wetten. Weil B3D verkleinert sie wenn sie zu gross ist für deine Karte ... Aber kann sein das ich mich irre, Radeon 9XXX tuns auf jeden Fall nicht. Und wie gesagt: Selbst wenn, niemand wäre so blöd eine solche Textur zu verwenden. Da kann man auch gleich sagen "Diese demo ist nur zum testen was passiert wenn ich mehr VRAM brauche als meine karte hat" ggg (was übrigens zu einem MAV führt, nur damit das auch geklärt wäre )
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Mai 22, 2006 13:49
Antworten mit Zitat

Da würd ich nicht drauf wetten. Weil B3D verkleinert sie wenn sie zu gross ist für deine Karte ...

Aber kann sein das ich mich irre, Radeon 9XXX tuns auf jeden Fall nicht.
Und wie gesagt: Selbst wenn, niemand wäre so blöd eine solche Textur zu verwenden. Da kann man auch gleich sagen "Diese demo ist nur zum testen was passiert wenn ich mehr VRAM brauche als meine karte hat" *ggg* (was übrigens zu einem MAV führt, nur damit das auch geklärt wäre Wink

)

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

	LaiKiam	Mo, Mai 22, 2006 14:08 Antworten mit Zitat
Danke @ Dremora. Okay, werde wohl heute 'ne Meshterrainengine coden müssen, habe grade beim Suchen nach Meshterrains zu meinem Randproblem folgendes gefunden https://www.blitzforum.de/foru...eshterrain: Zitat: Jedenfalls gibt es (soweit ich weiß) keine Lösung dafür, ein Terrain macht sich automatisch mit sich selber kachelbar, d.h. wenn es rechts hoch ist, wird es links die gleiche Höhe haben (wenn auch nur am Rand). demTerrainCodervonBBHaareeinzelnrausreis

LaiKiam

Mo, Mai 22, 2006 14:08
Antworten mit Zitat

Danke @ Dremora.
Okay, werde wohl heute 'ne Meshterrainengine coden müssen, habe grade beim Suchen nach Meshterrains zu meinem Randproblem folgendes gefunden https://www.blitzforum.de/foru...eshterrain:
Zitat:

Jedenfalls gibt es (soweit ich weiß) keine Lösung dafür, ein Terrain macht sich automatisch mit sich selber kachelbar, d.h. wenn es rechts hoch ist, wird es links die gleiche Höhe haben (wenn auch nur am Rand).

*demTerrainCodervonBBHaareeinzelnrausreis*

	Dreamora	Mo, Mai 22, 2006 14:14 Antworten mit Zitat
Clamping aktivieren oder die Heightmaps nicht als Texturen laden, weil das eh nicht notwendig ist, sondern als Bilder. Da kann BB nix dafür, das ist ein Standardverhalten von DirectX. Der letzte Pixel links und der erste Pixel rechts werden mit einander "verblendet". Will man das raus haben, wirds leicht umständlich, da man clamping reinpacken muss und die UV koordinaten leicht modifizieren muss (glaube die müssen dann am Rand überall 1 / anzahl pixel pro seite# reingezogen werden und im verbleibenden bereich gleichmässig aufgeteilt werden, wenn ich mich recht erinnere an meinen damaligen Versuch der auch auf genau das Problem rauslief ... wie bei den meisten mit mesh terrain und geomipmapping )
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Mai 22, 2006 14:14
Antworten mit Zitat

Clamping aktivieren oder die Heightmaps nicht als Texturen laden, weil das eh nicht notwendig ist, sondern als Bilder.

Da kann BB nix dafür, das ist ein Standardverhalten von DirectX. Der letzte Pixel links und der erste Pixel rechts werden mit einander "verblendet". Will man das raus haben, wirds leicht umständlich, da man clamping reinpacken muss und die UV koordinaten leicht modifizieren muss (glaube die müssen dann am Rand überall 1 / anzahl pixel pro seite# reingezogen werden und im verbleibenden bereich gleichmässig aufgeteilt werden, wenn ich mich recht erinnere an meinen damaligen Versuch der auch auf genau das Problem rauslief ... wie bei den meisten mit mesh terrain und geomipmapping Wink

)

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

	LaiKiam	Mi, Mai 24, 2006 19:39 Antworten mit Zitat
Hi again, nerv bin gerade bei den MeshTerrains und hab' aus den obigen Posts einiges gelernt, allerdings ist noch ein Miniprob: Der Clamping Fehler ist bei mir auch aufgetaucht, und hab es korrigiert (Dank an Bob & Dreamora), allerdings verbleibt eine kleine Linie wie man im Bild sieht, egal ob als Image, Texture oder Brush geladen. Hab schon an jeder Ecke +/- 1 probiert, nix hilft. @Dreamora : Ich denke das liegt daran Zitat: Da kann BB nix dafür, das ist ein Standardverhalten von DirectX. Der letzte Pixel links und der erste Pixel rechts werden mit einander "verblendet". Will man das raus haben, wirds leicht umständlich, da man clamping reinpacken muss und die UV koordinaten leicht modifizieren muss (glaube die müssen dann am Rand überall 1 / anzahl pixel pro seite# reingezogen werden und im verbleibenden bereich gleichmässig aufgeteilt werden,... nur hab ich das noch nicht so ganz gecheckt, wie ich es beheben soll. Mag mir jemand das nochmal genauer erläutern?

LaiKiam

Mi, Mai 24, 2006 19:39
Antworten mit Zitat

Hi again, *nerv*

bin gerade bei den MeshTerrains und hab' aus den obigen Posts einiges gelernt, allerdings ist noch ein Miniprob:

Der Clamping Fehler ist bei mir auch aufgetaucht, und hab es korrigiert (Dank an Bob & Dreamora), allerdings verbleibt eine kleine Linie wie man im Bild sieht, egal ob als Image, Texture oder Brush geladen. Hab schon an jeder Ecke +/- 1 probiert, nix hilft.
@Dreamora : Ich denke das liegt daran Zitat:

Da kann BB nix dafür, das ist ein Standardverhalten von DirectX. Der letzte Pixel links und der erste Pixel rechts werden mit einander "verblendet". Will man das raus haben, wirds leicht umständlich, da man clamping reinpacken muss und die UV koordinaten leicht modifizieren muss (glaube die müssen dann am Rand überall 1 / anzahl pixel pro seite# reingezogen werden und im verbleibenden bereich gleichmässig aufgeteilt werden,...

nur hab ich das noch nicht so ganz gecheckt, wie ich es beheben soll. Mag mir jemand das nochmal genauer erläutern?

	stfighter01	Mi, Mai 24, 2006 22:13 Antworten mit Zitat
btw eine anregung. man muss ja nicht das ganze terrain auf einmal laden, man ein flache terrains erstellen und mit modifyterrain die höhen setzen. die kann man entweder laufend generieren od. aus einer datei streamen.
Denken hilft!

stfighter01

Mi, Mai 24, 2006 22:13
Antworten mit Zitat

btw eine anregung.

man muss ja nicht das ganze terrain auf einmal laden, man ein flache terrains erstellen und mit modifyterrain die höhen setzen.
die kann man entweder laufend generieren od. aus einer datei streamen.

Denken hilft!

	Bob	Mo, Mai 29, 2006 23:26 Antworten mit Zitat
Hi, war ein paar tage in Urlaub deshalb melde ich mich jetzt erst wieder. Zitat: Der Clamping Fehler ist bei mir auch aufgetaucht, und hab es korrigiert (Dank an Bob & Dreamora), allerdings verbleibt eine kleine Linie wie man im Bild sieht, egal ob als Image, Texture oder Brush geladen. Hab schon an jeder Ecke +/- 1 probiert, nix hilft. Habe mich nun mittlerweile sehr intensiv mit der Problematik befasst und komme zu folgendem Ergebniss. Die noch immer sichtbren Linien trotz UV Clamping (Texturkoordinaten verschieben bringt gar nichts) liegen einzig und allein an den VertexNormalen. Bei meiner MeshTileEngine ist es so das sich die Geometrie teilweise überdeckt. Der Befehl UpdateNormals ist dabei aber leider nicht zu gebrauchen weil dann dieser Effekt zustande kommt. Habe mittlerweile diverse Berechnungen angestellt, Stichwort Kreuzprodukt, um die Normalen an den Kanten richtig zu berechnen. Leider alles ergebnisslos. Ich bin sogar soweit gegangen an der Stelle der Überlappung der Meshes die Normalen von Mesh 1 auf Mesh 2 zu kopieren. Das Ergebniss ist ein ähnliches wie vorher auch. Die Kanten sind danach zwar in Ordnung (was die Theorie bestätigt) allerdings unterscheiden sich die Normalen, je nach Geländeaufbau, dann wieder zu stark von den nachbar Normalen. Zu Testzwecken einfach mal alle Lichter ausser Ambientlight ausschalten. Dann wirst du feststellen das alles genau passt. Viel Erfolg noch.
Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

Bob

Mo, Mai 29, 2006 23:26
Antworten mit Zitat

Hi,

war ein paar tage in Urlaub deshalb melde ich mich jetzt erst wieder.

Zitat:

Habe mich nun mittlerweile sehr intensiv mit der Problematik befasst und komme zu folgendem Ergebniss.

Die noch immer sichtbren Linien trotz UV Clamping (Texturkoordinaten verschieben bringt gar nichts)
liegen einzig und allein an den VertexNormalen.
Bei meiner MeshTileEngine ist es so das sich die Geometrie teilweise überdeckt. Der Befehl UpdateNormals ist dabei aber leider nicht zu gebrauchen weil dann dieser Effekt zustande kommt.
Habe mittlerweile diverse Berechnungen angestellt, Stichwort Kreuzprodukt, um die Normalen an den Kanten richtig zu berechnen.
Leider alles ergebnisslos.
Ich bin sogar soweit gegangen an der Stelle der Überlappung der Meshes die Normalen von Mesh 1 auf Mesh 2 zu kopieren.
Das Ergebniss ist ein ähnliches wie vorher auch. Die Kanten sind danach zwar in Ordnung (was die Theorie bestätigt) allerdings unterscheiden sich die Normalen, je nach Geländeaufbau, dann wieder zu stark von den nachbar Normalen.

Zu Testzwecken einfach mal alle Lichter ausser Ambientlight ausschalten. Dann wirst du feststellen das alles genau passt.

Viel Erfolg noch.

Er soll an den Spielen teilnehmen bis er spielend stirbt. MCP - TRON

	LaiKiam Betreff: Schatten knicken?!?	Mi, Jun 07, 2006 15:38 Antworten mit Zitat
Hi an alle, nach ein paar Tagen coden bin ich etwas weiter, Dank für die Hilfe und Ideen bisher, man lernt nie aus ... Alle Probleme sind bisher gelöst (Cracks und T-Junctions waren nicht ganz trivial, uff..), allerdings bräuchte ich wieder mal den einen oder anderen Denkanstoss. Die Schatten werden jetzt doch als Meshschatten dargestellt. Allerdings nehme ich eine Bitmap und ein Rechteck aus 8 Polygonen: Bisher funktioniert das auf horizontalen Flächen sehr gut, allerdings wird der Schatten an Geländekanten abgeschnitten (ist ja auch Logo): Bisher habe ich das Schattenmesh einfach kopiert und die Handles davon in einem Typefeld abgespeichert. Jetzt die Frage: Um den Schatten an Kanten umzubrechen, ist es vorteilhafter nach der Terrainerstellung diese Meshes einzeln abzuspeichern und beim initalisieren zu laden oder statt dessen die Höhen der Eckpunkte im Type mit abzulegen und die Vertices jedes Schattenmeshes beim initialisieren einzeln zu verschieben? Wer hat sowas schonmal probiert oder gibt es eine bessere Idee? LaiKiam Axo, ich habe den alten Thread 'aufgewärmt' damit man den Fortschritt sieht, sonst denkt noch einer, irgendwelche Tips versacken im Nichts... Hier mal eine Fernsicht mit Sonne und Schatten...

LaiKiam

Betreff: Schatten knicken?!?

Mi, Jun 07, 2006 15:38
Antworten mit Zitat

Hi an alle,
nach ein paar Tagen coden bin ich etwas weiter, Dank für die Hilfe und Ideen bisher, man lernt nie aus Wink

...

Alle Probleme sind bisher gelöst (Cracks und T-Junctions waren nicht ganz trivial, uff..), allerdings bräuchte ich wieder mal den einen oder anderen Denkanstoss. Die Schatten werden jetzt doch als Meshschatten dargestellt. Allerdings nehme ich eine Bitmap und ein Rechteck aus 8 Polygonen:
user posted image

Bisher funktioniert das auf horizontalen Flächen sehr gut, allerdings wird der Schatten an Geländekanten abgeschnitten (ist ja auch Logo):

Bisher habe ich das Schattenmesh einfach kopiert und die Handles davon in einem Typefeld abgespeichert. Jetzt die Frage: Um den Schatten an Kanten umzubrechen, ist es vorteilhafter nach der Terrainerstellung diese Meshes einzeln abzuspeichern und beim initalisieren zu laden oder statt dessen die Höhen der Eckpunkte im Type mit abzulegen und die Vertices jedes Schattenmeshes beim initialisieren einzeln zu verschieben?
Wer hat sowas schonmal probiert oder gibt es eine bessere Idee?

LaiKiam

Axo, ich habe den alten Thread 'aufgewärmt' damit man den Fortschritt sieht, sonst denkt noch einer, irgendwelche Tips versacken im Nichts...
Hier mal eine Fernsicht mit Sonne und Schatten...

Gehe zu Seite Zurück 1, 2

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Mal wieder Terrain...

Betreff: Schatten knicken?!?