My Thoughts

[Dalayeth]

Just saw your video about the physics, great stuff! As soon as I saw the video title I thought of that Teardown talk so I was so glad when you not only mentioned it but based your implementation on it. I had a chance to play around with the demo and just wanted to put my thoughts down for you. Please don't take any of them as criticism as I think you are doing amazing work.

When I saw you video it seemed that voxels became un-editable when part of a rigid body and when I tried the demo I confirmed that. This is something that I see in a lot of voxel games/implementations and it's an understandable compromise. But personally I would love to have editable moving voxels. I don't know how Teardown does theirs and it's probably way more complicated than what I have in mind. But the ability to continue to break down larger objects like trees is very satisfying. Also this could enable support for boats and airships in the future. These are obviously long term goals but I know that they become more difficult to add alter if they aren't taken into consideration early on. There are some Minecraft mods that attempt to add these but they have to be complex and often introduce bugs. They also become a nightmare to maintain. I think Vintage Story just moved to a system where dynamic voxel grids are possible. They call it mini dimensions. Vintage Story also has a good portion of their source code under a code-readable license. I'm only able to find the API for their mini dimension and not the underlying code but the game is written in C# so you could read it using dnspy. Having disconnected voxels become separate interactable voxel grids instead of just rigid bodies would be huge improvement in my opinion.

When I tried your demo I was glad to see the behavior of targeting voxels was switched from fixed distance to what is probably a raycast and that was awesome. It feels way better to use now. The first thing I did though was to try and a large rigid body by removing all voxels that connect to a large roof and saw that it failed to make a rigid body. I wasn't surprised this is a common limitation. I know that the algorithms to detect disconnected voxels can be unwieldy at larger sizes. I expected either that the game would freeze until calculation was complete or not work at all. Again as a long term goal it would be great to have larger rigid bodies. I think I saw a Youtube comment about internal forces in rigid bodies which would be great with larger objects as well. But again long term goals.

After stress testing the physics engine I noticed it would slow down but was completely disconnected from frame rate and I just have to say that was amazing. Well done. I absolutely did not expect for my frame timing to stay the same and objects just start to slow down. Some objects would slow down and then speed up which makes me think that instead of fixed rate physics happening say 60 times a second you are using the delta time to handle changing intervals in the physics steps which I think is the right choice.

My first test bogged the physics down pretty bad and it never seemed to get better. At first I thought that objects weren't being put to sleep. But after placing a large number of objects on flat ground thought that maybe they were. Not sure whether you have a sleep system in your physics engine to remove computation of rigid bodies that have come to a complete rest and no longer need to be simulated but if not it will be an important part of your physics system.

I don't know if it's the iterative solver you are using but I noticed that a pile of objects never seemed to come to rest under any circumstances and it just got more unstable over time. I don't know if this is caused because the iterative solver has to keep iterating until it finds a stable position and doesn't or if gravity is being applied even to sleeping objects which causes them to wake and intersect with objects beneath them.

The book you mentioned while great is fairly old. I would consider looking at some newer physics implementations to see what kind of improvements have been made in the field in the last ~14 years. I don't know for sure though. Jolt Physics would probably be a great resource for you. Perhaps there are some solver optimizations for voxels that you could take advantage of.

Again these are just my opinions about what I would like to see long term. The engine is amazing so far. You've made incredible progress and gotten farther than a lot of commercial projects in making everyone's dream voxel engine. I hope you keep up the amazing work. I'm rooting for you!

[DouglasDwyer]

Hey, thanks for all of the feedback! I appreciate it, and agree with most of what you've found. Supporting more of these features is a matter of time and dedication, but I need to work on other parts of the engine before improving physics more.

When I saw you video it seemed that voxels became un-editable when part of a rigid body and when I tried the demo I confirmed that.

I haven't bothered to support editing individual rigid bodies because I don't know if that will be a useful gameplay mechanic. I don't think that it will be hard to add, though - I will do it in the future if it makes sense for whatever game(s) are made with the engine.

Again as a long term goal it would be great to have larger rigid bodies.

I agree. Right now, for performance reasons, rigid bodies are limited to being 256^3 voxels in size. I don't plan to change this in the near future since it would be technically challenging. It would also put more stress on the collision detector. But maybe someday!

At first I thought that objects weren't being put to sleep. But after placing a large number of objects on flat ground thought that maybe they were.

There are a few cases where the engine lags for me (namely, putting a whole bunch of small rigid bodies close together). But objects should go to sleep, and in my testing having many independent objects (say 100 or 200) all resting separately on flat ground should not be an issue. Did you experience lag in this case?

I don't know if it's the iterative solver you are using but I noticed that a pile of objects never seemed to come to rest under any circumstances and it just got more unstable over time

Yep, this is just caused by the iterative solver! Moving to a simultaneous constraint solver is the first solution that I want to try for this.

[DouglasDwyer]

Just as a follow-up, if you could give a more complete description of any stress tests that led to lag, it would help me greatly. Fixing performance issues is a priority to me.

[Dalayeth]

I experienced no noticeable lag when placing a large number of rigid body shapes on flat ground. The two times I experienced a significant slowdown in physics was when I tried to make the entire roof a rigid body and it failed so I cut it into four smaller pieces. The pieces fell and couldn't find a stable position so they just kept jiggling and any new falling blocks would fall in slow motion. Not easily reproducible. But a test that you could reproduce was placing ~20 rigid body objects in a confined space. For example I use the area here:

Lightly stacking objects from a few meters up to make sure that none of them overlap and I get a clean test. With only 20 objects there is very noticeable slow down in physics. As I mentioned I think this is mostly due to the iterative solver. Some of the objects even slowly phase through the ground. Like so:

You could probably get a bit more life out of the iterative solver if you used an algorithm to reduce contact points from all contacts to minimum contact points required for a stable collision. I know some physics engines have ways to reduce a shape resting on flat ground all the way down to one contact point. Even though the collision detection has many contact point not all are needed to accurately resolve collision. For example using what I understand of Teardown's system a box could generation a contact point for every edge voxel touching a flat surface. But for such a simple case even a single contact point would be sufficient. I don't know if you are doing any of these optimizations but I think most iterative solvers used in production do something like this.

Another optimization is that some physics engines will apply dampening forces to objects near rest state in a way that, while not physically accurate, will force objects that are moving only small amounts to come to a complete stop and enter a sleep state.

[Dalayeth]

I don't know if you'll see this but I didn't want to open a whole new issue for something so small. I was watching a video today about the creation of Nanite and the developer was talking about some of the other technologies he considered and researched amongst which was voxels and though that it was right up your alley. The video and timestamp is here the voxel portion is only about 15-20 minutes but take a look I think you'll find it interesting.