Fehler bei der Interpolation der Terrainkoordinaten

Übersicht BlitzBasic Blitz3D

Neue Antwort erstellen

 

sddsmhr

Betreff: Fehler bei der Interpolation der Terrainkoordinaten

BeitragSa, Jul 28, 2012 23:00
Antworten mit Zitat
Benutzer-Profile anzeigen
Schön, wenn Items unter dem Terrain verschwinden, oder in der Luft hängen... -_-

Screenshot:
user posted image

Code für Testumgebung:
Code: [AUSKLAPPEN]
;BB3Ds Terrain Interpolation Bug (tested version: BB3D V1.106)
;-----------------------------------------------------------

;> feel free to change the 'random_mode'
;and 'invert' vars to get some different
;terrain types...

;> use the steps-parameter for the step size
;of the 'grid'...

;> You should notice how some calculated
;interpolated y-coordinates of the terrain
;are lying under the surface while some other
;calculated coords are lying above of it...

;(note the grid-cubes or move with the red
;sphere over terrain)

;(the wrong interpolation can be critical even
;for a quite smooth terrain, e.g. if you want
;to set some small items on terrain which won't
;be visible in some cases...)

Global random_mode=2 ;valid: 0,1,2
Global invert=1 ;valid: 0,1
Global steps=4

;-----------------------------------------------------------

SeedRnd MilliSecs()

Global set_scrx=800
Global set_scry=600

;### Graphics
Graphics3D set_scrx,set_scry,32,2
SetBuffer BackBuffer()

;### Terrain
Global ter_size=8
Global x_scale=100
Global y_scale=200
Global z_scale=100
Global ter=CreateTerrain(ter_size)
ScaleEntity ter,x_scale,y_scale,z_scale
TerrainDetail ter,10000,1
TerrainShading ter,1
EntityPickMode ter,2

;texture
If FileType("mossyground.bmp") Then
   EntityTexture ter,LoadTexture("mossyground.bmp")
Else
   EntityColor ter,0,64,0
EndIf

If invert Then
   For x=0 To ter_size
      For z=0 To ter_size
         ModifyTerrain(ter,x,z,1.)
      Next
   Next
EndIf

Select random_mode
   Case 0 ;random distort
      For x=0 To ter_size
         For z=0 To ter_size
            ModifyTerrain(ter,x,z,Rnd(0.,1.))
         Next
      Next
   Case 1 ;big hill/valley
      For xp=ter_size/2-1 To ter_size/2+1
         For zp=ter_size/2-1 To ter_size/2+1
            ModifyTerrain(ter,xp,zp,0.5)
         Next
      Next
   Case 2 ;random hills/valleys
      For i=1 To 10
         xp=Rand(0,ter_size)
         zp=Rand(0,ter_size)
         ModifyTerrain(ter,xp,zp,0.5)
      Next
End Select

;'grid'
If steps>0 Then
   For x=0 To ter_size*steps
      For z=0 To ter_size*steps
         cube=CreateCube()
         ScaleEntity cube,2,2,2
         xp=x*x_scale/steps
         zp=z*z_scale/steps
         PositionEntity cube,xp,TerrainY(ter,xp,0,zp),zp
      Next
   Next
EndIf

;### Scene
Global cam=CreateCamera()
PositionEntity cam,ter_size/2*x_scale,200,ter_size/2*z_scale
CameraRange cam,1,5000

Global light=CreateLight()
RotateEntity light,45,0,0

sphere=CreateSphere()
ScaleEntity sphere,2,2,2
EntityColor sphere,255,0,0

HidePointer

