myconid

Back to doing groundwork for the postprocessing effects manager. Here's HDR + bloom + fog: http://imgur.com/a/p1jxm Code: https://github.com/myconid/0ad/tree/postproc MrEmjeR, if you want to get started on the tilt-shift shader, look at the "hdr" shader for how to access the render and depth buffers.

Whoops looks like I forgot to add the civic centre files to that branch, sorry! Mars_temple2 should work, though!

The flickering is sort of expected, as I haven't worked on the shadowmap at all... but there's no sign of any effects anywhere, which is odd (it should either work or fail miserably, not look unchanged). Just to be sure, are you on the "effectsdistance"branch and preferglsl/gentangents are set to true in the config? (thanks btw)

Yup, that looks more correct! http://imgur.com/a/CkHWf In regards to parallax: when you are creating heightmaps remember that the parallax effect actually goes inwards (i.e. the real surface of the polygon is at height=white). If your entire polygon is much lower than that, it gets pushed inwards and the effect doesn't know what to draw to fill in the gaps at the edges. That's why you got tiling gaps on the roof of the roman civil centre. The solution? Make the brick heightmap brighter, until the tops of the stones=white.

Yes!

Best way would be to add it as a prop, meaning it's a model with a grass material attached to a specific point on the main roof. (when I'm talking about decals, I'm talking about terrain decals like the patch of dirt drawn under buildings)

The LOD is actually just for models atm, though it'll get adapted eventually. As for fur on bears... it's possible, but is it worth it?

At the very least, that would give me an excuse to implement fancy materials for decals.

There's no hurry, test whenever you have time. The branch is "effectdistance2".

Ok, done with the effects distance. Unrolled GLSL loop and using the new system with it, with 2 different quality levels. I haven't checked the stats, but it definitely feels like it's faster now! wraitii, when you get a chance see if this works with your ARB shader. fabio, if you're still looking at this thread, can you check if the updated parallax effect works on your X1600?

Yeah, something like that. What's left to do is to somehow pass the config values into the shaders, so they know when to fade themselves out. This can probably be done using defines.

You could look at how the automatically-generated normalmap worked around that issue. Afaik, this wasn't a problem with that. In Blender, no. We'd need to explicitly turn the heightmap into geometry for it to affect the AO.

Alright, I've now implemented effects that can disable themselves with distance. It's done through the materials files and controlled from the config without hardcoding anything. Instead of using "define" to set up effects in the materials, we can use "conditional_define" that looks like this: <conditional_define name="USE_PARALLAX_MAP" value="1" type="draw_range" conf="parallaxdist"/> This tells it that we want the shaders to see a define of that name/value only when the "draw_range" condition type is true with the values it gets from the "parallaxdist" set of values in the config file. In the config, this will appear like this materialmgr.parallaxdist.max = 120 i.e. parallax is enabled only when the distance to the model is up to 120 units away. If we set this to a value less than 0 (e.g. -1) the effect is always on. If the value is 0 then the effect is always off. Code: https://github.com/myconid/0ad/tree/effectdistance2

Alright, here are two big screenshots: There are some tiling artifacts on the stone part of the roof, but otherwise this looks gorgeous. Download the attachments for the massive versions, if they'll be more helpful.

I'll give this a try! Btw, have you considered using this heightmap with the "displace" modifier in Blender? Maybe we could bake more detailed AO maps that way, and you could use the sculpting tools to improve your results.

https://github.com/myconid/0ad/tree/effectdistance I'm skeptical whether this is the best solution... We should be able to get better results by doing this through the material files instead of the effects files.

I have the latest version of your waterShader branch, which doesn't use the depth texture, so I guess... no?

1. You have a memory leak on the GPU, because you allocate a texture called "heightName" every frame, but you don't free it. 2. You create heightName as GLuint* and then give that undefined pointer to glGenTextures, which causes things to crash when the driver tries to write to it. Create it as GLuint and adapt the rest of your code.

I thought it was when loading at first, though it looks like it always segfaults when it's trying to display water.

Yeah, that's what I was thinking. If you draw that value with gl_fragColor, the resulting colour directly in the centre of the screen should be constant as you zoom in and out with the mousewheel. That is, the depth should be unaffected by the distance from the camera. Yeah, I've read that somewhere, and as I have an ATI card that may be what I'm experiencing. Anyway, I think it should be possible to calculate it manually in the vertex shader. In fact, if you calculate it yourself it may be possible to avoid linearising it altogether (maybe). Oh, btw. Looks like superfancywater=true causes a segfault when loading the game.

wraitii, that depth buffer thing has been bugging me a lot. I googled up gl_Fragcoord.z and it's indeed supposed to be the value that is written to the depth buffer. In theory, if you linearise both the depth value from the texture and the depth value from gl_Fragcoord.z you should be able to subtract one from the other and get a meaningful measure of distance between the two. But, it's not that simple it would seem.

I haven't looked into the code, but there's a few things I'd like to see first. Like custom Javascript brushes, for example. I'm thinking we could have a general system where you can select, for instance, the "biome-alpine" brush and paint it over the terrain, and it changes the terrain textures and objects to match that biome. Such a brush system could also be made to modify the terrain in specific ways, with erosion being one of them. Let's say we'll simulate erosion as the carrying of dirt by water as it flows downhill. Here's a super-simple way to model it: Create a temporary texture that is several times larger than the piece of terrain you are eroding (eg 8x) and copy into it the terrain heights, with blurring/filtering to avoid jaggedness from stretching. In each texel store (at least) two values: the interpolated height, and the amount of water flowing through it over time. "Rain" water in a Gaussian shape at the middle of the brush. Texels that receive water add it to their water amount. For each texel A that has water in it, find the lowest-height neighbouring texel B that is of lower height than that A. Move water from A to B until their (height+water) values are equal, or A runs out of water. Depending on the amount of water that is moved, move with it a corresponding amount of dirt (lower height of A and add it to B ). Repeat from 3. Heightmap values become the average of the texels' heights. Modify textures based on finer data in texture. This will probably need a separate result texture to do properly, though good news is that all the simulation should be straightforward to do on the GPU.

Works and looks good! A bit slow, but I'm sure there's plenty of room for improvement.

I know proper GPU raytracing can be done with OpenCL... though it's tricky to do with GLSL shaders. For raytracing you need access to your entire model, so for each point you can cast a bunch of rays and check if they collide with any other parts of the model. Shaders only have local info about the triangle they are currently rendering, so obviously that's a problem. Assuming we don't want to use the shadowmapping method and we want to try real GPU raytracing, I've been thinking about what kind of algorithms we can try. The good thing about AO calculation is that we don't care about the colour of each ray, just whether it shoots into the sky. One possible solution is to first render the model into a 3d texture (on either CPU or GPU) and then do the actual tracing of rays by "walking" through the texture on the GPU. This alone may be enough for our purposes, but this paper goes a step further and passes in a data structure (stored in a texture) with the triangle data that occurs in each voxel, and thus calculates exactly what the ray hits. A 2563 3d texture is 16MB. 5123 is 128MB. Seems totally feasible, I think... but we'll have to try it to be sure.

That's the comparison function for the depth buffer, so geometry that is behind other geometry doesn't get drawn. Completely different thing. Define is for compiling, so same problem. We need something that does the comparison dynamically in the engine. It should be easy to do, though I'm afraid it'll have to wait till the weekend (as usual).