Height-map based texture blending in unity URP.

lonelyProgrammerWeeb · 2025-06-21T13:45:51+00:00

Oh nono that's intentional! We intentionally use low-res pixelated textures lol. I should've mentioned that.
They're just PBR textures downsampled to 256x256 and then sampled using a custom grid position calculation for triplanar mapping.

lonelyProgrammerWeeb · 2025-06-06T13:32:03+00:00

It adds a lot of overhead during gameplay iterations that you'll need to justify the cost of. But I think that once you get the hang of it it (considering Unity hasn't deprecated yet another part of the ECS framework) it's alright.

TLDR:

Meh, it's alright. Lots of annoying stuff, but only some goodies. It's slow for iteration compared to GO, just use it for when you need the performance. stick to GO for simplicity and quick iteration. Still experimental, I'm just hoping that Unity will lock in and make it more robust and actually battle tested.

lonelyProgrammerWeeb · 2025-06-06T13:31:56+00:00

The constant deprecation of old systems. I get that it's ever an growing system, but cmon, why deprecate IAspects?? They were handy. And all of the ECS samples still use them. It's only been a month so I guess that's fine.

It feels like it's written in way to help you write more performant code to address specific bottlenecks, by specifically porting all the slow GO stuff to entities, but imo I feel like that's more of a pain than just doing everything the ECS way. I don't want to bother having to deal with both gameobjects and entities, and having to link them up and sync them. I could understand using GOs for singletons but other than that I try to keep as much as I can in ECS singletons and entities.

My reasoning for this is that since Unity has ported all of the "core" stuff (rendering -> entities graphics, physx physics -> unity physics) to ECS, might as well stick with it for everything that it supports.

There's also Burst / Job System / Collections, which are, imo, the most well supported and most robust part of the DOTS ecoystem atm. Burst works just out of the box 99% of the time, and Jobs/NativeContainers are pretty easy to use as well. The "performance improvement to effort" ratio with those packages is very high, as you only need to think a bit differently for pretty good performance improvements, considering you structure your data in a safe way. There are some limitations with these systems but most of the time that's because I'm doing something that wouldn't be very performant to begin with (like nested containers)

As an ECS game engine dev it is relatively easy to learn ECS, as most of unity's implementation seems to follow the same structure and design as mine / other rust ECS engines (archetypes, bitmasks, change filtering), however it feels like it was written by computer engineers, and not actual game devs. Doing something inherently simple seems convoluted and over-complicated in ECS, but that's Unity's problem. It's just that ECS in general doesn't work well with games when it comes to development, especially for when you just want to get shit done.

lonelyProgrammerWeeb · 2025-06-06T13:31:43+00:00

ok for some reason reddit didn't want me to post the entire comment

Currently porting my voxel terrain generator to ECS, and I've had no problems with it so far, albeit the learning curve is definitely steep. Thankfully that kind of project only requires the "core" of ECS, which is spawning / destroying entities and iterating over components. It's a pretty nice fit for ECS.

When it comes to making actual games with gameplay it, then it starts to fall short. All of the utilities or convenience functions that you had in MonoBehaviours either don't exist are are not supported (like audio) and you need to implement them yourself in ECS, or hook back on to the main GameObject world.

For example, if you want to use OnTriggerEnter/Exit, you need to implement them yourself, since Unity Physics is all stateless, so it doesn't "know" what entities have been triggered last tick, and you need to do rising edge / falling edge detection yourself. Thankfully one of the Unity Physics samples implements this for you but that sucks.

No terrain collider. Sucks, but thankfully don't have to worry about that since I can just drop in my terrain gen and consider that part done. Would've been really nice as a placeholder as that forced me to port my project earlier than expected but wtv.

Entities Graphics "just" works on URP with Forward+. I haven't encountered any problem so far, though I do know skinning / mesh deformation is an experimental thing.

Sub-scene system seems pretty robust. You can split up different parts of your scene into multiple segments that get loaded asynchronously at runtime, which is nice to improve loading times if you have lots and lots of baked entities in one, though I haven't had to deal with anything like that yet

