myconid

Looks totally doable, though it'd take a bit more hacking than the trees. Here's how I think it was done in that video: there is a much finer water mesh than in 0ad it is displaced with cos waves by the vertex shader (just like the trees) then there's also code in the fragment shader to draw a foam texture on areas where the angle of the water is large (the tops of the waves). Unlike the trees, this will use more processing power, because there's a need for additional vertices. I think all the effects in Lion.Kanzen's previous video should be possible with my other patches, with the exception of the cloud shadows. I think those can be done by passing in a cloud texture to the fragment shader and using the LOS texture transform to make it look like shadows on the ground. i.e. it should be as simple as a texture read and a multiplication.

zoot seems to have exposed a bug in the actor editor: when trying to choose the "anim name" in the animations dialog box, the combo box fails to store the value chosen. He found this while testing under Linux, and I have reproduced it under Linux. I'm assuming this does not occur under Windows. The issue is in the file source/tools/atlas/AtlasUI/CustomControls/EditableListCtrl/QuickComboBox.cpp, in this method: void QuickComboBox::OnKillFocus(wxFocusEvent& event) { // We need to test whether there's actually a window receiving focus; // otherwise it tries to destroy the control while wx is focusing // on the text-input box, and everything crashes. if (event.GetWindow()) { GetValidator()->TransferFromWindow(); Destroy(); } } It appears that under Linux, event.GetWindow() returns NULL so the control can't lose focus and as a result the validator never gets triggered and the value isn't stored. If I leave the if statement out, I don't get a crash like it's suggested in the comment, though that may not be the case on other platforms. Isn't it better and safer if we just force the focus to the parent window instead? i.e.: void QuickComboBox::OnKillFocus(wxFocusEvent& event) { GetValidator()->TransferFromWindow(); GetParent()->SetFocus(); Destroy(); } This solves zoot's bug, but does it work around the crashing issue? Edit: This solution seems to mess it up in other ways. Sigh.

The animation happens while transforming the vertices for display on the screen, so only the objects that are to be displayed are animated.

This. That's definitely the fastest way to create complex-shaped, non-animated models like statues, etc. In Blender, you can first get the basic shape by sculpting, then you can apply the Decimate modifier to reduce the poly count and finally tweak the low poly mesh to get exactly what you need.

Thanks, I realise now that my question contained the answer: there's no real technical reason for choosing that size, I just need to "make it large enough for the maximum feasible mesh size" like the comment says, which is now 4MB. Problem sorted.

Here's a question for the programmers: The actor in actors/campaigns/structures/hellenes/settlement_houses.xml is having some issues with the tangent generation. I get this error when loading the model (which comes out looking wrong): ERROR: Failed to create VBOs (64*47479) The error is not caused by any real hardware or software limit. There's a hardcoded 2MB buffer limit in renderer/VertexBuffer.h: // Absolute maximum (bytewise) size of each GL vertex buffer object. // Make it large enough for the maximum feasible mesh size (64K vertexes, // 32 bytes per vertex in ShaderModelRenderer). // TODO: measure what influence this has on performance #define MAX_VB_SIZE_BYTES (2*1024*1024) This assumes 32 bytes per vertex max, but obviously by adding tangents, extra UVs etc that gets pushed over (and there's also padding to power of 2 sizes). What's the point of this hardcoded limit, other than not putting everything in one buffer? ... Can I change it to 4*1024*1024 (i.e. 64 bytes per vertex)?

Hmm, I doubt it... I think that won't look perspective-correct unless you can find a way to draw each blade of grass back-to-front. Btw, it may not be as slow as I thought initially. Still pretty slow, though.

The longer the grass, the slower it needs to be to look decent (12 iterations per vertex in the above). I'm using the multipass shader system for rendering, which definitely contributes to the slowness, though I'm certain the algorithm is already quite slow due to how it works. We could make this material a special case in the renderer, though I'm not a fan of that idea.

Had some time today, so I threw this together to test performance... it certainly looks interesting, but it's just too slow.

The procedural rivers look interesting. zoot is correct, it can be just another material. There are also screen-space effects on the way (look nearer the beginning of the thread).

Afraid not. That may involve hardcoding stuff and I'd rather avoid that at this point.

