Creative No artist was harmed in the making of ... whatever this is. :)

Something I'm just toying with ...


Actually, that is not true, I know where I want to take this but I just started today and we all know how many unsolvable issues lurk just around the next corrrrnggggphhhttatatameinlebän!!

Here's a proof of concept video to see it in "action" (a moving light to highlight the depth).

PS: Yes, I know Voxelstein! This ain't a game. I just like the wall texture for being low-res and full of memories. As I keep moving forward with what I have in mind, it's going to evolve into an art and map design tool.

Like this post if you want to see more of this ...

 

(reserved)

 

Here's another one, with point light:


Source:


Trivia: name the game!

Ignore the dark pixels that look like failed SSAO. UVs are messed up for some faces.

 

I'm really enjoying the voxel-ish look of low-res textures.

Take for example this one right here taken from an OpenGameArt.org tileset:


It is 80x80 so a bit higher-res than the Wolfenstein 64x64 - however the contrast is low and zoomed in, it looks like anti-aliasing. Introducing two parameters to control the min/max levels of brightness as well as clamping it (a curve is in order here) I can generate walls from it that do have a decent amount of depth (light source to the left):

 

Ultra-Low-Res works surprisingly well:


Source image is 16x16 pixels, shown here with 8x (!) scale:


The dithering/noise on walls not facing along X axis (see blue X) is due to garbled UVs. I've since fixed this as seen in this video:

I also tested this with orthographic camera to give a side-scroller look but with depth. Add a light and this makes your platformer stand out instantly and you don't even have to create 3D models!

 

Weird creative sort. Love it.

 

This is the first result of the "batch importer":


Using this tile texture by VectorPixelStar:


An example of a tile "block":

 

Hot day today. Right day to do some refactoring. I fixed the generator so that it creates the voxel meshes on top of the atlas texture, and also allows each mesh to be GPU instanced since they now use the original 2D atlas material.

That is quite a sight ... I'm thinking: instant replacement of 2D tiles to get a 3D look for any game using tilesets like this one.




There's much to do. Normalizing height levels. Configure settings for individual tiles. Different algorithms for height picking (luminance, saturation, color, etc). Cull backside when not needed. Marching cubes to reduce polycount. Maybe averaging vertices to get a non-rectangular low-poly look. Save as assets/prefabs (with optional rotation). Certainly a lot more ...

 

It's been almost a week. Time flies. Code doesn't. I ran into issues that were frustrating and time consuming, most importantly my proof-of-concept code wouldn't scale as it created 6-digit numbers of (temporary) Cubes and running MeshCombine on those which, even though I deleted them right away, put too much of a burden on Unity and the time it needed to do "internal processing" grew exponentially.

So I'm refactoring to do it the right way, using Jobs and MeshData. After all, I want to be able to modify parameters in realtime and I know it's possible. I just did not expect the brute-force code to be this problematic - I was hoping to refactor it later when all the features were in.

In the meantime, here's the most recent glitch I programmed, completely on purpose of course.

 

I mentioned before that I do not know what this is (or will be). Right?

