Light Style© by Fisana

Jump to content


Photo

Progress reports on funded work


  • Please log in to reply
239 replies to this topic

#181 plumo

plumo

    Centurio

  • 0 A.D. Art Team
  • 953 posts

Posted 25 February 2012 - 01:39 PM

Keep up the good work, Philip.

It seems tedious to do, but the possible advantages are needed. Also remember, if you succeed you will be the first open source contributer to program a decent RTS AI. :banana: In my eyes that is very significant groundwork for all next open source RTS games.

History is yours, my friend :cheers:
  • 0
B. Guns [aka Plumo]
0 A.D. Community Liaison
Contact email: plumo@wildfiregames.com

#182 iap

iap

    Sesquiplicarius

  • Community Members
  • PipPip
  • 101 posts

Posted 25 February 2012 - 07:27 PM

Keep up the good work, Philip.


YEAH! :D
  • 0

#183 hhyloc

hhyloc

    Duplicarius

  • Community Members
  • PipPipPip
  • 214 posts

Posted 26 February 2012 - 05:09 AM

It's nice too see the game improves and advances with a steady rate everyday thanks to your hardwork Philip :)
And since the Pledgie donation campaign has finished with (at least) 13$ dollars over goal, I wonder that will you continue to work full-time for another month?
  • 0

#184 Echelon9

Echelon9

    Discens

  • Donator
  • 66 posts

Posted 26 February 2012 - 07:31 AM

1330232949[/url]' post='235022']
It's nice too see the game improves and advances with a steady rate everyday thanks to your hardwork Philip :)
And since the Pledgie donation campaign has finished with (at least) 13$ dollars over goal, I wonder that will you continue to work full-time for another month?

Yes great to see another Pledgie campaign successfully raised.
  • 0

#185 fabio

fabio

    Centurio

  • WFG Programming Team
  • 607 posts

Posted 26 February 2012 - 07:47 PM

Also remember, if you succeed you will be the first open source contributer to program a decent RTS AI. :banana: In my eyes that is very significant groundwork for all next open source RTS games.


Could the new pathfinder be released as a standalone library, so that other open source projects can use it (and, eventually, also improve it for us :))?
  • 0

Graphics problems with 0 A.D. under Ubuntu and free drivers? Check out the Updated and Optimized Graphics Drivers Archive: includes updated drivers with fixes and improvements for games, including 0 A.D..


#186 Sonarpulse

Sonarpulse

    Sesquiplicarius

  • Community Members
  • PipPip
  • 166 posts

Posted 27 February 2012 - 08:16 AM

These updates are so fascinating! Thanks for your effort, Phillip.

Could the new pathfinder be released as a standalone library, so that other open source projects can use it (and, eventually, also improve it for us :))?


Well either way the code will always be there for others to use.
  • 0
Posted ImagePosted ImagePosted Image

#187 fabio

fabio

    Centurio

  • WFG Programming Team
  • 607 posts

Posted 27 February 2012 - 08:34 AM

Well either way the code will always be there for others to use.

Yes, but this way it's more difficult to keep them in sync, they will eventually diverge and improvements become incompatible. Obviously developing a library that can be used by different projects is more difficult.

In another news Spring 0.86 got recently released with many pathfinder improvements: 0.86 changelog.
  • 0

Graphics problems with 0 A.D. under Ubuntu and free drivers? Check out the Updated and Optimized Graphics Drivers Archive: includes updated drivers with fixes and improvements for games, including 0 A.D..


#188 feneur

feneur

    Cartographer of imaginary worlds

  • 0 A.D. Project Leader
  • 7,627 posts

Posted 28 February 2012 - 08:52 PM

Not sure how relevant it is, but I thought I'd forward this comment from the ModDB repost of the day 15 writeup:

The other, less computationally intensive approach, is to just make sure that your obstacle assets have a 1 cell border around them that's passable for that annoying diagonal passthru. This is what the old Command and Conquer games did .. even a things like starcraft and TA do it.
Granted you've got more processing time to work with than they did so It'll be interesting to see how it works out. :-D.
Nice bit of work and enjoyed the post, will be following this game.


  • 0

Erik Johansson [ aka feneur ]

Wildfire Games
Contact me: feneur@wildfiregames.com



Support Wildfire Games!


#189 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,908 posts

Posted 31 March 2012 - 04:14 PM

Days 16 and 17

Trying to do something other than pathfinding for a bit, since I'm not very good at concentrating on that (continued getting distracted by doing the release and reviewing and life and other stuff).

The game's current renderer is hard-coded to support three different materials:

* Plain old diffuse maps - a mesh has a single RGB texture, which is just multiplied by lighting and shadows etc and then drawn.
* Diffuse maps plus player-colouring - a mesh has an RGBA texture, where the A channel determines where to use the RGB channels and where to use the player colour (blue, red, etc) instead. (Most units use this.)
* Diffuse maps plus alpha-blending - a mesh has an RGBA texture, where the A channel determines where the mesh should be drawn as opaque or transparent or semi-transparent. (We use this a lot for trees and other vegetation.)

Also, each model is rendered in several different modes:

* The basic mode that draws a visible model onto the screen.
* Shadow-map generation: the scene is rendered from the direction of the sun, computing only the depth (i.e. distance from sun) of each pixel, not the colour, to support shadowing calculations.
* Silhouette blocking: to support silhouettes, i.e. units being rendered as solid colour when behind a building/tree/etc, the buildings/trees/etc are drawn to a 1-bit stencil buffer (no colour, it just wants to know which pixels were covered).
* Silhouette display: after rendering the blockers, it then renders the units that will display a silhouette, as a solid colour, using the depth and stencil buffers so it's only drawn when behind a blocker.

Different materials behave differently in each mode. E.g. in shadow-map generation we ignore colour, so non-alpha-blended models don't have to load their texture at all, which can improve performance; but alpha-blended models do have to load their texture so that the transparent areas don't cast a shadow.

The renderer therefore has a "shader effect" per mode per material, where a shader effect defines a "shader technique" that defines how to render a mesh (i.e. what vertex data it needs, what textures it needs, what computation to perform to produce the colour of each pixel, what OpenGL state to set up (blending, depth test, masks), etc). The renderer stores a separate list of models for each material, and in each mode it renders each of those lists with the appropriate technique.

Alpha-blending is special because you have to draw polygons in order from furthest to nearest, to get the correct rendering: Graphics cards store a depth buffer so that you can draw opaque objects in any order, and if you try to draw a pixel that's behind another previously-drawn nearer pixel then it will be rejected (so you'll end up with only the nearest object being visible). If the pixel in front is meant to be semi-transparent, you actually do want to draw behind it, but the hardware doesn't store enough data per pixel to be able to detect that case. In practice, you have to sort transparent objects by distance from camera and draw each one twice to get it working well enough, which is not fast.

As an extra complication, there's an "instancing" optimisation for non-animated models. Animated models store a separate copy of their mesh data for every unit (since we compute the vertex positions on the CPU, and each unit will be in a slightly different animation state, so they can't share), but for non-animated models we only need to store a single copy of the mesh data and can easily tell the GPU to translate/rotate it as necessary for each instance, which saves memory and helps performance.

As yet another complication, we want to maintain support for old graphics cards that don't support shaders at all (or that have unusably buggy or slow support), since there's a non-trivial number of them. Every shader effect actually defines three techniques: one that doesn't use real shaders (for maximum compatibility), one that uses GLSL shaders (for compatibility with OpenGL ES, currently just for Android), and one that uses GL_ARB_fragment_program shaders (for typical use, since GLSL is less widely and more buggily supported than ARB shaders).



