Cannot generate maps.

by **cookevillain** » Tue Dec 06, 2011 8: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.

by **bschack** » Thu Dec 08, 2011 3: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

by **cookevillain** » Thu Dec 08, 2011 4: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

by **bschack** » Thu Dec 08, 2011 7:47 am

cookevillain wrote in Thu Dec 08, 2011 4: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

by **cookevillain** » Thu Dec 08, 2011 3: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

by **bschack** » Tue Dec 13, 2011 7:48 am

cookevillain wrote in Thu Dec 08, 2011 3: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

by **cookevillain** » Tue Dec 13, 2011 3:00 pm

bschack wrote in Tue Dec 13, 2011 7: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.

by **chrisr** » Sat Dec 17, 2011 8: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

by **bschack** » Tue Dec 27, 2011 7: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

by **bschack** » Tue Dec 27, 2011 8: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

by **chrisr** » Thu Dec 29, 2011 9:06 am

Brian,
Thanks for looking into this:

bschack wrote in Tue Dec 27, 2011 8: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

by **bschack** » Tue Jan 03, 2012 7:02 am

chrisr wrote in Thu Dec 29, 2011 9: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

by **chrisr** » Wed Jan 04, 2012 5: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

by **bschack** » Thu Jan 05, 2012 6:58 am

chrisr wrote in Wed Jan 04, 2012 5: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

by **i4dnf** » Thu Jan 05, 2012 8:53 am

chrisr wrote in Thu Dec 29, 2011 9: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.

Board index ‹ FlightGear ‹ Support ‹ Tools ‹ Atlas

Cannot generate maps.

Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Re: Cannot generate maps.

Who is online