28 replies to this topic

[fabio]

With some mesa drivers there is a wrong shadow behind some objects (example below) that goes away when disabling shadows in 0 A.D.. This is a known mesa clamping bug affecting r300, r300g, softpipe, llvmpipe, swrast mesa drivers and possibly others.

Other than the original shadow bug this thread discussed also two other graphic related problems. Overall status update:

• [FIXED in mesa 7.11 (r300/r300g, softpipe, llvmpipe, swrast, see also mesa bug #31159) and backported to 7.10.2 on r300g only] original shadow problem;
  
• [FIXED in 0 A.D. alpha 2 (r8313)] icons corruption problem;
  
• [FIXED in 0 A.D. alpha 2 (r8288)] 0.A.D. off-by-one error giving mesa warnings;

Example:

Attached Thumbnails

• 

Edited by fabio, 02 November 2012 - 11:05 AM.

[Ykkrosh]

Does the unit's icon (in the bottom/center) really look like in the screenshot? (That looks rather ugly - it shouldn't be like that...)

When you have the shadow problem, could you press "g" to disable the GUI and "`" to open the console and enter "?renderer.displayFrustum=true" ? That should make it render the shadow map in the top left corner, which might help show something about the problem.

[Mythos_Ruler]

Posted image is broken for me.

[fcxSanya]

Mythos_Ruler, on Oct 4 2010, 10:44 PM, said:

Posted image is broken for me.

It seems like this is right link.

[Mythos_Ruler]

AHA, nice FOW bug...

And yes, the center icons all look blurry because they are being scaled up from 64x64 to something like 100x100. The only solution is to use bigger icon sheets.

[Ykkrosh]

It's not just blurred, it's got patches of black and blue that really shouldn't be there.

[fabio]

Ykkrosh, on Oct 4 2010, 12:53 PM, said:

Does the unit's icon (in the bottom/center) really look like in the screenshot? (That looks rather ugly - it shouldn't be like that...)

Yes, some images are even uglier, e.g.:
http://imagebin.org/117060

Quote

When you have the shadow problem, could you press "g" to disable the GUI and "`" to open the console and enter "?renderer.displayFrustum=true" ? That should make it render the shadow map in the top left corner, which might help show something about the problem.

I get this:
http://imagebin.org/117061

Note: I pressed F9 to open the console.

Edited by fabio, 05 October 2010 - 07:26 AM.

[Ykkrosh]

fabio, on Oct 5 2010, 08:23 AM, said:

Yes, some images are even uglier

Hmm, looks kind of like a bug in the driver's S3TC handling, but I'm not sure why it only affects that texture. Maybe because it's scaled up, and/or has no mipmaps? Do you see similar texture issues anywhere else, e.g. if you do shift+D and disable "restrict camera" and zoom in so other textures get scaled up? Does it change if you edit binaries/data/mods/public/art/textures/ui/textures.xml to say mipmap="true"?

Quote

I get this:

That looks like the shadow map is getting generated correctly, and the horse's shadow is faint but clearly separated from the edge of the shadow map, but in the main display the dark edge cuts through the middle of it. So it seems the problem is somewhere between the generation of the shadow map and the application of it. I'm afraid I don't know enough about the rendering code or OpenGL or potential driver bugs etc to understand the problem more, though

(By the way, another useful console command is "?gameView.lockCullCamera=true", which locks the position of the camera used for shadow generation and lets you move around and see it from other angles. Probably won't help much here, though.)

[fabio]

Ykkrosh, on Oct 5 2010, 11:17 AM, said:

Hmm, looks kind of like a bug in the driver's S3TC handling, but I'm not sure why it only affects that texture. Maybe because it's scaled up, and/or has no mipmaps? Do you see similar texture issues anywhere else, e.g. if you do shift+D and disable "restrict camera" and zoom in so other textures get scaled up?

I looked at details of many units and buildings but I don't see other artifacts (this model has a grey face: http://imagebin.org/117106 but I think it's not an artifact).

Quote

Does it change if you edit binaries/data/mods/public/art/textures/ui/textures.xml to say mipmap="true"?

It's still the same.

Quote

That looks like the shadow map is getting generated correctly, and the horse's shadow is faint but clearly separated from the edge of the shadow map, but in the main display the dark edge cuts through the middle of it. So it seems the problem is somewhere between the generation of the shadow map and the application of it. I'm afraid I don't know enough about the rendering code or OpenGL or potential driver bugs etc to understand the problem more, though