The problem with this rendering system is its inflexibility. Say we wanted to add specular lighting to some models to make them look shiny - that would be a new material, and it would require a significant number of changes to the C++ code and a new shader effect (with non-shader/GLSL/ARB variants). But actually we'd want to combine the specular lighting with all the other materials: diffuse+specular, diffuse+playercolour+specular, diffuse+alphablend+specular. Add in the instancing vs non-instancing versions of each of those, and the number of combinations explodes and becomes unmanageable.

The most useful new material (and what prompted me to work on this) would be one that uses alpha-testing instead of alpha-blending: that is, it has a texture with a 1-bit alpha channel and every rendered pixel is either fully opaque or fully transparent. (The image here gives an example - compare the sharp edges of the tree on the left, vs the softly faded edges of the tree on the right). That means you avoid all the ordering problems of semi-transparent blending, so performance can be much better. If we could use that for most of the game's vegetation, framerates should improve significantly. The compromise is that artists probably have to be more careful to make it look good - light fluffy branches are generally out, but you can still do things like this/this/this/this/this/this etc (if I'm not mistaken) without alpha-blending, and it's what basically every other game seems to do.

As well as materials, we sometimes need to render models in slightly different modes. E.g. if you're constructing a building and dragging the placement preview object around the screen, it looks a lot like the normal rendering of a building, but if you drag it into fog-of-war or shroud-of-darkness then it shouldn't turn grey/black like normal buildings do (it should remain visible and bright red to indicate you can't build there). That would require a change to the shader code used to render that model (to stop it applying the LOS texture), but we currently have no way to implement that other than creating yet another variant of every single material and shader effect.



To improve on that, I've been changing the renderer to work more flexibly, and to be more data-driven rather than code-driven.

Every model is associated with a single material (via its actor XML file). The material refers to a shader effect, and also defines a set of, uh, "definitions". (Need a better name for them...). E.g. the material XML file might say

<material>
  <shader effect="model"/>
  <define name="USE_PLAYERCOLOR" value="1"/>
</material>
The material might include some dynamically-generated definitions too, e.g. "PLACEMENTPREVIEW=1". The C++ rendering code will have its own definitions, e.g. "MODE_SHADOWCAST=1" when it's rendering the shadow map. It will collect all models into about one list, regardless of material. Then, for each model, it combines the mode definitions with the material definitions, and loads the material's shader effect.

The "model.xml" shader effect file might say

<effect>
    <technique>
        <require context="MODE_SHADOWCAST || MODE_SILHOUETTEOCCLUDER"/>
        <require shaders="glsl"/>
        <pass shader="glsl/model_solid"/>
    </technique>
    <technique>
        <require shaders="glsl"/>
        <pass shader="glsl/model_common"/>
    </technique>
</effect>
so it will select the "model_solid" shader if one of the relevant modes was defined, else it'll pick the next suitable technique. Then the shader might say

...
#ifdef USE_PLAYERCOLOR
  color *= mix(playerColor, vec3(1.0, 1.0, 1.0), tex.a);
#endif
...
which is depending on the USE_PLAYERCOLOR defined by the material.

So the renderer loads the appropriate technique for each model based on the material and mode. Then it can group together models that use the same shader (to improve performance by minimising state changes) (then it groups by mesh, then by texture), and render them all.

There's lots of caching so that loading shaders for every model for every mode, every frame, has a very small cost. It's not perfectly fast but it seems no worse (and sometimes better) than the old renderer implementation, and it allows much more flexibility, which is nice.

Still to do: Clean up the code; merge with the non-shader-based code as much as possible; add the new materials (at least alpha-testing); document stuff; then it should probably be alright.
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#190 feneur

feneur

    Cartographer of imaginary worlds

  • 0 A.D. Project Leader
  • 7,627 posts

Posted 31 March 2012 - 04:43 PM

Thanks for the write-up Philip (y) I can't say I fully understand everything, but adding this flexibility is definitely nice for the future :) (Especially with the speed and added modes possible with these changes :) )
  • 0

Erik Johansson [ aka feneur ]

Wildfire Games
Contact me: feneur@wildfiregames.com



Support Wildfire Games!


#191 Sonarpulse

Sonarpulse

    Sesquiplicarius

  • Community Members
  • PipPip
  • 166 posts

Posted 31 March 2012 - 08:38 PM

So there is an XML for every model, and a XML for every material? Is that different from the current setup?

Also, I noticed in that unity link, they mentioned alpha blending, but with alpha testing to minimize the sorting problems. Any viability with that?
  • 0
Posted ImagePosted ImagePosted Image

#192 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,908 posts

Posted 31 March 2012 - 10:25 PM

So there is an XML for every model, and a XML for every material? Is that different from the current setup?

That's the same - each model has an actor XML file (of which we have hundreds) that points at a material XML file (currently there's about four). The difference now is that the material XML file explicitly points at the shader effect XML file, whereas the old renderer had C++ code that picked which shader effect to use for each material.

