2024-07-28 0722 EDT it seems it would make sense to add shaft_radius to GearProfile, but what if one wanted a d-shaped shaft or something? with the current approach of using templated functions, this would then make GearProfile a templated class. maybe a std::function could work here. or a curve object which would be normative or it could be passed into the draw function gear shapes often have things added to them, like a second gear of a different radius, or a larger part it might be more useful to have it be generally composable to other surfaces or such this would mean providing a way to get the outline. and drawing the face of the gear in outer code; this code would only draw the edge of the gear we had an idea of, instead of using min and max, we could provide instead the initial buffer. there's some question of whether or not to do the factoring focus right now, mostly related to producing success but there is of course potential helpfulness and past request. can we resolve the concern of representing closedness of the curve and points. in 3space, we want to share duplicate points. not totally sure how to do this. in 2space, we want to be able to provide whether or not duplicate points should be output. this is slightly less of a concern since the issue only happens at the tails which are easy to find. ok in 3space if we passed a complete surface, we'd likely have a duplicate or shared output point, but it might not be a shared parameter that's interesting, the current degenerate point code might find it, for example ok so detecting duplicate result points might help with that ... what if we passed in a curve, and wanted to append to that curve with another. we wouldn't want the second call to regenerate the first point. you could pop it before you pass it ... given some complexity and issues i think it might be ok to assume that for now the current approach is double-calculating points between ends, but i think this will become more clear if the parts are connected into one curve in a function somewhere somehow. it looks like the calculation of the initial points is related. it would make more sense to calculate 'key points' that have output data as well as input data, to reuse the output and interpolate the input. ok so how can i make this concatenated curve into a single piecewise curve that could possibly be used elsewhere oh to consider the thing about points and parameters, that organizes the approach to be able to associate across pieces looks like it generalizes to providing the caller access to the implementation detail of how each queued part is considered so it's different if e.g. edge and point data are treated as references ok so the concern around how to expose implementation details [before they are settled upon] can be aided by moving the access to them closer to the implementation. i.e. by passing a single function rather than stitching one together. then the callee has access to all the 'key points' at once and can convert them to its implementation detail inside it, and still ensure all the parts inform all the other parts within it ok so how to pass piecewise we can use precise keypoints because the parameters are preserved. let's just write a function that takes a single one. oh hmm ok so it's a little slow (i think it was?) to calculate the involute angle from the rolling angle. so our 'key points' were rolling angles, but they aren't in a sequence ... they could be 'encoded' in some manner, and then decoded .. i made it simpler; the rolling angles are known in advance and be precalculated. this can even be done before the change. so now the code only has one duplicate point at the end. .. it has different params. it may be a little complicated to handle in the 3space approach, but it simplifies the space. ok so something i'm noticing here is: - 3space points are associated with shared points - 2space parameters are associated with independet triangles corners because triangles need proper interpolation across them but points want to share identical location data sadly also: surfaces include tail points because triangles need to span the final strip so it could make sense to have the curve be closed, and also add a structure to it that provides re-reference of the closing point - 3space data, points, are shared between triangles - 2space params may be unique to triangles - note, previously tesselation was a static member function of the internal data object. this could work to expose it. - 3space data, points, are shared between triangles - 2space params may be unique to triangles i don't want to change the algorithm too much so the [code attack doesn't use instability to make it very hard to recover something that works] but the current approach uses a list of points first, rather than a list of triangles, despite using the list of triangles later. we do want to migrate to a list of points referenced by triangles. let's make a list of points out of the input. or, maybe it could make sense to take different input since it isn't used yet. how about a list of parameters, and a list of triangles that index the parameters? [shows how mat32 was questioned :s] then the eventual internal structure could maybe be triangles that reference parameter points from a shared list unsure it is a little simpler if we stick with mat32 but find duplicate points within it we're going to try this because it makes for less uncertainty and instability emotionally adding support for taking the mean with nan and requiring the passing of initial triangles may make it unnecessary to detect degenerate points .. 1105 code running with global function with local structs now 1156 so the surface code can be simplified if there is a plan to not draw the face. the face would be provided as a curve in 3-space maybe? the callera could maybe use the 2-space curve to calculate the face. we could provide methods to give its pos maybe unsure as a function of orientation. ok it looks like we'll want to pull out the gear profile curve before modifying the surface tesselation to use it the profile curve has state, the min/max rolling angle. i guess this would be cached on hte class in normal styles. it could also be created when the curve is requested not sure if that would work, would be a strange return type, i guess auto, i guess an auto return type is ok it seems nic eot have it be a flat function might need some time or space was considering caching the rolling angle i'm guessing this would be based on the tooth count and pressure angle, both attributes of the meshing no, the angular width of the tooth is a function of the gear profile. i guess it can be a class rather than a struct. ok now uses reusable gear curve in 2d this may significantly simplify the helical code? maybe not? let's make a helical surface function like the involute face function ok. it now makes the surfaces using curve functions and such. how do we make the caps now :s were thinking of some way to export the curve to fill with a cap. a cap filler might for example take radius and angle, and pass the angle to the cap function. so the confusion is between 2space and 3space the cap bound is still in 2space. this is converted to 3space by adding the center and multiplying by orientation. i'm thinking this might be easier if transformation were left to the caller and a norm were expressed of having all objects in object-space, and the caller transforming all the points. how then would the side or face things work or look? well it would be clearer to know where the face is physically located. you could then make a surface function prior to transform, to make them i'm curious why it was that we didn't pass a function to the thing, though, and have it fill the front and back in using the bound function one reason was for generality, to have more objects that share a surface like a gear of two different sizes, or a ring that's part of a mount does seem a small reason, but if we think of objects as sequences of surfaces with things placed in areas at the surface, it makes a little sense you could think of a ring that's part of a mount, as a mount that has a ring in it, and gears of two different sizes, as a cyliner with two gears as its surface i guess ok so we can produce the 3d points but we still have an idea of uv coordinates kind of. the gear edges are positioned, and oriented, in some other uv coordinates. when drawing around those, the gear edges that overlap them are needed. gears are basically radial things, but could also be x/y/u/v things the math wasn't done that way 1613 ok so it would be nice to get a radial function of the gear, maybe more useful/nice than a radial microdelusion? than a list of points in 3space ... as a function of the radius? say we put the gear in a square. a square has xy=uv roughly we can put the gear there, but it's uncertain how to draw the bound. we just need some parameters that connect them i guess i might put x=0.5 y=0.5 as the edge of the gear ...? or one could convert to radius and angle. this seems to make more sense, to convert the square to radius/angle and then start the radius at r=0 where the gear edge is we're doing radial things anyway :s so maybe it would have been much better to pass a function, we still could, things can be unsure reviewing the file could reveal a further (smaller i think) refactor maybe but it shouldn't be hard because we already have a curve in 2space that takes radius angle we can make one that outputs 3space and takes orientation etc. whew weirdly hard to reach idea. now we can use involute_cuvre inside involute_surface ok so what I'm realising is that this is the exact same function as the surface function. it's simply evaluated at the depth bounds. we could make the cap with that. ok so that gives the gear bound; how do we find in a radius ...? how make surface using things. other function might make easier. i think passing a shaft function would be really helpful :s this could even be used inside another surface. so we can make 3d points as a function of angle and depth if the shaft function could do that too it would be helpful as we could interpolate between them ok it's notable the profile could also take a shaft function. but all that's needed there is to draw it, it doesn't need to do anything with it. 1648 it's looking really good but is continuously tesselating without regard to accuracy as far as i can see so it seems it could be nice to set a breakpoint on something a number of the points are supposed to be in the XY plane, so maybe we can check if all the points of a triangle are in the XY plane we have gotten really far. remaining are subdivision issue. - the subdivision is not stopping when not needed - the subdivision does not inform neighboring edges to prevent gaps ok, the line subdivision is indeed different from the midpoint subdivision somehow it's still coplanar maybe another dot product issue i'm not sure could it be at the edge of the gear or shaft, this would explain yeah params[1] == 1 which means it's the cylinder boundary. makes sense i think it's subdividing the diagonal again is halving the radius and halving the angle not the same as halving the diagonal halving the angle is correct halving the radius i guess is a close approximation let's look at what happned here somehow the midpoint has a positive x when both endpoints have a negative x x of both endpoints is around -0.39 whereas y of one is -1.9 (radius=1), y of the other is -0.415 (radius=0) ok so their x coords are about the same ... and they have really different y coords ... why is the midpoint having a positive x i wonder. maybe i can see i think i'll step through pts[0] = (6.28,0.666) -> whooooooooog got some intensity let's make a file writer then so we were in the middle of troubleshooting subdivision issues (again). the new subdivider is cooler, because it can quickly make a ring gear, as well as various shaft profiles, and the approaches between 2d and 3d are more consistent. the problem is that the surfaces are getting subdivided when they are coplanar. different problem. similar. well, let's have some supper. 1747 maybe we can look at it while eating somewhere somehow. the computer is nearly fully charged. it's exciting it can make gear solids including the ring gear. 1811 ok we're planning to eat while also considering the issue. i guess the first step is to run the code in gdb, and maybe to log the processing of pts where the tri is coplanar with xy tri 0 pts[0] = [0, 0]: <-0.3961,-0.4156657,0> pts[1] = [1.2566, 0]: <-0.418, 0.44589, 0> pts[2] = [0, 1]: < 1, 0, 0> ok, so the first triangle it pushes is index 0, but it then starts processing from the other end when processing starts. tri 9 pts[0] = [6.283, 0]: <-0.3961, -0.4156657, 0> pts[1] = [6.283, 1]: <1, -0, 0> pts[2] = [5.0265,1]: <-0.382, -1.902, 0> so immediately we can see that 2pi,0 is at a different angle from 2pi, 1 i wonder if i can see that in the stl it's hard to tell. one can see that there are straight lines that come off the edges, but i suppose they are not radial. there's a good chance we just need to e.g. subtract the pressure angle from the gear curve render angle how would we check that. one would set a breakpoint or somehow break ... prior to this call? need consistent data; seems different this time so i put a breakpoint in shaft_edge and it lets me verify that angle,radius (0,0) => xyz <2,0,0> 0 degrees is the x axis for shaft_edge. is it for gear_edge? it just happened to pass (0,0) to my breakpoint rather than rotating the output coordinates, we could change the angle by which the inner function is looked up yeah. it happens in GearProfile::involute_curve and likely nested deeper. when a different angle is requested, it outputs a rotated point, rather than looking at a rotated structure for the requested point. this might fix the tesselation. it does verify there were not radial lines of subdivision, but rather linearly-interpolated spirals. i think GearProfile::involute_curve is the right function to make the adjustment in. lower level functions are mathematical primitives, whereas involute_curve is intended to render the outline of a gear. might make sense to add to Involute() unsure. thinking on how this would be done, could inform the approach Involute() takes an angle indicating where on an involute curve to draw, and a parameter indicating how rotated the base is, and draws that point is there a difference between the two concerns? i think so ... we are asking for a different point, from the same set of points. so we would ask for a different involute curve, as well as an equally different rotation. i see i think, we'd modify angle by a constant ... no .. i'm running into [working memory issues maybe] we have a set of points each defined by a base angle and a rolling angle. the angle at which each is drawn is its involute angle plus the tooth angle for drawing them, we pick the base angle for the tooth, and then move along the involute angles. well it's not a linear function, is it? we're not calculating the rolling angle every call, so it's a funny curve rather than a smooth interpolation we could calculate it, it might make sense to you could also pursue performing a more accurate interpolation check by projecting the real point onto the plane of the triangle or the triangulated surface rather than just the line it is drawn with given the initial points prevent edges from being interpolated over, it could work well to project to the plane of the triangle. ok, so it's iterating all the angles, and calculating things based on them to generate a point, and it's offset. it's actually intentionally offset so that the first pitch point is at y=0 if we change the angle passed to the function, we get the same curve, but offset ... almost, and basically. so it picks the involute base locations i think reasonably fine but there is an offset euqal to the _involute_angle _involute_angle = 0.402020318, about 23 degrees the first point generated at angle 0 is at an angle of -34.54 degrees it's probably the start of the first tooth, curving upward to get its pitch point at x=0 the teeth are supposed to be spread a quarter of their angular width from the pitch point 18 degrees, half of 36 degrees, half of 72 the first tooth edge curves from around -.303,-.227 to .165,.379 found conflustering, the center is at (-1,0) so that's -31.48 deg to 31.452 degrees. given inaccurate numbers, that's likely an honest tooth span of 63 degrees or so +- the x axis, and we'd want to shift the angle by 31.48 degrees or so it should be 36 degrees ... not 31.48 ... but it could be because we only used 3 digits of precision putting th enumbers in given its radius is only 1.0 so we should shift it by 18 degrees, or a quarter of the tooth angular width counterclockwise and that means the first tooth edge will start at a negative angle or an angle > 360 it's of course possible we will see it is 5-10 degrees wrong if one inaccuracy does not fix the other from not being caused by it i think it might be fixed, what does the stl look like? the edges may be straighter but they are still oversubdivided additionally the oversubdivision of the cylinder side indicates there is a second issue let's check if this one was fixed in gdb observation: because it is a quarter of the tooth width that is of interest, the multiplication cancels and the constant change is 0.25 no it doesn't look like it worked the point is now 0.8999, -0.3243 i'm going to change the center to 0 instead of (-1,0) then i'll run it with and without the shift and look at the numbers i'm starting off with _minus_ 0.25 to see if that's the one angle 0, tooth adjustment -0.25, [0.560896755, -0.23764289] angle 0, tooth adjustment +0.25, [0.954593676558, -0.054856300] so, are those uhh 36 degrees off? 18. they're 18 degrees off. but not exactly. but nearly. they're 19.672669 degrees off O_O thinking a little of walking through the math and seeing exactly how the number comes -- but i'm guessing that if we aren't at ... i'm guessing it has to do with the calculation of the rolling angle. i think it would give more return to look at the cylinder circumference where rotation should not be present let's look for tris where all the distances from the center axis are equal didn't find any, will step in manually looking at the first shaft edge points <2,0,0> <0.6180339887,1.90211303259,0> <2,0,0.3333333333> the first two coords all square to 4 somehow it calculated a difference of 7. i see a sign typo so the question on the shaft edge is, why are vertical/depth line segments getting subdivided. probably from the diagonals getting subdivided sir. that should be the same as the horizontals getting subdivided .... should it? if we have a quad over the side of a cylinder then the parts needing subdivision will be the diagonal and the two horizontals, not the verticals. that's two points for each triangle, so each triangle is subdivided into 4 more. this makes a new horizontal that crosses the diagonal in two lines one from each triangle as well as a new vertical from subdividing the horizontals and the diagonals and drawing lines between. if instead we only subdivided into 3 triangles there would not be a new horizontal. it is notable that given the curvature is only in one dimension, a quad-based subdivision would work much better i wonder what a good way to subdivide is. our current approach is good for plane-like surfaces where the input coordinates are linearly transformed when projected to the plane what if we only subdivided one line at a time ... the verticals are valid, but the new horizontals are not needed actually, i think this case could be detected because one of the new points is a linear interpolation of the other two often a cylinder is made with extrusion and only the curve itself is subdivided, not the cylinder surface [i would expect a good subdivider t ... well i'll think about it a little i guess and it's notable the current solution has workableness the google AI answer that i didn't request but had an idea was to compare the side with the largest error to its opposite vertex. this is higher for the vertical axis than the horizontal on the cylinder it would then subdivide the horizontal first, and could then review again it's probably a simpler algorithm! so the two points have the same error, but one is farther from its opposite vertex ... when the horizontal farther one is subdivided, it doesn't quite fix it. A_B_C | /| D E F points A, B, C, G, H, I are all good. |/__| G H I A_B_C |\ /| D-E-F This is the correct subdivision, with one new vertical added. |/_\| Note there are no horizontals between B,E,H. (the chart is sideways regarding a 3D cylinder from D to F). G H I Our algorithm adds those horizontals, subdividing each triangle into 4 more triangles: A_B_C |/|/| the center triangles it adds specifically cross the correct subdivision. wrong: D-E-F |/|/| G H I A_B_C |\ /| D-E-F it subdivided GC at E because it was off. |/_\| as well as CI at F because it was off. G H I it only added points that were off, no others. the subdivision CEF and DEG are intuitive and the same between the approaches, because they contain a corner and the new midpoint. is this subdivision correct? A_B_C |,'/| D-C and G-F are drawn D-E-F |/,'| G H I i suppose that either subdivision is fine, but the previous one seemed more balanced the key is to only add points that do need subdivision not sure why it is not finishing now seems like some of the triangles are made wrong, it keeps subdividing forever maybe a wrong midpoint i'll find be eliminating 3rd one is wrong it's the same as the second one diag must not be changing maybe it seems to relate to the number of triangles more than 2 vs 3 it fails to finish when both 2 and 3 are included i don't understand a cause of it. i thought the triangles were independent of each other maybe it makes for intertwining results that depend on both paths and keep going, that seems like it would make sense maybe there is a surface engagement that does that is there a pathological subdivision situation? A___B___C A___B___C |\ /| | ,'/| J K L M J ,K L M | \ / | |,' / | D---E---F D---E---F regardless of the diagonals chosen, _all_ of JKLMNOPQ are then subdivided. | / \ | | / ,'| not correct. N O P Q N O P' Q |/_____\| |/,'____| G H I G H I A___B___C | ,' | J ,K L M |,' | D---E---F this is the correct first subdivision. the first one i said was correct perhaps is not. | ,'| the point E is not included, as neither is the original diagonal between C and G N O P' Q | ,'____| G H I although we did originally subdivide E, because it was not represented well by CG, it is represented fine now by DF. it seems very helpful to draw lines in directions of minimal curl but this may be a situation where it would make sense to manually specify the subdivision here. to subdivide the curves and draw extrusion between them the problem then returns to the earlier problem of drawing radial lines well. the earlier problem is similar to this one: the face is planar, so edges can be drawn only between the end curves fine. an approach would be to tell it to subdivide along one parameter before another. like quads i suppose. but you could do it better with tris. so there are ways to resolve it kind of. battery 27% may head back inside or something. is the current addition bad ?? it seems weird it freezes up. let's walk through it. to keep stable state. there are 100ks of triangles and it is almost certainly in its pathological area total_subdivision = 1 subdivided_edge = 01 adds two tris, <2,0,01>, and <2,01,1> then engages i assume <2,01,1>; it needs no subdivisions and is popped then engages i assume <2,0,01>; it is also popped as complete new triangle; two subdivisions, so it's using the new code diag=1 retained_edge=0 adds three tris, <2,20,12>,<12,0,1>,<20,0,1> then engages i assum <20,0,1>; 1 subdivision, subdivided_edge=20 1 subdivision immediately again; subdivided_edge=01 pop; pop; 2 subdivisions, retained_edge=0 now we've recursed, we're back on retained_edge=0 which was the retained edge above pts[0] = [5.34,.5]:<0.791896,-1.386685,0> pts[1] = [5.026548,1]:<0.6180339887,-1.902113,0> pts[2] = [5.131268,0.833333]:<0.692194566,-1.69582,0> these points are all pretty distant looking. surprised that 01 is retained :s. the triangle is also xy planar, it's not on the side of a cylinder at all midpts[0] has already been overwritten by line_midpts[0] well maybe i'll go indoors and keep looking at it thinking of trying the single-subdivision scheme - try single subdivision scheme - project line midpt onto plane of tri rather than line, to check fo rinaccuracy. this will help in flat spirals. ok i did single subdivision i think and it is still loopin' forever ok logged 2 tris complete, 3 1x subdivisions, repeat so it's breaking a triangle 3 times, and only completing one of the breaks, making it continue forever [on the 2nd break, the 2nd part of that triangle is rebreaking forever it actually shows the same numbers over and over again, it seems so if we can look at them specifically, it should reveal the bug reminder, the second subdivision is producing a triangle that is replicating itself 1. it breaks between 0.871,0.076,0.975..0.930,0.219,1.0 at 0.903,0.143,0.987 2. it breaks between 0.836,0.017,0.963..0.903,0.143,0.987 at 0.871,0.076,0.975 ok i'm noticing that the second triangle outputs a coordinate that was in the first. i think this should only happen for a degenerate triangle it might relate to param weirdness/nonlinearity/such, seems somewhat likely ok the third point of the first triangle is between the first two points of its subdivision there must be a parameter propagation error happening. let's output the parameters too i am seeing a degenerate triangle here. triangle 4 has the same parameters for points 1 and 2 .. as well as the same coordinates it's detected on completed triangle 63 or so a midpt was made the same as a corner pt the first coordinate of the params is the same between the points, and the second coordinate only differs by float precision. so averaging them made a duplicate parameter how can it possibly not be well approximated when they are that near looks like projection error, i guess this would happen if we were bisecting a side that did not need to be bisected. the projection is identical. it shouldn't be bisected. it turns out it is happening because the third vertex is the midpoint of the other two we can partly derive this would happen in a cylinder situation with <3 bisections a long skinny triangle will have one coordinate approach the opposing edge not sufficient ... confused ... it looks like we are indeed on the cylinder side, params[1] == pt[2] [internal upset 0= 6.283, 1: 0.930, 0.219, 1 1= 6.178, 0.975: 0.871, 0.076, 0.975 2= 6.230, 0.987: 0.903, 0.143, 0.987 01 projection = 0.899, 0.145, 0.987 01 real = 6.230, 0.987: 0.903, 0.143, 0.987 ok i see 2.params[1] is the mean of 1 and 2 and i see that 2.params[0] is the mean of 0 and 1 so the points should be colinear. no, the 3d points aren't colinear. but the parameters are. projecting the subdivision to the triangle plane should fix it i think, in this instance i could be wrong ... these are really distant points to be bumping into this it's a mapping between parameter space and euclidean space the parameters are colinear, but they curve in euclidean space so a triangle is drawn well that's not a very useful triangle. the parameters should be used as the edges of some other triangle. well it's an interesting puzzle noting the second parameter is the z coordinate, and the first the angle ok so points 0 and 1 have wide angles but one has a low z coordinate then point 2 has an angle between theirs, and a middle z coordinate could/n't you do that in euclidean space too ...? (3,3) (1,1) (2,2) it's definitely colinear weird line to draw spiraling around a cylinder. not needed of course what operation brought us to colinear points probably we shrank a triangle to its base because the subdivision of its base was needed ...? it's certainly irritating! i guess a workaround would make sense at this point :/ it's related to parameter space being different from euclidean space i don't have a logical description of it completely, it could be a logic mistake somewhere i'm observing the midpoint between two points was off but the midpoint between the parameters was already present of course that's _after_ we already have a triangle with colinear parameters we can have a degenerate triangle that has area. it's degenerate in the parameter space. but the points are not colinear in euclidean space. it then subdivides until it crashes. because euclidean space differs from parameter space, it is quite possible to generate a triangle that is colinear in parameter space, while trying to shrink euclidean space. it is not intuitive that that would happen frequently at all, but it is here. we would need code that doesn't let that happen. thinking a little bit about the idea of shrinking parameter space rather than euclidean space this triangle could be considered already precise in parameter space because it has no area there. it could be huge! it could have 4000 units of area in euclidean space, but because it is colinear in parameter space it can't subdivide. it should have been subdivided as part of another triangle. when it calculates what to subdivide it should use the parameter distance rather than the euclidean distance, to take the max of :] this did not fix it this is because it's not comparing it with other points. basically it bumps into a triangle that is not very tall and accurate heightwise, but is very wide and inaccurate widthwise. unfortunately the height is 0 in parameter space. the approach of bisecting evenly in all directions did avoid that 2135 why did it bisect the height down so much, or did it start that way? one idea is we simply shouldn't have triangles that are colinear in parameter space i am curious how it got that way it processes about 40 tris before this happens, and it looks like it might be the gear surface so, i am not sure how to handle this, and days are passing by it does seem like a nice hting to try to figure out while coping with mind, assuming we still do that. it would need a lot of neuron movement that karl has worked in past kind of but it might make sense to go back to the other way maybe we can at least check projection to plane how do you project to plane project to two sides of the triangle and add them seems to be in an unstable state now >( we have to go soon thinking how to check for colinear parameters .... dot product? but what if on opposite sides? absolute dot product? ok i think it would be fund to implement a different subdivision function that just connects two curves using a triangle strip. this would address all the applied concerns, even though the theoretical one remains unresolved. intense thing, we wonder if coding inhibition resonated via recent police officer engaging, seems conventionally unlikely, unknown the nice thing about triangle_disc is it could very easily connect a circle to a square! ok again a remaining thing is a little big. it would make sense to generate the edge of the gear first and use it as initial points; but this leaves out helices. really, these edges are really meaningful, they're how surfaces are connected. but we also don't want to overcomplicate the code as more time is spent on it. maybe it would be helpful if the tesselater stored edge lists as it ran. this seems pretty helpful. but it might make sense for now to just tesselate it independently. the disc generator is nice but can get an edge case where progressing along one curve is always better than progressing along the other because a step on the other curve is larger than every step on the first curve. not sure why that would happen -- it's morning on monday, i took a shower, it's before 8 this triangle disc stuff works great, but the algorithm has issues right now it's at 17,2 and the second coord is advancing without the first advancing. it started at 1,0 so this is distant from the start area. next = 18,3 dist from cur1 17 to cur2 2 = 0.42 dist from cur1 17 to next2 3 = 0.458 dist from next1 18 to cur2 2 = 0.48 dist from next1 18 to next2 3 = 0.52 so advancing lengthens the distance here; the curves are separating. because they are both separating, it lengthens the distance less to advance the one with less slope. consider one curve inside another. when the inner one shrinks tightly, it becomes distant from all the points of the outer one. in that case, the distance comparison fails. what about considering progression along the curve; maybe along both curves together. we want say to move a comparable percentage along the curves. there's kind of code for that already, not quite kind of how detect this scenario ... 8 9 10 11 -.-.----.---.-- outer ----..--.-.---- inner 2 3 4 5 basically we want to progress around both of them, such that the points straddle each other however, we know there is some point where we can align them. we can say for example that 10 and 4 go together, and do the rest of the strip based on this. we can then calculate our percentage around, and treat that as the goal rather than the distance. but the indices can disalign k i changed it to percentage and it's looping again showing a bug! start is [61,7] cur is [21,7] ct is [0,0]. it's not incrementing ct ok it completes now but ithink it is looping multiple times until the numbers line up exactly its 822 could be wrong starts at 61 7 .. progresses to 9 15 then suddenly considers 0 to be after 15, maybe a 16-long list finally reaches 60 7 and finishes. next one starts at 0 0, does reach 0 0 again after 15 108, 0 109 next number is 0 1, it's hard to tell from the previous 0 0 if it's really a new curve runs until 15 104, next is 15 105 a little funny k shows starts now. first curve 61 7, does indeed run to 61 7 roughly then 0 0, runs to 0 0 then 15 105, it's kind of working it probably has off-by-one and normal issues 2024-07-29 0827 EDT // it's only supposed to stop when the next pair is specifically // the first pair //while (!started || (cur[0] != start[0] || cur[1] != start[1])); //next_pct[0] = ((next[0] > start[0] ? curve[0].size() : 0) + next[0] - start[0]) / curve[0].size(); //next_pct[1] = ((next[1] > start[1] ? curve[1].size() : 0) + next[1] - start[1]) / curve[1].size(); // advance the side that increases progression disparity the least, and draw a triangle with the advancing //dist_next[0] = curve1[next[0]].dist_sqr(curve2[cur[1]]); //dist_next[1] = curve2[next[1]].dist_sqr(curve1[cur[0]]); // the issue here is the projections are not perpendicular. making it 10 times bigger makes there be 100 more triangles i think ok so it can make a simple gear bearing but it involves swizzling hardcoded stuff. it's 0938. let's figure out maybe when rta customer service opens? maybe have food and brush our teeth both? we might send money card to therapist. the next thing on the hardcoded stuff might be to move the helical angles and things into the meshing structure. it might seem a little interesting to undo the change that made the other things into verbose classes, too. this might mean doing very quick calculations at runtime? or passing precalculated values to internal functions? i'll try to send money to therapist. hey we could try to print it at the downtown library 1414 well it's printing and done in 7 minutes, not maybe the best settings for anything i think i need to leave more space between the gears, or adjust the slicer for wider filament or something might be wrong it's fancy but karl always wanted to do cam or lasercutting instead of 3d printing we were wondering about updating the file to output svg for the whole thing. also cam still on queue. these machines are more and more available, that carve wood and other materials like metal so an svg file has a header and a footer, and polygons are closed shapes a quick way to make it happen would be to detect a closed shape by noticing a final point equaling a start point :s the next print looks like there is too much space and planets will fall out. can we do it right so there is 0.3mm between the surfaces? it looks like the units are centimeters. not 'right' as in more extensive design and math, but have it succeed ok it won't look nice. we should add profile shifting ... we want the pitch point of one to be 'tolerance' away from the other so we change the base radius based on the radius it's used at :/