Well ... I found myself evaluating node graphs and ended up throwing this together as a proof of concept and learning the graph stuff (too bad NodeGraphProcessor hasn't seen any updates for > 10 months - I decided to fork it, it is not without issues but also not difficult to work with):


Output is a mesh asset with all the cubes and quads combined into a single mesh. Don't get me started on materials though, I suppose there's no other way than to create a prefab if I want to connect materials in here, since mesh assets apparently can't contain their own materials (at least not when you create them in Unity rather than import an FBX/OBJ).

This is still related to what I showed above since I wanted to have the whole processing as modular as possible, and also visual for myself and a graph helps to force me into a modular workflow rather than having to come up with my own. I tend to run out of steam when I cannot SEE results for too long - either visually, or as unit tests passing/failing. Reminds me: need to check how I can unit-test nodes and graphs. Building something like this without tests would be mAdnEsS!!

Btw I learned about Blender's geometry nodes after I did the initial research because I was sure something like this had to exist. I don't expect any of my ideas to be original and time and time again I am proven right hehe .
Interestingly though, it took me several attempts and asking friends for graph-based modelling tools (they didn't know any either) before I found anything close (Substance 3D, Houdini) and through that I came to Blender.

 

This is super beautiful!

 

Thanks!
Do you refer to the voxelized images or the graph editor concept?

 

Here's a quick live demo of "Mesh Graph" with the scene view as preview:

I intend to embed the preview rendering in the graph itself, using a preview scene.

Node-wise nothing much happened (besides the random node) since I had to create my own MeshGeometry class. The reason is you cannot just grab vertices and move them around without knowing about the faces - the cube here would just show 6 disconnected quads moving around, creating gaps in the geometry.

Benefit of the custom data model is that it doesn't really matter anymore whether I'm working with triangles, quads or n-gons.

 

I added tesselation of primitives and instancing to the graph.

You can now "spawn" meshes on another mesh's vertices (or edges or face centers) and this is what it looks like:


I know the graph interface sucks right now, it will be overhauled after major features are in. I need to get some experience putting stuff in to see where I can generalize both code and optimize the UI. For instance I want to automatically switch between manual input and input through port, hiding the manual input fields when and edge connects to the port.

Also fixed the performance issues. A single update was nearly 1 second but I want this to work in (near) realtime. For that each node in debug mode displays its processing time if it goes over 1 ms. If you look closely you'll see the graph updating in 3 ms, and it's still single-threaded.

This is clearly not a stress-test scenario, on the other hand I don't expect graphs to be used for super-complex (ie whole level) kind of meshes. Still, I make sure to write the relevant code with Jobs in mind.

 

I felt like posting another update (it's been over a week) even though it's "only" been a lot of work in progress under the hood. So I'll start off with some colorful visuals first ...



See that floating thing in the back?

That's this single-face mesh fan-triangulated into, well, triangles:


This is the first visualization I got from my GMesh implementation. GMesh is open source, published under MIT License, and at the moment far from production-ready.

What in the name of the heck is a GMesh?

Initially, I thought I'll just work with vertices and faces for as long as I can. It didn't take long to appreciate the utility of Blender's BMesh structure since you can far more easily add/remove elements (faces, loops, edges, vertices) to a mesh.

BMesh is the graph-based format with which Blender stores all mesh information (elements as well as attributes such as normals, uv, material, etc.) necessary for live-editing meshes. It allows for (fast) traversal in all directions, ie given a vertex, you can find all connecting edges and faces. Or given a face, you can find all the edges and vertices of the face - without having to store duplicates of this information. Splitting faces is done upon "export" so at any time you can decide whether vertices should be shared on a per-face or per-vertex basis.

As a matter of fact, the design of this graph based mesh structure reaches all the way back to the 1980s.

I did some looking around and found BMeshUnity, an implementation for Unity. Great! Only that after half a day test-driving it, I found numerous issues: vertices, edges, loops are incrementally one-off to each other, flipped faces because of that, edges are duplicated, lack of documented assumptions, no unit tests (only few functional tests) and no way to make this work with Burst/Jobs.

However, BMeshUnity showed me how approachable the BMesh structure actually is, while Blender's C implementation of BMesh is littered with memory allocations, pointer arithmetic, archaic syntax (hard to believe I once programmed in C/C++), unusual type checks (there are no classes) and typical C-style abbreviated variables because die-hard C programmers to this day work under the assumption "memory is costly, typing takes time, vim is the best". Agh!

So, on a hunch that I can easily implement my own version and make it so that it should be easy to add Burst/Jobs support when needed, I started working on GMesh. Where "G" stands for "Graph" as it is a graph-based structure.

All elements (vertices, edges, loops, faces) are blittable structs. References to other elements are indices into their respective NativeList. That poses an issue with deleting elements. An issue that, for the time being, I worked around by simply flagging deleted elements because removing items from the lists would require updating a lot of indices of existing elements, possibly all of them.

I can later add some (job-driven) method to "clean up deleted elements" but since Mesh Graph will be generating meshes from scratch every time, deletions should not be very frequent.

Oh and I immediately fell in love with Euler operators! They are so simple and elegant yet enable every kind of basic modification you may want to perform on a mesh while preventing you to break the mesh.

So from today, I will start replacing my existing MeshGeometry class with GMesh in the node graph and that should enable me to work on the next-step that I was trying to focus on last week: bevels / chamfers.

As seen here.
Or this image (top: bevel, bottom: chamfer) taken from here:


I wanted to do a round cube. Simple enough, right?

But trying to solve that without GMesh even just for a cube, let alone random shapes, would have lead to a horrific mess. Thus I think the 3 days I've been working on GMesh so far are justified.

My near-term goal is to enable users to create low-poly art with Mesh Graph, very much like these pillars:


This is my milestone task: Use Mesh Graph to create a stack of slightly uneven flat-shaded cubes with random cuts in them and be able to make plenty of variations.

Then the next step would be tile-able walls, floors, ceilings followed by walls with holes in them (often simply referred to as doors, sometimes trapdoors, and on occasion: windows).

Lastly, here's the simplemost GMesh to UnityEngine.Mesh code example creating the test face mentioned above:

Code (CSharp):

1. using (var gmesh = new GMesh())
2. {
3.     gmesh.CreateFace(vertices);
4.     _meshFilter.sharedMesh = gmesh.ToMesh();
5. }

The vertices is 3 or more points in any IEnumerable<float3> (or Vector3) collection. GMesh implements IDisposable due to using NativeList internally.

I also emphasize debuggability of the code I write. ToString() on any object with all the relevant information makes me see whether everything is alright at a glance:


The simplicity of indexing allows for more naturally following relations. Whereas if each element were an object, you'd either have little to no information or unbearably long strings.

 

Being able to generate low poly meshes? Count me in
As for creating a "scene" (like a house), wouldn't it make sense for that to be a separate system? IE a graph that constructs a house by arranging gameobject instances of generated meshes found in a list.

 

Yeah, I suppose there's also merit in some sort of "Prefab Graph". I've been pondering this as well. But first things first: wiggle your big toe.

The initial goal is: I want to be able to make low-poly, tileable meshes. Then I'll see where to go next.

I mean I can imagine a graph that builds a dungeon/maze from tiles based on some rules. A house (skyscrapers specifically) would merely be a special kind of dungeon, both if you consider the exterior (walls, windows, doors, ornaments, terraces, ...) and the interior.

 

Just a quick update, I added gizmos to visualize the GMesh vertices, edges, loops and faces (can be rendered individually) since I got tired of trying to visualize all of this in my head. All this information overload of the past days lead to me reporting two very stupid issues to JetBrains which were both my fault, so I call this a preventive measure.

Vertices (cyan), edges + cycles (yellow), loops (green), faces (red):


For comparison, the text log of a smaller version of this plane (3x3 quads) is already 80 lines.

 

Sometimes, it's the seemingly simple things: behold, a cube!



With varying subdivisions per axis:


This actually demonstrates GMesh.Combine() feature (as well as edge loops debugging) since I've taken 6 planes, rotated and positioned to form a cube. Then I ran GMesh.Combine(planes) which returns a new GMesh instance where all 24 plane vertices were melded into 8 so that there are no duplicate vertices, edges or loops.

The precision of melding vertices is currently set to combine every vertex within a 1mm range but the actual vertex position is left unchanged.

 

Finally, today I fixed the last remaining bug with splitting edges / inserting vertices. The result is a densely tesselated cube:


Now I'll work on the opposite Euler operator: delete vertex, join edge.

 

I just wanted to draw a Pentagon correctly, then I realized the algorithm can be applied to any number of vertices. Now it draws an N-Gon, anything from triangle to circle.


Mesh generation is using the tried and trusted fan triangulation as you can see. Triangle strips wouldn't be hard to implement either but I'll put this back for as long as the fan doesn't cause any issues.

I'm currently fixing the GMesh implementation so that it is a solid foundation. I copied most of the algorithms from UnityBMesh only to find that it has some issues, doesn't consider many edge cases, and it was all done using direct assignment, rather than utility methods such as "insert/remove edge/loop to/from cycle". So I went all the way down to the lowest level, adding unit tests for the simplest things, because those issues trickle up and cause problems that are otherwise hard to debug in a complete mesh.

At the same time I'm implementing validation checks in the Graph itself, so that debug drawings above turn red at the element in question when one of the checks fail. Otherwise it would be hard to spot an issue.

 

Another week passed and I don't have much visuals to show, except for this chart ...



I converted the whole mesh generation process from previously managed code to Jobs (and Burst, naturally). This is the time from generating several (40k vert) planes, combining them, merging vertices, triangulating the combined mesh and outputting a Unity mesh. It went from 1-2 seconds down to 5-10 ms. And there's still some room for optimization.

Now I began writing the code for creating what I call a VoxPlane which will generate meshes like the ones in the earlier posts. It can take any type of heightmap, so it won't be limited to just textures.

And when I get that working, I will have to add the colors back in, probably vertex colors at first and palette texture later. Thus far, I've ignored UVs. Ugh. Everyone hates UVs, right?

 

Finally, I've come full circle:


This is a 64x64 voxelized heightmap mesh but this time not using stretched cubes but properly constructed quad faces.

The heightmap is random, and there's no color information - those are the next steps.

I also plan on adding the option to "close" the surroundings, ie run strips of quads down to zero height so it can easily tile. Of course smoothing and leveling out minimal height differences and cube-marching it to reduce polycounts are also on my list.

Interestingly, if you set a cookie texture on the directional light, you can sort of add a texture to the mesh (in fact, every mesh - not sure if this can be controlled with layers) even though the mesh has no UVs and the material has no texture on it.


I'm wondering about the applications of this. It has some issues since it makes everything darker and the screen borders seem to fluctuate in brightness. But maybe this can be controlled with settings or proper textures. I leave this to whoever is interested in toying around with this.

I welcome any updates on what you can do with light cookies and whether there is a possible use case for making untextured low-poly worlds more interesting.

 

Now with borders:


Borderline City Skyline, so to speak.

And its got vertex color now:

 

Have you run into any issues with artefacts on the borders between two touching tris that don't share vertices? (e.g. on your edge skirts, like in the screenshot) I got quite a few when using some of the CSG assets available, which split up my polys. If you ran into any, how did you fix them?

The artefacts I saw were single pixels along the shared edge that weren't filled in by either tri. This was way more noticeable when using shadows and the resolution was much smaller, so there were large squares of unshadowed surface where it should have clearly been in shade.

 

Do you mean something like this?


No, I haven't seen those at all.

I haven't tried what would happen if I made the higher (blue-ish) block actually include the lower (pink-ish) blocks vertex on the connecting side, ie splitting the edge that runs vertically on the blue block. I could actually try this as a post-step.

Playing around with the shadow settings can improve those artifacts and two-sided shadows help also but I could not get rid of them all. There's always at least tiny splotches of light somewhere where it shouldn't be.

This is on URP but it seems just the same in legacy renderer.

I'm not seeing any artifacts on the sides though:

 

Insane vertex colors


I was looking for a Unity.Mathematics type that mapped natively to Color32 but .. there isn't one.
Fortunately, someone unbelievable made this which has byte4 in it: https://github.com/MrUnbelievable92/MaxMath

 

Why are software projects always late?

Because it can take two entire days to get a mesh from solid color to properly vertex colored from a texture even though you've done it before there's always something - including technical and mental issues - and when it's done, there's still something ... look at how vertex colors bleed. It looks alright in similar-color textures but for high contrast I think I need to do something about that.

See for yourself (extreme height differences are on purpose):


This looks rather nice, happy with it (extreme height differences are on purpose).


Source image:


Btw, this is how you make a vertex color shader in Shader Graph (works for URP and legacy):


Without color conversion colors would look somewhat pale / undersaturated.

 

Same as at the beginning of the thread ... but different.

 

Loving this and appreciate you blogging the progress.
Also appreciate the BMesh links as it was something I wanted to look into soon and seems like some good starting points.

 

Since I'm dabbling with retro shooters, I ended up spending just over a week recreating Doom (2016)'s first map in, well, Doom (1994).

That got me thinking because making maps is fun. I wanted to try if ProBuilder is a decent replacement for old-school Quake shooters. After all, Dusk was made entirely with ProBuilder in Unity. I put this together in a day:

Makes me wonder ... why aren't there any classic, fast-paced, indoor-centric first-person shooter kits for Unity in the store? So that's a route I'm exploring currently with a couple ideas in my head for the procedural mesh generation I did further up this thread.

 

Continuing with Qnity or whatever I'd call it ... I've added a shotgun with sound, fire particles, lava pit with particles and dealing damage (actually just playing sounds).

 

So the whole retro FPS gaming detour made me delve into Netcode for GameObjects. I will have something to share about this soon because it took me a while to get it working and grasp the concepts, realizing there's a bunch of things I can and wish to add to the whole Netcode experience.

So I was starting over with a blank project and get players connected, and this is what I end up with in the first test:


Both capsules are spawned with a rigid body in the same position and when the second player joins, the action begins ... uhm ... well ... I'll leave you to it.

I made a video of this:

 

HEUREKA!!!


Needs some explanation, doesn't it?

So I was working on what I call "FileTransfer for Netcode" for the past couple days. While I was getting a stream of bytes from A to B (client to server) and compared SHA1 hashes, actually applying this to a texture in the project, sending it over from the client and seeing it appear correctly on the server (my logo) is a completely different thing!

To transfer this texture, it had to be read/write enabled so I could use texture.EncodeToPNG() on the client and on the server texture.LoadImage(). Pretty trivial but seeing this work over the network, and this working with just anything you can encode to and decode from a byte[] is ... wonderful!

Next I'll add a file picker just so I can test sending ANYTHING on my computer to ... well, my computer.
But I'll be sure to test this with friends over the Internet. It already works perfectly fine with the lag, jitter & packet loss simulator set to crazy values.

There's only an artificial file (buffer) size limit: 100 MB seems reasonable. It would be able to send up to 2GB but who wants that going through their network? Besides, during the transfer the buffer is currently 100% in-memory, with ".partial" file downloading and resuming on the wishlist.

I put up a Trello Board for this. I welcome all suggestions and feature requests! Plan is to release this to the Asset Store within a month (depending on review) and then I'll work on another Netcode tool until I get user feedback.


I'm slightly torn with the name because it has NetworkDataTransfer at its core to send/receive byte[] with a thin NetworkFileTransfer wrapper that will read/write the byte[] to/from files or other representations, such as on-the-fly Texture to PNG conversion.

So, would you rather call it "File Transfer" or "Data Transfer", or something else?

Also, which of these tools would you think would be needed the most?

1. QuickStart for Netcode (simple Host/Client connect/reconnect thing with a wizard menu - this would be free)
2. File/Data Transfer for Netcode (see above)
3. Text Chat for Netcode
   
4. Kick & Ban for Netcode
5. Persist for Netcode (identify and persist players, or any client-specific state on the server)
6. Ping for Netcode (well, that in itself seems "too simple")
7. PlayerInput for Netcode (transfer input state from clients to server for server authoritative gameplay, also demo recording)
8. Other ideas?

 

How goes the 3D voxel stuff?

 

Cool project

 

Currently on hold. That's not to say I won't pick it up again, but I felt it difficult to come up with use-cases and requirements that provide good value without having to spend several more months on it.

I currently focus on networking with Netcode and when I get more done in that area, I still have this Voxelstein-like shooter (multiplayer of course) in the back of my head which could make use of the "voxel stuff", and "quake stuff".

 

I've recently dipped into playing Prodeus ( GamePass PC ) and the style of graphics would perfectly suit this technique with some careful art direction and tasteful settings, maybe even downscaling the textures even further as I felt that the Minecraft samples here work better than those from Doom. I'm thinking just enough to remove all the normal mapped elements and replace them with equivariant voxel depth geom.


The game is a lot of fun for quick bursts, though they really need to work on the main menu interface - feels like original IMGUI placeholder graphics

So yeah hope you keep tinkering with this when you have the time.

 

Funny thing: I played Prodeus last month, for one I've never had the chance to and wanted to check how true to the classics it really is. But I also wanted to check if that would voxelize well.

And I was interested in its map builder. It feels almost like they used the ProBuilder API to make their runtime editor, however after spending a couple hours in it I'm baffled how they managed to work with that. If I remember correctly it didn't even have undo.

After a couple levels I stopped playing though. It felt too dark with a certain lack of contrast, none of the locations really stood out as a highlight. Visually I'm more of a fan of the more colorful, even cartoon-style shooters like Doom and Duke 3D.

 

FYI I created a new thread for the Netcode project / systems I'm working on.