TGEA1.7.1 Terrain hightmap also busted

#21 I think I might have a solution. Bear with me.

#22 That would be great. :)

#23 OK, technically 2 solutions.

First Solution:
Create a megaterrain with a 512 pixel png, then delete the other 3 terrains you don't want, take the surviving terrain out of the megaterrain folder and delete that folder. Drop the height of the terrain by -1024 (because megaterrains always get created high).

Solution 2:

1. Get your 256 pixel png. In Gimp, Photoshop, whatever you use, flip it vertically, then offset (58, -27) and save.
2. Boot up Torque mission, go to camera (ALT+C - helps you to stop player falling and it's easier to see), make sure that your terrain has "tile" off (so you can see the very edge of it against the sky) and open "Terraform Editor".
3. Set your min height and height range in General, hit apply.
4. Load your bitmap, then make sure your bitmap is loaded. It will look offset and messed up in the "Heightmap Preview" - ignore this (only the "Mission Area Editor Preview" displays the correct terrain). Hit apply with the bitmap operation selected. Your terrain should now appear.
5. Go into "Mission Area Editor", it should be black or at least unchanged. Go out of edit mode (F11) then back in and it should update the "Mission Area Preview" view. Your bitmap should be there in black and white, exactly as you originally intended.

It might be 1 pixel over-lapping at the edge, if so either alter the offset in your Gimp/PS/image editor or smooth it out with Torque's terrain editor.

Right, that's that, both of these approaches worked for me.

#24 Neat Steve

From what i recall from my cursory exploring the scripts MEGAterrain mission builder option is a tool to simply split a terrain hightmap into 4 terrain mesh chunks. If megaterrain generation do not have the offset problems this would lead me to think it is a slight bug in the scripts...

#25 Checking it out...

Yes, that was the fix for the non-megaterrain heightmap. Thanks!

Now we should be able to find that somewhere in the code and fix it. Where to start...

#26 Guys - I don't have time to work on this right now, but here is something you can try, it's seems likely to be the problem.

In Tools/MissionEditor/Scripts/editors, in Terraformer.ed.cs, find this line:

ETerraformer.setShift( getField(%data,9), getField(%data,11) );

Comment it out, and then add this line in it's place.

ETerraformer.setShift( 0,0 );

#27 Spoke too soon. It gets misaligned at the southwest corner. Tweaking the offset doesn't fix it. It is very slightly misaligned, and if I change it one pixel it breaks the other corner again. :)

Fun stuff!

#28 I'll check that out Jaimi. Thanks.

EDIT: That was a good fix, Jaimi. Now it just looks like it wants to tile my non-tiling heightmap, and so it has a very slight offset at the NE corner. That is probably something with the terrain tiling code. Still digging.

#29 Tools/MissionEditor/Scripts/editors/terraformer.ed.cs

Works great, bitmap aligns edges correctly with mission area preview.
To be pedantic I found it to be 1 pixel off but hey.

note: bitmap still gets vertically flipped, so if "north and south" are real important you'll still have to manually flip your image before terraforming.

#30 Looks like that 1 pixel can't be terraformed away, either. However, if I'm going to use just a single terrain block, then that can probably be hidden. It's far better than it was when this conversation first started. :)

#31 Steve's work-about(megatearrains way) also allows me to get terrains imported into 1.8. Its a hassle but will work for now. I hope an official FIX is posted sometime very soon.

#32 @Steve - filename fixed. Sorry!

#33

Quote:
bitmap still gets vertically flipped, so if "north and south" are real important you'll still have to manually flip your image before terraforming.

@Steve - I'm not seeing this. I'm using TGEA/AFX 1.71, so perhaps this was fixed or changed from this version. Does your LoadGreyScale function look like this?

bool Terraformer::loadGreyscale(U32 r, const char *filename)
{
   Heightfield *dst = getRegister(r);

//   return ResourceManager->findFile(filename);
   GBitmap *bmp = (GBitmap *) ResourceManager->loadInstance(filename);
   if (!bmp)
      return false;

   for (S32 y=0; y<blockSize; y++)
      for (S32 x=0; x<blockSize; x++)
      {
         U8 *rgb = bmp->getAddress(x,(blockSize-1)-y); 
         // compute the luminance of each RGB
         dst->val(x, y) = ((F32)rgb[0]) * (0.299f/256.0f) +
                          ((F32)rgb[1]) * (0.587f/256.0f) +
                          ((F32)rgb[2]) * (0.114f/256.0f);
      }

   delete bmp;
   return true;
}

This line is the one that flips it on load:

U8 *rgb = bmp->getAddress(x,(blockSize-1)-y);

#34 Ok, so I tested this further. I made a totally flat heightmap (solid black) and placed one 1 white pixel marker at the top left & top right corners, and two at the bottom center. I then placed a white letter N, E, S, & W that was 8 pixels high & repeated in each appropriate direction. Using this test heightmap I found that the offset is no more than 1 pixel off in a Left-Right and Top-Bottom direction.

So there is an offset. Of one pixel. Which is still a far cry from a
"busted" heightmap import. I think that what is actually happening is that even though the heightmap texture is 256x256 or 512x512 the terrain heightfield renderer only takes the first 255 or 511 pixels into account when it creates the terrain block itself. The last row/column of coordinates would then be used to merge the edges together.

The extreme overlap/offset that other people are seeing does not happen to me. I've ported dozens of maps from TGE into TGEa and not seen any problems other than this one pixel offset, and for me that one pixel is not an issue. Chalk it up to another one of those little inconsistencies in Torque that varies from one user to another.

#35 Michael, I guess so, considering I posted screenshots of the huge offset I was seeing. :)

Anyway, I think we're well on our way toward a good fix. Thanks to Caylo for bringing it up, and thanks to everyone else for providing input.

#36 If it is not working correctly, then is it not busted? I have tested this 'busted' terrain hightmap problem on 4 other PC's and two laptops making sure it was not an issue with hardware/OS or other variables, I like to fully evaluate a problem before i define it as a problem. I also asked another person here to follow the video tutorial and they also had the same problem using there computer.

Michale, i would expect your testing environment, or testing methodology is somehow different then a standard TGEA1.7.1 fresh install if your not able to recreate the same problem i have witnessed on multiple differently configured PC's. Did you test with a fresh unchanged EXE and script files from a TGEA1.7.1? Did your tests follow the outlined steps from the above linked video tutorial?

Im only asking because if indeed Torque is inconsistent from user to user, then i want my money back! A game engine with inconsistencies is not a reliable game engine is it? (inconsistencies excluding flaky OS, outdated drivers and environmental variables outside the control of the engine itself of course)

#37 Ok, I got to thinking about this. Why was I consistently able to import terrains without the bizarre offset and yet others couldn't? The only difference I could think of was that I was using a different set of scripts -- yes Caylo you were right, I don't use the standard scripts. The stock scripts are just an example of how to start a game right? I like to think that I have something better than the stock scripts, so maybe I inadvertently fixed something that I hadn't known was broken. I don't keep a backup of the stock scripts like I do the source, so I had to reinstall the SDK just to start with a fresh copy. I loaded up the T3D project and tried to import a heightmap. Lo and behold there it was -- that bizarre offset. Hmm, I tried the Stronghold example -- yep there it was again, that damn huge offset! So the problem did exist and I was able to repeat it. Consistently. Sorry for doubting you guys.

I tried my project again just to make sure I wasn't delusional, and guess what? No offset. So what was different?

The New Mission Template. I had been using a custom New Mission Template that had flat terrain and a spawnpoint at the center of the terrain. It seems that the stock New Mission Template has the terrain offset already encoded in the terrain file itself. Thus anytime that you imported a new heightmap the offset would carry over. So you would need to center the terrain under the camera at dead center -- the origin (0, 0), before you import any new heightmaps.

To fix the problem simply edit the newMission.mis file to spawn at the center of the map. Or you could spawn normally and simply position yourself -- the camera -- at the center. Without moving from the center, go to the Terrain Terraformer Editor and in general properties click on Center on Camera. Save your mission and let it overwrite your existing newMission.mis file -- this is your new "centered" template. Reload and import a heightmap. Verify that the offset is gone now. The one pixel offset is still there though and I don't think there is any getting around that, but I didn't try.

If you want it, here is the FLAT New Mission Template that I was using.

#38 Wow neat, that a relief. I was doubting myself for finding so many little bugs and when mentioning them no one else seem to have them.

Myself i used Steve megaterrain work around posted above, went into the C'code and edit it to take an 256x256 hightmap, and am quit happy to be able to import hightmaps into TGEA1.8 now.

Thanks for drilling at it Michael, its exactly that type of persistence on a matter that dont truly effect oneself that makes the GG community better then any of the other engine communitys i have been part of.

EDIT:
Also now knowing what is changed from your scripts vrs stock scripts should give the GG folk a starting point to fix the bug. Its a big help all around.

#39 @Jaimi (morning!)

Yes I have all that code in terraformer.cpp.

I'm using vanilla(ish) TGEA 1.7.1.

--------------

Now when I say I'm seeing something "vertically flipped", what I've realised is that the Y-axis on the "Mission Editor Preview" is orientated down my screen. That way the bitmap in "Mission Editor Preview" appears to have an inverted Y-axis from how I would view the bitmap in an image editor.

And here's a pick to illustrate my initial confusion on orientation.
edit: image

double edit: Actually that does have an inverted Y-axis doesn't it?

#40 Michael, I'm glad that we are all no longer doubting our sanity. Thanks for your persistence. :)

I'll try your fix when I get home. Again, I think that 1-pixel offset may have something to do with the terrain tiling code. It's like you turn off the visible terrain tiling, but it still wants to tile in the background or something. I was poking around in the terraformer code last night. With such a lack of comments, it will take some time to understand how TGEA does terrain.