I had to check if this was written in rust. And from the thumbnail alone I could tell it had to be. No other kind of developer spams "blazingly fast 🚀", "memory safe 🔒", "zero cost abstractions 🅾💰▶" and "fearless concurrency 🚫😱🔀" everywhere they go, and I absolutely love it.

@DouglasDwyer

10 ай бұрын

Rust isn't just a programming language, it's a lifestyle 🦀🦀🦀

@EsseCaraAiNaCapaMesmo

10 ай бұрын

@@DouglasDwyer bro do you think rust gonna take over c++, c#??

@DouglasDwyer

10 ай бұрын

I think Rust will become an increasingly-used option over C++, since both fill the same niche as a systems language. I do not think that it will replace C#, though, because C# is a higher-level language whose primary purpose is implementing business logic. Rust and C# do different things.

@aladvs

10 ай бұрын

@@UC0FVA9DdusgF7y2gwveSsngwhile AGI is promising, there is no way it will be used *soon* for things like games, or any lightweight applications. too performance ineffective and also not deterministic or fine-tunable enough.

@irice7

5 ай бұрын

​@@DouglasDwyerC++ already taken over the industry. But only if developers doesn't scream out overexaggeration, it'll be a quite better language

Douglas, the idea that fallen pieces eventually become a part of the environment is wonderful. As always, it's beautiful progress

@aspidinton

10 ай бұрын

I always thought about it but it can only be used for soils, wood and maybe leaves, however if you apply this logic to something like stone or items (weapons, tools) it'll break them, so it's pretty item specific. But of course it will optimise the game a lot

@aspidinton

10 ай бұрын

i wonder if any voxels disappear / new appear during this attachment to terrain

@null643

10 ай бұрын

It is really cool. 7 days to die has something similar though way simpler. Physics and voxels is neat.

I really like the idea of merging debree onto terrain instead of just discarding them.

You should add a "softness" property to the physics materials. When an object is "soft", it falls off on its own if it's not attached to enough other voxels or it reaches a high enough stress threshold. This could add a cool collapsing behavior and mitigate the floaty feeling of some scenarios (like when you're digging a hole). Plus, it would also make it so that chopping trees (and the like) would feel more natural because you wouldn't have to remove *every single* voxel attachment to make it fall over.

I was thinking last video that it would be cool if the bits would merge-I didn’t expect it to be this cool, though!

watching your videos consistently for a couple of months now, it's crazy to see the progress of this project - keep it up!

about the event-driven vs ECS way of game dev, I would say that you are better off using both at the same time. for example, bevy uses an ECS architecture, but also uses events for things such as asset updates and closing the app. I think you can even create your own events. ever since i used bevy, always saw event-driven architectures as a sub category of an ECS, because you can use events to update systems.

@DouglasDwyer

10 ай бұрын

Thanks for your perspective! My issue with Bevy's event system (at least on paper) is that the double-buffering and requirement of calling Events::update make it difficult to reason about event ordering and whether all events will be consumed within the same frame.

@anonymousacid9160

10 ай бұрын

@@DouglasDwyer i think you can also use the EventWriter/EventReader as a system param which doesn't require calling Events::update. basically, an event writes to an EventWriter/Reader channel which other systems can read from. im still not that bright on the event system in bevy though, and there definitely are some caveats that i am not aware of.

@icesentry

10 ай бұрын

@@DouglasDwyer This mostly comes down to system ordering which is an important concept when doing ECS whether you are using events or not. As for more ergonomics event there's the bevy_eventlistener crate that has a different type of event that isn't based on the normal bevy events. Personally, I'm very biased since I've been using and contributing to bevy for a few years a this point but I definitely prefer using it over something that only relies on events. I fully agree with OP that ECS can do both.

Very nice video! Optimization is my favorite part of programming :) I know it's a looot of work, but object fracturing would be cool to add, could allow some teardown-level destruction.

@DouglasDwyer

10 ай бұрын

For sure - once I get a character controller and more gameplay added, some realistic destruction mechanics would be amazing :)

@BusinessWolf1

10 ай бұрын

@@DouglasDwyer Oh damn, a game engine developer who actually intends to add gameplay features. That's rare. Most engine developers who call themselves game developers would've just continued to impletement destruction mechanics, more optimization and other things, worrying about gameplay later while thinking it's essentially just copy pasting everyone else's implementations.

Can't wait for the plugin api. I'm definitely going to play around with it

Funny idea, have an eye tracker that checks when the player blinks. Upon player blinking, the loose physics objects rasterize into the terrain. I have yet to see a game that uses real life blinking as update window for something xD

Every time that I see a notification for a new video I feel happy :)

I've heard somewhere that sound usually uses its own thread, if thats true, make sure to reserve a thread for that. (Otherwise your testing/benshmarking could be misleading.)

It's been a lot of fun "speedrunning" watching these videos from Devlog #1 today. Small things like an improved microphone setup, more deft editing, etc, all nicely parallel the improvements and growth in the actual engine. Nice work.

@DouglasDwyer

5 ай бұрын

I'm glad that you noticed!

This is really great to see, and mergin the voxels back in when the player's back is turned is really neat and elagant! One other optimization you might want to consider is distance-based processing of things like the physics. Things further away obviously aren't seen in as much detail, so you can get away with simpler "lazier" processing than you could when the player is up-close. That way if something happens to make a tree fall over 1000 blocks away from the player (e.g. something akin to a Ghast in Minecraft shooting a fireball at the player and missing, and then hits a tree hundreds of blocks away), then you're not wasting as many resources processing extra detail the player will never see. It may not seem like a big deal when it's just one event, but it's the kind of thing that can help a lot when you start scaling things up, especially if you plan to support multiplayer (or even full scale MMO) environments where a lot of stuff might be happening at a variety of distances. Even Minecraft itself has a concept like this with its "lazy chunk loading" mechanics, where it will not process more intense redstone / falling block / entity AI etc tasks in chunks that are far away from the player. Anyway, it's just a suggestion 😊

I am very impressed with project - in many attempts of developers to build large scale voxel game engine yours is one of the most promising! Really want to see future updates. Have a good day)

The merging idea is too cool. This is looking great!

You are so underrated! I MEAN IT!!!

