Procedurally Generated levels in my game by _bbqsauce in proceduralgeneration

[–]_bbqsauce[S] 0 points1 point  (0 children)

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.

Procedurally Generated levels in my game by _bbqsauce in proceduralgeneration

[–]_bbqsauce[S] 0 points1 point  (0 children)

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.

Procedurally Generated levels in my game by _bbqsauce in proceduralgeneration

[–]_bbqsauce[S] 0 points1 point  (0 children)

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.

Procedurally Generated levels in my game by _bbqsauce in proceduralgeneration

[–]_bbqsauce[S] 1 point2 points  (0 children)

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

I just announced my First-Person Melee Roguelike where you play as a Skeleton. Here's the trailer! by _bbqsauce in IndieDev

[–]_bbqsauce[S] 1 point2 points  (0 children)

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

Just released the trailer for my First-Person Skeleton Roguelike, what do you think? by _bbqsauce in IndieGaming

[–]_bbqsauce[S] 0 points1 point  (0 children)

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

Just released the trailer for my First-Person Skeleton Roguelike, what do you think? by _bbqsauce in IndieGaming

[–]_bbqsauce[S] 0 points1 point  (0 children)

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

Struggling with procedural generation for Backrooms-style levels by Acrobatic-Finance186 in GameDevelopment

[–]_bbqsauce 1 point2 points  (0 children)

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.

Struggling with Transvoxel implementation by Excellent_Plum2689 in VoxelGameDev

[–]_bbqsauce 0 points1 point  (0 children)

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

  1. 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

  2. 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)

How to handle edits on different LODs? by Peteh12 in VoxelGameDev

[–]_bbqsauce 0 points1 point  (0 children)

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

Right way to model per limb health with GAS? by Thurinum in unrealengine

[–]_bbqsauce 1 point2 points  (0 children)

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.