Board index FlightGear Support Tools Atlas

Cannot generate maps.  Topic is solved

Atlas is an addon that lets FlightGear users display a real-time "moving-map" of their flight.

Cannot generate maps.

Postby cookevillain » Tue Dec 06, 2011 7:20 pm

Hi,

I have just installed (compiled form source) Atlas 0.4.0 and am trying to generate maps using

Map --fg-root=/usr/local/share/flightgear/ --fg-scenery=/usr/local/share/flightgear/Scenery --atlas=/usr/local/share/flightgear/Atlas

but Map aborts with:

Map: TileMapper.cxx:179: void TileMapper::render(): Assertion `__glewCheckFramebufferStatusEXT(0x8D40) == 0x8CD5' failed

I am also seeing a bunch of entries like the one below:

Chunk::_scanScenery: unexpected tile directory 'w060s60' - ignoring

My flightgear works fine and the full scenery is installed.
Is there a fix for this anywhere? Is there an alternative to Atlas to display flightgear map data?

Thanks.
cookevillain
 
Posts: 28
Joined: Thu Jul 24, 2008 10:31 pm

Re: Cannot generate maps.

Postby bschack » Thu Dec 08, 2011 2:58 am

Try running Map with the '--verbose' option and show us the output; that should tell us a bit more about what it's trying to do.

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby cookevillain » Thu Dec 08, 2011 3:15 am

Here is the output of Map --verbose (the $FG_ROOT and $FG_SCENERY were set as well):

Code: Select all
Scenery directories: /usr/local/share/flightgear/Scenery/
Map directory: /usr/local/share/flightgear//Atlas
Chunk::_scanScenery: unexpected tile directory 'w060s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w059s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w056s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w055s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w058s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w057s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e166s48' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e143n48' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e141n49' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e149n47' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e148n47' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e147n47' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e144n47' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e145n47' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180n85' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180n83' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180n87' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180n86' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180n84' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e027s39' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e146n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e140n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e144n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e149n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e142n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e141n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e145n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e148n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'e147n56' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180s85' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180s87' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180s86' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w180s88' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w061s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w171n59' - ignoring
Trying to read palette file 'default.ap'
Trying to read palette file '/usr/local/share/flightgear//Atlas/Palettes/default.ap'
Palette file: /usr/local/share/flightgear//Atlas/Palettes/default.ap
Map sizes: 4 (16x16), 6 (64x64), 8 (256x256)
Scenery: 31516 tiles
OpenGL 1.5 supported
OpenGL framebuffer object extension supported
Maximum supported texture size <= map size: 256x256
Map: TileMapper.cxx:179: void TileMapper::render(): Assertion `__glewCheckFramebufferStatusEXT(0x8D40) == 0x8CD5' failed.
e000s90: Aborted
cookevillain
 
Posts: 28
Joined: Thu Jul 24, 2008 10:31 pm

Re: Cannot generate maps.

Postby bschack » Thu Dec 08, 2011 6:47 am

cookevillain wrote in Thu Dec 08, 2011 3:15 am:Here is the output of Map --verbose (the $FG_ROOT and $FG_SCENERY were set as well):

