Page 1 of 1
Lunar eclipse - hires moon texture
Posted: 21.02.2008, 02:30
by LordFerret
This involves the Celestia v1.5.0 Windows installation...
The hires moon texture has worked previously for me the past 2 times I've enabled it (from about the same distance as in these following images). I wanted to 'follow' tonight's lunar eclipse in Celestia, and this is what I get...
Moon hires texture enabled
as opposed to Moon medres texture enabled
There have been no changes to my system since the first 2 times the texture worked (see system specs below). There are no updated drivers for the integrated graphics that I know of.
Any ideas?
Posted: 21.02.2008, 03:51
by Johaen
I can test it out if you say which high res moon texture you're talking about.
Posted: 21.02.2008, 04:30
by LordFerret
The one which came default with the new v1.5.0 Windows install.
Posted: 21.02.2008, 13:05
by Johaen
Oh! I probably should have guessed that.
I just tried it out. I have no issues. I watched the eclipse in it's entirety with the default high res texture and had no problems.
Posted: 21.02.2008, 22:12
by chris
I think I know what is happening. On non-OpenGL 2.0 render paths, eclipse rendering occurs in a second pass. If the geometry in the second pass isn't identical, you'll get strange "z fighting" artifacts like the ones in your image. Now, Celestia *should* be rendering identical geometry, but it's possible that this isn't happening when the main texture is being subdivide because it exceeds your graphics hardware's maximum texture size. Could you cut and past the contents of the OpenGL Info window here (it's under the help menu.)
--Chris
Posted: 23.02.2008, 06:07
by LordFerret
Sorry for the late reply, had a full day with the doctors on Friday.
The specs...
Code: Select all
Vendor: Intel
Renderer: Intel 845G
Version: 1.3.0 - Build 4.14.10.4342
Max simultaneous textures: 4
Max texture size: 2048
Point size range: 0.500000 - 10.000000
Supported Extensions:
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_texture_env_crossbar
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_cull_vertex
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_filter_anisotropic
GL_3DFX_texture_compression_FXT1
GL_IBM_texture_mirrored_repeat
GL_NV_blend_square
GL_NV_texgen_reflection
GL_SGIS_generate_mipmap
GL_WIN_swap_hintJust went and looked at the moon again in hires... now that it's away from earthshadow it looks fine (still slows my system tho).
Posted: 23.02.2008, 14:47
by Johaen
Based on the responses here, I decided to try out the non-OpenGL 2.0 render paths, to see if I get the error then. I don't, but I did notice something else going on.
All non-OpenGL 2.0 render paths:
vs.
OpenGL 2.0
As you can see, the shadow is in a different position based on the different render paths. I'm not sure how big of an issue this is.
