zoot

Tree generation has been around since the early 70's, but those early algorithms were guided more by mathematical and botanical principles (like fractals) than by visual appearance. ngPlant seems to be based on a more recent (1995) and well-established technique by Jason Weber and Joseph Penn, designed specifically for photorealism. Here is a sound bite from their paper, which was presented at SIGGRAPH: "Our attention in designing the model was focused on allowing a general user to create trees that generally match images from books or photographs.The user needs no knowledge of botany or complex mathematical principles, only a basic understanding of geometry. We concentrated on the general structural appearance of a tree instead of the biological and biophysical principles that produced its structure." Commercial packages like SpeedTree also seem to use some variation of this technique. Furthermore, ngPlant comes with a "designer" application which allows you (or an artist) to model a base tree which can then be randomized within some specificed range. The model is exported as a special file which can be imported into the game using the C++ library and seeded at runtime. So overall, it seems like a pretty controlled and professional solution. As for alpha testing vs. alpha blending, I imagine that is entirely up to the user - the library only concerns itself with creating the basic tree model (the mesh, if you will). Texturing it would be done with whatever tools artists normally use.

I wonder if 0 A.D. might benefit from using a library like ngPlant: If I understand correctly, it will actually generate a random (subject to input parameters) tree and give you a description of how each leaf and branch relate to each other. This would allow us to animate it with something like this. Later iterations could even do crazy things like animating individual leaves on high-end systems but to begin with it can just support basic low poly trees much like those already in the game: (Screenshots from BlenderArtists.org)

I suspect technical limitations has driven the scale that has been chosen for maps. The problem with tall mountains is that they require an equally wide base if they are to be passable by units. So this would quickly lead to very large maps, which in turn would gobble up memory (unless implemented with a fancy technique like megatextures).

Could git-annex be used to track binaries in Git? Don't know if it has Windows support though, which might be an issue...

That is one of Pureon's screenshots from the GUI thread: http://www.wildfiregames.com/forum/index.php?showtopic=16111&st=60#entry241554 Maybe he can chime as to whether AA was on.

Oh, I guess alpha isn't supported for textures? Curious why there is an additional black edge around the white edge though. (Edit: I guess that is the intended visual but the resolution just doesn't render it very smoothtly? Anyway, I'm not an expert, just wondering what was going on there.)

Is there a problem with alpha blending on the new selection rings? They seem to have a jaggy white edge. It could be for contrast, but IMO it looks wrong: http://i173.photobucket.com/albums/w73/purepics/0AD/0ADgui02.png (ignore the UI mockup) Probably a known issue, but there you have it.

Totally put it out as something you "would like". As with the sound system, someone might pick it up just because they find it interesting.

Maybe we could precompute a base model of the river with fluid dynamics as the map is loading and then animate that model with simpler techniques once in-game.

The main simplification seems to be that they only calculate the fluid physics in 2D. It is probably still too advanced for our uses but perhaps some approximation could be found that looks reasonably nice, even on lower-end systems.

I guess that is a matter of "easier said than done".

And who will get the blame when people begin complaining about the inconsistency of having to affix some things with "maps" and others not? The programmer.

I expect because it clutters the namespace for tags. Imagine someone came up with a graphics technique called "actor maps". You would then need to add a tag to your list of the type "<Actor>". But that tag is already used for something else in the engine, so the parser would not know what the intended meaning is. In short, it's better to be specific from the beginning.

Consider something like this for rivers:

I wonder if a better approach might be to redesign the GUI engine and then let the artists experiment with the various possibilities. Not saying that anyone on the team wants to do this but someone else might if they were asked.

The waves we have now looks more like ripples. I think we could throw in a configurable wave amplitude, beach waves (breakers) and perhaps some scattering and caustics. Also, I think you'd want another physics for flowing rivers, like fluid dynamics.

Letting the correspondence depend on ordering seems a bit dirty - I'd clear that with the team first Sounds interesting nonetheless.

Particles and animated textures can probably do things like foam, wakes and waterfalls. Waves I'm not so sure about.

I don't think rigid body dynamics is the right tool for this job, but surely other work has been done on real-time water simulation which could be relied upon.

5. Foam and spray around obstacles in rivers.

I wonder how hard it would be to add displacement maping. Seems like it would be ideally suited for that kind of thing.

Well, perhaps your changes aren't sizeable enough (with no disrespect meant) or they are too isolated to conflict with other changes. The risk of merge conflicts goes up with the number of contributors and the number of changes they make, but it is not something everyone experiences all the time. Conversely, outside contributors may be deterred from making significant contributions if the revision control system isn't capable of handling them. That way, a project can avoid merge conflicts for a long time - but only because no one is bothering to make the kind of substantial contributions that might cause such conflicts.

How well does that work for contributors who don't have an SVN account? I suspect not at all.

Looks very good. I guess the thingy that culls stuff in the SoD needs to be tweaked so objects don't pop into existence at the edge of the LoS.

A solution to LOD "popping" can be tessellation (on newer graphics cards). It has the added benefit of giving artists more vertices to work with at standard zoom, if someone is willing to make the required displacement maps.