Also, I noticed in that unity link, they mentioned alpha blending, but with alpha testing to minimize the sorting problems. Any viability with that?

That's what we currently do. The downside is that you have to draw every model twice - the first pass draws with alpha testing, and the second pass with alpha blending. That means twice as many draw calls and twice as many polygons to render, which hurts performance when there's a lot of transparent models.
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#193 Sonarpulse

Sonarpulse

    Sesquiplicarius

  • Community Members
  • PipPip
  • 166 posts

Posted 02 April 2012 - 12:25 AM

Cool setup then. Also, I guess now alpha testing could be subsisted for alpha blending for those using FSAA right now, without modifying any foliage textures.
  • 0
Posted ImagePosted ImagePosted Image

#194 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,908 posts

Posted 05 April 2012 - 10:27 PM

Day 18

I finished and committed those renderer changes (74 files changed, 2315 lines inserted, 3503 lines deleted).

In general, there ought to be no visible changes. The exception is that I fixed the non-shader-based rendering mode so that its lighting matches the shader mode - the difference is that it allows the sunlight to be brighter than pure white (by a maximum factor of 2). I've also been experimenting with specular lighting, so this seems like a good opportunity to show some vaguely pretty pictures of the lighting system. (This is all very technically simple - other games have been doing this for most of a decade, but at least we're advancing a little bit.)

The first component is the basic textures for models and terrain: (click images for larger higher-quality versions)

Posted Image

Then there's the diffuse lighting - surfaces that are facing towards the sun are bright, surfaces that are perpendicular to the sun or facing away are dark:

Posted Image

The scenario designer can control the colour and brightness of the sun, which affects this diffuse lighting.

Surfaces that aren't lit directly by the sun shouldn't be totally black - they'd still be lit by light bouncing off nearby objects. As a (very rough) approximation, we add an ambient lighting component:

Posted Image

The scenario designer can control the colour and brightness again, with separate values for terrain and for models to give them more control over the final appearance.

Finally there's the shadows:

Posted Image

All these components get multiplied and added to produce the final result:

Posted Image

This is what the game currently looks like. If you compare it against the first image, you can see that some parts of the scene are brighter than the unlit textures - that's what happens when the ambient plus diffuse lighting is brighter than pure white. (OpenGL generally clamps colours to the range [0, 1] so you can't exceed white, so what we actually do is compute all the ambient and diffuse lighting at 50% of its desired value and then multiply everything by 2 just before drawing it onto the screen.)

I also added some shader code to do specular lighting, to simulate the sun reflecting off shiny surfaces. For testing I've applied it to every model, which looks like:

Posted Image

and that gets added to all the previous lighting so you end up with:

Posted Image