I think event-driven architecture would work hand in hand with entity-component architecture, they really are different paradigms. Apples to oranges? Both fruit of course, but different in such a fundamental way. I think should you need entities, it would be trivial to add a new event-driven system that handles the entity-component systems. Great work as always, Douglas!

underrated af channel

Thanks for the kudos, but never forget that you're the one who is putting in the work to implement these features! And kudos to anyone who had the same idea - you're all thinking like proper gamedevs trying to optimise projects where it makes the most logical sense! Speaking of suggestions, I've seen a few asking for sand/water. One of the most performant-yet-appealing ways to do that is to fake it ala Unreal 5's Fluid Flux extension (otherwise you'd be limiting yourself to "x" amount of particles). Such water is a combination of "2D shallow-water simulation" and foam/shiny shaders to make the water look, well, watery! Ghostcharm on KZread made an excellent video titled "Water in Video Games" about the many shader tricks retro games used to render water. Okay, that's enough of me waterboarding everyone with recommendations! :P Oh man though, you have no idea how much content could be made for this once you add modding support. Keep chipping away at it, you're making something seriously cool!

@DouglasDwyer

10 ай бұрын

Yeah, my current idea for supporting fluids is to use 2D heightmaps. If I ever need fully volumetric water, the engine can just spawn multiple heightmaps. Since most water is homogenous (without too many holes), this should be quite efficient. Then, I can use cellular automata or other simulation logic to manipulate the heights. I'll be sure to check out the video by Ghostcharm!

always great to see more chris doerksen

@DouglasDwyer

10 ай бұрын

Love his music!

From a technical perspective, this is mind-bogglingly cool! Looking at it from more of a gameplay perspective, the building tools seem a little awkward IMO. I really like how Minecraft has a selection of building components - full blocks with many different textures, but also blocks with different shapes like doors, walls, panes, stairs, etc - that make it quite straightforward to put something together. For something that scales down to smaller voxels, maybe it could work something like: import a prefab object (like a door, wall segment, window, etc - you'd probably want some kind of model list or way to import entire textures), move the part in the world as a detached object, then once you like it you'd finalize its position and re-rasterize it into the world.

@DouglasDwyer

10 ай бұрын

I completely agree! Prefabs will be a must for the actual game. No one wants to build voxel by voxel, haha. I was thinking some sort of "blueprint" system, where you have a model defined (and can swap out the materials, reorient it, and the like) and then can place copies of the model into the world. Blueprints could be stored, shared online or even be in-game items. It depends upon the kind of game, though. Edit: I just want to point out that building is not yet meant to be refined. I haven't worked on it at all yet :)

@planetguyplays520

10 ай бұрын

@@DouglasDwyer Sounds great, and I'm excited to see where this goes!

It would be awesome to add in creatures that were voxelated like your other objects, and would walk around and interact with the world. Then, if they died, their body would become interactable as voxels. Making the trees become solid again while not looking at them is one of my favorite mechanics. I've seen it done very rarely, where the world changes when you AREN'T looking at it, and it was used perfectly here. Blueprints may be an important thing in your game. I don't see how else people could reasonably make objects and structures given the size of the voxels. But if a player could create a blueprint within an in-game holographic "drawing board" of sorts, and then just input materials into the blueprint to create the object, that seems like one way that it could work. Then they could also re-use the blueprint, making columns/floor tiles/fences/other repetitive structures feasible.

8:25, good news for you! Bevy in version 0.12 added support for so-called "one shot systems" aka invoking specific systems manually and only once (oh however many times you need to). I must say that I've been loving Bevy so far, it just takes a bit of time to get used to the data-driven paradigm

Beautiful Video Dougy

You should add a max size for objects that can be merged back into the grid, so big objects that are relevant to gameplay don’t fuse to the ground.

@DouglasDwyer

10 ай бұрын

Definitely, it will be a controlled setting! The object decay/fusion system is only meant for ground debris created by the player. Developers will be able to control the objects to which it is applied.

I think that if some of the trees could get displaced, destroyed, or maybe some leaf voxels destroyed and some displaced based on how fast it is moving would be cool. the result would be something like the leaves getting moshed instead of being completely ridged. I would say like bounce back to shape but that would be to demanding for something likely not noticed.

I'm not a rust programmer but I can give you my two cents anyway: In general if I *had* to choose between ECS or Event-Driven arcitectures, I'd take the events every time. It just makes more sense to my brain and I find it generally faster and easier to work with. Ideally id be nice to have access to both so that ECSes could post and listen for events themselves though.

Can you show us the transition that we're not supposed to see (floating items turning into the terrain) in the next devlog?

@nosense6885

10 ай бұрын

Once the object stops moving, there shouldn't be any visual change, it's only a transfer between data structures. Worst case would be a slight flickering for 1 frame.

@DouglasDwyer

10 ай бұрын

Yeah, I can try to include an example! The object sort of "pops" from one state to the next.

@SchemingGoldberg

10 ай бұрын

@@nosense6885 That's not true, because objects have rotation, but voxels are always grid-aligned. So it must rotate the object to be grid aligned, and then convert it to voxels. So the position of the object will change.

@nosense6885

10 ай бұрын

@@SchemingGoldberg Right, this is what I meaned by "a transfer between data structures", I forgot about the vertices rebuild from the updated octree. It's not that the object position change, there is no tree object anymore, it has been merged to the world.

@DouglasDwyer

10 ай бұрын

The object is not rotated to be grid-aligned, but rather re-splatted like the Steve character at 2:15 :)

very cool updates

Keep up the good work!!

Let’s goooooo more Douglas voxel game devvvvv

this looks amazing

I've never felt that stupid as after watching your devlogs. Great job, you are doing everything I've dreamed of doing for a long time 😅

Woo! Conservation of mass! I saw that original comment and i'm so glad you decided to implement the revoxelizing mechanic! It feels like your logical next step for a nice looking world would be to add water. I'm curious how you'll go about tackling that, will it have physics or will it just be static?

@DouglasDwyer

10 ай бұрын

Another commenter asked a similar question. I would love to have dynamic water! My current idea for supporting fluids is to use 2D heightmaps. If I ever need fully volumetric water, the engine can just spawn multiple heightmaps. Since most water is homogenous (without too many holes), this should be quite efficient. Then, I can use cellular automata or other simulation logic to manipulate the water heights and create effects.

Impressive, I envy your programming knowledge, if it would help, the game is played in the highest settings: frame rate 4.7 ms PC: ryzen 5 5600, GTX 1070, Ram 2133 MHZ

Love the progress, keep it up. Personally I prefer ECS. In my homemade engine I use ECS as a base where some components can emit events, which are then handled by an event handling system. But I could definitely see the other way around working as well, I guess it depends on how you like your project structured.

2:15 I WAS THINKING THE SAME THING! Lol!

The changes on geese allowing your engine to be multithreaded are great! Is this still compatible with web builds (maybe fallbacking to single thread)? I love your work btw.

@DouglasDwyer

10 ай бұрын

It's completely compatible with web builds and web workers! I use the wasm_thread crate in order to spawn multiple threads on the web, so a fallback is not even necessary :)

So like you could use cache like add different states For example Sleep state becomes when something isn't running for 3-5 mins Than you could add cache State After about 10 mins of sleep Where game just saves an file in folder which has visual data of that object so rendering can be faster But keep in mind you should create system to check how fast user's ssd or Hard Drive is so it doesn't take an 100 ms or something You could hide sides which user don't see and add cache to it too If user gets some Proformance and it's like you got 10 ms spare why don't like users going forward Use regression modal to predict next where user will go now pre render it in that Limited 10 ms So take advantage fully it may make it 25 ms not even 1 ms slower maybe but it will be better at caching the sudden spikes like suddenly breaking thunders of objects so if we already render it it's gonna be fine and instead of going to 30 ms or 100 it will stay 25

You should try running the collisions in opencl. I did that and the improvement is massive. I did it for voxel spaceships for my game.

Idk if you are doing this already, but if your using an svo, for such complex objects like trees, your collision detection could probably be at a lower resolution, and you would still get simmilar results. Also, love the idea of the voxels becoming part of the terrain! I personally like the ecs architecture, although I have never used an event based system.

@DouglasDwyer

10 ай бұрын

Yep, I use voxel octrees to accelerate the collision detection process! But I do want voxel-perfect detection because otherwise artifacts like objects hovering above the surface of the ground could occur.

@natecraver6362

10 ай бұрын

@@DouglasDwyer Ahh, yeah, that makes sense

looks nice, I'm also trying to create the voxel engine I think, that gpu acceleration of physics will be quite useful in this case)

Have you seen the Box2D writeup about Islands? Having just read that I feel there could be some overlap with your implementation. Great video!

@DouglasDwyer

8 ай бұрын

I'll be sure to check it out! I would guess that Box2D uses a similar concept; maybe something slightly more complicated than mine as Box2D has a full constraint-based solver :)

btw maybe you should use basic particle physics (with particle position being in the center) for really small objects? (if you're not doing that already of course) like if the object is less then like 4-5 voxels in size. this should speed up processing of really small debris and stuff

Very impressive! I think the physics objects merging into the main voxel world after some time will be the key to having Teardown-level physics on huge or infinite worlds. Keep it up!

@alan83251

10 ай бұрын

After thinking about it further, you’d probably want some way of keeping some things physics objects like chairs, cabinets, beds other furniture, etc., but merge stuff like debris piles (which could also be made up of small pieces) into the terrain. Not sure how you’d go about classifying these things.

recently made my ecs, and for the matter of multi threading its arguably the same, if not ever so slightly better for multi threading because every system in the ecs is a stand alone component which shouldnt rely on anything. So its already very similar to your event system, although given its architecture it removes the need for checking which processes need to activate after others, so it would arguably be slightly faster by maybe 10-25%. Though you will need to keep in mind that all systems are multithreaded so you can not have a collision system separated from a movement system per say. So you would need to keep it hooked up as a physic system which handles both movement and collision.

@DouglasDwyer

8 ай бұрын

In the architecture I use, you can definitely have a collision system separated from a movement system! The event library automatically detects these cases and ensures that those systems will execute in serial (relative to each other). While this does indeed add some overhead, the time taken to schedule new tasks is about ~500 ns per task. For my use case, this is negligible in comparison to time spent running the tasks themselves.

This is damn cool

Look into Photon Quantum’s ECS and event approach, I like it very much

What do you think about your voxel engine plus the raytracing GPU's now in combination compared to John Carmacks Trinity engine? Also I have subbed and liked! Looking forward to seeing what you're doing.

@DouglasDwyer

9 ай бұрын

I'm unfamiliar with Trinity, and cannot find a great deal of information about it online - so if you have any links, feel free to share them! GPUs nowadays are very powerful, and I've enjoyed trying out various rendering techniques on them. Unfortunately, since I target a wide range of computer hardware for this project, I still use rasterization (even though RTX cards are capable of much more). To compensate for this, I'm hoping to offload other tasks to the GPU as well (like world generation). This will provide performance boosts to those with modern hardware whilst allowing anyone to run my engine :)

Leaving a Comment for the AL-GOR-ITHM.

@DouglasDwyer

10 ай бұрын

Much appreciated, haha

God imagine if we had a 3d version of The Powder Toy with infinite space. It would be awesome and propably very inefficient.

It would be nice to have you give an overview of Geese. Maybe a demo or something like that

@DouglasDwyer

10 ай бұрын

Yeah, I would love to make a tutorial for it and add some example projects to the GitHub repository. Perhaps a future video on it :) I will mention that I talk about Geese more in my ninth devlog, so check that out for additional details.

Something fun woud be to be able to grab and move physic based object before they merge with the ground. And something funny would be to, instead of letting the player place blueprints on the grid, only giving them physic objects for building and letting your engine decide how to merge them.

Would you make the leaves of the cut tree die out and remove itself to reveal the wooden structure of the tree while it's fused to the terrain?

@DouglasDwyer

10 ай бұрын

I like this idea!

I would love a game that works like haven and hearth in this style.

I've been thinking about an interesting approach to voxel base game dev: So one of the biggest pain points with voxels is how will the users interact with the environment. But, what if the interaction is significantly simplified (e.g. large blocks are used, like in Minecraft), BUT all the voxel detail is procedurally generated on top, like in Townscaper? In townscaper, all you can do as a placer is place/remove large blocks, and the game automatically decides how to decorate them. Whether the blocks are buildings, roads, plazas, parks, houses, archways, roofs, etc. I feel like that could go a very long way in making an easy to interact with but also very pretty and detailed game, as players would likely not want to manually place all that detail themselves each time. Later down the line, you could add animations just like in townscaper too, where different decorations morph between each other as the blocks around change and the context changes. But yeah I guess the main consideration here is, is it a good idea to think allow your game engine to support decoration voxels that the player can't interact with, while their existence is influenced by other environment constraints, and the voxels can disappear when the constraints change?

@DouglasDwyer

10 ай бұрын

This is a very intriguing take! As I am building an engine, I want to support the largest degree of flexibility possible - which means that every voxel can be edited by developers. That said, there's nothing preventing a developer from creating procedurally-decorated blocks, or limiting player interaction to discrete sections :) To combat the problem of user creativity, my solution would be to provide pre-fab structures (like a corner of wall, a piece of floor, and the like) which users can place. Users would retain the freedom of editing individual voxels, but they could use pre-fabs for a quick, easier build.

How do you sample voxels fast? Do you use a trick to sample bigger parent voxels in the octree or do you only sample 2D or how do you do?

@DouglasDwyer

10 ай бұрын

Yes, my engine samples homogenous octants within the octree rather than individual voxels. I talk about this more in my last two devlogs! I'd be happy to elaborate if you want to know how voxel sampling works for a specific algorithm.

The cubes seem to have much more rotational inertia than positional inertia, they always rotate very slowly.

@DouglasDwyer

10 ай бұрын

Moment of inertia is an adjustable parameter! Perhaps it was set a bit low in this video.

this verry cool

Hi, great result! Please add water, streams and rivers, waterfalls, what do you think about it?

@DouglasDwyer

10 ай бұрын

Water will be another challenging thing to implement efficiently, but I would love to do it!

@Alexey_Pe

10 ай бұрын

@@DouglasDwyer I understand that water is very difficult. And I can understand how to write the physics of water so that it flows down, but it’s very difficult for me to make a waterfall - because all the water always flows down, so the complexity of the task just kills me xD

Does your web/wasm version you can try online use the multithreading? (using web workers, for example)

@DouglasDwyer

10 ай бұрын

Yes, the multithreading system works on both web and native!

If I detached an object, rotated it a certain amount, then spun myself 360 degrees, could I realign it so that I got more material than I started with?

@DouglasDwyer

10 ай бұрын

Good question! Yes, you could technically increase the volume. This is necessary because I use a conservative rasterization process - any voxel that overlaps the object, even slightly, will be filled. This ensures that the object (which was originally one connected component) remains one connected component after splatting. To combat this (because it could cause balancing issues if the game has resource harvesting) I plan to make it so that you can only harvest some fixed percentage (say, 80%) of the voxels that you destroy. Other voxels will be lost upon destruction, guaranteeing that repeatedly destroying an object doesn't make it grow arbitrarily.

Is weather going to be a part of the game ? If it's going to be part of the game are particles like snow that appeared in the video going to be affected by wind or other stuff ? Very nice project i like it so far.

@DouglasDwyer

10 ай бұрын

Yes, I would like to include weather in the project long-term. Having wind effects on the particles is a good idea! I'll probably add that when I redo the particle system to increase customizability.

Dang, seeing as I considered aligning non-world objects with the world again too in an earlier mental draft of my voxel engine and thought there would be a lot of issues: Do the voxel counts stay the same after the structure is re-aligned?

@DouglasDwyer

10 ай бұрын

Good question! Another commenter asked this as well. The voxel counts typically do increase after re-splatting. This is necessary because I use a conservative rasterization process - any voxel that overlaps the object, even slightly, will be filled. This ensures that the object (which was originally one connected component) remains one connected component after splatting. To combat this (because it could cause balancing issues if the game has resource harvesting) I plan to make it so that you can only harvest some fixed percentage (say, 80%) of the voxels that you destroy. Other voxels will be lost upon destruction, guaranteeing that repeatedly destroying an object doesn't make it grow arbitrarily.

so if a tree falls diagonaly and merges with the terrain, does it have to snap to an orthagonal direction and line the voxels up? or is the entire object "re-rasterized" at a new angle?

@DouglasDwyer

10 ай бұрын

Great question - the entire object is conservatively re-rasterized at the new angle.

Would be cool if your game had water, gravel, and sand that interacted with the physics engine. You could reuse this "put them to sleep when not moving" part to not simulate them all the time. The only real difference between sand and water in your engine would be the slope they settle on.

If you were to have sand that falls, would you make the sand into falling objects (like Minecraft), or would you make it work like those falling sand games, where the sand particles aren't individual falling objects?

@DouglasDwyer

10 ай бұрын

Haha this is a tough question. My engine is designed for large, sparse updates to the voxel grid - so it wouldn't handle many small updates (like falling sand) that well. I would probably need to create some kind of separate "fluid" object (the same kind of object used for water) which large chunks of sand become when disturbed.

@BusinessWolf1

10 ай бұрын

@@DouglasDwyer Another way would be, if an object starts being affected by physics in some way you could look for other objects being affected by physics in some radius around it, and if it surpasses a certain number of entities you scan again with a bigger radius, and so on. And when you've got all the objects, you make everything that is not part of the world into the 'fluid' object you mentioned. So sort of a dynamic 'lots of stuff moving' detector.

The web demo is running really well on my Xiaomi Poco F5! (even tho I can’t look around or move)

@dominicstocker5144

6 ай бұрын

I think that in maybe 5 years this could be the case for the majority of phones, considering that games can take that long to develop, adding mobile support to the engine as a launch feature might make sense, but idk

Nifty

ECS Systems are really good at intense simulations, but they're pretty bad for general software usage (logins, UI etc). I think any game that gets large enough is going to have an ECS system embedded in it, but not be the entire application.

Are you using SIMD to increase performance? I like that debris become a permanent part of the world. You could make it an option that player dropped items also become permanent after some time. If there is more than 1 item nearby, they could be put in a box/chest.

@DouglasDwyer

10 ай бұрын

Yes, I use 128-bit SIMD to process eight 16-bit voxels at a time :)

