[Post-processing effects test (SSAO/HDR/Bloom)]

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).

[Post-processing effects test (SSAO/HDR/Bloom)]

Holy pasta, that looks spectacular! Just look at this: http://imgur.com/a/W12du

looks like that Parallax Stuff on Transparent and on Player Collor behaves weirdly.

If you can be more specific, I'll try to help.

Also, looks like the new shader does not applies to animations, so the gate fails to load the material.

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?

[Post-processing effects test (SSAO/HDR/Bloom)]

Whoops, fixed.

[Post-processing effects test (SSAO/HDR/Bloom)]

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

[Post-processing effects test (SSAO/HDR/Bloom)]

Hmm, can the GLSL version be tweaked to have identical looking particles? It's a shame if we have all these nice new effects but particles become ugly.

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

It has something to do with these changes, because it didn't happen before. But I guess what you mean is that the particle shaders need fixed, rather than your new code needing fixed. Amirite?

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

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.

[SVN Atlas Scenario Editor causes GFX card crash?]

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.

[AO\Shader problem]

Thing is, my graphics driver is an Acer driver, not a standard Intel driver.

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

[Post-processing effects test (SSAO/HDR/Bloom)]

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

[Post-processing effects test (SSAO/HDR/Bloom)]

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

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.

[AO\Shader problem]

it said my OpenGL version is 3.1, but when I click version details, the program crashes.

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).

[SVN Atlas Scenario Editor causes GFX card crash?]

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)

[AO\Shader problem]

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:

With GLSL, 0ad has only ever showed a black screen on my computer.

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?

[Revamping the Actor Editor (merging with ActorViewer)]

Already asked myconid about that... sounds like that it's not going to happen. The intensity values are in the material file.

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

Thanks! Just thought I should mention that I have added the AO Shader to the Rock_Scandiv.

If you haven't noticed it yet, go take a small look

Thanks for letting me know, it looks amazing!

[Post-processing effects test (SSAO/HDR/Bloom)]

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

Well, there is something that is odd: last week I posted some issues with flickering, probably related to normals and my macbook's drivers. I have really tried to trigger this flickering with the current GLSL code, but I guess I have to accept it is gone

While I didn't fix that, maybe somebody else did.

Now, I did run into a problem when setting the renderpath to fixed (with preferglsl, gentangents, and smoothlos set to true, quality level 10). This gave a problem related to the LOS, I think. Setting smoothlos to false circumvents the problem. Maybe the smoothlos setting should be ignored if the renderpath is fixed (or there may be a fix, I don't know). A stacktrace can be found in the attachment, the crash happens right after pressing Start Game.

That's as expected, and probably not worth worrying about/fixing.

Is that by setting preferglsl and gentangents to false?

Yup.

Incidentally, is smoothlos supposed to work when preferglsl is set to false?

It'll work, but by using a GLSL shader by force. That is, it'll fail on PCs that don't have GLSL support.

[Post-processing effects test (SSAO/HDR/Bloom)]

I meant the non-GLSL shader path.

[Post-processing effects test (SSAO/HDR/Bloom)]

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

[AO\Shader problem]

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

[AO\Shader problem]

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.

[Post-processing effects test (SSAO/HDR/Bloom)]

Try that now.

[AO\Shader problem]

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?