Let's show Quadratic some love for supporting rust developers, star their github page! github: github.com/quadratichq/quadratic careers page: github.com/quadratichq/quadratic/
If the tree generation is fast, an alternative way to avoid the chunk boundary problem is to generate the trees of the neighboring chunks as well for the current chunk. This then can be completely parallelized, and has no dependencies on other chunks :).
That is if the tree placement uses noise and the tree generation uses a seed based off its position. I think Tantan may just be using random numbers so it would involve a bit more work to make sure you are generating trees the exact same way in the imaginary surrounding chunks as you are in the actual surrounding chunks. This method may be viable but he should really just recode it to be more like Minecraft, your idea wouldn't work well with large structures that might stretch across 3 or more chunks, now you have to generate structures in the surrounding 3 or more chunks too.
@@quinnbattaglia5189 You can just ignore any tree bits that are outside of your original chunk, since those are the only ones you need to build a mesh for. The other chunks will take care of their own tree meshes.
I did not think it was possible to incorporate Beethoven’s 5th into a coding video and have it fit. You proved me wrong. Seriously though, fantastic video!
Nice video Tantan! I love the visualisations, very pretty. It might interest you to know that there are much faster and cleaner techniques for generating large structures over multiple chunks (including very large structures that cover arbitrary many chunks!). In Veloren we used a modified form of cellular noise plus a terrain noise sample to find altitude when deciding to place trees. It works very effectively and means that generation threads don't need to fight for control over terrain resources, nor do you need a post-generation modification step that can lead to expensive remeshes and superfluous data (and is intractably complex in the general case: what happens for trees with a radius > 1 chunk?). It's also very cheap to precompute structure positions, which is useful if you ever want to add an LoD system :) Although don't fear: the technique you're using is used by other voxel games, including Minecraft I believe. You're not alone in using it :)
Instead of checking the distance from each line for each potential voxel space, why not step through the line and place blocks as you go? You could take the gradient and length of each line, and then in order to step through the line just take the gradient, calculate the point where the line segment leaves the voxel, fill in that voxel and subtract off the length and repeat until you run out of length, then switch the gradient and repeat until the tree is complete. To get the thiccness you desire, you could either use a non-uniform grid where each horizontal cell is 2 blocks wide, or use how far the entry and exit points are from the horizontal borders of the block to place additional voxels outside of the line as required. Sorry if that doesn't make a whole lot of sense, happy to explain in more detail if you're interested
I'm pretty sure noita used a 3x3 checkerboard pattern and staggered their game updates into 9 smaller stages. That way neighboring chunks could always be accessed without contention. It falls apart for any radius greater than one chunk, but is a neat solution regardless.
I think you could turn that tree voxelization thing into O(n), by doing something similar to how you rasterize pixels, but in 3D and for each branch. You couöd start with a 2d version which rasterizes the lines onto a grid, and then make the appropriate changes to go 3D. Rasterization is how, for instance, a line gets converted into pixels on your screen. See Bresenham's line algorithm
I was just starting to complain about not having a new tantan video and BAM, new tantan video. And on a topic that's actually relevant to what I'm developing, perfect
You might already be doing this, but layering noise can make terrain a lot more interesting As well as using a different noise function for some of the layers, one that has sharper peaks I like the monty phython reference :)
Looking really good, great job It reminds me of when I tried to make a system for generating houses at one point, once the inspiration starts flowing there are so many possibilities and it was hard to draw a line where I could say, ok, now it's good enough, haha I also wanted to generate vegetation like trees ferns and stuff in that game but never got that far, so seeing this is really cool :)
i care more for gameplay. its cool to see generators. I wonder how it would be if it was used for gameplay or charecters. like imagine a charector generator that actually made unique skills, moves, gameplay, items. all generated
You should go look at Henrik Kniberg's video on Minecraft's new terrain generation (tldr: use 3 noises, two 2D noises control terrain shaping and 1 2D noise controls terrain height, and they are mapped via a spline chart)
Looks great! pretty awesome so far. I know this is way early to ask but I really enjoy engaging movement & when skills cause movement (to yourself) in fun ways. AAAAAAA now I want to do stuff. aaaaa I feel odd. aa seeya around also. Non very human character options are awesome
Amazing bro, even minecraft couldn't add procedural tree and use a performant code like rust Anyway I suggest to use vulkan rendering api for rendering on the GPU, so it will be even more fast
Did you try positioning the trees so that they are guaranteed to never cross a chunk boundary? If the forests on the map aren't too dense this might still look fine, but I'm not sure.
A better solution would be to come up with tree positions deterministically (in the same way that sampling noise is deterministic). That way, it's fine for trees to overlap chunk borders and you don't need a post-generation chunk modification step either.
How would you place these structures tho? As you can see in the video a lot of the trees are half floating. Need either to make space or find space to place them correctly - I couldn't find a nice solution for this.. :/
A good approach is to find some cheap and approximate way to determine the altitude at arbitrary voxel columns. Often this means resampling the original noise that produced the terrain in the first place.
I had the same problem with structures bleeding into other chunks when I was making my first voxel engine! Realized I had to completely recode things just for structures, and it sounds like you will have to as well. The way you described it made it sound like you don't have the rendering and voxel data separate, you should be loading several chunks beyond what is actually being rendered, meaning many chunks will be "loaded" but not rendered. The amount depends on how large of structures you load in. Apologies if you already know that. One thing I can say for sure is that having each chunk on a separate thread is a horrible idea lol your computer should only have 4-8 threads anyway, so it would be a better idea to offload all chunk gen on one thread, and all mesh gen on another. You should be waiting until you know for sure that a chunk has all of its voxel data before you start generating its mesh.
When I saw Cubeworld, I thought it would have been really cool if the terrain was smoothed instead of just squares. I'm pretty sure there is an algorithm for doing such a thing. Maybe it's something you can consider for your game to make it stand out.
If you mean marching-cubes, that's another beast, and would require Tantan reworking much of his game. Definitely cool, but not right for him at this point in the project.
@@schelney There are more algorithms than Marching Cubes. Naive surface nets is relatively simple to implement (not much more difficult than standard cubic mesh extraction) and gives pretty much the same (or better) results in most cases.
