wraitii

1. Only actors, not sure what you mean exactly otherwise 2.It's for SVN (and should also work for alpha 20)

I've been adding more stuff. First thing is I now open the PMP files, which allowed me to sort which actors go over water and which go under (or both), to avoid weirdness. I also added the possibility of adding "rules", for example a map might decide to not add entities around a certain fauna/flora element, or forbid some actors from appearing (useful on volcanic lands for example). Finally I've added a beautifier based on the terrain texture, but it only works on some textures (check out Oasis) so it's not as useful as I'd hoped. It could probably be modified slightly to become a more uniform way of placing actors around a map though. At this point I'm not entirely sure what to add next, so I invite everyone to play a bit with it and see if they like it. Generally speaking I think it looks good, needs a few tweaks. Just download the mod at https://github.com/wraitii/0-AD-RM-beautifier

I don't think a beautification pass like that is really easy to do during the map generation. It might be helped by better integration with the random map generator though. I've kept the work up, now working on adding more "meta" info. I've also added a function to add a given amount of actors, so you can easily set your density. Results at "2","10" and "100".

New comparison screenshot over SVN RM Syria. I'll let you guess which is with and without.

Yes, the script currently loops over entities (and only entities) to add actors (and only actors). Ultimately I think it should also run over actors to add actors. I don't see adding entities working very well overall.

FYI, the mod runs the beautification 4 times when it should really just be run one time, to overdo it. Here are some screenshots from a modded Kerala with no beautification. I added a flag for all added props. As you can see it adds a lot of props, particularly under dense amount of trees. I've also updated the github repo with the latest version of the script and mod. It now takes basic distances into account so the result is overall better.

Added a mod to simply see the effects: https://github.com/wraitii/0-AD-RM-beautifier Just use the beautifier mod. Basically this automatically adds beautification elements around entities. The mod overdoes it so you can see the changes.

Created a Githbub repo for a simple python script that sort of implements this. For now it's very naive and only uses entities as a source. https://github.com/wraitii/0-AD-RM-beautifier/ Sample output: http://pastebin.com/11MLkwTZ

I do not see many real improvements coming unless: map size is increased massively for more realistic scales Walls become much harder to penetrate while other buildings become much easier to destroy (meaning walls become more necessary) Both these things require substantial gameplay changes and code changes. The biggest problem imo is building time.

Generally speaking, any realistic implementation of siege warfare would be too "slow" to work in the game. Unless you went with very abstract things such as a special "mining" ability that just makes walls explode instantly or something.

Hello LittleDev, For your information the current AI developer is mimo, it was previously me (like 2 years ago) and before that a few other people. If you have questions, feel free to ask.

Something like Grass waving requires many many more grass actors than the rendering engine can currently support (test it yourself in Atlas), but the waving isn't a problem: trees already do it. To support that many actors we'll need to have some real instancing which is still a bit out of reach.

Seems like a brilliant change to me, with the caveat Sanderd noticed. For our purpose, maybe make it reach a little less far? It'd probably go into the meshes of buildings too much like that.

Oh god the lag

It would need some testing, I think that might be a bit too much, it really depends. Perhaps a proper implementation would be a separate "pop cap", where different buildings have different values. SO a house costs 1 slot, but a barracks 10 or 5 so you have to decide.

Yeah this color-fade effect isn't handled very well. I think another direction to work on is to base reflections more intelligently on normals. If the reflection vector ends up being "straight up" there should definitely not be a reflection of a nearby object from the map. About depth: I find the idea of a logarithm very interesting.

I think you made refraction too weak at low waviness.

Interesting. Limiting the number of building per phase might actually be an idea I'd like to try.

Yup, you're entirely right. I tried some stuffs to fix that but it just added more problems. I'm quite interested in your patch, looks good. Re normal maps: there are no visual artifacts. There's only a visual "issue" that you see flat reflections instead of seeing what you should see (a mix of water color and sky). Check out this picture, we see very little reflection in the distance, as the water isn't flat. Compare with this. And in-game in the attached picture. It only ever happens at low angles, but it looks very bad on cinematic shots.

Yeah, I'm aware of that last issue, but you're really free to change it if you think it looks better. About the normal map point: The textures used at low angle, even with a lot of anisotropic filtering, end up being blurred at low angles, or are very "sharp" which looks even worse (basically either left or right here). You need at least 16x anisotropic filtering to keep it acceptable, and even then it's never really enough. Also I might have done the linear fresnel thing on purpose: we as humans are used to seeing reflections on water, as we tend to look at water at a low angle. Looking at water from above with no reflections at all looks kind of odd, so I artificially made my water too reflective. You're right that looking at the side of a wave means more refraction, but because of the problem in my diagram above instead code usually shows reflections, which is basically entirely wrong. Feel free to ask any other question.

Are you sure about FBOs? Also Yves is definitely focusing on draw calls but not only that, and porting to OpenGL 4.0 requires quite q few changes so definitely talk to him if you wish to update the renderer. FYI the chrome was never committed as there were some slight issues with implementation details, but it used the skybox, not a "real" 3D Reflection. It would be pretty much impossible to render realistic reflections for arbitrary items, but for a few very important ones we could in theory render a very downsampled box texture of the surrounding terrain. This is the technique used by games such as GTA5. My belief remains that we need to implement software batching by actually merging objects together to unlock great performance. Also FYI the water shader is really separate from the rest so I used an "if" there as it was supposed to be a more "modern" feature, which are very widely supported. The rest of the code is supposed to be runnable for an Opengl 2 system, but that decision might change.

Speaking as the maintainer of the water code: Seems like you managed to fix the weird inverted normal Issue I had which made specular wrong and I never bothered to fix. By this point I expect you have noticed I'm using real reflections for the skybox and distorting a transparent "reflection map" for objects that are near. FYI the "artifacts" when you orient the wind north are dependent on graphic cards. It never happened for me on Intel GMA and I could never fix it because of that. Make sure to test your code with all textures types and all waviness settings as there is a lot of room for mistakes there. Likewise, the Red color that appears at low angle is WorkingAsDesigned and is there because of the distortion code. With the shader tries to get refraction texels that are "above water" pixel and contain garbage data. I detected this in the shader by checking the red component against the other one (the "horrible hack") and choosing the original undistorted texel in this case. However in some cases even that is insufficient. SO if you just remove the hack you're only going to break it further. The red comes from the C++ code, the refraction texture is cleared with (255,0,0) before drawing the refraction. So when you fetch a pixel that's not rendered (above water) you get full red, which is why it happens on the edges of the map. The proper fix for that problem is not trivial. Also FYI the shore waves took me months of thinking to get somewhat right. I do not believe they are recomputed every frame, though, if they are it's an insane bug on my part. IIRC I create polygons by trying to follow the shore, but I never got it to work really well. Edit: Oh yeah also I see you removed my comment about reflections being wrong at low angles far away, but the problem is still there. Just as an FYI, I still believe my "default to sky color" is the right way to go about this, but there is one thing to notice: since the normal map gets entirely blurry, the normal of the water plane becomes (0,1,0) ie straight vertical. But in real-life, you see the sky more because of the wave ripples. See my attached diagram. So that may be another thing to go after.

I agree that the current speed of cav should see them either trot fast or slowly gallop.

I think we should also come back to about 3 workers per farm or even fewer.

Looks pretty good. I've reviewed your updated patch and uploaded a slightly cleaner version for Leper to give a look at, I think you can continue with this and we'll get around to committing it.