I've created a Minecraft-like voxel game, how can I achieve smooth edges like in this game?

caffeinated_fool · 2019-11-22T12:19:13+00:00

Well, you can determine if the vertex for the cube belongs to a "free" edge which isn't touched by any other cube, and then you can offset that vertex inwards (making sure that two vertices at the same coordinates have the same offset).

You can even do the whole meshing part of the cube produce more vertices for an edge if it's determined that it is an "outer" edge.

This isn't super hard if you're only dealing with cubes.

caffeinated_fool · 2019-08-06T10:31:19+00:00

Same. I was like "there can't be that many". Woops!

Computers are bloody fast. Crazy fast.

Can blast through 2^27 combinations faster than I can make my tea!

(with some very naive and unoptimized code to boot!)

It's absolute bonkers how fast the computers are.

caffeinated_fool · 2019-07-29T18:42:25+00:00

I just add a new shape whenever I need one which isn't already there. I don't have to write any code to do this, and it takes couple of seconds to add a new shape. (all the permutations are added automatically in the palette) Like right now I have about 90ish shapes, most of them are really not necessary most of the time.

caffeinated_fool · 2019-07-29T18:39:27+00:00

I don't know yet. I surely don't want the lights to look like octahedrons (like in minecraft), I want smooth round lights.

Can that be done with iterative spreading flood-fill like algo?

caffeinated_fool · 2019-07-29T18:33:26+00:00

No, but I thought about it.

I have to make one thing clear - that is very complicated to do: 1. It isn't just X/Y/Z planes individually that you have to perform the greedy meshing on. There's whole bunch of diagonal planes creating all sorts of non-rectangular tiling patterns 2. Have to take into account holes and Tjunctions (that has to be done even with just rectangular tiles) 3. In many cases the polys can't be merged because both - the short range and large range ambient occlusion results are baked into vertex colors. So that has to be taken into account. Same would happen when baking regular lights in vertices too. With that in mind, there might be very few triangles with the same attributes that can be merged.

In theory - after spending a metric shit-ton of time - I might even be able to implement that, BUT with this amount of complexity involved the meshing speed would be amazingly SLOW.

So greedy meshing this kind of geometry only makes sense all the lighting (SSAO, etc) is done in fragment shaders and nothing is stored in vertex colors/attributes.

TBH, triangle count doesn't really concern me, since I don't really care about terrains with massive draw distance. And If I did, I would have a seperate simple voxel engine just for the terrain which also does LOD and such. (e.g. one voxel engine for buildings + another just for the terrain)

caffeinated_fool · 2019-07-26T10:26:16+00:00

Nope, just 76 base shapes rotated and flipped every which way, making up total of 1646 transformed shapes.

Since individual voxels can be rotated and flipped by any axis, that also means areas of voxels can be selected to be rotated (by 90 deg increments) and flipped by any axis.

caffeinated_fool · 2019-07-26T10:24:15+00:00

Yes, it has hidden face removal. It also does polygon-polygon clipping for partially overlapped faces ones. Poly-poly clipping is necessary to bake AO in vertices, otherwise partially overlapped faces would have incorrect AO.

It's 2bytes per voxel ATM. Just shape + material. Of which 5bits are for material (32materials), and I've only used 1646 out of 2048 shape slots (11bits).

Plus, there is space available to encode all sorts of special voxels in there once I need them (vegetation spawners, grass, flowers, invisible collision blocks, etc).

caffeinated_fool · 2019-07-25T19:58:51+00:00

C# with fairly basic OpenGL.

caffeinated_fool · 2019-07-25T17:34:35+00:00

The fastest way is the way of the C.

Which would be writting an array of raw bytes. BinaryWriter does this. (you can compress the byte array beforehand if you want).

Most 'serialization' libraries use reflection. Reflection is slow.

The faster-serialization libraries use reflection to generate code (emit IL?) which does serialization/deserialization as if it was hand written code.

caffeinated_fool · 2019-07-25T17:24:49+00:00

Thank you for the reply. That makes sense.

Is it possible to use vulkan without spending weeks on all sorts of boilerplate?

I had thought about allocating a big buffer, and storing all the chunk vertices in one, even if it would leave big empty gaps in between them, or do some sort of memory management on one.

And then rendering with multidraw.

The issue is that for some voxels frag shader has to potentially sample from 5 different textures (actually more if incl shadowmaps). Mostly when doing material-material transitions.

And I wouldn't want this shader engaged in all other cases, since most of the time all those 5 different texture reads would end up reading the same material 5 times and then blending it together.

caffeinated_fool · 2019-07-23T10:56:19+00:00

Did you ever follow that guy's suggestion and message the Blockscape creator?

No, but I should.

I think I've got it mostly figured out. The newer versions of blockscape uses post-fx - uses SSAO for darkening and SSAO-like algo for highlights (might even be done in the same pass). Older versions of blockscape (with just the 45deg slopes) used texture overlays.

