zoot

Definitely looks better, but have you tried tweaking the 'blending range'? In GPU Gems, they seem to obtain rather epic results with a range of 'roughly 10 to 20 degrees'.

Can we mitigate texture stretching with something like triplanar mapping?

Oh, yeah, that's probably it.

Shadows and water reflections are disabled by default when I run the game, also prior to patching it, so I assume this is down to my poor hardware. By the way, I guess self-shadowing can't be done with shadow mapping? It seems to detract quite a bit from the visual fidelity:

I wouldn't know how to enable anti-aliasing, though

I seem to be missing the snow texture itself:

I think the key to successful open source development is to stop worrying and love the bomb present solutions instead. There is nothing in this suggestion, nor in the deliberations about gates, that will prevent the pathfinder from being optimized.

It works

Well, that's the thing - that big cliff does have overhangs. Even if we pretend that it just goes vertically down, we still can't do it in the current implementation, because there will always be a smoothening between the 'high' tile and the 'low' tile, which leads to the formation of a slope.

Can you give an example of a pathfinding scenario with this system that would require a complete rewrite of the pathfinder?

Would you be able to model something like this with Atlas' height maps? Not a chance.

Supposedly, Ensemble Studios used vector fields in Halo Wars as a direct consequence of hating the height map based system they used in AoE3.

One thing in 0 A.D. that, in my opinion, doesn't really do the rest of the modelling justice, and makes the game feel somewhat like a dying remnant from the 90's, is the terrain. If you've noticed, the terrain is always smoothened and curved in a simple, almost pastoral way: Does this scream war and terror to you? Probably not. What you'd want is more like this: The main problem is that the engine uses simple height maps for terrain which do not allow horizontal displacement of the terrain mesh. So while the vertical placement of the terrain vertices may vary greatly from map to map, their horizontal placement is essentially identical. This gives every map a sort of "I've seen this movie before" kind of feel, in my experience. This all made me wonder if we could use vector fields for terrain instead of height maps/fields. Basically, this would attach a 3-dimensional displacement vector to each terrain vertex or tile, so instead of being limited to this: ... you would be able to do something like this: I assume this displacement could be done with simple operations in a vertex shader, so the performance impact is limited. Clearly, a 3-dimensional vector requires 3 times as much memory as an 1-dimensional one, but we could probably compress it so only vertices that actually has been displaced relative to the height map will be stored 3-dimensionally. It also has implications for the pathfinder, but not all that much, as you'd just need to extend the definition of what is passable terrain. What could be a problem, though, is how to manipulate the vertices accurately enough in Atlas. I don't have a solution for this, but maybe someone else could come up with something. Thoughts?

Maybe one day we could add a relief mapping material for some sweet-looking terrain features. This scene has a triangle count of 2:

Now testing on my netbook with an 'Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)' graphics adapter. Tree animations works with no issue ( ). Parallax mapping works nicely in Atlas: It also works in-game, though lightning of the terrain flickers back and forth several times a second (normal, darker, normal, darker etc.) If I disable GLSL, there is no flickering. If I enable GLSL with the unpatched master branch, I also experience flickering. (Conclusion: Flickering not due to your changes, but due to a problem in the GLSL support, hardware or software.)

Within the past two months, Valve Software and Unity Technologies has both announced Linux support for their respective game engines. Maybe you can teach them a thing or two

Thanks!

No, it's still bad, though the geometry doesn't seem to be messed up: By the way, any chance you could push your work to Github or a similar site as you go along, possibly as a branch off this? Makes it a lot easier for testers to juggle between the various versions.

Here is my impression of how Sonarpulse's suggestion would work: The idea is to split the current SVN repository into three Git repositories: Code for the engine code, Data for art and scripts and Binaries for autobuilt executables. Additionally, there will be a Programmers repository which has Code and Data as its submodules and an Artists repository which has Data and a shallow clone of Binaries as its submodules. Comments?

Well, technically, no one would be making changes to a shallow clone of the binaries branch itself, am I right? No one needs to manually edit the binaries. So if the shallow cloning is compatible with submodules this might just work...?

Wouldn't the binaries branch still be prohibitively big to download?

I'm on a fairly old machine with an integrated graphics card listed as: "Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)" When the patch is applied and preferglsl and gentangents are set to true, I get this: When preferglsl and gentangents are set to false, the game looks normal.

I think there would still be an issue with maneuverability in the minimal space on the wall.

As a nitpick, the black buttons along the bottom would break the design less if they had the same dusty brownish background as the formation buttons.

Sorry, you must have meant this. That was indeed a team proposal, but as the thread progressed, they seem to have settled on a much narrower redesign of just the unit panel.