Question: Since you're building this in Rust, and also have available in-browser, any plans on transitioning to a wgpu renderer (WebGPU for browser)? And what about Vulkan instead of OpenGL?

@DouglasDwyer

8 ай бұрын

Definitely - switching to WGPU is on the to-do list; it should bring some nice performance benefits as well as amazing new features (like compute shaders) :)

@HickoryDickory86

8 ай бұрын

@@DouglasDwyer 😁

DOUGLASSSS

do you use any dependencies for the physics? Or is everything from scratch?

@DouglasDwyer

5 ай бұрын

I describe the details of the physics system in devlog #12. Everything is from scratch! In the future, I will probably be either redoing it or switching to a library so that I can use a constraint solver for the physics. This will allow it to be more physically accurate.

@ohfacts

5 ай бұрын

I see. Very impressive work. @@DouglasDwyer

4:35 i'm not sure it it's true, imagine something flies up and then stays there because it lost all kinetic energy and only has potential, but stays there. Maybe there shoul be like "it's didn't change position in last 2 ticks"

@DouglasDwyer

10 ай бұрын

Yeah, I definitely glossed over this in the video - but the physics system detects arbitrary changes in both an object's position and velocity. In this case, the object would not get stuck because its velocity would flip direction at the apex of its motion!

@aspidinton

