myconid

historic, please try again now (needs recompile). I took a screenshot and I can't see anything in Gimp, not even with maxed brightness/contrast - your monitor must be so bright it's giving you a tan! Btw, zoot, I want to look into that "shimmering rock" problem you encountered. I haven't been able to reproduce it. Does it happen always, or is it triggered by something?

Wait, I'm confuzzled. Don't his edits say he didn't have that problem after all, or was I reading them wrong..? No, you shall not be banned, but you must be punished!!

Fixed?

Fixed?

Thanks, that should be fixed now.

Just committed a fix for that weird bug. The sky, minimap and healthbars are now rendered with shaders, except when using the fixed renderpath. I'd like to ask people to test this ASAP and report anything strange. Alpha 11 is just around the corner and I don't want to add any new bugs...

I think it varies slightly from one computer to the other. Still not exactly sure what causes it, but at least I know how to fix it.

I'm a little busy with a whole lot of other things right now, but I'm sure someone will find a chance to add this some day. Maybe open a new ticket for it on Trac.

You can hack the game to get rid of the black thing by following the instructions I wrote in this post. It doesn't need the game to be rebuilt.

They look fine here... Anyway, I've figured out historic/zaggy's problem with the water. The minimap, health bars and sky have one thing in common: they are all drawn with ancient OpenGL 1.2-era commands. For some reason, they don't like the more modern shader stuff. To reproduce the bug, I added the Roman barracks at an empty location on Oasis 10. I zoomed in completely (until inside the building, so it's the only thing being drawn besides terrain) and then out, and boom there it is. The sky becomes really dark (hence the water problem), while the minimap and health bars become black. So far, I've started giving the sky renderer a little face-lift. That works like a charm now, but it's not ready for commit just yet.

That's a very useful datapoint, dvangennip! Btw, would you be able to recreate the problem for testing purposes? I haven't forgotten about that. It might be related, though I kind of think the minimap thing you experienced is a separate engine bug. Will try to track that down too, as I'd like to have that fixed. Hmm.. That's probably the old specularity. I wonder if there's a material missing the "specularPower" line or something. See if you can find which actor that is.

This feels like an engine bug, not a driver issue. My instinct tells me this has something to do with GL_BLEND or GL_DEPTH_TEST or similar, though it's not immediately obvious where to look for the problem and there's not enough info to take a guess from. I think I'll just do a thorough cleanup session and hopefully this won't resurface again.

From Wikipedia: It also links to this essay: http://www.historyne...ncient-rome.htm

Have you ever played a game called Seven Kingdoms? It's always been one of my fav strategy games, and it was made free/open source a couple of years ago. Anyway, a very interesting game meachanic is the spy units, which you can dress in the enemy's colours and send them into their base. You can give them commands (even though they look like enemy units) or you can just leave them be and they'll stay undercover and behave like normal enemy units. Their main functions are: They can change to any player colours on command, as long as there's nobody around. They can do assassinations. If you put them in a fort, you can use them to assassinate a general or king. They can capture buildings. If they are promoted to generals and placed in a fort, they can capture that fort and any soldiers garrisoned in it. If they are alone in any building (no workers in a factory, no soldiers in a fort, etc), they can capture that building. They can also bribe a general to defect, which also captures the building and soldiers. If placed in a village, they can lower the loyalty of the civilians, which can lead to lower tax revenue and even riots. They can do sabotage. If placed in a mine or factory, they can lower production or even stop it completely. They can tell you the status of a building and steal government secrets. How many soldiers are garrisoned in it, what resources are stored in it, tell you a kingdom's amount of resources, about alliances between kingdoms, population data, find out the locations of enemy spies in your kingdom... If placed in your own buildings, they do counter-espionage. That is, they find and arrest enemy spies. (Their success is based on their spying skill level, which typically increases with the amount of time they remain idle "sleepers"). If you have several spies working together, you can tear a kingdom apart and they'll never know what hit them. That game didn't have a way of capturing a building by force directly, afaik. As soon as a building was attacked, all the soldiers came out so the fighting happened outside. You could then send in a spy to do the capturing, if you wanted it. Also, if you placed spies in a friendly/allied kingdom and they were discovered, you took a reputation hit or in the worst case ruined your friendly status with that kingdom. Not sure if any of this can work in 0ad, but I really like the idea of spies peeking behind enemy lines, stealing resources, bribing generals to capture buildings/soldiers, sabotaging unit production and so on.

