# LineRenderer on Mesh surface

Goal: Render distance lines between two points on the surface of a mesh-based primitive (i.e. sphere, cube, etc).

Current Solution: Iteratively traverse distance line between two end points and "reverse" raycast through this point somehow. Since the distance line directly connects both vertices through the mesh, the according points on the mesh surface are required.

Ray ray = new Ray();
RaycastHit raycastHit;
ray.origin = posOnDistanceLine;
ray.direction = raycastNormal.normalized;
// Reverse ray since we can't raycast from inside the mesh
ray.origin = ray.GetPoint(1);
ray.direction = -ray.direction;


Lines are then drawn using Unity's LineRenderer which is being populated with positions of vertices whenever a change in normals (to previous raycast) is identified.

Issues:

• Horrible performance (as 100 rays are cast whenever the end points move).

• Solution doesn't always work and produces unexpected, jagged lines / points.

Question: Is there a better approach to implement this?

• Do you have any constraints on the mesh shape / topology? Solving problems like this on the most general case can get quite thorny, but if the meshes are generally "sphere-like" in some sense then there might be much more efficient options. – DMGregory Feb 27 '19 at 23:55
• I'd appreciate the algorithm to be applicable for common 3D primitives such as cubes, pyramids, cylinders and spheres. The idea is to give the user the possibility to measure simple shapes. – Adrian MK Feb 28 '19 at 0:09
• Ah, so does this solution also need to report back the distance traveled by the line? (For instance, I can imagine a shader-based solution that will draw the line on the GPU as part of rendering the mesh, but it will have no concept of length it could report back to the CPU) – DMGregory Feb 28 '19 at 0:12
• Yes, unfortunately, to overly complicate this task, the distance traveled by the line needs to be approximated as well. Given my current solution this is done by summation of the polyline defined by vertices in-between those two user-defined end points. It suffers from performance issues though and even if that's the only feasible solution, I can't seem to fully make it work. – Adrian MK Feb 28 '19 at 0:16