Code: Select all
Scenery directories: /usr/local/share/flightgear/Scenery/
Map directory: /usr/local/share/flightgear//Atlas
Chunk::_scanScenery: unexpected tile directory 'w060s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w059s60' - ignoring
[...]
Chunk::_scanScenery: unexpected tile directory 'w061s60' - ignoring
Chunk::_scanScenery: unexpected tile directory 'w171n59' - ignoring
Trying to read palette file 'default.ap'
Trying to read palette file '/usr/local/share/flightgear//Atlas/Palettes/default.ap'
Palette file: /usr/local/share/flightgear//Atlas/Palettes/default.ap
Map sizes: 4 (16x16), 6 (64x64), 8 (256x256)
Scenery: 31516 tiles
OpenGL 1.5 supported
OpenGL framebuffer object extension supported
Maximum supported texture size <= map size: 256x256
Map: TileMapper.cxx:179: void TileMapper::render(): Assertion `__glewCheckFramebufferStatusEXT(0x8D40) == 0x8CD5' failed.
e000s90: Aborted


The "unexpected tile directory" messages can be ignored for now (they're not terribly important). The assertion error is critical though. Can you change line 179 in TileMapper.cxx to:

Code: Select all
printf("check framebuffer status = %#x\n", glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT));
exit(0);


What does it print out?

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby cookevillain » Thu Dec 08, 2011 2:12 pm

Hi Brian!

Here is the output:

Code: Select all
e000s90: check framebuffer status = 0x8cdd


I do not know how relevant this is but I use a GeForce 6600 card with NVidia's proprietary drivers on Ubuntu 10.04
cookevillain
 
Posts: 28
Joined: Thu Jul 24, 2008 10:31 pm

Re: Cannot generate maps.

Postby bschack » Tue Dec 13, 2011 6:48 am

cookevillain wrote in Thu Dec 08, 2011 2:12 pm:Hi Brian!

Here is the output:

Code: Select all
e000s90: check framebuffer status = 0x8cdd


I do not know how relevant this is but I use a GeForce 6600 card with NVidia's proprietary drivers on Ubuntu 10.04


The error code means that the particular combination of framebuffer parameters Map asked for is not supported by your graphics card (although the card does support framebuffers of some sort).

So now we need to figure out what it doesn't like. As far as I can tell, OpenGL doesn't support a nice way of figuring out what is supported, except by trying them out and seeing if it produces an error (somebody correct me if I'm wrong). I'll have to write a program to do that. Are you (and anybody else reading this) willing to be a guinea pig?

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby cookevillain » Tue Dec 13, 2011 2:00 pm

bschack wrote in Tue Dec 13, 2011 6:48 am: I'll have to write a program to do that. Are you (and anybody else reading this) willing to be a guinea pig?


Sure, aren't we all already? :shock: If you do write that code, it should probably be included with Atlas (or even FG) in case something like this happens in the future.
cookevillain
 
Posts: 28
Joined: Thu Jul 24, 2008 10:31 pm

Re: Cannot generate maps.

Postby chrisr » Sat Dec 17, 2011 7:35 am

I am in the same position:

1 Map is aborting at the assert in Atlas/src/TileMapper.cxx(179) because glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT) equals 0x8CDD (GL_FRAMEBUFFER_UNSUPPORTED_EXT) instead of the required value 0x8CD5 (GL_FRAMEBUFFER_COMPLETE_EXT).

2 I too am using Linux, have a GeForce GTX 470, and NVidia's proprietary drivers

3 If it is any help, the utility visualinfo reports (in part)
Code: Select all
    GL_EXT_texture_env_add, GL_EXT_abgr,
    GL_EXT_bgra, GL_EXT_bindable_uniform, GL_EXT_blend_color,
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array,
    GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_direct_state_access,
    GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_draw_range_elements,
    GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample,
    GL_EXTX_framebuffer_mixed_formats, GL_EXT_framebuffer_object,
    GL_EXT_framebuffer_sRGB, GL_EXT_geometry_shader4,
    GL_EXT_gpu_program_parameters, GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_depth_stencil, GL_EXT_packed_float, GL_EXT_packed_pixels,
    GL_EXT_pixel_buffer_object, GL_EXT_point_parameters,
    GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_shader_objects, GL_EXT_separate_specular_color,
    GL_EXT_shader_image_load_store, GL_EXT_shadow_funcs,
    GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D,
    GL_EXT_texture_array, GL_EXT_texture_buffer_object,
    GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc,
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
    GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
    GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias,
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
    GL_EXT_texture_shared_exponent, GL_EXT_texture_sRGB, GL_EXT_texture_swizzle,
    GL_EXT_timer_query, GL_EXT_transform_feedback2, GL_EXT_vertex_array,
    GL_EXT_vertex_array_bgra, GL_EXT_vertex_attrib_64bit


4 The utility glewinfo reports (in part):
Code: Select all
GLX_EXT_fbconfig_packed_float:                                 OK
GLX_EXT_framebuffer_sRGB:                                      OK
GLX_EXT_import_context:                                        OK
  glXFreeContextEXT:                                           OK
  glXGetContextIDEXT:                                          OK
  glXImportContextEXT:                                         OK
  glXQueryContextInfoEXT:                                      OK

GLX_EXT_scene_marker:                                          MISSING
GLX_EXT_swap_control:                                          OK
  glXSwapIntervalEXT:                                          OK

GLX_EXT_texture_from_pixmap:                                   OK
  glXBindTexImageEXT:                                          OK
  glXReleaseTexImageEXT:                                       OK

GLX_EXT_visual_info:                                           OK
GLX_EXT_visual_rating:                                         OK


I don't know anything about OpenGL programming, but am happy to trial any patches you can come up with.
Chris
chrisr
 
Posts: 14
Joined: Sat Oct 30, 2010 11:40 pm
Version: Git
OS: Ubuntu 10.4

Re: Cannot generate maps.

Postby bschack » Tue Dec 27, 2011 6:45 am

This is a stock suggestion, and I'm assuming those who have posted here have tried this, but just in case: make sure your video drivers are up-to-date. Another user was experiencing the same problem, but found out his/her driver was over two years old. After updating, the problem went away.

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby bschack » Tue Dec 27, 2011 7:34 am

I've been doing a bit more reading about frame buffers. A document I found by NVIDIA says that the error code we've been seeing means the "application should try different format combinations until one succeeds". "Format" in this case refers to the texture we're rendering to. In our case, this is given by this line in TileMapper.cxx:

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);


It's a pretty unremarkable request, using pretty standard parameters. I can see only two bits that might cause problems:

(1) The _width and _height, which refer, not surprisingly, to the desired width and height of the map. If you request something really big (like 4096x4096), the driver might complain. That doesn't seem to be the problem for the people who have posted here.

(2) The first instance of "GL_RGB". This tells OpenGL the internal format to use for the texture. This might cause a problem because it is incomplete - it tells OpenGL to create an RGB texture, but it leaves it up to the driver to decide how big each component should be. So maybe the driver is using a default that render buffers don't support.

Assuming the problem is not (1), nor a problem with an out-of-date driver (see my previous post), then maybe we need to fully specify the format in (2). So, here is my suggestion:

Replace the first "GL_RGB" with "GL_RGB8"

This tells OpenGL that we want to use 8 bits for each of the red, green, and blue components. Note: do not change the second "GL_RGB" in the call - that one refers to how the texture is stored in main memory. The line should look like this:

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);


Try it out and let me know if anything changes.

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby chrisr » Thu Dec 29, 2011 8:06 am

Brian,
Thanks for looking into this:

bschack wrote in Tue Dec 27, 2011 7:34 am:I've been doing a bit more reading about frame buffers. A document I found by NVIDIA says that the error code we've been seeing means the "application should try different format combinations until one succeeds". "Format" in this case refers to the texture we're rendering to. In our case, this is given by this line in TileMapper.cxx:

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);


It's a pretty unremarkable request, using pretty standard parameters. I can see only two bits that might cause problems:

(1) The _width and _height, which refer, not surprisingly, to the desired width and height of the map. If you request something really big (like 4096x4096), the driver might complain. That doesn't seem to be the problem for the people who have posted here.

(2) The first instance of "GL_RGB". This tells OpenGL the internal format to use for the texture. This might cause a problem because it is incomplete - it tells OpenGL to create an RGB texture, but it leaves it up to the driver to decide how big each component should be. So maybe the driver is using a default that render buffers don't support.

Assuming the problem is not (1), nor a problem with an out-of-date driver (see my previous post), then maybe we need to fully specify the format in (2). So, here is my suggestion:

Replace the first "GL_RGB" with "GL_RGB8"

This tells OpenGL that we want to use 8 bits for each of the red, green, and blue components. Note: do not change the second "GL_RGB" in the call - that one refers to how the texture is stored in main memory. The line should look like this:

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);


Try it out and let me know if anything changes.

Brian


Here are my findings...

Regarding up-to-dateness of the nVidia drivers, my system is routinely updated. Although I don't know a really definitive way to check this, I note that all libraries in /usr/lib/nvidia-current are date-stamped as 2011-10-14.

You speculate about width*height of the textures. I have added some diagnostic printf's that may be of use:
Code: Select all
At line 69, 2^MAX_MAP_LEVEL = 0x10000
At line 69, maxTextureSize = 0x4000
At line 69, maxBufferSize = 0x4000
At line 69, log2(min(,,)) = 14.000000
w023n65:
At line 160, computed width*height = 512 * 1024 = 0x80000
At line 172, after glTexImage2D(), glGetError = 0x0
After glFrameBufferTexture2DEXT(), glGetError = 0x0
Just before assert, glCheckFramebufferStatusEXT = 0x8CDD. Disaster looming...

Map: TileMapper.cxx:202: void TileMapper::render(): Assertion `__glewCheckFramebufferStatusEXT(0x8D40) == 0x8CD5' failed.
Aborted


