End of September Update - 3D Sprites

First off, one of the biggest developments this month is work being underway to allow for 3D sprites. This sounds like a contradiction (well, it basically is), but what this refers to is getting 2D sprites to rotate along all axes three-dimensionally, as can be seen with the attached video. How the hell does this work?

From a conversation with Tovl:

So my idea is to actually have full 3-axis rotations (for units that benefit from it) with a nominal 32 frames per rotation. The naive approach to do this would then require 32  15  32 + 2  32 = 15424 frames (taking into account the polar singularities) which is a ridiculously high number. We can probably cut that in half, because it is unlikely we will need to see the bottom of any units, but that's still an enormous amount. Now, the first step in my approach would be to transform the local pitch,roll,yaw rotations to a coordinate system aligned with the screen, so that the z axis points straight into the screen and the other two axes are parallel to it. Because we don't have our lighting baked into the sprites anymore, we can actually do unit rotations around the z axis by simply rotating a single frame in the engine. This gives us an essentially unlimited amount of virtual frame angles around that axis. This already reduces the number of needed frames by a lot: 32 15 + 2 = 482. (again, this could be cut down in half or even more if we limit the steepness of the slopes).

Now, this approach is already good enough for the smaller fast turning vehicles and for things like ships and infantry (which don't need to tilt) we can just continue using the current approach. For the bigger slow turning vehicles like heavy tanks and planes the 32 frames might not be enough, so this is where we might be able to leverage frame interpolation. To reiterate: this problem is already solved for rotations around the z axis, so we would need an interpolation method that is specifically aimed at rotations away from the camera and that is where a parallax shader could come in.

Also, to add onto this: If the parallax shader (or another method to fill the same role) does give acceptable results, we can take this even further. If we just visualize, for the sake of argument, the unit rotations instead as the camera rotating around the unit on a sort of globe pointing inward: I already mentioned the polar singularity where you only need a single frame because the camera roll and the 'longitude' angle become one (and camera roll just means a rotated frame). In principle, the higher your 'latitude' angle is (closer to the pole) the smaller the number of longitude angles you'd need in terms of information content (because the longitude lines get closer together, the closer you are to the pole). If we can use parallax interpolation successfully to reconstruct intermediate frames, then we might be able to remove longitude frames at higher latitudes so that the spherical distance between each frame is roughly equal in each dimension. That would drastically reduce the number of frames needed even further.

If this went over your head, don't worry, it mostly went over mine as well. But the gist of it is using a limited number of additional rotational frames along various pitch angles, adding in-engine sprite rotation (the results of which are seen in the video with the helicopter above), and then using a special shader to add frame interpolation, creating on-the-fly rotations for the object, allowing for different angles of movement, and smoothing out sprite rotation in general, while also requiring a relatively low number of different sprite rotations per every unit sprite sheet.

We've also been continuing to work replacing old assets with ones updated for the lighting system.

 

We also came up with a new system to combine the dynamic lighting system with baked-in, fake lighting, as can be seen in the above gif. Things such as the floodlights and blinking obstruction lights are just a separate sprite, placed over the normal building sprite, with an IgnoreLighting tag set and with a BlendMode set to Screen (similar to how BlendModes work in Photoshop and other art programs). The result is surprisingly convincing.

That's all for this month. Next month we plan to expand more on the planned Population/Reinforcement system, and to replace all the remaining artwork with updated ones compatible with the new system.

Thank you all for the continued support.