Leaderboard

Temperate Terrains on a new map I call Gallic Highlands The Belgian Bog map using new Temperate terrains A reimagined Lorraine Plain map using new Temperate terrains How a jungle map (here using the India set) can look

Gentlemen, I declare this shader finished. I wanted to put the skybox fetch, but I don't know how to pass the info to the shader. I copied the code from the water shader, and so it should work, but it is not getting the skybox and the rotation; and my C++ sources are nowhere near compiling state; I interrupted the engine work I was doing to work on shaders; and I no longer remember where I was at. In any case, the sky box was not going to help much, unless it has LOD's to bias into, to control blurriness of reflections. Then there is the green-detection hack, which should have worked but this common_model shader does not seem to have jurisdiction over too much foliage, apparently. I don't know what shader does the trees and stuff. So I removed the green hack, and the skybox; all I have is metals blue dresses human skin And that's it. It works. It does have a few bugs I cannot resolve, like the fact that roofs often acquire glossy varnish as the skin detection hack gets confused by the similar color to skin. Overall, though, it's darned good. What makes it so good is the correctness. Even down to the detail that specular highlights look brighter the smaller they are; this is something I have NEVER seen anybody else take into account. The Fresnel calculation is based on Schlick's approximation, which is a science level approximation; not some cheap graphics hack. The lack of skybox is not an issue at all, in my opinion. The reflective items are small and curvy; you don't have big mirrors here; it's not like the water, where you need to see clouds reflected. This is small objects like pots or helmets reflecting; a sky-biased ambient light is plenty good for that, specially WITH self-occlusion and ground occlusion hacks. And we got variations in dielectric constant and in shininess, albeit all ad-hoc values, like 1.5 index of refraction for skin, versus 1.0 for everything else. Specular power I take over a lot of the time, increasing it for metals, decreasing it for non-metals, setting it to 17.0 for skin, and to 2.0 for blue dresses. That's nowhere nearly as good as being able to specify these things via texture channels, of course; but that's the next shader. So I invite you all to try it, discuss it, give me feedback, so we can finalize this and move to the the big one. You need to apply a patch first, then replace the shaders attached below. The patch is attached to this post here: And you may also have to add a line to your config for gpu_skinning for the ao to work, I'm not sure because according to Stan it should make no difference, but if that's not what made the difference for me seeing the ao's in game, I don't know what did. model_common.fs model_common.vs terrain_common.fs

