Sonarpulse

On a whole other note, I thought of another long-term/theoretical issue with terrain blending: multi-terrain blending. With the tile system, I believe only two materials/ground-types can be blended at a time. This probably isn't something many map makers have been dying for, but it seems still worth considering. Hypothetically you could do 4 with RGBA each corresponding to a material. I'm not sure that would be the best approach though, for a four channel bitmap has lot of redundancy, for only the ratio between the various materials matters. For example (RGBA) 128,32,64,256 represents the same state as 4,1,2,8. "luminosity" doesn't matter. A simple solution would be to subtract the sum of all channels to get a 5th channel, but I don't know of what algorithms exist for blending stuff (in atlas or an image editor) with the assumption that all channels should add up to a fixed sum. I feel kind of like a raving madman writing about such an odd missing feature, but hopefully that makes some sense.

Full support since march first this year. http://trac.edgewall.org/wiki/TracGit http://trac.edgewall.org/wiki/VersionControlSystem http://trac.edgewall.org/milestone/1.0

Oh, sorry. I didn't not mean to flame in anyway. In hindsight I have no idea how i got the impression you were wondering whether 0ad might switch languages. As a general principle I would say one can use as high-level a language as he/she wants for anything as long as a compiler/interpreter exists which is fast enough for the task at hand. A second more practical consideration would be the availability of libraries to simplify the task. Edit (2013): I now know Rust as actually a great language for high-performance desktop applications.

Is there a technical reason why a single map-wide mask would be inferior?

Oh, OK. I assumed the game had a single large mask for the entire map, not a "patchwork quilt" as evidently is the case. My dithering idea was a way to get more natural looking transitions out of the same resolution blending texture, were the map to use one single mask.

That reminds me, if the git repo is updates with a svn revision that came from git, does that mean the history in the git repo is squashed to conform to the svn version or does everything play nice?

Here is normal blending versus two types of dithering. (The third, not showed, approach is a clean break in the middle.) Now dithering is traditional y used as a way to go from a a smother image to a pelleted one, but perhaps the two steps of stretching the texture map and dithering it could be combined into one "shader" (I'm not sure how/if OpenGL let's one add texture stretching methods).

What about my dithering idea? not to self promote, but I always thought smoothly blended textures looked really bad. Even if the alternative is the wavy artifacts we see here (akin to the line of sight "circle" in aoe II I might add). In real life, sand turns to grass as patches of grass start to appear more and more, and the soil gains more nutrients. with snow, patches of snow become bigger and bigger until they cover the entire ground. I see no real life inspiration for smooth blends, only granular ones.

Wait... What are you advocating? The game industry has gone complacent with lower-level languages more suitable for systems programing? Or that gaming is developed enough so that new languages, libraries, etc are worth the effort of switching?

I dunno, unless it's a new technology with an old name, I'm pretty sure of myself. The vertex blending I know is a old technology used extensively in older FPSs for example. It's only as good as the number of vertices you have in your mesh. I think the example you showed just has a lot of vertices. See this old article: http://www.katsbits.com/tutorials/idtech/vertex-texture-blending-applied-to-models.php

Vertex blending is much worse. Think vertex shading vs per-pixel shading. Also since the heightmap and texture max seem to have the same resolution, it would basically have the same affect. Perhaps for the hieghtmap some sort of "intelligent dithering" stretching algorithm instead of the bilinear/trilinear we have now would look nice. That would do stuff like mini sand dunes and patches of snow automatically.

Well, C++ get's bigger with every standardization. In more seriousness, http://www.paulgraham.com/icad.html .

In regards to the line ending issue, it maybe wise to keep a .gitattributes in the repository. Not only does mean each user no longer needs to individually setup git, but I've found it works more reliably too. simply * text=auto eol=crlf might be enough to get the job done. Also, myconid mentioned compiling GLSL to ARB. As the number of sharers increases going forward, shouldn't that be the most robust solution?

I personally am very interested in alternative languages and paradigms, but with an established codebase like 0ad/pyrogenisis, the cost of switching languages often outweighs the benefits.

Well in 3ds max as you probably know you can "make a shadow" by placing a light-source in the scene. I assume that is the best and most proper way to do it in blender too.

I know some programming, but I am just going out on a limb here. This game, http://www.wolfire.com/overgrowth , is pretty famous (as indie games go) for it's animations. Here is an interviewer where one of the few people behind the game talks about the animation. Obviously in RTS animation is way less important. But if methods like those make animation development easier (and not just the finished product more awesome), might they be worthwhile to implement?

In 3ds Max you can bake such a "procedural wrapper" like box mapping to a manual UVW unwrap. I can't see why blender wouldn't support that too.

So does that only work for line right now?

Excellent. For the record though, I've found that git add -A ; git reset --hard HEAD works the best. Something about staging modified files induces git to delete them more reliably.

Yeah, I don't think a new android interface should be given any priority until part 2. But if somebody tweak the SDL to work with an external keyboard and mouse, a playable android version should be quite trivial.

@Gen.Kenobi I was more addressing Kyriakos who started the thread and evidently is trying blender instead of 3ds Max. But that's awesome that you also mod C&C. I hadn't heard of Tidal Wars before like a pretty sweet concept. I'm not actually on the team that makes APB but I've made some "sub-mods" so to speak. My hope is that someday Pyrogenisis may be able to handle C&C recreations.

OK, yeah I said blender was better based on licensing issues, and the animation thread demonstrating a consensus that moving to blender was worth the pains of conversion. That said, I didn't know that for static models and an eventual collada target import/export both ways is pretty good. My main experience with 3ds Max is with the A Path Beyond game in my sig where importing/exporting to work in another tool (animation or no animation) is very lossy and something to be avoided. If everything (besides animation) than can be done 3ds Max and supported in Collada can be imported with equal finesse to blender, then I take back what I said. Blender is better for avoiding licensing issues and all that. But for making static models you should be able to work in 3ds Max, if that's what you are more comfortable with, and not worry about the team finding your work less useful in the long run.

Off Topic, but I noticed that in the screenshot with the Nile map, it said the river divides the map into north and south halves. Seeing that the Nile is a mainly north-south river wouldn't saying it divides the map into east and west halves make more sense? The river is vertical in the preview too.

Looks good, it's certainly more than I've done with the program. BTW, Which is easier at the moment, getting models from Blender to 3ds Max or vice versa?

In your defense, after I wrote it, I realized that computing the stretch values from a 3D displacement map (r=x g=y b=z) would indeed be simpler than I thought.