SpiderPig

Thanks I had no idea it could be done that easily in GIMP.

Thanks I'll try it!

I agree, its a bit messy. I could merge vertices in a 2nd pass but I think it'll be a bit slow - or maybe it could be done in one pass as I create the vertices... but Surface Nets should make better geometry because the vertices should be relative evenly spaced, and there will be less triangles too. I'm working on it now so should have some results soon.

I'll admit, once there are textures applied its not too bad. I still think it could be better though.

Found this. The normals here don't look too amazing. I think they're smooth shading, kind of looks like it. https://www.youtube.com/watch?v=pI61q7q-2HE

Love the Model::Save() method. In blender I confirmed there is no double up on verts, all triangles are sharing what they should be. These are the exported normals. Using blender to recalculate smooth shading gave no visual difference. I thought they should look better than this? Maybe this is another pitfall of marching cubes. Too many small thin triangles!

I've decided I will write a method that saves a voxel terrains component as a mesh so I can do some more testing on it in a separate program. I'll upload some results and hopefully find what I'm doing wrong.

Getting some mixed results with this. There are no double vertices in the mesh any more (99.9% sure ) and this is with model->UpdateNormals(). This is the result. I've outlined the wireframe with red. It seems that if the triangles are really small it gives sharp results.

Fixed a few issues. I was only allocating enough voxel memory pages for the final level of subdivision that represented the surface. I didn't take into account the fact that I needed space for the all their parent nodes too. Also have finally removed double vertices with the TransVoxel method. In one scene there was 108k vertices, after the fix it went down to 30k. About a 72% decrease!

This is a 2k Voxel Terrain with tri-planer texturing. It's just diffuse right now, and the red is an area that will be textured differently. It's coming along nicely. I think I'll work on normal maps and smooth shading. The LOD algorithm needs work, the detail in the terrain falls off too sharply I feel.

Issues disappears when I delete the directional light.

I wonder if it's too much to ask for a temporary solution for this? Just the ability to get the index the material is stored in the shader is enough, I can do the rest and send it to my shader. I'd like to get a nice material up and running for the voxel terrain. I'm just guessing at what the material index is in the shader. It changes though as the game grows though.

I just tried it and it made no difference. I tried a size of 32 and 8192.

Hmm, I might have been wrong about what was causing the issue.

Thanks for you help too Josh. Your pointing out what should have been obvious to me pushed me in the right direction.

I believe I have found a solution. If the node's corners are all above OR all below a surface (so a voxel index of 0 or 255) then the corner with the shortest distance is retrieved and it's distance is tested against half the radius of a sphere that encompasses all of the nodes corners (the distance from one of the corners to the centre of the bounds). This way it ensures that the surface is not within the bounds of the node. It creates nearly double the amount of nodes, and I dare say 30 to 40% of them don't represent the surface, but it fixes the gaps in the mesh and it's still fast. Exploring the 4k terrain only uses about 100k nodes so it's not bad at all. Fingers crossed it holds up!

Thanks I reckon they'll come in handy. I think what I really need to do is ray-march the surface so I can get a point that is on the surface and then I can test that against the node bounds. For now I have taken a simpler approach which is to average out all the corner distances and then test if the result is less than the radius of a sphere that enclosures the bounds of the node. It should solve the problem at the cost of creating a few nodes that aren't actually needed.

After the quicker AABB test I might be able to use the circle (or sphere) intersection points.

...did you know that never crossed my mind to encapsulate the whole SDF into it's own bounds.

My epic MS Paint skills tell me that the rays would not go through the origin. They would all meet at different points and even their intersection points would (in this case) say the surface is outside of the bounds.

A better description of what I'm looking for might be "AABB intersection with a Signed Distance Field".

Kind of, except I only have the distances from each corner to a surface. I need to turn those 8 distances into 8 points, or just one. Then I can check against the bounding box.

Each corner distance isn't a distance to the same point on the surface either, pretty sure it's just the closest point, whatever that may be. But - I'm pretty sure all distances will go through a common point - the sdf's origin. In this case the circles origin. 🤔 So maybe if I get a vector from the corner to the SDF origin; multiply it by its distance to the surface and the add it to the corner's position I could then do a simple check to see if that surface point is inside the nodes bounds or not. If the result is true for any of the 8 corners then that would be problem solved. Sounds too easy though. 🤔

I wonder if anyone here has heard of a way to do this? I'm sure it's possible somehow... In voxel terrain the 8 corners of a node are tested against some user function that defines a surface. A Signed Distance Field is a perfect example of this. Each corner tests it's distance to the circle's centre and subtracts the radius to get the distance to the circles surface. If the corner is above the surface, it returns a positive value. If it is below, it returns a negative value. If all corners are above the surface, the node is discarded because it doesn't represent the surface. It's the same result if all the corners are below the surface. Thus to check if a node needs subdividing further or if a mesh should be made inside of it, a bit flag is set in an unsigned char that corresponds to the corners index. So a node has a voxel_index which ranges between 0 and 255. 0 means all corners are outside the surface. 255 means all corners are inside. Anything between and a marching cube table is looked up to see how a triangle mesh should be created inside the node. Right now I do not use nodes with a voxel_index of 0 or 255, because both of these cases understandably do not make any triangles. However, in the 2D example below there are a few cases where a voxel_idex of 0 still needs to be subdivided (it won't represent a mesh at all, because the surface doesn't intersect an edge) but it does need to be subdivided to a lower node size because chances are high that some of its children will represent the surface. Finally I reach my question - the green squares are cases where the node should be subdivided because the circle intersects the edge or is inside the square. However all corners are outside the surface in all cases so the voxel_index is 0 and is discarded (creating holes in the final mesh). The black lines are distances to the surface and are all positive values. I wonder, knowing the corners positions and the distances to the surface can it be determined if the surface exists within the square? I was thinking if I get the average distance and it is below some threshold, maybe the radius of the AABB (distance from the centre to any one of the corners)? I think this could give false positives as it's kinda checking it against a sphere rather than a cube... Curious if anyone has any input. I will be thinking on this for a while.

I think they were my normals actually. I realised I was using an old shader I made so I changed it for my newer one with normal calculations in the geometry shader and I haven't noticed the issue yet. Hopefully that was it.