(By the way, another useful console command is "?gameView.lockCullCamera=true", which locks the position of the camera used for shadow generation and lets you move around and see it from other angles. Probably won't help much here, though.)

I tried but it doesn't get any new info apparently.

I noticed also that (using a mesa driver compiled with debug info) sometimes (I can't find a way to reliably reproduce it) I get this warning:

Mesa warning: glDraw[Range]Elements(start 0, end 24, count 36, type 0x1403, indices=0xa7ebec88)
	end is out of bounds (max=23)  Element Buffer 0 (size 0)
	This should probably be fixed in the application.

This looks like a 0ad bug and similar to an old nexuiz bug:
http://bugs.freedesk...ug.cgi?id=22743

Edited by fabio, 05 October 2010 - 02:03 PM.

[Ykkrosh]

fabio, on Oct 5 2010, 03:00 PM, said:

I looked at details of many units and buildings but I don't see other artifacts (this model has a grey face: http://imagebin.org/117106 but I think it's not an artifact).

Hmm, looks like lots of artifacts to me . Should look like this - there's a big quality difference in the face, the grass, the back of the shield, etc. Just to check it's not a bug in the texture compression code, could you upload the file ~/.cache/0ad/art/textures/terrain/types/grass/grass1_spring.dds.*.dds ?

Quote

I noticed also that (using a mesa driver compiled with debug info) sometimes (I can't find a way to reliably reproduce it) I get this warning:

Mesa warning: glDraw[Range]Elements(start 0, end 24, count 36, type 0x1403, indices=0xa7ebec88)
	end is out of bounds (max=23)  Element Buffer 0 (size 0)
	This should probably be fixed in the application.

Can you reproduce it often enough that you could catch it in a debugger? (Put a breakpoint on _mesa_warning, I think, then do a "bt full" if it hits it.)

[fabio]

Ykkrosh, on Oct 5 2010, 03:28 PM, said:

Hmm, looks like lots of artifacts to me . Should look like this - there's a big quality difference in the face, the grass, the back of the shield, etc. Just to check it's not a bug in the texture compression code, could you upload the file ~/.cache/0ad/art/textures/terrain/types/grass/grass1_spring.dds.*.dds ?

I never noticed they were artifacts. I uploaded the file here:
http://uploadbin.net/5fb586b421e7102e98449...365fa586346.dds

Quote

Can you reproduce it often enough that you could catch it in a debugger? (Put a breakpoint on _mesa_warning, I think, then do a "bt full" if it hits it.)

I'll try.

[Ykkrosh]

Ykkrosh, on Oct 5 2010, 04:28 PM, said:

Can you reproduce it often enough that you could catch it in a debugger?

Actually there's no need, I reproduced it myself - it fails when the vertex buffer allocator happens to allocate the final index of a buffer (which is why it seems random), since we pass the wrong end value to glDrawRangeElements. Fixed.

[Ykkrosh]

fabio, on Oct 5 2010, 04:51 PM, said:

I never noticed they were artifacts. I uploaded the file here:

Oh, interesting, it looks like the artifacts are introduced by the texture compression process, not by the rendering.

In that case:

If you delete ~/.cache/0ad/ then run the game again, does it still have those artifacts?

Are you using the default bundled copy of NVTT, not a different version (installed into /usr/include/nvtt etc)? What's the output of the "Building NVTT..." section when running update-workspaces.sh? What OS and CPU architecture are you on?

[fabio]

Ykkrosh, on Oct 5 2010, 04:08 PM, said:

Oh, interesting, it looks like the artifacts are introduced by the texture compression process, not by the rendering.

In that case:

If you delete ~/.cache/0ad/ then run the game again, does it still have those artifacts?

Yes.

Quote

Are you using the default bundled copy of NVTT, not a different version (installed into /usr/include/nvtt etc)? What's the output of the "Building NVTT..." section when running update-workspaces.sh?

Yes:

Building NVTT...

-- Setting optimal options
--   Processor: i686
--   Compiler Flags:  -march=i686
-- Looking for OpenGL - found
-- Looking for GLUT - found
-- Looking for DirectX - not found
-- Looking for GLEW - not found
-- Looking for Cg - not found
-- Looking for CUDA - not found
-- Looking for Maya - not found
-- Looking for JPEG - found
-- Looking for PNG - found
-- Looking for TIFF - found
-- Looking for OpenEXR - not found
-- Use thread library: -lpthread
-- Configuring done
-- Generating done
-- Build files have been written to: /home/fabio/sorgenti/0ad/libraries/nvtt/src/build
[ 16%] Built target nvcore
[ 30%] Built target nvmath
[ 32%] Built target posh
[ 58%] Built target nvimage
[ 72%] Built target squish
[100%] Built target nvtt

Quote

What OS and CPU architecture are you on?

32 bit Ubuntu 10.10 (maverick) on a Core Duo cpu:

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 14
model name	: Genuine Intel(R) CPU		   T2600  @ 2.16GHz
stepping	: 8
cpu MHz		: 2167.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
bogomips	: 4327.52
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 32 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 14
model name	: Genuine Intel(R) CPU		   T2600  @ 2.16GHz
stepping	: 8
cpu MHz		: 2167.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
bogomips	: 4327.55
clflush size	: 64
cache_alignment	: 64
address sizes	: 32 bits physical, 32 bits virtual
power management:

[Ykkrosh]

Aha, I can seemingly reproduce the texture compression if I compile with GCC 4.4.4, but not with 4.3.4 or 4.5.0. (This is on Gentoo amd64). So it looks like a GCC bug. But since Ubuntu defaults to GCC 4.4 I guess it's a bug we have to find a workaround for

[Ykkrosh]

Hmm, actually (after painful investigation) it's a bug in NVTT, which peculiarly seems to be triggered only by that specific version of GCC, as far as I can tell.

I'll patch our bundled copy of NVTT tomorrow, which should fix this texture thing for you.

(The shadow issue is completely unrelated, though.)

[fabio]

OK, the nvtt bug is fixed.

Is it true that 0ad tarballs will include only precompressed textures? Does providing precompressed textures avoid the "gray textures for some seconds the first time the game is run"? Does providing precompressed textures remove the dependency on nvtt?

[Ykkrosh]

fabio, on Oct 11 2010, 11:14 AM, said:

Is it true that 0ad tarballs will include only precompressed textures?

Yes. (And it's only precompressed textures because including both versions would substantially increase the download size, and most users will never want the uncompressed ones, and it should be easy enough to find the uncompressed ones via SVN.)

Quote

Does providing precompressed textures avoid the "gray textures for some seconds the first time the game is run"?

Yes.

Quote

Does providing precompressed textures remove the dependency on nvtt?

No. We want to support mods well, which means the game still needs to handle dynamic conversion of textures even if the standard bundled ones are preconverted.

[fabio]

Ykkrosh, on Oct 11 2010, 03:44 PM, said:

Quote

Does providing precompressed textures remove the dependency on nvtt?

No. We want to support mods well, which means the game still needs to handle dynamic conversion of textures even if the standard bundled ones are preconverted.

This may be a problem for linux distribution, then. The point of the disabled S3TC and the external libtxc_dxtn is that they included patented algorithm and the it isn't included by default. If nvtt will include the same libtxc_dxtn patented algorithm it still couldn't be distributed by linux distributions. At that point it could make sense to entirely drop nvtt (using it only for generating the compressed textures from the PNGs to distribute in tarballs) and suggest users install libtxc_dxtn.

Edited by fabio, 12 October 2010 - 10:20 AM.

[Ykkrosh]

NVTT FAQ:

Quote

NVIDIA has a license of the S3TC patent that covers all our products, including our Texture Tools. You don't have to obtain a license of the S3TC patent to use any of NVIDIA's products

which I believe means Linux distros providing NVTT packages would be covered.

Most distros already seem to provide packages for DevIL, which includes a S3TC compression algorithm (which would be affected by the same patents as NVTT) and isn't covered by any form of patent license, so they should be no less willing to provide NVTT. Debian apparently dislikes only actively-enforced patents, and I don't believe the S3TC patent is enforced in this context (only in GPU implementations).

If the patent is a real problem, dropping NVTT wouldn't help the game anyway, since we have our own S3TC decompression algorithm in the engine (to decompress the textures at runtime when the user doesn't have S3TC support). We'd have to remove that too, and then the game would totally fail to run for most Linux users.