www.quadsoftware.com
FAQ  FAQ   Search  Search   Memberlist  Memberlist   Usergroups  Usergroups
Register  ::  Log in Log in to check your private messages


Post new topic  Reply to topic
 Exporting .RAW for import into L3DT « View previous topic :: View next topic » 
Author Message
AD_Dennis
PostPosted: Tue Feb 17, 2009 12:28 am    Post subject: Exporting .RAW for import into L3DT Reply with quote



Joined: 02 Apr 2008
Posts: 32

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 intervals running horizontally across the terrain.

The General Export routine in Grome assumes that heightmaps are size+1. To correct the problem make the following change to set the export code to use the actual terrain size make change the two indicated lines in exporter.cpp:

Code:

t_error cGeneralExport::_DetermineOutputInfo(t_bool show_msg, HWND hWnd)
{
   // Determine the heightmap raw dimensions.
   uint hm_width = 0;
   uint hm_height = 0;
   if(_hm_sampling_x)
      hm_width = (uint)gRoundFloatToInt((_terrain_max.x - _terrain_min.x) / _hm_sampling_x);
   if(_hm_sampling_z)
      hm_height = (uint)gRoundFloatToInt((_terrain_max.z - _terrain_min.z) / _hm_sampling_z);
   _hm_width = hm_width;// + 1; // Add one texel.  <== Remove the '+1;'
   _hm_height = hm_height;// + 1;               <== Remove the '+1;'

   // Determine the opacity masks sizes.
   if(_param_mask_upp)
Back to top
View user's profile Send private message
ALicu
PostPosted: Tue Feb 17, 2009 7:55 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi Dennis,

I've tried to replicate your issue but with no luck. I've created 2 by 2 zones of 256 tiles each, with 10 units per tile. Then exported an raw with 10 units resolution (so I've got a 513 by 513 raw). There are no zero height lines in my raw (I can see it opened in Photoshop).

Basically when you have 512 by 512 tiles you have 513 by 513 vertices. The raw is sampled in each vertex so you get 513 by 513 height values. Also many engines require power of two + 1 for the raw sizes. Engines that require power of two need to have this image rescaled first. Maybe L3DT editor also requires power of two. Can you try to export as 513 and then rescale to 512 to see if the problem is still there.

Also can you send me (you can use licu at quadsoftware.com) a sample export with this problem present? Also please tell me the exact Grome scene size, number of tiles, units per tile and the parameters you've used for export. Maybe there is a floating point issue that cause the heightmap size to be one size too much.

Thank you,
Adrian L.
Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Wed Feb 18, 2009 1:21 am    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

Alicu, I have tried smaller terrains and they seem to import correctly. The problem seems to be the larger terrains. I tried a small terrain consisting of four 513 x 513 zones in a 2 x 2 arrangement. This was exported using the General Large Exporter plugin in the raw format and imported into L3DT using an overall size of 1025 x 1025 and it worked fine. I've sent you a link to download the full size file.

Edited to remove picture links - see next post.


Last edited by AD_Dennis on Wed Feb 18, 2009 2:18 am; edited 1 time in total
Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Wed Feb 18, 2009 2:17 am    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

Alicu, The raw file output by the standard plugin produces a file that is correctly sized for a 4097 x 8193 16 bit raw file (67,133,442 bytes). As you suggested it appears that it is correct. When this is imported into L3DT using the expected size (4097 x 8193) it produces the following heightmap:



If you change the "y" axis size to 8192 when importing (with 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 for the "y" height produces:



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 also imports correctly. What is odd is that small files work fine. So it appears that L3DT is doing something unexpected during the import. I've posted this info over on the L3DT forums too. You can ignore the link to the raw file I sent to you.
Back to top
View user's profile Send private message
ALicu
PostPosted: Wed Feb 18, 2009 10:00 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hello,

As you've said too, I can see no problem with the heightmap. I believe that is the L3DT which doesn't like non-power-of-two textures. Let me know if you find anything else about this issue.

Regards,
Adrian L.
Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Sat Aug 15, 2009 6:46 pm    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

This has continued to be a problem. Exported terrains have zero height cuts running across them. In Grome the terrain does not show any evidence of this feature. It is visible in both L3DT and TGEA. Here is the latest example:



512 rows from the bottom of the image there is a row that is a constant 0 meters in height. In Exporter.cpp the value of hm_val is zero for the entire row at R=512.

float hm_val = terrain_editor->GetHeight(curr_hm_x, curr_hm_y);

My initial impression was that this was an error due to round off in the value of curr_hm_y since it is type float. After evaluating this for a while this doesn't appear to be the case.

The exporter appears to be handling this correctly and Grome appears to be returning a height of zero even though it shouldn't.

Am I missing something?
[/img]
Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Sat Aug 15, 2009 9:10 pm    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

I may have been wrong in concluding that this isn't a round-off error problem. The following code eliminated the cut in the terrain.

Quote:

float hm_val = terrain_editor->GetHeight(curr_hm_x, curr_hm_y);
if(hm_val == 0.f)
{
float hm_val1, hm_val2;
hm_val1 = hm_val2 = 0.f;
hm_val1 = terrain_editor->GetHeight(curr_hm_x, curr_hm_y - row_height/10.f);
hm_val2 = terrain_editor->GetHeight(curr_hm_x, curr_hm_y + row_height/10.f);
if(hm_val1 != 0.f) hm_val = hm_val1;
if(hm_val2 != 0.f) hm_val = hm_val2;
}


Here is the corrected terrain:

Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Sun Aug 16, 2009 1:16 am    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

Here is the updated heightmap export code:
Code:

      if(param_hm_export_as_raw)
      {
         uint hm_lines_no = hm_lines_per_row;
         if(R == rows_no) // Last additional row (only for heightmap), get only one line.
            hm_lines_no = 1;
         
         const uint last_column = _hm_width - 1;

         for(uint L=0; L<hm_lines_no; L++, curr_hm.y -= _hm_raw_sampling_z)
         {
            curr_hm.x = _terrain_min.x + _hm_raw_sampling_x / 100.f;   //bias on the high side to insure we're in the zone

            float curr_hm_y = ((float)R*_terrain_max.z-(float)(R-(int)rows_no)*_terrain_min.z)/(float)rows_no;   //Interpolate our world coordinate from our row
                                                                                       //this minimizes cumulative round-off error
            if(R == 0 && L == hm_lines_no-1) // Last row (from below).
               curr_hm_y += _hm_raw_sampling_z * 0.01f; // Bias the sampling position inside the zone to avoid floating point rundup errors.

            // Gather data in rows
            for(uint C=0; C<_hm_width; C++, curr_hm.x += _hm_raw_sampling_x)   //this will usually execute once   
            {
               float curr_hm_x = curr_hm.x;
               if(C == last_column) curr_hm_x = _terrain_max.x - 0.02f * _hm_raw_sampling_x;   // Last column, bias the sampling position inside the zone to avoid floating point rundup errors.

               float hm_val = terrain_editor->GetHeight(curr_hm_x, curr_hm_y);

               if(hm_val == 0.f)      //If hm_val is zero then evaluate a position slightly to each side
               {                  //and then decide if you have a nonzero result
                  float hm_val1, hm_val2;
                  hm_val1 = hm_val2 = 0.f;
                  hm_val1 = terrain_editor->GetHeight(curr_hm_x, curr_hm_y - row_height/10.f);
                  hm_val2 = terrain_editor->GetHeight(curr_hm_x, curr_hm_y + row_height/10.f);
                  if(hm_val1 != 0.f) hm_val = hm_val1;
                  if(hm_val2 != 0.f) hm_val = hm_val2;
               }

               // Limit the value to the computed limits.
               // We can have zero returned by GetHeight when the pick is in a blank area (not occupied by any zone).
               // This zero value can be outside the limits.
               if(hm_val > _terrain_max.y)
                  hm_val = _terrain_max.y;
               else
               if(hm_val < _terrain_min.y)
                  hm_val = _terrain_min.y;

               int32 raw_val = (int16)((hm_val + _hm_raw_bias) * _hm_raw_scale);

               _hm_row[C] = (uint16)raw_val;
            }

            // Write the data to files
            fwrite(_hm_row, sizeof(uint16), _hm_width, hm_raw_file);
         }
      }
Back to top
View user's profile Send private message
ALicu
PostPosted: Sun Aug 16, 2009 10:32 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hmm, I see. I will have to check the exporter myself on Monday once I am back at the office. Thank you for letting me know this issue.

Regards,
Adrian L.
Back to top
View user's profile Send private message
ALicu
PostPosted: Mon Aug 17, 2009 7:20 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Can you send me the scene to test? You can use my email address (licu at quadsoftware.com). If the archive is too big (over 10MB) just send me an email address and i will reply with the data for a FTP account you can use for transfer.

Regards,
Adrian L.
Back to top
View user's profile Send private message
AD_Dennis
PostPosted: Wed Aug 19, 2009 1:01 am    Post subject: Reply with quote



Joined: 02 Apr 2008
Posts: 32

Alicu, the terrain is ~20mb so I sent you an email requesting a link to FTP. Here is a picture of the terrain with the heightmap problem. Note the "wall" to the upper left and the sharp chasm at the lower right.The code presented above has corrected this problem.

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Based on a template by Dustin Baccetti
Powered by phpBB © 2001, 2005 phpBB Group