Tinkercad Raises $1 Million, Aims To Popularize 3D Printing(techcrunch.com)
techcrunch.com
Tinkercad Raises $1 Million, Aims To Popularize 3D Printing
http://techcrunch.com/2011/11/08/tinkercad-raises-1-million/
6 comments
Kai, What are the limitations you'll face in the browser? Will you be able to handle compound curvature in the future?
I love the concept and it seemed to be a hit at MakerFaire NYC!
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
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.
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.
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.
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)
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)
The 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.
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.
Wow 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?
We 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.
Any plans on supporting objects in standard open CAD formats? It'd be handy on occasion to be able to be able to dump an IGES or STEP file out of Solidworks and get it printed.
Yes. Real Soon Now (tm). :-)
Generic import is starting to be pretty close on the roadmap. After that it's just a question of adding file types as people request them. IGES and STEP are definitely on the list.
Generic import is starting to be pretty close on the roadmap. After that it's just a question of adding file types as people request them. IGES and STEP are definitely on the list.
Kai from Tinkercad here. Happy to answer any questions about the product or space.
Hi,
I have an idea for something that I could really use but can't find anywhere.. So let's say I design my thingy, I'm thinking of roughly the size of 20cm x 5cm x 4cm, how much would it roughly cost to have this printed and sent to me? Would it get much cheaper if I ordered 20 or 100 pieces?
This depends largely on material choice and to a lesser extent on which supplier you choose. Tinkercad is a design package, we don't do the printing ourself but outsource it to printing services like Shapeways and i.Materialise. I would suggest taking a look at their sites to figure out prices and materials.
Will you keep your operations in Finland or move somewhere else?
I used to live in Mountain View, CA and only moved back to Finland quite recently so we have a very strong connection to the Valley. It's no coincidence that we took money from the likes of Joshua, Eghosa, Taher and Jyri who all operate in the Bay Area. And True is obviously based there as well.
Speculating about the future is always dangerous but I think we will end up having a strong engineering presence in Finland. I also think it's very probable that we'll have another office in North America, maybe in the Valley.
Speculating about the future is always dangerous but I think we will end up having a strong engineering presence in Finland. I also think it's very probable that we'll have another office in North America, maybe in the Valley.
Congrats Kai!