Unlike diffuse lighting, specular depends on the position of the camera, so it looks better in motion. Also it obviously shouldn't be applied to every model, and should preferably be controlled by a new specular texture for models that want it (so e.g. the metal parts of a soldier's texture could be marked as highly reflective and the cloth parts as non-reflective), but that should be easy to add thanks to the changes I made to the renderer, and then it might allow some nicer artistic effects.

Performance of fancier lighting is a potential concern, since it does extra computation (in this case a vector normalisation and an exponentiation) for every single pixel that's drawn. In practice, with specular lighting applied across an entire 1024x768 screen, the extra cost on an Intel GMA 4500MHD on Linux (which is barely fast enough to run the game decently anyway) looks to be about 2msec/frame, while on Intel HD Graphics 3000 on Windows it's too small to easily measure. So it should probably be optional to help the bottom-end hardware, but is fine for anything slightly more advanced than that.
  • 1
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#195 Mythos_Ruler

Mythos_Ruler

    Megas Philhellene

  • 0 A.D. Project Leader
  • 14,887 posts

Posted 06 April 2012 - 12:19 AM

Great update. Added to Moddb. I can't wait to play with specular maps when that feature is mature. (y) Helmets, shields, armour, skin, roof tiles, and even horse hair will look nice if done right.
  • 0

Michael D. Hafer [aka Mythos_Ruler]

Wildfire Games Project Leader

Contact me: michaeldhafergmailcom

 

Support Wildfire Games!

 

10298.png


#196 Wijitmaker

Wijitmaker

    0 A.D. Old Timer

  • WFG Retired
  • 9,528 posts

Posted 06 April 2012 - 02:57 AM

so e.g. the metal parts of a soldier's texture could be marked as highly reflective and the cloth parts as non-reflective

Cool, shiny trees :victory: , so you would probably have to do that with a separate image correct? In the typical soldier texture, the alpha is already being used for player color.
  • 0

Jason Bishop [ aka Wijitmaker ]

Wildfire Games CFO, retired artist
Contact me: jason@wildfiregames.com


Support Wildfire Games!!!


#197 Mythos_Ruler

Mythos_Ruler

    Megas Philhellene

  • 0 A.D. Project Leader
  • 14,887 posts

Posted 06 April 2012 - 03:27 AM

Yep. Likely a gray scale PNG.
  • 0

Michael D. Hafer [aka Mythos_Ruler]

Wildfire Games Project Leader

Contact me: michaeldhafergmailcom

 

Support Wildfire Games!

 

10298.png


#198 Wijitmaker

Wijitmaker

    0 A.D. Old Timer

  • WFG Retired
  • 9,528 posts

Posted 06 April 2012 - 05:30 PM

Perhaps it could be planned so that the (RGB) channel would be reserved for a normal map and the (A) channel of this special new shader texture would be used as specular.
  • 0

Jason Bishop [ aka Wijitmaker ]

Wildfire Games CFO, retired artist
Contact me: jason@wildfiregames.com


Support Wildfire Games!!!


#199 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,908 posts

Posted 06 April 2012 - 06:50 PM

When we want normal maps, I imagine it might be easier for artists if we keep them in separate files from the specular maps, given the apparent troublesomeness of editing alpha channels, then the game can be made to automatically combine them both into a single DXTC-compressed DDS file on first load for efficient memory usage. (For better DXTC compression of normal+specular it actually seems common to use the RGBA channels to store not XYZS, but something more like 0XSY, so the game will need to do some swizzling when importing the textures anyway.)
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#200 fabio

fabio

    Centurio

  • WFG Programming Team
  • 607 posts

Posted 07 April 2012 - 11:24 AM

Would be possible to add dynamic texture to simulate snow (or other environmental effects)? This is how it looks like Settler 6, note that snow gradually appears over the buildings:

Posted Image
  • 0

Graphics problems with 0 A.D. under Ubuntu and free drivers? Check out the Updated and Optimized Graphics Drivers Archive: includes updated drivers with fixes and improvements for games, including 0 A.D..