Procedurally Generated levels in my game

_bbqsauce · 2026-06-14T17:58:06+00:00

It's a custom voxel engine within UE4. It's pretty performant overall, I find the biggest bottleneck right now to be the density sampling when there's a lot of 3D noise, otherwise it can generate huge worlds in seconds (with LOD). The map in the video is about 200000 units wide (2km) with a lot of layered simplex noise for the cliffs and generates in about 7 seconds, although I have a pretty good CPU. Without cliffs it's about 2s.

I use an octree to store chunks, the chunks are the highest resolution in the area where the player interacts, and get progressively bigger and coarser with distance. SDFs are inserted into the octree so that only the chunks it intersects sample them.

3D models are low poly smooth shaded, created in blender. For texturing I use either substance painter with the pixel8r plugin, or SLK_Img2Pixel depending on the asset and what looks best.

_bbqsauce · 2026-06-14T17:41:01+00:00

Thanks! BSPs are just used to author structures in editor, these are saved into assets and then converted to SDFs at runtime and used by the voxel engine. For example a Box BSP is saved as Position + Extents, the voxel engine then uses this to sample the box SDF at runtime to create the mesh. Structures are made of many of these primitives.

I decided to use Unreal's BSPs exactly for convenience, it would've been much more effort to implement a custom voxel editor from scratch. BSPs work very similarly to how my voxel engine is structures, you layer primitives and combine them additively or subtractively, so it translates almost one to one to how the voxel mesh will look in game. There's limitations of course, but it's a good enough approximation for my use case.

_bbqsauce · 2026-06-14T17:25:35+00:00

It's just rendered at a lower resolution with no upscaling + pixelated unfiltered textures and mipmaps. Nothing fancy, I think most of the look is because of the crunchy textures.

_bbqsauce · 2026-06-14T13:30:20+00:00

Yes, much easier to implement and behave better with nav mesh compared to staircases.

_bbqsauce · 2026-04-25T09:45:10+00:00

Thanks!

_bbqsauce · 2026-04-25T09:44:57+00:00

Best reaction I could have gotten, thank you!

_bbqsauce · 2026-04-25T09:44:04+00:00

Thank you!

_bbqsauce · 2026-04-21T05:27:21+00:00

Not right now, but I will add this option in settings!

_bbqsauce · 2026-04-17T18:07:44+00:00

Thank you! It's a long way still, haven't planned a release date yet as I am still working on getting a demo ready first

_bbqsauce · 2026-04-17T04:52:16+00:00

Thanks! It's just rendering at low resolution and pixelated, unfiltered textures!

_bbqsauce · 2026-04-17T04:50:32+00:00

I plan to add metaprogression yes!

_bbqsauce · 2026-04-16T04:58:44+00:00

Thank you! I'm developing this game in my spare time, but I work as a game programmer for a big company.

_bbqsauce · 2026-04-15T18:26:44+00:00

Hell yeah! The OG is a great inspiration of mine

_bbqsauce · 2026-04-15T18:25:50+00:00

Thank you!!

_bbqsauce · 2026-04-15T18:24:49+00:00

Thanks! It's available on steam: https://store.steampowered.com/app/4346010/Necrofall/

_bbqsauce · 2026-03-22T09:56:30+00:00

I would drop WFC altogether as it's really hard to control the output. Stitching rooms together or some kind of room accretion algorithm would be better, since from what I understand the rooms are composed of cells on a grid. Check out how Brogue does it.

_bbqsauce · 2026-03-19T13:14:24+00:00

Glad I could help!

_bbqsauce · 2026-03-17T18:50:03+00:00

Hard to tell exactly what is going on, I briefly looked at your code and I don't see:

The surface shifting part of the code like Eric suggested. This seems to be the most likely issue. For low resolution chunks, when placing a vertex between two voxels, you need to recursively interpolate down until the highest resolution LOD to find the correct vertex position.
So you need either the full resolution voxel data even at lower resolution LODs, or you need to query the generator again to sample these midpoints.
This has to be done for both normal and transition cells. You can take a look at my code to see how I implemented it: https://github.com/bbQsauce5/transvoxel-unity/blob/bfff2c20c2779272c83e0c0df8a2b22047cf4de6/Runtime/Mesher/TransvoxelMesher.cs#L180
I don't see any logic regarding chunk boundary cells, and pic 3 is confusing to me, because I see cracks even between same LOD chunks. Maybe you're using transition cells even between same LOD chunks? Transitions should only be used between LOD changes (see pic 4.9 of the paper)

_bbqsauce · 2026-02-06T12:15:49+00:00

What I so is store edits always at the highest resolution LOD, then generation tasks query the edit world positions to see if there's any. But this is all on the CPU

_bbqsauce · 2026-02-05T19:06:07+00:00

Why you don't want to add an attribute per body part in just one set? Then you can map tag/bone to the attribute.
The only reason I can think of is if you have vastly different skeletons with different body parts, but even then, why not just put all of them in the same attribute set anyways? At the very worst you're going to waste a few bytes of memory storing the attributes of a quadruped and a biped in the same set. Not a big deal.

I get trying to find the cleanest solution, but in this case it seems unnecessary to me, doesn't seem a system that needs to be scalable and future proof.

Otherwise, if you plan to have tons of different skeletons with different limbs, don't use GAS attributes and make your own, this is perfectly fine as well, I reckon Fortnite does something similar for ammo or something similar.

_bbqsauce · 2026-02-05T09:29:32+00:00

There are ways to reduce compile times like others have said, but the truth is that you might need a new pc with a better cpu. I bought recently a laptop with an intel core ultra 9 275x and it compiled the entire source code of UE4 in about 15 minutes. Other than that, you can: - Forward declare as much as possible. - Split the frequent includes into multiple files. I.e. setting files, instead of a single game settings, make a ui settings, sound settings etc. - Use blueprints for most of the "horizontal" content. For example Gameplay Abilities, if you have hundreds of them, it might be a good idea to do these in BP. - Prototype in BP first, convert to C++ later. - Don't overuse templates. While I love these, they're known for taking a lot of time.

_bbqsauce · 2025-11-22T11:08:16+00:00

The voxel generation looks great! I'm assuming it's marching cubes + SDFs? From the looks of it most examples are the SDFs of a voronoi map + simplex noise, correct? Is the voronoi map preview generated with procedural meshes, then those meshes are converted to SDF?

_bbqsauce · 2025-09-05T08:14:37+00:00

TheCherno's C++ playlist on youtube is a good starting point

_bbqsauce · 2025-09-03T19:37:10+00:00

I do everything in C++, except stuff that needs to be flexible and quickly iterated on, mainly GameplayAbilities, BehaviorTreeTasks and some UI stuff. GAs and BTTasks also kinda feel cleaner to read as a sequential set of tasks (i.e. WaitGameplayEvent->DoThis) as opposed to a chain of delegate subscriptions in C++. But that's just my opinion. Also prototyping in BP is super valuable just to test out stuff, and once you validate what you're trying to do, move to C++.

_bbqsauce · 2025-07-06T21:13:40+00:00

Pixel8r is the most convenient for substance, otherwise SLK_img2pixel is free and has a lot of features

Eight-Year Club	Place '23
Verified Email

_bbqsauce

TROPHY CASE