You mean the ones used for UV unwrapping? No, don't think so. I'll try to explain what is going wrong. The way parallax works, it expects the normal to be constant across the polygon (i.e. that the surface is flat). In the case of smoothed surfaces like in the Iberian buildings, the normal is different at each vertex, so the surface is "curved" and parallax doesn't have the information to deal with that in the shader. To visualise this, consider that the parallax effect moves the surface inwards in varying degrees to create a 3d effect. Where the surface has been pushed in, it reveals what lies behind it, so to find that the effect raytraces in the heightmap along the view direction until it hits something else. The raytracing step assumes that the surface is flat, and the position of the object behind is assumed to have the same normal as the position in front - which are false when the surface is curved! Hence the visual distortion. Hope that makes sense. Anyway, the technical solutions to this problem that I can think of would be to either calculate and pass the curvature information to the shader, or to add a second set of flat normals for use with parallax (while smoothed normals are used for regular shading). Both of these sound crazy wasteful to me, so I'd recommend to just not use parallax on smoothed surfaces. It's better to disable it completely on buildings with too many smoothed surfaces, and where the smoothed surfaces aren't visible (like that Roman camp model) just get rid of the smoothing on the entire model. Normal and specular mapping will still work correctly, so hopefully you can get good results by making the most of those (hint: use a normalmap generated with a Sobel or Prewitt operator to get a more powerful effect). (To disable the parallax, choose or create a material that doesn't use the effect. It doesn't matter if the texture has a heightmap in it for use with other buildings that don't have this problem, as when parallax isn't used it will simply be ignored)

That happens on (some?) smoothed surfaces when using parallax. There was some discussion about it on pages 51/52. Enrique says it only happens on polygons that were set to smoothed but are flat, and suggested a way to fix it. I'm not entirely convinced the parallax effect can play nice with smoothed surfaces at all, but it's worth trying what he suggested (and let us know if it helps!).

Ok, thanks Deiz. historic, when exactly did the water go black? Can you find a way to reproduce the problem?

Deiz, a fix has been committed. Please let me know if it helps.

Ah, thanks (when you said "status bars" I thought you meant something different). I'm 100% positive these are all related, and must be caused by a blending issue. Won't be too hard to track down.

Deiz: At first I thought it might be using the wrong UV set for texturing, though from your new screenshots it looks like it's in fact being completely random. Then there's the lighter/darker thing, where the mapping is similar, but the lighting changes. So it must be something in the modelrenderer - for some reason, the parameters are sometimes not bound correctly to the shaders! Will look into this (again). historic_bruno/wraitii: I need more info... I can guess what might be up with the water, the minimap was already bugged in GLSL mode (or is this ARB mode). What's wrong with the LOS and the status bars?

If you already have pkg-config installed but it's not detected, you can tell it where to look export PKG_CONFIG_PATH=...

I'm just using the defaults for everything: no normalisation, attenuation distance 10, constant QMC, no falloff. Blender v2.63a. As for loading the props, that's unlikely to happen. The props information is stored in the actor files, which means the script would have to parse the xml, find the props, load them up and attach them in the right places. I think only the Greek buildings have a problem because their main structures are divided up into pieces. The best solution is to store those models in one piece and duplicate some of the textures instead (or combine them in a bigger texture).

You need to "reveal map" from the dev console. Like I said above, this hack disables all the LOS, so obviously while it gets the job done for now, it's unacceptable for the long term. The right way to do this will be to modify the simulation, not the renderer. The process to initialise a cutscene should both tell the renderer to enable sky rendering and also tell the LOS updating component (which is in the simulation part of the engine) to clear the LOS completely (i.e. LOS is still rendered, but it's invisible).

Apologies for the delay. I've checked the memory alignment in the renderers and found nothing out of the ordinary (that I can see, anyway). I suppose that's a good thing, but we still have no solution for your problem nor any workaround that might improve it. Let's hope the driver developers will have a fix for it, eventually.

Yeah, the water needs to be modified separately. Changed my post above to include that.