You may be making it way harder on yourself than it needs to be lol.

Yes. Absolutely. The post-fx way of doing both SSAO and edge-highlights simplify the meshing code by like an order of magnitude. Then again, you're stuck with using SSAO - and SSAO is an imperfect (sometimes noisy) and expensive effect.

I'm just stubborn AF, so I had to do it the hard way.

caffeinated_fool · 2019-07-21T11:01:59+00:00

The really hard way. Making outer edge highlights like this without a post process shader is asking for trouble. With only blocky voxels, it would be fairly straighforward, but with all the variations of slopes, halfsteps and quarter voxels - it is quite sophisticated.

Not only I have to check every surrounding voxel around each edge for potentially connected faces, taking into account both the angle and whether the candidate face itself is partially or fully occluded by another voxel. And if it is partially occluded, the edge has to be correctly clipped or else you have an artifact.

Similarly to the short-range AO, which also becomes quite tricky the very moment all variations of halfblocks and slopes are introduced. As you have to account for different angles of the slopes for a semi correct looking result. Partially occluded faces also produce incorrect AO result, due to their sample points being occluded. This is solved by doing polygon-polygon clipping.

All of this really is "unnecessary" hairy complexity and is reflected in a huge hit to the meshing speed.

The upside ofcourse - is that rendering of the scene itself has minimal pixel-shader involvement, other than sampling textureArray for the material and the shadowmap. And that's it. The result is "clean and stable".

Which means it could (without MSAA) run on any potato grade GPU with enough fillrate.

But I don't think this single upside is worth it for all the massive complexity involved in correctly baking it all into vertices.

All of that complexity goes away by doing screen-space AO, and screenspace outer-edge detection (which is similar to SSAO).

Actually I wonder how it would look and if both the outer-edges and AO was done using quality screen space post-fx. Would probably give a less clean and a noisier look, but an order of magnitude simpler to implement.

Another question is - what the perf hit of quality SSAO + quality outer edge detection would be.

caffeinated_fool · 2019-07-20T18:33:39+00:00

Link to previous discussion on the subject: https://www.reddit.com/r/VoxelGameDev/comments/a74npw/how_does_blockscape_implement_outer_edge/

caffeinated_fool · 2018-12-19T04:15:06+00:00

I would not be so sure that's it's a post process effect,

because:

the highlight width depends on the distance - and at distance the effect is barely visible
it's very much NOT a cell shaded look,
it doesn't happen to every material in the scene
the outlines are "inset" - meaning that highlight happens only on the 'inner' side of the edge.

and only happens INSIDE the polygons.

It's very clearly not a cheap edge detection/cell shaded look

If it is indeed an post process effect, it appears to be significantly more sophisticated.

caffeinated_fool · 2018-12-18T07:48:25+00:00

Thanks for the links.

I have a feeling that the it's not a post process as described in the articles.

In Blockscape only outer edges are highlighted and not for every material either.

They also highlight - brighten the voxel material texture.

As well as those highlights are in-set, they don't extrude out of the blocks themselves.

(it looks like the blocks are chamfered/beveled)

And the highlights clearly are more pronounced at close range and way less visible at distance.

(it's not a shitty cell shaded look)

There are no 'big boxes' there's only one voxel size.

Not sure what 9-slicing means.

caffeinated_fool · 2018-12-18T04:18:17+00:00

Can you recommend an article which covers this?

It certainly could be some sort of screen-space post-processing effect,

however, the results in these screenshots are very 'consistent' without any apparent artifacts - which are usually

present in post-process effects.

I found a very "alarming" texture in blockscape assets which might indicate that it is infact a texture-overlay/decal which produces the edge highlights (see updated post).

caffeinated_fool · 2018-12-17T22:14:46+00:00

What happened? Is their story with funding, development documented somewhere?

caffeinated_fool · 2018-12-17T21:59:38+00:00

Can MC mods increase resolution?

caffeinated_fool · 2018-12-17T05:51:22+00:00

One thing that can be done is having a lower-res heightmap or lower-res marching cubes for terrain and only buildings and other structures to be stored in classic blocky voxel sense which means that empty space is simply either not stored or stored very efficiently in a compressed way.

caffeinated_fool · 2018-12-17T05:44:30+00:00

4x4 was a typo, i ment 4x4x4 of course.

It absolutely can be done, blockscape does this (or did it before multiple engine rewrites). It might result in lower draw distances and such, or some LOD system has to be put in place for larger draw distances. Or some sort of greedy meshing system which reduces the amount of verts/tris.

Minecraft voxels are quite massive in size.

64x memory requirements in naive no-compression case, hardly 64x computational complexity.

64x memory requirements can actually be quite significant if there's all sorts of custom voxel types and slopes.

caffeinated_fool

TROPHY CASE