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

[zoot]

Are we even using self-light? If not, I would just disable it for all materials and make people create a new material if they want self lighting. Seems less likely to cause confusion.

I believe it's the right approach to delete it from that material. Someone put it in there by mistake (no reason for a 'basic_specmap' object to outright glow). Self-light should be neat for embers in rubble actors and the like, though.

[myconid]

This might simply be a float precision thing... Try this: go in the basic_specmap material and change the second value in the "effectsSettings" uniform to something smaller like 15. It's currently set at 50, which is massive.

[zoot]

This might simply be a float precision thing... Try this: go in the basic_specmap material and change the second value in the "effectsSettings" uniform to something smaller like 15. It's currently set at 50, which is massive.

That actually seems to make it a bit worse. And if I reduce it to 0, it's really bad (like, across the whole rock all the time).

[myconid]

That actually seems to make it a bit worse. And if I reduce it to 0, it's really bad (like, across the whole rock all the time).

So the uniforms and shader are working fine... it's definitely the specular texture not loading properly, then.

It works perfectly here, though, and since other specular mapped models work fine for you (yes?), it's not at all clear what the problem is...

[zoot]

It works perfectly here, though, and since other specular mapped models work fine for you (yes?), it's not at all clear what the problem is...

Can you name a specular mapped actor that you are certain is set up correctly?

[myconid]

I think the Iberian CC has it on the roof, and that looked correct in that gif you'd posted.

[zoot]

I think the Iberian CC has it on the roof, and that looked correct in that gif you'd posted.

Indeed, I see no artifacts on that model, even when zoomed in closely.

[Yves]

The minimap is now broken when using renderpath = fixed.

The general question is if we still want to support this.

I've tested it quickly on punjab3 and apart from the minimap it still seems to work.

EDIT:

Another issue with the fixed renderpath is that rivers are red sometimes.

Punjab is not in egypt so it's not one of the plagues from the bible.

EDIT:

With the help of priests the water is now green.

You can see on the second screenshots where the color seems to come from...

[historic_bruno]

The minimap is now broken when using renderpath = fixed.

The general question is if we still want to support this.

Yes (This would qualify as a regression especially since it was part of fixing a case that almost no one will use - GLSL)

[Jeru]

With the help of priests the water is now green.

Algal bloom?

[zoot]

Algal bloom?

Yeah, put that on the release notes "New effects for fixed-renderpath!"

Once again, I'll have to implore y'all to standardize on Git (or whatever DVCS you may prefer). Development suffers when you can't even fix bugs without worrying that you may break the pending release as a consequence.

Edited September 1, 2012 by zoot

[myconid]

Yes (This would qualify as a regression especially since it was part of fixing a case that almost no one will use - GLSL)

You mean there are people who use the fixed renderpath?

Anyway, this shouldn't be a problem. I know exactly how to fix it.

Btw, is there a set date for Alpha 11 yet?

[historic_bruno]

You mean there are people who use the fixed renderpath?

Anyway, this shouldn't be a problem. I know exactly how to fix it.

Btw, is there a set date for Alpha 11 yet?

Yeah, fixed renderpath can be used when the person's hardware has a buggy shader implementation, to at least make the game playable without crashing. We already detect a few such cases in hwdetect.js: Mesa DRI R1/2/300 drivers, GeForce FX, and SiS Mirage 3. I'm sure there are others we don't know about yet, so it's nice to keep the option available.

We're doing testing today in staff multiplayer matches, if we don't find any more release blockers, it's safe to assume the final build and packaging will occur within days.

[myconid]

Yeah, fixed renderpath can be used when the person's hardware has a buggy shader implementation, to at least make the game playable without crashing. We already detect a few such cases in hwdetect.js: Mesa DRI R1/2/300 drivers, GeForce FX, and SiS Mirage 3. I'm sure there are others we don't know about yet, so it's nice to keep the option available.

Okay, I was joking, but joking aside...

<rant>

How many users actually still use such old hardware? How many of those people will still use that hardware when the game is finally released? How many of those people have a realistic expectation that a modern game should work on their hardware?

Many commercial games don't even support 4-year-old hardware with official drivers, let alone 10-year-old hardware with unusable drivers. I know we aren't a commercial enterprise, so our goals and motivations are somewhat different, however what we are attempting is more ambitious than porting Crysis (2008) to DirectX 8 hardware (2001)!