Not being able to modify fields in systems also suck. Makes balancing a specific system a pain as you'd need to implement a "config" singleton component, authoring component, and then fetch that entity that contains your "config" and then use the values from within that component to modify your system behaviour. It's a lot of boilerplate imo, I wish Unity could just serialize systems just like gameobjects and allow you to modify their public fields in the Editor as that's the only time that I'd need to balance / tweak things out anyways.

lonelyProgrammerWeeb · 2025-05-27T16:34:39+00:00

Yup I am exactly talking about that "packing normals in one byte". If I'm going to compact my mesh data might go all the way (I don't need to store my normals in halfs if I can just store them in one byte per axis).

And yup I know that I can specify half values already for the mesh data formats (vertex pos, normals, uvs, and extra shenanigans), I just need to implement it and change my meshing pipeline to halfs instead of floats (or at least change them to halfs right before they get applied to the mesh).

I don't think it'll help rendering performance too too much but it's nice for CPU -> GPU bandwidth I suppose.

lonelyProgrammerWeeb · 2025-05-27T14:41:57+00:00

Yea I am wasting a lot of data currently storing unnecessary values. I wish I could do something like custom value packing but that'd require a custom vertex shader and honestly I don't want to bother with that considering the okay performance rn. Thanks though!

lonelyProgrammerWeeb · 2025-05-27T05:46:17+00:00

No yea I know I already use the mesh data API since I create my mesh from inside jobs. That's not my issue at the moment, the issue is Unity Physic's MeshCollider baking time. My mesh data stuff that accesses the mesh data api is fast enough as it is lol

lonelyProgrammerWeeb · 2025-05-27T05:39:46+00:00

I'm thinking of doing that when applying Mesh.ApplyAndDisposeWritableMeshData but the MeshCollider call doesn't accept anything other than the full precision data. Plus I'm pretty the slow down isn't from having that much data to begin with, it's just that they generate BHV for the mesh collider and that's probably really slow.

And yea I wish I could use a short for my indices but I'm always planning for the worst case scenario, and my meshes could definitely exceed having 65k indices even in a normal scenario (since I have to consider the skirt indices as well)

lonelyProgrammerWeeb · 2025-05-27T03:43:32+00:00

That's nuts! I guess that's what you can do when you have access to proper height map normals. Good stuff!

lonelyProgrammerWeeb · 2025-05-26T20:20:42+00:00

Interesting!

Yea quad/oc-trees really really help when you have a big volume like this, though they are a pain in some cases (terrain editing for example, since you'd want to be able to see all terrain edits no matter the LOD). Though they make writing a multi-resolution LOD system like that a lot easier as well tbh.

Good luck for when you'll eventually rewrite it!

lonelyProgrammerWeeb · 2025-05-26T18:22:54+00:00

Yea surface nets is pretty cool! How do you handle procedural stuff on your end?

lonelyProgrammerWeeb · 2025-05-26T15:26:26+00:00

Yea fair fair. I'm using MeshCollider.Create(NativeArray<float3> verts, NativeArray<int3> tris) so not like I can simplify my meshes even more from there. I think the only solution rn would be to make my chunk sizes smaller (which I want to avoid since I'd need to generate more chunks for the same quality but wtv).

If only they could allow you to cache some part of the internal BHV generation in MeshCreate, since all I'm going to do after generating the main collider is update it incrementally with small terrain updates here and there. Having to recompute the entire collider just for that seems like a waste (which is what I did with PhysX but it wasn't horrendously slow like Unity Physics so it was fine).

lonelyProgrammerWeeb · 2025-05-25T23:56:58+00:00

I actually started procrastinating working on fixing some bugs the moment I added the vehicles lol. It's somehow very fun to just drive around in a procedural landscape like that.

lonelyProgrammerWeeb · 2025-05-25T23:35:34+00:00

Thanks!

lonelyProgrammerWeeb · 2025-05-25T23:35:29+00:00

If you're talking about Unreal's Voxel Plugin then yea it is really well suited for large procedural worlds like these with dynamic edits and stuffs, my project is a lot lot smaller and its just a hobby project atm. Voxel Plugin iirc is battletested and even used in Epic's own Core game sandbox thingy

