PnP TerrainCreator - Forum

The PnP TerrainCreator Forum
It is currently Thu Sep 21, 2017 8:42 am

All times are UTC




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 13 posts ] 
Author Message
 Post subject: Gaps between sectors
PostPosted: Mon May 15, 2006 1:38 am 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
I'm using Ogre's paging terrain engine for my project and I can export/import terrain from PNPTC to it, but I'm getting gaps between the sector heightmaps.

I'm exporting using the BMP Heightmap exporter as an 8bit grayscale PNG at 512 pixel size. One problem is exporting as 8bit grayscale, really exports as a 24bit rgb grayscale, but I can work around that.

The problem I have is the exported sector heightmaps have gaps in them. I load up my terrain and see gaps, so I load up the heightmaps in photoshop and where the gaps are, the pixel color values are off by at least 1.

It could be a precision error, but I haven't looked hard enough to know yet. Anyway, as a generic terrain editor, its probably important to have heightmaps exported accurately, for me and future customers.

I'll admit it might be my mistake, but I've checked all my settings, stepped through the code and did heightmap comparisons.

If anyone has any insight or info regarding this, let me know.

Thanks!

-Troy


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 15, 2006 8:23 am 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
Quote:
I'm exporting using the BMP Heightmap exporter as an 8bit grayscale PNG at 512 pixel size. One problem is exporting as 8bit grayscale, really exports as a 24bit rgb grayscale, but I can work around that.


Well, I'm currently using the DX extensions methods for generating the different bitmap file formats. So what I'm doing is: generate the export bitmap in BMP format in memory and afterwards call the DX methods to convert it. The BMP format is 8 bit, so the conversion to 24 bit happens somewhere in the DX methods. I don't know at the moment, if I can find a way around that. If you use the BMP format for export, you will have a pure 8 bit format.

Quote:
The problem I have is the exported sector heightmaps have gaps in them. I load up my terrain and see gaps, so I load up the heightmaps in photoshop and where the gaps are, the pixel color values are off by at least 1.

It could be a precision error...


First of all, how do you export the terrain? Do you export all at once (from the file menu) or sector by sector from the sector's context menu? If you export it by sector, do you use the sector or the terrain height range? If you use the sector height range, you will get gaps and there is no way around it, because the scaling differs for every sector. So you have to use the terrain scaling, if you want to correctly place the sectors next to each other without gaps.

I don't think, this is a precision error, as even such precision errors a deterministic. They will result in the same erroneous value given the same input value. So the question is, is the input value really the same? Which leads me to the next question: Maybe the paging scene manager assumes, that the right most pixel of one page is the same as the corresponding left most pixel of the sector right to it? In this case the export will not work properly at the moment, because it only exports the "pixels" of one sector into a file and naturally the border "pixels" of two neighboring sectors will not be the same! If you take a look at the RAW exporter. This exporter has the possibility of adding an extra value at the right and top most border of the exports, which corresponds to the left/bottom most value of the neighboring sector. If I would add such an option to the BMP exporters too, this might solve your problem. What do you think? Or could you use the RAW export instead? That would give your terrain some extra precision.

The same is true, if you divide one sector into several smaller patches. Every heightmap position is exported only once, so there is no "overlapping".

Quote:
I'm using Ogre's paging terrain engine...


I would be very interested in your results for that export, as I'm currently only using the OGRE mesh format (which is not very good for terrains) and haven't found the time yet to take a deeper look into the paging scene manager exports.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 15, 2006 7:51 pm 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
Ralf wrote:
Quote:
I'm exporting using the BMP Heightmap exporter as an 8bit grayscale PNG at 512 pixel size. One problem is exporting as 8bit grayscale, really exports as a 24bit rgb grayscale, but I can work around that.


Well, I'm currently using the DX extensions methods for generating the different bitmap file formats. So what I'm doing is: generate the export bitmap in BMP format in memory and afterwards call the DX methods to convert it. The BMP format is 8 bit, so the conversion to 24 bit happens somewhere in the DX methods. I don't know at the moment, if I can find a way around that. If you use the BMP format for export, you will have a pure 8 bit format.


Roger that.

Ralf wrote:
Quote:
The problem I have is the exported sector heightmaps have gaps in them. I load up my terrain and see gaps, so I load up the heightmaps in photoshop and where the gaps are, the pixel color values are off by at least 1.