The other thing to report is that changing argument 3 from GL_RGB to GL_RGB8 had no effect: glCheckFramebufferStatusEXT still returned 0x8CDD.

So no solution yet. Any more suggestions welcome!
Chris
chrisr
 
Posts: 14
Joined: Sat Oct 30, 2010 11:40 pm
Version: Git
OS: Ubuntu 10.4

Re: Cannot generate maps.

Postby bschack » Tue Jan 03, 2012 6:02 am

chrisr wrote in Thu Dec 29, 2011 8:06 am:Here are my findings...

Regarding up-to-dateness of the nVidia drivers, my system is routinely updated. Although I don't know a really definitive way to check this, I note that all libraries in /usr/lib/nvidia-current are date-stamped as 2011-10-14.

You speculate about width*height of the textures. I have added some diagnostic printf's that may be of use:
Code: Select all
At line 69, 2^MAX_MAP_LEVEL = 0x10000
At line 69, maxTextureSize = 0x4000
At line 69, maxBufferSize = 0x4000
At line 69, log2(min(,,)) = 14.000000
w023n65:
At line 160, computed width*height = 512 * 1024 = 0x80000
At line 172, after glTexImage2D(), glGetError = 0x0
After glFrameBufferTexture2DEXT(), glGetError = 0x0
Just before assert, glCheckFramebufferStatusEXT = 0x8CDD. Disaster looming...

