What causes these jagged edges in Torque (see picture)?

#1 Looks like Z-fighting to me (when two polys overlap, the graphics card doesn't know which one is supposed to be on top and attempts to draw both, which causes jaggies like that). Have you tried tweaking the terrain and waterblock to resolve the ambiguity?

#2 What do you mean by tweaking? Lowering/raising?

#3 move forward your front clip plane ,or use w buffer, or use higher res (32b) z-buffer,

#4 I experienced this problem with torque when I used 16bit mode, but it worked in 32 bit. I tried on both a gf2 mx and a gf4 ti.

#5 Yeah, I second that... seems to be caused by 16 bit mode - switch to 32 bit colors and it should be gone...

#6 Thanks I'll try that. Unfortunately my PC runs like crap in 32bit mode. There's something wrong with a piece of hardware (probably gfx card or motherboard) inside, but I've given up trying to find which one.

#7 I have noticed it in 32bit mode at really great lenghts of distance.

#8 I only had that in 16 bit too... never have it in 32 bit mode....
I wonder if its still there with Melv's water... should check that out.

#9 Yeah, with Melv's water it's much better I guess cause there aren't such sharp "edges" anymore... didn't try it with "16bit-Melv" yet, though :p
... but with "32bit-Melv" you can go as high as you want, it always looks smooth... :)
And now you can set the "minAlpha" value very low, so the outter areas of the blocks are almost transparent, which also helps...

#10 I seem to remember that Tribes 2 also had this similar jagged edge problem in 16 bit, but was fine in 32.

#11 it's a z-buffer problem and yes, T2 has it as well.

as I remember, there's less z-buffer in 16-bit mode, which is why the problem is much worse there. in 32-bit you only see it very rarely. the engine doesn't know quite which part is in front of which since they have the same z-buffer depths.(*)
melv's water solves that mostly because due to the transparency the edge doesn't look as ugly anymore.

I don't think there's a solution to this problem without serious changes deep in the engine. :-(


(*) edit: here's why I think you see the jaggies:
simplified, you can consider it to be a rounding problem. so you have water, and terrain, and their distance from the camera:

table: water real / water rounded || terrain real / rounded || which is front

12.4 / 12 || 12.7 / 13 || water (correct)
12.6 / 13 || 12.9 / 13 || terrain (wrong)
12.9 / 13 || 13.2 / 13 || terrain (wrong)
13.3 / 13 || 13.6 / 14 || water (correct)

and so on, alternating between water and terrain. at first glance, it looks like the engine favouring terrain when both values are equal is the bug. on second thought, it doesn't make much of a difference because it could well be the other way around, with the water being UNDER the terrain. not favouring terrain there would probably be a dumb idea since it lets water show up where no water is. I'd rather take the jaggy edges.

#12 Running in 32bit certainly gets rid of the problem. Thanks.

#13 Any other solution other than always running in 32 bit?

#14 Z fighting is an issue in any game. All you can do is try to minimize it. You can either increase the accuracy of the z buffer by using a larger bit depth such as 32 bit, use a w buffer (which is more accurate..does torque support that?) or play with your geometry to help reduce it. It is caused by geometry that is too close together. They are withint the margin of error distance apart so the engine gets confused and they "fight" for z-order. Try seperating the problem areas a little bit. This can sometimes help if you have no other choice.

#15 What is "Melv's water"? I was unable to find it as a resource.

#16 Dan : because it's part of HEAD now iirc :)

#17 Nicolas,

Thanks!