Surely, the percentage of users with hardware released circa 0 A.D. is already below 5% (and that's being generous). My concern as a programmer is that the fixed renderpath works completely differently from the shader renderpath, and maintaining it takes a disproportionate amount of development time relative to the number of people who benefit from it. Moreover, I think all the effort we put into testing it and keeping it alive is going to waste, because by the time the game is released, almost no-one will have a use for it. Finally, the mixing of ancient OpenGL code with modern shader code is introducing bugs into the engine, as we are basically trying to sandwich two engines into one, and that ultimately results in a worse experience for all players.

Therefore, my recommendation is to drop fixed support now, before we spend another 100 hours working on it just to decide we don't need it after all. We should focus development on making GLSL mode as feature-rich as possible, while also porting a limited number of features to ARB, and making ARB rock-solid for use as a fallback on tomorrow's older hardware.

</rant>

[historic_bruno]

Alternative POV: consider these issues before breaking a currently supported platform, not after they are broken, and especially not ~a week before a new release It's worth discussing at some point, but keep in mind that up to now, supporting even old hardware has been much more important to 0 A.D. than flashy new graphics features.

[zoot]

No irreversible changes has been made (other perhaps than the time Myconid has put into it ).

[historic_bruno]

I was thinking earlier about GLSL and ARB. Doesn't it seem more wasteful to duplicate all the same features for two different shaders than to support them for only one type of shader and still have a decent fallback for old hardware? Just think if a bug is found in one implementation of windy trees or parallax (as an example) it has to be fixed in the other and if a parameter changes in one, it has to be changed in the other. Seems like potentially a lot of maintenance going forward. At least with the fixed renderpath we can mostly ignore all the new advanced rendering stuff we add which is purely eye candy, and as long as we don't break it we're fine.

[myconid]

My previous comment was mostly in response to Yves' question about why I think the fixed renderpath should be removed in later versions of the game. I'm not saying that the fixed renderpath should be eliminated right now, of course. We'll definitely have a fully working fixed renderpath in Alpha 11, and I'm not the type to remove it without agreement from the rest of the team (I hope that's clear).

The question is if we should keep it in the future, or start phasing it out. Some time ago, I was talking about this on IRC with Philip and k776, and as far as I can recall there was agreement that ARB will become the fallback mode, while fixed should be retired.

Why keep ARB instead of fixed? There is a lot of overlap between GLSL and ARB code (on the CPU side), so we don't have to maintain what are essentially two different engines inside a massive if statement. ARB doesn't have to implement all the effects of GLSL if we don't want to maintain them - it can be left alone too if we wish (I haven't needed to change a single line of the ARB shaders in implementing all these changes to the GLSL and CPU code, though I can't say the same for the fixed renderpath..!).

[historic_bruno]

Fixed renderpath looks much better now This is a bit weird, actors aren't being shaded in LOS, but that may have been a problem before?

And for lack of a better place to mention this, the "basic_trans_parallax_spec.xml" material references an alternate material "basic_trans_spec.xml" which doesn't exist.

[Zeta1127]

Is a nVidia GeForce 6200 too old for all of these post-processing effects?

[Mythos_Ruler]

And for lack of a better place to mention this, the "basic_trans_parallax_spec.xml" material references an alternate material "basic_trans_spec.xml" which doesn't exist.

We should make one.

[myconid]

This is a bit weird, actors aren't being shaded in LOS, but that may have been a problem before?

From what I remember, the fixed renderpath doesn't "paint" LOS on the models. Instead, it depends on culling to hide the models, so that annoying model-popping behaviour is made even worse.

And for lack of a better place to mention this, the "basic_trans_parallax_spec.xml" material references an alternate material "basic_trans_spec.xml" which doesn't exist.

Thanks. Mythos, can you also check what's up with the decal of the Roman CC? It seems to have tons of specularity on it.

[myconid]

Is a nVidia GeForce 6200 too old for all of these post-processing effects?

I think they'll work. They need OpenGL 2.1, which your card seems to support.

[Mythos_Ruler]

Mythos, can you also check what's up with the decal of the Roman CC? It seems to have tons of specularity on it.

Yeah, that only seems to be happening intermittently, not all the time. I don't know what triggers it yet.

[historic_bruno]

From what I remember, the fixed renderpath doesn't "paint" LOS on the models. Instead, it depends on culling to hide the models, so that annoying model-popping behaviour is made even worse.

It seems you fixed that too, thanks http://trac.wildfiregames.com/changeset/12593