Godot Port Update #4

Porting stats
Porting progress: ~35%
Hours with Godot: ~278h
Scripts transferred: 42
3D-assets transferred: 39
Audio files transferred: 121
Godot project size: 10.52GB

What are these Godot Port Updates?

Porting a game to another engine is a big and rather unique thing, so these post are my way of documenting this porting experience and giving some honest updates on how the porting process is going.

These posts are a weekly thing until all the core features have been ported and along with these posts there are also Patreon test builds each week. These test builds are directed to small audience and the main purpose is to get performance data and early feedback on the ported features.

What has been ported this week?

Custom shader caching
Shadow cascade blending
Support for bolt-action rifles
Mosin + reload animations
Staged reloads / manual bullet insert
Bullet Casing drop SFX
LOD Transition improvements
Separate shadow materials
Radio (Interactable)
Radio tracks / music
NVG Filter + noise shaders
Custom post-processing UI
Film grain + Vignette
Settings DOF blur
Frame rate limits
Antialiasing options
Shadow quality options
FSR upscaling + sharpening
Transition Fader
Texture improvements
New building
More props

Fixing the stutters (Shader caching)

This following week has been mostly tech-oriented week, since one of the main tasks was removing the stutters that were related to Godot's initial shader compiling.

The short explanation for this topic is that Godot's renderer dynamically compiles shaders as they appear within camera view frustum. If there are no existing shader caches available, there are quite severe stutters until the caches are created.

This problem occurs with each new build and currently it's up to developer to figure out a solution to combat those initial caching stutters.

Luckily, I had bunch of experience with this topic and I decided to implement one of my most trusted caching solutions that I call "Frustum scanner".

This method is quite an universal trick for most projects and basically what happens behind the shader loading screen is the following:

1. Main camera gets detached from player controller.
2. Dynamic objects (like weapon rigs) are instantiated front of the camera.
3. Dynamic effects (like particles) are instantiated front of the camera.
4. Main camera FOV is set to high value to capture as much environment as possible.
5. Main camera spins 360-degrees and "scans" the environment from different map positions.
6 Main camera returns to player controller + FOV will reset to default
7. Scan is ended, caches are created, loading screen disappears.

I have used this "Frustum scanner" method in multiple projects and it has proven to be most simple trick to force those shader caches and all the stutters occur only behind the loading screen.

The "extra" loading time is dependent on the hardware and map complexity but for Road to Vostok maps and assets, loading times are something like this:

- First scan (no initial caches): 6-10 seconds
- All other scans (initial caches created): 1-4 seconds

Currently all the main stutters that were related to this issue are now removed and gameplay is butter smooth with hardware that I have tested, so my trusted caching solution was proven to be useful once again.

Edit: The stutters were also removed from all Patreon supporters who tested the latest build (compared to previous one), so I can pretty confidently say that the fix indeed worked like expected.

Project structure

This topic is pretty hard to explain but when it comes to learning from your mistakes, I want to quickly highlight few details that are related to project structures.

Since this porting adventure provided me an unique opportunity to rebuild the project from scratch, I decided that I will make multiple asset hierarchy and referencing changes compared to the previous Unity project.

In Godot, I have tried to make "engine-independent" small modular scripts and in general rebuild stuff in a way that is more easy to manage and scale. Most of these topics are related to scene structures, instancing solutions and having a separate game data resource which reduces the need of cross referencing different systems between each other.

I'm really happy with this current project structure and if I had to choose between this one and the previous Unity one, I would not go back even if the Unity situation never even happened. This is not Godot is better than Unity comment, I simply just had an opportunity to rebuild stuff a better way and learn from previous painpoints that I had with my Unity project, so I used the opportunity.

.gLTF = Double edged sword

Currently, I use two different formats for 3D-assets in Godot which are .obj and .gLTF when previously I only used .fbx files in Unity.

The most common .gLTF (.glb) assets are animated weapon rigs and custom made terrains since I need support for vertex colors and armature / skeleton deforming to those asset types through that .gLTF format.

9 / 10 times the .gLTF and importing to Godot works without any issues but every now and then there's always something that throws a curveball and the debugging process starts.

Some of these curveballs are not bugs, they are once again format behaviors but personally I really don't like some of these "automation" behaviors, here's one example.

Few days ago I added .gLTF based weapon rig for bolt-action weapons and it included bunch of animation files. One of those animation files was named Mosin_Reload_Bolt_Cycle which is based on my own naming conventions and many of my helper scripts that I have created for setting up the weapon rigs inside the game engine.

When I started testing the weapon rig, I noticed that some of the animation name parts were missing and there was also weird behavior with animation looping. Well, after some debugging and researching the finger was pointing once again towards .gLTF format.

All the issues were basically related to .gLTF animation suffixes since the words like _Cycle and _Loop are considered to be "automation" key phrases, so they get removed from the animation list and they force animation to be in different looping modes within the game-engine.

I don't like this type of behavior since it basically forces me to avoid certain words and you have to change your (and your contractors) naming conventions and helper scripts since the .gLTF is doing its own procedures with those specific words.

This topic falls under the "nice to know" category and when you are porting a game to another engine (with another file formats) that category is definitely filling up quite rapidly :)

50% Port status is getting closer

This week I will start preparing the "scary" porting topics like AI and Inventory. Once I have those two ported, I can pretty confidently say that 50% of the Road to Vostok features have been ported to Godot.

Visually there's still bunch of 3D-assets missing but I left those "easy tasks" for later on since porting them doesn't require any "brain power" because they are just simple drag and drop porting tasks.

My goal is to release the Road to Vostok (Godot demo) at the end of this year and if I reach that 50% port status within next few weeks, timeline wise this porting process is going just like I expected.

- Antti (Developer)