Terrain HeightMap problem: I need help please. ?.
Blitz3D Forums/Blitz3D Beginners Area/Terrain HeightMap problem: I need help please. ?.
| ||
| Hi everyone ! Please can you help me? I'm making a terrain with Blitz3D but I have a problem ; I use an Heightmap and the function LoadTerrain (). first, I have tried the following bitmap (.bmp) as Heightmap and it works fine : here is a ".jpg" snapshot of the heightmap that is working (the original is in ".bmp" format):  - - here is a ".jpg" snapshot of the heightmap that is not working (the original is in ".bmp" format):  - - -Now, here is direct link to a ".zip" file containing the working HeightMap and the not working HeightMap, for you to test it: http://www.mediafire.com/file/nixewgglvozesh3/Terrain%20HeightMaps.zip - - The problem I have is that I have a HeightMap that works and another that don't work: Please, can you explain why the heightmap doesn't work? And please, can you tell me what I have to do in order to create a working heightmap ? "A heightmaps dimensions (width and height) must be the same and must be a power of 2, e.g. 32, 64, 128, 256, 512, 1024." I know that and this is what I did. Last edited 2011 |
| ||
| Could you post your code that calls the LoadTerrain() functions, or at least what about the heightmap is "not working"? Otherwise, it's difficult to know where to start ;) |
| ||
| I don't think it is the heightmap that doesn't work. Testing it with the LoadTerrain example seems to work fine: |
| ||
| Try vertically scaling the terrain (after loading the second heightmap), maybe the height-differences are too small to see without scaling the terrain. |
| ||
| I remember a while back I had an issue where certain Terrain functions causing MAVs if they weren't used after a RenderWOrld call... or something like that. Maybe this is happening? There's no reason a heightmap itself should cause any kind of problem. |
| ||
hi @Malice, I have discovered that the following code works with both images, but my program still doesn't work. (just put the heightmap in the program's directory):
Graphics3D 640,480
camera = CreateCamera ()
V_Terrain_1_E = LoadTerrain ("working heigthmap.bmp")
TerrainShading V_Terrain_1_E,True
ScaleEntity V_Terrain_1_E,1.0,40.0,1.0
Repeat
Locate 0,0
Print TerrainHeight# ( V_Terrain_1_E, 10, 10 )
;Print ligne1$
;Print ligne2$
;Print ligne3$
RenderWorld
Forever
This is really annoying because I can't reproduce the bug I'm having. My program is too long to be posted here, plus, there are several included files in it. simply, in my program, I create a terrain and then position a cube on it and it works with one heightmap and not with the other. Please, I need help ! EDIT: I just found out that the problem is not the heightmap itself : the problem is some terrain related function probably "TerrainY# ()", I'm not sure at the moment but this is probably the problem: "TerrainY# ()" don't work on some terrains or heightmaps ! |
| ||
| So what doesn;t work? Do you get an error message? Or does it just not do what you intend? |
| ||
| @Malice, this is what happens with the wrong heightmap: I get a black screen! this is because the background is black: in fact the cube I've created disappears, the terrain isn't there, and the command "Print EntityZ# ( V_3dObject_A_E, True )" simply return a very strange "NaN": do you know what "NaN" means ? note: I'm now sure it's "TerrainY# ()" that generates the problem ! Because I've tested the program 'with' and 'without' it ! |
| ||
| Nan -> Not A Number Last edited 2011 |
| ||
| Then, come to think about it: you are using TerrainY to position the cube onto the terrain, right? It could be that TerrainY returns a Nan (invalid value) and your character is placed somewhere into oblivian. Does it happen at the start? Then you should print out your characters position before using TerrainY. If it happens at some point later on, you could try the following to create a short version of the problem: 1) Create a key that prints out the box position: if keyhit(57) debuglog "x=" + entityx(box) debuglog "y=" + entityy(box) debuglog "z=" + entityz(box) end if 2) Enable debug, run around, pressing space every once in a while and wait for the black screen to appear. 3) Then, based on the debuglog, find out where the invalid position is 4) Create a separate example, based on the LoadTerrain example, where you position your cube on this faulty location and post this. The example should show a black screen as well. I'm sure there is a way around this bug. Either rounding your characters position before using TerrainY, or some safeguard around the position it uses as an input. |
| ||
| hi where is your camera?, may be, it's above the terrain in one map and below in the other, if your camera is below the terrain you simply will not see it. Are you using collisions?, make shure the Cube is above the terrain and plus some offset, if not, the collision system may cause a collision/response in the first UpdateWorld and send the cube to an incorrect position, other than the one you like. I remember some time ago my camera flying like a rocket far far away (+z axis). Juan |
| ||
Graphics3D 640,480
camera = CreateCamera ()
V_Terrain_1_E = LoadTerrain ("working heigthmap.bmp")
TerrainShading V_Terrain_1_E,True
ScaleEntity V_Terrain_1_E,1.0,40.0,1.0
Repeat
Locate 0,0
Print TerrainHeight# ( V_Terrain_1_E, 10, 10 )
;Print ligne1$
;Print ligne2$
;Print ligne3$
RenderWorld
Forever
I may be wrong here, but isn't this tryiong to check the terrain height at a location that is OFF the terrain? The terrain was scaled to 0.l x 0.1 of its size (X and Z) then you're checking the height at location 10,10 (X and Z) Also, as you're not using the back buffer, rendering might be problematic, I'd recommend setting the BackBuffer and using Flip command. Lastly, JUST IN CASE, add in a Renderworld earlier.
Graphics3D 640,480
SetBuffer BackBuffer()
camera = CreateCamera ()
MoveEntity camera,0,10,0
V_Terrain_1_E = LoadTerrain ("heightmap.bmp")
RenderWorld
TerrainShading V_Terrain_1_E,True
ScaleEntity V_Terrain_1_E,10.0,40.0,10.0
RenderWorld
Repeat
UpdateWorld
RenderWorld
Text 0,0, str(TerrainY(V_TErrain_1_E,EntityX(camera,True),EntityY(camera,True),EntityZ(camera,True)))
;Text 0,20, ligne1$
;Text 0,40, ligne2$
;Text 0,60, ligne3$
Flip
Forever
|
| ||
| hi everyone ! I've decided to post the full program for you to see what's wrong, here it is: http://www.mediafire.com/file/wy6y4b0afgm0n84/Ball%20-%20Blitz3D%20Problem.zip - - explanations: the main program to be executed is : "_prog-PRO.bb". -when you run the program, you get a black screen and in the top left corner you can read: "NaN NaN" in fact, the first line should print the Angle of terrain at the player coordinates. And the second line should print "Z" coordinates of the player. - The problem is that, normally, you should see a white shaded terrain and a cube on it, that you can move using "up key" (arrow key). But because of a strange error you get a black screen. - -In order to make the program work normally, you have to change: -line #129, in "F_fonctions1.bb": replace "RotateEntity V_Work_Entitee_B_E,0.0,V_CameraY_F+90.0,0.0" with "RotateEntity V_Work_Entitee_B_E,0.0,V_CameraY_F,0.0" -This shows that there is a bug with Blitz3D, in my opinion, because if you don't replace line #129 you can change the heightmap and it will work normally, (there are some heightmaps that works and some others that don't): -at line #217, in the same file, replace "V_Terrain_1_E = LoadTerrain ("Bin\Terrain\" + "not working heightmap.bmp")" with "V_Terrain_1_E = LoadTerrain ("Bin\Terrain\" + "working heightmap.bmp")". - -What do you think? should I post in the bugs report section ? I think I will report the bug. I've tried without success to reproduce it in another short program. Last edited 2011 Last edited 2011 |
| ||
| I took a look at your code and... well, I have no idea, that's why I didn't chime in with anything earlier (my opinion? Don't use Blitz terrains at all - use mesh terrains. That way you don't have to suffer dynamic LOD). However... I mean this is the best possible way and wish to be constructive, but: PLEASE, for the sake of your project's organisation, learn how to use 1) Types and 2) Locals! Using a global for anything is considered bad form and makes code more difficult to read, but we usually allow and overlook it for things that are truly "global" in nature (for the sake of brevity). But why on Earth are you using Globals for everything? None of your functions even take parameters... which means for all practical purposes your code doesn't even use functions, only Gosubs! I'm sorry to rant, and I do respect that it's your right to write code however you see fit... but it's really, really hard (at least for me) to actually read this code and see what's going on! Last edited 2011 |
| ||
In F_fonctions1.bb, about line 24, there is this instruction:MoveEntity V_Work_Entitee_A_E,V_Vitesse_Z_F,0,V_Vitesse_Actu_F If I remove that line, the program works well. When I use DebugLog on that line, and I check the values, I see that V_Vitesse_Z_F = Infinity Moving your character with Infinity steps results in a point that is way beyond the terrain limits. That would explain why TerrainY doesn't work. This value is calculated in Function f_Apports_Joueur(). There is a division, either: V_Apports_Z_F = ( Abs ( V_Inclinaison_Z_Terrain_F / 1200.0 ) / V_Duree_TOTAL_E ) * 17 or V_Apports_Z_F = ( Abs ( V_Inclinaison_Z_Terrain_F / 1200.0 ) / V_Duree_TOTAL_E ) * 17 I think that V_Duree_TOTAL_E is zero at that point, resulting in Infinity. So, right before the line that says: ; Apports latéral; Use this: If V_Duree_TOTAL_E < 0.1 Then V_Duree_TOTAL_E = 1 It will prevent the divison by zero which results in infinity. Last edited 2011 |
| ||
| hi everyone ! I found a solution for my program, thanks to @Warner: I've added the following line of code to the main loop of the program (in "F_Deroulement.bb": If V_Duree_TOTAL_E < 1 Then V_Duree_TOTAL_E = 1 I did this to prevent a possible division by zero. Although I did everything to prevent the variable "V_Duree_TOTAL_E" from being equal to value below "16.6" ! With this fix, everything works as expected. If I encounter further problems I will let you know as you are very helpful ! I would like to thank everyone for your help, especially @Warner because he/she helped me to figure out the solution ! Last edited 2011 |
| ||
| hi, everyone ! I want to make a good looking terrain but i'm using "LoadTerrain" and there is the "LOD" feature enabled: -is it possible to disable "LOD" ? -is it possible to reduce the LOD effect (always changing terrain...) ? I don't think so... So, is there an alternative, maybe using a mesh ? -but if I use a mesh, how will I get the "Ground height" of the terrain ? -And how will I get the "X", "Y" and "Z" size of the terrain ? The "LOD" feature is special to me: it don't look very good, in my opinion and the player see the terrain changing strangely... So I would like to know if there is an other solution without the LOD (or something less visible)... |
| ||
| hi one thing you should do is give the mesh an EntityPickMode mesh,2 and then do a LinePick in the -z direction, then test PickedY() LinePick x,y,100,0,0,z-200, asuming that +100 is higher than any mountain in your mesh... to get the scale use: meshwidth, meshheight and meshdepth with the x,y,z scale if you use ScaleEntity mesh,x,y,z Juan |
| ||
| There's a few things you can do with Terrains to make them smoother or reduce the effect of morphing and pop-up. None of them are pareticularly wonderful on their own, best results rely on the detail of the textures, use of fog and whatever other objects are placed aroundto give a depth of field impression. Have a look at these commands, though, especially the TerrainDetail, setting the third parameeter to False will disable the vertex morphing: TerrainShading myTerrain,bEnable TerrainDetail myTerrain,nLOD,bLODMorphing |
| ||
| Here's a drop-in alternative: http://www.blitzbasic.com/Community/posts.php?topic=84809 Uses static meshes so there should be no LOD problems. |
   |