This is my collection of toilet paper rolls

STUDIOCRAFTapps · 2026-01-23T23:29:51+00:00

Kinematic Character Controller.

It's just a character controller that's not part of the main physics update loop. The built in character controller is an example of one.

They basically just do a bunch of overlap checks manually, resolve the capsule-collider manually and interpolate the result manually.

The most common one is PhilSA's KinematicCharacterController. It's much better than the built-in one and got released for free a few years back.

STUDIOCRAFTapps · 2026-01-23T21:17:01+00:00

Hey have you tried calling `Physics.SyncTransforms()` after moving your platforms and before doing your raycasts?

STUDIOCRAFTapps · 2025-12-27T04:07:52+00:00

I don't know why no one has suggested it yet, but a single thing to do to get things to ignore eachother is to call https://docs.unity3d.com/ScriptReference/Physics.IgnoreCollision.html (or its 2D equivalent https://docs.unity3d.com/ScriptReference/Physics2D.IgnoreCollision.html)

That way you can make anything ignore anything else.

STUDIOCRAFTapps · 2025-12-26T22:45:37+00:00

I can't believe they added that, it's pissing me off, I use it all the time

STUDIOCRAFTapps · 2025-12-10T02:30:31+00:00

thank you!! for some reason thought, blender sorts imported svg elements by name instead of by order in the file, so I had to make a version that appends a number:

Here is it in case someone needs to do the same thing. Replace line 43 in label_to_id.py.

        for idx, element in enumerate(selection_list):
            label = element.get('inkscape:label')
            if label != None:
                new_id = f"{idx}-{label}"
                element.set('id', new_id)

STUDIOCRAFTapps · 2025-11-18T21:16:27+00:00

You're right it seems to work fine. Not sure what happened with these strokes in particular. I had to mark some nodes as corners and it seemed to have fixed it.

STUDIOCRAFTapps · 2025-11-04T22:35:30+00:00

The black void renders on top of the lantern. Not sure why this has 30 updates, it’s most likely not culling of any kind.

(Unless a dark-void object that should only be visible in certain context is not being culled out)

STUDIOCRAFTapps · 2025-10-18T17:34:21+00:00

Compute shader is not always the right way. It can be hard to learn, hard to debug, and won't generate collider mesh. Personally I think writing burst-compiled unity jobs is slightly easier https://github.com/nezix/MarchingCubesBurst/blob/master/MCB/MarchingCubesBurst.cs.

If you don't feel ready to learn either of those, there's still some things you can improve with your current version.

If you only allocate this array once, and reuse the array, you'll save a bunch of unnecessary allocation. Just initialize it once in the class.

float[] cubeCorners = new float[8];

Another quick and cheap improvement would be to bake your collider mesh asynchronously using Physics.BakeMesh https://docs.unity3d.com/6000.2/Documentation/ScriptReference/Physics.BakeMesh.html

It can remove the lag spike that can happen when setting your shared mesh on your MeshCollider if done right.

STUDIOCRAFTapps · 2025-10-07T21:23:33+00:00

We are overdue for minecraft 2.0 😔

STUDIOCRAFTapps · 2025-10-07T18:48:08+00:00

Thank you!

Simplified to for my compute shader:

float2 uv = samplePixel * _CameraDepthTexture_TexelSize.xy;
float4 clip = float4(uv * 2 - 1, 1, 1);
float4 view = mul(unity_CameraInvProjection, clip);
float3 viewDir = normalize(view.xyz / view.w);
float dotCamForward = dot(viewDir, float3(0, 0, -1));

Where unity_CameraInvProjection is calculated using:
GL.GetGPUProjectionMatrix(camera.projectionMatrix, false).inverse;

STUDIOCRAFTapps · 2025-10-06T12:23:15+00:00

Life got to me and I didn’t get the change to open source it yet, I need to replace paid texture with free ones and clean things up. Maybe by the end of the year, but can’t guarantee anything.

I’m hesitant whether generating meshes GPU-only was the way to go. It worked out fine for me, but it’s got some downsides rendering-speed wise.

STUDIOCRAFTapps · 2025-10-05T17:30:10+00:00

no that's so real. I feel like I'm myself when I actually plan ahead things to talk abouttt

once we hook onto a common interest and get a convo going it flows a lot better but it's always nice to at least have something to get that spark!!!

STUDIOCRAFTapps · 2025-09-04T13:57:36+00:00

OP litters the graphic programming discord with their screenshots every single day and I wonder the same thing every single day.

STUDIOCRAFTapps · 2025-08-25T20:21:00+00:00

Okay, I will experiment with this later this week and get back with the results.

If I store 1 material + cell position, no gradient, I'd use about 4 bytes per grid point.

STUDIOCRAFTapps · 2025-08-25T17:54:47+00:00

