Adding A CACHE To My Custom VOXEL Game Engine | Devlog #5

[@Nate-mi2se]

I think your biggest concern for this project is KZbin's compression lol

[@voxelbee]

Yeah lol

[@slavkosky]

@@voxelbee Best way through that is to make sure to encode all capture/output sources (and your final export) at as high a bitrate as you're willing to handle waiting for the video to upload. Since KZbin recompresses your uploads into it's various formats (resolution dependent), capture and export at ~40-60Mbps for 1080p (H.265 gives a better result over H.264 if you can spare the extra CPU overhead)

[@woofcaptain8212]

@@slavkosky also if you upscale the video and upload it the KZbin compressor will lose less data since there are more pixels to work with

[@slavkosky]

@@woofcaptain8212 That's...partially true. KZbin sets a target bitrate for it's VBR compressor based on resolution..so more resolution = higher bitrate ceiling, but that doesn't guarantee quality if the source material is overly compressed to begin with

[@Phoen1x883]

@@slavkosky so tl;dr: record and render at a really high bit rate (lossless if feasible). Upscale to 4K for the final render if you didn't record in 4K.

[@superscatboy]

KZbin's video codec really doesn't like those textures at all. Neither do I tbh, but it doesn't take away from how slick this tech demo is.

[@voxelbee]

Thanks! I'm going to try some other scenes that might work better for the next time!

[@3dadventures792]

@@voxelbee I think rendering to 4K, or even higher, might help. Even if you don't have a _native_ 8K recording, youtube is going to give the 8K streaming a much wider bitrate, which will massively help with this.

[@jameshasseriousedoubtsabou560]

You could make an entire detailed, non voxel looking game game using that amount of voxels. Insane.

[@superkingofdeathify]

The only problem with that would be the manipulation of the voxels. I may be entirely wrong but it seems like a dynamic (on the level of actual geometry moving at 60fps+) world of these voxels would either need to approximate movements and not simulate the motion of all voxels, bake animations, or pretty much just use intersections with mesh geometry for estimates at which point you might as well use normal meshes again. It's brilliant as a voxel simulation but I don't think it's suited for a non-voxel game with any level of dynamic motion.

[@MDGeist-ws2rh]

@@superkingofdeathify Look up atomontage and John Lin's Sandbox.

[@superkingofdeathify]

@@MDGeist-ws2rh both of those take a different approach to the rendering and data management, as far as I understood. Whilst I wouldn't say it's not possible, the engine in this video doesn't lend itself to soft body or armature deformation and I still think it wouldn't work so well for normal dynamic gameworlds. Would be incredible for to be proven an idiot though.

[@BigDickEnergy777]

@@superkingofdeathify maybe It doesn't work now, but that doesn't mean we can't make a mixed approach or evolve later ta a fully dynamic world with quadrillions voxels... Just need to keep evolving, maybe we can get to a point so ridiculously high in efficiency that we can make old 98 windows era Hardware run lifelike realtime dynamic voxel worlds...

[@superkingofdeathify]

@@BigDickEnergy777 oh I fully agree, I was only referring to the difficulties in doing so as it is, in reply to the original comment about it being good for use in standard games.

[@Kelvin-hh1ci]

Wow, that's one of the most efficient voxel renderers I've ever seen. This is amazing!

[@jerryplayz101]

I would love to learn how to do such complicated things in Compute shaders... and yes... that is a crazy efficient algorithm that I would not of thought of would work. You have dumbfounded my 3AM brain....

[@aleksitjvladica.]

Thank you.

[@sjoerdev]

this is all i look forward to in my life now

[@widrolo]

cant wait for a game that was made with this engine

[@rogercruz1547]

Problem 1 was a buffer overflow. You can talk dirty/tech to us, we'll get it ;)

[@DungeonsAndDiving]

At least there's no RIP overwrites occurring... haha

[@rogodarius9166]