10 ай бұрын

@@DouglasDwyer oh then everything is well coded 🙂👍

I want to make a game with this like a lot

@DouglasDwyer

10 ай бұрын

My goal is that someday you'll be able to do so!

Interesting video reminds me of RubyDung The pre-alpha version Minecraft of Mojang Specification 2008 Year

Can't wait for a modding api, im tired of minecraft!!!!!!!!!!!!!!!!!!! Keep up the good work!

I think ECS is more of a bulk processing thingy. And it's not even an alternative to events really, it is just an advanced representation of objects (cache local components aka fields and cache local methods aka systems). It's not there to replace messaging/events and it shouldn't really.

I'm wondering if you were planning adding any multiplayer capabilities to your engine?

@DouglasDwyer

7 ай бұрын

Multiplayer is already implemented and completely working! You should be able to try it using the online demo. I discuss the multiplayer system a bit more in Devlog 5 (although the microphone for the video is a bit poor - please excuse it).

@programmingfromnull9784

6 ай бұрын

@@DouglasDwyer My bad. I have now watched your videos on the engine and it's mighty interesting. I plan on making a voxel game but I have no idea where to start. (To be fair, I'm still on very early "sketching the core mechanics" stage) The game will be about designing robots to battle. There will be different arenas/maps and the possibility of having multiple robots controlled by a single player. Controlled is actually the wrong word here because I plan to give the robots some simple ai to battle, players will mostly be involved in designing the robots and changing "AI mode" with some added spice. (ie: defensive, which makes your bot try to stay at a distance where it's longest range weapon can still hit the enemy bot, aggressive which makes your bot try to get as close as possible to the enemy bot) I originally wanted players to be able to build any kind of robot by just placing different types of voxels (ie: light armor, heavy armor voxel, and multi voxel parts like guns, wheels, etc) but... knowing the internet, there will be at least some people making inappropriate shapes, so I scrapped this idea and decided to go with larger pre-built pieces (ie: disc shaped chasis, triangular chasis, etc) I also plan on adding some simple drag and drop scripting similar to scratch to allow users to program their robots, though I'm not sure how detailed I want this system to be... (Should it be super high-level like SetTarget(Robot target) / SetTarget(Voxel target) or something more Like AimAt(x, y, z)... Or Both?) I also want to add some other stuff regarding voxels but I am not sure how I can add them... For example, let's say a spider robots leg is normally 8x1x8 voxels wide, but it got damaged and lost a few voxels, now it's connected by only a small 3x1x3 piece... How would I go about determining that and maybe making it so the leg bends/deforms if the robot puts too much pressure on that leg? Similarly, let's say a heavy gun is mounted on the stinger of a scorpion shaped robot, if this stinger gets damaged, or the gun is too heavy to be supported by the stinger, I want the stinger to bend downwards, making aiming incredibly difficult. How would I go about detecting that a part is too thin to support the weight of the connected parts?

@programmingfromnull9784

6 ай бұрын

@@DouglasDwyer How do you think that bending mechanic could be implemented?

@DouglasDwyer

6 ай бұрын

Hey, I think it's great that you have an idea regarding the core gameplay mechanics for your project! It's helpful to know early-on, so that you can spend your time effectively. If you are going with pre-built robot pieces, perhaps the most straightforward approach is to script/pre-program all possible interactions? For example, your spider leg could have three states for varying amounts of damage. These three states could each correspond to a different voxel model (the damaged states would have some voxels missing) and a different amount of deformation. By pre-scripting all interactions, you avoid having to build an entire physics system to create such emergent properties (which is a very difficult task) and you also gain more control over each interaction/state. The bending mechanic is a very tough question to answer. Most voxel engines represent voxels as regular grids, without deformation. Games like Teardown achieve bending, then, by connecting separate voxel objects together using physics constraints which allow the individual non-deforming pieces to move and rotate at a joint. Another possibility would be to use a "cloth-like" simulation where each vertex in your voxel mesh is allowed to move from its origin somewhat. Let me know if you have any other questions, and good luck on your project :)

