DarkRadiant Preview Bug

[BigBadWolf]

Hello, This is my first post so I think its right to introduce myself. Ive been working with game development for about 8 years now. Some of my work can be found on my website:

Aether Games

 

 

And to the issue. Ive been having trouble with the Lighting Preview in DarkRadiant. It renders the light and diffuse properly but does not render the normal map, even though it shows as being loaded in the console. When I still had Vista I had a similar issue that was fixed by using old ATI drivers.

 

Information about my machine:

- Windows 7 x64

- AMD Phenom x4

- ATI Radeon HD 4870x2

- 4gig ram

- DarkRadiant 1.4.0 x64

 

Things I have tried:

- Changing versions of DarkRadiant ranging from 1.2.0 to 1.5.0 beta

- Changing binaries of Darkradiant from x64 to x86

- Changing compatibility options for DarkRadiant.exe

- Tried GtkRadiant 1.5.0 with same issues

- Changing my Display Drivers from 10.9, to 9.7, to 8.8 and back

- Removing 3d options in Catalyst such as AA and AF

- Tried to locate newer version of GtkGLext

- Searched internet for countless hours.

 

 

I figured its about time to ask for some assistance on this issue as I have gotten nowhere.

Any assistance would be much appreciated.

 

Thanks

Bryan

[nbohr1more]

You are working on OverDose! (That is some quality stuff! )

 

I'll take a dumb blind guess... is the Normal Map "non-power of two"?

 

(I would post your material definition code so smart folk can provide better questions and answers...)

[BigBadWolf]

The texture shown in the screenshot I posted is 512 x 128. Though the same applies to 1024 x 1024 textures. Ive tried rearranging the material to no effect.

 

 

Here's an example of the material:

textures/chess_base/trim02
{
surfaceType   concrete
bumpMap    textures/chess_base/trim02_local.tga
diffuseMap   textures/chess_base/trim02_d.tga
specularMap   textures/chess_base/trim02_s.tga
}

Edited October 11, 2010 by BigBadWolf

[nbohr1more]

What happens if you remove the ".tga" extensions from the material definition?

 

Have you tried using a converted heightmap stage (for trouble-shooting purposes)?

 

textures/heightmap
{
{
blend bumpmap
map heightmap(textures/custom/image_1.tga, 10)
}
}

[greebo]

The only thing I can think of is that your drivers don't accept the glVertexAttribPointerARB(ATTR_NORMAL) call, or maybe the drivers are tricking DarkRadiant into not sending the normal information.

 

Can you open the About Dialog and tell me which GL extensions are listed in there?

[BigBadWolf]

Theres a bunch of them.

I have the source as well, would compiling a debug version help? Im a nub at C++.

 

 

