L3DT users' community
Large 3D terrain generator

Heightmap corruption while importing to L3DT from Grome

Any and all chit-chat regarding L3DT.

Heightmap corruption while importing to L3DT from Grome

Postby dennis » Tue Feb 17, 2009 12:45 am

I generally use both Grome and L3DT to create terrains which requires the ability to import the terrain into both packages from the other. When attempting to export terrain from Grome and then importing it into L3DT using the .raw format I ran into a problem where the imported terrain had zero height strips at tile width intervals running horizontally across the terrain. I suppose that is great if you want regularly spaced moats that run across the entire continent...

The solution involves recompiling the General Export plugin to use a heightmap tile of "size x size" instead of "size+1 x size+1". The details are posted at
http://www.quadsoftware.com/forum/viewtopic.php?t=365
dennis
Luminary
 
Posts: 65
Joined: Fri Aug 04, 2006 9:54 pm

Postby Aaron » Tue Feb 17, 2009 9:28 pm

Hi Dennis,

I vaguely recall running into a similar problem a few years ago, possibly with World Machine Pro tilesets. If memory serves, I wrote a plugin to load WM Pro maps and trim the unneeded rows/columns from the tiles. I'm happy to do the same for Grome. Could you send me* a small dataset for testing? (say, a 2x2 set of 513x513 tiles)

Cheerio,
Aaron.

* to aaron@bundysoft.com.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby dennis » Wed Feb 18, 2009 2:10 am

Aaron, The raw file output by the standard (as supplied by quadsoft) plugin produces a raw file that is correctly sized for a 4097 x 8193 16 bit raw file (67,133,442 bytes). When this is imported into L3DT using this size it produces the following heightmap:

Image

If you change the "y" axis size to 8192 then the terrain imports correctly. Using 4096 for the "x" axis produces a skewed terrain as would be expected. Using 8192 instead of 8193 produces:

Image

The mods posted to "correct" the problem creates a raw file with a "y" axis size of 8192 and an "x" axis size of 4096 which imports correctly. What is odd is that small files work fine. The small file that you suggested would work fine. To be clear the original terrain was created in L3DT at 4096 x 8192, exported as raw, imported to Grome for editing, exported as raw and then imported into L3DT so that it could be saved in the appropriate format for use as an overlay.
dennis
Luminary
 
Posts: 65
Joined: Fri Aug 04, 2006 9:54 pm

Postby dennis » Wed Feb 18, 2009 2:11 am

Aaron, The raw file output by the standard (as supplied by quadsoft) plugin produces a raw file that is correctly sized for a 4097 x 8193 16 bit raw file (67,133,442 bytes). When this is imported into L3DT using this size it produces the following heightmap:

Image

If you change the "y" axis size to 8192 (using the same raw file) then the terrain imports correctly. Using 4096 for the "x" axis produces a skewed terrain as would be expected. Using 8192 instead of 8193 produces:

Image

The mods posted to "correct" the problem creates a raw file with a "y" axis size of 8192 and an "x" axis size of 4096 which imports correctly. What is odd is that small files work fine. The small file that you suggested would work fine. To be clear the original terrain was created in L3DT at 4096 x 8192, exported as raw, imported to Grome for editing, exported as raw and then imported into L3DT so that it could be saved in the appropriate format for use as an overlay.
dennis
Luminary
 
Posts: 65
Joined: Fri Aug 04, 2006 9:54 pm

Postby Aaron » Thu Feb 19, 2009 8:45 pm

Hi Dennis,

Okay, this looks like it's just a bug in Grome's exporter when dealing with large files. Is this a safe assumption, or is there anything I should be doing/fixing from my side?

Cheerio,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3696
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby dennis » Fri Feb 20, 2009 2:43 am

Aaron, I honestly don't know where the issue is. It isn't an issue for me since I can import and export between the two packages as needed. At this point I would recommend not worrying about it.
dennis
Luminary
 
Posts: 65
Joined: Fri Aug 04, 2006 9:54 pm

Postby dennis » Sat Nov 14, 2009 3:15 am

Finally found the cause of this problem. It was a round-off error in the Grome exporter. All of the heightmap data used in the Grome exporter, including height and point position, use a float data type. The assumption was that you were evaluating a point just inside of a tile when under certain circumstances you would be evaluating a point just outside. Under these conditions the result was zero height.

The fix is posted http://www.quadsoftware.com/forum/viewtopic.php?t=365. Look at the end of the post for the final code.
dennis
Luminary
 
Posts: 65
Joined: Fri Aug 04, 2006 9:54 pm


Return to General discussion

Who is online

Users browsing this forum: No registered users and 7 guests

cron