myconid

Whoops, for committing I should have referenced the dds not the png. Try it now.

The texture/norm/spec maps are 512x512. That's not too bad considering terrain is not even meant to be looked at up close... Still, 1024x1024 would be a huge improvement, and I think it's what most games would use these days. Awesome! I've just pushed the map etc I've been playing with (pic below). It's a map named "test" in Atlas (or "unnamed" in the game). Btw, I tried turning anti-aliasing on and... I really wish the game had better-looking cliffs and a skybox...

Yup, it's already been addressed. I finally had a chance to work on the terrain materials. Not finished yet, though most of the big changes are in place. You can check out the terrainmapping branch, if you're curious, but stay away from the fixed renderpath because it's broken. https://github.com/m.../terrainmapping Terrain types are no longer created by just putting textures in art/textures/terrain/types. The image files are still located at that path, however there is now an extra art/terrains directory that contains terrain xml files, which are very similar to actor files. They look kind of like this: <terrain> <tag>alpine_cliff</tag> <textures> <texture name="baseTex" file="alpine_cliff.dds"/> <texture name="normTex" file="alpine_cliff_norm.png"/> <texture name="specTex" file="alpine_cliff_spec.png"/> </textures> <material>terrain_norm_spec.xml</material> <props groups="forestfloor" mmap="100 50 25" angle="12.0" size="64.0"/> </terrain> The "terrains.xml" files are kept, but they modify the xml files, not the image files. The result doesn't look too different from the tests I did way back, though it's much improved under the hood.

Nice, thanks for testing! Yeah, that's a known issue with the shadowmap (I used to get it too until I "fixed" it by accident, at least on my PC). The cause is a mystery. I had a quick look at the shadowmap code and nothing stands out as wrong.. so clearly we'll need a more serious debugging session sooner or later. I posted in another thread a few days back. I'd say it's improved a little since, though you get the basic idea. That should be possible with steep parallax, I could even add the "fake" self-shadows. I wonder how slow it would be on my comp...

What? Next you'll be asking me for a DOS .exe! You should keep up with the times, man! Just kidding. Surely someone will be kind enough to upload an exe for you, or you can just press people to review the patches faster.

I think I've found a nice little project for the weekend: material-based terrains! The normal/specular terrain demos I did earlier sort of forced what the shaders should be and were quite inflexible, so I'm thinking the same materials system being used for models would work great for the terrains as well...

https://github.com/myconid/0ad Will add stuff as I salvage it from my broken git-svn. Check out the "windtrees" branch if you want, it contains all the modelmapping stuff + moving trees.

According to the spec, the Intel G33 chipset only supports OpenGL 1.4, and the game uses GLSL 1.2 that requires OpenGL 2.1. I'm surprised it runs at all (maybe we should check and automatically fallback to ARB/non-GLSL)! The differences you see between the old and new shaders are probably caused by your card's 96-instruction shader limit: the old vertex shader fits in that limit, while the new one doesn't (hence messed up geometry in the new one), and the fragment shaders don't fit in either case (hence messed up texturing). I'll see what I can do.

I can get the interpolated time by directly modifying ps/Game.cpp or even main.cpp, though either of those options requires me to add "rendering-aware" code where it doesn't belong. What I'm suggesting is, every frame we pass the global time info into a specialised class that is inside the renderer... and hope there's no non-obvious threading going on anywhere that could break this.

Some of the effects I want to add (trees, smooth LOS...) need to have game-time information. I realise the renderer has no way of keeping track of it, and I was wondering if there's a good reason for that, or if it's just an omission. I'm thinking I could add something like a TimeManager class in the renderer that basically keeps track of: the smoothed time since the last frame, and global time so those can be used for displaying graphical effects that are independent of the game simulation. Maybe even a simple interface/callback mechanism where classes can register themselves to receive an "update" call every frame, to replace the hacky bits in Gameview.cpp. Again I need to ask, is there any reason why I shouldn't do this given the current architecture of the renderer?

Awesome!

Can you please check if the attached files help at all (I'm working completely blind, so chances are they'll not). If this doesn't help, I'll need to modify the source code again... modelmap-nvidia.zip

Looks like your old Intel graphics card may not be up to the task. If you try the unchanged version of the game with preferglsl=true does it work?

