myconid

Done! Code: https://github.com/myconid/0ad/tree/terrainalpha Anyone who wants to experiment can add new alpha maps using the UV layout of the default map (art/textures/terrain/alphamaps/blendtex.png) and then modifying the terrain xml and changing the "blendTex" entry.

All maps are square internally, so if a rectangular heightmap is given it has to cut off the parts that don't fit. Not a huge problem, I don't think.

If we store all the small alpha textures into a single, larger texture (with a predetermined x/y location for each blend type), each terrain xml could have an entry for a texture called "blendTex" that tells it what kind of blending to use. Basically, each terrain type could have its own blend textures. Really easy to implement, too.

Sure. http://i.imgur.com/cGcI7.jpg

I'm relieved, as I had no clue what in my changes could be causing this, other than the LOS changes that we ruled out. Still, we should get this fixed! I'll look at the minimap code tonight (it seems like it's using old-style OpenGL calls to do the drawing). Anyway, enough multi-multi-multi-tasking, back to multi-multi-tasking so I can get some work done.

NB: terrainCommon isn't cleaned up and may still change.

Okay, keep going. Let's switch to the modelmapping branch. Check if this also occurs there.

Ok, let's stick to the smoothlos branch for now because this is definitely a LOS-related bug. So far your findings tell us that this happens when preferglsl is true and happens regardless of whether smoothlos is enabled in the config or not. Is this correct?

Does it still happen when smoothlos is disabled?

Ok, think I got it! Try either merged or smoothlos. Awesome!

The thing is, the minimap depends on the LOS code, not on the water shader. Make sure you're using the right shaders & you've recompiled. If that doesn't help, does this also occur in "merged"?

I haven't given it much thought yet, but I could incorporate all the GLSL-related aspects of wraitii's code in my repo and then we could prepare a separate patch for all the ARB stuff. Seems easier to review.

Haven't been able to reproduce. Be more specific. Which map? GLSL or ARB? Yeah, it's not a problem.

k776, there have been a few bugfixes, so I'll generate new patches. To test, any heightmap image should do, just pick any one off Google. The image must be in RGB/A mode, as the engine can't load greyscale/indexed images (not my fault). Assuming 0-255 colour values. The image is currently truncated to a fixed size, but that should be easy to fix by resizing the map. The heightmap comes out looking flipped, though that is also easy to fix. A dialog to choose options would be nice, but these days I don't have much patience for GUI programming. OTOH, an erosion method would be awesome and I'd like to try it eventually. Already fixed but not committed. Done. Grass is not implemented in the ARB shaders. The grass texture is actually identical to the default texture, but also contains an alpha channel -- the alpha should be ignored, sounds like it isn't. I'm aware of this. Not sure if there's anything that can be done about it. The terrain adds new geometry that is higher than the terrain itself, and there's no way of telling the overlay renderers about that. I'm also aware of this. Not sure if it's my fault or a pre-existing issue with GLSL mode. Will look into it eventually. I think I know what you mean about the thing in the distance. That's due to how the grass algorithm works (no LOD). We may be able to tweak the algorithm to hide the artifacts by doing something wraitii suggested, and I think my grass texture isn't exactly of the finest artistic quality. The advantage of this grass? It looks like grass! Plus, it can be animated with a wind effect, so it could look nice. The real disadvantage? We're adding new geometry, though we aren't sorting the geometry and the wrong blending around the edges is really tricky to hide. But anyway, the grass effect is meant to be just a test. It's an xml file and something like 5 lines in the shaders, without changes in the engine, so let's just ignore it for now. Thanks for testing.

Shouldn't be hard to fix. Tomorrow! All the work is done on the GPU, so it depends on your hardware. Keep in mind that when you reveal the map, everything gets drawn, so it's normal that it becomes slower. Try using it on a smaller map (or on a more powerful GPU ).

Alright, tell me it's fixed.

Looks like you're both having the same issue (with the LOS). Ok, I'm off to bed and I'll look at that again tomorrow. ARGH. Figured it out. I'm such an idiot sometimes.

zoot, could you please try to recreate the problem in the "smoothlos" branch instead of "merged"? (needs update_workspaces and recompile)

How is this even possible... If smoothlos is disabled, the InterpolateLOS method shouldn't ever reach the point where it calls RecomputeTexture, yet there it is in your stacktrace. GAH.

Hmm, it's LOS-related then. When creating the textures, it looks like... And you say this only happens when smoothlos is false?

You could try playing with gdb, I guess. See if you can find a tutorial.

No problems here. I hope you remembered to recompile? Any change if you turn off smoothlos in the config? What about turning off fancywater?

Fixed. More info?? Btw, water surfaces can now receive shadows.

Sounds good! And listen to zoot's advice. Create a new branch from your ARB branch and then try "git merge" with my merged branch.

Alright, done! When you get a chance, give the "merged" branch a try with GLSL on. Let me know if anything else doesn't work.