In our game, there is a requirement for building destruction. A sequence is played in a very spacious area. In this sequence, the Boss attacks the protagonist, causing several nearby tile-roofed houses to shatter. There are tiles and a considerable number of debris fragments. As expected, the real-time computational cost is high. Combined with the baseline overhead of running the game, this design was not anticipated to run smoothly from the outset.
Therefore, from the very beginning, we planned to try using Chaos Cache to handle the destruction effects within this sequence.
We created a physics asset for the boss, consisting of roughly appropriate capsules and spheres covering its body, and also prepared the destruction assets. The intention was that during the sequence playback, the boss would naturally collide with and impact the destruction assets via its animation and physics asset, triggering the destruction, and the results would be recorded.
During the first test, we found the houses were being knocked away. So, we added an Anchor Field. Then we encountered three problems:
1. Originally, setting the “General” - “Object Type” property of the destruction assets to “Dynamic” allowed them to be moved. However, after anchoring, there was no collision response to the boss’s attacks in the sequence.
2. To solve problem 1, I changed the type to “Sleeping”. After this change, destruction occurred, but the shattering effect was clearly incorrect. There were numerous cases of mesh interpenetration, and many fragments that should have broken off failed to detach.
3. Under the above conditions, the destruction assets would still undergo short-distance displacement as a whole when impacted.
Considering that the first impact force might be too strong, we thought about making the assets fracture first; subsequent impacts would then be more natural and wouldn’t cause the entire asset to displace. So, we added a Fracture Field, activated at the appropriate moment, to make the destruction assets fracture before the impact.
After this, the recording process concluded very smoothly. However, when using the cache, we encountered a new problem:
4. The cache effect and the actions in the sequence simply would not match up.
No matter how we adjusted the “Start Time,” we couldn’t get it to align with the animation throughout the entire sequence. While troubleshooting this mismatch, we spent considerable time analyzing potential scene influences, checking if the sequence had time dilation… Eventually, we noticed an issue with the “Recorded Duration” time of the Chaos cache. Our sequence runs at 60 frames per second, totaling 2140 frames (approximately 35 seconds). However, our recorded destruction cache was only 21 seconds long. Furthermore, there was a 10-second wait before the sequence even started playing. We then started using screen recording software to capture the desktop, specifically recording the “Recorded Duration” parameter within the cache window. Upon analyzing the recording later, we saw that after waiting 10 seconds in the game, the “Recorded Duration” in the cache was only around 6 seconds. By the time the sequence finished playing, the “Recorded Duration” in the cache was still less than 21 seconds.
We haven’t had time to look at the code yet. But subjectively, we suspect that the game might be experiencing stuttering, causing the interval between frames to be large (exceeding 16ms or 33ms). The minimum frame interval for physics is 0.033 seconds. To ensure the continuity of the simulation effect, even if the game’s frame interval is higher than 33ms, the physics likely must use 33ms as the timestep for calculation. Otherwise, significant visual jumps would occur, leading to many other issues. If this is the case, then if the frame rate during recording is insufficient, it would inevitably cause the data recorded in the cache to not match the sequence’s timeline.
The above describes the problems we encountered.
Attached is a test project prepared to reproduce the situation we encountered, replicating our usage method and the issues we faced. If the colleague handling this issue has a sufficiently powerful computer where the RecordLevel runs without any lag, you can replace the destruction assets in the level with GC_Cube3. The CacheLevel is a level that uses the cached data.