Got it. It is not dynamically generated. Ykkrosh wanted it to be dynamically generated, and these patches make it easier to implement that algorithm (which is actually not too complex). While that is definitely something I want to add in the future (perhaps in 0ad part 2), right now I already have my hands full, as you can see. The colour of the spec map changes the specularity colour, the brightness (value) of that colour changes the amount of specular. The "specularPower" entry in the material xml controls the "shininess" factor. The self-illumination is controlled by the alpha channel of the spec map, which you can ignore completely if you don't enable the USE_SELF_LIGHT effect in the material.

Not a dumb question at all. I suggest you download the patch, open demo/art/materials/player_trans_ao_parallax_spec.xml and read the comments. Look at demo/art/actors/structures/romans/temple_mars2.xml for an example of an actor using that material. Does that answer your question? If there are specific features you need (such as a way to control the intensity of the normals from the materials), just tell me and I'll add them.

Good work! I wish software testers were all as thorough as you are. The problem is with the model_common.xml file -- it doesn't test if tangents/extra UVs are provided in each model, so those end up becoming null pointers somewhere in the driver. ATI drivers probably checked for this, though Nvidia drivers don't. Will need to do it myself. Thank you!

Ah thanks, this is the sort of testing I'm talking about! Looks like it could be an Nvidia incompatibility (the exception is in the driver), though it's hard to tell which of the 3 patches is at fault here. Edit: It's probably my fault, of course.. Please check if setting the materialmgr.quality to 0 and gentangents to false helps at all. Oh, you should also try without GLSL... If that doesn't help, you'll need to try recompiling, adding one patch at a time and checking which one breaks it...

Definitely a good thing! There are some instructions about how to get a test model in the game, right after the patching instructions. You need to copy across some files, and you'll have a test model available in Atlas, which you can add to maps or whatever. You're welcome! Regarding your question, the AO texture is held separately from the base colour texture, and they are only combined together (really fast by the hardware) while they are being drawn to the screen. This way, there only needs to be a low-quality AO texture that is unique for each model, while the high-quality colour texture can be reused.

I'd love to, though I really need to get some sleep (I'm in Europe!). Can we do it some time later?

Maybe (never had a Mac). You can use these files instead. actors.zip

PATCH: Normal, parallax, specular, emissive and lightmapping (AO etc) The attached archive contains the "final" patch/files for all the above. It's here and not on Trac because of Trac's 512k size limit. I decided to generate the diff manually, to avoid including the two other patches in this one. While they are not explicitly included, they are still prerequisites. The instructions to patch everything are a bit longish, and maybe it would have been easier if I wrote a script for it, but it's a one-off thing so I couldn't be arsed. Here goes: Update workspaces and compile. Here you need to run the game to copy over the config. If everything goes correctly, the game should run and nothing should look different than usual. To start using the new features, go into your local.cfg file and set preferglsl and gentangents to true. (At the end of the file you'll also notice a materialmgr.quality setting. The version of the material that is loaded depends on the materialmgr.quality setting in the config (which is out of 10, float). For instance, parallax is only enabled if the config setting is >= 8. If it's smaller, the material redirects to a simpler version of itself that only contains normal mapping, which redirects to the completely basic material if the quality setting is not >= 3). The archive contains a "demo" folder, which has some test files you can try. Copy the $patdir/demo/art directory over the game's 0ad/binaries/data/mods/public/art directory and merge them. This will add a new model called "mars_temple2", found under "Actors (All)" in Atlas. That's pretty much it. Good luck modelmappingpatch.zip

Thanks. Yes, those need reviewing, though don't commit them just yet because they'll also be included in this patch (without changes AFAIK).

Every bit of testing counts. Once I release the patch, please give it a try and give me some feedback

Final patch for model normal/parallax/specular/emissive mapping should be dropping tomorrow. I somehow managed to mess up my git-svn setup, so the patch will also include patches #1493 and #1497, sorry! Testing specularity now. Here are a couple more pics: The first one uses greyscale specularity to model the marble, the second uses colour specularity to model the metallic parts on the columns. They look better in motion...

You're very welcome! Now trying to get the mapping stuff cleaned up. Here's a peek (NB: automatically generated normal/height maps are pretty bad, but hopefully you get an idea about what's possible). Edit: I know about the seam. I must have broken something while cleaning up the normal mapping. Will look into it. Edit2: Never mind. I win the stupid mistake prize.