Hi,
With all those FFs you've been doing on rendering sprites and assets in the game over the years, i've been wondering if you've ever considered other methods to render stuff in an isometric style game. I happen to be quite heavily involved in part of modding community for an old game called "Original War" which also happens to be a Czech game, made by Altar Studios in 2001.
What i found out about the game is that to deal with the problem of "correct sprite ordering" (pardon my lack of jargon but i'm always bad with technical terms) Altar had used a method where each sprite had an additional layer in greyscale. That greyscale image was generated based on the 3D model and basically represented the height of the model (so if something was higher in the 3D space, it was brighter in the 2D layer).
That greyscale image was then used by the engine to check whether each pixel of an object should be rendered in front or behind other pixel of other objects (if that makes sense to anybody). I've been trying to make a tutorial for OW modders about model rendering so i happen to have a short clip to better illustrate what i mean. Pardon my shameless plug: https://youtu.be/fv3RsfOLvvg?t=172.
And finally my question to You, the devs, is whether you've encountered this method while designing the game and (if so) did you ultimately decide to stick with more "standard" way of dealing with game sprites by drawing parts of object in different layers depending on how they are supposed to work in game (also, please correct me if i'm wrong because i may not be aware of the full picture). The method i've talked about has been striking me as a much simpler solution to the problem and i would like to know if there are limits and obstacles that would render this method inappropriate for Factorio as an example.
Cheers,
Question to the devs about rendering methods
Re: Question to the devs about rendering methods
Hello,
Yes, I am aware of the technique. I didn't know Original War was using it, but I am aware of Original War (and when I first saw Factorio, I assumed it was going to be similar RTS). I know kovarex and Tomas chose 2D because they wanted the game to be about large scale factories, and thought 2D will be more performant than 3D. And I also know kovarex is not interested in graphics programming. Other than that, I don't know what the thoughts on rendering were.
In short, the game was not designed to work with height maps from the beggining, so when we were thinking about using them later, we realized we are content locked into current method of sorting sprites back to from. All sprite assets were already made with antialiased edges and we were heavily utilizing transparency in one was or another. Also, despite sprite being rendered from 3D models, these models are often not "correct" ... as in, they are made such they look as artists desired when rendered to sprite, but if you rotated it, you'd find that things are disconnected, etc. So it might be hard for us to create height maps that would not expose this.
In addition to that, as opposed to 3D games, where depth is calculated when projecting and rasterizing triangles from 3D space to 2D screen coordinates, therefore the depth can be known before pixel shader is executed, so early depth test can be performed and occluded pixels discarded even without running the pixel shader, which means less work for GPU. We would know depth only as a result of sampling the height map in the pixel shader, so it might end up being less efficient (for the GPU) than just rendering everything back to front
- instead of: sample texture, read background color, blend texture color onto it, write new backround color (2 reads and 1 write)
- it would do: sample texture, sample height map to calculate depth, read depth buffer, if new pixel is further than previous pixel discard new pixel, otherwise write new depth, read background color, blend texture color onto it, write new backround color. (3 reads when depth test fails, or 4 reads and 2 writes when it passes)
Late depth test would also probably disable some internal GPU depth buffer optimizations (like hierarchical depth), so the depth tests would probably be slower than in 3D case using early depth test.
On the other hand, it would allow us to sort and batch sprites by texture ... we could create smaller atlases (or possibly could get away with not creating atlases at all), and draw all sprites using texture 1, then all sprites using texture 2, etc... This would in turn give us more freedom to use more custom shaders on entities. And also, it would have solved lot of issues of sprites being drawn in wrong order we currently have.
So, it could have been done, but disadvantages were:
- need to change art style and recreate almost all art
- most sprites will need counterpart heightmap, significantly increasing startup time and memory usage
- it would very likely be more demanding on GPU
At which point, I'd rather just move to 3D rendering
Yes, I am aware of the technique. I didn't know Original War was using it, but I am aware of Original War (and when I first saw Factorio, I assumed it was going to be similar RTS). I know kovarex and Tomas chose 2D because they wanted the game to be about large scale factories, and thought 2D will be more performant than 3D. And I also know kovarex is not interested in graphics programming. Other than that, I don't know what the thoughts on rendering were.
In short, the game was not designed to work with height maps from the beggining, so when we were thinking about using them later, we realized we are content locked into current method of sorting sprites back to from. All sprite assets were already made with antialiased edges and we were heavily utilizing transparency in one was or another. Also, despite sprite being rendered from 3D models, these models are often not "correct" ... as in, they are made such they look as artists desired when rendered to sprite, but if you rotated it, you'd find that things are disconnected, etc. So it might be hard for us to create height maps that would not expose this.
In addition to that, as opposed to 3D games, where depth is calculated when projecting and rasterizing triangles from 3D space to 2D screen coordinates, therefore the depth can be known before pixel shader is executed, so early depth test can be performed and occluded pixels discarded even without running the pixel shader, which means less work for GPU. We would know depth only as a result of sampling the height map in the pixel shader, so it might end up being less efficient (for the GPU) than just rendering everything back to front
- instead of: sample texture, read background color, blend texture color onto it, write new backround color (2 reads and 1 write)
- it would do: sample texture, sample height map to calculate depth, read depth buffer, if new pixel is further than previous pixel discard new pixel, otherwise write new depth, read background color, blend texture color onto it, write new backround color. (3 reads when depth test fails, or 4 reads and 2 writes when it passes)
Late depth test would also probably disable some internal GPU depth buffer optimizations (like hierarchical depth), so the depth tests would probably be slower than in 3D case using early depth test.
On the other hand, it would allow us to sort and batch sprites by texture ... we could create smaller atlases (or possibly could get away with not creating atlases at all), and draw all sprites using texture 1, then all sprites using texture 2, etc... This would in turn give us more freedom to use more custom shaders on entities. And also, it would have solved lot of issues of sprites being drawn in wrong order we currently have.
So, it could have been done, but disadvantages were:
- need to change art style and recreate almost all art
- most sprites will need counterpart heightmap, significantly increasing startup time and memory usage
- it would very likely be more demanding on GPU
At which point, I'd rather just move to 3D rendering
Re: Question to the devs about rendering methods
Allright, so it was really just a result of some random chance in the end But thanks for the in-depth explanation and your thought process. I understand why it would probably be very unfeasable to introduce any changes to the engine even early on in the development, once the foundations were established.
Cheers,
But thanks for the in-depth explanation and your thought process. I understand why it would probably be very unfeasable to introduce any changes to the engine even early on in the development, once the foundations were established.Cheers,