Damn, that's impressive - I thought I was being clever when I used slices of alpha textures to represent filled and unfilled voxels - I used to brag about numbers like 8million voxels with only 49k triangles xD - your engine has officially won the voxel race :D

[@user-vx1wt4hb5l]

Dude, this is sick. I had this idea to store Manhattan distance fields to voxels in 3d textures with a chunk loading system (the distance fields could be made in only a couple ms with separable filters). Traversing that was FAST (>400fps with 4 billion voxels). But seriously, a trillion voxels wtf? I just wonder if both systems combined could be even better?

[@voxelbee]

Thanks man! That's a pretty cool idea haven't explored distance fields but that sounds like some good performance! Maybe should look into it...

[@PenguinjitsuX]

These videos are really cool! It's so interesting to see someone making their own game engine among the sea of KZbinrs making devlogs for just games. It's really unique and fun to see this and I'm excited to see the full engine someday! I especially loved that huge scale change zooming in effect you were working in another video, there can be some really cool games made with that ability.

[@voxelbee]

Thank you so much!

[@gownerjones]

This is some truly impressive technology. You should definitely write a paper about this.

[@voxelbee]

Thanks! You should check out the papers I used to make this... I've linked one in the description!

[@rancoroustomberry3398]

Almost unbelievable ! Your work is incredible, and your determination is inspiring ! Good luck man, I can't wait for your next devlog !

[@Exxabite]

Imagine if Minecraft could handle that many blocks.

[@anselp.498]

If we could get a variation on this engine that allows for rotated and textured voxels, this would be incredible. The next thing is to have lighting, but all of these features lead to a less optimized video engine

[@iamlogdog]

@C M What?

[@DemsW]

@@anselp.498 Best thing would be to make it so the features are toggleable and can work independently for max perf

[@gownerjones]

@@anselp.498 Call me an idiot but I don't see why you would need textures in an engine that can render potentially infinite levels of detail. Using view frustum culling, like the engine is already doing, and some refined level of detail optimization, you can easily have a voxel per pixel visible (or more) and achieve perfect resolution. An engine like this doesn't need textures in the traditional sense. But then again, I'm not an expert.

[@dairop3220]

@@gownerjones I guess textures can still be used to save some calculation time for close views, but you're right, textures can probably be done using only those voxels and some defined colors

[@Poly_0000]

I like how you actually show your errors. Most gamedevs like to skip past all their mistakes.

[@philsburydoboy]

That is brilliant. Now you've got my gears turning on similar caching systems for my projects.

[@c64cosmin]

I have a million of questions, your algorithm is genius! Never went out of my way to learn Vulkan, but you show here what power it enables. Instantly subscribed, looking forward for more, wish you good thoughts and success. You're inspiring! Thank you!

[@OnToreOllaStopa]

This is super impressive and the cache pausing that you implemented is the perfect way to show off what is happening!

[@Banji59]

This is incredible to see how smooth it runs ! Good Luck man !

[@jackadevil9746]

2 things: 1. This is hella impressive and I gotta watch the rest of the series to understand how the voxels are rendered 1. You're really good at explaing things 2. You have a really nice voice

[@dami4823]

your devlogs make me want to work with vulkan again, thanks 😌 you are doing a very good job by the way 👌

[@voxelbee]

Thank you so much

[@excitedbox5705]

Very interesting. I think the reason this works is because the cache is small, otherwise if you don't turn around you would get voxels at the center of your cache that don't get rendered for a long time and also don't get moved. Since the cache is small most of the cache is probably used rendering what is on screen. If you add a small bit of momentum to the player's movement you can use predictive rendering. Any direction change will take a split second as the character has to slow / change direction and this time can be used to start rendering what is expected to be in the new heading. Ie. when player pushes left button the engine can start rendering what is to the left but the camera doesn't start moving left right away. This method was used a lot back in the day and works for most games except FPS where it can feel like input lag. In a physics based world it is normal though to have momentum and as long as it is kept small this can buy you a few ms as a buffer.