GL_AMDX_debug_output 
GL_AMDX_vertex_shader_tessellator 
GL_AMD_conservative_depth 
GL_AMD_debug_output 
GL_AMD_draw_buffers_blend 
GL_AMD_name_gen_delete 
GL_AMD_performance_monitor 
GL_AMD_sample_positions 
GL_AMD_seamless_cubemap_per_texture
GL_AMD_shader_stencil_export 
GL_AMD_texture_cube_map_array 
GL_AMD_texture_texture4 
GL_AMD_vertex_shader_tessellator 
GL_ARB_blend_func_extended 
GL_ARB_color_buffer_float 
GL_ARB_copy_buffer 
GL_ARB_depth_buffer_float 
GL_ARB_depth_clamp 
GL_ARB_depth_texture
GL_ARB_draw_buffers 
GL_ARB_draw_buffers_blend 
GL_ARB_draw_elements_base_vertex 
GL_ARB_draw_instanced 
GL_ARB_explicit_attrib_location 
GL_ARB_fragment_coord_conventions 
GL_ARB_fragment_program 
GL_ARB_fragment_program_shadow 
GL_ARB_fragment_shader 
GL_ARB_framebuffer_object 
GL_ARB_framebuffer_sRGB 
GL_ARB_geometry_shader4 
GL_ARB_half_float_pixel 
GL_ARB_half_float_vertex 
GL_ARB_imaging 
GL_ARB_instanced_arrays 
GL_ARB_map_buffer_range
GL_ARB_multisample 
GL_ARB_multitexture 
GL_ARB_occlusion_query 
GL_ARB_occlusion_query2 
GL_ARB_pixel_buffer_object 
GL_ARB_point_parameters 
GL_ARB_point_sprite 
GL_ARB_provoking_vertex 
GL_ARB_sample_shading 
GL_ARB_sampler_objects 
GL_ARB_seamless_cube_map 
GL_ARB_shader_bit_encoding 
GL_ARB_shader_objects 
GL_ARB_shader_texture_lod 
GL_ARB_shading_language_100 
GL_ARB_shadow 
GL_ARB_shadow_ambient 
GL_ARB_sync 
GL_ARB_texture_border_clamp 
GL_ARB_texture_buffer_object 
GL_ARB_texture_compression 
GL_ARB_texture_compression_rgtc 
GL_ARB_texture_cube_map 
GL_ARB_texture_cube_map_array 
GL_ARB_texture_env_add 
GL_ARB_texture_env_combine 
GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 
GL_ARB_texture_float 
GL_ARB_texture_gather 
GL_ARB_texture_mirrored_repeat 
GL_ARB_texture_multisample 
GL_ARB_texture_non_power_of_two 
GL_ARB_texture_query_lod 
GL_ARB_texture_rectangle 
GL_ARB_texture_rg 
GL_ARB_texture_rgb10_a2ui 
GL_ARB_texture_snorm 
GL_ARB_timer_query 
GL_ARB_transform_feedback2 
GL_ARB_transform_feedback3 
GL_ARB_transpose_matrix 
GL_ARB_uniform_buffer_object 
GL_ARB_vertex_array_bgra 
GL_ARB_vertex_array_object 
GL_ARB_vertex_buffer_object 
GL_ARB_vertex_program 
GL_ARB_vertex_shader 
GL_ARB_vertex_type_2_10_10_10_rev 
GL_ARB_window_pos 
GL_ATI_draw_buffers 
GL_ATI_envmap_bumpmap 
GL_ATI_fragment_shader 
GL_ATI_meminfo 
GL_ATI_separate_stencil 
GL_ATI_texture_compression_3dc 
GL_ATI_texture_env_combine3 
GL_ATI_texture_float 
GL_ATI_texture_mirror_once 
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_copy_buffer 
GL_EXT_copy_texture 
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_EXT_framebuffer_object 
GL_EXT_framebuffer_sRGB 
GL_EXT_geometry_shader4 
GL_EXT_gpu_program_parameters 
GL_EXT_gpu_shader4 
GL_EXT_histogram 
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_specular_color 
GL_EXT_shadow_funcs 
GL_EXT_stencil_wrap 
GL_EXT_subtexture 
GL_EXT_texgen_reflection 
GL_EXT_texture3D 
GL_EXT_texture_array 
GL_EXT_texture_buffer_object 
GL_EXT_texture_buffer_object_rgb32 
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_add 
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_rectangle 
GL_EXT_texture_sRGB 
GL_EXT_texture_shared_exponent 
GL_EXT_texture_snorm 
GL_EXT_texture_swizzle 
GL_EXT_timer_query 
GL_EXT_transform_feedback 
GL_EXT_vertex_array 
GL_EXT_vertex_array_bgra 
GL_IBM_texture_mirrored_repeat 
GL_KTX_buffer_region 
GL_NV_blend_square
GL_NV_conditional_render 
GL_NV_copy_depth_to_color 
GL_NV_explicit_multisample 
GL_NV_float_buffer 
GL_NV_half_float 
GL_NV_primitive_restart 
GL_NV_texgen_reflection 
GL_SGIS_generate_mipmap 
GL_SGIS_texture_edge_clamp 
GL_SGIS_texture_lod 
GL_SUN_multi_draw_arrays 
GL_WIN_swap_hint 
WGL_EXT_swap_control

[greebo]

No, I think the drivers are fine from that point of view.

 

It's the first time I've been hearing about such a problem, and if you're saying you had this before and fixed by changing drivers it sounds to me like it is specific to your setup. Compiling a debug build won't help much. The only thing we can confirm is that DarkRadiant is sending the normal information to the drivers, by setting a breakpoint in the brush rendering code. I don't know if you want to go through that hassle, but if you do, there is a DR compilation guide on the wiki, and I can tell you the exact file and line where to set the breakpoint.

 

Sorry, there's not much else I can do.

[Serpentine]

I can confirm that my new card (HD 5670) is also not rendering the normalmaps.

 

My old card (1900XT) rendered them correctly on the same config. If I can get VS installed I'll have a look at this, but .net framework is blocking install because it's crap :/

[greebo]

WTF. Got a new notebook last week (with an ATI 5870), and guess what happens here: no normal maps either. Never switched to lighting mode since then, so I never noticed it myself up until today.

 

I think I have Catalyst version 9.12, but not entirely sure.

 

Seems like there are some pieces missing to get DR to render on newer ATI hardware. Gotta love it when things stop to work on their own.

[New Horizon]

Three cheers for ATI!

[greebo]

After looking briefly at the shader programs, it seems DR had a small problem causing the renderer to always use ARB programs. That isn't a problem causing that behaviour, but at least I can confirm now that neither GLSL nor ARB programs render the bumpmap correctly, although the bump texture is correctly loaded (I swapped the diffuse and bumpmap textures in the .glsl file and the normalmap is rendered as diffusemap as expected).

 

Needs further investigation.

[greebo]

Looking at the GLSL program, it seems like the texture matrix of unit 1 is not working correctly:

 

var_tex_diffuse_bump.pq = (gl_TextureMatrix[1] * attr_TexCoord0).st;

 

The UV values stored in the last two values of var_tex_diffuse_bump are wrong, they deliver more or less uniform values (0,0?) and the texture lookup in the fragment program is failing. Changing this line to use the texture matrix of unit 0 (diffusemap unit) makes the bumpmapping working correctly. I'll need to check where these values are pumped into openGL.

[greebo]

Turns out I can fix this issue on my local system by activating texture unit 1 each time along with unit 0, but I'm pretty sure that this is not an elegant solution at all.

 

