I have been working on a little planet generator by generating a icosahedron and applying some 3d perlin noise to it to generate mountains on it.
Now I wanted to slice the planets vertices at a certain distance from the planets origin. This means I can add a loopcut at a certain mountain height. I used http://www.xbdev.net/java/tutorials_3d/clipping/index.php as a reference for triangle cutting.
It works. But there are a few problems as some cutted triangles have a reversed vertex order which results in some triangles not showing up unless I view them from within the planet.
I also havent figured out how to share vertexes to get smooth normals but thats the next step
Could someone have a look why some triangles are flipped?
I just started randomly flipping triangle winding orders and solved it…
Not sure if you had typos or if there is some other issue, but I enclose a screenshot of my source control diff of what changed from your posted script to the functioning one so you can hand-apply and sorta see if it makes sense.
(Highly recommend you use source control if you are not using it already!)
It’s harder than I thought it would be but I can’t get the vertex sharing properly
I looked at the code where the sphere got subdivided and how the subdivided triangle vertex got their number assigned and it looks to me it should work for the sliced triangles aswell which is the following:
bool firstIsSmaller = p1 < p2;
long smallerIndex = firstIsSmaller ? p1 : p2;
long greaterIndex = firstIsSmaller ? p2 : p1;
long key = (smallerIndex << 32) + greaterIndex;
int ret;
if (middlePointIndexCache.TryGetValue(key, out ret))
{
return ret;
}
Although the normal shading does look better, there are still some vertex sharing problems:
Haven’t looked at your code yet but did you consider that a vertex could be shared by more than two three or even four faces?? You want to tally up ALL the faces that it is shared by, then take that normal as the new shared normal.
ALSO… just be sure you honestly don’t just have two vertices that are vanishingly close to each other, because then you will actually not be able to smooth properly, unless you actually weight the normal averages according to size of each triangle, which would really get tricky, considering triangles can be long and slender, and you care about the direction of the normal sampling.
Not fully sure if I understand you right but I don’t think there are multiple vertices very close to each other. Probably an order thingy again. Maybe it’s out of my league, it frustrates me I suck at math Im still trying
It’s not an easy thing to solve. It requires multiple “depths” of smoothing, not just averaging nearby face normals.
See attached image: the bottom line is the “side view” of the dotted traverse line across your planet, a line that passes two edges. As those edges get closer together, naive averaging of normals is going to produce a sharp normal discontinuity across a very narrow triangle slice (the middle triangle), such as when the line of traverse taken lower and lower on the top three faces. Does that make sense?? In any case, that’s just one possible answer as to why you might still be seeing a discontinuity in normal.
Hmm, it’s hard to understand. I thought that shared vertexes have automatic smoothing as it is an avarage of all neighbours.
I updated the code with a new way to calculate the intersection points which makes the slices a lot smoother.
Unfortunately the shared vertex problem persists.
Edit: I exported the mesh and imported it into Blender > Recalculate normals… Stays the same
Im still trying 