[@voxelbee]

Thanks! Camera interpolation and other techniques to get rid of the loading is something I am going to explore...

[@bangjey5439]

Yo, got recommended by youtube and straight up subscribing! This is amazing!

[@WhoCarrot]

I've just found your videos and I really instantly binged them all. I love how informative they are and how you're able to explain such complex algorithms in understandable and simple languages. Something I would really like is if you could show small code snippets and going through them explaining what they do. This way I might be able to better understand how an algorithm works in order to use it myself at a later point in time. Keep up the work, I think (and hope) your channel will blow up in the near future!

[@Lucas-gg9yb]

What you're working is the Future of gaming, keep working, because the Future is big for this

[@woahbus]

I wonder how such a simple and efficient rendering method wasn't found sooner, good work man!

[@pawwilon]

compute and data oriented programming is still a very young area of programming, with largely unexplored capabilities

[@Vickett20]

Really cool project, looking forward to seeing where you'll end up taking it

[@brettkruskie]

First video I've ever saw. I've always loved voxels and the use. I firmly believe they could be next gen. Thank you for sharing this feat

[@GeorgiKrastevMusic]

This looks like an insane city from Blame!

[@unusualfabrication9937]

you are incredibly talented, fitting a trillion voxels into a megabyte?! this is next level. so excited to see more

[@voxelbee]

Haha well it is using a caching system! So not all the voxels are always loaded but it looks like they are!

[@JeromyReimer]

It's not possible for a trillion voxels to fit into one megabyte. Each voxel would have to be less than a bit, but he didn't say he was storing a trillion voxels in the 1mb cache. I'm not 100% sure, but I think what he was saying is that the render came from a trillion voxels. Not all voxels are loaded, rather some form of LOD is used.

[@olie304]

You are making KZbin's compression algorithm cry!

[@mrjean9376]

Holly! What a great efficiency! I love to watch more of compression and performance optimization in the future again! Subs 👍

[@MaximusMuleti]

That's a super amazing feat getting that to run on 1mb of video memory, good job!!

[@Kiomoh]

this is Minecraft 2?

[@streeterville773]

This entire project is fascinating. I can't wait to see what comes of this.

[@MrPointness]

Awesome work!! I am looking forward to the next blog!

[@ThibsWorkshop]

Just randomly found you, what kind of black magic this is? I'm impressed this is the most optimized voxel engine I've ever seen

[@icyleamon]

I have no idea what is happening, but I can imaging a few cool concepts with this system. Cant wait to see the game design part!

[@rossaylen7441]

This is so sick, going to be interesting to see some terrain built in this engine

[@haraldlindohf4032]

Very impressive! I randomly got this recommended, so I haven't watched the previous parts, but if you render the voxels slightly outside of the viewport, you could probably get rid of those edge artifacts without having to increase the cashe size a lot.

[@voxelbee]

Thanks! Yeah expanding the view of the camera would probably get rid of a lot of those problems!

[@NathanNahrung]

