4 ms·
The first thing you need to realize is that Tinkercad is only partially a browser application, we also run a relatively complex cloud based component. Every ope
by kaib 15y ago
The first thing you need to realize is that Tinkercad is only partially a browser application, we also run a relatively complex cloud based component. Every operation you make is actually distributed across a 100 core cluster with the result shipped back in a few hundred ms. We try to hide this as much as possible so unless you look at the application with a debugger it's hard to notice. I did a tech talk at Google about the full architecture here: http://www.youtube.com/watch?v=5aY4a9QnLhw http://www.youtube.com/watch?v=5aY4a9QnLhw
The browser itself is pretty robust. Our biggest issue is with old graphics drivers that cause problems with WebGL, this is an age old problem from game development. Hopefully more 3D web application will help graphics hardware vendors push out more stable software.
To answer your specific question. Our stack should be able to handle compound curvatures, the big question for us is how to make the UI manageable.
- replicatorblog 15y agoWow thats pretty impressive. Do you think you'll eventually embrace a "configurator" approach where you give people freeform capabilities, to a degree, and then supplement that with more in depth functionality that is constrained in a way to make the UI easier to handle?
- kaib 15y agoWe definitely want to make an API available that would allow almost anything to connect to the core editor. Using that it should be possible to write specific tools (like a lathe or extrusion style tool). We see Tinkercad as a core around which you can build more specialized tools and we want to give a broader community the ability to do so, not just depend on us to hack out new stuff.
- tjoff 15y agoThe first thing you need to realize is that Tinkercad is only partially a browser application, we also run a relatively complex cloud based component. Every operation you make is actually distributed across a 100 core cluster with the result shipped back in a few hundred ms. Interesting, but why? Just curious, I know nothing about javascript, WebGL etc. but what operations are not suitable to do on the client? If WebGL is supposed to be able to drive games etc. shouldn't it be able to handle this, without any help? (avoiding JS might be enough but I often feel that the, practically unlimited, power of the client is ignored) (only looked at the intro-demo of the google talk, will probably watch the rest when I have time)
- kaib 15y agoThe answer is somewhat technical so bear with me. tl;dr solid modeling is O(n^3) Computer graphics, which is what most games require, is largely a solved problem. An iPad or a WebGL browser is easily able to run most games from a few years ago without sweating too much. However, to model physical objects you don't just need a graphical representation, you need what's called a solid geometry kernel. What the kernel does is give you the ability to do boolean operations on two solid objects, something Tinkercad does with every editing operation. The problem is that these operations are computationally extremely complex, fundamentally O(n^3). When I say we use a 100 core cluster I specifically mean that many operations use the whole cluster. So if a single operation you make in Tinkercad takes 200ms of cluster wall time you might be using 10s of CPU time. And the code we run on the servers is optimized and vectorized Go/C++ code, easily 10x faster than anything you could do in Javascript. A second consideration is that we use gigabytes of memory to do each operation, which gives us the advantage of much faster running times. So when you compound these, instead of having to wait a second for your operation (depending on where you are located) a Javascript version would take minutes or hours for every operation. The kernel we have is unique, it is written from scratch for Tinkercad. As far as we know there is no equivalent even in the high end professional tools.