myconid

Btw Gen.Kenobi, one small suggestion: if you are rendering the AO with Blender, you might want to avoid its "normalise" option. It exaggerates the effect and makes it look too contrasted. Otherwise, you can try fiddling with the AO value in the effectsSettings (in the material files).

Holy pasta, that looks spectacular! Just look at this: http://imgur.com/a/W12du If you can be more specific, I'll try to help. Yeah, only instanced things can use that at the moment. Maybe I should work on that next, just so it's more consistent. When you say "the gate" do you mean the entire structure with the walls etc, or just the door part? If it's the entire structure, maybe the door part could be moved to a prop instead?

Whoops, fixed.

Done. (there was a bug in the GLSL shader)

I'll give it a try now. It shouldn't be too hard to figure out. Since the GLSL and ARB shaders look different, the quick fix would be to go in the shaders/effects folder, find the "particle*" effects and remove the reference to the GLSL shader, so the ARB shader always gets used.

Well yes, if you put it like that! Don't get me wrong, this is just how I always work: I like to separate the regressions from the stuff that was already broken. It's my way of not going a step backward every time I take a step forward.

Mythos, I believe the GLSL implementation of that shader looks a little different from the ARB implementation. Nothing to do with these changes, I think.

I'm seeing a lot of reports on the net that Crossfire/SLI tend to have some very serious issues with non-AAA games that aren't explicitly tested and supported by AMD/Nvidia (those reports also mention the driver crashing in exactly the way you described it). I suspect Crossfire support for OpenGL isn't too great, either. However, you say that a much older version of Atlas didn't have this problem. I'd like to find out exactly what OpenGL functionality causes the crash. When/if you get a chance, roll back the SVN history until you find a version of Atlas that works. Revision 12299 may be a good place to start. If you are able to get any debug output it could be useful, though I'm not too hopeful a driver crash like this would show on a debugger. All that having been said, the workaround seems pretty solid and very few people use Crossfire. I'd say this is a low-priority problem, so we shouldn't worry too much about it - at least at this point.

Oh my, that's probably years out of date. Use the Intel driver if you can.

Mythos, done. Try now. (doesn't need recompile)

These effects have been created for use with the instancing renderer, so you shouldn't use them on units (at least for the moment). That said, specular mapping should be relatively easy to adapt - I'll see if I can do that now.

You need two new materials. Simplest way is to make a copy of player_trans_ao_parallax_spec and delete the effects you don't need. e.g: <material> <shader effect="model"/> <define name="USE_PLAYERCOLOR" value="1"/> <define name="USE_SPECULAR_MAP" value="1"/> <uniform name="effectSettings" value="1.0 50.0 0.0075 0.85"/> </material> In one of the materials just remove the "USE_PLAYERCOLOR" line to disable player color. The "50.0" value is the specular power (look at the comments in player_trans_ao_parallax_spec). In the actor, reference the material you created and add an entry for "specTex" that points to the specular map you want to load.

So we can conclude that either that is a very crappy utility or there's something wrong with your system... Just to be sure, let's assume the former: you need to find another utility/app that tries to use or test advanced OpenGL features (such as GLSL).

I've been making some pretty heavy modifications to the rendering code lately, so maybe it's my fault. Pretty surprising that there's a driver crash, though. If you urgently need the editor, you can roll back the SVN a few revisions until you find one that works for you (try revision 12299). Do you know how to do that? Btw, if this fixes it then we'll need to do some debugging, when you have time. Thanks. (AFAIK you're the first Crossfire user to try this code)

As there's no indication about what the problem might be, we have to try and narrow this down a little. This is suspicious and I'm curious if it's related: I know someone has already tested these changes on an Intel HD Graphics 3000 (on Mac), and they worked fine in both ARB and GLSL modes. So first of all, do any other GLSL-based games work on your PC? Maybe look for an OpenGL test utility to ensure your configuration works correctly. This one is at the top of my Google results - I can't vouch for its quality, as I haven't tried it. If you run 0ad in GLSL mode, are there any errors? Anything at all out of the ordinary (what happens when you move the camera)? How about in Atlas? Does the error you posted above appear in the logs in GLSL mode? Does the Fixed renderpath work for you?

At the moment they are, but that doesn't mean it's never ever going to happen. In fact, it shouldn't be too hard to add, and it's something we should add for completeness. But, for now, it makes no real difference where the settings ("uniform") are stored. If two materials have the same effects enabled ("define"), they map to the same shader internally, so there's no recompilation overhead or memory use. The uniforms are really fast to switch.

Thanks for letting me know, it looks amazing!

halcyonXII, that's because there's no render sorting in the terrain renderer, and it's probably not practical to try to add it. It's somewhat possible to hide the artifacts, by first painting the terrain with a simple grass texture and then painting the fancy grass on top. However, that material is more likely to be used for decals instead of terrain, where I believe this won't be a problem. Gen.Kenobi, you just add a new UV map in Blender and the rest is handled automatically. One thing, though: you should be careful to put the new UV map after the existing UV map, because that's where the shaders expect to find it.

While I didn't fix that, maybe somebody else did. That's as expected, and probably not worth worrying about/fixing. Yup. It'll work, but by using a GLSL shader by force. That is, it'll fail on PCs that don't have GLSL support.

I meant the non-GLSL shader path.

Awesome. Can you guys also test the ARB version a bit?

Btw, just to make sure, is smoothlos also set to false?

Ok, there are two things we can try: The first would be to try with materiamgr.quality = 0. This probably won't help, but it's worth a shot. The second would be to try this branch on git, that has a few bugfixes still not present on svn. It normally needs a recompile, but your error looks like something that might be fixable without one.

Try that now.

Hey LmScar13, unfortunately those errors don't give me much information! What are the other settings in your config? Other than the errors, do you see any graphical problems?