I run a small makerspace for kids and teens in Norway, and we kept hitting the same wall: the 3D tools we tried were either too fiddly for a 9-year-old or locked behind installs and accounts. So I built Akse — a browser-based 3D modeller for beginners, where the path from idea to a printable STL is as short as I could make it.
It's deliberately limited, but with a rather powerfull 2D Blueprint mode where you draw an outline on millimetre paper and extrude it to 3D. You build by placing and combining primitive shapes (box, cylinder, sphere, cone, pyramid, wedge, torus), set any shape to "hole" mode to cut it out of another. Everything is in real millimetres, so what's on screen matches what comes off the printer. Output is a single STL. That's most of it — no parametric constraints, no assemblies, no fillets. For teaching beginners that's intentional, not a gap.
The obvious comparison is Tinkercad — same space (primitive-based, browser, education-oriented), and I'm not claiming Akse is better. The differences are that it's open source, embeddable as a Svelte component, works in Norwegian as well as English, and is even more stripped down. It mostly exists because I wanted something I could shape around how our workshop actually runs, and put in front of Norwegian-speaking kids without an account or install.
Under the hood it's a Svelte 5 component using Three.js for rendering and three-bvh-csg for the boolean operations; storage goes through a small port interface so it's backend-agnostic, and the standalone version just uses localStorage. It's early (v0.1) and has rough edges. I'd really value feedback on where it trips up first-time users, since that's the entire point of the thing.
Source (AGPL-3.0, with a commercial option): github.com/joachimhs/akse3d
I have similar hopes for Solvespace - that every middle school student can pick it up and design things. We have a couple issues that keep me from recommending it too strongly though - bugs in the boolean code are IMHO the biggest blocker for kids.
Any chance you could have the kids make comparisons between the two? Solvespace is completely constraint-based, so it may be a bit harder to learn but also more flexible.
> that every middle school student can pick it up and design things.
The Solvespace UI is a long, long way from being the sort of UI a contemporary kid has any kind of comfort with, I'm afraid, and will be obtuse even to teachers (many of whom, with subjects that concern technology, do not have time to develop expertise in an obtuse UI and may indeed only be confident they understand the meaning of all the lessons they are teaching and not much more).
I don't think bugs in your booleans are your biggest problem at all.
I think Tinkercad has weaknesses as a classic CAD package, and there are things I would like to see done better, but as a package to teach younger people how core concepts in 3D modelling (rather than the ontologies of bRep) actually work, it is the standard you are working against.
which I find a little less confusing than the traditional 3D CAD packages I've tried (and failed to learn) --- at least for Dune 3D I've made it through the tutorial successfully.
As noted on the footnote for the project on Github:
>I ended up directly using solvespace's solver instead of the suggested wrapper code since it didn't expose all of the features I needed. I also had to patch the solver to make it sufficiently fast for the kinds of equations I was generating by symbolically solving equations where applicable. ↩
>> The Solvespace UI is a long, long way from being the sort of UI a contemporary kid has any kind of comfort with...
Respectfully, I disagree. Even adults have used the word "fun" to describe using solvespace. But I don't actually have feedback from kids, hence the question to OP.
Don't get me wrong, I think Solvespace is really important and I am glad you are keeping it ticking over, but it is the least fun UI I have ever encountered, I'm afraid (kind of obtuse on a trackpad too)
Not saying any of this is easy — Shapr3D on an iPad, expensive and marketed on its extraordinary usability, is just utterly perplexing!
Oh, I actually hate trying to use solvespace with anything other than a 3-button mouse. Unfortunate because the web version can actually run on my phone but is unusable in practice.
Not the person you were responding to, but genuine question: How are you interacting with computers without practically ever using a mouse? And how do you expect to use CAD software without a mouse?
I have used Macbooks with good trackpads since 2003. The models from the 2008 unibody Macbook and onwards are so very obviously superior to mice, that I simply have never wanted to use a mouse since.
My preference for mice was two-button Microsoft Mouse models (I had the magnificent early "dove bar" Microsoft mouse, which I regretfully had to replace with a 2.0 at some point). On the Mac, you only had one-button mice anyway.
For Linux I did try a nicely made Logitech three-button mouse, but ended up giving it away because some quirk of my neurology or physiology simply will not let me consistently independently address the middle button while holding or moving the mouse. I will almost always end up pressing one or other finger either side as well (sometimes enough to click it).
Scroll wheel mice are slightly better because the middle button is physically different (and often slightly raised). I do have one stored away in case I need it.
On a trackpad I do have individual fingertip tap control, for some reason.
I also use a wacom pen for photo editing, but those are not really much use for CAD. (Honestly, I don't get how people think Shapr3D is usable on the iPad with the Pencil; it is not)
For CAD: FreeCAD's "Gesture" control mode is superb! The "touchpad" control mode not bad. I've toyed with the idea of getting a Spacemouse for my left hand (or making one of the DIY ones) but I have never really felt enough need, because the Gesture mode is so fluid and instinctive.
>> Scroll wheel mice are slightly better because the middle button is physically different (and often slightly raised). I do have one stored away in case I need it.
Solvespace does great with a scroll-wheel mouse. Scroll = zoom.
> That's most of it — no parametric constraints, no assemblies, no fillets. For teaching beginners that's intentional, not a gap.
Fillets seems like an omission. For 3d printing, fillets are pretty important for getting good results.
Every other limitation makes sense to me, tho it’d be cool to see parametric constraints eventually, if you could find a way to add them without confusing beginners.
Thanks for making this! I will be recommending it over tinkercad going forward!
Group transform is out of order. It does not transform the group but the elements. This leads to the suspicion that position and rotation are not transformation chains on object trees but attributes. That would be the wrong architecture.
I am very sorry, but please explain. Why is this a nice looking Svelte / Three / CSG app, but the basics are wrong?
No, they are complaining that a basic functionality is not working and hinting at not having the right architecture to deliver correct results in more complex scenarios.
but this is clearly not meant to be onshape, its for kids who want to 3d print something.
the 'hole' mode does not seem to subtract like I would expect.
I think that's a lot better. "Please explain your wrongness" really had me scratching my head. Hopefully they can make improvements to the 3D architecture or find someone who can help.
This library provides a cache store for Svelte applications that simplifies fetching, creating, updating, and deleting items from a REST API that adheres to the simple-json-api specification. It also supports side-loading of related data and automatic cache management.
I find myself implementing similar backend APIs when I develop applications. These APis are more often than not based on REST principles with JSON payloads. As a result, I have publised the start of a simple JSON API spec at http://simple-json-api.com. This specification makes it easy to write both backend and frontend code to handle the data communication between the applications in a uniform manner. This approach makes it possible to write a fairly small amount of code to get advanced functionality on the frontend-data-layer.
While some good API specifications do exist, this project attempts to provide a common middle-ground being not too complex, while broad enough to not be too specific and too complex.
While, for instance, JSON:API is a thorough specification, Simple JSON API aims to provide a much simplified data-structure leaving the server-side specifics out of the specification. At the same time, while specifications such as JSON Web Key (JWK) is too narrow.
I am currently writing Ember.js in Action (http://manning.com/skeie). This book is, of course, through a traditional publishing company. Combined with the fact that this is my first technical book, my royalty rate is pretty low (10%). This is OK, as the book will reach a wider audience that I would on my own! So far, the book is approaching 2000 units in pre-sales (MEAP - Manning Early Access Programme), which make it the 5th most sold Manning MEAP of 2013 :)
I have started work on my next book project, which will be completely free and open sourced. This book will teach JavaScript programming to kids through building a Raspberry Pi powered remote controlled car (or or other vehicle). The content for this book is not yet available online and most of it will be created through a hands on 7-part course that I am teaching during the spring of 2014. You can find a bit more information about this book here: http://www.indiegogo.com/projects/open-source-programming-bo...
The way I see it, if the content is at all going to be approachable by children aged 11 and up, then that content needs to be well designed, typeset and proofread. While writing an open source book for professionals, pointing them to a set of markdownfiles would suffice if the content is good enough.
The idea is that the design and the content should facilitate children's learning as much as possible.
I could definitely go the publisher route with this, but then the whole project will change characteristics and be less dynamic.
Its not the open source code or project that is important in this project, its really the end result which is content that is easily approachable for the target audience.
I'm just telling you what it comes across as, a perception that apparently I'm not the only one to hold (in fact, I wasn't going to mention it except that dave_sid had the same reaction).
Defend it all you want, but that's not going to change the fact that some readers will see it as an underhanded jab.
Thank you for you comments. This is one of the goals that I am trying to achieve through my book-in-progress Ember.js in Action (Manning Publications).
And I do agree. Examples of large-scale applications built with any of the MVC-based frameworks is lacking.
Ember.js is a framework for writing web applications on the client side. This experience, and the end result will be a lot different that the type of web apps that you might be used to writing from the server-side.
I've created my share of Java-based server-side generated web applications, and when it comes to writing applications that run well on the web, JavaScript MVC frameworks are the way to go.
I can't comment on how it might affect your career on either the short of long term, though. That said, I expect that the demand for these types of rich webapps will become larger as we move forward.
I'm turned 22 ten years ago myself, but I think making that statement you made is unfair.
So you think that client side JS web apps are 'the way to go'. What's wrong with server side MCV web applications?
How does Ember.js in the clients browser scale when you have a a lot of data that needs marshaling / unmarshaling or generally processing and moving around? Surely it's more performant to do this on the JVM on the server rather than relying on the clients computing power (or lack of). Ideally you wouldn't do a lot of data processing in the MVC part of an app anyway but it seems like you're telling me the whole web app needs to be client side?
So, you would do most data-processing on the server side. But the data that your client-side application needs you will server to it, most likely via JSON.
You can definately go too far and implement too much on the client side, and this is generally a bad approach.
It's like with anything else. You need to figure out the balance between what you process on the server and what you process on the client.
Most data-processing (if not all) should be done on the server-side. Your API should give your front-end app as much of a complete data-set as possible. Note that data 'appearance' is fine on the front-end for the most part.
So what's the point of making the MVC portion of the application client side when I can just use Spring MVC (or similar) and keep to the same tech stack that the rest of the project is using? Same goes for .NET projects etc?
If you write all of your code to run on the server then you need to pull down a full page from the server every time you want to update your data.
There's plenty of reasons you might want to avoid this in some cases.
For example, you might want your forms to be validated without waiting for the user to push submit. You might have rich content in some markup language (like markdown) and you want the user to have a live preview on the same page as they are editing. Or you might have an app with real time data that changes frequently and you don't want the user to sit there pushing refresh constantly.
This functionality is already provided via AJAX. There's no need for me to put the whole MVC later on the client side to achieve this.
You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.
Once you are doing AJAX you are going to be writing Javascript (or something that compiles to it). Ember.js can help with that. So rather than writing a bunch of code to pull down JSON from the server and manually update the DOM in ways that deal with various browser quirks you can say "here's my model, here's how I want it rendered, link it to this REST API" and it will take care of a ton of heavy lifting for you.
It's true that it doesn't give you any magical power that you didn't have before and you can do everything it can do with vanilla javascript or any of the other frameworks. However that's a bit like saying you don't see the point of rails because you can just use vanilla PHP for everything.
You're speaking as if doing AJAX and doing client-side MVC are one step apart. Moreover, you're speaking as if using server-side MVC forces the programmer to use no JavaScript at all. At best, this is naive. Either that, or you deliberately misrepresenting technologies to promote something.
The simplest way to use AJAX with a server-side MVC is by fetching blocks of pre-rendered HTML. This is commonly known as AHAH. It's dead-simple to do, powerful and trivial to use via progressive enhancement. That is what you should treat as the server-side alternative to client-side MVC.
If your app has a lot of rich client functionality, it can be a lot easier to just use JSON data with client side MVC rather than having to constantly regenerate everything on the server, especially when several parts of the page need to be updated at once and a lot more performant.
Sounds like you haven't tried making a large AJAX app. Yes, if all you need to do is validate a form this or any other framework is overkill. You'll likely have multiple forms, lots of views, dynamically updating data, filtered tables, modals, etc etc. You can manage it all yourself, but frameworks like Ember maker this a whole lot easier.
Basically, your server side doesn't change much. The difference is that instead of outputting HTML, it outputs JSON.
Instead of writing your own code to handle AJAX on top of jQuery, you write code that handles the real logic and let the framework handle the DOM manipulation. In that way, it's easier to test, easier to debug, easier to provide superior experiences.
Right now, writing AJAX in the browser is equivalent of the JSPs of yesteryear. Remember all that horrific logic that used to creep into your JSPs? That's what jQuery looks like, and this new crop of frameworks is getting us to JSTL or facelets at the minimum.
The difference is that instead of outputting HTML, it outputs JSON.
Which is non-semantic, so it cannot be progressively enhanced, does not benefit from browser updates and is pretty much not crawlable by anyone except Google.
It's deliberately limited, but with a rather powerfull 2D Blueprint mode where you draw an outline on millimetre paper and extrude it to 3D. You build by placing and combining primitive shapes (box, cylinder, sphere, cone, pyramid, wedge, torus), set any shape to "hole" mode to cut it out of another. Everything is in real millimetres, so what's on screen matches what comes off the printer. Output is a single STL. That's most of it — no parametric constraints, no assemblies, no fillets. For teaching beginners that's intentional, not a gap.
The obvious comparison is Tinkercad — same space (primitive-based, browser, education-oriented), and I'm not claiming Akse is better. The differences are that it's open source, embeddable as a Svelte component, works in Norwegian as well as English, and is even more stripped down. It mostly exists because I wanted something I could shape around how our workshop actually runs, and put in front of Norwegian-speaking kids without an account or install.
Under the hood it's a Svelte 5 component using Three.js for rendering and three-bvh-csg for the boolean operations; storage goes through a small port interface so it's backend-agnostic, and the standalone version just uses localStorage. It's early (v0.1) and has rough edges. I'd really value feedback on where it trips up first-time users, since that's the entire point of the thing.
Source (AGPL-3.0, with a commercial option): github.com/joachimhs/akse3d