Could be really cool if it was possible to render the physics-enabled voxels aligned per-frame to the main voxel terrain grid (think pixel-perfect sprite rotation) so that when the physics object stops moving you can add it back to the destructible voxel terrain grid. This would solve two problems: one where physics-enabled voxel objects could build up causing excessive lag, and two it'd seamlessly convert a voxel physics object into the terrain grid. Phenomenal work! Subscribed!
This is a good suggestion, and I'm working on implementing part of it: I'm not planning on rendering all voxels as axis-aligned. I can't think of a good way to implement it that would be fast enough to run on all objects every frame. I also think that it might be confusing and jarring to players, making it harder to tell where the object actually is (if we are assuming that the underlying physics collider still rotates normally). However, I do need a way to reduce lag! The plan is to re-rasterize any ground debris that has been alive for a certain time period whenever the player isn't looking it at. The ground debris will then fuse back with the voxel grid, like you suggest. The transition wouldn't be too jarring, hopefully, because it will usually happen when the player's back is turned. There are other physics optimizations that I plan to add as well. I need to make the system multithreaded (it is already designed for this, just don't have a threadpool yet) and add object sleeping.
@@netcore10 excellent question. The plan is to try and fuse objects when *no* nearby players are watching! That said, there will be also be a maximum time limit to ground debris, and it will eventually fuse/despawn no matter what. This is to prevent too many objects from accumulating.
This is also what I immediately had in mind. With voxels that support substructures of itself like these, smoothing roundness of corners as an object rotates is very feasible.
it's such a relief to see that even if John Lin remains in silence about his sandbox project, there are other people who dream in voxels, working on their own projects... like you. one day your voxel engine may do whatever his did, and beyond!
You mention boiling things down into their smallest constituents. This is also what is called 'first principles thinking'. Nice video. Can't wait for next update. :-)
While I was watching the quaternion bit, I couldn't help but thing that writing a few tests would have gone a long way towards tracking the quaternion issue down. I remember writing game-engine-adjacent stuff like you are right now, and I remember how hard it was to debug these kinds of issues. Now that I've started writing tests, however, tracking issues down has been much easier, as the tests initially catch them much closer to their root than just running the program ever could.
I remember getting burned on Quaternion rotations once in Unity, what saved me was peeping the source code of the multiplication function and seeing the subtractions (back then I didn't know how quaternions worked)
For the stack of boxes not tipping over (14:36), does your collision check differentiate between dynamic-dynamic collisions and dynamic-static collisions? And do you apply the forces (and later their corresponding torques) to both colliding objects? I'm guessing from the video, but it seems the forces holding up the top box (biased to the left so the resulting torque is negligible), are not being applied to the box directly below (their bias to the left would cause a higher torque on the second box that would accumulate down the stack). This fix brings other issues though, as the transmission of these forces ends up being 1 dynamic object per physics iteration (wobbly physics as the system settles), and depending on your force calculations, can lead to the bottom object "sinking" into others (spring/force) or ex/im-ploding (overlap correction/momentum).
Your description is completely accurate. When an entity is processed, it sees all other objects as completely static and immovable. So forces aren't really transferred beyond one object, in the normal sense. This is what I meant when I said things are not physically accurate - forces and momentum are not conserved. I definitely want to try adding more comprehensive force/momentum transfer in the future. I think that it would help with having pool balls collide and bounce off one another, for instance. But what I've built so far works well, and I also want to spend some time on other parts of the engine :)
It is so cool how you turned the debugging process of fixing the quaternion commutivity error into a compelling story and documented it all. I’ve never seen someone make debugging so interesting and exciting, like it was a mystery that needed to be solved :)
Absolutely! Once I add real character controls, I plan to make voxel breaking and placing feel much more realistic. I want the player to actually *hit* the tree with an axe and have voxels fly off it!
Yes, I've seen Tooley's work. It's very impressive from both a technical and artistic perspective! I think that he uses the PhysX SDK for his physics system.
If you store whether a voxel is exposed to open air, then you should only need to consider those voxels when doing connected component labeling to check whether the object is still connected to the world. After that, you would have to consider all the voxels, but doing a quick litmus test beforehand should speed things up.
You're spot on! I didn't describe how I choose the starting points for DFS in the video, but this is exactly right. I only start graph traversal on solid voxels which have neighbors that used to be solid, but have become air. Only these voxels could possibly have been bridge nodes in the graph :)
i would recommend making the trees as a single object this way it would be easier to make a complex system like the forest and making the leaves react to wind and etc.
new sub here now you just need to add. player body + inventory + resource drops. then more ideas and inspiration will come while playing ... good work👌
Hi there, I'm new here, I noticed you're using a Suzanne head for some physics testing, I guess you're a Blenderer? Awesome channel btw I really appreciate the thorough explanations since I'm not a coder or developer, but I've been getting into it these past few years and voxel is where it's at imo. Other than MC, Teardown was my intro to voxel gaming, I'm sure you have checked it out, it uses much bigger voxels and much more limited overall map sizes.
I've always wondered how that's handled in voxel engines, ty! I was wondering, when a bunch of voxels become its own entity, how do you then store the voxels? Are they in a separate octree?
Just about. There's a maximum size that an object can be. Any bigger than that, and the DFS algorithm gives up to save processing time. So for any object that is connected to the ground, the DFS starts reading voxels from the ground. It discovers a large number of them, because the ground extends downward infinitely, and then gives up.
Thanks! I switched over to standard greedy meshing in Episode 9, and I have not yet switched back. With the LOD system that I've implemented, meshing is just as efficient but simpler to use. I did invest a lot into parallax ray marching, so I definitely want to revisit in the future. But for now, multithreading/sound/modding take priority :)
I wonder, could you allow the leaves to clip through the floor and delete every voxel after the intersection? The weight of the tree would crush the branches and leaves below it. Or give the leaf voxels some kind of health that takes damage on impact. But idk how hard any of that would be, I'm not a programmer. (I skipped through the video cos I knew I'd have no hope of understanding shit)
That's a great question. I was stuck on contact point estimation for a while, and I ended up just using the average of the two colliding voxels' positions as the contact point. This is something that I want to improve, though, because being able to extract contact lines and planes (I can only extract points) will be important if I ever build a constraint-based solver. It's probably worth looking at how Teardown does it.
@@DouglasDwyer Oh it's cool that it seems to work so well even using the midpoint. The thing im working on uses more traditional colliders and your comment has me wondering if a rough voxelization step would be a faster way to generate rough estimates for contact points than the alternatives... The idea might be a little cursed. Oh well.
Excellent question. There are two reasons for this. First and foremost, compile times. Rust caches compiled crates, so if you separate your project into many small crates, it won't have to recompile the entire codebase every time. Secondly, I have multiple compilation targets - including the native client, the web client, and the backend webserver. Since each of these is a separate binary target, it's easiest to put them in different crates.
To fall or not to fall, is the question 😄 Fun by side! Oh, Quaternions can be very hard on your emotions, playing games with your mind. However you mastered it, putting huge amounts of time into it. Very nice!👌🏻 Still I wonder, which hardware/computer you run this on? Even with those clever improvements, the calculations must be immensely, nothing for phones at least, even with ARM-Chips I guess🤔 With voxel objects being that free, meaning right now, your simulation is not a voxel polygon hybrid like Minecraft, will there be future items? What happens to the tree after it has fallen? Will it drop items?🤨 When I see this simulation of yours, it feels like it’s possible to create a game, in which you can have even voxel entities to tear down. Well actually you managed that already! I am imagining the zombies form Minecraft in this game, getting pixeled down, if you know what I mean. The entities itself would have something real underneath the skin, speaking of voxel bones, muscles, and other stuff. If possible it could turn out to be amazing!😉
My target spec is any desktop machine from the last ten years. You're right - there are many calculations - but they run on desktop CPUs in realtime. For example, the scenes shown in this video had the connected component labeling (CCL) algorithm run on a single thread of an Intel i7-7700. CCL takes about 20 milliseconds to identify the tree, and then another 20 milliseconds to copy it into a separate volume. This runs on a single background thread, so there are no frame hiccups. I think that I can make the copying process faster, still - and I can make it multithreaded too. Yeah, I don't plan on targeting phones at this time. That's mainly due to the limited GPU power of mobile devices. I might revisit it at some point, though. Good question. I don't want items to be a "separate" concept than normal voxel objects. I don't like how dropped items in Minecraft are little mini-blocks; it feels unrealistic and disconnected from the rest of the world. In my game, I want you to simply be able to pick up a piece of log that you've chopped down as long as it is within some size limit. I agree - getting to see a zombie's volumetric, voxelized innards would be a neat touch :)
@@dominicstocker5144 indeed, certain high-end mobile phones are probably capable of running the engine. But not all phones are that powerful, which is why it's not my present focus :)
I am using the GPU! It's how I'm rendering such large quantities of voxels. But I don't currently do much general-purpose compute on the GPU, only rendering. This is because I want to target a wide variety of hardware, including integrated GPUs - which aren't powerful enough to run the entirety of the engine on them. I do want to offload terrain generation to the GPU, though.
It's sad that the voxels are not aligned to the grid when they begin moving, rotating, scaling. It ruins the whole point of the voxel engine to begin with. I'm sure if you put a little time and effort you could figure out a method of keeping everything aligned to the world.
Unfortunately, I don't have a Twitter. However, I do have a Discord (@douglasdwyer). I hang around on Gabe Rundlett's Discord server - he's another voxel RUclips with a really innovative project.
![Making voxels MOVE with the separating axis test [Voxel Devlog #11]](http://i.ytimg.com/vi/PW1Xwc3zzNc/mqdefault.jpg)
![Making voxels MOVE with the separating axis test [Voxel Devlog #11]](/img/tr.png)
![OPTIMIZING my physics engine [Voxel Devlog #13]](http://i.ytimg.com/vi/b_d-0EyOuVg/mqdefault.jpg)
![GPU-generated DISTANCE FIELDS [Voxel Devlog #8]](http://i.ytimg.com/vi/REKcTBgkrsE/mqdefault.jpg)
Could be really cool if it was possible to render the physics-enabled voxels aligned per-frame to the main voxel terrain grid (think pixel-perfect sprite rotation) so that when the physics object stops moving you can add it back to the destructible voxel terrain grid. This would solve two problems: one where physics-enabled voxel objects could build up causing excessive lag, and two it'd seamlessly convert a voxel physics object into the terrain grid. Phenomenal work! Subscribed!
This is a good suggestion, and I'm working on implementing part of it:
I'm not planning on rendering all voxels as axis-aligned. I can't think of a good way to implement it that would be fast enough to run on all objects every frame. I also think that it might be confusing and jarring to players, making it harder to tell where the object actually is (if we are assuming that the underlying physics collider still rotates normally).
However, I do need a way to reduce lag! The plan is to re-rasterize any ground debris that has been alive for a certain time period whenever the player isn't looking it at. The ground debris will then fuse back with the voxel grid, like you suggest. The transition wouldn't be too jarring, hopefully, because it will usually happen when the player's back is turned.
There are other physics optimizations that I plan to add as well. I need to make the system multithreaded (it is already designed for this, just don't have a threadpool yet) and add object sleeping.
@@DouglasDwyer wouldn't multiplayer cause the fusing to be jarring, because there's a chance someone is watching?
@@netcore10 excellent question. The plan is to try and fuse objects when *no* nearby players are watching! That said, there will be also be a maximum time limit to ground debris, and it will eventually fuse/despawn no matter what. This is to prevent too many objects from accumulating.
This is also what I immediately had in mind. With voxels that support substructures of itself like these, smoothing roundness of corners as an object rotates is very feasible.
it's such a relief to see that even if John Lin remains in silence about his sandbox project, there are other people who dream in voxels, working on their own projects... like you. one day your voxel engine may do whatever his did, and beyond!
I certainly hope so :)
Crystal Islands.
15:05 This quick clip of the red pole being cut into little pieces impresses me the most about this video.
You are part of the reason i decided to start learning rust thank you.
It's Blazing Fast™ 🚀🦀🚀🦀
You mention boiling things down into their smallest constituents. This is also what is called 'first principles thinking'.
Nice video. Can't wait for next update. :-)
Another DouglasVoxel video 👀
Very nice. Makes a huge difference to how real it feels ❤
Thanks!
While I was watching the quaternion bit, I couldn't help but thing that writing a few tests would have gone a long way towards tracking the quaternion issue down. I remember writing game-engine-adjacent stuff like you are right now, and I remember how hard it was to debug these kinds of issues. Now that I've started writing tests, however, tracking issues down has been much easier, as the tests initially catch them much closer to their root than just running the program ever could.
I remember getting burned on Quaternion rotations once in Unity, what saved me was peeping the source code of the multiplication function and seeing the subtractions (back then I didn't know how quaternions worked)
Very impressive! A custom physics system is definitely quite the project, nice work
Thanks Frozein! As an aside, I've been enjoying following your Terra Toy devlogs - so keep up the good work yourself :)
its rare to find these kinds of devlogs
This is awesome it`s doing like almost all the stuff from the Noita GDC talk but in 3D! Very good job
finally someone with a github link and actual voxel tutorials!
Bro couldn’t wait for Minecraft 2
You are the only youtuber for whom I've turned notifications on. I always look forward to seeing a new video on the engine.
Congrats on getting the physics working! I always enjoy seeing more work being done in voxels.
since this is a voxel game you can make it when the tree falls any leaves that touch the ground moves instead of staying in place
I hope to see more growth of your engine development.
Subscribed and notif on👍
Congrats on the physics breakthrough!
Your project is looking really cool. Keep up the good work!
Your content is amazing, I'm really exited for it, and learning a lot. One day I will do my own voxel engine
Yay! I love it, congrats on solving that issue with quaternions 😆
For the stack of boxes not tipping over (14:36), does your collision check differentiate between dynamic-dynamic collisions and dynamic-static collisions? And do you apply the forces (and later their corresponding torques) to both colliding objects? I'm guessing from the video, but it seems the forces holding up the top box (biased to the left so the resulting torque is negligible), are not being applied to the box directly below (their bias to the left would cause a higher torque on the second box that would accumulate down the stack). This fix brings other issues though, as the transmission of these forces ends up being 1 dynamic object per physics iteration (wobbly physics as the system settles), and depending on your force calculations, can lead to the bottom object "sinking" into others (spring/force) or ex/im-ploding (overlap correction/momentum).
Your description is completely accurate. When an entity is processed, it sees all other objects as completely static and immovable. So forces aren't really transferred beyond one object, in the normal sense. This is what I meant when I said things are not physically accurate - forces and momentum are not conserved.
I definitely want to try adding more comprehensive force/momentum transfer in the future. I think that it would help with having pool balls collide and bounce off one another, for instance. But what I've built so far works well, and I also want to spend some time on other parts of the engine :)
Wow again, this is awesome ! i rly want to play game like this !
I love voxels, and i cant wait when i can build something here :D
It is so cool how you turned the debugging process of fixing the quaternion commutivity error into a compelling story and documented it all. I’ve never seen someone make debugging so interesting and exciting, like it was a mystery that needed to be solved :)
I am a big Douglas fan!
Could you randomly jumble/offset some of the voxels in the trunk as you’re chopping it to make it look like it’s splintering?
Absolutely! Once I add real character controls, I plan to make voxel breaking and placing feel much more realistic. I want the player to actually *hit* the tree with an axe and have voxels fly off it!
awesome! these physics remind me of teardown
@Tooley1998 has done some awesome work on a very similar voxel game. Interesting to see how to go about implementing a system like this. good work
Yes, I've seen Tooley's work. It's very impressive from both a technical and artistic perspective! I think that he uses the PhysX SDK for his physics system.
Incredible work ! Physics is really hard to do
If you store whether a voxel is exposed to open air, then you should only need to consider those voxels when doing connected component labeling to check whether the object is still connected to the world. After that, you would have to consider all the voxels, but doing a quick litmus test beforehand should speed things up.
You're spot on! I didn't describe how I choose the starting points for DFS in the video, but this is exactly right. I only start graph traversal on solid voxels which have neighbors that used to be solid, but have become air. Only these voxels could possibly have been bridge nodes in the graph :)
i would recommend making the trees as a single object this way it would be easier to make a complex system like the forest and making the leaves react to wind and etc.
If you didn’t know breaking down a problem into smaller pieces is called decomposition.
That's a very concise way to put it, yes :)
basically teardown from now on
back to rendering with rays and there you go
very cool! well done, impressive!
Молодец мужик 👍
new sub here
now you just need to add. player body + inventory + resource drops. then more ideas and inspiration will come while playing ... good work👌
Hi there, I'm new here, I noticed you're using a Suzanne head for some physics testing, I guess you're a Blenderer? Awesome channel btw I really appreciate the thorough explanations since I'm not a coder or developer, but I've been getting into it these past few years and voxel is where it's at imo. Other than MC, Teardown was my intro to voxel gaming, I'm sure you have checked it out, it uses much bigger voxels and much more limited overall map sizes.
I've always wondered how that's handled in voxel engines, ty! I was wondering, when a bunch of voxels become its own entity, how do you then store the voxels? Are they in a separate octree?
Yes, that's right. The voxels get copied into their own octree which I can render and process independently :)
This is cool af!!! but they fall a bit to fast, that makes the whole thing really goofy XD, but it is still, really cool
How does it decide which "side" gets disconnected? Does it just choose the smaller one?
Just about. There's a maximum size that an object can be. Any bigger than that, and the DFS algorithm gives up to save processing time. So for any object that is connected to the ground, the DFS starts reading voxels from the ground. It discovers a large number of them, because the ground extends downward infinitely, and then gives up.
now we just need the leaves to crush
This is amazing, great job
Tried out the demo, and is looking sweet! I was curious if you where still using parallax raymarching, or if you switched over to a mesh only system.
Thanks! I switched over to standard greedy meshing in Episode 9, and I have not yet switched back. With the LOD system that I've implemented, meshing is just as efficient but simpler to use. I did invest a lot into parallax ray marching, so I definitely want to revisit in the future. But for now, multithreading/sound/modding take priority :)
I wonder, could you allow the leaves to clip through the floor and delete every voxel after the intersection? The weight of the tree would crush the branches and leaves below it.
Or give the leaf voxels some kind of health that takes damage on impact. But idk how hard any of that would be, I'm not a programmer. (I skipped through the video cos I knew I'd have no hope of understanding shit)
That's a very cool idea, although it's not my present focus for development :)
You’re a wizard!!
do you remember the mod, da vincis vessels?
I tried the online demo and got a bit disappointed because I couldn't cut the already cut down pieces.
Thanks for the feedback! I do plan to add that eventually, it was just too much trouble for the demo.
you'll always have a vertex poking into a face or an edge hitting an edge right?
Doctor: the sex-change operation was a success
Credit card: declines
Doctor: 0:50
Yikes 🤣
Were there any resources you used for contact point estimation that proved helpful? Been stuck on something similar for something i was working on
That's a great question. I was stuck on contact point estimation for a while, and I ended up just using the average of the two colliding voxels' positions as the contact point. This is something that I want to improve, though, because being able to extract contact lines and planes (I can only extract points) will be important if I ever build a constraint-based solver. It's probably worth looking at how Teardown does it.
@@DouglasDwyer Oh it's cool that it seems to work so well even using the midpoint. The thing im working on uses more traditional colliders and your comment has me wondering if a rough voxelization step would be a faster way to generate rough estimates for contact points than the alternatives... The idea might be a little cursed. Oh well.
Keep up the good work
the leaves should break down as they impact with the ground
I'm new to Rust and I have a question. Why are the modules of your engine separated as crates in a workspace and not modules in a crate?
Excellent question. There are two reasons for this. First and foremost, compile times. Rust caches compiled crates, so if you separate your project into many small crates, it won't have to recompile the entire codebase every time. Secondly, I have multiple compilation targets - including the native client, the web client, and the backend webserver. Since each of these is a separate binary target, it's easiest to put them in different crates.
To fall or not to fall, is the question 😄
Fun by side! Oh, Quaternions can be very hard on your emotions, playing games with your mind.
However you mastered it, putting huge amounts of time into it. Very nice!👌🏻
Still I wonder, which hardware/computer you run this on? Even with those clever improvements, the calculations must be immensely, nothing for phones at least, even with ARM-Chips I guess🤔
With voxel objects being that free, meaning right now, your simulation is not a voxel polygon hybrid like Minecraft, will there be future items? What happens to the tree after it has fallen? Will it drop items?🤨
When I see this simulation of yours, it feels like it’s possible to create a game, in which you can have even voxel entities to tear down. Well actually you managed that already! I am imagining the zombies form Minecraft in this game, getting pixeled down, if you know what I mean. The entities itself would have something real underneath the skin, speaking of voxel bones, muscles, and other stuff. If possible it could turn out to be amazing!😉
My target spec is any desktop machine from the last ten years. You're right - there are many calculations - but they run on desktop CPUs in realtime. For example, the scenes shown in this video had the connected component labeling (CCL) algorithm run on a single thread of an Intel i7-7700. CCL takes about 20 milliseconds to identify the tree, and then another 20 milliseconds to copy it into a separate volume. This runs on a single background thread, so there are no frame hiccups. I think that I can make the copying process faster, still - and I can make it multithreaded too.
Yeah, I don't plan on targeting phones at this time. That's mainly due to the limited GPU power of mobile devices. I might revisit it at some point, though.
Good question. I don't want items to be a "separate" concept than normal voxel objects. I don't like how dropped items in Minecraft are little mini-blocks; it feels unrealistic and disconnected from the rest of the world. In my game, I want you to simply be able to pick up a piece of log that you've chopped down as long as it is within some size limit.
I agree - getting to see a zombie's volumetric, voxelized innards would be a neat touch :)
@@DouglasDwyer :)
@@DouglasDwyerwait, doesn’t the Snapdragon 8 Gen 2 GPU have comparable Benchmark scores to a desktop GTX 1050?
@@dominicstocker5144 indeed, certain high-end mobile phones are probably capable of running the engine. But not all phones are that powerful, which is why it's not my present focus :)
Will you make that leaves break then tree fall and only solid part is tree itself?
Per-material physics is absolutely something that I want to try, which would make leaves, wood, grass, ice and the like all behave differently.
I want to make a game based on this voxel engine!
Why are you not using the gpu'??
I am using the GPU! It's how I'm rendering such large quantities of voxels. But I don't currently do much general-purpose compute on the GPU, only rendering. This is because I want to target a wide variety of hardware, including integrated GPUs - which aren't powerful enough to run the entirety of the engine on them. I do want to offload terrain generation to the GPU, though.
Hello, please add water, rivers and waterfalls
O C T R E E S
woah
please add modding support with lua
The plan is to allow users to create plugins that compile to WASM. This will allow users to write mods in whatever language they'd like!
@@DouglasDwyer neat
It's sad that the voxels are not aligned to the grid when they begin moving, rotating, scaling. It ruins the whole point of the voxel engine to begin with. I'm sure if you put a little time and effort you could figure out a method of keeping everything aligned to the world.
Lol good luck with that
2:30 WHY WOULD YOU BURN MY EYES!??!!?! NOT EVEN A WARNING??
are you on twitter?
Unfortunately, I don't have a Twitter. However, I do have a Discord (@douglasdwyer). I hang around on Gabe Rundlett's Discord server - he's another voxel RUclips with a really innovative project.