It could be a precision error...


First of all, how do you export the terrain? Do you export all at once (from the file menu) or sector by sector from the sector's context menu? If you export it by sector, do you use the sector or the terrain height range? If you use the sector height range, you will get gaps and there is no way around it, because the scaling differs for every sector. So you have to use the terrain scaling, if you want to correctly place the sectors next to each other without gaps.


I have been exporting each sector via its context menu. I noted the sector versus terrain height range in the code and accounted for that. I mainly use the template scene exporter and the HeightMapBMP tag (can't remember the real name), but I have tried exporting each sector heightmap manually via the BMP heightmap exporter and both generate the same results.

The template scene exporter's heightmap export defaults to using the sector's height range, which is not real useful in a multi sector terrain IMHO, but I have my own version of the plugin that forces use of the terrain's height range.

When I manually export each sector via the BMP heightmap exporter, I make sure and use the terrain height range.

Both methods produce the same results. Sectors that are very close to correct, but with small gaps every so often along the seams. If I use the sector height range, I of course get large gaps since each sector's height range varies.


Ralf wrote:
I don't think, this is a precision error, as even such precision errors a deterministic. They will result in the same erroneous value given the same input value. So the question is, is the input value really the same?


True and I'm not sure.

Ralf wrote:
Which leads me to the next question: Maybe the paging scene manager assumes, that the right most pixel of one page is the same as the corresponding left most pixel of the sector right to it? In this case the export will not work properly at the moment, because it only exports the "pixels" of one sector into a file and naturally the border "pixels" of two neighboring sectors will not be the same!


Nah, it doesn't assume that they are the same pixel, just that the pixels are the same color value. Basically, it lays the pages down flush next to each other. When one side's pixel value is off by 1, it causes a vertical gap.

I've looked at the generated heightmaps in Photoshop and the pixel values are definately off by at least 1 in the areas where gaps appear.
All I have to do is go to one side of the terrain and find where two sectors meet that have a gap. Note the sectors and view the two heightmap corners in extreme zoom in Photoshop. Then use the color picker to check the value.

Ralf wrote:
If you take a look at the RAW exporter. This exporter has the possibility of adding an extra value at the right and top most border of the exports, which corresponds to the left/bottom most value of the neighboring sector. If I would add such an option to the BMP exporters too, this might solve your problem. What do you think? Or could you use the RAW export instead? That would give your terrain some extra precision.

The same is true, if you divide one sector into several smaller patches. Every heightmap position is exported only once, so there is no "overlapping".


Yeah, I was gonna look at moving to the raw file format for the extra precision in the heightmap, but since I was seeing this, I didn't know if I should move on until I knew the cause of these gaps.

I find the raw file format to be a pain to work with since there are multiple variations of it.

Ralf wrote:
Quote:
I'm using Ogre's paging terrain engine...


I would be very interested in your results for that export, as I'm currently only using the OGRE mesh format (which is not very good for terrains) and haven't found the time yet to take a deeper look into the paging scene manager exports.


It works pretty well. I get some terracing in the terrain. This is probably mostly due to the 8bit png format I'm currently using. Moving to 16bit raw files will hopefully make that go away. The paging scene manager's (PLSM2) map splitter tool can output 8bit grayscale png files that don't exhibit this behaviour, but who knows.

Couple of other issues I've run into...

PLSM2's page ordering is top to bottom, left to right. So 0,0 is the top left, then 1,0 is the sector below 0,0. I may have the indexes wrong as I don't have the code in front of me, but you get my drift. Its backasswards.

The terrain origin (0,0) is centered in the terrain. So it moves depending on if you have a 1x1, 3x3 or 9x9 terrain. Generally your terrain's size doesn't change often so once you account for this its fine, but it does make object placement and things like sector origins something you have to think about. This is why I posted earlier about sector origins and relative object positions. Probably would have been easier if the terrain origin in PLSM2 was in a consistent spot like top left or bottom left.

PLSM2 has lots of config options, but not lots of detailed docs. It has a forum which is useful, but the project dev's really need to add some more to the docs. You can run into issues like not having a config option defined or defined right which can cause your app to crash, but without enough info to let you know why. This can mean a lot of unnessecary debugging and researching of what docs and posts there are.

For all its faults though its pretty full featured and can produce some really cool stuff. The community is really good and helpful and and its free..:)

