Zero divide is missing from normalize/normalize3 (glmath.h/glmath.cc) functions

[m-7761]

https://github.com/zturtleman/mm3d/blob/master/src/libmm3d/glmath.cc#L875-L892

(Also found inline in the header and a Quaternion method.)

FWIW I was just testing the "Boolean" (model_bool.cc) code (adding texture coordinates to it) and it produces 0 length vectors. TBH I'm surprised this hasn't been an issue before now.

[m-7761]

Sorry, if you're interested here's some code for the Boolean function. I'm making an effort to fix the many editing functions that disregard texture mapping.

BTW, there second block of code prevents Model::booleanOperation from processing the split off triangles since it uses the same list for this. I get the same pattern in my test scenario (see update/note in next reply.) I think something that's missing is when a triangle is fully inset (like a stencil) inside a coplanar triangle. I suspected this wouldn't work because only two vertices are generated when cutting triangles, and this would need three. I think this kind of stenciling should be supported since it's very useful. Just another thought. (What happens is the inner triangle's normal/winding is reversed for some reason--some other part of the CSG logic I presume--but no cuts are made.)

Anyway, it's a wonder Kevin did all of this work but didn't bother to factor in texture mapping. He must've been quite a character going by a lot of the code and programmer's comments.

	//2022: This is new fix up code for texture mapping.
	//I couldn't find a way to make it work without the
	//normal vector not being normalized, so the 
	//https://www.scratchapixel.com/lessons/3d-basic-rendering/ray-tracing-rendering-a-triangle/barycentric-coordinates
	float st3[2][3];
	model->getTextureCoords(ut.tri,st3);
	float st1[2],st2[2];
	{
		auto &v0 = *(Vector*)ut.coord[0];
		auto &v1 = *(Vector*)ut.coord[1]; 
		auto &v2 = *(Vector*)ut.coord[2];

		Vector edge1 = v2-v1, edge2 = v0-v2;
				
		//auto &N = *(Vector*)ut.norm;
		double denorm = ut.denorm;
		double N[3]; //Un-normalize N?
		for(int i=3;i-->0;) N[i] = ut.norm[i]*denorm;
		//Revert saved length to N.dot(N) and prefer 
		//reciprocal for optimal division down below.
		denorm = 1/(denorm*denorm);

		for(int i=2;i-->0;)
		{	
			auto &P = *(Vector*)(i?nc2:nc1);
			
			//NOTE: normalize3 could be skipped if N wasn't
			//itself normalized... in which case u/v need to
			//be divided by N.dot3(N).
			double u = denorm*dot3(N,edge1.cross3(P-v1).getVector());
			double v = denorm*dot3(N,edge2.cross3(P-v2).getVector());
			double w = 1-u-v;

			float *st = i?st2:st1; for(int j=2;j-->0;)
			{
				st[j] = (float)(u*st3[j][0]+v*st3[j][1]+w*st3[j][2]);
			}			
		}
	}

	bool setUt = true;

	int group = model->getTriangleGroup(ut.tri);

	// now add the remaining triangles to the list
	for(auto&ea:ntl)	
	if(model_bool_isValidTriangle(model,ea.v[0],ea.v[1],ea.v[2]))
	{
		int tri; if(setUt)
		{
			tri = ut.tri; setUt = false;

			model->setTriangleVertices(tri,ea.v[0],ea.v[1],ea.v[2]);			
			model_bool_initUnionTriangle(model,ut,tri);
		}
		else
		{
			tri = model->addTriangle(ea.v[0],ea.v[1],ea.v[2]);
			if(group>=0) model->addTriangleToGroup(group,tri);

			model_bool_UnionTriangle nut;
			model_bool_initUnionTriangle(model,nut,tri);
			utl.push_back(nut);
		}

		float st[2][3]; for(int i=3;i-->0;) //2022
		{
			float &s = st[0][i], &t = st[1][i]; 
			int cmp = ea.v[i];
			if(cmp==v1){ s = st1[0], t = st1[1]; }
			if(cmp==v2){ s = st2[0], t = st2[1]; }
			if(cmp==v3[0]){ s = st3[0][0], t = st3[1][0]; }
			if(cmp==v3[1]){ s = st3[0][1], t = st3[1][1]; }
			if(cmp==v3[2]){ s = st3[0][2], t = st3[1][2]; }
		}
		model->setTextureCoords(tri,st);
	}

	if(setUt) log_error("No valid triangles in any splits\n");

[m-7761]

EDITED/UPDATE: Please disregard the (stupid) bit about the outer loop (I've removed that code and struck out that sentence from the previous comment/reply.) It's obvious that the split off triangles are still required to fully represent their source triangles. I'm sure the originals could be retained in a non-destructive way, but the splits themselves would still have to be applied in sequence. (As opposed to all at once.)