I think zoot is right on a lot of points, and I'd say Sonarpulse's method #2 would work around the problem that historic_bruno describes (with caveats). I also think that Sonarpulse's method #2 would be more feasible to implement efficiently than he believes. Imagine that you are replacing the terrain's heightmap with a "normalmap", where the vertical Y component of the normals is equivalent to the heightmap's height values. The simulation generally doesn't need to know about the additional XZ components, as this stretching happens during rendering. Taking historic_bruno's two pics as an example, the simulation can just see the top pic, and the bottom pic is only generated by displacing terrain vertices/model positions by the XZ amount of the normalmap when rendering. The model positions do not actually overlap in the simulation. The stretching can cause some problems, though. It may affect unit speed, with units passing over stretched terrain going faster (we'd need to reduce that based on the magnitude of the XZ displacement vector). More importantly, it would affect mouse input, as we'd need to also displace the bounding boxes used for that. You would also find that rendered unit LOS stretches with the terrain, unit AI can see further when the terrain is stretched, projectiles are thrown farther where terrain is stretched... Most of those are not unsolvable problems, and would be possible to fix by changing distance queries to take the stretching into account. Calculating the LOS for rendering would be a huge pain... tl;dr What zoot is describing is probably possible, but would need a lot of intricate changes and a ton of testing.

My patches added a way to scale the amount of effects through the game's config file. Setting that value to 0 = no effects, 10 = all effects. Values in between scale the effects up gradually, depending on how the effects registered themselves with the materials manager.

IMHO, this sort of thing could be built into the pathfinder itself. And maybe the pathfinder could even go a step further than the paper. The Voronoi partitioning could be combined with a summed area table, which would make it dead easy to approximate how crowded a square region is (including objects like trees, etc!) and avoid it... if that makes sense.

I know people don't like it when I say this, but it's not really that complex... I think it may be inefficient because we'd have to render the terrain 10+ times, once for each "layer", though I suppose there's no harm in having the option available. Btw, this reveals a lack of multipass shader support in the terrain renderer. In theory, the materials system and model renderer can do something like this, but the terrain renderer will need to see some changes first. Anyway, I'm having a really busy week right now, so I'll look at this over the weekend!

After I'm done with the graphics (which could be a while from now), I might have a look at scripting. As long as I can find interesting problems to solve, I'm happy. I should probably mention that by saying I know stuff about scripting I mean I know stuff about writing compilers and VMs... probably a bit different from what's done in 0ad, but I should find something I can help with.

The black and white bump mapping algorithm is pretty old and not supported, however I do use such "bump" maps (heightmaps) for the parallax effect, which is the "new version" of bump mapping in a sense. It should also be possible to generate normal maps from bump maps, if that's an issue for you. Fixed, sorry. A bunch of broken debug stuff, mostly. I'm a programmer, though not a game programmer. In my day job, I need to know more about AI, optimisation ('pathfinding') and scripting than about 3d graphics. Don't want to sound overly mysterious or anything, I just don't know what else to tell you. I discovered 0AD a couple of years ago, and I've always wanted to contribute, so here I am! After I'm done with the renderer, I'll just pick out something that looks interesting... not sure what yet.

I see. This sort of thing could be useful for implementing something like seasons. For example, you could have dynamic snow that accumulates on surfaces higher than P and less steep than X angle. Or seasonal plants that bloom over Q texture at Y angle...

The idea is to make a special material just for slopes to avoid using this everywhere. Whatever you see that looks odd, it's most probably intended. When used like this, the triplanar effect is a trick that removes one type of artifact (the stretching) and replaces it with other artifacts that are hopefully a lot less noticeable.. Edit: Or maybe it's not intended... I'll look into it.

I'm not sure I understand your suggestion, Sonarpulse. Are you talking about storing that information in the terrain files?

Already done, though I guess that last pic was a bit messy. How about this one: Triplanar + normal mapping + specular mapping. The stretching problem is solved. I should note that triplanar texturing is a pretty GPU intensive effect: it replaces every texture access with 3x accesses, and memory access is pretty much the slowest operation. I think I'll make it so it lives in a separate material of its own that is used for cliff textures.. On a completely different subject, did you know that Nvidia's CG compiler can automatically convert a subset of GLSL to ARB assembly? That means it may be possible to 'port' some of the lighter GLSL effects (eg AO) to ARB with very little effort...

Haha, no I was just kidding. Or was I?

Sure, looks simple enough!

Ah, good. Sure can, it's just that the model ambient colour is a little too bright in that map. I think I should stick to coding and leave stuff like that up to the map designers.

I force AA on through AMD's control panel app. Don't know if there's something similar for intel cards. Uh-oh...! Why are there no shadows in that pic? This couldn't possibly be the fault of my changes, I think. And also the sky reflection. Is the game turning stuff off if it's running slowly, maybe?