Position: Historian, linguistics consultant, text editor (not in the list of openings, but I have seen a few things that could be very much improved) Do you understand that Wildfire Games is a non-commercial project, work for 0 A.D. is volunteer, and work is done for free? Yes Do you agree to distribute all your work for Wildfire Games under Creative Commons Attribution Share-Alike license? Yes Are you sure you are not wanting to work on something programming related? (Then you don't need to send in an application form.) Yes Name: jorellaf Email: contact jorellaf com Location: Europe Availability: 1-4, depending on the week Age: Mid-20s Occupation: PhD researcher in archaeology Skills and Experience: PhD in archaeology, in-prep papers in ancient history, work in other historical mods, intermediate Ancient Greek, some Welsh, programming in various languages, from Python to C++. Motivation: I have had an interest in ancient history for a long time Personality: Affable but also hot-tempered judgemental nitpicking perfectionist with a sense of humour. Short Essay: Can't remember when I first heard of 0 A.D., but I've played on and off since around 2016-2017. Wanted to work on such a nice open-source project, and contribute my own knowledge to help out wherever I can, especially when it comes to improving things. I like to point out issues and help correct them, which also drives me to do research whenever I feel something is not right. I try not to be an eternal downer, and like to construct rather than destruct (not a word probably). I'm a friendly person, I swear! Interests and Hobbies: Ancient history, archaeology, illustration, drawing, folk and ancient music (beginner, can't play instruments properly worth a crap), aviation, historical linguistics, Celtic languages. Staff: Nyet. Community: RTW Discord, Total War Centre, Total War org, not very active normally unless I'm helping out. Favorite Game: Currently: Rome: Total War with RTR? All time: perhaps RTW with EB? Hegemony I and/or III? EU3 with MEIOU? Hard to say really. Work Examples: See, e.g. here, here, also made the faction logo, though trying to rework it for another illustration cause it's kinda crap. Working on the RTR8 team (made the game launcher too).

I have already been experimenting with giving the game a much needed update to the terrain textures. I have been exclusively using assets from this website here, licensed as cc0: CC0 Textures - Public Domain PBR Materials We could contact this gentleman and ask for his assistance in creating new assets if his site currently does not have them and WFG could even become a Patron (his highest Patreon level is $5/month). Even if we don't try to partner with him, we can still utilize his excellent CC0 assets and ask him to check out how we're using his stuff. cough I am very keen now on using CC0 or CC-BY-SA materials. eh hem. And so far the results have been better than I'd hoped. EXAMPLES India: Desert (using assets from the India biome) Alpine-Polar (I think these 2 should be combined) Pros for updating the terrains: The game's current terrains are inconsistent in quality and scattershot in style. A new set of terrains can unify the quality and style. Terrains take up a massive amount of screen space, or what the player sees, so improving them gives a large boost in visual quality. The current terrains don't fully take advantage of the graphics engine's capabilities. A new set of terrains can do that. Improving the terrains can bring the look of the game closer to modern expectations. We can reduce the sheer number of terrains by half, which comes with the benefit of visual consistency and ease of use for mappers. Cons for updating the terrains: It will take considerable effort and take attention away from other possible tasks. The new textures will be on average 4x larger than the existing textures and will add normal maps and spec maps where previously there were few. Will increase the graphics memory load and possibly push out those with low-spec computer rigs. ?

Thanks. Although I haven't read the book myself, I daresay it's worth a read. Anything published by Brill is generally high-quality. Moreover, books such as this, where various experts each contribute a chapter on a specific subject, tend to reflect recent scholarship and can greatly further one's understanding of a topic, as well as make one think about something from a different way than one would otherwise. That said, they're not introductions written for a general audience. (I don't know if that's the purpose of this thread.) This title is actually part of a larger series ( https://brill.com/view/serial/IMEM ), of which some volumes are open access.

It's just right. If you want more light, make the sun brighter, or increase ambient. I don't have any hacks to alter the physics or the optics; it is what it is, according to the lights and the materials; no more; no less. It just follows physics and optics. Users have brightness AND contrast controls on their monitors; so do I; so do you. How do we know that our controls are all adjusted exactly the same? This is a subject we should explore, like how bright or dark should it be shipped, so that it doesn't fall out of the range of users' adjustments. One thing I would hate, though, is in-game brightness controls, before anybody asks; because then you run into the trouble of "should I increase the game's brightness?, or my monitors?, or my videocard's? Too many adjustments in a long chain. It's like if you are a musician, and you got 5 effects pedals, each having a gain pot, followed by the amplifier's gain; and you also have a volume pot on your guitar or bass; you end up with like 10 volume pots, and you don't know which needs adjustment. Let me ask you another thing, though: In the real world, would you go about complaining it is too dark or too bright? I mean, today we would, because we have electric lighting we can control. But in the real world it happens often you're near a building at dusk, and the building looks super bright with golden radiance; and the rest of the place looks rather dark. No? Why should it be different in-game? Obviously I'm not alone feeling like this way, as someone created an Acropolis at Night map, designed to be dark; --even challengingly dark. I played that map several times. As a gamer I enjoy realism far more than I do unrequested catering to my incorrectly presumed preferences. If you want to know how it all got darker than before, well, part of that is that a lot of the stuff has bright specular textures, most of which I'm suppressing. The ambient occlusions were not being used in many cases, and where they were used, their gain was turned down to as low as 0.6 for no reason whatsoever (in those xml files); and then the shader was multiplying the ao's by 2.0, also for no reason whatsoever. Last but not least, some of the grounds had bright specular textures, causing the color of the ground to go to saturation. Once I turned off specular in the terrain shader, the diffuse textures, specially the Acropolis map, were still too bright, so I worked at detecting grayscale color (in the terrain shader) and dimming it while increasing contrast, and lo and behold, I discovered for the first time that the ground in the Acropolis map had nice square tiles. I had never known that before. The same goes for some of the stone paths, like in the Badlands, and Belgian Bog; now they can really be appreciated in their full beauty; before they were just whitish blurs. So yes, if you try to go brighter than monitors can display, you lose a lot of detail :-) You might care to sue Samsung rather than blame me. So right now everything is right, by physics and optics. The way to increase light is by cranking up the light, if that's what you want; but it looks good to my eyes. I want to see contrasts. I want to see bright sun reflections contrasting with darker surrounding objects. If you make everything be as bright as to be in the goldilocks of visual perception, you lose realism and beauty overall; it all becomes a cheap arcade. You might as well ask Goya why his paintings were so dark. Well, he was showing realities that other painters were ignoring. The question is, does it look real? Forget about passing judgement on how bright or dark it should be; does it look real? Having said all that, I do enjoy direct sunlight, in the VERY FEW maps that feature it. In the pictures I just posted, only the first one shows some hint of nice rays; the rest are all ambient light based, which is boring as hell. More maps should be like Belgian Bog and Oceanside. Beautiful suns... Ambient light should be reduced in most maps; it is so bright it doesn't let you appreciate the sunlight; and it reduces the visibility of shadows, which are important for 3D perception. EDIT: Speaking of brighness and contrast, I just remembered an issue we worked on at Vegastrike, namely "gamma awareness", which is a rather obscure subject... Monitors, for the longest time, have been very non-linear devices, and it's been customary to this day to compensate for the nonlinearity in the color values of assets and textures. The theory is long to explain, but in practical terms, what it boils down to is that when a shader reads any textures, it should immediately square the value, to convert from standard texture gamma to linear space. Once all the light computations are done, and the shader is about to output the final color for the pixel, it should take the square root first, then output, so as to go back to display device gamma space. I'm going to try this tomorrow. I mean today... 4 AM !!!

system info and crashlog coming but not this is not actual crash and the game continued fine. Reported by @Edwarf @vladislavbelov The replay is another bug. Two of A six women batch at the beginning of the game decided to back after being tasked to the woodline @wraitii 2021-02-16_0005.zip

Hello all, I am a web developer and, more importantly, a huge fan of the game. Lately, I've been considering making a web application of the structure tree so that players can study it from where ever they happen to be. I'm not familiar at all with the source code, so I could use some direction finding data structures and image files that I could use for building this project. I've found the technologies and civs JSONs but I could really use some pointers from people more familiar with the source. I'm open to any and all ideas. You might even think the community won't be interested in this project - doesn't matter, I'm all ears! Thanks!

Is that something I should remember or try to believe? Well, I've been forced to move dozens and dozens of things out of conditionals, or else it won't work. One asset denies me having a normal; another denies me the half-vector, another denies me the view vector... I can't see the USE of denying information to the shader. If the shader doesn't use it, nobody hurts; but trying to get something done and having problem after problem after problem, THAT hurts. Anyways, I'm making some progress now. Look at this picture, and look at those women's arms... See the whitish specularities? That is natural skin Fresnel sheen, my friend. The opposite end of the spectrum, vis a vis metals. Now we got the full range of materials. Too many hacks, though; I wrote a skin detection hack, but it detects parts of the building as being human skin, so the sheen is applied to some of the trim... I also wrote a blue dress detection hack that makes their dresses a bit shinier.

There's WAAAY too many options and conditionals in the shaders; it is an incomprehensible rats' nest. I mean, if something does not need a normalmap, just give it one texel normalmap. If something doesn't need a specular texture, just give it a single black texel specular. What is the need to have compiler switches everywhere, gazillions of different shaders...?

What I'm saying is I think there is value in having a stable 'meta' for the game. I'm personally rather satisfied with a 4-6 months release cycle, not that we've had that in a long time. I am not convinced that an exclusively "continuous delivery" model is better. I can't say I'm 100% certain of this, though. Just not something I'm really looking at working on.

darn it is looking cool

You're really not addressing my point. The technical side is trivial to an extent. The fact is that the gameplay would change, and that's not a good player experience. Changing the revision while joining a game, so you don't even know what you're playing? Absurd. That being said, including an easy way to auto-update, even with semi-regular releases, is likely a good idea. Whether it should be a priority, I'm not so sure. We'll take patches, should they be sufficiently well written.

I'm not convinced that we need to, or indeed should, switch to a "continuous release" model, to be honest. Yes, it has pros, namely more testing more often, but it'll make the game both less buggy and less stable. Further, for players, continuous balance changes won't be very good. There are advantages to periodic release - 'marketing', things like that. 'Real' companies do a bit of both, but video games that I know tend to work with semi-regular "patches", not actual continuous releasing. There's likely a good reason for that. It would also be rougher on modders, who would need to maintain their mod continuously to avoid issues (though of course, it somewhat makes it easier). I believe shorter release cycles (4-6 months) with an "svn" alongside, is overall a rather good model.

Slightly late this week!

Just a few thoughts (been following this conversation with interest!)- The modern, end-user-friendly solution for something like you're describing might a game install/update service like Steam or GOG Galaxy. There are many work-in-progress commercial games (M&B II: Bannerlord comes to mind) which pursue a highly-active (near daily) update schedule on such services for their Beta branch, while preserving a monthly 'Main' branch for players seeking a less buggy and more consistent experience; both separate from their internal development branches of course. Granted, we're talking about projects made by teams 5-10x larger than the active dev team on 0 A.D., who are also full-time paid employees of a company, but I digress. In my experience making music software, a not-insignificant number of (non-Linux) users struggle even to do basic things like copy/paste or renaming files. I once sought a simpler solution for sharing FOSS musical sample library projects while in development and even went so far as to advocate the mediocre but relatively simple GUI-based Github Desktop app; yet still the vast majority just preferred to download the .zip from the mirror despite my best efforts and tutorials... so, personal rule of thumb, if setting something up is any harder than 'download thing and click a button', it's not going to fly for many if not most end-users. Even proper GUI-based installers can be problematic for many, especially if they click too quickly through and do not read the steps. I like your suggestion of separating the repos for art and such out. Already many of the original raw game sound effect assets are completely lost to time, so we're stuck with either replacing them outright or working from lossy file formats. Now we mostly do sound development over on a separate Git which functions as a Mod for the game, so a small group of us can iterate quickly on a few ideas (and share them with others) before committing anything to the game itself. Returning to the topic at hand, I think what you are doing looks great so far, especially if combined with the aforementioned new textures. I think the proper solution here would be to fully implement texture maps/keys for metallic as you suggested earlier, rather than trying to auto-detect. That'd probably take an enormous effort, but it is the sort of thing which needs to be done honestly. In the sound department, for A24 we mostly just tried to patch problems up with 'meatball surgery', but for A25 we're already at work on deeper, more fundamental changes to make the sound assets and their implementation consistent and "correct". Keep in mind 0 AD has been in development for well over a decade. There are brilliant, clever implementations of things, and sloppy messy hacks right next to each other in every corner of the game. New features and changes are not checked by a singular Producer or Director, but by the team as a whole- an experience which can seem at times like an inquisition, when the actual intention is to ensure there are no weaknesses in the proposal and that it will provide a suitable foundation for future development. The deeper the change, the more things are at risk, and as a result the game tends to move more slowly the deeper you want to go. It is easy for me to replace a few bad or poorly made sound effects from a decade ago, but when we get into stuff like changing (or fixing!) the way the sound engine works, it takes a lot more planning and discussion to make sure things work and what we leave behind will be workable for many years to come. In my opinion: Having said that, it also means it is fundamentally necessary that any code changes really need to be done the "right" way. Layers of hacks upon hacks is what has caused numerous issues on the project, so I believe it's essential whatever is decided must be done fully and in such a way that it doesn't impede future work. This means in a perfect world, changes shouldn't compensate for, override, assume, or guess about assets or previous work because that creates a feedback cycle of spaghetti going back into spaghetti. Ideally every change should be at the root of the issue, not treating or concealing the symptoms. If I understand your proposal and the architectures involved correctly, that means implementing this requires fixing textures so they give you explicit information on what is metallic, and integrating that in the workflow so all textures present and future have that.

4K

Delenda Est-izing Sahyadri Buttes

Some Sunday 1v1 fun!

More wildlife! This time, camels!

I have made another thread with Iberians, I have put something that could be useful as a wonder, a fort that used the greatest Iberian technology of the time, unique fertility rituals in that area and all the defense measures that were never used, because it is about of an exceptional historical and monumental complex, unique in our Spain From here the people of the ilergetes were born, who had Indíbil and Mandonio as main

Buenos días/tardes La actual maravilla para los íberos "Cancho Roano" realmente pertenece a la cultura Tartessos e intentar hacer que la actual civilización de los íberos represente a todas las diversas culturas de la Península ibérica es un ERROR HISTÓRICO grande , e pensado que la maravilla puede ser sustituida por un palacio; Boceto nueva maravilla íbera ; (vista frontal) (vista trasera) Intenté darle unas texturas similares a las actuales del juego , pero no se si está muy logrado (por eso no le puse detalles , hasta no tener certeza de que este proyecto es viable) , me inspiré en las ruinas de un palacio íbero de Andalucía (España) pero me tomé algunas libertades a la hora de crear el boceto por la falta de información suficiente , en lo general es históricamente correcto ya que los aristócratas íberos acostumbraban a construir sus viviendas suntuosas y esto no es un caso aislado arqueológico. Referencias; Disculpen las molestias*

Recreated the 128x128 thureos texture in 256x256 size and created two new shield textures for the Thracians.

Yes, that too, I have found however pics under the license of an Albino\Blonde Zebra, as well as Burchell's Zebras with quagga like patterns, the albino has the hooves in the grass, so it could be hard for skins here is a photo that could be good for quagga mutations found in burchells zebras, the zebra at the end of the photo that is drinking in a side view, could be alright for a mutation

Also keep in mind there are three different zebra species, each with fundamentally different skin patterns:

Here are some more textures, I am planning to consult on adding a Scythian horse archer unit to Atlas