Map: TileMapper.cxx:202: void TileMapper::render(): Assertion `__glewCheckFramebufferStatusEXT(0x8D40) == 0x8CD5' failed.
Aborted


The other thing to report is that changing argument 3 from GL_RGB to GL_RGB8 had no effect: glCheckFramebufferStatusEXT still returned 0x8CDD.

So no solution yet. Any more suggestions welcome!
Chris


Thanks for the report. I wonder if you could check one more thing for me. I notice that you are generating a non-square tile (512 x 1024). This is not an error, as map tiles become skinnier as you move north. Also, OpenGL has been able to handle non-square textures for a long time. However, I'm less sure about non-square render buffers.

So, can you do an experiment for me and force width = height? The easiest way is just to add "_width = _height" after you get the map size:

Code: Select all
    _tile->mapSize(_maxLevel, &_width, &_height);
    _width = _height;

Thanks,
Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby chrisr » Wed Jan 04, 2012 4:12 am

As you requested I tried forcing _height=_width, however the diagnostics and the assert failure was still identical. I also downloaded tiles from more moderate latitudes, which called for 1024*1024 textures; but the assert still failed, with the same error code.

So, still a mystery.

It is not relevant to the problem at hand, but for completeness I should mention that I did three things to the downloaded Git version of Atlas to get it to this point:
  • To fix "variable ‘SGBucket b’ has initializer but incomplete type" I deleted the constructor and a subsequent reference to 'b'.
  • To fix lots of errors like "undefined reference to SGMutex" I added '-lsgthreads' to the final link (by editing Atlas/src/Makefile.am). Then did "./download_and_compile.sh -p n -d n ATLAS"
  • To fix multiple errors, referring to GL/glew*, during compilation of Map.cxx I did "apt-get install glew-utils libglew-dev" which adds several packages, but most importantly libglew1.5-dev

These are separate issues, I know, but may be of help when packaging the new version.
Chris
chrisr
 
Posts: 14
Joined: Sat Oct 30, 2010 11:40 pm
Version: Git
OS: Ubuntu 10.4

Re: Cannot generate maps.

Postby bschack » Thu Jan 05, 2012 5:58 am

chrisr wrote in Wed Jan 04, 2012 4:12 am:As you requested I tried forcing _height=_width, however the diagnostics and the assert failure was still identical. I also downloaded tiles from more moderate latitudes, which called for 1024*1024 textures; but the assert still failed, with the same error code.

So, still a mystery.

Chris


It certainly is, and thanks again for the report. Upon further reading, it appears that the Nvidia driver is overly picky about texture completeness when used with framebuffers (see http://www.opengl.org/wiki/Common_Mistakes#Updating_A_Texture). So let's try another experiment. In render() (around line 179), add a call to glGenerateMipmapEXT():

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);
glGenerateMipmapEXT(GL_TEXTURE_2D);


I'm not sure if we need to add more, but if it doesn't work, add these calls:

Code: Select all
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, _width, _height, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glGenerateMipmapEXT(GL_TEXTURE_2D);


(And yes, I am just taking wild shots in the dark).

Brian
bschack
 
Posts: 195
Joined: Tue Jul 01, 2008 9:04 am

Re: Cannot generate maps.

Postby i4dnf » Thu Jan 05, 2012 7:53 am

chrisr wrote in Thu Dec 29, 2011 8:06 am:Regarding up-to-dateness of the nVidia drivers, my system is routinely updated. Although I don't know a really definitive way to check this, I note that all libraries in /usr/lib/nvidia-current are date-stamped as 2011-10-14.

They might be date stamped as that, but they are a very old version most probably. Distrowatch reports 195.36.15 as the version for nvidia-drivers on ubuntu 10.4, if that's so, that's a very old and buggy(IIRC the 195 series was a particularly bad one) version of nvidia's drivers.
you can use
Code: Select all
nvidia-settings -q NvidiaDriverVersion
to find out the version of the driver that's currently in use on your system.
i4dnf
Retired
 
Posts: 745
Joined: Wed Sep 09, 2009 7:17 am
Location: LRBS
Callsign: YR-I4D
Version: GIT
OS: Gentoo Linux ~amd64

Next

Return to Atlas

Who is online

Users browsing this forum: No registered users and 1 guest