myconid

In that case you might want to look at TortoiseSVN's documentation. After the patch is applied, don't forget to add #include "precompiled.h" at the beginning of "weldmesh.cpp" and "mikktspace.cpp"

Well, either you need to build the engine from source, or you can wait until someone uploads the compiled executables for your system. Btw, bumpy specular terrain has arrived!

I'm afraid I don't have a Windows installation any more. If historic_bruno or another Windows user doesn't mind uploading a compiled binary, I'll upload a separate archive with the shaders and other files you'll need to run it.

This afternoon I got started on bumpy terrains. Just normal-mapping for now. http://imgur.com/a/gDdxZ#0 Quite happy with the way it's turning out! Specular mapping is next. Should be good for things like snowed terrain.

Thanks for testing! I'm relieved that it worked on Windows/MSVC without any important changes. No Nvidia users about? Do let me know how horribly and inexplicably it breaks on your hardware.

Changing from ".a" to ".r" on fglrx fixes it for me for some reason (FYI that change might have been left in the patch, the original was ".a"). It's odd that people are having trouble with terrain shadows but not with model shadows, since the same code is duplicated almost verbatim in both shaders. Like Ykkrosh mentioned earlier, the shadowmap is created as GL_INTENSITY, so all its channels should contain the same values. Maybe there's something not quite right with the shadow2D function, which is deprecated, though I can't tell. Mythos, I believe this is just a shadowmap issue, not a terrain blending issue. The artifacts are caused by the get_shadow function not affecting the ambient lighting.

In terrain_common.fs, in this statement: return (1.0/9.0)*dot(size.zxzx*size.wwyy, vec4(shadow2D(shadowTex, vec3(weight.zw, v_shadow.z)).X, shadow2D(shadowTex, vec3(weight.xw, v_shadow.z)).X, shadow2D(shadowTex, vec3(weight.zy, v_shadow.z)).X, shadow2D(shadowTex, vec3(weight.xy, v_shadow.z)).X)); try changing the ".X" at the end of each line to either ".r" or ".a". One of them should work.

You have an X1600? For some reason I thought you had the RV770-based card... Anyway, this definitely seems like either a driver or hardware problem. Based on what you just said, my best guess is that the shader is too long for your older card. That may be a result of actual hardware limitations, or there's a chance the driver is incorrectly trying to unroll the while loop and is thus generating a lot of useless code...

Thanks feneur! Here's a map that uses quantumstate's heightmap with a more pronounced normalmap component. Turn the model and terrain ambient colour right down, set the sun elevation to really low, and move the sun rotation slider to see what happens.

quantum, just tested your new heightmap. Yours looks much better than the one I had! Made some more changes to the map, so the normalmapping is a bit stronger... But how do I upload attachments? Are they disabled for noobs?

