21 December 2024 - Physics Peeves, Mod Analyzer Woes

Oh boy, it's another complaining post!

Physics Peeves

I have a love-hate (like, 90% love, 10% hate) relationship with Godot Jolt physics. For those who don't know, plain Jolt is a third party physics engine that is universally better than Godot's native 3D physics system, especially with respect to assembly (as in, physical assembly, not code) complexity. Needless to say, Godot physics panics and breaks down a bit too soon when making mechanisms.

Originally, I used Godot physics until I started working on character models, when I found interest in PhysicalBoneSimulator3D. Of course, I quickly ran into the issue of physics going spastic and completely breaking. When I asked for help, I was advised to use the plugin to cross-port Jolt into Godot instead of native physics.

To be frank, I could probably write an entire blog post about Jolt. It's a really awesome physics engine. I think the only physics engine I have as much appreciation for is something like Valve's Rubikon (as it functions in the present day, think Half-Life: Alyx).

Gripes and Nitpicks with Godot Jolt

Godot Jolt is phenomenal, until it isn't. It is missing features I consider vital for the design of my game, some make more sense than others to be missing.

Physics simulation is not multithreaded, even though Godot has an option for this and Jolt supports it natively.
- This seems to be fixed in the official integration that came as part of 4.4-dev7?
Godot Jolt is not deterministic, and I plan to have a multiplayer game.
- This isn't a huge deal, network ownership is still going to be needed anyway.
- This limitation makes sense, I'm like a rich kid complaining that the gold leaf on his coin is too thin.
Certain collision shapes (i.e. WorldBoundaryShape3D) don't work.

Useful parts of Godot Jolt

That's not to say it is useless though. There's some things that are absolutely useful.

Higher performance physics is always a win.
Static compound shape construction (physics bodies with multiple collision shapes).
- Originally, my terrain colliders used baked and cached compound shapes made via V-HACD.
  - This was extremely laggy under Godot physics, even as static colliders.
- Godot prefers mutable compound shapes, and Jolt prefers static compound shapes.
  - You may have heard of things like "baking" in computers, this refers to a common tradeoff. You know how games have a power slider, like speed vs. health? Computers have something a bit like that, where you trade off computational time for data cost.
  - Godot prefers allowing data to be changed quickly, at the cost of slow physics code but fast object creation and destruction.
  - Jolt prefers denying data changes in a timely manner, at the benefit of fast physics code but slow object creation and destruction.

Mod Analyzer

A long while ago, I made a blog post about Roslyn Analyzers and VSIX and how it is nightmarishly and horrifyingly awful to work with both at the same time. Status update: It still fucking. sucks. To be honest, I don't know if I will even release it with the modding SDK at this point. That's how bad it is. I might just give up on it, and I don't give up easy.

Every couple weeks or so I get the idea, "hey, maybe I'll try working on the analyzer again"! Then, I proceed to fiddle around with things for the next couple hours, and finally throw the project back into the abyss in defeat. Last time this happened I made negative progress because now my VSIX does nothing and I have no clue why. What, did you think I was going to debug it? What are you, insane? Everybody knows that for some god-awful reason you can't use breakpoints and the debugger when hosting the experimental VS build.

If anyone on the VS/Roslyn team is reading this perchance, please hear my call for help. The documentation is outdated. VSIX documentation that I get led to is still telling people to use the synchronous model. The documentation for Roslyn is long and complicated, so much so that it's giving me flashbacks to when I was first learning to write code some 15 years ago. It's an uphill battle from two sides and it feels awful to learn.

I feel like to really get VSIX to work the way I want it to with my customizations to the code view, I'd practically have to learn how Visual Studio itself works, because it is by far one of the most confusing and unintuitive systems I have ever dealt with.

As far as Roslyn goes, it's just way too complicated for me. I have a loose grasp that there is something known as a syntax tree, and that it stores the code somehow. But as far as how and when and where and in what context and how it splits it apart, I am clueless.

I need help

Most of my analyzer's functionality comes from Attributes. For example, methods that declare or inherit [MayRunOnAlternateThread] are supposed to add a color coded piece of text to the tooltip when you hover your cursor over the method to view documentation (I actually have a picture of this working in the old blog post, see the top of this section).

Some analyzer functions will observe method calls. For example, if the body of the aforementioned example method is calling something decorated with [MustRunOnMainThread], this should raise a warning. This seems like a fairly easy analysis to make, "if the thing I am calling has this annotation, and the caller has this other annotation, raise a warning".

Like this is not that complicated, this feels easy, and I think that's why I keep coming back to it. It's just that actually implementing it feels like trying to make it through a labyrinth.

Hopefully I can work through this, but as far as I care now, I will be skipping work on the mod analyzer.