Very cool... I was thinking it would be interesting if at the smallest level color was dependent on structure (analogous to how a butterfly's wing gets its color), so you only need to record solid or non-solid but the number of solid faces adjoining influences the hue. That might save some memory and give a unique mesmerizing view. It would be necessary to count adjoining faces on at least 2 dimensions or cells in at least 3 dimensions and then combine the colors. Using primes for RGB could work so 2 is blue, 3 is green, and 5 is red, while leaving 7 for clear and 1 (and higher primes like 11 and 13) for black. By this logic a 6x5 flat face would be white because it can be decomposed into the first 3 primes, but so can 2x15 and 3x10 faces. The highest practical co-prime would be 35 (5x7) so I wouldn't test for color above 64x64 for processing, so just default to grey above that. It might even be possible to make this process procedural for recursion.

[@voxelbee]

Wow! That's a very cool idea I like it! I'm going to be exploring different generation methods to get procedural views and this sounds like a cool idea to try...

[@NathanNahrung]

@@voxelbee Awesome! I feel I should mention a slight variation which would probably be easier to implement, more controllable, and be computationally less expensive... Test for the thickness/depth of a face as that would be just a 1D query (at the cost of color space)... As an example, and using the previously mentioned primes to colors key, imagine a 4x3x5 block. The 3x4 faces are red (because depth is 5), the 4x5 faces are green because (because depth is 3), and the 3x5 faces are blue (because depth is 2x2). Now imagine the same block but hollow with a wall thickness of 1. Around the edges the colors would be identical, but the middle area of all faces would be black. It could kind of reveal internal structure of things but if cleverly used could be used to introduce a small palette of arbitrary colors to a surface artistically... Best of luck with whatever you choose to do! (also, for the record, I claim no ownership for these ideas)

[@thehonestdude1067]

thats really impressive, looking forward to see more stuff :DD

[@rmoretto]

Wow, this is amazing! The cache system idea is really simple and elegant. One question, could you point out some resources that you used to learn the Vulkan API? Again, amazing work, looking forward to see more of it!

[@voxelbee]

Thanks so much! I'm gonna post a video about how I learnt about all this but one thing that was useful was vulkan-tutorial.com/ you should check that's out!

[@hondwelt]

Such talent has to be supported with more subs! I wish you all the best!

[@imjustpassingby5058]

I understand the concept now. And I conclusion an ideal. For example, you are in Minecraft world and right below you it's a stone block and you stand in a dirt block. The game basically will not render it. But if you destroy that dirt block it's will transfer and optimize a dirt block to your inventory and left it aside (it's just an example so of course, I know Minecraft doesn't work like that xD). It's will help a ton of memories and keep the resource more stable. But in that video, in the mentioned it still has a lot of problems. But he came up with brilliant idea.

[@danieloliveira9815]

Awesome progress! A suggetion I would make is to add some sort of smoothening to the trasition that occurs on the edges of the viewport when you move the camera around. A simple 2D mask (like you did with that green effect on previous videos) would already improve it a lot, in my opinion :)

[@voxelbee]

Thank you! :) Yeah I am going to improve the transition at the edges of the camera in later versions!

[@waliullahmetroid1338]

This is actually very impressive.

[@onerimeuse]

This is honestly brilliant mate. Well done!

[@panjak323]

I would call this: Sponge humps a Mandelbrot set Seriously this is so freaking cool!

[@typicalhog]

Have you thought about extrapolating camera movement to make pop-in less noticeable? I think you should experiment with that when you get the meat done.

[@voxelbee]

Yeah that Is one of the goals once I have the whole caching setup I need to the optimise the loading and remove all the poping. Camera interpolation is definitely a good thing to try!

[@HAWXLEADER]

@@Joorin4711 Doesn't account for camera translation tough.

[@dinkledankle]

@@HAWXLEADER How so? I'm just a pleb, so it'd seem to me that: If the renderer is rendering a 10x10 area in front of the camera, and we are only able to see a 6x6 area in the middle, there would be a 10x2 area around what we can't see that is still being rendered, as a 'buffer zone' for pop-in. The scene is still being rendered outside the viewable area, and since there is a 'buffer zone' the renderer would be able to 'account' for camera translation. Instead of rendering the entire scene or only what's viewable, it'd render only what's viewable and then a little extra. Surely with enough being rendered just outside the camera's view, that'd eliminate pop-in? Like I said, I don't know what I'm talking about. Just going off uninformed experience. Extrapolating camera movement might be superior to something like that, though it would be interesting to see what'd happen 🤷‍♂️

[@HAWXLEADER]

@@dinkledankle Occlusion would still cause pop in. Besides, You don't have to render more, just cache more than you see.

[@iestynne]

Unreal engine has the same issue (when occlusion culling is enabled), so you're in good company ;)