fabio, it looks like the issue is with the parallax (perhaps I'm misunderstanding). The other error isn't too important (technically, self-light uses input from specular, so nvm). You seem to have newer hardware than me, and nothing in the parallax code stands out as something that could cause that sort of discolouration (parallax doesn't actually write any pixels out, it just distorts the UVs). I assume both you and quantumstate are using the same Mesa driver and his works fine, so I'm kind of stumped... If you turn everything off except the parallax and move the camera around, do you see the effect, even though it's pixellated, or is it not working at all? Also, can you make sure the textures have been installed correctly? quantum, yeah I missed your edit. The scale transition is definitely a good idea! Glad it works!

Fabio, we'll have to isolate the problem before we can fix it (to the time machine!). In the fragment shader (.fs), right before the main function there are four preprocessor switches: #define USE_PARALLAX 1 #define USE_NORMAL_MAP 1 #define USE_SPECULAR_MAP 1 #define USE_SELF_LIGHT 1 Try setting them to 0 one at a time to check which effect is causing trouble. quantumstate, thanks for testing (and for the improved map). The clipping is probably caused by the line "float height = 0.5;" in the fragment shader. Try setting it to 1.0 (I can't test it myself right now). You may find the effect is a bit too strong then, so you may need to adjust the brightness/contrast of the heightmap.

Thanks for testing, fabio! I'm using fglrx. I wasn't even aware the OSS driver was capable of 3d yet... Anyway, looks like there are too many shader "outs", basically. Not a problem, since I left a bunch of stuff in there that isn't needed. Could you try replacing model_common_norm.vs with this: http://pastebin.com/LxqDEfps and model_common_norm.fs with this: http://pastebin.com/Zp5XxhFf (no need to recompile) You get the flashing terrain problem? Interesting. That bug has something to do with the shadowmap, and it's actually come up once before in this thread. Please ignore for now...

Sorry, that was a mistake on my part. It doesn't need 1.4 support, it should run with 1.2. The somewhat cleaned up version I put on Trac had that fixed. Edit: Whoops. In the file model_common_norm.vs in the GLSL shaders directory, change the line #version 140 to #version 120 and it should stop complaining.

Much appreciated. I'd like it if people tried the code and gave me some feedback, if possible. No need for anything fancy, just compile, run Oasis 10 and let me know if anything looks wrong, and how good or bad the performance is. Yup, that's the idea! In the long-term, there are a number of things I will/might try (sort of a wish list, in no particular order): Post-processing effects done right with a dedicated "manager" component. Generic lightmapping. The ability to load arbitrary textures with a separate UV set, and combine them on the model using a user-specified blending mode. For instance, an AO texture would use "multiply", while an emissive lightsource could use "add" or "lighten". Moving textures. E.g. a waterfall could "translate" one or more texture layers at differing speeds to create the illusion of falling water. Ground and distance fog. Variable water level. Water is currently represented as a flat plane. It could use a low-resolution heightmap to have different heights in different parts of the map. Fading line-of-sight. Fade between changes to the LOS texture, to give the effect of smooth movement (like in HoMM6). Line-of-sight obstructions. Use a limited raycasting method to prevent units from seeing through walls or buildings (this makes the game more challenging). Terrain erosion for map generation. Simulate the effects of water and/or wind erosion to create more realistic terrains and specialised terrain textures in Atlas. Anyway, I really hope my experiments will not impinge on anyone's territory...!

"Bumpy specular" and self-illumination are now implemented on models: http://imgur.com/a/oRHdk See attachment for latest patch: http://trac.wildfiregames.com/ticket/1429

http://www.2shared.com/file/xOa3k6FI/bumpydiff.html This contains the normal and parallax effects, not the screen-space effects. To test: Get a clean version of the code, extract the archive, patch the code with patch -p0 -i bumpy.diff in the 0ad base directory (that contains "source" and "binaries" directories), copy the four png files to binaries/data/mods/public/art/textures/skins/structural/, update workspaces and compile. Look at the Roman civil centre and Roman arch models to see examples of the effects. To try adding your own, create or modify an "actor" file to use the player_trans_norm.xml material, and add "normal" and "specular" tags as in the examples (if the maps are not found bad things will happen). The normal map uses the rgb channels for normal mapping and the alpha channel for a heightmap for parallax. The specular map uses the rgb channels for a specular colour and the alpha channel for the self-illumination factor. Let me know what the performance is like when fully zoomed in -- that may need some tweaking. Disclaimer: Not finished by any stretch of the imagination. Only tested on Linux/Ati. If you do something cool with it, feel free to share!

I hear you. Speaking of patches, I shudder to think what horrible things I've done to the whitespace...! I'm on a 4-Y.O. laptop with an ATI Mobility HD 4670, and the GPU is running on low-power settings. I get about 20 fps with SSAO, HDR, Bloom, normal maps and parallax maps enabled at the same time (and the first three are implemented really inefficiently, allocating/deallocating several large textures every frame). Anyway, I should mention that I'm taking a slight detour from the plan I posted earlier. Before I delve into the terrain renderer, I'll take a shot at implementing specular and self-illumination maps for models (it ought to be trivial). I'd love to do precomputed AO as well, but that will require more drastic changes to the UV-loading code, so it'll have to wait. An outstanding (non-)issue with the current tangent-space implementation is that animated objects do not support bump/parallax. This is due to my own laziness, as I'd have to transform the tangents on the CPU...

A small update, just to let you know that the glitches are hopefully all ironed out, and the tangent stuff is now all computed on the CPU (with exactly the same method as Blender so even baked maps should work correctly). Here's a little test pic: http://imgur.com/HPJ76 The roof on the left is parallaxed/normal mapped, the roof on the right isn't. I think it looks a little better! Since the parallax effect is most noticeable up close, it only gets applied when objects are closer than 65m away, and is gradually scaled up in quality as the object comes closer (The cutoff is done with an if statement, with some possible caveats depending on what the GLSL compiler does under the hood... though it should save clock cycles in almost all cases). Normal mapping is always on, though a similar trick could be used for that. I'll probably release some source code over the weekend if any people want to play with it, though be warned that it's still very much a work-in-progress.

Thank you. I'm glad I don't have to mess with premake configs directly -- that would have been such a huge PITA!

Right, so far I've been calculating tangent space per-fragment on the GPU (using dFdx/dFdy). That's good enough for a prototype, but it's actually really expensive, so now I'm setting things up so the tangents are precomputed once on the CPU and passed into the vertex shader. I want to do that the "standard-compliant" way by using mikktspace.h/mikktspace.c like Blender does... but I can't get my head around the premake system. Can someone please briefly explain how I can compile/link to these from ModelRenderer?

Probably not going to put more work in tonight, but here's something a little different just for fun http://i.imgur.com/NnSDI.jpg (From TESV, obviously.)

Thanks, I might have a read later.

They are, but very subtly for some reason. The heightmaps were automatically generated in the GIMP, so they're less than ideal.

As promised, some more work on the shaders! Here's tangent-space normal mapping + steep parallax mapping: http://i.imgur.com/L8bdN.jpg Nowhere near finished yet, however. I must have messed up the parallax math somewhere, because there are some nasty artifacts all over the place. Plus, it's still stupidly slow.