@programmingfromnull9784

6 ай бұрын

​@@DouglasDwyer That's a good answer. I wanted the physics system to be dynamic though. Because I want the game to be rewarding to those who took the time to write better algorithms for their bots. For example. Let's say there is a spider robot. The weak points on the legs would probably be the hinges (well that's true for most robots with "legs" instead of wheels or tracks I guess) If two robots were to be equal, I want the person who scripted their bot to aim specifically for the hinges instead of "legs" to have an easier time damaging the mobility of the enemy... Or let's take a more different approach. Let's say there is a tank shaped robot that has a sprint loaded flat piece of metal. It's purpose is to try to get under enemy bots legs and flip them to make it easier for other bots to target. The plate would be a huge target, so instead of the plate I want the players who aim at the hinge points of the plate (or players aiming at the part of the chasis where the spring loading mechanism would be) to have an advantage than ones that simply program their robots to target the weapons(this plate would count as a weapon). Anyways, it feels like making the vertices move slightly seems like a really good option. The calculations for that still seem rather difficult to calculate though...

I can't seem to find a license for it on the github. What is the business model of the project, or if you don't have one, what's the intent?

@DouglasDwyer

10 ай бұрын

Excellent question. I started this project purely as a hobby, for my own enjoyment (hence why no license - I am not yet distributing it). In my dreams, the engine's business model would roughly follow that of Minecraft/Roblox. Users would be able to create and publish games on my platform, which other users could then seamlessly download and play. In terms of revenue sources, I could charge for account creation and also take a cut of any purchases that users make (on third-party games and IAPs) sort of like Roblox. But I'm still working out exactly what the best way to monetize the engine would be. I see that your KZread username is BusinessWolf, so if you have any business suggestions I'm all ears :)

I have a suggestion. When you are chopping the trees and the leaves, the just fall down vertically. That looks a bit unnatural. How about adding a force to them? simulating the impact of the axe?

@DouglasDwyer

10 ай бұрын

Somebody made the same suggestion last video :) The axe is just a placeholder, but I think that is a great idea! 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!

