hi, i have seen this often in tinkercad objects, there are sometimes these small lines that are seen on the object so does this mean that there will be a problem like missing layers, etc when printing? Is it possible to fix this? thanks
Date
Votes
22 comments
-
Permanently deleted user Hi Trudy,
Those small lines are caused by precision issues. In general, when you have coplanar faces and you make a group, all will go well and you won't get those lines. There are some cases in which the precision of the mesh kernel will have problems to merge faces and you will see these lines. You can try printing a model with this issue and most probably you won't notice it.
-
Permanently deleted user These "precision issues" play havoc in many, many cases. Guillermo, I know I've sent you many pictures of these problems during the last 18 month. When are these issues going to be resolved? Is a fix part of the T2 release?
- Bob
-
Permanently deleted user The precision issues can go away at the expense of considerable increase of calculations. The question, as usual, is how to find the balance between a service that performs and a service that delivers better results but takes more time (a lot more time). When Gen6 was created, some assumptions were made regarding precision. As we discussed many times, some of those assumptions need to be challenged based on the growth in complexity of what gets done in Tinkercad. We have some ideas about how to deal with this post T2, without compromising performance for the vast majority that either doesn't get these issues or is less concerned about them.
-
Cleared Ok, so it is a probability that the model will print out fine but there is still a chance that it might have slight esthethic issues. In this case I would rather search for a model that does not have any lines at all. thanks. have a good day.
-
Permanently deleted user Guillermo,
These precision issues started cropping up about 18 months ago. I had several conversations with you on the issue. First you denied there were any problems. Then for 6 months you insisted it was because Shape Generators were written incorrectly. But when I started sending you screen grabs of flawed stock Tinkercad objects you swore up and down that your team hadn't changed a line of code in the Gen6 graphics kernel. Now it comes out. Though you might not have changed any algorithms, you cut the refinement count to save on CPU costs. This change has been causing users literally countless hours of struggle trying to work around this flaw that you knowingly created, hide from struggling users and denied existed.
- Bob
-
Permanently deleted user Bob, I mentioned that this assumption was made when Gen6 was created. This is previous to the acquisition. We did not change precision to make things faster. I'm saying that for making things more precise, we need more bits and thus more calculations and more time.
-
Permanently deleted user So I shouldn't be able to find any old Tinkercad designs that used to render properly (as demonstrated by STL files generated back in the day) yet appear flawed in Tinkercad today?
-
Permanently deleted user I don't think so, unless there was another regression we are not aware of. I'm just saying that we did not introduce a decrease in precision in order to speed things up. If you have any files that show a change, please send us the old and new STL. I'll check if we can track date of revision out of which the old STL file was generated so we can compare the current state of the file to its state back then.
-
Permanently deleted user You're saying that you have not as yet knowingly made any changes that would create these errors. I think you're also saying that your team thinks they understand the cause of the flaw but are hesitant to institute a fix because of fears that it would significantly increase the CPU (or GPU) cycles needed to service user operations. Is that correct?
I assume these calculations are being done using floating point math. Is it an issue of long to double or double to long double? Or is it a question of ANSI floating point to infinite precision libraries?
Guillermo, this issue is bad -- and very common. Try this...
* Add a stock cylinder to a Tinkercad canvas. Resize it to 25mm around and 0.5mm height.
* Add another cylinder. Resize it to 24mm around and 0.5mm height.
* Align the 2 cylinders centered, then group.
* Rotate the group 45deg along the Y axis.
* All looks good, right? Now refresh the browser for this tab, forcing a redraw. Garbage.
Tinkercad's usability is severely limited by this known flaw. To make matters worse, users often don't know that their design is garbage until after they spend a lot of time creating it, only to sign back on the next morning to find garbage.
- Bob
-
Permanently deleted user Sorry, not long to double, but float to double.
-
Permanently deleted user Hi Bob. Since you seemed to want more details about how things are computed, this is coming from Aki (the guy behind most of the GenX engines in Tinkercad, since the Airstone times)
The issue you describe is one of the compromises we had to make in Tinkercad early on, before I had even started writing gen6. The transformations to basic shapes are applied by multiplying vertex coordinates by affine matrices (4x4) in the floating point domain. The issue touches on something quite fundamental in computational geometry, and I will try to describe it as succinctly as I can at this time.
Contemporary mesh formats represent geometry by vertex coordinates and a bunch of triangles connecting those coordinates. In Tinkercad we chose to use triangle meshes as the I/O format due to an understanding that it was the least common denominator everyone seemed to agree on (in 3d graphics and 3d printing anyway).
Now, the problem you describe is that vertices that happen to lie on a given plane, z=0 for example, no longer are on any single plane after a rotation matrix is applied to the said vertices. This is true irrespective of the number of bits we used in the mantissa. It would happen with 24 bits, it does happen with the 52 bits we have now and it would happen with 112 bits of quadruple precision. What you describe as garbage is floating point roundoff noise at the edge of precision. For some rotations, the outputs happen to line up nicely, but for others like 45, 60 and so on, the sines or cosines end up being irrational and the roundoff noise will show its ugly face.
To its credit, Tinkercad will at least compute a result for you. I agree that it’s in this case not the result you generally wanted, but every other modeler I know of would give you a crash, shoot some vertices to infinities, or just get stuck and leave you staring at the screen forever. None of these behaviors are difficult to produce on commercial CAD programs either (as sad as that may sound). Geometry is difficult and computational geometry in finite precision is much more so.
For Tinkercad (and gen6) one avenue to try would be to move the transformation a step deeper, from the floating-point vertex-coordinate mesh domain, into the plane equation world of gen6, where coplanarity is preserved as a rule. In that domain, a vertex is the intersection of 3 or more plane equations, a line is the intersection of two, and so on, so restructuring the pipeline so that transformations would be applied to the planes could make this problem go away. But contemporary graphics accelerators can not understand geometry in the gen6 native format, they want to deal with triangles and vertex coordinates instead, so we can’t move the entire pipeline to be about planes, and we’ll still end up doing the quick affine transformations during interactive frame rate manipulations in the browser, as that’s all graphics accelerators are good with in the foreseeable future.
-
Permanently deleted user Adding to it, and understanding it's not a solution, my normal workaround is to make sure holes are not coplanar with the solids I'm grouping with if there's any rotation.
There may be some solutions where we can compute on ASM (our solid kernel) or Gen6, depending on the situation. This can get quite complex fast and needs to be done very carefully. We don't want to confuse users either.
-
Permanently deleted user Guillermo & Aki, especially Aki, thank you both for taking the time to respond in such depth so that users like myself, at least the technically minded among us, better understand the root causes of these issues. I'll assume that those still reading this thread are either frustrated enough or technical enough to tolerate some further exploration of this very big problem in Tinkercad. I'll again repeat here for the 100th time that I'm not by any means a graphics expert, though I'm classically trained CS having spent my career in technology. So, again, thank you for indulging in a little practical brainstorming.
I understand the problem in general. I hear you saying that these situations become problematic as a variable representing an angle or other problematic value approaches a limit. The result of one of these calculations goes asymptotic as the variable approaches this limit. Just to keep it simple: like when the divisor approaches zero. When the variable actually is zero, then the algorithm needs to somehow “punt” or crash.
And then I think about the outward simplicity that is Tinkercad. Unlike MCAD packages like Autocad or Solidworks, the range and the level of precision Tinkercad users are able to specify is quite limited. The effective canvas is currently 1,000mm2 with 2 digits of precision echoed back to the user. Angles of rotation are currently limited to 1/2 degrees. While everybody would like to see these ranges and levels of precision increase over time, I think it would be reasonable for the GenN algorithms to assume for the span of the next generation (Gen7?) that, for example, the canvas won’t exceed 100m and precision won't exceed a “small number of decimal places” - 4? 5?
Aki, are you saying that the problem were talking through here remains a problem even with the realities of these small ranges of values and levels of precision? Or might a practical workaround to this challenge be to evolve the algorithms to introduce a “fudge” when a variable comes too close to a problematic value? If this were possible, then striving for a large number of bits in the representation of your floating point variables would perhaps keep rounding issues at bay. For example, 45 degrees might be fudged internally to 45.0001. (Maybe every angle would be fudged by a value outside the user-visible precision.)
Another point that comes to mind for me is the various ways these rounding errors exhibit themselves. Consider the simple characterization I gave yesterday with the cylinder group rotated 45 degrees. The problem is not just that the mesh is not exactly the way that I want/need/expect it to be. A big part of the problem is that it’s highly irregular. Is there a practical workaround that might at least result in a usable, however incorrect, mesh. One that doesn’t jut in and out?
Aki seems to be saying that these errors are birthed at the mesh rendering level of the engine due to the exclusive use of triangles, but not quadrangles. Would using quads help resolve the issue?
Some other common characterization of the rounding errors that I often encounter include what Chistian Pramuk refers to as “cuts” in the mesh. Another common situation shows itself either as orphan bodies, or even as invalid “appendages” in the mesh that jut out from an otherwise correctly rendered shape. Taken together, these faults in Tinkercad are extremely common. It would not be an exaggeration to say that I don’t have any designs with a rotated object that don’t exhibit these errors in the mesh. Worse, my students begin to experience these problems as soon as they start using rotated objects in their designs. More than one of my students have literally walking away from 3D modeling from this perpetual frustration.
Again, I’m shooting blind here, not having any visibility on the code, the architecture, nor internal brainstorming. This problem needs to be fixed, even if my thoughts don't contribute anything new.
- Bob
-
Permanently deleted user Guillermo, you say that your normal workaround is to make sure holes are not coplanar with the solids you're grouping with if there's any rotation. Keeping with the universal contract between software and user -- minimum visible complexity -- it should be Tinkercad's task (or GenN's) to identify when holes are coplanar with solids being grouped together and internally fudge the hole without the user's knowledge. -- And of course remove the fudge if the object is ungrouped.
- Bob
-
Permanently deleted user That logic may work.
I bounced an idea with Aki and some of the other smart people in the team (I'm just the product manager ;) ) and there might be a solution that removes the complexity for users and does not need fudging or any other trick. It will take a while to try and take into production, but if it works, I expect it to be a real game changer.
In the meantime, creating holes with elements that exceed the height of the solids on both sides (if they go all the way through) or one side (if they are subtracting part of the object) does not seem to be such a bad idea. At that point, no rotation will break anything.
My past experience (before Tinkercad) has been mostly in solid modeling for mechanical design and architecture, and even in that world you fear and avoid the bodies with coplanar faces. So I just extended my habit when building 3D with ACIS or Parasolids into my mesh modeling best practices. Again, not saying this eliminates the problem, but it avoids the frustration and the desire to abandon the fascinating world of personal fabrication.
-
Permanently deleted user Happy on the one hand that you can imagine a solution. Not thrilled to hear you say it'll take a long time. You're the same guy who's always saying we should expect this feature or that feature "really soon," only to have it take years. If you say this fix will take a long time, then it will take a long time indeed. But, hey, at least the issue's on the table after 18 months of public denials.
I get your suggestion on how to avoid the flaw, though I don't see that as very realistic. How do you express a particular design intent on the one hand and then have to hack the dimensions everywhere? Oh, and how do I explain your suggestion to a 4th grader? Not a realistic option.
- Bob
-
Permanently deleted user One more point worth mentioning... The flaw doesn't just happen when grouping a rotated shape and hole combination. As I read your response I was fighting with a jagged edge on a hi-res tube Generator rotated 45 degrees. Please factor that in when considering and ultimately implementing a solution.
-
Permanently deleted user This is probably a very personal opinion, so please take it as such. I don't think design intent gets affected when what you want is a tube 1mm thick and 25mm diameter, and you achieve it by creating a cylinder 25mm diameter, and then aligning with another cylinder 24mm diameter, which you make thicker than the solid. Once you group them, the thicker one disappears, so you get what you needed. I also find that holes longer or thicker than the solid makes them easier to select if you need to make edits. This has worked pretty well for me, both for my designs, and in several sessions with 7 to 12 year old kids.
-
Permanently deleted user Sure, sometimes hacking the dimensions of a shape won't matter. A lot of times it does though. Suppose I add a millimeter at the bottom of a hole so that the shape and hole aren't coplanar. Now, what if I need to rotate those 2 objects before grouping them? The mm that's been added will change the center point of the selection about which it would rotate. The same is sometimes true that the added mm will affect resizing and rescaling results. Sure, I could group, then rotate, then ungroup. And commonly I do. All too commonly. And this becomes an appreciable drag on productivity.
And if the cloud servers are overloaded that day, then the act of grouping, transforming, then ungrouping is no longer a local operation, but rather involves several network roundtrips.
Or, instead of using two cylinder objects like in the characterization I gave earlier, I could use the Tube Generator. Except that there's a huge bottleneck in Tinkercad processing Generators. So that results in a massive productivity loss because of an entirely different flaw.
Tell me Guillermo, how do you tell the public that you're going to "rewrite" Tinkercad, but the rewrite doesn't even address these central flaws like the ones we're talking about here? You're fine about just kicking the can further down the road. The product is in the wrong hands I tell you.
- Bob
-
Permanently deleted user This is Tinkercad. And this is okay in your mind? You'll "rewrite" the product but leave the rendering engine as it is? No excuses. This is 4 years after you took over the product.
-
Permanently deleted user Give me a break, Bob.
Because Guillermo, who doesn't operate in a vacuum, doesn't necessarily agree with your view of the universe, or at least its timeline, it's in the wrong hands? He's described a possible solution, which can't be implemented today, so it's in the wrong hands?
I for one do not envy Guillermo's position of trying to get a new TC developed while maintaining the old one as demand explodes.
As far as I can tell, that guy never sleeps. Or he's a zombie, I can never be sure what goes on in California.
-
Permanently deleted user First of all, I like Guillermo as a person. Who wouldn't? You're right, being a product manager is a tough job. Guillermo clearly works hard. But I'm sorry, the job takes more than sweat. It takes judgement. It takes the ability to successfully convince the management team to spend the necessary money. You have to get your arms around what to triage -- know what to fix first and how long it's going to take. Has Guillermo shown that judgement, that ability to execute and to persuade?
It's been almost 4 years now. As a point of comparison -- OnShape was founded after the date Autodesk took over Tinkercad. At this point the sizes of the development teams look similar, though OnShape's was initially much smaller. They built their product from scratch in that time.
I should add that what you don't see in this public discussion are all the private emails I've exchanged with Guillermo over the years. The series of unfulfilled expectations would curl your hair if it's not already. Four years, and he's still groping around for the solution to a problem that was on the table on day one. I'm not saying it's necessarily easy. I'm not saying they haven't tried. What I'm saying is that this is what we still have today, and I spend 100's of hours hacking my designs trying to work around flaws that, in my view, should have been one of the first priorities on day 1.
There was a time some months back when they were talking about a rewrite. Sure, that rewrite isn't denied when the subject's brought up. But seen any signs that it's on it's way or that's it's going to be something worth waiting for? Guillermo is signaling that fixing the shape generator API and fixing these rounding errors are both NOT on the T2 feature list. How do you feel about that Glenn? Months ago there was talk of a property manager and shape modifiers. Will you be disappointed if they don't make it either? Should I still give Guillermo a break if they're not? Or it T2 never even happens?
Tinkercad takes up "market space". It's difficult for a startup to get investment in this market as long as Tinkercad exists, even in the sorry shape that it's in. We love Tinkercad like we loved Novell, Word Perfect and Lotus back in their days. We were sad when they disappeared. But that opened up other opportunities for their replacements. Autodesk is CLEARLY struggling to get forward momentum on Tinkercad. Straight up... I think it's because Guillermo has perpetual optimism that's absolutely baseless. He's been unsuccessful both in getting the necessary resources and in bringing in the key players who pull the rabbit out of the hat and move the product forward. I'm not saying Guillermo sleeps too much. I'm saying that his personality isn't a fit for being product manager. Experience him as an evangelist, and a good one at that. But Autodesk's consumer apps need a product manager. Because time's running out -- whether you realize it or not Glenn.
- Bob
Please sign in to leave a comment.