;### update stuff
While Not KeyDown( 1 )

   ;### CAMERA MOVEMENT
   ;L-Shift
   If KeyDown(42) Then
      dist=10
   Else
      dist=2
   EndIf
   mxs#=MouseXSpeed()
   mys#=MouseYSpeed()
   ;right MB
   If MouseDown(2) Then
      MoveMouse set_scrx/2,set_scry/2
      If mxs#<>0. Then camyaw#=camyaw#-mxs#*0.2
      If mys#<>0. Then campitch#=campitch#+mys#*0.2
      RotateEntity cam,campitch#,camyaw#,0.
   EndIf
   ;W,A,S,D
   If KeyDown(17) Then MoveEntity cam,0,0,dist
   If KeyDown(30) Then MoveEntity cam,-dist,0,0
   If KeyDown(31) Then MoveEntity cam,0,0,-dist
   If KeyDown(32) Then MoveEntity cam,dist,0,0

   ;### PICK TERRAIN
   CameraPick(cam,MouseX(),MouseY())
   in_pe=PickedEntity()
   If in_pe=ter Then
      in_px#=PickedX()
      in_py#=PickedY()
      in_pz#=PickedZ()
      PositionEntity sphere,in_px#,TerrainY(ter,in_px#,0,in_pz#),in_pz#
   EndIf

   If KeyHit(57) Then
      wf=1-wf
      WireFrame wf
   EndIf

   ;### RENDER WORLD
   RenderWorld

   ;### INFO STUFF
;   Text 0,0,"M - switch mode (current: "+mode+")"
   Text 0,16,"W,A,S,D - Camera Movement (L-SHIFT for faster movement)"
   Text 0,32,"Right Mouse Button + Drag to rotate Cam"
   Text 0,48,"SPACEBAR - wireframe on/off"

   Flip

Wend


By the way... wäre auch schön, wenn die Terrainhöhe nicht auf 255 Stufen begrenzt wäre...
 

bjh

BeitragSa, Jul 28, 2012 23:38
Antworten mit Zitat
Benutzer-Profile anzeigen
hallo,

ich würde dir empfehlen, das terrain ohne lod selbst zu erstellen.
dann sind alle höhen immer richtig.
und man kann dann auch bilder mit allen farbwerten also von 0-16777216 verwenden.

wenn du davon keine ahnung hast, dann könnte ich dir auch nen mapgenerator schreiben Wink
 

sddsmhr

BeitragSo, Jul 29, 2012 0:10
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich kann mir leider kaum Einbußen bei der Performance leisten... Und ich operiere mit Terraingrößen von 256x256 (genau genommen kann der Spieler zwischen 16 bis 1024 wählen, 128 oder 256 sind optimal).

Vielleicht überzeugt mich aber eine Art Benchmark...? Very Happy
 

bjh

BeitragSo, Jul 29, 2012 0:17
Antworten mit Zitat
Benutzer-Profile anzeigen
probiers doch mal aus.

wie groß ist die map und was ist eine benchmark? Wink
 

sddsmhr

BeitragSo, Jul 29, 2012 1:54
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich meine einen Vergleich der Laufzeiten entsprechender Befehle... (ModifyTerrain, TerrainY...) Bspw. ist das Terrain ja nicht einfach nur flach, sondern bekommt noch eine Heightmap übergestülpt. Eine zufällige Modifikation der Terrainhöhe (ModifyTerrain) in jedem Punkt der Terrainmatrix benötigt bei einer Gittergröße von 512 in meinem Fall (2GHz-CPU) bspw. ca. 100ms...

Gut, das findet nur einmalig bei der Kartengenerierung statt. Zur Laufzeit müsste allerdings mindestens noch diverse Male (pro Frame) die Terrainhöhe abgefragt werden, was zusammen mit Interpolation (wenn auch nur linear) ein wenig Rechenaufwand bedeuten dürfte. Und hinzu kommt natürlich auch noch die Frage nach dem TerrainShading und dem LOD...

Hm... aber da gibt es ja immerhin diese Demo von David Bird (Samples\Blitz 3D Samples\birdie\Brush Tiles\tt.bb). Auf der Basis könnte man eigentlich ein wenig herumexperimentieren.

Der Forderung nach Behebung des obigen Bugs tut es natürlich keinen Abbruch. Very Happy
 

bjh

BeitragSo, Jul 29, 2012 7:32
Antworten mit Zitat
Benutzer-Profile anzeigen
wie groß sollte die map sein (in metern)?

ich lade immer vorher alle maphöhen in ein dimfeld.
dann werden die vertices erstellt.

