0 A.D.: Graphics Development
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Belov, Vladislav
0 A.D. is a free and open-source game of ancient warfare. It is a real-time strategy game which can compete with the classics of the industry, but comes with absolutely no cost for the players. Come and discover your new favorite game! I'll present a short story about graphics of 0 A. D. Why it requires math and algorithms, why water is the most expensive thing and why the Sun is watching you.
 Hello, my name is Vladislav Bilov, I'm a graphics engineer and in my free time I'm working as a volunteer on ZeroAD, free open source strategy game. If you like real-time strategy games, games like Edge of Empires, Warcraft or Starcraft, then you might find ZeroAD interesting as well. ZeroAD is an open source game, it's also a cross-platform and it's available on Linux, Mac OS and Windows. The game supports single and multiplayer modes, so you can play with your friends via internet or local connection and you don't have to use the same platform to play with them. Basically when you start a game you have a base, civilization center that you need to build up, develop and upgrade. You need to explore a map, increase population, maximum number of units, build your army and then you can crash your opponents. In the single player mode you can play with AII, it's flexible so it doesn't let you get bored. In the multiplayer mode you can play not only with friends but you also can enter a lobby and find people to play with or just join to any open game that you'll see in the lobby. ZeroAD is a history-based real-time strategy game about ancient times. Many in-game buildings, units, maps and names are based on real-time historical documents. ZeroAD as a year doesn't exist in Julian and Gregorian calendar so one idea goes straight after one BC. By the way the only zero is used as successful exit status on most platforms. Players might explore many real ancient civilizations, each of them has unique buildings, units, technologies and bonuses. The game has built-in civilizations of every view so players can enjoy some real history. Civilizations have not only a different gameplay but also a different and really interesting visual style what I also enjoy as a graphics engineer. The modability of ZeroAD is really high. There are modes that add new civilizations, different time frames, gameplay features and even fictional worlds like a world of legend of Zelda, the fictional one you might see on the screenshot. The mod structure is plain and transparent and doesn't require any special knowledge to make a mod. Also which mod works on any platform the game works on. ZeroAD has a lot of visual content that's used to make maps more interesting and different. On the one hand it might be a difficult challenge to optimize such art for graphics development, on the other hand it's useful and fun to have such art. All screenshots that you have seen before are real screenshots from the game without any offline rendering or post-processing. Graphics is the important part of games, not necessarily the most important but it definitely has a valuable impact. Also some outdoor advertising marketers claim that a human eye receives about 90% of the information. Better graphics does immerse players in games much more, though it doesn't mean that a more realistic graphics always makes a game better. Even small details can make a good atmosphere. Let's take a look at the screenshot without some applied details. Without lighting the wall scene seems flat, though you still might distinguish between buildings, units and landscapes. The only sunlight in adds a lot of volume, now it's easy to distinguish most of vertical objects but landscapes seem not related to the game objects. And after adding shadows the scene looks like a single wall. If add some post-processing the scene becomes to be poisoned or just an alien planet. The water also might have meaningful details. Adding reflections, adding reflections and making the open water participate in the open source conference. Every period step is a part of graphics development. What do we need to create such a nice picture? First of all we have a beautiful content made by our artists. It includes 3D modules, textures, material settings and so on. On the other hand we have end user platforms with own hardware and drivers and the task of graphics development is to deliver the content to players, saving its visual style using the whole power of the user hardware. What is it that 3D model in terms of games? It's a set of data that anyone can understand, process and send to GPU to draw. Basically most of game models consist of vertices and primitives that connect them. The basic primitive is a triangle. Triangle consists of three vertices. Also there is such thing as indices. They help to save memory by sharing vertices and multiple primitives. Game engines use vertices, indices and primitives as a base because GPU understand that and it doesn't require any complex processing to draw such models via GPU. How to render a 3D model? This is the fixed function pipeline. We can only set special GPU states, that means mostly no flexibility and GPU does process all data received from CPU itself. As OpenGL 2 we have shaders, so we can control most of each step on GPU. We can transform vertices via vertex shaders. We can control each drone pixel of a primitive by fragment shader. All these shaders can be written by a programmer and change dynamically multiple times per each frame of a game. More mathematical speaking graphics development tries to solve a rendering equation. This equation describes everything happens in graphics. Despite its simplicity it doesn't have any analytical solution yet. Graphics development in games over offline rendering in the industry are making approximated solutions. We use different approximations for different materials. The following equation is a simple approximation. It describes a straight diffused lighting that was common in first 3D games. It describes how much light goes from a position in space toward a camera pixel. We assume that we have the only one light source in the sun. The ambient light is the feeling light. It's a simplification of the modern global illumination. The simplest rendering equation if you're trying to look into a black hole in its electric center. On the processing step we collect all objects on the map that visible from the game camera. That's called cooling and you can see the camera bounce on the screenshot. We also prepare object data like texture or models. All shaders required for the object materials. The main task of vertex shaders is to convert world or map space coordinates into GPU friendly coordinates. But it also allows us to modify per vertex data. That's how vertices look like for the terrain. Let's make a very simple asteroid crater and it can be done just by applying some sinus to the vertex position and it looks like this. In the vertex shader of the terrain we have only modified the vertex position and vertex color. What we can do with fragment shaders? We can make a winter just by applying a dot product and it looks like this. More code details I can show you after the talk. For shadows it's not enough to use some formula. We need to know a collider that block the sunlight and we render them in a special texture. That's called a shadow map. For each own pixel it contains distance to the collider in that pixel. In light space on the screenshot dark color means that a position is closer to the sun. We don't need to draw colliders in case its shadow is invisible from the main camera and bounce in which shadow map is drawn always follow the camera so we can say that the sun in most games is square and always following you as a player. Why such a water is expensive? Because of physics. Light after colliding with water splits into reflection and refraction light and we can just make the water transparent because the refraction light is a different angle and we can just reflect the light until we have a modern feature called retracing. So we have to use two additional textures refraction map and refraction map. They are generated by rendering the scene another two times similar to shadow map but with colors. So what we have done for rendering a frame. We have a list of text on a map. We called invisible objects for each pass. We rendered the game scene three times into helper textures shadow map refraction map and refraction map. We combine them in the main rendering of the game scene. After that we have applied some post processing like adjusting brightness or contrast. And that's the basic algorithm of rendering of a game frame. To draw things we are not interacting with GPU directly. The OpenGL driver does that work for us. We are using its API. Our custom engine of the game is written in C++ and it calls OpenGL functions to set a state and draw primitives. We were supporting old OpenGL versions 1.4 and 1.5 with a fixed function pipeline for long time. We have players with really old hardware and the good news is that we have dropped its support a few months ago. To understand how old is the OpenGL and particularly the fixed function pipeline let's take a look at OpenGL history from new years to oldest. OpenGL 4 was released in 2010. More than 10 years ago the last version is 4.6 was released in 2017. Pretty modern for OpenGL. This performance of GL4 might be comparable to the next generation APIs like DX12, Vulkan or Metal. OpenGL 3 was released in 2008. Seems even older. The most interesting version for us is 3.3. It was released in 2010. We hope to set OpenGL 3.3 as a target API version in future releases because more than 70% of our players already supported. OpenGL 2 was released in 2004. Sounds like a couple of centuries ago. The most common second version is 2.1. It was released in 2006. Somewhere here Dinosaur were killed by an asteroid and finally we have reached the OpenGL 1. Originally it was released in 1992 but the first supported version 1.4 was released in 2002. The number of players with old hardware is continuously decreasing fortunately. So we are hoping to drop all versions below OpenGL 3.3. That will allow us to use the most of modern API functions and significantly improve rendering quality and performance on modern hardware. We are also looking at the next generation of graphics API and Vulkan seems like a highly possible future for us. The last version of Vulkan was released in 2020. It's pretty new for some part of our players so we are going to research its support first. But Vulkan is definitely required for high performance games on modern hardware. I also find the game very interesting. As a programmer or as an artist I can do various experiments. I can test a lot of things without building a game or a demo from scratch. For example I can easily do experiments with edge detection on an image using subway operator. These matrices are for detecting horizontal and vertical edges. Using them both allows to have a chance to detect most of the game object edges. This picture is generated by applying previous matrices to the colors of the game scene. You might see that detected edges are not necessarily real object edges. Also the image has a visible noise but we can solve it. This one is generated by applying the same matrices to the depth of the game scene. Now it has mostly no noise and edges are pretty bright. So that's the fascinating and diverse world of graphics programming. Thank you for watching. Please subscribe and download the game. Hi all this love, thanks for your presentation. And let's get some questions. So I can see on the list that Coray Stefan asked. I have an unusual graphic question from Mr Beloff as long time fan for 0AD. The more graphic card fidelity is added to the game the better it looks. But that comes with a notice if not disabled performance cost of course. What are you doing to focus on the stability of the games and can run smoothly on a system with lower end GPU or older GPU? We are trying to support as many as we can. Kind of hardware. We are trying to target new features of new hardware and still support old hardware but it's really hard task to support old hardware and modern at the same time. So and we can't support everything for forever. So we have to drop some really old hardware one time. A few months ago we dropped fixed pipeline. It was this open-dale one. Also there is a really important thing that game development is different a bit different from usual open source development because you are also collaborating with artists and it means a lot of 3D content of textures and you have to teach them to how to create a content that can work on modern GPU and on lower end GPU and CPU. You have actually to make it run perfectly you need to optimize models textures for different kinds of hardware and it's a lot of work. We are looking in few directions where we can help our artists like a level of details and some kind of such optimizations. But anyway, besides engineer, programmers work we need also artists work to make it perform on lower end. So we are doing our best with what we have now. Okay, just one question when you said you dropped support for all the hardware with the, how old is it? Actually I said that in talk that actually open-dale one was supported on the open-dale one on 1.4 and 1.5. They were released in 2002. So it's really old in terms of software and we still have players that support only 1.4 and 1.5. So we can support them because it's a lot of cost and we can just introduce new features because they are blocked by old hardware. There is another question related about your opinion on BGDFX or other projects that could abstract a rendering API like Vulkan, OpenGL and so on. Do you build your own Jaina on top of it? We have our own custom engine, it's written in C++. It can work with OpenGL and OpenGL is for some type of builds. It's not a real sort of just has an ability to build with OpenGL ES. So yeah, we have a custom engine. We are thinking about using some abstract library. But the problem that we have a lot of content and some things might should be really optimized for API. Ideally, we can use some kind of abstract library for modern APIs, Vulkan, DirectX 12 and Metal. It might be useful because it's powerful enough to handle our content. Okay, maybe we have time for the next question, but before it's finished, let me tell you that you can ask more questions in the chat room once it's open. So the last question maybe is what are the skills for new contributors that something can be available for the project? Probably you don't need to have any strong abilities, skills to make some useful stuff for the game because we have different tasks, different level of tasks. Some kind of task might do mostly everyone who just entered the programming or maybe some part because these tasks don't require any special knowledge. We can help with them. Okay, I can see one last question. If one minute is about GPU acceleration and powerization, can you comment this? Yeah, for getting away from these
 Hello, my name is Vladislav Bilov, I'm a graphics engineer and in my free time I'm working as  a volunteer on ZeroAD, free open source strategy game.  If you like real-time strategy games, games like Edge of Empires, Warcraft or Starcraft,  then you might find ZeroAD interesting as well.  ZeroAD is an open source game, it's also a cross-platform and it's available on Linux,  Mac OS and Windows.  The game supports single and multiplayer modes, so you can play with your friends via internet  or local connection and you don't have to use the same platform to play with them.  Basically when you start a game you have a base, civilization center that you need to  build up, develop and upgrade.  You need to explore a map, increase population, maximum number of units, build your army and  then you can crash your opponents.  In the single player mode you can play with AII, it's flexible so it doesn't let you get  bored.  In the multiplayer mode you can play not only with friends but you also can enter a lobby  and find people to play with or just join to any open game that you'll see in the lobby.  ZeroAD is a history-based real-time strategy game about ancient times.  Many in-game buildings, units, maps and names are based on real-time historical documents.  ZeroAD as a year doesn't exist in Julian and Gregorian calendar so one idea goes straight  after one BC.  By the way the only zero is used as successful exit status on most platforms.  Players might explore many real ancient civilizations, each of them has unique buildings, units,  technologies and bonuses.  The game has built-in civilizations of every view so players can enjoy some real history.  Civilizations have not only a different gameplay but also a different and really interesting  visual style what I also enjoy as a graphics engineer.  The modability of ZeroAD is really high.  There are modes that add new civilizations, different time frames, gameplay features and  even fictional worlds like a world of legend of Zelda, the fictional one you might see  on the screenshot.  The mod structure is plain and transparent and doesn't require any special knowledge  to make a mod.  Also which mod works on any platform the game works on.  ZeroAD has a lot of visual content that's used to make maps more interesting and different.  On the one hand it might be a difficult challenge to optimize such art for graphics development,  on the other hand it's useful and fun to have such art.  All screenshots that you have seen before are real screenshots from the game without  any offline rendering or post-processing.  Graphics is the important part of games, not necessarily the most important but it definitely  has a valuable impact.  Also some outdoor advertising marketers claim that a human eye receives about 90% of the  information.  Better graphics does immerse players in games much more, though it doesn't mean that a  more realistic graphics always makes a game better.  Even small details can make a good atmosphere.  Let's take a look at the screenshot without some applied details.  Without lighting the wall scene seems flat, though you still might distinguish between  buildings, units and landscapes.  The only sunlight in adds a lot of volume, now it's easy to distinguish most of vertical  objects but landscapes seem not related to the game objects.  And after adding shadows the scene looks like a single wall.  If add some post-processing the scene becomes to be poisoned or just an alien planet.  The water also might have meaningful details.  Adding reflections, adding reflections and making the open water participate in the open  source conference.  Every period step is a part of graphics development.  What do we need to create such a nice picture?  First of all we have a beautiful content made by our artists.  It includes 3D modules, textures, material settings and so on.  On the other hand we have end user platforms with own hardware and drivers and the task  of graphics development is to deliver the content to players, saving its visual style  using the whole power of the user hardware.  What is it that 3D model in terms of games?  It's a set of data that anyone can understand, process and send to GPU to draw.  Basically most of game models consist of vertices and primitives that connect them.  The basic primitive is a triangle.  Triangle consists of three vertices.  Also there is such thing as indices.  They help to save memory by sharing vertices and multiple primitives.  Game engines use vertices, indices and primitives as a base because GPU understand that and  it doesn't require any complex processing to draw such models via GPU.  How to render a 3D model?  This is the fixed function pipeline.  We can only set special GPU states, that means mostly no flexibility and GPU does process  all data received from CPU itself.  As OpenGL 2 we have shaders, so we can control most of each step on GPU.  We can transform vertices via vertex shaders.  We can control each drone pixel of a primitive by fragment shader.  All these shaders can be written by a programmer and change dynamically multiple times per  each frame of a game.  More mathematical speaking graphics development tries to solve a rendering equation.  This equation describes everything happens in graphics.  Despite its simplicity it doesn't have any analytical solution yet.  Graphics development in games over offline rendering in the industry are making approximated  solutions.  We use different approximations for different materials.  The following equation is a simple approximation.  It describes a straight diffused lighting that was common in first 3D games.  It describes how much light goes from a position in space toward a camera pixel.  We assume that we have the only one light source in the sun.  The ambient light is the feeling light.  It's a simplification of the modern global illumination.  The simplest rendering equation if you're trying to look into a black hole in its electric  center.  On the processing step we collect all objects on the map that visible from the game camera.  That's called cooling and you can see the camera bounce on the screenshot.  We also prepare object data like texture or models.  All shaders required for the object materials.  The main task of vertex shaders is to convert world or map space coordinates into GPU friendly  coordinates.  But it also allows us to modify per vertex data.  That's how vertices look like for the terrain.  Let's make a very simple asteroid crater and it can be done just by applying some sinus  to the vertex position and it looks like this.  In the vertex shader of the terrain we have only modified the vertex position and vertex  color.  What we can do with fragment shaders?  We can make a winter just by applying a dot product and it looks like this.  More code details I can show you after the talk.  For shadows it's not enough to use some formula.  We need to know a collider that block the sunlight and we render them in a special texture.  That's called a shadow map.  For each own pixel it contains distance to the collider in that pixel.  In light space on the screenshot dark color means that a position is closer to the sun.  We don't need to draw colliders in case its shadow is invisible from the main camera and  bounce in which shadow map is drawn always follow the camera so we can say that the sun  in most games is square and always following you as a player.  Why such a water is expensive?  Because of physics.  Light after colliding with water splits into reflection and refraction light and we can  just make the water transparent because the refraction light is a different angle and we  can just reflect the light until we have a modern feature called retracing.  So we have to use two additional textures refraction map and refraction map.  They are generated by rendering the scene another two times similar to shadow map but  with colors.  So what we have done for rendering a frame.  We have a list of text on a map.  We called invisible objects for each pass.  We rendered the game scene three times into helper textures shadow map refraction map and  refraction map.  We combine them in the main rendering of the game scene.  After that we have applied some post processing like adjusting brightness or contrast.  And that's the basic algorithm of rendering of a game frame.  To draw things we are not interacting with GPU directly.  The OpenGL driver does that work for us.  We are using its API.  Our custom engine of the game is written in C++ and it calls OpenGL functions to set  a state and draw primitives.  We were supporting old OpenGL versions 1.4 and 1.5 with a fixed function pipeline for  long time.  We have players with really old hardware and the good news is that we have dropped its  support a few months ago.  To understand how old is the OpenGL and particularly the fixed function pipeline let's take a  look at OpenGL history from new years to oldest.  OpenGL 4 was released in 2010.  More than 10 years ago the last version is 4.6 was released in 2017.  Pretty modern for OpenGL.  This performance of GL4 might be comparable to the next generation APIs like DX12, Vulkan  or Metal.  OpenGL 3 was released in 2008.  Seems even older.  The most interesting version for us is 3.3.  It was released in 2010.  We hope to set OpenGL 3.3 as a target API version in future releases because more than 70%  of our players already supported.  OpenGL 2 was released in 2004.  Sounds like a couple of centuries ago.  The most common second version is 2.1.  It was released in 2006.  Somewhere here Dinosaur were killed by an asteroid and finally we have reached the OpenGL 1.  Originally it was released in 1992 but the first supported version 1.4 was released in  2002.  The number of players with old hardware is continuously decreasing fortunately.  So we are hoping to drop all versions below OpenGL 3.3.  That will allow us to use the most of modern API functions and significantly improve rendering  quality and performance on modern hardware.  We are also looking at the next generation of graphics API and Vulkan seems like a highly  possible future for us.  The last version of Vulkan was released in 2020.  It's pretty new for some part of our players so we are going to research its support first.  But Vulkan is definitely required for high performance games on modern hardware.  I also find the game very interesting.  As a programmer or as an artist I can do various experiments.  I can test a lot of things without building a game or a demo from scratch.  For example I can easily do experiments with edge detection on an image using subway operator.  These matrices are for detecting horizontal and vertical edges.  Using them both allows to have a chance to detect most of the game object edges.  This picture is generated by applying previous matrices to the colors of the game scene.  You might see that detected edges are not necessarily real object edges.  Also the image has a visible noise but we can solve it.  This one is generated by applying the same matrices to the depth of the game scene.  Now it has mostly no noise and edges are pretty bright.  So that's the fascinating and diverse world of graphics programming.  Thank you for watching.  Please subscribe and download the game.  Hi all this love, thanks for your presentation.  And let's get some questions.  So I can see on the list that Coray Stefan asked.  I have an unusual graphic question from Mr Beloff as long time fan for 0AD.  The more graphic card fidelity is added to the game the better it looks.  But that comes with a notice if not disabled performance cost of course.  What are you doing to focus on the stability of the games and can run smoothly on a system  with lower end GPU or older GPU?  We are trying to support as many as we can.  Kind of hardware.  We are trying to target new features of new hardware and still support old hardware but  it's really hard task to support old hardware and modern at the same time.  So and we can't support everything for forever.  So we have to drop some really old hardware one time.  A few months ago we dropped fixed pipeline.  It was this open-dale one.  Also there is a really important thing that game development is different a bit different  from usual open source development because you are also collaborating with artists and  it means a lot of 3D content of textures and you have to teach them to how to create a  content that can work on modern GPU and on lower end GPU and CPU.  You have actually to make it run perfectly you need to optimize models textures for different  kinds of hardware and it's a lot of work.  We are looking in few directions where we can help our artists like a level of details  and some kind of such optimizations.  But anyway, besides engineer, programmers work we need also artists work to make it  perform on lower end.  So we are doing our best with what we have now.  Okay, just one question when you said you dropped support for all the hardware with  the, how old is it?  Actually I said that in talk that actually open-dale one was supported on the open-dale  one on 1.4 and 1.5.  They were released in 2002.  So it's really old in terms of software and we still have players that support only 1.4  and 1.5.  So we can support them because it's a lot of cost and we can just introduce new features  because they are blocked by old hardware.  There is another question related about your opinion on BGDFX or other projects that could  abstract a rendering API like Vulkan, OpenGL and so on.  Do you build your own Jaina on top of it?  We have our own custom engine, it's written in C++.  It can work with OpenGL and OpenGL is for some type of builds.  It's not a real sort of just has an ability to build with OpenGL ES.  So yeah, we have a custom engine.  We are thinking about using some abstract library.  But the problem that we have a lot of content and some things might should be really optimized  for API.  Ideally, we can use some kind of abstract library for modern APIs, Vulkan, DirectX 12 and Metal.  It might be useful because it's powerful enough to handle our content.  Okay, maybe we have time for the next question, but before it's finished, let me tell you  that you can ask more questions in the chat room once it's open.  So the last question maybe is what are the skills for new contributors that something  can be available for the project?  Probably you don't need to have any strong abilities, skills to make some useful stuff  for the game because we have different tasks, different level of tasks.  Some kind of task might do mostly everyone who just entered the programming or maybe  some part because these tasks don't require any special knowledge.  We can help with them.  Okay, I can see one last question.  If one minute is about GPU acceleration and powerization, can you comment this?  Yeah, for getting away from these
0ad_0_167.png 0ad_168_1595.png 0ad_1596_2147.png 0ad_2148_2747.png 0ad_2748_3683.png 0ad_3684_5711.png 0ad_5712_6311.png 0ad_6312_7151.png 0ad_7152_8339.png 0ad_8340_8483.png 0ad_8484_9011.png 0ad_9012_9143.png 0ad_9144_9851.png 0ad_9852_9935.png 0ad_9936_10343.png 0ad_10344_11747.png 0ad_11748_12371.png 0ad_12372_12467.png 0ad_12468_16295.png 0ad_16296_17363.png 0ad_17364_17411.png 0ad_17412_17567.png 0ad_17568_17963.png 0ad_17964_18491.png 0ad_18492_28331.png 0ad_28332_28446.png