The triangulation of the different shapes (sphere, cylinder, torus … plane surfaces) uses the same algorithm with only small differences due to the mathematical dependencies.
If you want to combine different shapes into an inner geometry, it is better to have only one function. This function then uses the appropriate mathematics for the geometry (normal, surface point …).
In addition to the triangulation functions, the construction of the matching fronts (boundaries, holes) causes a not inconsiderable effort. Currently approximately 1 to 1. If other forms are added (torus), the ratio shifts further.
cap: ‘btm’ ‘top’ -> added
Because of the different distances you cannot simply turn the cap and InnerGeometryTHREEi_01.html uses different colors for front and back.
In a test version this was partially already available for Christmas 2019, but the orientation of the forms has been changed to make them identical to the plane cap for the cylinder.
Tested it on Android smartphone and Windows laptop. Even on an old Android 4.4 tablet it works, just takes a little longer.
I get the error itself if I have defined fronts for boundaries and holes incorrectly. Even if they get too close. front[m] is the currently edited object of the active front. idx vertex index, ang front angle there.
let front = []; // active front // front[ i ]: object { idx: 0, ang: 0 }
…
m = getMinimalAngleIndex( ); // front angle
makeNewTriangles( m );
If only one geometry is left in the example, the search becomes easier. Even if you then add the holes step by step.
With me it runs identically under Windows with Firefox, Chrome and Opera.
I’ll get to the bottom of it and have tried a few things. I found some errors in comments, where I changed the order of one thing some time ago. But no real bug so far.
The problem are the fronts that are not really predictable according to the rather complicated algorithm. If something does not develop “correctly”, there are errors in the angles and then also in the new triangles. For example, fronts could cross over. That’s why it’s so difficult to debug. Especially if the identical file is running from the net on one user, but not on another. Perhaps an error in precision?
I suppose it happens with the newly added plane forms ( possibly star, from outline array ) with its complicated fronts. You’d have to take the other forms away.
specifically, since the value is 0 it gets into calculateFrontAngle; there xs* values turn to NaN after coordTangentialSystem() call, causing NaN angles in turn:
In coordTangentialSystem this happens because most of global variables are already NaNs:
Which brings us to getSystemAtPoint function that sets these… there, both getPrevPoint and getPoint pick up the same point because, if you remember, the front array only has one item. You can guess what happens next:
So the question is, how comes front has only one item? I will try to catch this next, but if it takes too long, I will not try too hard
you see, this line is supposed to catch the case where front has 3 vertices or whatever they are, and just make a triangle out of it, however this does not happen, because by the time it reaches there, one of them is already removed by makeNewTriangles and it makes only 2 of them left.
variables iSplit and jSplit are set to 2 and 68 which causes next front length to be 3 (2 first items and 1 last) - so the front length 4 never happens and the code above enters the bug condition.
Many thanks for the exact error analysis. I will have a closer look if the algorithm for such cases can be refined. It was originally designed for implicit surfaces only. They have a relatively even surface and no jagged holes. I think that’s the problem.
After some changes in the stars, I now have an error as well. Identical in Firefox, Chrome, Opera. My assumption seems to be confirmed. I will have to check more closely.
The wrong fronts sometimes lead to the error.
Peaks are wrong, but not an error in the calculation. star center
xSt = 0.5 * R * Math.cos( phi );
ySt = 0.5 * R * Math.sin( phi );
With some console.log outputs I sometimes have deviations in the last 1 to 3 digits. Complex functions with sin, cos … could be slightly different. At one point I have an epsilon to avoid 0. Probably there are more.
I am annoyed that browsers react differently on much more important things, e.g. the slider after F5.
it is not identical. Apart from the design, after F5 Firefox (currently default) remembers where the slider was. The others set it to its starting position. Such simple things I mean.
I have added plane shapes with holes.