@jawadch8723

10 ай бұрын

@@DouglasDwyer Its is lovely to know that your feedback reaches where it should.

@JMW1906

10 ай бұрын

Regarding the leaves falling straight down: Each voxel type could have a weight or density associated, a (simplified) ulsurface area could be computed (e.g. bounding box or all voxel sides exposed to one side), this could be efficiently stored in the entity after it was computed once. With that data there could be wind (e.g. just coming from one direction or even roughly simulated based on the surrounding world), which applies a force on the entire object based on its surface area. The biggest performance impacts would probably be calculating the surface area (once), simulating the wind based on the environment (can be cached as wind doesn't change too often) and that there is more potential for objects moving and this not going into idle as early. But it would be awesome if leaves/other entities could fly around in the wind and the and wind system could be used for other gameplay elements.

Is it possible for a game to use both voxels and traditional polygons? I love the freedom and destruct-ability that voxels provide but generally prefer the sharper more detailed graphics polygon based games provide. Could an engine use voxels for the internal structure/physics interactions of objects but have a "skin" of higher resolution polygonal textures laid over the objects? Maybe integrate an ai model that could predict and adjust how the textures would change as damage is done to an object. I'd also love to see material interactions like wood burning and breaking down into ash, heating water to evaporate it, or acid actually dissolving and breaking down susceptible materials. A game that demonstrates this well is Noita though its 2d and uses regular pixels. Anyway great work, looking forward to seeing what else you come up with 👌

@DouglasDwyer

8 ай бұрын

Thanks for watching! Yes, some engines do use a voxel representation underneath while rendering with polygons. The most common technique for doing this is called marching cubes. However, I plan to stick with cube-based rendering for this project - it is where I have focused my tech and artistic efforts. Material interactions would be awesome. For performance reasons, I'm not sure if I can get quite as sophisticated as Noita - it's much easier to simulate 1024^2 pixels than 1024^3 voxels, haha. But things like fire and acid might be possible! I think another voxel KZreadr, Tooley, did integrate fire into his engine with success - and his scale is similar to mine.

What do you use for GUI? Imgui?

@DouglasDwyer

9 ай бұрын

I use egui for the debug UI right now.

@YYYValentine

9 ай бұрын

@@DouglasDwyer that was the other one i considered, it has impresssive demo. I would like to create some visual programming stuff. But it will be a long time.. I just getting now borrow checker

What if Objects cut from the world have their voxels "fall" and turn to dirt. That dirt gets attached to the terrain. Like a degradation mechanic for cut trees. Instead of just a cut tree that becomes part of the terrain. Or maybe over time? Felt like tossing the idea

If you plan to have enemy adveserials, forest critters and other npcs, I would mock them up asap. (for physics, despawning, messages, etc). Otherwise you'll optimize the the game a second time later on. It would also increase hype:D I would also recommend doing a full gameplay loop right away, otherwise it is too enticing to keep optimizing internal systems. I've been there too many times 😅

@DouglasDwyer

10 ай бұрын

For sure - once I get the plugin system working (and some other essentials such as sound and game input), I want to create a simple proof-of-concept game that establishes the capabilities of my engine. But the goal is to allow other developers to create their own games with it too!

@dominicstocker5144

10 ай бұрын

@@DouglasDwyerso it would be something like Unity licensing wise? Being able to use your engine for one’s own game sounds like a dream

@dominicstocker5144

10 ай бұрын

@@DouglasDwyerI do wonder what platforms your wonderful engine will support!

@DouglasDwyer

10 ай бұрын

Others will absolutely be able to use my engine - but the licensing will be more like the App Store rather than Unity. I don't intend to charge developers a fixed rate to use my engine - rather, I plan on taking a cut of the profits made with my platform. Creating and publishing new content will be free for developers :)

@DouglasDwyer

10 ай бұрын

At this time, I plan to support all desktop platforms as well as the web :)

light theme 😩

@DouglasDwyer

10 ай бұрын

😎

I'm learning rust for graphics and game programming, I will test geese as soon as possible

@DouglasDwyer

9 ай бұрын

Epic - let me know what you think!

Douglas-agen

why don't you remove the collision from the tree's leaf and make the fallen small leaf destroyed

Maybe you already explained how you're doing physics for objects that have spawned as a result of world voxels being separated from the scene's volume, but 1ms per tree is insane! There's algorithms for filling an arbitrary 2D area with rectangles and 3D area with rectangular prisms. Maybe you're already doing something like that, but if not, you should be able to get a huge perf speedup if you represent voxel objects using a simpler collision representation. IIRC this is what Teardown does, or something similar to it. It definitely shouldn't take 1ms to perform collision detection with one object! If your plan is to have a multiplayer world then there's going to be a lot of objects, dozens, at times, so minimizing the compute required to perform physics updates on voxel volume objects is imperative.

@DouglasDwyer

8 ай бұрын

