Phyisics Engine as maintained library (Velthoric)

[MisterNorwood]

Summary

Library for proper ridgidbody physics, that uses jolt at a core
This is very likely more attainable than it sounds.

Goals

Maintain Velthoric as a standard library for cleanroom, keeping up with upstream for bugfixes wherever possible.

Non Goals

Retrofit entire game to be rigid physics based
Rewrite the entire project from scratch

Motivation

Perhaps the biggest pain in the ass (besides rendering and chunkloading/generation) is physics. A lot of mod aspirations end with the fact someone would need to maintain their own physics engine implementation. Minecraft itself has never maintained any good physics systems. On 1.12.2 we had a taste of it with DynamiX, however it has been discontinued, and it uses ancient Jbullet, which leaves a lot to be desired. Velthoric is perhaps the best attempt at a proper support for rigid body physics in minecraft I have seen so far. After this project picked up, coincidentally I have seen a lot more vehicle mods spring up on modern (Only via videos and word of mouth, I rarely play modern)
Shipping a full-blown threaded physics engine API would be amazing for clearnoom's utility. Most of the work and optimalization has already been done by the creator, hence I believe this is a possible goal to archive in the long term. This unlocks vehicle mods that can run very well on the cleanroom platform with minimal frictrion for the developer.

Description

Id like to state the case why this seems to be an attainable goal. I know this sounds like an overexcited kid begging for new toys. Codebase is very agnostic compared to a typical mod. It is already trying to work on every modding API possible, meaning we really only care about the commons module. That is still about 17k lines of code (Blank, comments excluded, 2.7 k complexity according to scc) sure, however a lot of it is purely agnostic. Using clanker powers I was able to go through the project and see how much of it is actually minecraft related, especially to rendering as that's perhaps the biggest difference. Turns out that only about 61% of the project classes import minecraft packages, from this about 71 classes actually use modern APIs specifically, they are primarily related to blaze3D, which is a whatever as Kirino should be used for this anyway. Another good piece of news is that code concentration in the rigid modern classes is about 1%. Unless I am overlooking something major, this seems to be doable by someone with kirino knowledge in a rather short amount of time.
mc_code_detail.log
mc_code.log

I suggest you contact the developer, as he may be keen to abstract out the problematic lines to possibly make this even easier to maintain.

Dependencies

Kirino

References

mc_code_detail.log
mc_code.log

Guidelines

• I have and will continue to adhere to the guidelines

[tttsaurus]

I like this proposal overall, but let me point out one of the concerns

• I'd love hearing using kirino as a dependency but kirino is still wip and I don't have time to provide dedicated rendering support. Let me briefly explain kirino's situation, it's still on the infrastructure stage and having some experimental features building upon the infrastructures, like vanilla terrain rendering. A rendering pipeline implementation that targets on physics objects requires extra amount of work.
  Moreover, Velthoric still uses a traditional renderer pattern

  class BlockRenderer {
    void render();
  }

  while kirino enforces the render command pattern, so I would expect the migration to take a considerable amount of time.

I'm afraid that the goal is hard to attain if no one is going to spend time maintaining and porting such thing. It'd be the best if someone who knows GL and is willing to be part of kirino development creates a kirino branch to integrate the physics mod.

[MisterNorwood]

Of course. I am willing to give it a shot myself at some point, with or without kirino. I will be experimenting with kirino soon enough so I may be able to get some experience. I hope that maintaining will be as simple as I say it could be.

[tttsaurus]

Good to know that. By the way, I'd just recommend reading kirino source code at this point.