corners would still look kinda pointy but ¯\_(ツ)_/¯

quick generating caves test

#GameDev #IndieDev #ProcGen

if i kind of artfully place the camera to cut out the cornflower blue void surrounding this tiny chunk of terrain on all sides its almost starting to look like a real game :D
trying to add a faux edge bevel through normals and actual lighting equations is proving extremely challenging and i'm starting to give serious thought to manually baking the lighting into the textures

after endless futzing about and tweaking i think i have something that may just be workable for this faux bevel effect i want

(note that there's a "bevel" between adjacent blocks cause i haven't made the effect dependent on the block's neighbors yet)

I dunno I'm just not feeling the actual lighting model. Its not like minecraft exactly has realistic lighting anyway: blocks are lit from two opposite sides!

But the problem with baked lighting is if you have non symmetrical blocks you have to make 4 versions of each face to get all the lighting. Not that that's super onerous

Also if I made something like a lectern that would be a lot of work to do manually for each orientation

On the other hand when I made isometric games I'd have to make two of everything to get the lighting right and I didn't mind that so much so maybe I'm overthinking it

ok i figured out a reasonable way to fudge the normals so i won't have to manually bake lighting. basically what i do is set the normals of the edges so that they point towards where the adjacent faces are pointing (90 degree bend) and then i lerp from the face's lighting factor to the neighbor's lighting factor

that gives me the result on the left. i tried just having regular, actual normals, but it creates artifacts like on the right (its accurate that it shades it like that but it looks bad)

i was worried the corners would look too sharp without modification but honestly the smooth gradient does a great job without blunting the corners
took all day but i've optimized the vertex format for blocks *and* implemented auto-bevelled terrain. shown without textures to make the bevelling clearer

here's a gif of the textured terrain toggling the faux bevel effect on and off to really show how it softens the terrain. i'm really pleased with this

#GameDev #IndieDev #ProcGen

doing a side by side with my style guide i think i'm getting there. i'll probably wanna do some fancier color grading on the lighting though, and i want outlines, but the soft rounded feel of the terrain is definitely there now even though its still all cubes

i've brought back the grass, which is actually an obj model

see i made an engine before and appropriated it for this project. it could load obj models (with normal maps) so at first the blocks in my world were actually loaded from obj models

that's why i had to redo a buncha stuff to add the bevelling, since i had to generate the faces myself

I should probably start linking up chunks before I do much else so I don't wind up having to deal with a ton of "this block's neighbor is in another chunk" situations later

had a silly idea for block outlines using the bevel system. i take the dot product of the vector from the camera to the world position with the normal to determine if the bevel normal is pointing away from the camera, then add an outline based on that. there's some outlines where they don't belong but i can get easily rid of those

... i don't hate it? 🤔

yeah i'm happy with these terrain outlines for now

#GameDev #IndieDev #ProcGen

another few shots of the new outline tech

#GameDev #IndieDev #ProcGen

lol the outlining has more than doubled the code in my fragment shader

texturing, lighting, and bevelling: 12 lines of code

just doing outlines: 19 lines of code

Not to pat myself on the back too hard but it's really nice how good this is turning out, like, aesthetically. It's not exactly trivial to make graphics look good when you only have a single 16x16 texture >_>

On the other hand I guess it would be fair to say these graphics are looking a little...... muddy

Eh? Eh? Eh? :D

i'm commander shepherd and this is my favorite spot on the citadel

(seriously i cannot get enough of looking at this particular subsection of a screenshot i took of the outlines in my voxel engine)

captured a little fly through video for y'all. i can seriously just fly around this one chunk for 10-15 mins at a time enjoying the aesthetics :D

#GameDev #IndieDev #ProcGen

debating what i wanna do with grass in my engine. atm i have a block shader, and a model shader. i feel like i could efficiently implement shell textured grass by making a shell texturing shader, but i also don't want to balloon the number of different shaders i need to render all my terrain 🤔

i could just use the model shader, but it becomes a pain in the ass to implement shell textured terrain then

i could try and combine it with the block shader but they both do really different things

hmm if i want to add bits to the shell texturing so it doesn't look bad viewed side-on i kinda have to go the model route

though i figured out i can get away with only 6 variations to get all the edge transitions 🤔 that could be doable if a bit annoying

i'm overthinking the grass thing so i've made the textures required to make the shells for a 16-tile transition and i'll just generate the model for each of those 16 and implement them in the engine and move on so i don't wind up blocked by choice paralysis

if i want i can always just change it later

hell yeah, grassy voxels

#GameDev #IndieDev #PixelArt #ProcGen

here it is compared to my style guide image. how did i do, chat?

i probably wanna pull the grass away from the edge a bit more because it obscures the outlines, but i'm pretty happy with this overall

At the moment the wild grass is actually a block on top of the dirt (like carpets in minecraft) but I'm thinking maybe I should change it so that the grass is part of the dirt block that sticks out above it as it were. That way things can occupy the same block as the grass without deleting it, like shrubs, flowers, or other non-opaque blocks

here's another close up i really enjoyed of the terrain in my block game

#GameDev #IndieDev #PixelArt #ProcGen

i've got columns of chunks working, but they're not really connected at the moment so i gotta fix that next

#GameDev #IndieDev #ProcGen

chunks connect properly now! with bonus shot of the sprawling cave systems beneath the surface

i made a staged chunk generation system where chunks can request their neighbors be generated but only up to a certain stage, which keeps the generation from going infinitely in all directions, because the requested stage must always be lower than the chunk's current stage of generation

#GameDev #IndieDev #ProcGen

you can see through the sides of chunks now because the chunks (correctly!) note that their underground sides faces are obscured. it's just that they're obscured by chunks you can't see because they haven't fully been generated yet

who's got two thumbs and infinitely spawning terrain? this girl 👈👈

#GameDev #IndieDev #ProcGen

@eniko Time to throw the generator on another thread! 😄
@jsbarretto i fixed it for now by only running one generator per frame >_>
@eniko Aha, the PWM approach! I remember doing this years ago in my Game Maker voxel game (GM didn't have multi-threading). It certainly gets the job done. If you wanted to calibrate it for the performance of the device you could throw generator requests into a work queue, then use the 'idle' time at the end of each frame to do generator work.
@jsbarretto i'll move it to threads eventually but it's kind of tricky with how chunks need to touch their neighbors in order to fully generate so i just haven't bothered with that complexity for the moment
@eniko Yes, it's a hairy problem. In @veloren we wait until all 8 neighbours of a chunk are available before scheduling a generator run, then we batch immutable references (chunks are copy-on-write) to all 9 chunks and throw them at a worker thread for meshing/floodfill lighting.
@jsbarretto atm in my design a stage of a generator can request a list of other chunks up to a minimum generation stage so i may have made things difficult for myself :'D
@eniko Ah, is this for things like tree generation (and other structures that spread between chunk boundaries)?
@jsbarretto yeah, exactly that. i don't plan on having actually infinite worlds so i'll probably make life easy on myself and generate large structures up-front on world creation
@eniko Yeah, this can get really complex, and even more so with larger structures. You can sort of paper over the issue with a tree (it's small enough to only cover a maximum of 4 chunks), but generating an entire town, say, requires a totally different approach. Instead you need to find a closed-form solution for generating candidate tree positions in a manner that's closer to procedural noise. I recommend looking into cellular noise techniques, which involves placing trees on a perturbed grid.
@eniko When it comes to threading, the golden rule is: minimise the amount of conversation that needs to happen between the threads. This means that ideally your worker thread should be given the resources it needs to do its work when it's started, and doesn't need to mutate or talk to any other part of the game state until it's finished.

@jsbarretto yeah, that's how i always deal with threading

pass in a bunch of data, have it crunch it, then pass back the result

but like you said it's hard to do this with chunk generation because their neighbors are not in stasis while chunks are being generated

@eniko Yeah! This is why every mutation of a block needs to not only increment the counter for the chunk it appears in, but also that chunk's neighbours: that way, you end up propagating changes across chunk borders properly.
@jsbarretto and this is just for stuff like lighting updates and block connectivity right? If a tnt blows up on the border of a chunk that is generating, you don't take into account the damage it should've taken
@eniko Yes, absolutely. There's not even a good way to account for that damage, I think. But that's a pretty rare case as you say and I've not personally ever observed something like that being visible (we don't have TNT, but we do have firebolts that explode on impact and scorch/destroy terrain).
@jsbarretto @eniko I would bet that some speedrunners will find a way to use that contention 😎
@gilesgoat @eniko Surprisingly, I've not seen people do much exploitation of the terrain system (other than 'reload chunks a bunch of times to get new items', but we've fixed that now). The design hasn't meaningfully changed in about 5 years, so my suspicion is that it's fairly watertight at this point.
@jsbarretto actually my version of remeshing is split. its just that grass is a block with connectivity so the generator needs to handle that. but rebuilding the vertex/index buffer data for a chunk is basically just chunk.Rebuild() which is separate from generation
@jsbarretto @eniko "jumping in the conversation" .. yes, precisely , I think you can even mathematically prove ( various things ) that "what mostly will risk to fuck everything up is the communication lock/unlock between threads". In fact it can be very easily the OS could spend LOT more time to let your threads exchange data then the threads working on it. "Measuring" ( performance ) is the only way can give you indication if you are doing right or not "theory" alone won't suffice.
@jsbarretto @eniko Also "Mutex" vs "Semaphores" vs "Critical Sections" .. I found it "almost impossible" "by thinking alone or even by using them" to figure out "which one works the best" .. when we could say "in reality all work the worst ?" .. I think the key is "minimal as infrequent as possibile data exchange" and/or "as infrequent as possible but blast a chunk when you do" and/or use "double buffering techniques with PTRs swaps" so you can work in a buff while another can used by a thread
@gilesgoat @eniko Best approach here is to avoid locking primitives entirely and just use a work-stealing queue to ensure minimal contention.
@jsbarretto @eniko But I know as a fact, with modern CPUs, there's fundamentally NO bits of code without using "Locking primitives" that can guarantee you'll NEVER have contention.
@gilesgoat @eniko Well, yes, contention *of some sort* is inevitable, but it's not really a useful observation in the context of how one goes about designing a concurrency model for a voxel game. The important distinction is whether a design results in a worker thread sitting around waiting for a resource to be available vs not doing that. So that's where discussions about locking vs copy-on-write start to be relevant because you can trade off latency against total work done.
@jsbarretto @eniko Sure, I guess depends on how much dangerous/tolerable/rare to happen that contention is.