myconid

You don't need to. From the first link you posted. In other words, you can use it any way you like, BUT you need to credit the author in the LICENSE.TXT file. You only need to contact the author if the image is under "all rights reserved" copyright. Not when it's in the public domain or CC licensed. The second image is CC-BY-SA. The "sharealike" part means you need to release any modifications under the same license, which I believe is the case with 0ad's art assets.

Ah, from the third screenshot it looks like this issue was present in A10, but it wasn't as obvious. I think the problem is somewhere in the unit renderer or the driver. Something wrong with the VBO/Array wrappers/implementations? This might help: set novbo = true, preferglsl = false, gentangents = false.

That's true, actually. The cached model files have moved to a new version that have multiple UVs, which older versions of the engine didn't support.

It looks like the graphic errors only happen on units. The changes I've been making shouldn't affect units at all, as they are rendered separately. Do you get similar problems with ARB? Do you get similar problems in older versions when preferglsl was true? Make sure you haven't enabled gpuskinning by accident.

Okay, is there anything different about those models from the camp model that Zaggy has issues with?

Afraid not. Smooth shading uses a different normal for every vertex, whereas flat shading uses the same normal for all face vertices and these are generated in your 3d software, not in the engine. I could recalculate the normals when generating tangents, but that would force smooth shading off on everything. The best solution is to separate the smooth surfaces from the main mesh, add them as a prop and use a different material that has no parallax...

There are two problems here. The terrain thing is caused by your GPU or driver. The errors are caused by your cache being out of date. Delete that and the errors should go away.

I think someone broke the roman corral...

Doubtful. Might as well give it a shot, though. That makes sense, actually, as I don't think parallax and smooth shading can mix very well... Where you use smooth shading you can try setting the heightmap values to white, to disable parallax.

There's neither parallax nor normal mapping on that part of the model... and I don't get that artifact at all. Did you find a way to fix it?

Zaggy, that's def due to parallax. I'll take a look at it when it's committed.

Set materialmgr.quality to something like 5. If you're lucky, everything except parallax should work. You might still run into errors if people haven't been setting their "alternative"s up correctly, though nothing fatal.

Wijit, that's similar to the problems we had with fabio's old card. There are too many "varying" interpolated variables for the hardware to handle. We tried working around it at some point, even. While we did get it to work on his hardware initially, it completely broke shadows for me (yet another driver bug, I think), so I gave up on it in the end.

"Receive Transparent" option in Material/Shadow?

You need to have an "alternative" entry that points to a material. There was some discussion about that in this thread. Oops, sorry. I thought it was Wijitmaker. Hmm, it shouldn't matter (much), I think. The shader applies the transparency from the diffuse texture to the AO as well. No. The terrain blending wasn't playing nice with it, so I removed it. Maybe at some point I'll have a random flash of genius and return to it. Works for me. Go ahead and commit it, if you haven't already.

preferglsl = false gentangents = false smoothlos = false

Those companies are law firms with game dev departments. If they want to shut us down, they don't need a legal technicality, they can just sue with a completely random accusation, take us offline and wait until the project is dead and drowning in legal fees. It's what today's law was designed to do, unfortunately, and there's little we can do to prepare for that possibility. However, properly crediting people for their work is a completely different topic. The texture licensing terms in particular are rather vague. IANAL, but these are my thoughts (I think most of this is obvious/common sense): Even CC-BY/-SA needs attribution (hence the BY). If textures were obtained from other FOSS projects or from DeviantArt, we need to attribute them. Textures that are used with permission should be marked as such. The project should keep a copy of any emails exchanged, in case the team member retires and they get lost. Related to #2, there needs to be a clear distinction between textures that are under an open license and those under the CGTextures license, in case there are other projects that want to reuse 0ad's textures. Generally-speaking, photographs/literal copies of public domain works that are not transformative do not get a new copyright. This may depend on regional laws. We might want to pick a country and stick to that country's law. Lots of people here aren't from the US (including me), but US law has fair use, and the EFF is based in the US. AFAIK, US law is also more friendly than European law regarding point #4. Then again, a ridiculous number of trolls are active in the US...

It's telling you that your graphics card is too old to use the GLSL shaders, so you need to disable them in the config. You need support for at least OpenGL 2.1/GLSL 1.2.

That is by design for the triplanar material. If it happens with anything else, then I'd like to know about it... Check if the terrains you're using have a "props" entry, as there might be a rotation specified.

Nice, thanks for testing! Dunno if this'll work, but you can try this: go into graphics/ObjectEntry.cpp after this line (137) textureProps.SetWrap(GL_CLAMP_TO_EDGE); add this: textureProps.SetMaxAnisotropy(X); where X is the amount of filtering you want. Try 2, 4 or 8.

Turn up the texture filtering in your graphics card's utility thingie...

Tried that tool with Wine, but none of the options looked correct when imported into Blender. Though you're definitely right, the problem is Blender's weirdness of using Z as the vertical axis. Some of the models define "up_axis" as Z_UP and some as Y_UP. I'd guess Y_UP might be problematic, though I'm uncertain if it's so clear-cut. I'm testing the following solution for swapping left/right-handed coord-systems and it appears to work (with celt_civic3.dae, at least): Swap trans.Y, trans.Z trans.Y = -trans.Y rot.X = 0

Indeed. On that point, I'm trying to get Blender's Collada importer to cooperate. I've imported a few random models and most of them import correctly, but some come out in the wrong orientation. Do you know anything that might help me? I've tried converting to an intermediate format (.obj) and importing that, but annoyingly it looks like it discards the attachpoint info. Thanks, fixed.

I don't remember how I did that. I doubt it was anything too complicated. One thing I can mention is that the way the AO is applied to the model is with this equation: (2 * ao * colour). This is a (over-)simplification of how Photoshop/GIMP do the "multiply" blending mode, and there's also a setting in the materials that controls AO intensity. As a result, if you bake normalised AO (read: contrast-stretched AO), you can roughly control how much to mix in through the material setting. If you bake unnormalised AO, it won't look too dark since this is doing "multiply". I think you need to experiment and get acquainted with the options, and decide what looks better. If you want any changes made, this is the place to ask.

The easiest and most efficient way to do that would be to use additional geometry.