Thanks for your feedback - I agree, minimizing the time spent during collision processing for an active object is imperative. What makes you believe that 1 millisecond is an unreasonably large amount of time for collision detection with the trees? They are large, complicated objects, and volume-on-volume collisions require identifying potentially-overlapping voxels and then running precise collision detection tests on them. (Bear in mind that this is the time it takes to actually run collision detection, so for frames where the trees are sleeping, collision detection does not occur. For smaller/simpler objects, collision detection is quicker). I would love to know if there's a way to do better, but I personally view even my 1 millisecond time as an achievement. Of course, there's still much room for improvement in my physics engine (like the lack of a real constraint-based solver) but I don't have many ideas for further optimizing detection.

@CharlesVanNoland

8 ай бұрын

​@@DouglasDwyer What I mean is that you don't need to do precise volume-on-volume intersection tests. It's a compute-hungry operation that doesn't really add to the player experience. One millisecond to do that is totally impressive, for sure, but if the aim is speed, to handle many potential objects of all shapes and sizes in a multiplayer game where there could be potentially dozens of objects bouncing around, and you can sacrifice precision, then you can perform simpler intersection tests where a volumetric object (like a felled tree) performs all of its collision detection using a handful of parametric shapes against the world's volume - like a set of boxes or spheres approximating the object's volume, which will be much cheaper to check collisions against. For a multiplayer game there's no way per-voxel collision is going to be viable between objects, not with today's hardware at least. You should also start thinking about how all of this is going to work in terms of multiplayer netcode. What is the server itself going to be doing in all of this: is it going to be authoritative, telling every player client what each object is doing, where it i, how it's moving, etc... or are you going to let clients tell other clients what the situation is to minimize strain on game servers, which will make the game a potential target for hackers too. i.e. if a tree falls down, who is in charge of its physical state? The player that caused it to fall, or the game server? Depending on how many players you plan to have, can a server handle the potential number of objects that all of those players might be creating? Collision between one object and the world should be very fast - and when it comes to interactive realtime simulations, one millisecond for one object is very slow. When an object is spawned from a detected free-floating chunk of world voxels you can find a set of boxes, or generate a coarse triangle mesh, that approximates its shape and perform collision with that. The speed up will be orders of magnitude.

@DouglasDwyer

8 ай бұрын

Thanks for your response! Multiplayer is already implemented in a server-authoritative model. Agreed, the faster the objects can be processed the better. This is why I implemented the techniques in the video (like object sleeping) so that even if some really large objects are spawned, most won't be processed unless they are actually moving. I guess I still don't fully understand how finding an approximate set of bounding boxes would work while ensuring that the physics still functions in a convincing way (I would rule out generating a triangle mesh, because that would mean performing mesh-versus-mesh intersections and that sounds difficult for non-convex objects). How precisely does one "find a set of boxes that approximates the shape?" The approximation would need to be specific to the object - for example, the approximation for a tree would need to roughly conform to the trunk and the tree leaves. Or what about approximating a constant slope/plane of voxels? Any approximation whatsoever will overshoot/undershoot in certain places, causing nearby objects to visibly float inside/outside of the plane. Again, note that the trees are quite large and smaller objects don't take up as much processing power. Further, for objects like players it's possible to just use a single collision AABB, which should be much quicker. So unless dozens of players are chopping down trees at the same time, small-scale multiplayer with this scheme should be viable. Lastly, I should mention that I am using an acceleration structure for physics already - individual voxels are not compared, but rather octants in voxel octrees. Even with that, the collision detection time is about 1 millisecond for the trees. I appreciate your insights, by the way :)

@CharlesVanNoland

8 ай бұрын

@@DouglasDwyer Yes, you need unique collision geometry for each object when it is spawned because each object is unique, and the coarseness/accuracy of that collision geometry will be up to you. I'd lean toward preventing non-contacts from happening and always have the collision geometry err on the side of being smaller than the actual voxel volume itself, which will cause some intersection but IMO that's better than having objects bounce off the world or each other without visibly contacting. This could be using an array of 3D collision boxes, or spheres. There are ways to fill a given 2D/3D shape with rectangles/boxes or circles/spheres. As for the cost of intersecting collision meshes: this is what all the old physics games used, like Half-Life2, Doom3, etc. Then you're just finding when a vertex is on the wrong side of another object's collision-mesh triangles, and performing mesh/volume intersection tests for object-world collisions. For a tree I'd imagine maybe two-dozen triangles for a mesh, tops. You're definitely not generating a mesh directly from the voxels, that would produce hundreds of triangles and defeat the purpose. Collision meshes don't have to be super detailed and accurate, that's where the performance gains come from. You can also include a simple flat-array spatial index when generating the coarse meshes so that it's fast to determine what vertices/edges/triangles to test for intersection against. Isosurface extract a level of the volume octree above the leaf nodes, then perform a triangle decimation pass to further reduce the triangle count. The goal is to reduce collision detection to a minimal number of intersection tests. Objects should only be a handful of checks, with whatever broadphase culling strategies you want to employ to ignore as much geometry as possible - like having a simple bounding sphere for objects too that you first check one object's vertices against (simple distance check against radius of sphere) to determine if a vertex on one object's collision mesh is even potentially intersecting the triangles of another. Verts inside the other object's bounding sphere then are used to find which triangles to check against via the spatial index. Super fast and simple! There are all kinds of things that can be done and this is just one example. So right now you're performing collision against the volume by iterating through the object's volume octree? Have you tried not iterating down to the leaves, and only go down to the level above them? If a node contains empty/non-solid children leaves then treat it as empty. This will cause the partial-intersection issue, but it will be better than objects not touching at all when they bounce off each other. Skipping the leaf nodes I imagine will halve the collision testing time, but 0.5ms is still expensive for a single object. Yes, I get that the trees are big, but ideally it would be a relatively flat cost for all objects because trees likely won't be the biggest chunks that players produce. Another idea for your existing approach would be to only consider voxels that are corner/edge voxels when checking for intersection against another volume. Instead, instead of generating collision volumes you preprocess a new object by finding those corner/edge voxels and save them to a spatial index for the object to use for checking for intersection with another volume, rather than every surface voxel checking against the volume of another object or the world. There will still be a number of corner voxels for a shape like a tree, and it won't be as flat of a cost, but if done right it should be faster than traversing the volume's octree and checking every surface voxel. The key is broadphase culling. Adding a simple bounding sphere to first check if a voxel is even within the bounding sphere of the other object first would probably halve the time it takes to check one object against another. At the end of the day, 1ms is a huge expense for a single object, however big or small. You won't find a game or engine that spends an entire millisecond on determining if one object intersects anything. For a single-player game you might be able to get away with it, but if you have an authoritative server model then your server is going to be spending most of its time doing collision calculations and potentially lagging the experience for players. Are servers running in the cloud or do players run servers themselves? I'd want the server to be able to run at a fixed update rate, and a number of players will each be creating a bunch of objects rolling and bouncing around simultaneously from time to time and I'd want my physics to be as fast as possible in that situation. That's where leaning on as many strategies as possible to speed things up comes into play - simpler representations of an object's volume, broadphase culling at the object level and at the actual intersection test level, etc... Anything that saves CPU cycles without totally ruining the game is a win. Another strategy is to multithread collision and physics in general, divvy up the work across all available cores. I've found that to be invaluable when maximizing performance on end-users' hardware. I've always gone with a threaded job system, usually where only the main thread can spawn jobs (it ends up being simpler to code) and at init I just spawn as many threads as there are cores, minus one (let the main thread have a core to itself), all running in a spinlock that keeps checking a ring buffer for new jobs and taking one on if there is. That's protected by a mutex to ensure that two threads don't take the same job. It's worked great for my gamedev projects and my software. Anyway, hope you got something out of this. I look forward to seeing where you take things. Good luck! :)

@DouglasDwyer

8 ай бұрын

Yeah, I guess it's just a problem of accuracy. Like I mentioned previously: doing something like only iterating down to the nth octree level (rather than the leaves) could leave objects visually intersecting/floating apart from one another when they should be just touching. It depends upon whether you value that amount of detail, which I presently do. Of course, it doesn't have to be perfect, but having collision be off by an entire voxel seems noticeable :) The idea of edge voxels is a good one! That might be possibly to do even on-the-fly with the way the voxel octrees are set up. As it currently is, I only check surface voxels/octants, but this could potentially allow for another speedup. I could try this at some point. Yes, I already have broadphase culling implemented. Only models with overlapping bounding boxes are checked for collisions. This is where the 1 millisecond number comes from - performing a precise intersection test between tree and terrain after the the broadphase test passes. Agreed, the current goal is to have the server run at a fixed rate of 25 milliseconds per update on average. Players will run the servers themselves, but they could also very well set up a cloud server independently if they chose. I will state that my current engine is designed to facilitate physics objects with a maximum size similar to the trees - anything bigger won't be supported by default (at least for destruction). This, I think, is a realistic goal. Doing the math (albeit somewhat optimistically), for a tick rate of 25 ms/update on a machine with a 4-thread threadpool, up to 25*4 = 100 players should be able to simultaneously chop down a tree before lag begins to occur. This number is acceptable to me for now, since I don't envision situations where a player is able to create many large objects simultaneously (and by the time that a player moves on to destroying other objects, the initial objects should move into the sleeping state, no longer incurring processing time). Could it be much better? Always. But my time is unfortunately limited, and so for right now I'll probably be moving toward developing other parts of the engine :) Thanks again for your time! I will do more reading on the space-filling algorithms you discuss. I have heard that engines like Noita use triangular approximations to great success. But it's hard for me to imagine an algorithm that produces believable results. Still, maybe there's more room for optimization even in the current implementation; I haven't profiled that extensively.

ECS is better. You can use your event driven aproach in UI, network and so on, but game code wil be better in ECS. Events are harder than ecs to maintain in long run development.

@DouglasDwyer

10 ай бұрын

Thanks for your feedback!

Where is the source code? I could only find a compiled exe on github.

@DouglasDwyer

6 ай бұрын

Thanks for your interest in my project! At this time, I have not released the source. I am still working on polishing and improving the engine. However, I have open-sourced several components, including the event system and networking libraries! If those interest you, feel free to check out my GitHub.

@owendavies8227

6 ай бұрын

@@DouglasDwyer Are you planning to release it?

@DouglasDwyer

6 ай бұрын

As long as I am actively developing the project, I don't plan on releasing the engine in full. I hope to turn it into some kind of publishable game or product :)

Fallen pieces becoming the world is an extremely interesting take, but your tree example seems wrong to me. I was able to push it around and now I cannot. I'd limit it only to "particles". Right now, I can chop down the tree, split it into logs and [whatever else], but as soon as I walk away to "sharpen my axe", I'll return to the tree shaped terrain. IMO, object sleeping should absolutely be enough. I should be able to cut down the tree and (if it won't disappear altogether) come back to it in a month and push it aside. Still, I absolutely love it as a tech and for particles disappearing. You could cut the whole forest and instead of ending up with a grassy plains, you'll have lots and lots of "debris induced coloring" on the ground. Basically forever.

@DouglasDwyer

10 ай бұрын

For sure, I can see why both ways could be desirable. From the opposite perspective, having excessive trash on the ground could get annoying to players - so it might be good to remove it, depending upon game mechanics. I guess you feel that objects above a certain size should never despawn? I want to make it tunable for developers.

This looks nice, But whats the point too it?

@DouglasDwyer

10 ай бұрын

My goal is to eventually create a game engine so that developers can create multiplayer video games using it. The fully destructible environment should lend game devs/players more creative freedoms than ever before!

@SchemingGoldberg

10 ай бұрын

It's a voxel engine. Similar to Minecraft, but with much smaller voxels. So the game can have more details and better physics.

The thing with all these voxel games that annoys me are objects that are moving, rotating, etc are no longer voxelized with the world which looks odd. I can understand that would probably take a lot of processing power.

A semblance of life Ic am creating. Regrettably, for the sake of expediency, it taketh the form of pixels. Likenesses therein Ic discern.

My small smooth unity\c# developer brain fails to understand whatever black magic you are doing when merging voxels back to the main voxel grid, but it is definitely cooler than just blinking them out of existence.

I notice lots of reverb in your recording. Try moving the microphone much closer to your mouth.

@DouglasDwyer

10 ай бұрын

Thanks for the tip! I will try that next time.