Inner Geometry (Triangulation)

The triangulation of the different shapes (sphere, cylinder, torus … plane surfaces) uses the same algorithm with only small differences due to the mathematical dependencies.

See
Triangulation sphere with holes
Triangulation cylinder with holes

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.

Cylinders can be connected excentrically with tilt and have tilted caps.
A first example https://hofk.de/main/threejs/Triangulation/01_InnerGeometry.html
Use the slider.

Update 25 February 2020
Now in Addon THREEi (https://github.com/hofk/THREEi.js)
https://hofk.de/main/threejs/sandboxthreei/InnerGeometryTHREEi_01.html
Different colors for front and back are realized with the shader @prisoner849. See How to have different colors/textures on bottom and top side of a Plane?

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.

example https://hofk.de/main/threejs/Triangulation/02_InnerGeometry.html

example
https://hofk.de/main/threejs/sandboxthreei/InnerGeometryTHREEi_03.html

GitHub https://github.com/hofk/THREEi.js
examples
https://github.com/hofk/THREEi.js/blob/master/examples/InnerGeometryTHREEi_01.html
https://github.com/hofk/THREEi.js/blob/master/examples/InnerGeometryTHREEi_02.html
https://github.com/hofk/THREEi.js/blob/master/examples/InnerGeometryTHREEi_03.html

4 Likes

:heavy_plus_sign: I have added plane shapes with holes.

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.

https://hofk.de/main/threejs/sandboxthreei/InnerGeometryTHREEi_03.html

see https://hofk.de/main/threejs/sandbox/ last section and https://github.com/hofk/THREEi.js

Hm, that’s weird. What system are you using?

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.

But I don’t get the error. :thinking:

weird, but TypeError only happens in firefox, chrome seems to run it fine (or not… the image does not look like your screenshot):

this happens when getMinimalAngleIndex( ) returns undefined, and it does that because of NaN angle apparently:
Screen Shot 2020-02-11 at 18.49.50

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.

I did a bit more of investigation of what is happening, not sure if this is helpful in any way. So the front[0].ang is set to NaN here:

specifically, since the value is 0 it gets into calculateFrontAngle; there xs* values turn to NaN after coordTangentialSystem() call, causing NaN angles in turn:
Screen Shot 2020-02-11 at 23.25.58

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:
Screen Shot 2020-02-11 at 23.43.01

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 :slight_smile:

2 Likes

yeah, so I found it - the bug is here:
Screen Shot 2020-02-12 at 0.21.36

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.

At the point where following condition is met:

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.

2 Likes

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.


Just noticed (earlier post above)

You have to move the Progress slider

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 );

changed to 0.4

fronts overflow

2020-02-12_09.21.48

2020-02-12_09.52.39

Not sure if the algorithm is adaptable to all possible holes. Possibly, the testing effort in the triangulation loop will also increase noticeably.

the one thing I still do not understand is why it only happened in my firefox

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. :confused:

If you do not want to make any effort and only code (from my example)

<body>
	progress <input type="range" id="range"  min="0" max="10000" value="5000" step="1" style="width: 80%;" >
</body>

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.

the way I see it, you do not want to make any effort now,

after F5 Firefox (currently default) remembers where the slider was

the answer to this and the method to fix it is in my link

to the previous
related Local image won't load


:hourglass_flowing_sand:


Update 25 February 2020
See original post.

Now in Addon THREEi