Nevermind, lol.
Just tested worldgen and nav-mesh generation on a map of 50k tiles (a 384 x 128 tile world made of 8x8 tile chunks), and it only takes about 20 seconds to initially generate both the terrain and navigation grid. And on the most expensive frames, calculating a navigation path only takes about 20 milliseconds.
(For reference, the player character would be 4 pixels tall here, and each set of dots marks an 8x8 tile chunk)
As much as I like billboard 2D sprites in 3D environments, having a lot of characters and variant outfits and such means LOTS of animations. I thought about doing rigged 2D sprites, but I want to spend a little time trying out a lowpoly 3D character with swapable textures and body part models first, to see how it goes.
Pretty happy with how it bends already, despite being a smooth-skinned mesh. Liking how the digitigrade legs came out too!
Wanted to get some work done on player controls and test in-game terrain editing performance, so I made a basic point-and-click terrain editing debug tool. Needs some better handling for determining which semi-tile to use where (some ramps or half-tile bumps/divots don't render because they *should* be impossible) but I'm glad it works without any hitching!
Seems like batching the terrain geometry into 8x8 tile mesh-chunks makes regenerating the terrain pretty much instantaneous, even when the mesh data for the world is very large!
(P.S. Please ignore Max poking her head in peridocially. She's just curious what's going on in this part of the level)
#GameDev #Godot #GodotEngine
Unfortunately, Windows 10 ate half of my Godot project, but I suppose it's as good a time as any to rebase the whole thing.
But before that, I turned this cute bit of birthday gift art (courtesy of @lovelyMia) into a little splash screen. Now I get to see it every time I boot up the editor. :3
Working on a little pixel-perfect (-ish) clock, inspired by old sprite scaling/rotation techniques.
Rendering the pixels at their actual resolution ended up a little too jaggy, so I'm cheating by upscaling UI elements and rendering the subpixels at the screen's resolution, to smooth movement and rotation without anti-aliasing. The dials also swap sprites based on angle, to minimize edge distortions as they rotate!
Going back to my comfort zone, and working on some 1-bit menu icons.
Bet you can't guess what they're all for. :3
UI Design! It's sorta fun actually!
Spent some time learning Godot's control node system. Finally got these bits working on the front end, and responding to screen size. Pretty happy with the readability and information density of the crew panels in the top right. And even if the tab menu is a bit Greybox still, it does a lot to organize and declutter things, which is great.
It's wild how adding a bit of UI makes this feel like a proper game, instead of a bunch of invisible systems.
Chipping away at a base model, so I can try out lowpoly pixel-textured characters in this, instead of sprites.
Even if I don't end up needing it, I'm pretty pleased to have managed a fully articulated, poseable hand in 126 triangles!
Finally worked up the chutzpah to rebuild my terrain system.
This time, I'm trying out a new level editor that uses CSG to sculpt tile-based terrain, and applies one of 8 textures based on the surface angle.
It's also good for making cute shapes.
I was a little disappointed by the limitations of my single-tile-deep terrain system.
I've been thinking about ways to include depth, while maintaining the simplicity and readability I like in 2D platformers.
I tried keeping it to a few layers of depth, and limiting hollowed-out chambers so that they're contiguous from the front to whatever depth they're dug out to. Foreground walls should never be able to occlude background chambers, but it still allows for limited 3D movement, and placing things at various depths.
Shout-outs to Diggles: The Myth of Fenris for the inspiration!
I appreciate your work, author of the NavigationRegion3D node, I really do... but can you please not be so opinionated about how much floating point precision you think people need? So much so that you even override the user's floating point precision settings to round numbers up to 2 decimal places?
I can't even set the cell size to 1/8th or 1/16th, without this tool rounding cells up to an irregular value that creates all kinds of artifacting and errors in the navmesh of my otherwise nice, orderly grid tiles.
I'm about to just write my own navmesh editor, I swear...
Anyway, I ended up making my own nav-mesh generator, to satisfy my need for nice and orderly shapes.
It uses the vertices and surface normals in a given mesh, to decide what surfaces should be part of the nav-mesh.
And far as I can tell, it's working beautifully.
Made a low-poly gremlin.
Still trying to decide if I want to pre-render some billboard sprite sheets from this, or put some Megaman Legends-ish unlit pixel textures on this in full 3D.
Either way, pretty happy with how this hair topology bends!
Been playing with Pixel Composer (https://pixel-composer.com/), and it *does* make rotating and posing a pre-rendered spritesheet a lot more doable, for animated pre-rendered billboards...
Could probably work this into something a bit Shining The Holy Ark, or Golden Sun.
Much to consider.
Using some old sprites to work on a billboard-style character animator.
My stars, trying to finalize this edge-collapse mesh simplification technique has been kicking my ass, but I've finally got the last necessary rule (I think).
This probably doesn't make sense to anyone but me, but I'm so happy to have cracked it! Huzzah!
Happy accidents, while making some map diagnostics.
Might have to turn these into some kind of map-loading effect...
Working on some smooth low-poly 3D tiles, for subterranean environments.
Having trouble with Blender, getting the sharp seams/normals to be shared across different tile shapes that they'll tile with. It's tricky to get the edges pointing the same kind of forward, but keep the vertical smoothing. I do like the general look though!
Wanted to take some downtime tonight to finalize Tile Variant generation for the marching cubes voxel system I've been implementing.
Far as I can tell, the important part works; it can create new meshes with rotated or flipped geo, generate UVs appropriately, and splits the mesh up into different faces. And the voxel "points" used to pick a mesh based on what corners are solid or empty are working fine.
...but Past Me decided to be rude and careless, and leave a bunch of cryptic bugs in the code. Parsing what needs doing is a bit like running brain-first into a brick wall.
Slowly getting there, with this Marching Cubes terrain overhaul.
A cloud of points is being fed into each Chunk of terrain. For testing, blue dots are solid, and red dots are empty space.
Each 2x2x2 cube of solid and empty dots is used to look up a particular tile shape from an atlas, and add it to the chunk.
Still debugging the tile generator, I'm afraid; some of the tiles are rotated the wrong way around, and I don't know why! But It's good to see it working somewhat!
It's done!
Terrain geometry is now generating properly, from grids of editable voxels!
(Maxine would be celebrating too, but she's just billboarding here for scale).
#GameDev #Godot
Whipped up a little debug environment, to get a sense for how the new terrain system will look in-game.
Willing to call the overhaul complete. Now to get back to gameplay!
#GameDev #Godot
Quick stress test of real-time terrain editing/geometry generation.
I'm shifting the terrain data one voxel to the left, and regenerating the geometry for the entire test map, 4 times per second. Camera and input are chugging a bit, but this is entirely unoptimized.
This Marching Cubes thing really is quick and efficient!
#Godot #GameDev #ProcGen
Added UV Mapping to the tile generator.
Would've just done Triplanar Projection, if I didn't want the textures to warp with the surfaces... but I think the squidgy sharp-seamed textures are worth it.
Just finished this 3D dual grid texturing system. It kicked my ass, but I'm so glad it's working!
I'd like to do a bigger writeup on my Patreon soon, but If you're curious about how it works:
The terrain is generated with tiles that are a dual-grid. That is, each Graphical Tile defines the corners of 8 adjacent Logic/Terrain Tiles.
This drastically reduces the number of tile shapes I need; terrain just uses 14 shapes, instead of hundreds!
But it also means each tile can have up to 8 different textures matching each of its neighbors. Which is tricky to do on the GPU instead of the CPU!
Rather than redoing the tiles, I created a system that paints tiles with Vertex Colors, which show what areas are part of what corners. I also pass each tile mesh a set of 8 texture IDs for which texture each corner will need.
This means all terrain in the world uses a single material and texture atlas, which can look up the right textures on the GPU, draw borders with its neighbors, etc. I'm very happy!
Debugging selective border drawing for tiles, and I just thought this happy accident looked nice?
Took a break from terrain coding, to start scribbling down some basic design thoughts about terrain materials, raw material harvesting, and crafting.
Solid terrain voxels represent 8 units of material. These might be stone bricks, a refined metal panel, a tree trunk, a mass of woodchips or scrap chitin, or whatever else.
I've roughed out a few form-factors materials can take, as various constructable objects or hard goods. I worked out how many units of material should comprise each, and some rough crafting flowcharts for what can be processed into what, to keep yields/volumes consistent.
Also had some thoughts on crafting or harvesting failure based on bad tools or low proficiency, resulting in mostly-unusable Rough materials, that need to be reprocessed before they're useful again.
This only really represents hard goods like minerals and lumber so far, but it's a place to start!
Turns out getting physics-driven characters to not walk off ledges is actually kind of hard?
Like, you can't just detect an overlap between some 3D shapes, and where you're planning to move, and stop the move when they'd collide.
You need to detect where geometry *isn't*, then make up some rules to restrict physics manually, based on a specific absence you can prove.
Settled on predicting if a character won't be on ground, if it moves in each of the cardinal directions this frame, and if so, it negates any movement along that direction.
Not perfect yet, but it's a start!
@rayk I considered it, but since I need characters to perform multiple styles of movement along both walls and floors, in a way that (for non-player characters) respects a discrete terrain grid, I needed a generalizable solution.
Some predictive Raycasts that I can reorient based on gravity seem to do the trick! Just want to implement some smoother sliding.
@danana_dread If that gets to be too slow, you might also be able to precompute a 1 bpp bitmap image where pixels that are a “1” are walkable and “0” is not, and map that to your grid. Essentially doing those raycast at build time instead of runtime.
Sounds like an interesting challenge!
Dana
Ray Kelm