zoot

I doubt that. See this page for example before and after shots. The 'before' shot looks essentially identical to our current terrain blending.

Have any of you heard of something called 'vertex blending' or 'vertex color blending'? I can't find any really concise information about it, but it sounds like a way to do it without any masks.

Blending of two different terrain textures currently look quite bad: Any ideas for how we might solve this? (Relevant ticket.)

I doubt this would scale to a full lake or river, because we can't tile it like the current water shader. You would need to run a full simulation of the entire body of water at all times or you would get weird artifacts where the ripples would cut off when you move the camera. Cool demo, though.

It's working (save for a minor fix)! Water has never looked so pretty on this crummy netbook. Well done.

I did this: TEMP temporary; MOV temporary, 0.8; POW fresnel, fresnel.x, temporary.x; Which seemed to work, because now the error has moved to another line: ERROR: Failed to compile fragment program 'shaders/arb/water_high.fp' (line 93): line 90, char 45: error: expected scalar suffix ERROR: CRenderer::EndFrame: GL errors occurred If you can fix all errors of this type and push to Github, I'll pull and try again.

I see. Yeah, I'm using an Intel card so all bets are off Could it be that it has a problem with literals and you'd need to MOV the values into variables first?

According to this spec, the POW instruction takes 2 inputs while you seem to give it 3: Instruction Inputs Output Description ----------- ------ ------ -------------------------------- POW s,s ssss exponentiate

I'm positive. I even did a 'git reset' and recompiled to be certain. If I do that, the error 'moves' to char 14: ERROR: Failed to compile fragment program 'shaders/arb/water_high.fp' (line 82): line 76, char 14: error: expected scalar suffix ERROR: CRenderer::EndFrame: GL errors occurred

Ah, yes. I deleted shaders/glsl. The result is the same. Also, I get this error: ERROR: Failed to compile fragment program 'shaders/arb/water_high.fp' (line 82): line 76, char 25: error: expected scalar suffix ERROR: CRenderer::EndFrame: GL errors occurred

This is what I get with the waterShader branch: Also, the surface is static (unanimated). By the way, does anyone know of a way to ascertain that I am using the ARB shader?

Seems like it: $ file source/renderer/TerrainRenderer.cpp source/renderer/TerrainRenderer.cpp: ASCII English text, with CRLF line terminators historic_bruno seemed to have issues with this too - maybe he can chime in with a solution...

I just found this on 0 A.D.'s Facebook wall: motion captured Hoplite animations (Didn't remember seeing it posted elsewhere on the forum, sorry if duplicate.)

And if you don't know how to do branches just yet, I can even do them for you. Such is the glory of Git. Main thing is that you get the code up so we can begin tinkering with it.

Github is the ideal solution if you want feedback on your code so you can clean it up prior to it being submitted to Trac. They have many good tutorials themselves, starting here. You will want to fork myconid's repo once you're set up. It should all be quite simple and even enjoyable once you get started.

Okay, now I don't get any errors in Atlas, but the original issue has reappeared Not sure what happened, since it is not likely to have anything to do with GL being enabled. Maybe I misinterpreted the result of my first test of 2.9 and the issue was never fixed in the first place.

If you manage to convert all the modelmapping shaders to ARB, that should increase the chance of getting them into A11 considerably (because it would remove the need for an unwieldy GLSL compatibility database). If you feel like pushing any of your work to Github, I'd be happy to help test/debug.

True. Maybe if you all become more keen on using Git one day, someone trusted could maintain a more liberal 'experimental' branch separate from the main trunk - a lot of OS projects seem to do that. Personally, I would use 'modelmapping' since the normal/parallax stuff seem to have the greatest near-term impact for artists.

Nice video. I'd like to know the story behind the palm obelisk too

Cool!

Nice, but I am wondering what was autogenerated and what was authored? The heightmap was generated randomly and then 'flooded' to some height level? To which degree can the layout be controlled?

On a general note, if #1493 is accepted, we can do opacity map type of things, so we can blend grass and sand textures, for instance, like this:

We should make the autobuilder capable of working off Github branches so all these kinds of features can be developed in cooperation with the artists who should use them.

That is actually intentional (unless you can give examples where it is not due to the viewing angle, of course).

I see. I'll try building again with that flag on.