eine veränderung würde dann so aussehen:
BlitzBasic: [AUSKLAPPEN]
map(x,y)=neuer_wert
VertexCoords map_surface,vertex,x,map(x,y),y


ich hoffe man erkennt, was ich zeigen will. Wink
 

sddsmhr

BeitragSo, Jul 29, 2012 23:57
Antworten mit Zitat
Benutzer-Profile anzeigen
bjh hat Folgendes geschrieben:
wie groß sollte die map sein (in metern)?
Öhm... wie misst man Meter in BB3D...? Very Happy

Aber wie gesagt müssten das schon bis zu 256x256 (oder mehr) Tiles sein... Jedes davon 2 Faces... Macht nach Adam Riese ja schon über 130000 Polys alleine für das Terrain... Shocked

Ohne das (recht effiziente) LOD für fernes Terrain dürfte das zusammen mit allen übrigen Objekten (im Schnitt kommen hier ca. 50k-100k Polygone in einer durchschnittlichen Szene vor) fast zur Diashow werden...

Nachtrag: Okay, so übel wird es sicherlich nicht werden. Da wäre ja auch noch CameraFog und/oder CameraRange, so dass ferne Gebiete nicht gerendert werden würden...

bjh hat Folgendes geschrieben:
ich lade immer vorher alle maphöhen in ein dimfeld.
dann werden die vertices erstellt.
Ja, ich hätte auch zuerst an ein 2dim-Array gedacht. Oder ein Graustufen-BMP-File als Heightmap. Apropos...

sddsmhr hat Folgendes geschrieben:
By the way... wäre auch schön, wenn die Terrainhöhe nicht auf 255 Stufen begrenzt wäre...
Im Hinblick auf die Graustufen-Heightmap macht eine Einteilung in 255 Werte wieder Sinn, fällt mir gerade ein... Und Import/Export von Heightmaps ist ja auch bereits implementiert und ein wichtiges Feature... (mit RGB-Farben könnte man natürlich mehr Unterteilungen vornehmen)

bjh hat Folgendes geschrieben:
eine veränderung würde dann so aussehen:
BlitzBasic: [AUSKLAPPEN]
map(x,y)=neuer_wert
VertexCoords map_surface,vertex,x,map(x,y),y


ich hoffe man erkennt, was ich zeigen will. Wink
Joa, das ist halt die Syntax... Ich arbeite derzeit an der Weiterentwicklung eines bereits fertigen Projektes. Und da müssten wirklich ein Haufen Code-Teile geändert werden. Bevor eine InGame-Szene läuft, müssten also erst einmal ein paar Tage Arbeit investiert werden. Und wenn sich dann zum Schluss herausstellt, dass irgendetwas aus prinzipiellen Gründen nicht hinhaut, oder das Spiel plötzlich zur Diashow wird, dann wäre das nicht sehr schön. Insofern wäre ein kleines Benchmark und andere Tests im Vorfeld nicht unklug. Ich versuche gerade das Beispiel von David Bird zu verstehen... Vor allem das Multitexturing beim Terrain ist ja wirklich ein schlagkräftiges Argument!

Toll... da haben wir auch schon das erste Problem... Eine MAV... Auslöser: RenderWorld. Debugging? Vermutlich no Chance... Rolling Eyes

Na mal sehen, ob jemand eine Idee hat...
https://www.blitzforum.de/foru...012#404012
 

bjh

BeitragMo, Jul 30, 2012 11:17
Antworten mit Zitat
Benutzer-Profile anzeigen
also das mit den 256*256*2=131072 polygonen wäre gar nicht so schlimm.
das würde von der performance her gut hinhauen.

das mit der größe in metern meinte ich so, dass du irgendeinen maßstab brauchst.
ich nehm zum beispiel meisten eins in b3d als ein meter.

was ist das eigentlich für ein spiel?
 

Fredko

BeitragMo, Jul 30, 2012 14:22
Antworten mit Zitat
Benutzer-Profile anzeigen
Der MAV wird wohl daher rühren, dass du alle Flächen in einer Surface unterbringen wolltest.
Diese sind aber begrenzt, entweder auf 256² Vertices und/oder 128² Triangles, wieso und warum ... weiß einer der Spezialisten hier bestimmt besser. Razz