My guess is that when using multiple texure units, it's not enough to deliver one set of texture coords per vertex, but one set per unit, which means that the "good old" DR way of specifying glVertexAttribPointerARB(11, ...) is not cutting it for the recent ATI generation.

[ungoliant]

i have an old ati and normals work, but everything else about lighting mode in DR is like... broke. its not even worth it to use because it runs so slowly and inaccurately to what you see in the game. Not that i'm complaining. I love DR. DR is the best and greebo is awesome.

[Nosslak]

Up until now I thought there were no support for normalmaps in DR as I've never seen any either. I'm using a nVidia Geforce GTX 275.

[greebo]

The easy workaround is to always use the texture matrix of the first texture unit, gl_textureMatrix[0], but I assume for full support of D3 shader stages each texture unit needs its independent matrix, otherwise it'd be impossible to use explicit diffusemap stages with scale or translate keywords while using a "normally" scaled bumpmap at the same time (some of our stone textures use that trick).

 

I'll try to reach Robert Beckebans from xReal, maybe he has some ideas what is going on, it's possible that we're hitting the ceiling with DR's current render code and some serious refactoring is necessary to properly support multitexturing the way those ATI cards are requiring it.

[BigBadWolf]

How is this temp fix achieved?

 

Ive located the code youve posted in the interaction vertex shader:

var_tex_diffuse_bump.pq = (gl_TextureMatrix[1] * attr_TexCoord0).st

Though when i change the matrix array value to 0 and restart the program, it remains ineffective.

Does this fix require a rebuild of the program? I thought glsl was ran like a script...

[greebo]

How is this temp fix achieved?

 

Ive located the code youve posted in the interaction vertex shader:

var_tex_diffuse_bump.pq = (gl_TextureMatrix[1] * attr_TexCoord0).st

Though when i change the matrix array value to 0 and restart the program, it remains ineffective.

Does this fix require a rebuild of the program? I thought glsl was ran like a script...

In principle you were heading to the right direction, but there was another bug in DarkRadiant's GLProgramFactory, which prevented the .glsl file from being used. It would always use the ARB program. I already checked in a fix for that to my working branch, but the pre-release version you are working with doesn't have that.

 

So, for the moment being, you can either wait for the next actual release, or hack the ARB program, or set up Visual Studio and compile from SVN source.

[BigBadWolf]

I have the svn and VS2008, ill give it a try.

 

Thanks for all the help so far. Ive been trying to use what i know and learn more about c++ and openGL, so this has been a good little learning session.

 

 

[greebo]

The compilation guide to DR is here, in case you haven't found it already: http://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compilation_Guide

[BigBadWolf]

I got a working build now and found a couple other issues.

 

Once the vertex shader was hacked to fix the bump map, I realized the specular map wasnt showing up. So I tried the same hack for the Specular calculation and it worked... However now the attenuation is way off. Either that or the spec is extreemly overbright. I checked the light material and textures but everything looked ok.

 

Edit: This overbright lighting is always there, even without the bump and specular fixes.

 

I took a screenshot of both the modified radiant and the origional for compairison. NOTE: the bump and spec are working.

Edited October 14, 2010 by BigBadWolf

[greebo]

Glad you got it working for you - I assume you have been checking out the trunk or did you switch to my particles dev branch?

 

I got a reply from Robert, he suggests pumping my own texture matrix into the Vertex Program. I'll have to dig a bit into this, a real fix will take some time. The overbright issue is not that good news either, but it might be related.

[OrbWeaver]

If I recall correctly, the texture matrix input to the shaders is not actually used as a texture matrix in the normal way, but is used to hold one of the other matrices (maybe local2light, or light2world or something). Perhaps the latest ATI drivers are implementing an optimisation which assumes something about the texture matrices that is not correct in our case.

 

I have seen the overbright issue before when switching from ARB to GLSL, but can't immediately remember what caused it.

[Serpentine]

Perhaps the latest ATI drivers are implementing an optimisation which assumes something about the texture matrices that is not correct in our case.

 

It's unlikely, I think the render on the gtkradiant side of things was just making an assumption that 'what works must be right' and relying on a quirk. Considering the issue also hits nvidia users now and they are always seen as the benchmark for opengl.

[OrbWeaver]

Having a brief look through the code (on my Linux machine, where I have not previously seen the bug), it seems that the problem could be that the GLSL shader is using the texture matrixes from texture units which have not had a texture matrix set or initialised. The only changes to the texture matrix are:

 

OpenGLRenderPass::render(), which initialises the texture matrix of the currently-bound texture unit (with no attempt to determine which this is) to identity, and

 

GLSLBumpProgram::applyRenderParams(), which loads the local2light transformation matrix into the texture matrix of texture unit 3.

 

I suspect this worked before because the unused texture matrices were simply left at the identity, but maybe the newer drivers are not initialising texture matrices for texture units that are not used, so this operation in the GLSL shader gives a wrong result.

 

If this reasoning is correct, then the solution could be as simple as removing the offending multiplication operation in the GLSL shader altogether, since it performs no purpose when the texture matrices are never used in the code.