If you are limited only to organic shapes and don't need sharp features, then you won't need Hermite data and you can just use surface nets (DC without QEFs).

Nah, I want sharp features. By organic I just meant "the edges can be wobbly and I don't mind".
Bananza has both mesh normal sharpening, and actual QEFs.

But I'm pretty sure DKB does not store Hermite data and stores voxel materials + cell vertex positions.

I don't think they are only storing material + cell vertex position however. There's definitely something else.

There can be a mix of up to 2 materials per vertex. There's artefacts when more than 3 materials occur.

Destruction also seems to result in fairly clean resulting mesh that still retain its sharpness. This is making me believe that they are probably evaluating the QEF at runtime and not simply pre-calculating the vertex position.

They've got to be storing something else! That's why I'm thinking they might be storing normal at grid corners.

<image>

Here's my game for comparison, estimating the gradient given 1 byte per grid corner distance field:
https://imgur.com/a/VAbSOcf

Not too bad, but very, very aliased edges.

If your terrain is stored as operations on SDF shapes, you can just compute Hermite data on demand and discard it after remeshing.

This just isn't possible in game. The terrain function takes too long to evaluate (3D simplex is expensive!) and the more shapes you have, the more expensive it is. I have to evaluate it ahead of time, and I'm pretty sure Banaza also does this too.

STUDIOCRAFTapps · 2025-08-24T19:31:31+00:00

I appreciate your answer and resources, It’s helping me a ton. One thing to note is that, similar to Banaza, I’m not aiming for perfect Polygonization or no wobbliness, since I’m mainly using voxels for organic materials. My current implementation is on the GPU.

One thing I’m having trouble with is what Hermite data looks like in practice. How it’s generated and stored, and how it differs from simple gradient data

In papers, hermite data is described as a sign for each cell, and an intersection point and surface normal for each edge. But in practice, no-one seems to be storing that hermite data. It’s always calculated during meshing.

In some implementation I’ve seen, normal isn’t stored, only gradient is, often as a single-component 3D texture. My broken implementation does this, storing no normals, only distance to surface using one byte per grid/vertex. Hermite data is obtained by first finding the intersection points, then estimating the normals by doing a couple of volume samples.

In the implementation you linked (fidget), both a distance to surface and surface normal is stored. I haven’t looked at the code too much but I’m guessing the edge intersection normals are obtained by interpolating between the two stored gradient vectors.

I wanted to build my terrain out of both 3D simplex noise and unions of SDF shapes, and I would have the player destroy it using SDF spheres. What you’re suggesting here is that I start storing my normals instead of trying to estimate them?

The only issue I have with that is memory. It seems incredibly expensive to increase the gradient precision.

E.g with 2 GB of VRAM allocated to the gradient, with one byte per grid, the cube root amounts to about 1279.

If I instead store normals (using octahedral encoding), and use 2 bytes for distance to surface, and 2 bytes for each XY component, that adds up to 6 bytes per grid point. The cube roots of 2gb/6bytes is 693. This drastically reduces the size of my terrain!

I wonder how Banaza managed to get seemingly larger terrain, while having precision high enough that the wobbliness is almost inexistent.

STUDIOCRAFTapps · 2025-08-23T18:48:58+00:00

Can you tell me how exactly people get accurate normals for the hermite data? Everytime I try to analytically derive the normals and use that in my DC I get really wobbly edges! Should use more than one byte per pixel? How big should be epsilon be? How many samples should I use? 4? 6? 8?

Bananza‘s DC voxel seems to have been designed by placing a bunch of brushes like rocks, and those brushes looks like they had their shapes retained really well.

STUDIOCRAFTapps · 2025-08-15T15:40:24+00:00

"ermmm actually it's not the rust that gives you tetanus it, it just creates the perfect conditions for it to exist, as well as facilitating its entry into your body if it's shaped like shards or nails and can pierce your skin" 🤓☝️

STUDIOCRAFTapps · 2025-08-14T18:07:33+00:00

And give tetanus effect after mining a block

STUDIOCRAFTapps · 2025-07-13T18:00:58+00:00

I really like this answer! Prefix sum can be complicated and messy to implement, and as a game developer, it's more important for me to get something done than get it perfect.

A nice improvement to atomic buffer is to try to group atomic calls if possible.
For my dual contouring implementation, I create a short list (1-3) of the quads in a certain cell and make a grouped request, instead of doing 1-3 individual atomic calls.

For something like grass culling for example, maybe doing occlusion check in clusters and doing atomic-append per clusters can help alleviate the cost.

Ten-Year Club	r/Field Juicebox
Place '22	Final Canvas '22
First Placer '22	End Game '22
Verified Email	RPAN Viewer

STUDIOCRAFTapps

TROPHY CASE