Folglich müsstest du die Karte in mehrere Surfaces unterteilen. Diese könnten dann alle in einem Mesh sein, aber das müsste dazu führen, dass diese immer gerendert werden. Entitys dagegen könnte man unterstützend noch verstecken, sollten diese komplett außer Sichtweite sein bzw. effektiv hinter der Kamera sind.

Dennoch würde ich das normale B3D-Terrain empfehlen. Zuletzt hat es auch den Vorteil, dass Kollision direkt enthalten ist, was bei einer eigenen Variante nochmal für Nachdenken sorgen könnten, vor allem wenn man einige Entitys per Hand versteckt, und somit eine Kollisionsvariante (auch wenn mit EntityAlpha 0.0) immer parat halten müsste. Und wenn ich mich nicht vertue, wäre es wohl auch einfacher bei dem B3D-Terrain zu bleiben, da man sonst alle damit zusammenhängenden Befehle finden und ersetzen müsste, McSddsmhr.

Zuletzt zu den verschwindenden bzw. in der Luft hängenden Items: passiert halt, wenn Objekte mit der Mitte auf die Terrainhöhe gesetzt werden. Man müsste also nur den Objektradius zur Höhe dazurechnen, und schön würde man mehr als nur halbe Items sehen. Sonst kann man auch noch die Normale heranziehen, worauf man die Objekte immer senkrecht zum aktuellen Boden stellen könnten, womit sie sich nur noch kaum mit dem Terrain schneiden dürften.
!
 

sddsmhr

BeitragMo, Jul 30, 2012 14:42
Antworten mit Zitat
Benutzer-Profile anzeigen
Bei mir habe ich den Meter auf 20px normiert, und arbeiten tue ich seit geraumer Zeit an der Weiterentwicklung des Source Codes von Stranded II. Hier müsste es eigentlich auch irgendwann mal ein Thema dazu gegeben haben... ja, hier:

https://www.blitzforum.de/foru...hp?t=22965
 

bjh

BeitragMo, Jul 30, 2012 15:12
Antworten mit Zitat
Benutzer-Profile anzeigen
die vertex- und triangleanzahl ist auf 65536 (256*256) begrenzt.

was meinst du mit 20px?
20 einheiten?

stranded2 hab ich schon sehr lange gespielt Wink
vor allem die ext-mod
 

sddsmhr

BeitragDi, Jul 31, 2012 6:46
Antworten mit Zitat
Benutzer-Profile anzeigen
Fredko hat Folgendes geschrieben:
Der MAV wird wohl daher rühren, dass du alle Flächen in einer Surface unterbringen wolltest.
Diese sind aber begrenzt, entweder auf 256² Vertices und/oder 128² Triangles, wieso und warum ... weiß einer der Spezialisten hier bestimmt besser. Razz
Im Thema verrutscht...? Very Happy

https://www.blitzforum.de/foru...hp?t=38848

Fredko hat Folgendes geschrieben:
Dennoch würde ich das normale B3D-Terrain empfehlen. Zuletzt hat es auch den Vorteil, dass Kollision direkt enthalten ist...
Ich war tatsächlich mal auf Terrainkollision umgestiegen... Es zeigte sich dann irgendwann - leider erst nach umfangreichen Änderungen am Code und erst nach einigen Tests - dass der Spieler in seltenen Fällen plötzlich stecken bleibt, wenn er über das Terrain läuft... Confused

Fredko hat Folgendes geschrieben:
Zuletzt zu den verschwindenden bzw. in der Luft hängenden Items: passiert halt, wenn Objekte mit der Mitte auf die Terrainhöhe gesetzt werden. Man müsste also nur den Objektradius zur Höhe dazurechnen, und schön würde man mehr als nur halbe Items sehen. Sonst kann man auch noch die Normale heranziehen, worauf man die Objekte immer senkrecht zum aktuellen Boden stellen könnten, womit sie sich nur noch kaum mit dem Terrain schneiden dürften.
Nö, siehe Code oben... Wink

