Jump to content

myconid

WFG Retired
  • Posts

    790
  • Joined

  • Last visited

  • Days Won

    11

Posts posted by myconid

  1. It's on all the actors named *_slabs.xml in art/actors/geology. They use the basic_spec.xml material.

    They look fine here... :unknw:

    Anyway, I've figured out historic/zaggy's problem with the water. The minimap, health bars and sky have one thing in common: they are all drawn with ancient OpenGL 1.2-era commands. For some reason, they don't like the more modern shader stuff.

    To reproduce the bug, I added the Roman barracks at an empty location on Oasis 10. I zoomed in completely (until inside the building, so it's the only thing being drawn besides terrain) and then out, and boom there it is. The sky becomes really dark (hence the water problem), while the minimap and health bars become black.

    So far, I've started giving the sky renderer a little face-lift. That works like a charm now, but it's not ready for commit just yet.

  2. I have noticed the same black health bars and black minimap a few days ago. Moving the view usually did away with the effects, unless I moved back to the old position. I did not check the water, as far as I noticed it didn't occur on the water (or this was not in view when things went black). I used a Macbook Pro 15" from 2007, so a quite different system (Nvidia 7800GM GPU), so it is indeed probably not a driver issue. This was with preferglsl=true, as well as the other relevant settings set to true.

    That's a very useful datapoint, dvangennip! Btw, would you be able to recreate the problem for testing purposes?

    When any of you experience these 'black' issues, can you please try disabling and enabling shadows (from "MENU -> Settings") and see if it makes any difference? It sounds a lot like issues I've had with the minimap when shadows are enabled.

    I haven't forgotten about that. It might be related, though I kind of think the minimap thing you experienced is a separate engine bug. Will try to track that down too, as I'd like to have that fixed.

    I get a strange shimmering artifact on the base of this metal mine rock:

    Hmm.. That's probably the old specularity. I wonder if there's a material missing the "specularPower" line or something. See if you can find which actor that is.

  3. The problem I see is that I have heard of very little espionage in the ancient times. I do like the third idea for capturing.

    From Wikipedia:

    Events involving espionage are well documented throughout history. The ancient writings of Chinese and Indian military strategists such as Sun-Tzu and Chanakya contain information on deception and subversion. Chanakya's student Chandragupta Maurya, founder of theMaurya Empire in India, made use of assassinations, spies and secret agents, which are described in Chanakya's Arthasastra. The ancient Egyptians had a thoroughly developed system for the acquisition of intelligence, and the Hebrews used spies as well, as in the story ofRahab. Spies were also prevalent in the Greek and Roman empires.[1] During the 13th and 14th centuries, the Mongols relied heavily on espionage in their conquests in Asia and Europe. Feudal Japan often used ninja to gather intelligence. More recently, spies played a significant part in ElizabethanEngland (see Francis Walsingham). Many modern espionage methods were well established even then.[2]Aztecs used Pochtecas, people in charge of commerce, as spies and diplomats, and had diplomatic immunity.

    It also links to this essay: http://www.historyne...ncient-rome.htm

  4. Have you ever played a game called Seven Kingdoms? It's always been one of my fav strategy games, and it was made free/open source a couple of years ago.

    Anyway, a very interesting game meachanic is the spy units, which you can dress in the enemy's colours and send them into their base. You can give them commands (even though they look like enemy units) or you can just leave them be and they'll stay undercover and behave like normal enemy units. Their main functions are:

    • They can change to any player colours on command, as long as there's nobody around.
    • They can do assassinations. If you put them in a fort, you can use them to assassinate a general or king.
    • They can capture buildings. If they are promoted to generals and placed in a fort, they can capture that fort and any soldiers garrisoned in it. If they are alone in any building (no workers in a factory, no soldiers in a fort, etc), they can capture that building. They can also bribe a general to defect, which also captures the building and soldiers.
    • If placed in a village, they can lower the loyalty of the civilians, which can lead to lower tax revenue and even riots.
    • They can do sabotage. If placed in a mine or factory, they can lower production or even stop it completely.
    • They can tell you the status of a building and steal government secrets. How many soldiers are garrisoned in it, what resources are stored in it, tell you a kingdom's amount of resources, about alliances between kingdoms, population data, find out the locations of enemy spies in your kingdom...
    • If placed in your own buildings, they do counter-espionage. That is, they find and arrest enemy spies.

    (Their success is based on their spying skill level, which typically increases with the amount of time they remain idle "sleepers").

    If you have several spies working together, you can tear a kingdom apart and they'll never know what hit them.

    That game didn't have a way of capturing a building by force directly, afaik. As soon as a building was attacked, all the soldiers came out so the fighting happened outside. You could then send in a spy to do the capturing, if you wanted it.

    Also, if you placed spies in a friendly/allied kingdom and they were discovered, you took a reputation hit or in the worst case ruined your friendly status with that kingdom.

    Not sure if any of this can work in 0ad, but I really like the idea of spies peeking behind enemy lines, stealing resources, bribing generals to capture buildings/soldiers, sabotaging unit production and so on.

  5. Maybe it has something to do with the seams?

    You mean the ones used for UV unwrapping? No, don't think so.

    I'll try to explain what is going wrong.

    The way parallax works, it expects the normal to be constant across the polygon (i.e. that the surface is flat). In the case of smoothed surfaces like in the Iberian buildings, the normal is different at each vertex, so the surface is "curved" and parallax doesn't have the information to deal with that in the shader.

    To visualise this, consider that the parallax effect moves the surface inwards in varying degrees to create a 3d effect. Where the surface has been pushed in, it reveals what lies behind it, so to find that the effect raytraces in the heightmap along the view direction until it hits something else. The raytracing step assumes that the surface is flat, and the position of the object behind is assumed to have the same normal as the position in front - which are false when the surface is curved! Hence the visual distortion.

    Hope that makes sense.

    Anyway, the technical solutions to this problem that I can think of would be to either calculate and pass the curvature information to the shader, or to add a second set of flat normals for use with parallax (while smoothed normals are used for regular shading).

    Both of these sound crazy wasteful to me, so I'd recommend to just not use parallax on smoothed surfaces. It's better to disable it completely on buildings with too many smoothed surfaces, and where the smoothed surfaces aren't visible (like that Roman camp model) just get rid of the smoothing on the entire model. Normal and specular mapping will still work correctly, so hopefully you can get good results by making the most of those (hint: use a normalmap generated with a Sobel or Prewitt operator to get a more powerful effect).

    (To disable the parallax, choose or create a material that doesn't use the effect. It doesn't matter if the texture has a heightmap in it for use with other buildings that don't have this problem, as when parallax isn't used it will simply be ignored)

  6. I got some weird artifacts playing on the Iberian CC and Scout tower after adding parallex:

    That happens on (some?) smoothed surfaces when using parallax. There was some discussion about it on pages 51/52.

    Enrique says it only happens on polygons that were set to smoothed but are flat, and suggested a way to fix it. I'm not entirely convinced the parallax effect can play nice with smoothed surfaces at all, but it's worth trying what he suggested (and let us know if it helps!).

  7. Deiz: At first I thought it might be using the wrong UV set for texturing, though from your new screenshots it looks like it's in fact being completely random. Then there's the lighter/darker thing, where the mapping is similar, but the lighting changes. So it must be something in the modelrenderer - for some reason, the parameters are sometimes not bound correctly to the shaders! Will look into this (again).

    historic_bruno/wraitii: I need more info... I can guess what might be up with the water, the minimap was already bugged in GLSL mode (or is this ARB mode). What's wrong with the LOS and the status bars?

  8. I'm just using the defaults for everything: no normalisation, attenuation distance 10, constant QMC, no falloff. Blender v2.63a.

    As for loading the props, that's unlikely to happen. The props information is stored in the actor files, which means the script would have to parse the xml, find the props, load them up and attach them in the right places. I think only the Greek buildings have a problem because their main structures are divided up into pieces. The best solution is to store those models in one piece and duplicate some of the textures instead (or combine them in a bigger texture).

  9. This is what I get. Maybe this could be enabled in future cutscenes mode.

    You need to "reveal map" from the dev console. Like I said above, this hack disables all the LOS, so obviously while it gets the job done for now, it's unacceptable for the long term.

    The right way to do this will be to modify the simulation, not the renderer. The process to initialise a cutscene should both tell the renderer to enable sky rendering and also tell the LOS updating component (which is in the simulation part of the engine) to clear the LOS completely (i.e. LOS is still rendered, but it's invisible).

×
×
  • Create New...