quick generating caves test
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
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'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
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? π€
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
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)
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
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
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
i can finally hop around this world and IT'S SO GOOD π
i uh, may or may not have spent several hours today just exploring and jumping around caves in my block game
anyway look at this cool cave i found!
i added placing and removing blocks, so i did what one does in such a situation and built a stone starter house
It is pitch black. You are likely to be eaten by a grue
(grass temporarily removed for convenience while working on lighting)
ok, got some basic lighting going on, now to refine it
(surface flattened temporarily for convenience)
i mean, this *is* a bit better than standard minecraft, but... idk. i don't think it's enough better?
may have to try an entirely different approach and fall back to this if i can't work anything out
bonus cave shot with lighting
@eniko I picked that up from this post. https://mastodon.gamedev.place/@eniko/115181739309375413 I had assumed you were doing the technique described in this paper, or something similar. https://dl.acm.org/doi/10.1145/2184319.2184345
Sorry for the confusion!
Attached: 2 images 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
@eniko is... this the doom engine fast circle approximation
*edit* to add context: https://doomwiki.org/wiki/Approximate_distance
Approximate distance is an important concept in the Doom engine and is used in nearly all calculations in the game simulation which require the distance between two points. Because Doom was written to run on early 386 and 486 processors which often lacked a floating-point unit entirely, and its use was slow even when present, the game was written to exclusively use fixed point math. This has an important impact on how distance can be measured.
@eniko oh, that sounds pretty neat, too, and would probably deal well with occlusion
i was about to say something dumb about convolution because my brain keeps going there
β@eniko Iβm not sure how you would without more data.
block: a lit room will glow from the outside unless you have per face data
vertex: if one face can see a light but not the adjacent one then the vertex is only lit from some angles, you donβt just need per vertex you need per normal per vertex
@bnut oh, so there's two steps here
1. a block knows its light level
2. when the geometry is sent to the gpu, blocks are uploaded as faces with two triangles each, and those faces are lit based on the block light level of the adjacent block
minecraft further smooths this out by having vertices take an average of the block level lighting for the 8 adjacent blocks
@eniko ah ok, so each block has a light level and the faceβs light level is, for example, the minimum of it and the adjacent one? Seems like a nice simple starting point, and you can add more complex lighting later.
Although your probably need adjacent chunk info for that to work which may ended up loading a bunch of info to the GPU you donβt otherwise need for rendering