[@AskelDev]

This is one of the coolest things I've ever seen. Keep up the great work!

[@muuuuuud]

Good ideas, can't wait to see where you take them ^^

[@chetana9802]

@bluedrake needs to check this out would be cool for your future in game dev

[@aristofanisrontogiannis5569]

This will prolly get buried, but you can speed up the cache by using a balanced binary search tree augmented with order statistics. Currently moving a voxel from somewhere in the middle of the cache to the beginning when it is rendered should take O(N) time, you can turn that O(N) into a O(log N) by turning the cache array into a cache treap.

[@voxelbee]

Yeah that is an interesting suggestion but algorithms like this are difficult to run in parallel on the GPU. I maybe should look into that a bit more...

[@guilhemane]

KZbin compression did this one dirty

[@kianbautista1016]

I’ll be “borrowing” this idea mate thanks!

[@hardwareful]

pausing the cache blew my mind

[@btarg1]

I'd like to see this implemented in a game similar to Teardown where you have a world made of many very small voxels. This is a really cool project!

[@FoehnG]

Wow.... I just stumbled onto this and I can't wait to see where it'll go in the future. Makes me wanna make games out of it. Though I wouldn't know how. I'm barely hanging on with Python so C++, I'd be lost x)

[@user-uk9er5vw4c]

this is very interesting. I'm not into Voxels, but I'm working in some custom/compute shaders and I want to try your cache system

[@privateparty4900]

Now expand what's being loaded beyond what is visible so as you pan around, you are less likely to all the pop-in as you look around.

[@carlosmspk]

I have no idea how these things work, but it seems easy to do simply by increasing the angle used in the GPU that it assumes the camera is viewing. So if you have a FOV of 90º, the GPU could render the equivalent of, say, 110º even though 20º aren't actually being seen on-screen. Of course, you're relying on the person controlling the camera not doing a full 180º turn, but it seems like it would work rather well at the cost of increasing what gets rendered.

[@TheFlynCow]

@@carlosmspk Scaling the view frustum wont work. As you can see in the video, occlusions also cause pop-ins.

[@carlosmspk]

@@TheFlynCow hah, damn, forgot about those

[@MateHomolya]

This is a great suggestion. This is especially efficient if you can anticipate the movement of the camera given the current angular velocity.

[@ttamttam1522]

Looks neat, wondering if you can shrink the performance overhead of walking the array every time you add to the cache. Maybe a circular buffer? That has its own problems though. Maybe you walk the array as you search, that way you already have space up front for the new object. I would be tempted to cache chunks and store them at fixed points in memory, relative to camera location/orientation, and just load the whole chunk when you need a voxel within it, that way you don't have to walk so many tiny voxels up and down the array.

[@voxelbee]

Thanks! It is actually implemented in a circular buffer so there isn't much array shifting going on within the array itself. I am looking into storing chunks of voxels too that might be useful!

[@exsolutusdev5118]

@@voxelbee How do you perform that "move to front" operation on a circular buffer? Swapping with the last element and incrementing the head would suddenly move the formerly last element further up the buffer (as in, the former position of the element being moved to the front). Is there another way, or is this not a problem?

[@Lebensgott]

this game engine looks really nice

[@SLPCaires]

So cool. Love anything voxel related. its the future!

[@ThunderDraws]

so are you actually shifting all the memory one voxel over to the "left" when you put append the recently used voxel to the "right"? I can't imagine that you actually do that, it would probably be inefficient right?

[@voxelbee]

Well I'm using a circular buffer so it doesn't actually require shifting the whole array!

[@iestynne]

I love circular buffers! This is a great use case :) So if you update the array in oldest to newest order, then the voxels that are rendered this frame will remain in the same order relative to each other, which is great. Exactly what you want. But it seems like the non-rendered voxels can get shuffled around relative to each other... so then the slots that get overwritten first with new voxels won't necessarily contain the 'oldest' voxels that you would prefer to discard first. Do you have a way of avoiding this, or do you find it doesn't affect performance too much? Very interesting video series btw, thanks for posting!

