vladislavbelov

So the unit and the prop are different actor with different animation files?

if I'm not mistaken they shouldn't be synced (because name just for an animation control), probably it should be synced in that way: <variant frequency="1" name="Base"> <animations> <animation file="units/death1.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood1.xml" attachpoint="root"/> </props> </variant> <variant frequency="1" name="Base"> <animations> <animation file="units/death2.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood2.xml" attachpoint="root"/> </props> </variant> ...

Shouldn't frequency="1" be there in the <group><variant frequency="1" name="Death">...</group>?

Probably yes, I didn't mean something specific, just some test tool. Because pvp matches or manual checking-s are very subjective, we could notice only very visible bugs.

AIs were only as example, I usually test (not 0AD) a balance with python scripts: generate all permutations of possible sides, simulate (very naive) and search some easy situations. Probably for the balance of the 0AD we could use something like this or whatever else.

Any tools which could check the balance (i.e. play non-visual 1000x matches between AIs)?

Interesting way (Taxation of ancient Greece), we could use a slider for balance between war buildings and economic buildings. And like it was in Greece: when a war with someone was started, you move the slider to war and usual building and units costs more, but war units cost less and faster to be produced.

Probably use one type of fields, but with different states (different models). F.e. it's fertile field, after N cycles the land will less fertile and less amount of food per gather. So need to build a field in other place (like real farm).

There is a ticket: http://trac.wildfiregames.com/ticket/4078, it provides to setup match settings to all AI.

The very interesting implementing of 0AD buildings, there is the question: why buildings have different angle? Ins't it worse for perfectionists?

Supporting of OpenGL3+ is a good idea, and I think it would be good to have separated (possibility to switch) renderers (2 - why we have arb shaders, 3.1, 4+, probably vulkan). Disabling of sky isn't good idea, because sky and reflections should use the same texture, and it doesn't really save time, instead f.e. lods, async ocqueries, geomips and many other things, that we haven't implemented yet. I think no need to move shaders, because shaders are moddable, so user shouldn't go to engine to change them. Deferred shading doesn't actually do what you said to wraitii about batching (he means something else), it saves time for fragment processing (it's something in other way), but not vertex. Batching and instancing saves cpu time (because no need to change states so often) and gpu time (no need to change cache so often to calc vertices). But yes, deferred shading is the good technique, and we need it, but there are few things: we need to store the g-buffer as small as possible (components packing), more number of textures to rendering. Dirs 'graphics' and 'renderer' don't do the same thing, 'graphics' is mostly preprocessing, and 'renderer' is actually rendering. UPD. FBOs, it's not actually true, because we don't need to switch between all FBO textures, why? Because we switch to FBO only when need to render to that, but we could use this textures without a FBO binding. So mostly it isn't expensive, but really we don't need so many FBOs.

I think, he means not browser version, but usual lobby match, and players can control units (as usually), terrain/environment too. It's not so hard as a browser port.

As I said to elexis, I have the unstable Atlas patch, which adds functions to control this camera paths, so I hope that it will be added to the next release, and we will make a movie

Both these ways are compatible and difference of mechanics isn't big. And don't need change something in engine to balance game. You could change units/building/etc settings to setup the balance as you want. Perhaps, you need give more detailed suggestions instead of volumetric discussion.

We had discussed with sanderd17 yesterday at IRC, that we can't show how much work translator did. So I have created the small tool to take statistics from transifex. And fcxSanya suggested to share the tool on the forum. Link: https://github.com/vladislavbelov/transifex-stats/ Usage: python transifex-stats.py -i 0ad -u vladislavbelov -l ru This command produce file with next content: http://pastebin.com/jbW6xQTW Instead of vladislavbelov & ru you could paste your username on the transifex and language code.

Cinematic Camera is in progress, I will post another video very soon, currently first part of the cinematic is under review.

About LOD: you can rotate your camera, so you can see objects which are near and far. And with lot of trees it's really slower. And it's not hard work for artists, because we need lower poly than we have now. So most of 3D programs can do this with few click, and some from console. You don't need to use glDrawInstanced or smth like that to do instancing, there are few techniques to draw copies of one object (not so fast as opengl 3.1, but faster than now).

Cool articles Yeah, there are some cool algorithms for visualization in GTA 5. And in my opinion, it's not hard to implement dynamic SSAO or Cascaded Shadow Mapping in 0 AD, even ocean. But I think, LOD & Good Instancing is most needed at current moment for perfomance.

Deja vu

Markov chains are very good for generate recognizable details of landscapes and it works very well, but it needs a lot of data. Do we have so number of scenarios map? Else we will get generating rules, which don't depend on map type (hot, island and etc).

I think it needs good scenario of trailer or intro

Use that for description: https://github.com/na-Itms/0ad/blob/docs/docs/pathfinder.tex, and svn for sources.

A lot of code is overwritten only in CinemaManager, and just small fixes are in math splines. So yes, there is old code, which works. But you will can to see code later.

I have implemented mode, where camera look at target, which is moving by self path. In xml it looks like: <Node time="4.0"> <Position x="467.20" y="40.87" z="887.26"/> <Target x="30" y="-45" z="0"/></Node>Instead of rotation. And target path is interpolated too. But the old way to rotate camera is on video.

Hi everyone, I'm trying to improve cinematic camera code. I think the adding cutscenes in scenarios maps makes them more exciting. After trompetin17 AtlasUI2 merging, you can find patch with UI tool at #3301. Cutscene starts when path has added to playlist from map triggers, and after every path end triggers are receiving an event: which path was ended. I want to share with you for some results. Example of camera movement: And camera path for that: UPDATE0 Camera movement with target movement: