Fehler bei der Interpolation der Terrainkoordinaten
Übersicht

sddsmhrBetreff: Fehler bei der Interpolation der Terrainkoordinaten |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Schön, wenn Items unter dem Terrain verschwinden, oder in der Luft hängen... -_-
Screenshot: ![]() 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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 ![]() |
||
sddsmhr |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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...? ![]() |
||
bjh |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
probiers doch mal aus.
wie groß ist die map und was ist eine benchmark? ![]() |
||
sddsmhr |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. ![]() |
||
bjh |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 ich hoffe man erkennt, was ich zeigen will. ![]() |
||
sddsmhr |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
bjh hat Folgendes geschrieben: wie groß sollte die map sein (in metern)? Öhm... wie misst man Meter in BB3D...? ![]() 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... ![]() 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.
Ja, ich hätte auch zuerst an ein 2dim-Array gedacht. Oder ein Graustufen-BMP-File als Heightmap. Apropos...
dann werden die vertices erstellt. 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:
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!
BlitzBasic: [AUSKLAPPEN] map(x,y)=neuer_wert ich hoffe man erkennt, was ich zeigen will. ![]() Toll... da haben wir auch schon das erste Problem... Eine MAV... Auslöser: RenderWorld. Debugging? Vermutlich no Chance... ![]() Na mal sehen, ob jemand eine Idee hat... https://www.blitzforum.de/foru...012#404012 |
||
bjh |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. ![]() 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 ![]() 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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
die vertex- und triangleanzahl ist auf 65536 (256*256) begrenzt.
was meinst du mit 20px? 20 einheiten? stranded2 hab ich schon sehr lange gespielt ![]() vor allem die ext-mod |
||
sddsmhr |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Fredko hat Folgendes geschrieben: Der MAV wird wohl daher rühren, dass du alle Flächen in einer Surface unterbringen wolltest.
Im Thema verrutscht...? Diese sind aber begrenzt, entweder auf 256² Vertices und/oder 128² Triangles, wieso und warum ... weiß einer der Spezialisten hier bestimmt besser. ![]() ![]() 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... ![]() 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... ![]() 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?
20px=20 Pixel, oder 'Einheiten', ja.
20 einheiten? bjh hat Folgendes geschrieben: stranded2 hab ich schon sehr lange gespielt 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)
![]() vor allem die ext-mod |
||
![]() |
BladeRunnerModerator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 ![]() |
||
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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) |
||
![]() |
BladeRunnerModerator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. |
||
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group