[@skaruts]

@@voxelbee so I guess that means one voxel is unloaded while you're rendering another voxel. No need for taking some time out to clear unused voxels.

[@lapissea1190]

This is some really cool tech you got going on there! I recently got in to gpu compute stuff and now I kinda wanna copy your idea. ^^ Got 3 questions for you. 1. Did you take any concepts from other voxel tech like OpenVDB or is your spatial tree completely purpose built concept? 2. Have you thought of how much versatility you want for this engine? For example, do you plan to support many volumes to be rendered at once in order to create a sort of a volume as object concept that many other voxel engines do (eg Teardown) and how would you approach things like bullet physics for such complex structures? 3. Are you concerned about the performance of the rendering as you do not have the convenience to rasterize almost everything then spice it up with fancy methods like raytracing?

[@voxelbee]

Thanks for watching! My tree is a pointer based octree I have customized the data structure for my needs but it's similar to what Gigavoxels have done. I think I need to experiment with having multiple volumes being rendered it's definitely something i'm exploring! Performance is one of my main concerns but at the moment it is quite performant. Just as more things are added they need to be optimised to work well

[@lapissea1190]

​@@voxelbee OOh nice! I was looking in to gigavoxel before but never got around to really exploring how it is doing things as I got way too distracted with openvdb (and now nanovdb) I asked about performance because I fear your current building blocks might not function as intended and it might be worth planning in advance for things like this. For example if you wish to create shadows from a sun or point lamp then you will put much much more strain on your "recent voxel accessed" cache system. (what is incredibly cool btw) Or if you wish to embed extra data in to the volume (such as material index or on the fly baked values like AO, GI etc...) then it will need to be able to work with less voxels on the same memory budget and even more reads and writes. It would suck to see the repeat of what I was doing in my game engines. What I was doing was basically, I think of a concept and really polish it to what i'm using at the moment. Then later I find myself needing to heavily modify it or completely rewrite as I was way too optimistic when thinking about the scope it would be used in. Best real example would probably be: At one point I had this really cool system of optimizing mesh data by generating many vertex indices based on how close you were to the model. (almost like a way ahead of its time version of Unreal Nanite) It ended up being a HUGE hog on my code base and was barely making things faster because I never considered that I would use it on a model that are bigger than 200 verts. (sounds silly but I barely knew modeling at the time) The worse part was that this was so entangled in the engine that I could not even disable it easily.

[@voxelbee]

@@lapissea1190 Wow! That so cool you made a system like that! But yeah I think the best way to fix this is I need to move onto other parts and keep going so I don't spend to long polishing one part. But it's really fun to polish one part... I can choose when the voxel should be marked as accessed so I think the system should be able to scale to very large accesses pretty well! But I agree that I need to move forward so that I can actually find out if it works as I want... Don't want to talk to soon then it doesn't work... Thanks so much for the feedback too! :)

[@ticiusarakan]

this is ingenious!!! keep going, dude!

[@Speiger]

I know this is late maybe you dont see this. But i think i have a better system for you that does not constantly require you to shift arrays around. What you could do is instead of using a arraylist you could use a HashMap (or Dictionary or orderedMap) that uses 2 arrays a key array and a value array. And for iteration you use a long[] where the first 32 bits are the previous index and the second 32 bits are the next index and the arrayIndex is self (so you get key value & next & previous with the same value) that way if you want to move indexes around you just need to adjust the bits of the long[] instead of arrayshifting the arraylist itself. Very little movement and also very fast iteration speed, and when adding a new entry you just put it in the first position, and when clearing the overflow you just remove the last indexes. shifting the entire array by changing effectivly 3 values. (Discarded, First and new). if you want a implementation example: github.com/vigna/fastutil Yes it is a different coding language but its insanely fast vs an arraylist approach and has very little data modification.

