Problem importing heightfield map to starter.fps
by Mike DuVall · in Torque Game Engine · 11/13/2006 (10:28 am) · 10 replies
I'm using a fresh install of Torque 1.5. If I go into starter.fps and import a heightmap, the actual terrain created is not properly centered. If I do exactly the same thing with starter.racing, it works just fine.
I've tried this with several heightmaps and I always get the same result: Works perfectly in starter.racing but get's un-centered in starter.fps.
What's wrong? Can anybody help me?
I've tried this with several heightmaps and I always get the same result: Works perfectly in starter.racing but get's un-centered in starter.fps.
What's wrong? Can anybody help me?
About the author
#2
11/14/2006 (1:19 pm)
The terrain is an object just like any other--if you dont' like where it is positioned, move it via setTransform (or just change it's "location" in the mission file).
#3
11/15/2006 (11:11 am)
I've moved on from this since I have a workaround, but my recollection was that I went through both the starter.fps and starter.racing and made all the parameters of the terrain the same(including position) before importing, and that this didn't fix the problem. So yes, I guess I could still monkey around with terrain location after the import of the heightmap, but in my opinion that's just a hack/workaround and doesn't explain the issue. The heightfield has everything exactly centered and where it should be. If I have to monkey with the terrain location afterward it seems difficult (though not impossible) to get it recentered exactly perfectly. At any rate, since I did change the terrain positions of both starter kits to be the same yet still got different results, I'd say this still doesn't explain the different results.
#4
Since the terrain is the basis of your world, it almost by defintion is the center of your world---what exactly isn't "centered"?
11/15/2006 (12:43 pm)
Recentered on what exactly?Since the terrain is the basis of your world, it almost by defintion is the center of your world---what exactly isn't "centered"?
#5
1. Pick your favorite heightmap .png file.
2. Go into starter.racing and import that heightmap.
3. Then go into the Mission Area editor and you will see that the terrain heightmap was imported exactly aligned as it appeared in the .png heightmap file. (I'm assuming you know the trick for making the Mission area editor properly update and reflect the current heightmap after importing one)
4. Now do exactly the same thing but with starter.fps. You will see that the terrain as it appears in the Mission Area editor will be shifted and not properly centered. For example, if the heightmap basically had a bowl shaped circle exactly in the center, in starter.fps this bowl is shifted upward and to the right.
At any rate, I don't know if this is a bug or something else that explains this different behavior.
-Mike
11/15/2006 (1:30 pm)
The best way to see what I'm talking about would be to just go try this experiment:1. Pick your favorite heightmap .png file.
2. Go into starter.racing and import that heightmap.
3. Then go into the Mission Area editor and you will see that the terrain heightmap was imported exactly aligned as it appeared in the .png heightmap file. (I'm assuming you know the trick for making the Mission area editor properly update and reflect the current heightmap after importing one)
4. Now do exactly the same thing but with starter.fps. You will see that the terrain as it appears in the Mission Area editor will be shifted and not properly centered. For example, if the heightmap basically had a bowl shaped circle exactly in the center, in starter.fps this bowl is shifted upward and to the right.
At any rate, I don't know if this is a bug or something else that explains this different behavior.
-Mike
#6
Which is why I said slide the terrain off using setTransform() so it's not an issue anymore.
11/15/2006 (2:35 pm)
It's just that two missions were created originally with different offsets from the origin for the terrain.Which is why I said slide the terrain off using setTransform() so it's not an issue anymore.
#7
Calling getTransform() on the TerrainBlock in both starter.racing and starter.fps returns exactly the same thing: "-1024 -1024 0 1 0 0 0"
If what your saying is true, they ought to return differnt results, shouldn't they? Or am i misunderstanding what you are saying?
11/15/2006 (3:04 pm)
I guess I'm not clear what you mean when you say that starter.racing and starter.fps were created with "different offsets from the origin for the terrain".Calling getTransform() on the TerrainBlock in both starter.racing and starter.fps returns exactly the same thing: "-1024 -1024 0 1 0 0 0"
If what your saying is true, they ought to return differnt results, shouldn't they? Or am i misunderstanding what you are saying?
#8
The two kits were never put together to be "terrain swappable", and no consideration was made for doing so.
When one level was made, the terrain was put together by using the built in terrain terraformer tools, and scenery objects placed appropriately. At a much later time, starting from scratch, the same was done for the second starter kit.
As far as I am aware, neither used imported heightfields, and if you're imported heightmap based terrain is offset, then use setTransform() to adjust it, or more useful: construct your scene around your terrain.
Other than as a learning excersize, you'll want to be manually placing all of your objects anyway for your game...most wind up removing all the objects in the scene and starting from scratch for a new level in any case, and especially when using totally custom terrains.
11/15/2006 (3:35 pm)
I think you are reading too much into a relatively basic scenario honestly.The two kits were never put together to be "terrain swappable", and no consideration was made for doing so.
When one level was made, the terrain was put together by using the built in terrain terraformer tools, and scenery objects placed appropriately. At a much later time, starting from scratch, the same was done for the second starter kit.
As far as I am aware, neither used imported heightfields, and if you're imported heightmap based terrain is offset, then use setTransform() to adjust it, or more useful: construct your scene around your terrain.
Other than as a learning excersize, you'll want to be manually placing all of your objects anyway for your game...most wind up removing all the objects in the scene and starting from scratch for a new level in any case, and especially when using totally custom terrains.
#9
11/16/2006 (2:53 am)
Stephen, I think we are fundamentally miscommunicating. Just curious, did you try doing steps 1-4 that I listed above? I think if you did you'd clearly see what I'm talking about. At any rate, I have a workaround so I'd say let's just drop it.
#10
Envision, for example, if your heightmap looked like a huge crater, perfectly centered on the 256 pixel square. Then you import it to starter.fps, and it is now 2/3 of a crater, with the missing 1/3 showing up on the opposite side of the terrain.
I think the ultimate plan for the TBE includes straightfoward and predictable behavior so it will be a more usable tool for more people. I'm not trying to be negative as I love this engine!, but I think this is definitely quirky behavior that should make the bug list.
Stephen, I'm not sure how to try your workaround of using setTransform(), and I see nothing under mission editor that will allow one to move the bitmap once it is imported. Can you clarify? Thanks.
12/17/2006 (10:41 am)
I am also using TGE 1.5 and I am seeing the same thing Mike mentions. The behavior should be to center the png heightmap on the terrain, yet the heightmap is offset, destroying my design, as it stops abruptly and then continues on the far side of the terrain. Envision, for example, if your heightmap looked like a huge crater, perfectly centered on the 256 pixel square. Then you import it to starter.fps, and it is now 2/3 of a crater, with the missing 1/3 showing up on the opposite side of the terrain.
I think the ultimate plan for the TBE includes straightfoward and predictable behavior so it will be a more usable tool for more people. I'm not trying to be negative as I love this engine!, but I think this is definitely quirky behavior that should make the bug list.
Stephen, I'm not sure how to try your workaround of using setTransform(), and I see nothing under mission editor that will allow one to move the bitmap once it is imported. Can you clarify? Thanks.
Torque Owner Mike DuVall
I was able to solve the problem: i copied the the "racing.ter" file from starter.racing to starter.fps, renamed it to stronghold.ter, and now I can import my heightfield map just fine.
I'm still curious if anyone can explain why I had to do this.