Thanks for the help!

-Troy


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 15, 2006 8:03 pm 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
Quote:
The template scene exporter's heightmap export defaults to using the sector's height range, which is not real useful in a multi sector terrain IMHO, but I have my own version of the plugin that forces use of the terrain's height range.


You're right. I should (and will) add an option to the template for the height range.


Quote:
Nah, it doesn't assume that they are the same pixel, just that the pixels are the same color value.


What's the difference? :)


Quote:
Basically, it lays the pages down flush next to each other. When one side's pixel value is off by 1, it causes a vertical gap.


That's exactly what I meant (at least I think so). It lays them next to each other, but it doesn't connect them to each other. If the bitmaps are exported without the additional overlapping pixel I mentioned, they have to be placed with a distance of one horizontal unit. And in this space the geometry has to created to fill the gap in horizontal and vertical direction. Do you understand what I mean? So adding an extra overlapping pixel will surely solve this problem.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 16, 2006 1:58 am 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
Ralf wrote:
Quote:
Nah, it doesn't assume that they are the same pixel, just that the pixels are the same color value.


What's the difference? :)


To my line of thinking, one is the mesh of each sector ends up sharing the same vertices along the seam and the other is each mesh's vertices are placed at the same position along the seam.

Ogre's paging scene manager works like the second.


Ralf wrote:
Quote:
Basically, it lays the pages down flush next to each other. When one side's pixel value is off by 1, it causes a vertical gap.


That's exactly what I meant (at least I think so). It lays them next to each other, but it doesn't connect them to each other.


Yeah, thats how it works.

Ralf wrote:
If the bitmaps are exported without the additional overlapping pixel I mentioned, they have to be placed with a distance of one horizontal unit. And in this space the geometry has to created to fill the gap in horizontal and vertical direction. Do you understand what I mean? So adding an extra overlapping pixel will surely solve this problem.


There is no horizontal gap, just the vertical gap exists. I already resize the heightmaps by one pixel because PLSM2 requires it. When I checked the heightmaps for differences in color values as described above, I checked before resizing the heightmaps so that wasn't skewing the test.

The problem, and this is not a knock on PNPTC because I like your product, is the exported heightmap. The terrain editor is the generic app here, not any one particular terrain engine. The exported sector heightmap pixels should be the same color values along the respective seams. At least in IMHO.

I'm gonna move to the raw file format to see what that produces. Maybe the extra precision will fix the problem. I suspect if that exporter suffers from the same problem, the gaps will just be smaller..:)

Anyway, thanks and if you think of anything else or need anything, please let me know.

-Troy


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 16, 2006 6:20 pm 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
Believe me. From all what I have heard from you ...


Quote:
Yeah, thats how it works. (not connecting)
...no horizontal gap...
...I already resize the heightmaps by one pixel because PLSM2 requires it....
...The exported sector heightmap pixels should be the same color values along the respective seams....



... adding one overlapping pixel will solve your problem. I'll add this feature.


BTW: moving to RAW will only fix your problem, if you use the "size + 1" feature too. It's definetly no precision problem.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 16, 2006 9:05 pm 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
I successfully exported and then imported the sector heightmaps in raw format, but PLSM2 displays them as flat planes. I've had it do this to me a few times before during other testing and is nearly always a image format problem.

I was too tired to debug it last night, so I'll take a look tonight. I have a few ideas of where the problem is. I prefer using the raw file format anyway since it should give better height resolution.

Anyway, I'll let you know how I make out tonight.

Thanks for all of the work!

-Troy


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 16, 2006 9:56 pm 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
Here is the bitmap exporter with the size+1 option.

I also added the sources for the template exporter to the zip archive, which also supports the size+1 feature (SizePlus1="true"). The color scale height range can now be set with a parameter in the template file too (HeightRange="Sector/Terrain").


Attachments:
size+1.zip [346.28 KiB]
Downloaded 460 times
Top
 Profile  
 
 Post subject:
PostPosted: Wed May 17, 2006 11:19 pm 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
Thanks for the updated exporter. I'll test it out and let you know.

I mentioned that using 16bit files was producing flat planes; well that wasn't exactly right. They were producing very slightly slanted planes in the terrain engine. I looked some more and found the problem.

