I could be wrong as I don’t consider myself a math expert, but am I correct by saying that due to floating point numbers, when you use the Raycaster to cast against multiple lines (the intersections from one cast, does not guarantee all intersections will be colinear or have the exact same slope?
Here is a jsfiddle example. https://jsfiddle.net/blackstrings/vuca7jnd/3/
This is something I am seeing as part of a bigger problem I am solving.
My hope, was that I could expect the intersections to be colinear in a logic check, but seems like it could be impossible or unreliable due to floating numbers?
if this is the case, what alternatives may you suggest I try.
In such situations, you do not perform an equality test (===) but you use an epsilon or tolerance value. A simple function that compares two floating point values could look like this:
function equal( x, y, e = Number.EPSILON ) {
return ( Math.abs( x - y ) < e );
}
In many situations it’s hard to define a meaningful value for e. If you know the input data, it makes sense to scale the epsilon value based on this information. This approach is actually used in THREE.QuickHull:
@Mugen87 I’ll give this tolerance equality check a try. Looks like a viable option.
@prisoner849 I’ll try to simplify the bigger problem without going too deep as this is rather a unique case. In the app, there is a geometry creation process that handles unique edge-case trimming. The trimming does its job except it sometimes eventually create these kind of geometries. Rather than replace the trimming process entirely, I am hoping to just remove these particular odd faces from the geometry.
Visually you see a straight line, like in the example, mathematically the points don’t create a perfect straight line, thus a triangle is created in the process.
How I can see, on your picture, the face has no neighbours, that can have vertices with the same coordinates as in that face with some tolerance, like in the @Mugen87’s answer.
Thus, if a face has no neighbours, you can remove/delete/do something else with it to not include it in the geometry.
In short, I want to achieve is 3 things.
1 - not have to replace the current trimming code, if I don’t have to (as it wasn’t written by me)
2 - By removing the face, I will overcome the issue of the face showing in the first place (there is a wireframe view of the shape in the app)
3 - The most crucial part, by removing the odd face, I can further separate the geometry into two or more geometries. the geometry needs to be separated for a later process as each geometry represents an actual product. Think of it as 1 product contains one geometry. The app is a material estimator app that later calculates parts or can toss out parts depending on logic. The geometry, holds vital information of the product’s dimension for calculation and pricing thus the reason for separating a geometry if it has loose elements.
By a corresponding calculation I recognize surface, edge or corner. There is indirectly an epsilon ( as divider). Note: in the current revision, the @Mugen87 workaround for raycasting multimaterial is no longer necessary.
