vladislavbelov
-
Posts
1.324 -
Joined
-
Last visited
-
Days Won
22
Posts posted by vladislavbelov
-
-
3 minutes ago, wraitii said:
Hm, the water settings you posted above are good. I notice some artifacts in the reflections though. What map-specific settings do you use? Water waviness? Water type? This map looks like it would benefit from much smaller waviness and water type "lake" or "clap".
There're few issues with the water: not clean reflections, shifts of reflection (the issue above), not so realistic refraction's colors.
-
6 minutes ago, wowgetoffyourcellphone said:
oh god, the game needs the 4th one in a row? how about a gameplay release...
There is a campaign ticket with a WIP patch: #4387. So I hope that it will be finished to A22.
About "V": the very interesting letter...
-
I mean the way where no variations, only animations:
40 minutes ago, vladislavbelov said:Or even without variations:
<animations> <animation file="infantry/general/walk1.psa" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" name="walk2" speed="250"/> </animations>
It's for the prop, not for unit.
-
29 minutes ago, wowgetoffyourcellphone said:
ediT: No, that is not working. Looks like the example @sanderd17 gives here is exactly how I am try to do it, but it is not working.
Have you tried the last one way?
-
53 minutes ago, wowgetoffyourcellphone said:
http://trac.wildfiregames.com/ticket/2324#comment:8
The last example there is what I am trying to achieve. I saved the names "death1" and "death2" in the dude's actor death variant file just like in the example (but death instead of walk). Then in the cape file I use death1 and death2 as the animation names and they do not sync. :/
There is frequence="1" again, but in the animation. Also "it will save the name for the props", probably you need to do this for unit:
<variant frequence="1" name="Walk"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant>
And for prop:
<variant frequence="1" name="walk1"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> </animations> </variant> <variant frequence="1" name="walk2"> <animations> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant>
Or even without variations:
<animations> <animation file="infantry/general/walk1.psa" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" name="walk2" speed="250"/> </animations>
I'm not sure, I'm searching in the source.
-
1
-
-
9 minutes ago, wowgetoffyourcellphone said:
Same animation file (for reasons). It all works fine if i just use one death animation, but when i use the 2, they become unsynced and sometimes don't use the same animations. I thought it was possible to set a name in the actor that they would both use and so use the same animations together.
I'm not sure that it's possible yet: sync different actors for animation with the same name and file, especially if actors described in different files.
-
2 minutes ago, wowgetoffyourcellphone said:
Both the dude and the cape use the same death animations. death_a.dae and death_b.dae. These are variations of death. So I am try to get the dude and the cape to use the same death animation at the same time - synced.
So the unit and the prop are different actor with different animation files?
-
15 minutes ago, wowgetoffyourcellphone said:
@vladislavbelov: Your suggestion now makes both the base unit dude and the prop do their death animation (thank you!), but they do not sync as they should based on them having the same name="death1", "death2" etc. Any more idea?
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>?
-
1
-
-
2 hours ago, niektb said:
@wraitii wrote a template analyzer a while ago. I think that does exactly what you mean, @vladislavbelov
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.
-
1 hour ago, Eraser said:
I fear AI currently can't exploit unique most civ mechanics afaik, specially the new ones I introduced (I've seen a Rome AI expand using Castrum thought).
I would suggest doing 1vs1 matches, be it against AI or a real player, so at least there's a player checking if things are too op.
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.
-
2
-
-
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).
-
1
-
-
5 hours ago, STHanger said:
Thanks, but this does not have the option to start the game without a UI right? I am now able to start the game and let two AIs battle immediately, but regular playthroughs would take way too long.
There is a ticket: http://trac.wildfiregames.com/ticket/4078, it provides to setup match settings to all AI.
-
1
-
-
The very interesting implementing of 0AD buildings, there is the question: why buildings have different angle? Ins't it worse for perfectionists?
-
2
-
-
On 12.02.2016 at 8:42 AM, aeonios said:
This was my source regarding FBOs: http://www.songho.ca/opengl/gl_fbo.html
Updating to 4.0 would alienate more than half of all players, and if it's optional then it shouldn't interfere with the rest of the code anyway. Eventually I'll look through his code and see what he's actually trying to do and how that could best fit in. I'm not really to the point where it's relevant yet anyway though.
That's what deferred shading does basically. First all objects are rendered onto a scene texture without lighting, and then all of the lighting calculations are done on the scene texture rather than per-object. Basically the entire scene becomes one object when fragment shading, which reduces the number of fragments that need to be produced.
The "if" I was talking about was actually the branch for the red-water issue, which is an "if" as opposed to an "#if". That's actually only supported by GL3.1 or newer, which I didn't notice before, but that's probably the only thing in the entire shader which isn't 2.0 compatible. TBH I'm not even sure why that compiles when the shader version is set to 110 and dynamic conditionals require version 140.
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.
-
1
-
-
4 hours ago, sanderd17 said:
An online map editor (as being able to edit the map online) will be very hard to implement. We'd basically have to port our entire game to the browser, which won't happen soon.
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.
-
1
-
-
On 29.03.2016 at 9:46 PM, feneur said:
Indeed
For this version it is not easy to use, but hopefully it will be a lot easier in the future On 29.03.2016 at 9:44 PM, Sturm said:Are you talking about the "Cinematic videos" such as Vladislav Belov videos uploaded on YouTube? If thats true, that is an awesome news!
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
-
1 hour ago, SeleucidKing said:
Okay, myself included, I see a lot of threads talking about units, balancing, and gameplay mechanics. But I think that we as a community (and the devs) need to think about is what type of game do we want.
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.
-
3
-
-
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.
-
3
-
-
By the way, any news about the Cinematic camera videos?
Cinematic Camera is in progress, I will post another video very soon, currently first part of the cinematic is under review.
-
1
-
-
I think different levels of detail are hard to do (lots of modeling work, not that many 3D artists are active at the moment I believe). And LOD works well when objects are both close (need high detail) and far away (can be low detail), as you might have in a first person view. The top down view of a typical RTS game like 0 A.D. has to have most of the things on-screen at the same level of detail because those are equally distant from the viewpoint. It would only provide a benefit once people zoom in or zoom out quite far.
So I don't know how strongly this game would benefit from LOD changes, although that also depends on the amount of mesh complexity reduction that could be achieved. Keeping the extra meshes in memory (ready to be swapped in and out) also comes with some cost in memory.
Instancing would probably have a larger impact as the average player will have many times the same building on-screen (such as houses, towers and walls), the same goes for the environment (trees are a good example). I'm no expert so I wouldn't be able to guess how much benefit may be obtained and whether it's worth spending development time on that (and drop support for any non-OpenGL 3.1 compatible systems).
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.
-
1
-
Flying buildings
in Bug reports
Posted
The first link is unreachable (https://wildfiregames.com/forum/index.php?/topic/18265-terrain-flattening/).
I agree with @FeXoR: current version has the balanced solution.