Hoimar

Hello, thanks for your interest in this project. I thought about collisions briefly but didn't put too much time into it (yet). I don't know where the performance hit comes...

For general, inaccurate collisions, (think planet vs. planet) a sphere shape would suffice. Well if you create a collision trimesh for every generated chunk, that's a lot of high resolution...

The engine by default does a broad phase and a narrow phase, it should only check against nearby collision shapes anyway. I'll have to look into it soon. By the...

So I'm still working on a more robust multithreaded job system for better maintainability and performance. It's kind of functional now, but I'm still debugging some hard to narrow down...

Oh, you actually continued to work on it? Which route did you take, `PhysicsServer` or physics nodes? I think the latter are not multithreading-friendly at all, I couldn't get it...

Okay. In the old version of `terrain_patch.gd`, there's a flag for threads on/off. Yeah, creating physics nodes doesn't seem to work in a thread as far as my tests went,...

I had a quick look at the code, it's looking good already, but yeah, apparently there are no collision shapes yet and it throws a lot of physics errors (also...

Alright, I built upon your work to create a physics shape (concave polygon shape) and body at runtime using `PhysicsServer`. After working out the quirks, it's running really stable and...

Now that you mention it, I'm not quite sure whether setting the space is actually needed, I didn't test without it yet. Yes, I also got stuck below terrain once...

Okay, I implemented the collision toggles ~~and merged `planet_collisions` back into `master` for better maintainability. But I'll leave the branch still to have a space for experiments.~~ Actually, I reverted...