[@voxelbee]

Yeah I think this is quite an interesting idea I am currently working on upgrading the data structures it's just it's quite difficult to implement a lot of these complex structures on the GPU. However, this might be of use on the CPU! I'm definitely going to look into this!

[@ZeroPlayerGame]

...isn't that just a doubly-linked list with extra steps?

[@ahdog8]

@@ZeroPlayerGame not a data structures expert, but I think that linked lists have slow random access. i.e., if you want to look at the 24759th element in a linked list, you might have to look at the first 24758 elements. This proposal could be faster than a linked list. EDIT: In another comment, voxelbee says he is using a "circular buffer." Not sure exactly what that is but it sounds like it would solve array shifting problems!

[@AndrewRedW]

Voxelbee is using ring buffer array. When inserting new element you decrement your tail (example if tail was pointing to 6, now its pointing to 5th element of the array), then you increment the head and insert this new element to the array with head index. When you are inserting recently rendered element to the front from the middle of the ring buffer array, you increment the head (if the array is always full, the you'll probably have to save the element with tail index, since the head now has index of the tail) place your voxel from the middle into array with new head index, then you place voxel from the original element with tail index to the place where rendered voxel was. This is only 1 array + two values (head index, tail index). I dont think you can make a simpler implementation of cache than this.

[@joaoalonso6942]

This is a really nice trick :-)

[@RoadsideCookie]

I'm your refactor, you could explore doubly linked lists which could possibly offer a performance boost when manipulating the list, and see how much, if at all, it affects rendering performance.

[@JackTheOrangePumpkin]

Hey mate. I am eagerly awaiting the next devlog. This project is just too interesting. Any chances that you will upload in the next couple of days? Anyways keep it up, much love :)

[@voxelbee]

Thanks so much! Just posted a video about why i'm making this engine! A devlog update will be on the way in a few weeks!

[@anerdwillhackit]

Very nice work! Thank you for sharing.

[@davids91nk]

This is amazing stuff! Thank you for the inspiration!

[@thesilverspanch]

This is amazing! keep it up man, this is going to be awesome.

[@Hobbitstomper]

You know those planet and star size comparison videos, you could do that in real time with your voxel engine.

[@2dozen22s]

Super impressive work, and (If I read the log right) this is running smoothly on a 555X? Jeez you'll have some headroom for some wicked stuff. Looking forward to how physics will be handled.

[@voxelbee]

Thanks so much! Yeah it is currently running on a 555X! haha

[@Waffle4569]

2:17 How do voxels get "moved up to the front of the array"? You need space for them to land, and you don't want to re-copy the array every time a voxel is moved. You could swap voxels in the array, but then a recently rendered voxel could get swapped straight to the back of the array and get overwritten too quickly.

[@Lluc3D]

this looks promising

[@eugenevarbanets3898]

imagine a collaboration between voxel devs on YT

[@cameronl2760]

this is so cool! when you explain the buffer I'm reminded of a circular buffer. maybe it would remove the need to shift things around when the cache is being written to, and instead be managed using rotating offset indexes?

[@voxelbee]

Yeah it is actually a circular buffer so that it just shifts the front and back instead of all the memory

[@theohallenius8882]

That looks pretty performant. You should also look into perfect spacial hashing as a way to efficiently pack large sparse voxels in tiny sized textures. It's also very gpu friendly (for unpacking).

[@iestynne]

I love that algorithm! Unfortunately it has two big downsides that wouldn't be acceptable for this project... 1. you can't add/remove voxels quickly (ie no voxel editing by the player; static worlds only) 2. you can't query whether a given XYZ location is empty or full (ie no visibility or collision queries)

[@robinmattheussen2395]