I'm using the 512x512 pixel WORD raw files with the +1 offset option. My terrain height range is from 0 to 512 meters.

There are two ways to store height values in this range in a raw file. One is to simply take the height value, cast it to a WORD and store it in the file. This is what PNPTC does. The other is to take the height value, calculate it as a percentage of the max terrain height (in my case 512), them times it by the max value of a WORD (65535) and store it in the file. This is what the paging terrain engine raw file importer expects.

As a result, I modified the exporter to export raw files in the format PLSM2 expects. I also had to flip the Y value since PLSM2 expects raw files to be oriented from the top left, not bottom left like PNPTC does.

Anyway, I now can export and then import raw sector heightmaps into PLSM2. This results in much better granularity with no terracing that I can discern. It also sealed all of my seam problems except one. The top row of the 3x3 sector terrain has the small vertical gap as before between it and the middle row. All other seams are ok. I'm sure this is an anomaly with the "image size + 1" stuff, although I'm not sure why I don't see the seam between the middle and bottom row of sectors.

I'll look some more tonight. Once I have this fixed, I should finally have terrain exporting correctly into Ogre + PLSM2.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 18, 2006 4:46 am 
Offline

Joined: Thu Apr 20, 2006 9:44 pm
Posts: 15
I looked some more at that last gap I mentioned in that last post. For some reason, I was getting a small vertical gap on the seam between the top row of sectors and the middle row.

I'm using the scene template height map raw file exporter, so I'm not sure if this applies to the regular raw file heightmap exporter that you can use seperately.

The problem happens in the x/y loop where the height is grabbed and then written to the raw file. In my case, I've modified the plugin to flip the heightmap vertically since PLSM2 expects the raw file in this format. I do this by simply doing something like ...

iPatchSizeWrite-iYPos

... where iPatchSizeWrite is 513, the size of my sectors. (512 + 1) This works fine. However, iYPos and iXPos both get capped by checking to make sure the position index is within the Sector's x and y index range. The code that does this uses Sector.GetMaxXIndex() and Sector.GetMaxYIndex(). This sounds good, but for some odd reason all sectors in my terrain's bottom and middle rows return the value 1023 and the top row returns the value 511. These are the values for Sector.GetMaxYIndex(), I didn't check Sector.GetMaxXIndex() although I'm assuming its the same since they are square. Where it came up with these odd values?..who knows..:)

Why the different sectors return something different? I have no idea since I don't have the source. I think the reason this causes gaps in that seam is the sectors on the top row only have data for the first 511 rows, instead of the 513. PLSM2 doesn't have the data to connect the sectors.

I fixed it by disregarding the use of Sector.GetMaxXIndex() and Sector.GetMaxYIndex() to cap the x and y indexes. This might cause problems later on, but I'm just trying to get it to work right now.

Putting this workaround in fixes the gaps because the data on the last two rows is grabbed.

Anyway, thought I'd post FYI in case it is a bug.

-Troy


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 18, 2006 7:43 am 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
I'm not sure if I ever really tested the combination of FlipY and size+1 for terrains with more than one sector, so there might be some problem. I'll take a look at it this evening.

Please take a look at this thread (http://www.pnp-terraincreator.com/forum/viewtopic.php?t=202). I just recently improved the RAW export with a full scale option, which does exactly what you mentioned.

I have not yet added this option to the template exporter, but it will be no problem.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 18, 2006 11:30 pm 
Offline
Programmierdochfix
User avatar

Joined: Tue Apr 27, 2004 12:53 pm
Posts: 891
Location: Braunschweig
Shouldn't it be iPatchSizeWrite-iYPos-1 ?

Well I added y flipping to the RAW exporter and also added y flipping and full scale to the template exporter (parameters "FlipY" and "FullScale").


Attachments:
flip-y.zip [20.13 KiB]
Downloaded 441 times
Top
 Profile  
 
 Post subject:
PostPosted: Thu May 18, 2006 11:35 pm 
Offline
Graphicanissimus
User avatar

Joined: Tue Apr 27, 2004 9:56 pm
Posts: 252
Location: the other side of the moon
[offtopic]Congratulation to the thousandth post in our forum Ralf 8) [/offtopic]

_________________
Image Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 13 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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 post attachments in this forum

Search for:
Jump to:  
cron