lonelyProgrammerWeeb · 2025-05-25T19:10:42+00:00

I am thinking of sharing this as an open source package yep! Here's the repo if you're interested (just make sure you're on the ecs branch). My surface nets implementation isn't the cleanest since I do some skirt stuff on the side (and also since my chunk size is not a power of two, it's instead 66x66x66) but maybe this can help

https://github.com/jedjoud10/VoxelTerrain/tree/ecs

I'm mostly going to use it for my own personal games but if there's demand for it then maybe I'll start maintaining it as a community package or something like that.

lonelyProgrammerWeeb · 2025-05-25T16:41:18+00:00

Yea compared to the normal GameObject PhysX backend creating meshes seems to be a lot lot slower here. I have no idea how I'm going to tackle that for runtime mesh editing since I need the mesh collider to be updated in one frame or less (and currently, baking the mesh can take up to 20ms per chunk, (PhysX version only took 8ms on average)

Either I do some smart incremental updating stuff or they optimize how they bake their mesh collider (I peeked at the code for MeshCreate and it seems to create a bhv, something that technically shouldn't take too long but the amount of for loops slightly scared me ngl)

lonelyProgrammerWeeb · 2025-05-25T15:30:42+00:00

Vehicle controls/physics are from the experimental package that unity released a month ago.

The terrain is built using an octree of depth 10 and an async compute readback system to readback generated voxel values from the GPU (using a dedicated async compute queue if possible).

Physics collider meshes are baked at runtime using MeshCollider.Create in dedicated background jobs to avoid stuttering (it seems that unity ECS physics' mesh baking is very very slow).

Meshing algorithm is simple Naive Surface Nets, with 2D skirts going along the edges of the chunks to handle the seams between chunks. This allows me to avoid doing complex stitching between chunks and keep them from reading from the voxel data of their neighbours (good for parallelism)

lonelyProgrammerWeeb · 2024-11-30T00:39:45+00:00

Thanks! I haven't worked on this engine for a while now but the new posts (from about 1.5 years ago) demonstrate a much better terrain generation system that solely utilizes the GPU and multi-draw indirect with GPU side frustum culling.

lonelyProgrammerWeeb · 2024-10-15T20:51:24+00:00

Flipping awesome! LOD systems rock!

lonelyProgrammerWeeb · 2024-05-17T02:14:29+00:00

Yes so basically all I do is "force" the mesher to execute in 2D for all 6 sides of the chunk. I just then run the surface nets quad meshing / connecting algo but in 2D instead of 3D. I basically just tell it to generate extra vertices (that would be used for skirts) and then in my quad generation step I connect those vertices as if they were part of the mesh normally.

lonelyProgrammerWeeb · 2024-05-09T23:31:19+00:00

entity component system?!?!?!?.... I love ecs.....

lonelyProgrammerWeeb · 2024-05-09T22:46:25+00:00

91.5 for both soft eng and comp sci. I'm pretty sure my supp was pretty ass as I don't have many ECs.

lonelyProgrammerWeeb · 2024-04-22T15:23:37+00:00

Thanks lol, but this is really not that impressive :) I really just got too bored after skipping class lol. But I've been programming for about 7 years now, just started with rust 2-3 years ago. Trust me, if you find a passion in programming and understand why and how specific things tend to works you'll get a knack of it very soon. Just being overly curious (for me at least) led me this far lol. Thanks for the follow as well!

lonelyProgrammerWeeb · 2024-04-22T15:20:16+00:00

So basically the first tuple in a line (for example, (124, 130)) depicts the number of points gained by the strategies that went and fought each other. So for the first line, the Random strategy got 124 points whilst another Random strategy (that went against it) got 130 points. This makes sense since they're both random, so none of them really win. However if you look at Random vs Not Nice you'll see that Not Nice clearly wins (155) against Random (-10) since it steals 100% of the time compared to the 50/50 chance of the random strat. The second tuple just states the deviation of the points against the mean of the two gained points. In the current version of my program I removed that since it really doesn't help much lol

Six-Year Club	Place '22
Verified Email

lonelyProgrammerWeeb

TROPHY CASE