Wouldn't making the cache as huge as you suggested ("several gigabytes") make things extremely slow? Moving a voxel takes O(N). If you're moving one from, say, the middle of the array (because it hasn't been accessed for a while) it's going to be quite slow with such a massive array. Or am I missing something?

[@Pockeywn]

yeah i think thats the weird popping were seeing

[@intingido9751]

would love to try your voxel game engine as soon as it's ready to be used

[@mineland8220]

Finally a game that i can run with 3gb of ram

[@specialgorilla]

Yo this is actually sick as hell kinda wanna try making something like this myself

[@artiartem]

Good luck!

[@voxelbee]

Thanks!

[@MateHomolya]

This is going to get even more interesting once you add cellular automata rules that evolve on their own. The best way to introduce a time component to this system is at the voxel level directly in the octree, represented by a one dimensional array in memory. Fractals are a good step in that direction, and from there it's easy to imagine all the different emergent phenomena that you will be able to observe at universe-scale with this game engine.

[@Cyberfoxxy]

RIP KZbin compression.

[@elwinactually7336]

Very impressive! You just gained a sub

[@letmesinup]

What your doing here is amazing.

[@vladosononame6376]

Super cool, instead design outside, design inside

[@jameswoodhouse8156]

Looking forward to it :)

[@voxelbee]

Yes bro!

[@joshshuter7536]

love from the UK!

[@voxelbee]

Represent! 🇬🇧😂

[@KrutoiPersonazh]

🇺🇦

[@sdziscool]

Yo, I was wondering if you used a circular buffer for your movements in cache? If not that might be something to look into as it would save a lot of moving cache values about.

[@voxelbee]

Yeah it is actually using that right now!

[@sdziscool]

@@voxelbee Nice, love me some optimal data structures!

[@Phiwipuss]

Kind reminder: Fractals

[@johnstifter]

Do you think you would be able to create a 3D cellular automata in this voxel game ... or would that be too complex? there are a lot of different rules and it would be interesting to see it running even if it's just confined to some bounding box. Great work

[@voxelbee]

I'm very interested in looking into cellular automata for the engine. I think it's doable!

[@johnstifter]

@@voxelbee This also reminded me of transitive percolation in Percolation theory, there may be a way to encode information into the index of each voxel and in doing so may give you a further memory advantage

[@david2618]

Those voxels, in game design, have a size way smaller than what is deemed insignificant, this is a good sign as it means that in a game environment the player would be able to see very far away.

[@typicalhog]

Moving (shifting) items in an array seems slow. How did you do it?

[@voxelbee]

What's really going on is more of a circular buffer so the front index moves most frequently. However, voxels do get swapped to the front of the array which is where the circular index currently is. Then you increment that index. That means we don't have to rearrange every element in the array as often making it fast.

[@typicalhog]

@@voxelbee Interesting!

[@SETHthegodofchaos]

@@voxelbee Was just about to ask if you used some sort of ring buffer for this :D

[@ServantKing72]

Have you got in touch with Miguel at Voxel Farm, I;m sure the two of you could revolutionize the voxel industry!

[@voxelbee]

I've seen some of his videos very cool stuff!

[@Steve-jy1vd]

I'd love to see your array handling algorithm. Would be extremely useful in other applications. I.E. packet analysis cache (especially if implemented on the NIC during capture)

[@Zeekblitz]

Keep up the good work!

[@voxelbee]

Thanks bro!

[@DanieIMonteiro]

How do you handle moving all the entries in the array? Considering youre moving i.e. pos. 200 to pos 1, you need to move 199 entries by one spot, which normal arrays do not support?

[@voxelbee]

Yeah well I'm actually using a circular buffer to move things to the front of the array!

[@DanieIMonteiro]

@@voxelbee Ah interesting, so that handles the replacement of the last element for you. I guess that still leaves the moving of the complete buffer by hand? moving the start pointer would break the chain of newest rendered

[@DanieIMonteiro]

@@Joorin4711 ah yes, makes perfect sense, but that would also mean that in some cases (i.e. A is, lets say, 3rd last position), that it would then be copied to the new start, and then be in the cache twice?