I'm using the puget textures from the osgdem example (http://www.cc.gatech.edu/projects/large_models/ps.html) to create a terrain. But now my colormap is flipped along the Y-Axis.
At first I thought that it would not be a problem and that I could just transform the texturecoordinates and that it is an "OpenGL uses different coordinate system" related problem. But things are not that easy:
osgdem creates multiple LOD Levels, with an own texture for each tile. Now when the upper right tile gets rendered, it shows the lower right of the terrain in the colormap, the mesh itself is correct (or the terrain is mirrored, which doesn't make a difference, they just don't fit).
When I flip the texturcoordinates, the upper right tile tile still shows the lower right part of the terrain, but now flipped around the Y-Axis. So the tile itself has a wrong texture and that is nothing what I could repair with texturecoordinate transformation.

I tried some parameters in osgdem like a negative Y resolution (-yy -10) but that just gave me strange and even more wrong results. So how do I fix that? The png files seam to match, and theoretically I could edit them, but what if I want to build other terrains (I have some very big files that none of my image manipulation programs can open...)

Moin! Any news to this topic? I built VPB from current sources yesterday and the problem with flipped textures still exists. My DEM and image file are of the same extent and reference system. Loading the DEM alone works fine. When I specify just the image file via -t without any DEM (omitting -d option), this texture also gets flipped. Further, the rendered tiles are somehow broken as they do not match at their boundaries. Increasing --tile-image-size I get my image to be displayed without any tiling at all where it results to be flipped in total.

I did some builds with VPB last week and didn't come across any flipping problems with the datasets I was working with.

My guess it must just be happening for certain datasets. Could you provide guidance on how you are running osgdem and the data you are using to see this flipping issue?

Robert.

On 23 February 2015 at 11:05, Michi Scholz < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

Moin! Any news to this topic? I built VPB from current sources yesterday and the problem with flipped textures still exists. My DEM and image file are of the same extent and reference system. Loading the DEM alone works fine. When I specify just the image file via -t without any DEM (omitting -d option), this texture also gets flipped. Further, the rendered tiles are somehow broken as they do not match at their boundaries. Increasing --tile-image-size I get my image to be displayed without any tiling at all where it results to be flipped in total.

using some SRTM .hgt heightfields and Landsat geotiff imagery in WGS84 geographic coordinates as input. Also tried "--compressed --compressor-gl-driver", which gives the same result.

I think the problem is related to the ReaderWriterDDS plugin, which in certain cases (the origin of the osg::Image is bottom left and texture sizes are a multiple of 4) is doing vertical flipping on write by default. This behaviour was introduced by osg rev. 13447. When I pass the "ddsNoAutoFlipWrite" option (that had also been added by that revision) to the plugin via "-O ddsNoAutoFlipWrite" vpb command line argument, the problem is gone.

BR
Stephan

On 23.02.2015 21:20, Robert Osfield wrote:

Quote:

Hi Michi,

I did some builds with VPB last week and didn't come across any flipping problems with the datasets I was working with.

My guess it must just be happening for certain datasets. Could you provide guidance on how you are running osgdem and the data you are using to see this flipping issue?

Robert.

On 23 February 2015 at 11:05, Michi Scholz < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

Moin! Any news to this topic? I built VPB from current sources yesterday and the problem with flipped textures still exists. My DEM and image file are of the same extent and reference system. Loading the DEM alone works fine. When I specify just the image file via -t without any DEM (omitting -d option), this texture also gets flipped. Further, the rendered tiles are somehow broken as they do not match at their boundaries. Increasing --tile-image-size I get my image to be displayed without any tiling at all where it results to be flipped in total.

Could you provide guidance on how you are running osgdem and the data you are using to see this flipping issue?

I attached 2 small geo-referenced (EPSG:32632) test datasets. When you load them into any GIS of your choice (QGIS for example), you see that they 100% fit together. My osgdem command is really simple but shows the problem:

Code:

osgdem.exe -l 5 -d dsm.tif -t borders.tif -o model.osg

Or use just the texture and compare the output to the original borders.tif:

Code:

osgdem.exe -l 5 -t borders.tif -o model.osg

My osgdem-version is from commit 43280018f46f4a1873bd543f3dc172b411e682dd and my OSG is 3.2.0, both x86. Sorry for running on windows
Michi

Unfortunately the files have not attached correctly. Could you zip them up and send them directly to me.

Thanks,

Robert.

On 24 February 2015 at 18:15, Michi Scholz < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

Huhu!

robertosfield wrote:

Quote:

Could you provide guidance on how you are running osgdem and the data you are using to see this flipping issue?

I attached 2 small geo-referenced (EPSG:32632) test datasets. When you load them into any GIS of your choice (QGIS for example), you see that they 100% fit together. My osgdem command is really simple but shows the problem:

Code:
osgdem.exe -l 5 -d dsm.tif -t borders.tif -o model.osg

Or use just the texture and compare the output to the original borders.tif:

Code:
osgdem.exe -l 5 -t borders.tif -o model.osg

My osgdem-version is from commit 43280018f46f4a1873bd543f3dc172b411e682dd and my OSG is 3.2.0, both x86. Sorry for running on windows
Michi

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

robertosfield wrote:

Quote:

Unfortunately the files have not attached correctly. Could you zip them up and send them directly to me.

I saw it directly after posting the raw TIFFs. Changed the attachment to a ZIP already last week. Can you use this data?

I have just done a search for posts from in my osg-users folder and can't find anything appropriate.

Could you please just help emailing me a zip file and exact instructions how to recreate. I can't promise anything as I have a lot of work to do but if I can easily recreate the problem I will try and get some some direction on it.

I have just done a search for posts from in my osg-users folder and can't find anything appropriate [..] Post generated by Mail2Forum

OK, mailinglist ... Then, again, you find the surface model and texture zipped as attachment to this message. In my forum post from Feb. 24th you find the call to osgdem which I used to produce the faulty texturing:

Using your data and suggest command line I have been able to reproduce the problem. Outputing to .osgb or .ive works fine. Also if I do as Stephan suggests and add -O "ddsNoAutoFlipWrite" to the command line the generated database also works fine.

The bug looks to be exactly what Stephan suggested - a mismatch between a revsion in default behaviour of the OSG's dds plugin when writing and the what VPB was assuming. I haven't yet decide the best correction, and will have look a the VPB code and general think about this side of things.

Until I check in a fix in your own usage simply add the -O "ddsNoAutoFlipWrite" i.e.

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

The bug looks to be exactly what Stephan suggested - a mismatch between a revsion in default behaviour of the OSG's dds plugin when writing and the what VPB was assuming. I haven't yet decide the best correction, and will have look a the VPB code and general think about this side of things.

Until I check in a fix in your own usage simply add the -O "ddsNoAutoFlipWrite" i.e.

What I have gone for is to simply add the "ddsNoAutoFlipWrite" to the osgDB::Options::OptionString passed into the osgDB::writeImageFile(..) when the file format is .dds. An svn update to VirtualPlanetBuilder will get you this fix.

I will tag another VPB dev release later this week once I've added support for DisplacementMapping.

Thanks a lot for your efforts! Yes, for the former version exporting as .osgb and .ive works fine and also by passing -O "ddsNoAutoFlipWrite" to osgdem I can export in .osg without problems. After pulling your changes I can confirm that no workaround is needed any more. Superb!

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