TerrainY liefert schlicht falsche Werte, die Cubes da oben dienen nur der Illustration.

bjh hat Folgendes geschrieben:
die vertex- und triangleanzahl ist auf 65536 (256*256) begrenzt.
Das ist dann aber eine willkürliche Festsetzung der Obergrenze, oder? An und für sich dürfte ja (je nach Rechenleistung) mehr drin sein.

bjh hat Folgendes geschrieben:
was meinst du mit 20px?
20 einheiten?
20px=20 Pixel, oder 'Einheiten', ja.

bjh hat Folgendes geschrieben:
stranded2 hab ich schon sehr lange gespielt Wink
vor allem die ext-mod
Ach ja... die Extension Mod. Damit hatte ich damals angefangen, als noch der ursprüngliche Autor, bizzl, am Start war... (der Heli, einige Häuserteile uvm. sind bspw. von mir)

BladeRunner

Moderator

BeitragDi, Jul 31, 2012 7:04
Antworten mit Zitat
Benutzer-Profile anzeigen
Zitat:
bjh hat Folgendes geschrieben:
die vertex- und triangleanzahl ist auf 65536 (256*256) begrenzt.
Das ist dann aber eine willkürliche Festsetzung der Obergrenze, oder? An und für sich dürfte ja (je nach Rechenleistung) mehr drin sein.

Das ist die Begrenzung die dir Direct X 7 vorgibt. Als DX 7 entstand war das ja eine echt große Menge und der Kapazität der existierenden Hardware geschuldet.
Da man aber ja selbst prä-DX3 so geile Spiele wie Half-Life entwickeln konnte sollte die Begrenzung dem Spielspass keinen Abbruch tun Wink
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92
 

sddsmhr

BeitragDi, Jul 31, 2012 9:05
Antworten mit Zitat
Benutzer-Profile anzeigen
Nein, ich bekomme mehr hin, mindestens 256+64, bei 384 kommt eine MAV während RenderWorld wobei das aber auch an meiner GraKa liegen könnte (was noch eine alte Radeon X800 Pro ist), welche in letzter Zeit auch bei einigen anderen Sachen herumzuzicken scheint...

Genauer: (256+64)^2*2=204800 Faces (da jedes Tile aus zwei Faces besteht)

BladeRunner

Moderator

BeitragDi, Jul 31, 2012 11:45
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich kann mich nur wiederholen: die Begrenzung an Polygonen pro Surface ist existent und ein "Feature" von DX7 - wenn Du mehr als erlaubt reinpacken kannst verwundert mich das sehr, dann vermute ich allerdings eher einen dirty Hack im GraKa-Treiber oder eine falsche Auszählung deinerseits, denn die Spezifikationen sind da eigentlich eindeutig. Die Positionen der Vertices werden in einer Liste gespeichert welche eben mit einem 16-Bit-Word adressiert wird, mehr als 65536 sind da einfach nicht drin.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92
 

sddsmhr

BeitragDi, Jul 31, 2012 14:03
Antworten mit Zitat
Benutzer-Profile anzeigen
Joa... die Gründe kenne ich natürlich nicht. Hab' die Grenzen anhand David Bird's Brush Tiles (Samples\Blitz 3D Samples\birdie\Brush Tiles\tt.bb) ausgetestet. Dort

Code: [AUSKLAPPEN]
Gridx=32
Gridz=32

durch
Code: [AUSKLAPPEN]
Gridx=320
Gridz=320

ersetzt, sowie weiter unten
Code: [AUSKLAPPEN]
Read track

durch
Code: [AUSKLAPPEN]
track=Rand(1,8)


Insofern könntest du es fix selbst testen, wenn du magst...

Es geht bei mir sogar noch mit Gittergröße 360, dann ist aber auch endgültig Schluss. Wäre interessant zu wissen, ob da tatsächlich die GraKa trickst. Denn in diesem Falle wäre klar von einer Überschreitung des von dir genannten Limits abzuraten.

Neue Antwort erstellen


Übersicht BlitzBasic Blitz3D

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group